Wednesday, June 4, 2008

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.

Monday, March 17, 2008

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.

Friday, February 22, 2008

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. 

Tuesday, February 5, 2008

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?

Saturday, January 26, 2008

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.

Wednesday, January 23, 2008

Is TDD useful?

I have heard a lot about testing lately. First I was told you need tests. I don't disagree with that at all. Companies wouldn't devote entire departments to testing if doing it was trivial or useless. Automated testing is ideal since you don't have to hire an entire department for this task but this can be difficult and hints at the heart of this post.

Then I was told that behavior driven development (BDD) was important. That you would create automated test cases that try to stress the way certain behaviors of the system should act. This has always seemed very nebulous to me and so close to test driven development that there really isn't a big difference between the two.

Which gets me to test driven development, TDD. The whole idea about this is that the developer really thinks about the method/function/module he/she need and writes tests first that express what that method should do. Supposedly this creates stronger and more robust code. Some developers have really hammered this thought into the agile development world about how testing first WILL create better code and more productive programmers.

Then I read this article. Basically, it says that testing does help but the number seem to show that testing a method after it is written actually creates better code. It says that tests are still really useful but writing tests first don't actually create better code and may actually be worse than testing methods after the fact.

What does this say to you about my development practices? Well, I will continue to write automated tests but the jury is still out on TDD. And, personally, I don't see any compelling reason to change my, or my teams, current development practices based off of some shaky numbers. Especially if it's true that testing after a method is written is better. Change isn't always for the better.

Monday, January 21, 2008

Merb, this isn't your dad's framework!

I found a pretty cool ORM for ruby a little while ago call datamapper. It looks pretty good and I would love to try it. Unfortunately, if you are using Rails it's pretty hard to use something besides ActiveRecord. In fact, Rail's is pretty tightly coupled and it's pretty hard to use anything but the default gems.

This led me to a framework called Merb. I pointed one of my friends in the direction of Merb and he also blogged about it. Merb is basically a MVC framework for ruby developers that prefers to use gems to add functionality then one monolithic framework. For example, you are allowed to use any of several ORMs for your project. Or templating engines. Merb is also smaller and faster than Rails. That alone is reason enough for me to check it out.

But, there are some downsides. Merb is still very young. It's not even at a 1.0 stage yet. But this post does give me some hope. Also, there isn't a lot of documentation on it yet. Still, there seems to be a lot of promise there.

Personally, I would love to try a combination of Merb, datamapper and DRYML. It would be great to throw DRYML at a good web developer and let them go to town while your ruby developers focus on creating a tight backend with datamapper. There is still an issue with routes but I'll blog about that later.

Sunday, January 20, 2008

Rails custom formbuilder

Is there no better way to create custom tags than with your own formbuilder? So far, I'm not impressed. I've read through a couple examples and neither one has really satisfied my needs.
http://www.aldenta.com/2006/09/19/writing-a-custom-formbuilder-in-rails/
http://www.railsonwave.com/railsonwave/2007/5/2/create-a-color-picker-helper-with-formbuilder

The first one is fine if you create your own namespace so that all your form_for, fields_for work correctly. I really don't want to start tacking a bunch of names on to my form_for, fields_for. It just leaves a bad taste in my mouth.

What about the second example? You create a class and then use :builder => MyFormBuilder. Well, then you have to start creating the same methods for fields_for and for all the ajax methods. This isn't isn't DRY.

I'm probably missing something obvious here but my real argument is that I have to much around with rails at all to create my own custom tags. Why do I have to jump through a bunch of hoops to create my own special tags to be used in my forms? Why is Rails tying y hands rather than making it easier for me like the framework should?

I really only bring this up because I've used some of Hobo's features. It builds on top of Rails and adds some pretty great stuff. My favorite is DRYML. Basically, DRYML lets you define your own tags to be used as you need. You can override what is already there and create new tags based off of tags that already exist.

One of the best things is that the code that you write looks like HTML. Actually, it is a bit like XML but I forgive the devs. This is good because I can create a library of custom tags and then hand it off to our HTML developer to code to his hart's content. If, at some point, he comes up with some new HTML/JavaScript tag, then that can be added to the library and used pretty quickly.

If you are interested in creating web pages quickly I suggest you take a look at Hobo. It has some blemishes (bad documentation, a lot of coupling, still a new project) but I think that it has a lot of promise. The developers are working hard to fix some of the current problems one of them being the coupling. I'm seriously considering moving over to DRYML when they finally make a gem/plugin out of it.