Ben Allfree :: Painless Programming

iPhone and OS X

admin — Tue, 23 Dec 2008 13:38:49 +0000

⇒ Having an Opinion

Strengths: niche, cult-like loyalty

Weaknesses: weak dev tools, limited market

Verdict: Thumbs Up

iPhone development is all the rage right now. You can do it two ways: first, you can develop a little "iPhone-aware" browser app that runs inside the iPhone's internal browser but otherwise looks like a normal application. This is Apple's widget strategy and you can find the same sort of thing on OS X's widget dashboard. I never use it.

The second way to approach iPhone development is to write a real, "on-deck" iPhone app that installs on the phone. These are much harder to write (you need to use Objective C, Apple's primary development language) and you might not get it approved for distribution in the Apple Store. Not being listed in the Apple Store kills your chance for success. Without Apple's blessing, 99% of iPhone users will never see you, and more importantly, will not be able to install your application. Apple holds the keys to software installation on the iPhone.

There is no inside track to getting placed in the Apple Store. Each app is reviewed for conflicts in business strategy and software code quality. I can make sure your app passes the QA tests, but nobody can promise Apple will let you in. You're putting your chips on the table and spinning the wheel. Hope it lands on green. I mention this because a if you ask to see links to my Apple Store apps, you have to realize that being in the Apple Store is way beyond my scope of influence.

The iPhone's UI is a paired down but optimized version of OS X. A lot of the development techniques used on the iPhone will be familiar to OS X developers while leaving developers of other platforms wanting more.

From a business standpoint, I need to question the value of serving the iPhone/OS X niche. But that's always been the case with supporting Apple. You have to believe that the loyalty of the customers makes up for the smaller market size.

With mobile device programming in general, it seems that you can't target just one. I'd no sooner advise that you make only an iPhone version of your app than I would you make a SmartPhone-only or J2ME-only, or Symbian-only version. I think a good mobile strategy is one that has value on each platform. Otherwise your business plan is married to a particular device, or even model of device.

Still, there's a lot of excitement about iPhone right now. Kind of like there was when Facebook first opened their API. My prediction is that, like Facebook, a few early players will get all market share, but that it won't be you. And those who do get the market share will find out it's hard to charge money for it.

But I can't blame a person for trying.

Thumbs up for iPhone!

Silverlight 2

admin — Tue, 23 Dec 2008 13:13:33 +0000

⇒ Having an Opinion

Strengths: slick as hell

Weaknesses: raw

Verdict: Thumbs Up

Silverlight brings .NET to the browser.

You can tell when you use it that it's a mish-mash of Microsoft's latest ideas for the framework. It's got a little XAML (but not all of it), some GUI controls (but not all of them), some .NET support (but not all of it), and some nice design time tools (but not all of them).

I looked at Silverlight 1 a year or two ago. It was just not ready. If you wanted to make a button, you had to draw it yourself with graphics primitives like rectangles and gradient fills. The plugin crashed on my browser a lot. But Silverlight 2 feels like a much more complete attempt at bringing .NET to the browser.

The stack of Microsoft tool downloads you need to develop Silverlight stands about 10 tall. You can imagine that it's painfully slow when you're trying to run all that shit at once on your computer. But the end result, the Silverlight experience that users have, is very nice. The interfaces are responsive, they look slick, and well, they are slick because they've got the programming power of .NET behind them.

My main complaint about Silverlight right now has to do with the completeness of the development tools. There is no WYSIWYG (please don't say Expression Blend), the process is memory hungry, and there are many subtle requirements that are neither documented nor reported adequately when an error occurs.

But the bottom line is it's close enough. You can actually build applications in Silverlight 2 that get stuff done. It's not as polished as Flex or Flex Builder but I'll take the .NET framework over Flex's API any day.

Thumbs up for Silverlight.

Amazon AWS

admin — Sun, 14 Dec 2008 02:38:55 +0000

⇒ Having an Opinion

Strengths: infinite

Weaknesses: questionable usefulness

Verdict: Thumbs Down

Amazon AWS mainly consists of S3 (infinite storage) and EC2 (infinite computing) in my projects. I'd venture to say that's true for you too even though AWS has other services too.

Amazon's claim is mostly true: they do offer, for all practical purposes, bottomless resources at utility pricing. The pricing isn't actually that great until you get into large capacities, but then it gets very competitive.

Designing an application to use AWS requires - to my way of thinking - a fundamentally different approach to application architecture. Basically, Amazon looked at their own infrastructure efforts and wondered how to sell it. That means your applications need to work according to how Amazon thinks scaling should work. The biggest limitation used to be that EC2 instances lost all their data when the power went out. This is because Amazon used EC2 internally as raw computing power that could be provisioned to any one of a number of specific servers pre-configured to do a job within their infrastructure. So you have to design your application the same way. Is it a bad idea? May be not. But it's certainly not the only or easiest way to design things. As my good friend said, if you are willing to ignore an assumption that has been true for the last 30 years (that data persists when the lights go out), EC2 sounds great. They've worked toward addressing the problem, but I still don't quite trust EC2 like I do other virtualization ISPs.

S3 is basically a big hash table. You give it a key and some data to store and it does it. If you name your keys to look like URL paths, then you can access it through HTTP too. So it's a giant static content bucket. Recently, they introduced edge caching to make S3 even faster. They've also introduced features like key renaming. By golly, one of these days it might behave like another 30-year-old concept: the file system. Until then, it still seems a little quirky and you really need to design with S3 usage in mind.

Now we come to the big question in my mind. I like to question big things, like whether cloud computing and utility computing really address needs you actually have. I can't speak for all businesses, but for you and me, utility computing answers a problem we don't have. I imagine over 90% of the web does not have the type of infrastructure problem AWS solves. Sure, you can invent problems that AWS can solve, but when you really sit down to look at who is using AWS and how, you begin to understand that it's a toy for them. Yes, they get up in front of the audience at the AWS conferences and say how AWS solved a massive infrastructure headache at a fraction of the cost because they didn't need to buy hardware. They espouse the virtues of infinite scalability and how they're ready for traffic spikes. But here on earth, very few of us are affected by scaling problems to an extent that would merit a fundamentally different application architecture.

To put all this in context, I say it from a base of experience. I have designed several apps that leverage AWS successfully. And each time, what I saw was that it was a big effort with a potential payoff down the road.

If you like to plan for success early, AWS may really resonate with you. If you're more in the Agile camp of doing things only after there is a concrete and observable need, then AWS is probably something you can skip until you have so much traffic and cash flow and investors that you can buy your own infrastructure. At that point, you can compare AWS against the big boys like Akamai. In the end, I suspect that if you stay Agile it will always be better to roll your own. See any of my blog posts about frameworks for more thoughts on this.

Overall, as much as I like the idea of AWS, I need to say thumbs down because it just hasn't proven to address a critical need for you. I love the idea and I love thinking about how awesome it would be to have a problem that AWS solves, but so far I have not come across one nor do any of the startups using AWS appear to have a concrete need for it. It's more like they're doing it for the publicity. The central point is that you pay for cool and, in this case, it doesn't pay you back.

Git

admin — Sun, 14 Dec 2008 02:36:26 +0000

⇒ Having an Opinion

Strengths: fast, clean

Weaknesses: constraining

Verdict: Thumbs Up

git is like the MacGyver of revision control systems. It's a faster Subversion. There are other advantages too, but I don't use them. My revision control needs are simple because my team sizes are normally 1-3 people. For larger teams, git's organizational features begin to shine. It was designed for that.

For my modest needs, I find all revision control systems constraining. You can't wantonly move or delete files and folders. Instead, you have to essentially ask permission by telling the revision system what you have done. I'm more of the genius mess-maker type when I'm in the middle of programming. I don't like to stop and think about logistics like that because it breaks the flow. Don't get me wrong, I always clean up my messes. But I'm not afraid to make them when I'm creating. Cleaning up your mess later runs counter to revision control system philosophies.

But you gotta have one and if you gotta have one, git is the one.

AJAX Frameworks: prototype, scr.iptaculo.us, jQuery, ExtJS

admin — Sun, 14 Dec 2008 02:31:18 +0000

⇒ Having an Opinion

Strengths: kung-fu made easy

Weaknesses: smells like RIA, hard to debug

Verdict: Thumbs Up

I know that AJAX isn't the same as client-side scripting. I'm lumping them together here because you can't have much of one without the other.

I've used most of the JS frameworks out there. They all share a similar strength. They make complex cross-browser scripting easy. With them, you can hook into events, set timers, perform animations and transitions, create popups, and in general make the browser window behave like a desktop app.

Every once in a while I see some useful AJAX applications. I like edit-in-place solutions if validation is handled properly. I like Lightbox for slideshows. I kind of like what Facebook did with the profile drag-and-drop layout management.

But so often, AJAX errors and validation are improperly handled ignored because, well, it's hard to do right. How do you handle unpredictable errors with AJAX? Normally a framework or web server would return a generic error to the user. After all, the point is that something unpredictable happened. Your application didn't anticipate it, so the underlying framework caught it and ended as gracefully as possible. But when that happens in AJAX, the user doesn't see it. The AJAX operation looks like it completed, but you find out later that your data did not save.

AJAX is hard to debug, hard to fail with grace, and can sometimes get a little carried away to the point that it starts smelling like RIA. Too much animation, too much solving problems differently for its own sake.

Overall, I give AJAX a cautious thumbs up.

Flash, Flex, AIR and RIA in General

admin — Sun, 14 Dec 2008 02:27:39 +0000

⇒ Having an Opinion

Strengths: ubiquitous, sizzle

Weaknesses: cancerous, subversive

Verdict: Thumbs Down

I'll probably get in trouble for calling Flash cancerous. I want to describe how difficult it is to decide where Flash stops once you start using it. You may start with just a slick menu or front end of some kind, but pretty soon you're thinking about writing your message forum in it. Clearly something took a wrong turn, and Flash is weird that way. It's hard to find a good place to transition back to your 'regular' application because the Flash user experience just feels a little bit different. There's always a seam when you move between Flash and the rest of a web site. Flash is so slick and smooth that it makes all the seams really noticeable. You keep building more in Flash to maintain that seamless feeling. For this reason, I do not like Flash for anything except playing media on a page.

But, I'm loathe to admit that Flash has sizzle and that is very attractive to some people. I have yet to meet a paying customer who really gives a shit, but the marketing and CEO types of startups are all about sizzle, so Flash gets abused frequently.

From a programming perspective, I find the ActionScript language crude like PHP. I don't care for the organization and documentation, and they have left out key functions of ECMAScript (JavaScript) that would make modern programming principles shine. It's undoubtedly a legacy issue once again. The Flash team is mired down with an interpreter that can only do so many things and never anticipated the direction things have taken.

Flash really shines and there is no substitute when it comes to video recording and playback. The Flash player is ubiquitous and it is the one video format that nearly everyone can play on their computers. Flash is the only solution when it comes to webcam recording.

Finally, I have to make a RIA confession. I just don't see it. I can't get excited about RIA and I feel like I've done enough of it to have given it a fair chance. You can get so much more real work done in other platforms that have better server-side support. Put it this way: you can name the commercially successful RIA applications on one hand, and none of them are at the top of the dog pile.

Thumbs down for RIA.

Classic ASP, .NET WinForms, ASP.NET, ASP.NET MVC

admin — Sun, 14 Dec 2008 02:23:40 +0000

⇒ Having an Opinion

Strengths: documented, complete, high quality

Weaknesses: compiled, master-of-nothing

Verdict: Thumbs Down

.NET has the best documentation you are going to find in any platform. It's commercial and presumably a bunch of people were paid actual money to make sure the documentation was correct and complete. For the most part, I find that to be true. In some cases it can't compete with a community-driven doc site like PHP has. Then again, a lot of the user comments for PHP address shortcomings in PHP itself. You don't have that problem with .NET.

.NET is also one of the most complete platforms you will find. Whatever your objective, .NET undoubtedly has some kind of supporting library for it. This support runs the gambit from RS-232 communication to SOAP and XML parsing.

.NET's completeness also leads to a pretty serious disadvantage: its very completeness leads to a deeply-nested structure where almost everything you need is buried and hard to find. You have to learn to think like Microsoft did when they designed the thing. Contrast that to PHP and Ruby on Rails which have a very flat structure. Almost everything you need is within 1 or 2 levels deep and the documentation reflects it. .NET is more like 7 levels deep. That makes .NET optimized for nothing, and that's a problem to me.

Finally, .NET is compiled. It wants to be compiled. It needs to be compiled. That makes deployment a mess because you can't just hop onto the server and 'tweak' something. If you are someone who thinks this is a positive feature, then feel free to move this to the pro side. There are plenty of other benefits of a compiled language (like type checking).

Classic ASP is dead for new projects. I don't recommend starting anything in it, but many companies have existing applications written in Classic ASP. Classic ASP is probably among the worst options when it comes to modern design principles.

Overall, I give the Microsoft stack a thumbs down for the types of applications I frequently build. Even so-called Microsoft Shops would benefit from considering something that more directly addresses the application space and marketplace they are targeting. The exception might be if they have a large investment in essential business libraries and for whatever reason can't expose those as web services.

PHP 5/6

admin — Sun, 14 Dec 2008 02:19:43 +0000

⇒ Having an Opinion

Strengths: deployable, fast, ubiquitous

Weaknesses: buggy, crude

Verdict: Thumbs Up

PHP pretty much runs the Internet. You can't argue with that kind of success, really. Despite any shortcomings of PHP, the reality is that a lot of people pay the bills with sites powered by PHP.

From a programmer's perspective, I find the PHP language to be crude. It is old and behind the curve as far as modern design and thinking goes. Even the modern MVC frameworks now available for PHP have shortcomings rooted in the language itself.

The core PHP development team have legacy issues to think about. Each new version of PHP will always feel like a Frankenstein. I personally am not bothered by that, but some people really are. What does bother me is that the PHP interpreter itself contains language bugs. Complex examples of valid PHP directives do not function properly and that limits my ability to apply modern design principles. The central reason this problem exists is that the PHP development team is trying to teach an old language new tricks.

So which is it? Thumbs up or thumbs down for me? Today, I need to say thumbs up. Despite its shortcomings, the rubber meets the road with PHP. It's easy to deploy, well understood, and most tasks have about 1,000 samples of how to do it. The community is vast and that makes up for a lot of imperfection.

Ruby on Rails 2.x

admin — Sun, 14 Dec 2008 02:12:29 +0000

⇒ Having an Opinion

Strengths: dynamic, modern, testable

Weaknesses: slow, memory-hungry, difficult to deploy

Verdict: Thumbs Up

Ruby on Rails is a great web framework because it establishes smart conventions and application structure. To those of us who already were making well-structured web applications (particularly true in the Java community), it took us a while to see what the big deal is about Rails. After all, we were already using many of the practices Rails brought to the masses.

Even so, Rails is a pretty big deal. The productivity gains of using Rails are quite impressive. The underlying language, Ruby, is very capable and beautiful. Compared with a language like PHP, Ruby is just elegant and wonderful. If you are a competent Lisp or Python programmer, you are probably scratching your head wondering why Ruby became more popular. I don't know either. Probably because Rails is written in Ruby.

My main complaint about Ruby is deployment. If you have lots of hardware and prefer an organized deployment approach, Rails will feel right at home. On the other hand, many clients I work with prefer a simpler ad-hoc deployment process and want to use stock servers and ISPs. In that scenario, Rails is harder to deploy relative to other technology options.

Terms of Service

admin — Sun, 14 Dec 2008 02:07:28 +0000

Did your last programmer protect everyone’s interests with a service agreement?

You can tell I provide a really focused, defined service. I have a really defined contract that goes along with it. We always use mine, not yours. That’s because I know what I am selling and how it needs to be sold. I want you to fully understand it too. The process is so critical to our success that I don’t want you trying to define it with your own contract.

It’s pretty boiler plate, I can show it to you if you ask me and you’ll definitely see it before we start working together. It says that I do the work and you get the credit.

It also has a toothy bit about collection agencies for people who think it’s fun to order work and not pay. Bug fixes are free and the work will get done. If you order something, plan on paying even if your business plan changes and the work I did for you doesn’t fit anymore. Sometimes that happens, try as we might.

In all honesty, I’d rather work on a hand shake. And most of the clients I work with end up feeling like me, that we didn’t really even need a contract. We’re rolling along and having so much fun that it seems crazy to imagine anything different. But I’m not clairvoyant either, and I just can’t tell ahead of time who needs the contract and who doesn’t. So we all use it.