One upon a time, before the web, developers created interfaces with forms, tabs, buttons, complex database back ends, and fancy effects. We did it with the tools we had, some good, some bad (and some ugly). Most development now a days is done on the web using HTML and HTTP. We do all the same things we used to do but the web solved a whole bunch of very difficult problems, the biggest of all being distribution.

With the transition to the web we took a lot of those tools and the methodologies that built those tools with us (the good, the bad, and the ugly). We learned a lot of new mistakes, forgot the mistakes we already made, and created a lot of great things. I wonder if the methods we use today are based on good sound design or just lazy default based on lazy defaults. I have a lot of opinions on the matter but they are based on logic and gut feel, hardly scientific. But one thing bothers me:

What ever happened to the event loop? GUI applications use to start up, do some set up, draw the UI, and wait for the user to do something. Most web applications start up, look around, figure out why they were created, do something, and shut everything down. Using this model, doing complex things become a total mess. Model dialogs become hundreds of lines of code, complex state becomes a burden, it becomes easier to just pull everything from a database all the time, and we spend most of out time doing the same thing over and over.

Bring back the event loop.

 

If your code-base does not conform to modern day quality standards and efficiency standards what do you do? Start over, isolate, or migrate?

Doing it over would allow you to do everything right but support would have to be dropped for most of your customers. That is suicide. Migration is a useless and demoralizing process that will leave most programmers (including this one) slipping back into bad practices and hacks to fit the existing methodology, in an attempt to get work done.

So with staring over being suicide and migration fixing essentially nothing, what do you do? Compromise, I guess. Isolate the existing code-base via and API and services giving the option to rewrite some essential pieces.

I guess that is the only option. *sigh*

All other languages suck. Seriously! I could go on and on about why I feel that way but I will spare you. If you want to remain a happy developer don’t ever lean Smalltalk.

Yea Canada!

2009-04-03

While the US (my native land) is in the middle of a finical ”crisis” Canada is doing ok. Thankfully I reside in Canada. I hear a lot about this, people say it is because Canada regulates this or that “more”. I am not sure what “more” means and have never heard anyone quantify “more”. In fact I think “more” regulation has little to do with it. Canada is conservative, not in the way that usually means but in the way it should mean.

Canada is careful. No sudden moves. Banks have not suddenly had a huge shift in the way they are regulated. The Government has not taken huge risks with deficit spending, wars, rapid shifts in regulation, or spending amounts. I am sure that, at times, Canada has made sudden moves. Certainly provincial insurance would be considered a sudden move by some, but by and large in my, admittedly, limited experience with Canadian government has been one of caution.

Thank you Canada be being careful and for putting thoughtful action above emotional reaction.

The Basis of Ten

2009-03-25

Zero through ten. It strikes me as a mistake to base a numerical system on the number of fingers one has on her hands. This arbitrary decision made by someone centuries ago has firmly taken hold in all aspects of our lives. We tend to think in 10, most of the world measures in 10, math is represented in tens, yet 10 is not devisable by 3 or 4 but only by 1, 2, and 5. It’s nice to have a half of something but what if I only want a third?

So we have a dozen eggs, 12 hours in a day, 60 minutes in an hour. These number are divisible by a much larger set of numbers than 10. 12 has 1, 2, 3, 4, and 6. 60 is devisable by 1 through 6! Moving the world to a base 12 numerical system would, of course, be folly but I think 10 was a bad initial decisions. Like so many bad initial decisions, made by ourselves or some person hundreds of years ago, we are stuck with it.

I sure would like to have a third of a meter.

On second thought duration is a bad example because it is a mixed radix system. We have 60 seconds in a minute, 60 minutes in an hour, and than it falls off the tracks. 24 hours is a day, 7 days in a week, …. woops backing up …. 28-31 days in a month, 12 months in a year, 365 (1/4 (unless your year is devisable by 100 but not if it is devisable by 400) ) days in a year, and lets not forget about leap seconds.

At least I get my bagels by the dozen.

Recently I have received the opportunity to head up a team that was to produce mobile software targeting two platforms, Blackberry and iPhone. Because of the constraints of our product we decided to create them as web applications and not native ones. I just received a link to an independent review of the Blackberry version of the site. It is very positive.

It was not easy. There was a lot of effort put in both in code and in interpersonal relationships. There were battles both internal and external to get this thing out there. Everyone who worked on the project in any way should be very proud. I am.

The Power of Small

2009-03-02

In the time I have been a software developer, about 11 years (oh crap I am getting hold), business software is usually written as huge monolithic systems that do everything a company has ever dreamed of or so they think. They are generally written in a single language that compromises a little bit of everything so that it can do an adequate job at everything. They usually offer little interpretability within there own massive architectures and almost no interpretability with other systems. I don’t know why so much software is written this way but I suspect it is largely motivated by fear. Companies don’t want to interoperate with competing systems because they are afraid that customers might leave and software development managers don’t want to develop outside of the chosen architecture or language largely because a fear of what they don’t know. But …

No language is good at everything. I would not want to write web applications in C but I would not want to write system drivers in PHP either (or just about anything BUT a web application).  It appears that a disturbingly high number of developers are very hesitant to go out side their comfort zone. They know Java or PHP. That that is all they ever want or think they need to know.

Not everything is like this. One of the core ideas behind UNIX was small simple applications that work together with each other over a standard form of communication. Applications could communication with each other over a “service” (hot word now a days) in plain text. This was and still it great for text processing but does not excel at complex hierarchical data. Developers need a quick, simple, standard, and language neutral way to communicate complex data in a stateful manner across languages and the network.

Service oriented architecture with SOAP at its helm is supposed to solve all this. But … well … SOAP is not ideal. The protocol is unnecessary verbose, it uses HTTP as its transport mechanism (why?), XML as its format, does not handle state well, and no two language implementations are compatible out of the box. To me it just seams like more of the same. Developers familiar with technologies applying them in non-optimal fashions (SOAP uses HTTP!!!).

Thrift is interesting. Thrift is protocol natural they supply a few transmission protocols in the distribution. Thrift supports a whole heap of languages, versioning, and a API definition language that is meant to be read and written by actual human beings. It’s not perfect. It does some things I don’t like like code generation and it does not support stateful communication between client and server but these are details.

Systems should be built small and interpretable. Languages should be chosen on a task level not a project one. System should be built so small that if they need to be entirely ditched and written again this can be done with out it being a huge financial burden. If someone make the mistake of writing a subsystem that needs to be fast in Ruby, than that developer can learn from his mistake and it can be rewritten in something more suitable.

I have been writing a little 2D collision detection and “physics” (playful and fun physics not real) library. All collisions assume that one object/shape is stationary (infinite mass) and the other object is a circle with motion (ball). A ball bouncing around in space.

Not having done this sort of thing before and sort of intentionally staying ignorant of how others have done it I am unaware of how things are typically done. A ball bouncing off a corner of a square is an interesting problem. I decided that a ball bouncing off the corner of a square behaves a lot like a ball bouncing off a very small ball. So that is what I do. Check if the ball contacted one of the flat sides and simply invert the momentum of the ball and cut it in half (why not). If the ball hits a corner I create a little ball on the corner of that square and than impact the ball on to the ball. It looks great.

Math is not my forte. I have always taken the attitude I will do it if I have to (not a bad attitude for a programmer I will note). Circle on square collisions are easy as long as everything is square on the cartesian axes (the bottom left corner’s x value is the same as the bottom right’s). Adding rotation into the picture and the math quickly goes over my head. Not wanting to learn any more than I have to I come to the conclusion that moving the ball relative to the square’s center of rotation would be much easier. Convert the ball’s coordinates and momentum to polar with the center being the center of rotation of the shape it is colliding with, add to theta, convert to cartesian, do the collision detection, convert back to polar, take away from theta, and finally convert back to cartesian. It works super.

You might be thinking (if you are stil reading this) all that math it must be slow. I thought it would be and I am sure there are faster ways but rotating a glyph on screen takes way more CPU power than doing the collision detection. It seams plenty fast for me.

These things might be normal, wrong, or a new and brilliant way of doing things. At this point I don’t know but damn it sure is fun.

I love Objective-C in a number of ways; True polymorphism, message passing, named arguments, lots of runtime flexibility, and the power of C right at your fingertips when ever you need it (but you don’t have to). But I have one, albeit stylistic, objection.

The [super init] nil checking in the init method of subclasses. Why would you want to, as a general rule, return nil as your newly constructed object? Why would you ever want your application to continue on its happy way sending messages to a nil object, an object you explicitly asked to be created out of a very specific class. Yikes.

If your parent fails to initialize the entire world should come crashing down. It is likely to do is later anyway after you ask the nil object to do something useful (other than return nil). If something is that wrong I want to know about it right then, right there, in that init, not 6 steps later after I take that object and do something useful with it.

I fail to see any sort of systimatic use for this nil checking of super in the init method. I could see some very limited usage but if [super init] ever decides to return nil I am going to have a real &*^%& of a bug to fix.

I would also like to add some confusing and contradictory from the same page of the Apple supplied documentation …

Subclass implementations of this method should initialize and return the new object. If it can’t be initialized, they should release the object and return nil.

And in the next paragraph they state …

Every class must guarantee that the init method either returns a fully functional instance of the class or raises an exception.

WTF?!

Wow LONG Time.

2009-02-24

Over a year and I have not posted (not that anyone follows this anyway). It is time to fire up the blog one more time.