Starting up again

It's been a while (2 years) since I last posted something. Recently I talked to some professors about going back to get my Ph.D. One of the qualities they said I should have was a love of writing. This blog will be my test.

Something that I found very interesting recently is Capsicum. It's a pretty interesting way of supplying capabilities to programs. It's very interesting. Basically it checks whether or not you have read/write access on unix file descriptors. FreeBSD 9 will include this and hopefully migrate over to using it in the future for all it's programs. There is already a chrome port running on FreeBSD.

It would be great to see the iPhone get this functionality in the future. Hacking through font rendering would be a thing of the past. If you get a chance, read their paper.

That was quick

I was going to blog about helping out making a couchdb store for extjs but my friend Shawn Garbett beat me to it. You can check out the code, with examples, here. Check it out.

It's been a while.

Like the title says, it's been a while. Some things have gone down at work that have kept me busy and I've neglected my blog. So, let me try and give some love to it. Here are some tidbits of what I've been playing around with.

First, Merb looks better and better every day. I highly suggest you take a look at it if you are interested in web frameworks. Also, datamapper just came out with 0.9 release. It's a pretty cool ORM and works well with Merb. Again, check it out. You can find both on github.

Lately, though, I've been really impressed by a project called couchdb. It's a totally different way of thinking about databases. I've been working with a friend to make an ExtJS datastore that ties into a couchdb record. I should be able to post some code soon and give more info then. Until then, you've got some reading to do.

It's been a while.

So, like the title suggests, I haven't blogged any in a while. I've been working pretty hard on some stuff at work. Most of it has to do with Ext js so not much has changed from my last post in that area. On the other hand, I've been dancing a whole lot more.

I just got back from lindyfest and it was very fun but it wore me out. I really need to work on my turns and spins. I think the way for me to reach the next level of swing dancing is to move myself more to emphasize what my follow does. There were some excellent teachers out there and I highly recommend taking classes from Ramona Staffeld and Peter Strom if you ever get the chance. Ramona is incredibly graceful and smooth and Peter is hilarious. They are both very good teachers.

Ext, an awesome JS toolkit

This post is for people making a fat web client. If you are going to be doing something small and a little more sane, then this post isn't for you. Turn around now. If you've considered creating a web app with flash, keep reading.

Ext is a toolkit for creating a web gui with javascript. It's for creating something like yahoo's new mail app. You create accordion panels, forms, fields, everything from javascript. You can use markup, but that will actually make more work for you. It's best just to let the library work it's magic and accept what it's got.

And, man, does it have a lot. It's got client side validations, data readers (more about them in a second), grid controls with built in searching and column sorting. Really, if you've thought about making an actual web application then I highly suggest you look at Ext.

Data readers are where it's at in Ext. Say you prototype out a simple contacts search. You might have a form where you can search by their first name, last name, or zip code. You send up your search query and get back a chunk of code that has the matching contact information. Prototyping that can be difficult if you are using static HTML but if you and Ext DataReader you can put in test data that your form will be populated with once the search is completed. This DataReader object will accept data in several formats including XML and JSON.

It gets better. The DataReader object can also take a url. So it is possible to prototype out your view and test it with the exact object and type of data it would normally use. Then, when you have your controller serving up the data in the format you need, you point your DataReader to the correct url and you're done.

This is great when you want a clear separation from your models and your views. This is exactly what I blogged about earlier. This lets your front end developers not have to worry about the back end and let's your programers do what they are good at: coding. 

A Great Smurfing Idea

Just to show that this blog isn't all about doom and gloom, here is a much lighter post.

Sitting around with some work friends we started talking about compilers and writing a language. We somehow stumbled upon creating a computer language based off of the smurfs. Hear me out:

Threading would be built in by default. You application would be the Smurf_Village and each thread pool would a Smurf_Mushroom. This seems to lend itself to a message passing system between Smurf_Mushrooms. So each Smurf_Mushroom, and perhaps Smurf_Village, could talk to one another by Smurf_Letter.

The language would be object oriented. Every object would inherit from the root object, Papa_Smurf. New objects would be named based on what they do. So you could have Jokey_Smurf, Brainy_Smurf, Miner_Smurf, etc. So what/who would create all these other Smurfs? Why, Smurfette of course. She would be in charge of creating new Smurfs and putting them in their Smurf_Mushroom.

At some point you need to join your threads and get a result. Azrael would wrangle up all the Smurfs to supply the answer. At some point your Smurfs will need to die and the memory re-allocated. Gargamel would be the Smurf garbage collector.

What do you guys think? What's missing from this Smurf language?

Templating for html developers

There was a presentation at railsconf in 2007 by Bruce Williams where he speaker talked about DRYing up your views. Now, I wasn't personally there but I've read an overview of the talk and I realized something. There were several template systems he compared but there was only one, maybe two, that someone who know html/css could use. That was DRYML and, maybe, Haml.

That right there is the fundamental problem with all of the templating systems, and even the presentation. They were all aimed at ruby developers. Now, if you are doing a small project, this is good. The team probably won't have many people on it and all of them are probably ruby developers. And you want your ruby devs to program in ruby. That's what they know. But this argument falls apart when you work on a large project with actual interface developers.

Working on a large project with many rails developers and a couple of html developers will cripple your development time if you have to use ruby for templating. It means that when your interface devs create a moderately complex site, one or two of your ruby devs have to translate it to whatever templating system you're using and get all the glue between your controllers and views. If your system is very complex, using a lot of javascript and css, then the problem gets worse.

This is why I'm interested in DRYML. I want a template that I can give to someone who knows html/css and be able to write in it. Then, every so often, have one of the rails developers put in the glue between the controller and view to have it working.