Touchy. . .

Ok, so I'm already sick of this whole Apple vs. Palm issue. . .

As many have said; the whole argument is ridiculous and provides elegant proof that the patent system in this country needs to either be overhauled or done away with. I am very aware that neither will happen, but I can still rant as though there's hope. . . right?

Apple's main beef is that Palm is "stealing" their "IP" by using multitouch gestures similar to the ones on the iPhone. We all know how this is going to end up, so why not skip all the chest pounding and ego tripping & jump to the end Apple: collaborate with major players in the industry to develop a standard set of gestures used to interact with any and all devices?

Reasons to punch Apple in the gonads:

1. Newsflash Apple: You didn't create the pinch or flick gestures. You also didn't create the ability for humans to touch something with more than one finger.
2. Newsflash Apple: Multitouch gestures are not what makes the iPhone great. Like all of your other products, there is no one things that makes the iPhone stand out - it's the way everything fits so perfectly together.

Reasons I saw this coming:

1. Though Apple has a very fashionable, approachable, and environmentally friendly image, they're in it for the money - just like everyone else. In very market except the mp3 space, Apple's either the little guy or the new kid on the block. They need every edge they can get - and they're willing to go to any length needed to sharpen those edges.
2. Though Apple plays very well in the open source space - and pushes standards adoption more than any other company I can think of - they're a big, mean bully when it comes to their bottom line. From what I've seen their attitude is pretty much: Join us or die.

All that being said: When Steve comes back I think things will change drastically. Since Steve's return twelve years ago Apple has embraced standards, open collaboration, and has worked very hard to be a good corporate citizen. I find it interesting that as soon as he takes a leave of absence Apple seems to do an about face.

Of course, Palm is a direct competitor to Apple now, and the Pre (Palm's new multitouch-enabled phone) is getting all kinds of positive attention. What's fascinating here is that this is really new ground for Apple: for the first time in their history they have a direct competitor who has a real shot at taking them down. As far as I can tell, Apple's always been off in it's own little corner of the tech world. Steve Jobs has worked very hard to characterize Apple as a company unto it's own.

The iPhone has succeeded so far because all it's competitors have sucked.

Now we're seeing how Apple reacts when pushed toe-to-toe with stiff competition. Something that's always puzzled me is how Apple maintains a reputation as a fast moving company - they're not. In fact, they move very slow and methodically - carefully planning each move, and not releasing a product until it's perfect. How long has it taken them to give us Cut, Copy, & Paste?

To stay relevant in the smartphone world Apple has to change the way they do things. They're in a market that's mature playing a game against many skilled opponents. Bullying won't work - turning out products that stand above the crowd in a timely fashion is the only way to win.

Welcome to the real world Apple - now you know how the rest of us feel.

In the end, Apple's patents will not stand up to scrutiny. What I'm curious to see is how far Apple will go fighting this war. They need to be really careful not to garner a reputation similar to M$. Apple has a lot of good will built up in consumers and with their business partners - but that can all vaporize faster than you can flick a photo. . .

Time flies. . .

Wow, it's been three weeks since my last post. It's also been quite a while since my last commit to any of my projects. It's been said before - and it bears repeating: life has a way of nudging you off track.

Unfortunately, responsibilities (mortgage, work, family, etc.) have taken all my time as of late and have left my code, blog, & wikis feeling woefully neglected. I'm hoping to be able to devote some more time to my hobby moving forward, but we'll see.

Currently I think my focus will be two fold:

1. Implement qualifying conditions in Caesar. Qualifying conditions are the vector/value pairs in a live query. I imagine their implementation will not be trivial.
2. Get paired up with a graphic designer and start working on an iPhone app for OS 3.0. This is tricky since I'll need to find a good graphic designer. . .

We'll see what the timetable for all of this looks like as I'm actively dating, working out, and trying to keep my house clean :-)

Caesar: growing up

I've been working on Caesar for a little bit now and can say two things:

1. Live Queries kick ass
2. Rails routing is very well designed (only one minor quibble so far)

First the Rails routing: it's easy to extend and very well thought out. I'm really surprised at how little work I've had to do to implement Live Query handling. What I've got so far is basically a second version of Rails' default route - with url helpers for all models.

:controller(:send_back)

That's the route used by all Live Queries. There is an optional :qualifiers parameter, but it defaults to 'id/:id'. You can pass a :path_prefix as you would with a normal Rails route (this is actually how Rome does it).

The really interesting part is all the extra stuff that happens when that route get created. . .

First, a whole slew of url helper methods get defined. Caesar (like web_home and Rome) is built around the CRUD pattern. The following default named routes are created:

• create POST :controller(:send_back) { :action => :create, :qualifiers => 'id/:id' }
• read GET :controller(:send_back) { :action => :read, :qualifiers => 'id/:id' }
• update PUT :controller(:send_back) { :action => :update, :qualifiers => 'id/:id' }
• delete DELETE :controller(:send_back) { :action => :delete, :qualifiers => 'id/:id' }

Just like all Rails named routes, all these get _url and _path methods created. I didn't want to stop there though. . . after all, the great thing about Rails is all that sugar they pour everywhere! To keep with convention, Caesar also creates helper methods for all four actions (create, read, update, and delete) for every model you have defined. These methods simply delegate to the generic helpers after populating the :controller and :action parameters.

The next step is to add a default value for :send_back. This means that if the :send_back parameter is not passed to the helpers, it'll default to returning all properties for the specified model. This means that you'll have three options when using Caesar's create url helpers:

1. create :controller => :photos, :send_back => ['thumbnail', 'name']
2. create_photos_url :send_back => ['thumbnail', 'name']
3. create_photos_url

And you'll have even more options for the read, update, and delete helpers since you could pass in either an :id or :qualifiers parameter. As a final layer of sweetness, I'm going to add both singular and plural versions of the url helpers. Some may call this overkill - and perhaps it is - but my thought is that it would at least provide a clear separation between single and batch invocations.

Caesar's coming along nicely. Once I get the sugar slathered on I plan on implementing the God Controller. With the way Live Queries work, I'm thinking I should be ale to have one Controller that handles all requests. . . I get chills thinking about how cool that would be :-)

Oh, yeah, my one quibble with Rails routing: NamedRouteCollection would be a LOT easier to subclass if it's private methods were protected. I plan on submitting a ticket for this and patching it. Other than that, Rails routing has been a lot of fun!

Caching. . . who knew?

So, I just figured out something that's been giving me a headache for a little while: one of the whiz-bang new features in Safari 4 is eager fetching. I'm not clear on the details yet, but it seems like Safari isn't waiting for you to tell it explicitly to hit a URL anymore - it's reading between the lines. Like I said, I don't understand the details yet, and I'm sure the solution will be simple.

The problem cropped up when testing Caesar. First of all, Safari 4 seems to take file extensions very seriously - but that's another post. I was testing a file upload widget I'd previously developed and noticed that even though I could create the photo and view it outside of my app, I was getting a broken image indicator instead of a thumbnail in my app.

I brought the issue up on the SproutCore Google group and was told the issue may be related to caching. Just to be sure, I uninstalled Safari 4 Beta and reinstalled Safari 4 Developer Release. Sure enough, everything worked fine in the older version of Safari (still version 4 though). This is nice as it means I didn't break anything while futzing with the code, and it means I need to learning about caching. . .

Ahhh. . . the wonders of technology's march forward!

I've got news on Caesar too, but that'll come in another post (probably very soon).

Caesar: the Live Query handler

Ok, so I've started implementing Live Queries in Rails. This means I've started work on a Rails plugin named Casear. Caesar has two goals:

1. Eliminate controllers
2. Eliminate routes.rb

What I've realized is that Live Queries are basically SQL using a URL. This means that a system built using Live Queries will basically be using Rails as a database. Eventually I'm sure we'll need things equivalent to Stored Procedures, Functions, and Triggers, but not yet.

I went through a few stages thinking about how to get rid of the controllers & routes.rb. I'm not exactly sure how it'll be done yet, but I'm thinking what'll end up happening is this:

• When the routes are drawn only four routes will be created for Live Queries one for each action: Create, Read, Update, & Delete. The only difference between the routes will be the HTTP verb. (:format will be an optional parameter to the base route and will not get it's own formatted_ method)
• During an http request Rails will do it's standard recognition stuff. (Except the controller/action will be created as needed)
• When a _url or _path method is called we'll have to do some magic. My thought now is that we check the requested model and see if it exists. If it does we create call the requested action on the appropriate controller (creating the controller/action if needed). My thought here is that people should be able to use either the singular or plural version of the model name is the _url or _path call (this may be a nice way to differentiate between single calls and batch invocations).

A couple notes:

• A controller will not be created until the first time a request is made against a model (via http or the _url/_path methods). In addition, the actions on the controller are not created until needed either.
• At some point I'd like to have a caching mechanism set up so that multiple requests of the same url will not actually hit the controller multiple times unless the data requested has changed.

It's looking to me like I'm going to need to dig into the Rails route recognition & generation code. I'm also gonna get a crash course in dynamic code generation!

Compact. Dynamic. CSS.

Yes, it's Valentine's day and I'm posting a blog entry. . . I do have plans later, but right now I'm a lonely SOB who has nothing better to do - so here we go!

There are two specs I'm working on: Dynamic CSS and Compact CSS. They are intended to be used together, but can also be used independently. I think they're really cool and will go a long way toward making better (read prettier) apps as well as cleaner JavaScript and CSS.

There are a few sticky points though:

1. File naming: There are essentially three possible configurations:
   • Straight Dynamic CSS (proposed extension: .dcss)
   • Straight Compact CSS (proposed extension: .ccss)
   • Combined Dynamic-Compact CSS (proposed extensions: .dccss)
2. Backward compatibility: This is essentially impossible as far as I know. The best we could do is create three new 'rel' attribute definitions for the link tag:
   • dynamic-stylesheet - For Dynamic CSS (possible shorthand: ds)
   • compact-stylesheet - For Compact CSS (possible shorthand: cs)
   • dynamic-compact-stylesheet - For Dynamic-Compact CSS (possible shorthand: dcs)
3. Evangelism: As great as I think these specs may be, what really matters is adoption - and that can't happen without evangelism. How do I get the word out - and more importantly how do I get buy in, and who do I get it from?

Point one really isn't a problem itself, it's more that I see how some people might view the introduction of three new file extensions as annoying/overkill. This kind of ties into the third point: I don't think three new file types will be a big deal if people understand the benefits of these specs and see how they'll help create cleaner code.

Point two kind of links points one and three. The idea is that the new 'rel' attributes would allow browsers that don't support Compact or Dynamic CSS to simply ignore the files altogether. This means, though, that there will essentially need to be at least two (possibly four) versions of every style definition:

1. Old school CSS
2. Compact CSS
3. Dynamic CSS
4. Compact and Dynamic CSS

Maybe part of the spec could say that to use Dynamic CSS the client must first implement Compact CSS. I think I like that idea. . . That does create a dependancy relationship though. . . Hmmm. . . Another solution would be to maintain the dependancy-free relationship between Compact and Dynamic CSS and develop a tool that "compiles" any CSS format required. DCSs (Dynamic-Compact-Stylesheets) could be coded and then other formats could be generated when needed. This could be code at request time on the server, or statically when the stylesheet is coded.

The biggest and most challenging issue by far is point three: Not only do I need to get the word out, but I also need to get buy in from a major browser (probably webkit) to actually work on implementing these specs.

First, though, I guess I need to actually finish and polish the specs eh?

Long term vision

Ok, so web_home's cool and all. . . but every open source project is cool at first - what about two years from now?

I would say there are three very distinct stages of vision I have for web_home and it's cousin projects:

1. The current level: web_home, rome, etc exist as completely separate projects
2. The SEGA (next) level: bundles are created by pairing web_home with it's server side companions
3. The Jennifer Connelly level: Not sure exactly how this'll be implemented yet, but the idea is that the js and css needed by web_home will be super customized by browser

The current level

This is the development that's happening now: web_home and rome are being developed separately. Sure they work together, but the also work just fine on their own (sort of, web_home doesn't use fixtures so it does require live data from a server). Once the architecture for web_home is pretty well ironed out my plan is to implement "degraded" versions of all web_home modules in Rome. This means that web_home would have a photo_album module and Rome would have a photo_album module. The goal is that both module look and feel as similar as possible to an end user. The difference would be that the Rome photo_album module would be sans JavaScript.

At this level both full and "light" (mobile) versions of modules would be developed. Also, in addition to Rome (the Rails implementation) I'd like to develop web_home server companions in PHP (phome) and Python (slick name forthcoming).

The SEGA level

I'm thinking this would basically just be wrapping web_home and a server companion into a command line application. The idea is that you could then create an entire web application by entering a command similar to:

nx-01 create="Enterprise" -bp

This would tell the nx-01 application (Gratuitous Star Trek reference) to create a new application named "Enterprise" (another gratuitous Star Trek reference) with the Blog and Photo Album modules. The output from this command would be a ready to run Rails app with web_home all set up and ready to go - you could cd into Enterprise, run ./script/server, and blog away!

The Jennifer Connelly Level

This super sexy level is where things really start getting crazy. My idea here is that instead of web_home being a static set of resources, web_home modules are built browser specific on request. This means that all object testing code in the JavaScript goes away because web_home knows what browser it's on and what that browser's capabilities are.

Some sort of templating language will probably need to be developed which will then "compile" down to browser specific JavaScript. The same thing will be done for CSS, but that won't require any magic, we will simply set up conventions telling web_home which CSS files to use for what browser.

An important note is that once compiled, JavaScript resources will be cached. This means that browser specific module configuration will be done at most once for a browser.

Sexy specs

I now have seven - that's right 7 - specs on web_home's GitHub wiki. I'm wondering if maybe I'm getting carried away. . .

I've realized that my real strength lies in making things better, not really creating from scratch. There's only one spec I'm working on that's "new". All the others simply build on specs already being used. The new spec (.synchronized) is really just a special purpose file format too - so it's not really that big a deal.

I think Live, Atomic, and Stable Queries will do a really nice job bridging the gap between REST and SOAP for Web Services - especially when combined with Response Constraints. Dynamic and Compact CSS will also make for much cleaner JavaScript and CSS files, respectively.

Now all I gotta do is work on hammering everything out!

Oh yeah. . . actually using these specs might be good to do sometime soon too :-)

Initial Commit

Ok, so what's this blog all about? Well it's basically a dumping ground and a place for me to have conversations with myself. It may be beneficial to you if you're interested to see what goes on inside the head of a mad scientist. . . or if you'd like some insight into the web_home project and it's sundry cousins.

I doubt many of the posts will be that long - or well written. Read at your own risk.