Change is coming to how we get the radio we listen too. Radio listeners will go from having 10 choices on their radios to thousands. Good times, good times.

Thursday, January 19, 2006

Ubuntu and servers

I love Ubuntu. I really do. I've been using it for about 9 months now, both at home and work. It is flexible and easy to upgrade. Recently, I was spouting off about how great Ubuntu is, and someone asked my why then I wouldn't use it in a server environment. My response?

Mostly the right tool for the job argument. Ubuntu is designed to be a workstation distro. Ease of use often goes hand-in-hand with lax security measures. RedHat is a good choice for home rolled production servers. Debian and Slack if you have a bit more experience. (Debian is pretty darn easy, especially coming from Ubuntu)

The best reason I know of, is when you run into problems on your server, you want active forums of experts who can help you. RH, Debian, and Slackware all have admins with gobs of experience who will help you. The Ubuntu server crowd is not going to be as robust.

Now, all of that being said, I do all of my development (rails included) on a VMWare virtual machine. Most of them are running Ubuntu in server mode. The reason I do this is because it is dead simple to set up, and file structure is exactly the same as my base machine. It makes things easier.

Bottom line, you can certainly use Ubuntu for a production server, but you'll be mostly on your own fighting an uphill battle to get the machine secure. You can do it, but it will take research.

Last word, I've only ever had one machine compromised, and it was a Fedora box. So take all the nice things I said about RedHat with that grain of salt.

Agile schema

I like to start with a database layout when building up a new site, but I go for the minimalist approach. Trying to flush out every table, and every column is right back to the waterfall model of software development. Agile development demands that you do only what is necessary to make the current test pass. If that means having a cusomer table with just an "id" and "name" field, so be it. With TDD its easy to flush out the db design as work progresses. There will be time to add address, phone, and bra size for a customer later. Its even easy to shut down a model and move its pieces around. Its true that changes like this tend to have concequences far and wide, but with tests in place, its easy to know what code needs to be massaged.

The idea is to hold off making structure decisions until the last possible minute. Once a data schema is set, it can get inflexible, even with good tests in place. I want to always leave the maximum amount of flexibility until I have no choice.

Example - does the "first name", "last name" fields go in the customer table, or the credit card table, or both? I've built apps all three ways, and untill you've gotten a lot of use cases, flushed out those cases, and even rewritten them with the user, it can be difficult to know which one is proper.

validator mixins

There was a proposal on the Rails mailing list this morning about divorcing the validation code from ActiveRecord, and making it its own mixin.

------------------------------------------------------------

It seems to me that Validations are quite useful for many objects, even
ones having nothing to do with ActiveRecord.

Common examples are Contact Us forms, multi-step forms, web service
paramater validations, etc.

I took a look at the source for Validations, and it seems that it is
very independent from ActiveRecord. I caught only three depenedencies:

1. validates_numericy --> depends on ActiveRecords' before_type_case
2. The exceptions were from the ActiveRecord namespace
3. Including Validations hooked on methods like save

It would seem to me that Validations would be best off as an independent
mixin. All ActiveRecord would need to do is mix it, add
validates_numericay (1), catch the exceptions and rethrow them as
ActiveRecord exceptions (2), and hook save type methods (3).

What does everyone say? Would this be a good change? Is there an
important reason for *not* doing this?


------------------------------------------------------------

I've been developing a data storage system based on Ferrett that clones the ActiveRecord interface, and having the ability to mixin validation instead of rolling my own makes my brow twitch like Elvis. "Better than a penut butter, bannana sandwich baby"

I've been calling my search based data storage IndexRecord, and the goal for its interface is simple. Have models subclass IndexRecord instead of ActiveRecord, and have them be interchangable. Currently, a model could be used like this. Imagine the power of mixing in validators.

class Page < IndexedRecord
#setting up searchable fields in Page documents
fields :page_number, :text
end

Then you can do stuff like this -

page = Page.new
page.page_number = 23
page.text = "One flew over the cookoo's nest."
page.save

pages = Page.search("text:cookoo") #gives back a hash of unique control_id and summary

Now, imagine with validators mixed in, this model would be one step closer to AcriveRecord functionality.

The end of one thing...

I resigned today from my old post today. That has to be one of the hardest things there is to do in business. Or, I suppose some people are dying to do it because they are unhappy, or whatever. I am not one of those people. In fact, I do not understand how someone can go, day after day, to a job that they do not like. Along with my family, my job fills out my life. Just like raising my boy, it gives me purpose.

That is why leaving is so difficult. I feel like I'm leaving a cause I have poured blood and sweat into. Everyone at my old job is hardworking and dedicated. I do not know if they will eventually be successful, but I do hope that is the case. Good people.

...Is the beginning of another.

So, every ending is followed by a new beginning, and that is what I am looking forward to with Mingle.com. I start officially on the 27th, but have been working on a project for several weeks as a contractor. We are using Rails for web development, and that has been new as well. After a bump in the learning curve, I've began to pick up what I need really quickly. The grammer of Ruby is intuitive, and elegant, making it easy to pick up new knowledge from code examples. The community on the mailing list, blogs, and forums is a real assett for the language as well. If you're trying to learn Rails, get on the list.

Speaking of learning Rails, I can only luke warmly recommend the new Agile book. While I have it, and reference it a lot, it leaves a lot for the 2nd edition. Most importantly, test driven development gets about 3 paragraphs in it. One of the things about Rails that is so attractive is how dead simple unit testing is. TDD was cumbersom at best for web design before Rails. With Rails, TDD is the only way to go, it is the strongest argument for using Rails in an Enterprise size project. The book has it as little more than a footnote.

Worse, when the book does get around to Unit Testing, they completly miss the boat on how to do it. Unit tests are NOT written after the code is in place. Even calling it "Testing" is a misnomer. Testing is for before and during development. Normal work flow goes like this - Test, code, test , refactor. Having the tests lying around is just a bonus ( a big one though! ) They allow you to refactor with confidence that your changes are isolated.

I see a maket for a book that dives into Rails with a TDD model.