Textastic for iPad

The beauty of an App Store is that you sometime stumble upon neat little gems and Textastic (iTunes Store link) certainly is one for me. Despite the hard to pronounce name, the app is amazing if you are a programmer that wants to edit text files either locally or on remote servers. The app supports FTP, FTPS and SFTP connections, with a password or a private key.

It also supports Dropbox and it does syntax highlighting for a ton of different file types and programming languages. The app is well done, well designed and, in my opinion, well worth the 10$ price tag.

It’s Not About The Rendering Engine Anymore

Today, RIM launched their new 6.0 OS (and the new BlackBerry Torch) and by doing so, added its name to the ever growing list of products using WebKit as the basis for their Web browser. RIM’s move isn’t really all that interesting: they had no good browser anyway and it’s not as if they are first to do this.

The interesting discussion in my opinion is what Microsoft should do. Back in the Netscape / IE war, Microsoft was convinced that Web browsers would ultimately replace desktops apps (they weren’t wrong) and they invested a lot of money in creating Internet Explorer. That war is still on, although nowadays the players have changed. With IE, we’re now talking about Firefox and Chrome as the main competitors.

But what really changed however, is that the HTML/CSS rendering engine shouldn’t matter that much. We went from a 1 browser = 1 engine model to a model where we now have a couple of really good open engines powering many browsers.

Controlling the world’s browser market is one thing, but as Google is proving, that doesn’t mean you need to have your own engine. Chrome is built on top of Web kit, just like Safari is and countless mobile web browsers are. These products are still competing with each others and are still different from each other yet they are built on the same foundation.

What that means of course, is easier Web development and less browser-specific bugs. This is why I think Microsoft needs to stop developing its own engine and start using either WebKit or Gecko. Both of these are well done, support many web standards and are fairly easy to integrate in a product.

Of course, such a change can’t happen overnight and it’s a difficult thing for Microsoft to do, but I do believe that in the long term, it’d make the Web a lot better. Trident, Microsoft’s rendering engine since IE 4 isn’t exactly renowned for its spectacular support for standards. And really, I’d much rather see Microsoft invest 18 months developing Internet Explorer proper rather than waste 80% of that time coding the engine.

Is Objective-C Really a Bad Thing For Apple?

Whenever flash on iPhone is debated, one of the thing that’s mentioned is that Objective-C is really terrible and Flash (or Action Script) is a much easier language to learn and to use. Of course, Action Script is loosely based on Javascript, a scripting language and Objective-C is a layer on top of C, so that does confer Action Script an advantage when it comes to ease of use.

What people seem to be forgetting however is that there’s more to life than ease of use. By using Objective-C and the Cocoa Touch APIs, Apple has a set of technology that’s not that hard to use (really, try to learn it, you’ll see) but also, a set of technology that while open, is also pretty much only used by them. I’ve said this before in my last post, but forcing people to learn Apple technologies is not a bad thing. It’s certainly a bad thing for flash developers looking to make quick bucks by quickly porting existing code, but for the rest of us, it means the developer has to spend some time on the Mac, learning how it works, what the UI paradigms are and why things work the way things work. Ultimately, this leads to a developer that might spend more time thinking about the UI issues and how to really optimize the interface for an iOS device.

Objective-C has been pretty successful for Apple on the desktop for years. When Apple “forced” developers to ditch Carbon APIs (C APIs) for Cocoa APIs a few years ago to benefit from the latest advances in the OS, many balked and predictions of doom were also thrown by many. As far as I can tell, my Mac seems to have survived and so did all of the apps I’ve used. Certainly it means that companies like Adobe and Microsoft had and have a lot more work ahead of them rewriting large portions of legacy code. You know what though? At the end of the day, we get stuff like Outlook for Mac, a newly written app that takes full advantage of Mac OS X instead of Entourage.

During WWDC, Apple announced that Farmville was coming to iOS. It’ll be interesting to see if that version will take advantage of iOS 4’s Game Center feature when it launches. By being a native app, it certainly has the potential.

Meanwhile, iOS 4 is coming out today for all users. Grab it, it’s a great update.

Keep it Pure (I’m Going To Sound Selfish Here)

Today, Apple announced a new version of the iPhone OS, the software that powers their mobile platforms like the iPhone, the iPod Touch and the newly released iPad (I’ll have my review soon). As part of that announcement, they have released a beta version of the SDK for us developers to play with but so far, the biggest news to come out of this is a little something they added to the license agreement.

John Gruber on Daring Fireball has a couple of post on this. To sum it up, Apple seems to have banned the use of Adobe’s Flash CS5 to iPhone technology or anything similar to that. What Apple has done basically, is force everyone to use their standards and their tools to code on their platform. Anything else is forbidden. That also impacts other tools like the Mono to iPhone stuff that’s also available.

John makes the point that it’s in Apple’s best interest and his arguments are good. I highly recommend you read the article in question but I’m going to go one step further here : I’m actually glad they did it and I think it’s a great thing for everyone involved except of course for Adobe and Flash-only developers. Here’s why.

If the Mac is known for anything, it’s for being a platform where attention to details is important. On OS X, we’ve seen a lot of application succeed because of the look and usability alone. The name “Delicious generation” was used to describe apps like these. Mac users expect apps to not only function well, but to look good, to act like a native app and to work like a native app. As such, the vast majority of apps available on OS X today are apps coded using Apple’s standards.

So what about the iPhone OS then? Well, by forcing people to use Apple’s tools, it forces people to be Mac users to develop for the iPhone platform. By doing so, it at least forces people to have a minimal knowledge of what it’s like to be on that platform. With any luck, that’ll end up improving the quality of apps on available on the App Store. Most people switching to Macs in my experience tend to become addicted to nice Apps anyway even if that was never really a concern before. It’s just part of the Mac mentality I guess.

I can understand why Flash developers are not happy and I can certainly sympathize with them, but I’m glad Apple did this. Let’s face it, Flash apps and Flash sites are not known for their great usability. They are known for flashy animations, terrible performance and for being generally harder to use.

From the start, the iPhone platform has never been an “open platform”. There are other platforms out there that are more open and equally great like Android. This is a closed garden. That comes with big advantages, but it also means you need to conform to the rules if you want to play in it.

How To : Adding SVN Info To Your Prompt

Ever since I switched to Linux years and years ago (and since then, to OS X), I’ve been carrying around a .profile script to configure my shell environment. The other day, I was browsing Ars Technica when I found a poster who had a very nice script in his prompt to add GIT info to his PS1 variable. Since I mostly use Subversion, I knew I had to adapt it but someone already did all the work! Let’s recap. My prompt usually looks like this:

user@computer ~/Documents/LCMM/Site/lcmm/trunk

That’s pretty good, but what if you could have SVN info when in a local repository. Here’s what I’ve got now:

user@computer ~/Documents/LCMM/Site/lcmm/trunk
SVN => [trunk:92]$

This gives me not only the local path, but also the current SVN path and the revision of the current directory. Of course, once you’re got that you can imagine other improvements that could be done here. To do that, here’s what I did. First, I downloaded this script on GitHub and placed it in /usr/local/bin (put it anywhere you want, it doesn’t matter).

Next, edit your bash init script (.profile for example) and add:

source /usr/local/bin/__svn_ps1.sh
export PS1="\u@\h \w \`__svn_ps1\`\$ "

That’s it. Pretty neat trick that could be adapted to anything else really. It works because the function returns either SVN info or nothing at all if this is not a local SVN repository.

In The Browser War, We All Win

If you’ve been around the Web development business for about 11+ years as I have, you will no doubt remember all the steps we’ve been through in the “browser war”. Remember how much better Netscape 3.x was compared to Internet Explorer 3? Or how truly attrocious Netscape 4 was once IE4 was released? Back in the Netscape VS IE days, web standards weren’t quite as established and prominent and with each release came new non-standard HTML tags. Good old Marquee tag. Remember the Layer tag? Each new release brought new headaches for developers trying to figure out compatibility between releases.

These days, the browser war is quite different. Ever since the rise to prominence of Firefox several years ago, we’ve seen what basically amounts to 3 important Web rendering engines: IE, Gecko and Webkit. With IE 9 coming sooner or later, IE finally seems to be catching up a little, although it’s too bad Microsoft still won’t adopt one of the other 2 engines and simply build IE around it.

Last week, news came out that for the first time, Google Chrome had surpassed Safari in Market share.While they may be newsworthy in itself, the much bigger news in my opinion is that combined, Safari and Chrome have about 10% market share. Since both use the Webkit engine, it’s a great news for both parties. At the end of the day, who controls the frame around the HTML renderer doesn’t impact us much. The really crucial bit is the renderer itself and Chrome’s popularity only helps here.

Apple has been the main driver behind Webkit ever since its release (as a port of the Konqueror engine) several years ago but Google’s participation has been increasing along with its own usage of the engine for the Chrome browser. With HTML5 and CSS3 still not completely implemented, it’s great to see 2 giants working together on that aspect. As much as Google and Apple might be competing these days, both of their phones are using the same HTML rendering engine and it’s a great example of how open source can sometime help. With the Web, what we need is a standard compliance, not a bunch of smaller rendering engines that each have their own bugs and features.

As for Javascript, each player has its own engine. Google’s V8 engine is extremely fast but Safari’s engine is not slouch either. Firefox is also making advances here but since Javascript has been fairly stable, multiple engines aren’t hurting us at all. While these 3 battle for speed, we reap the rewards.

At the end of the day, we all win. Let the war continue and let’s hope that Microsoft will at some point ditch its own engine and pick of the open source ones. Google and Apple have proven that you can compete and still share the headaches and costs associated with developing a complex rendering engine.