Living in code

Geekswithblogs.net

2009-03-04T03:55:00.001-08:00

this blog is pretty much dead. I started a new blog over at geekswithblogs. Check it out! I will probably reproduce some of this content over onto that blog at some point, but i'm doing a decent job of keeping it updated so far :)

nilsimsa

2007-10-09T17:53:00.000-07:00

http://ixazon.dynip.com/~cmeclax/nilsimsa.html

Check this out. I was pointed towards this the other day by a colleague of mine. A nilsimsa code is very similar to a hash with one key difference. The key attribute of a nilsimsa code is that when a small change occurs in the source data, only a small change occurs in the nilsimsa. This is the opposite of what you'd expect in a good hash function.

How is this useful? Well take anti-spam for instance. Two peices of text that are mostly the same but contain a few minor differences can be detected as being from the same origin with nilsimsa codes. This way you could have a single code for an email that could detect a whole slew of auto-munged versions of the same mail.

Challenge to the reader... How else could you use nilsimsa codes? I can think of some cool applications...

This past week

2007-10-07T10:03:00.000-07:00

I spent the past week out of town at an internal developer's conference for work. I can't tell you how awesome it is to meet people who are passionate about what they do. I got to meet the best and brightest at the company. I took it as a tremendous learning opportunity, a chance to network, and also as a challenge to see how far I myself can take myself and just how good I can become.

Some people write code for a living, but most of the people I met this week would be writing code even if they weren't getting paid for it. Great stuff.

Back on Track!

2007-09-22T07:45:00.001-07:00

My work @ Symantec is going really well and is incredibly gratifying, but i'm really excited because i'm working on some extra-curricular projects using Ruby on Rails again. My last web development project was a PHP-based mess that I inherited from non-coders who had hacked together a social networking site. The job was fun, but mostly because of the people, not the technology. Building site with Rails is almost too easy and on top of it all, its really fun! I love coding Ruby because it is the only language that I actually guess at syntax and usually end up being right. Ruby is that intuitive. Ok, enough gushing. Here is a list of Rails plugins i'm using in this new project that i love

SimpleCaptcha - A really simple, easy to integrate CAPTCHA plugin for Rails
acts_as_taggable on Steroids - make any object taggable
acts_as_commentable - make any object commentable
acts_as_authenticated - secure authentication on rails
acts_as_attachment - file uploads for rails

Coming up for air!!!

2007-08-21T18:35:00.001-07:00

Symantec sure is keeping me busy! coming up for air soon w/ some new content!

Python Challenge

2006-04-25T14:24:00.000-07:00

I recently had the opportunity to learn Python as part of a very short term consulting job I took on. Having also taken on Ruby recently this was an interesting task and I could spend a whole blog comparing the two (spoiler: I prefer Ruby); but I won't.

What I want to blog about here is way cooler. While I was looking up some python syntax I happened upon the Python Challenge. How cool is this! The python challenge is a game where each level can be solved using a clever or little known bit of Python code. I decided to take the challenge as a way to hone my newfound python skills. This is a great way to learn a language and to learn the nuances of a language. Of course, with my newborn Ruby (and Rails) passion I think we need a Ruby Challenge! Does one already exist? I think the python challenge format could pretty much be used but I would suggest one small change:

Use the challenge as a tutorial. Hear me out.

The ruby challenge starts with the most simple ruby concepts. Perhaps a sidebar or section at the top that always displays the ruby keywords, general syntax rules, etc. Each challenge gets harder. Eventually they reach a level where they are more puzzle than tutorial and at this point you start to learn the elegances of Ruby. Problems are formed to be solved by Ruby's unique features. So you learn Ruby, you learn more Ruby, and then you master Ruby all as part of a game. Furthermore it would be great to keep track of users and how well they are doing in the challenge so you can have a top 10 board or something. Millions of thoughts here. Feedback?

Nearly every language could use an involved, engaging tutorial/game like this. This is worthwhile Edutainment. I would love to work on this as a part time project. If you're interested in helping me out or you know of something like this that already exists. adaDONTSMAMMEPLEASEm.schepis@gmail.com or post a comment with contact info. If you care about privacy you can find a link to my GPG public key at the bottom of this page.

Rails won't become mainstream?

2006-04-07T03:10:00.000-07:00

I was surfing digg this morning and came across this blog entry by entitled "Why Ruby on Rails won't become mainstream." In it the author (Cedric) points out alot of the _potential_ barriers to Ruby (and Rails) becoming mainstream. Hold Up!! Before you let your indignation get the best and take off to rip him a new one please take note of you take this one little peice of information. He's a Rails lover! Cedric make's alot of good/valid points but I don't agree with his conclusion and as a VERY recent Ruby on Rails convert perhaps I can contribute a different perspective. My comments below to his list of reasons

1) Cedric says that one barrier is Ruby itself and getting it into the toolbox of the PHP/ASP crowd. Ruby _DOES_ have some advanced idioms. I'm still learning Ruby, but I can tell you from experience that I was able to take the Agile Web Development with Rails book and read it, go through the examples and when I was done doing so I was comfortable using Ruby. I hit the API and language references alot and I'm planning on getting the Pickaxe book but once you start to "get" Ruby (which for me was almost immediately) it is straightforward to use

2) Cedric thinks that Rails itself will hinder mainstream adoption because it is complex, does alot for you automagically, and is incredibly clever. He isn't sure that the Web Development community (which, let's remind ourselves, isn't made up entirely of quality, trained software engineers) will ever be ready to embrace the cleverness and magic. I'm not sure how I feel about this one yet except to say that I think Rails gives developers a better chance of building a product well within a reasonable schedule. There are fewer pitfalls than starting from scratch w/ PHP or using other frameworks and languages. Perhaps if we lead by example, they will follow.

3) The author claims that Rails Still has no credible IDE. This is the one point where Cedric is just plain wrong. RadRails is an AWESOME Rails plugin for Eclipse!

4) Next, fanatacism. Cedric thinks that the extreme fanatacism of some in the Rails community will hinder Rails. Now I have to agree here to a certain extent. We need to stop BASHING people who discount Rails and simply prove them wrong. Actions speak louder than words! Build some killing enterprise Rails apps. Don't insult James McGovern, disprove him. The other danger with the ultra-fanatacism that I've pointed out before is that some people look at Rails as a hammer and everything that can possibly show up in a browser window a nail! This is dangerous! Read my "no silver bullets" post to get my opinion on this.

5) The author's next point is that by being so great so soon Rails will stifle innovation in the area of Ruby web frameworks and that because Rails is the only game in town Rails itself will be stifled. This NEVER crossed my mind and I think the reason for that is because I lump ALL web development frameworks into the same bucket regardless of language. I think others tend to do this as well. Although it's important to distinguish which languages and frameworks are good for particular types of problems I believe that if somebody does something REALLY cool in one language/framework it tends to make its way into others. Case in point Grails, Trails, CakePHP, and many more. Rails has single handedly reinvigorated the web development platform and infused it with a fresh perspective! In the future Rails may benefit from the same effect caused by another framework

6) Next Cedric points out that Rails' Enterprise capabilities and scalability unclear. This is a common concern and one that needs to be put to rest. The Rails community needs to nail down the sweetspot of Rails once and for all in a mathematical way. Can a Rails app handle the type of traffic that slashdot and digg see everyday? If we built a peopleSoft type HR app for a company intranet with Rails could it scale when there are thousands of users worldwide constantly coming in and out and the server is seeing hundreds of transactions per second? I have no idea. Let's find out where Rails breaking point is (if there is one... I have no clue.)

7) Cedric's final point is Lack of support from Internet Providers. On this one I'm sort of in the "If you build it, they will come" mentality. Has PHP always enjoyed mainstream Internet Provider support? Maybe in the short term we're going to have to host our own servers or get dedicated servers but there is already a slew of providers with support for rails hosting.

Wow, a long retort! In closing I guess I should thank Cedric for starting this conversation from the perspective of a Rails supporter! The debate that will follow will surely be beneficial for the community.

Killer code snippet!

2006-04-05T06:53:00.000-07:00

This is straight out of Agile Web Development with Rails:

class Customer <>
has_many :orders
has_one :most_recent_order,
:class_name => 'Order',
:order => 'created_at DESC'
end

God damn this is beautiful! And powerful! The point is that the equivalent of this in other popular scripting languages used for building web apps includes you typing something like (pardon my horrendous psuedo code):

query = 'SELECT o.* FROM orders as o, customers as c WHERE o.customer_id = c.id ORDER BY created_at DESC LIMIT 1'

result = execute_query()
row = get_row(result)
// do something with the data.

Whether you do it in your php code, or a stored procedure you're still typing a messy SQL statement for something that should be simple. In Rails (or Ruby using ActiveRecord) you can simply do this:

customer = Customer.find(17) # get customer by id
puts "your last order was for #{number_to_currency(customer.most_recent_order)}"

And best of all, ZERO config. The ability to infer objects based on the schema of the underlying database is powerful. To then be able to define relationships that transcend that schema and fall into the realm of business logic (such as "your last order" and "orders pending shipment") at the model level is incredibly powerful particularly considering the amount of code you have to write. This is a great example of Rails allowing you to assist you in solving your problems as opposed to other frameworks that get in your way.

There is no silver bullet...

2006-03-31T10:50:00.000-08:00

If you care about software engineering as a practice, and you care about being a g{ood,reat} software engineer then you have probably read Fred Brooks' seminal article on solving the essence of software engineering problems. This article was written in 1987 and as I was reading it over again this afternoon it was as fresh to me as when I read it in college (thanks Professor Werner) in 2001, and still as fresh as it must have been in 1987. To put this into perspective, in 1987 I was 6 years old and Microsoft released Windows 2.0.

That being said, the reason I was re-reading this article is because the other night I finally got a chance to spend some real time with Ruby on Rails. I, as most people I have talked to, was blown away when I "got it." Rails makes writing database backed web applications simple, straightforward, and alot of fun. I hope it stays this way. In my opinion the worst thing that could happen to Rails is for people to start looking at it as a hammer and every project they get put on a nail because, as Fred Brooks has pointed out, there is no silver bullet and there isn't likely to be one anytime soon.

Rails can't/won't slay the Werewolf that is software projects but it is pretty adept at slaying one particular kind of beast. Rails is not the "silver bullet" but for database backed web applications (with AJAX, I might add) it is golden. Writing software is more like taking on every mythical beast known to man than it is like slaying a werewolf. So we could say that DB backed web apps are vampires, and Rails is the wooden stake that we can drive into its heart. I think that's a fitting analogy for Rails because it does go straight to the heart of the problem you're trying to solve. It's a little peice of our software engineering arsenal to be used in specific situations. Kind of like how nearly every boss monster in nearly every single video game I played growing up, and I played quite a few, had a particular weakness that I could exploit to achieve victory.

As software engineers the sooner we stop looking at all software engineering projects the same way the better off we'll be. I'm not the first one to say these things. We have to be actively on the lookout for more wooden stakes. More weapons for our arsenal. As creators we need to identify the applications we build time and time again and create frameworks like Rails to help us slay those beasts because if you've used Rails you know that when your project falls into the Rails sweet spot you've got a good opportunity to knock it out of the park EVERY SINGLE TIME. The reason for this is that the less code we write, the more time we can spend on solving the essence of software systems as pointed out by Fred Brooks. Now to quote from the article a bit

complexity - Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine--open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
conformity - Software people are not alone in facing complexity. Physics deals with terribly complex objects even at the "fundamental" particle level. The physicist labors on, however, in a firm faith that there are unifying principles to be found, whether in quarks or in unifiedfield theories. Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.
changeability - The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture; they are superseded by later models, or essential changes are incorporated into later-serial-number copies of the same basic design. Call-backs of automobiles are really quite infrequent; field changes of computers somewhat less so. Both are much less frequent than modifications to fielded software.
and invisibility - Software is invisible and unvisualizable. Geometric abstractions are powerful tools. The floor plan of a building helps both architect and client evaluate spaces, traffic flows, views. Contradictions and omissions become obvious. Scale drawings of mechanical parts and stick-figure models of molecules, although abstractions, serve the same purpose. A geometric reality is captured in a geometric abstraction. The reality of software is not inherently embedded in space. Hence, it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics.

There you have it, straight from the horse's mouth. To get back to how Rails fits into this lets look at what it does for the above issues:

complexity - Rails dramatically reduces the complexity of database driven web applications
conformity - Rails' notion of convention over configuration gives us guidance and a model to conform to.
changeability - ActiveRecord's ability to introspect database tables and automagically update models when the underlying database schema changes reduces the impact of software change.
invisibility - Not so sure Rails helps here, feel free to chime in and tell me how I'm wrong.

3 out of 4 ain't bad!

What is the single most important thing that we can take with us from Rails when we have to do something other than database driven web applications? Find more weapons! Build your arsenal!! As Dave Thomas of the Pragmatic Programmers has pointed out in his talks and books "Build your knowledge portfolio." And as you do, be on the lookout for wooden stakes, clubs (to smash zombies heads w/), silver bullets (for when we DO run into werewolves), water (for the wicked witches), and whatever other mythical weapons you can find for solving the task at hand.