. .

development

Getting Large Usually Means Getting Stodgy

February 4, 2010 12:22:05.896

Everything I read about Microsoft lately sounds like a replay of IBM back in the 80s: years of coasting on a profitable business (Mainframes then, Office/Windows now) have led to a very inward looking company. The NY Times has an article from Dick Brass that makes an interesting point about Tablets and Office:

When we were building the tablet PC in 2001, the vice president in charge of Office at the time decided he didn't like the concept. The tablet required a stylus, and he much preferred keyboards to pens and thought our efforts doomed. To guarantee they were, he refused to modify the popular Office applications to work properly with the tablet. So if you wanted to enter a number into a spreadsheet or correct a word in an e-mail message, you had to write it in a special pop-up box, which then transferred the information to Office. Annoying, clumsy and slow.

Rob Fahrni points out that the VP who pushed that POV was Steve Siofsky, who's now even more influential at MS. I think the next few years at Microsoft are going to play out a lot like the 80's did for IBM: a large decline (not death), with the possibility of a second (less influential) act - if they get a management team that can adapt to the new reality fast enough.

I lived in East Fishkill, NY when IBM started to run into trouble, and it really left a mark on that area - most jobs were either directly with IBM, or in businesses that served them or their staff. It took a long time before that area was able to diversify off being such a "company town" - I suspect Redmond is in for a lot of the same.

Technorati Tags: , ,

posted by James Robertson

 Share Tweet This

development

Objects, Hashes, Closures

February 2, 2010 9:01:56.393

Michael has some interesting thoughts on the unity of Objects, Hashes, and Closures.

Technorati Tags:

posted by James Robertson

 Share Tweet This

development

Files or Data Stores?

February 1, 2010 20:25:27.922

Gilad Bracha sees the iPhone and the iPad, and has decided that they portend the end of the filesystem as we know it:

Which brings us to the programmer experience. File APIs will disappear from client platforms (as in the web browser). So programmers will become accustomed to working with persistent object stores as provided by HTML 5, Air etc. And as they do, they will get less attached to files as code representation as well.

Well, not so fast. What's actually happening is that the end user experience (apps manage the file system for you on an application specific basis) is diverging from the developer experience (writing the code to make that "magic" possible. Take iTunes or iPhoto - I never really look at the way either application manages things. From my end user standpoint, there are two folders I don't need to pay attention to (Music and Pictures). Underneath all of that is a mass of files (raw photos, XML metadata, edited photos, etc). All of that stuff is stored in... files.

Heck, even if you think everything will end up in the cloud that won't change. The end user will end up seeing application defined portals into their data, while the back end will be some combination of application specific file storage, databases (etc) - all in a filesystem somewhere.

As to developers moving away from files - well. Anyone who uses a source code control tool is moving in that direction already. It happens to be the case that the simplest artifact to go into these tools is usually the file, but those files are increasingly organized into some kind of package structure that is more meaningful.

posted by James Robertson

 Share Tweet This

development

Paging the Past

January 31, 2010 20:32:15.774

While I understand what Mark Pilgrim is on about in this post, I have to say, it made me chuckle:

Once upon a time, Apple made the machines that made me who I am. I became who I am by tinkering. Now it seems they're doing everything in their power to stop my kids from finding that sense of wonder. Apple has declared war on the tinkerers of the world. With every software update, the previous generation of "jailbreaks" stop working, and people have to find new ways to break into their own computers.

Why am I chuckling? Consider the car tinkerer of the 1950s, transported in front of a modern car. I rather suspect he'd say a whole lot of the same things. Have we lost something since then? Maybe, but then again, cars are safer, simpler, and more reliable now. I think we'll be able to say the same thing about computing devices, too.

The computer sector, like audio systems (back in the 20's) and cars (up until the 50's or so), is moving past the tinkerer stage. It's less something to rage against than it is something that just is...

Technorati Tags: ,

posted by James Robertson

 Share Tweet This

development

PHP to Get Faster?

January 31, 2010 10:22:23.845

If this report is true, then maybe PHP will stop being the red headed stepchild that everyone seems to love to hate:

Well, I was able to put all the pieces together on this one, finally, and I now understand exactly what is up: Facebook has rewritten the PHP runtime from scratch. This coming Tuesday, they will make a big announcement around this project, and will make it available as open source software. I'm not really sure of any of the details of the project, but I do know that Facebook hired someone two years ago to do this, and I'm relatively sure this was a one-man project during that entire time.

Still sounds awfully speculative to me, but I guess we'll know the quality of the reporting on Tuesday. In the meantime, if you want a faster web runtime - both for development and deployment - you should have a look at Smalltalk.

Technorati Tags: ,

posted by James Robertson

 Share Tweet This

development

The Future of Computing

January 24, 2010 22:04:35.272

Gilad Bracha is worried about the future of computing - specifically, about the ability to use whatever development tools you prefer:

The iPhone is a prime example of a trend where our computing platforms become more restricted. As we move toward software as a service rather than an artifact, the computer is no longer as personal; it is very much under control of the service provider. In this case Apple, in other cases Amazon or Google or Microsoft. I'd be surprised if the rumored iTablet won't work on the same model: rather than an open version of MacOS, a semi-closed world with an app store.

The thing is, the ability to use whatever you want on the back end has never been more open than it is now - you can get full root level hosting at very affordable prices now (I've done that for this site). Things seem to be moving towards a fairly small set of front ends, with HTML/Javascript being the most prominent one. You can build your back end with complete freedom, using whatever tools you like. Sure, you have to pay for that - but who ever said life was free?

Technorati Tags: ,

posted by James Robertson

 Share Tweet This

development

Flash Coming to the iPhone

January 11, 2010 9:24:03.458

Well, Flash is sort of coming to the iPhone. But, it's enough to start a small tidal wave. TechCrunch reports:

Adobe is going to bring its 2 million Flash developers to the iPhone, with or without Apple's blessing. As it announced in October, the next version of its Flash developer tools, Creative Suite 5 (currently in private beta), will include a "Packager for iPhone" apps which will automatically convert any Flash app into an iPhone app. So while Flash apps won't run on the iPhone, any Flash app can easily be converted into an iPhone app. (Microsoft is taking a similar approach with Silverlight). This is a bigger deal than many people appreciate.

For good or ill, Flash is the standard video format on the web. HTML5 may change that over time, but not soon. For the forseeable future, Flash is pretty much where it's at if you want to hit the majority of browser users. More importantly (and this is what Apple feared early on) - it'll "flood the zone" with potential iPhone developers:

Once Adobe publicly releases CS5, Flash apps and video still won't run on the iPhone. But those 2 million developers will be able to keep working with Adobe tools and simply turn them into iPhone apps automatically. In contrast, there are only an estimated 125,000 or so iPhone developers.

Heck, I have the Flash SDK on my Mac inside Eclipse. I have the Glare code that hooks that up to VisualWorks. That means that with a fair amount of ease, I could probably package up a "Smalltalk Daily" app for the iPhone that drove itself off a VW back end once this comes out.

Technorati Tags: , ,

posted by James Robertson

 Share Tweet This

development

Y-2010

January 6, 2010 21:32:05.537

When I read stories like this, I end up feeling a whole lot better about my own code. An astonishing number of systems had trouble with the changeover from 2009 to 2010:

Chips used in bank cards to identify account numbers could not read the year 2010 properly, making it impossible for ATMs and point of sale machines in Germany to read debit cards of 30 million people since New Year's Day, according to published reports. The workaround is to reprogram the machines so the chips don't have to deal with the number.

To get that, you would have to have your software assume the first three digits of the year and just add the last one - apparently, some developer just assumed "of course this won't be running in 2010". The hilarious part is that this happened so soon after the whole "just assume the leading 19" thing from the last century's software...

posted by James Robertson

 Share Tweet This

development

Hard Coding

January 6, 2010 6:53:24.509

I should know better by now - when I hacked in support to my client posting tool for automated tweeting, I hardcoded the blog that the tweet was assumed to be coming from. Well, here I am, with a new blog, and said assumption blew up on me :) Hat tip chaetal for getting on me about it :)

posted by James Robertson

 Share Tweet This

development

There's Always a Bug

January 3, 2010 11:44:14.303

Sometimes the bugs make no sense, at least not to anyone who isn't looking at the code. Take this one, reported from Australia this week:

BOQ's Eftpos machines skipped ahead six years when the clock ticked over to January 1 and started date stamping January 2016.

I can't really laugh that loud, because the archive bug I used as a launch point for this post earlier in the week was pretty stupid, and - to anyone but me, who wasn't looking at the code, inexplicable - archive links worked for any non-2010 date :)

Sometimes, developers toss in code "that's good enough for now" - leaving a grenade that explodes in someone else's face later. I'd bet good money that the BOQ bug is like that.

posted by James Robertson

 Share Tweet This

Previous (61 total)