Aug 012008
 

I went to the 37 Signals event last night sponsored by CPB. The speaker was Jason Fried, who is a founder of the company, a designer and all around smart guy.

Jason spoke mainly about small business. He presented a list of things that companies can do to become more productive and better at whatever they do. His list included things such as:

  • 4 day work weeks
  • Virtual companies
  • Saying no to your customers more often than not
  • Do the easiest thing possible
  • Don’t design, just do
  • Don’t go to meetings
  • Turn off email and IM

A number of these things I do each day including turning off email and IM when I’m really cranking, be as virtual as possible, reduce lengthy design and just start working. Overall, Jason has great ideas for small companies. 37 Signals is probably in the 3-5 million dollar range or lower, with about 2-3 million dollars of overhead or more. They are a life-style company and will not grow beyond a certain threshold because of these ideals.

Having worked for a large company, worked on vastly more complex systems than Jason, created many open source frameworks and now starting my own company, I found Jason’s ideas exciting and total crap at the same time. I regularly find myself battling with creating solutions that will scale, versus creating the simplest solution. This naturally occurs to anyone who has ever worked with applications that do hundreds of millions of transactions per day (or per hour).

I pushed Jason a bit to see where he would break ranks with some of his ideals. From his responses, he absolutely would not abandon these ideals at any cost. However, I think this is a marketing tool created by 37 signals to promote their products as well as Ruby on Rails. The reason I know this to be true, is that Jason is intelligent and capable or understanding moderately complex problems with more ease than say a college student. In addition, he spoke briefly about how a single feature request such as adding time-stamps to ToDo list items can have a larger impact than any customer might think. These features requests require a large amount of thought and planning because they impact the entire system. Similarly, changes to the Rails internals require a large amount of thought and testing to ensure they don’t break existing applications.

This dichotomy is something that is a fact of life. It is something engineers, product managers and executives must deal with, no matter how small or large your company is. 37 Signals has built a reputation that they can safely ignore these problems and be wildly successful. However, it is 95% smoke and mirrors. The reality is that 37 Signals is composed completely of phenomenal employees who can work in complex domains without losing their minds. The can distill complexity into manageable pieces and then combine those pieces in the end to produce a complex yet functional system.

Mar 072008
 

With Grails, Rails, Python, etc offering developers the chance to change code, hit refresh and see the changes I often wonder if reload truly a feature that is a must have these days? It seems like it is one of the main selling point by most of the folks pushing those frameworks.

I think this is not a requirement, and doesn’t really increase productivity. Here’s why:

  • This promotes less tested code as you can code an entire app without testing at all by simply hitting refresh
  • The testing cycle is lengthy by nature, so you do any testing during development, it is going to take some time
  • Rather than using reload, if you use the development cycle of write, test, run or test, write, run, than starting up the application incurs minimal overhead in addition to running the tests
  • So, what are we really trying to accomplish while developing? Better code, less code, better tests, faster development. These things seem to imply great conventions and excellent extensibility and not reloading.

Feb 142007
 

Came across an interesting situation where my Rails application was going to be receiving URLs with characters like (dash) and . (period or dot). Something like this:

Ruby doesn’t allow dashes or periods in identifiers, so this was going to cause a problem with method naming. I couldn’t figure out how to handle this from the web and so I dove into the source and found that when the action method doesn’t exist Rails calls a catch all method called perform_action. Adding my logic to this method worked well. Looks something like this:

[tags]rails urls,ruby identifiers[/tags]

Jan 142007
 

I spent a couple of hours trying to figure out how to handle 404 and 500 errors in Rails. This is not simple and actually really annoying. Hopefully future versions clean this up because right now it sucks pretty badly. Anyways, I found a page on the wiki and some other blogs, but the issue was that they wouldn’t handle all the cases. So, here’s the solution:

1. Edit your app/controllers/application.rb file and add these three methods:

The first method will be explained in the next step. The second method is the method that Rails calls to handle most errors. This method will not capture a certain class of errors where neither the controller nor the action requested exist. The third method tells rails to stop sucking. Normally Rails handles requests made to localhost or 127.0.0.1 differently than all others. This might be for debugging purposes, but it sucks when testing error handling.

2. Edit config/routes.rb and add this line TO THE END OF THE FILE:

This tells Rails that if it can’t find any other route to handle the request (i.e. the *path) it should call the rescue_404 action on the application controller (the first method above).

3. Edit config/environments/development.rb and add this line:

This additionally tells Rails to stop sucking and stop handling requests to localhost and 127.0.0.1 differently.

Anyways, happy coding.

Nov 242006
 

Here’s a conversation between James and I that started on dynamic languages and went on a tangent about languages, revolutions and evolutions.
Ponch: I’ve just been working on Naymz stuff lately. Also tinkering with Groovy and using it with an MVC
James Humphrey: haven’t heard any good things about Groovy
James Humphrey: hearing a lot of bad things though
Ponch: Like what?
James Humphrey: can’t remember exactly…I think I remember something about it was just a pain in the ass to code in it. trying to remember specifics
Ponch: I think Groovy is fine for what it is, but I prefer ruby mostly.
James Humphrey: I think one was, there’s no good IDE out there for it
Ponch: Eclipse is really good, even has debugging for groovy
Ponch: Ruby is way behind in the IDE space.
Ponch: Groovy is way ahead.
Ponch: Groovy is much easier since it is just converted to Java. Ruby is different because it is a lot more dynamic
Ponch: So, you can’t really make a java class out of a ruby class
James Humphrey: I dunno, can’t really remember. I think most of the issues I read were programmatic. You know, loosely typed scripting issues; too much power given to the programmers, convention issues, etc
Ponch: haha those dudes would definitely hate ruby then.
James Humphrey: which dudes?
James Humphrey: oh, the dudes I read the artices ffrom?
Ponch: There are a lot of good articles about how loosely typed languages sometimes are better for large projects.
Ponch: Chcek out this thread I started at Groovy user list: Here’s the thread list that shows the replies:
http://www.nabble.com/codehaus—Groovy-f11866.html
and here is the post:
http://www.nabble.com/Trying-to-get-a-sense-for-dynamic-groovy-tf2665364.html
Ponch: It might be the largest thread. not sure though. hehe
James Humphrey: wtf is ‘duck typed’
Ponch: it is a loosely typed term. Here’s an example:
class Foo {
def foo() {}
}
class Bar {
def foo() {}
}

def someMethodThatCallsFoo(obj) { obj.foo() }

someMethodThatCallsFoo(new Foo())
someMethodThatCallsFoo(new Bar())
Ponch: I can call the method with any object that has that method. Only way to do this in Java is use an interface and have everything implement that interface and then the method takes the interface. Or using reflection (eeck!)
Ponch: That’s why most folks favor naming conventions heavily in dynamic languages, that way you can call methods that use length() and pass them String, Array, List, Map, anything that has that method on it.
James Humphrey: this is exactly why I hate scripting languages. I don’t understand any of this nor do I want to
Ponch: Man your already an old java meiser (sp?) hehe
James Humphrey: no, I just don’t like loosely typed languages. Usually, scripting languages are loosely typed. It’s just too hard to figure out what’s going on
James Humphrey: there’s just way too much freedom to write bad code and causing pain for maintaners
James Humphrey: er maintainers (ppl who do maintenance on the code)
Ponch: That is the most common misconception I think. Most people feel that way about them
Ponch: The freedom allows for less coders, less coder and easier maintenance (usually).
Ponch: sorry less code
James Humphrey: imo, there’s a programming semantic continuum. On the far right is DSLs and the far left SCripting languages. In the middle you have things like Java, C#, etc.

Imo, we should be moving more towards DSLs. SCripting languages are just too hard to figure out, maintain, and document. Sure, it’s easy to program in it…that’s the problem though
James Humphrey: contiuum is probably a bad model
James Humphrey: evolution maybe. dunno, you know what I mean though I think
Ponch: Many believe that DSLs are built on top of dyNamic languages.
Ponch: You can find a lot of information about using ruby to build DSLs very quickly
Ponch: To me it is more about features of a language because in the end they all do the same thing, compile down to assembler.
James Humphrey: I agree with that. I just think that you can evolutionize languages without making them loosely typed
Ponch: You can go both ways in evolution. C# is evolution on Java. Ruby is evolution on Perl
James Humphrey: and, you’re right. Honestly, I could care less about what’s underneath the language (usually) because in the end I know that it’s all assembly anyway. What’s important to me is not just how it’s coded but how it’s maintained
Ponch: my motto is use the right tool for the job. I don’t like writing java to handle a simple command line search and replace. Much better to use ruby. Don’t like using ruby to build a text parser, to slow.
James Humphrey: and, in my limited experience, it just seems to me that maintaining scripting languages are a pain in the ass because you never know what you’re going to get. One person does it this way, another does it that way, which leads to confusion
Ponch: Usually that doesn’t happen though.
Ponch: The code is concise enough that to understand it takes very little time.
Ponch: I figure the more tools I have in my toolkit the better off I am.
Ponch: That is why I’m learning groovy and python and c#, so I can figure out how they all work in case I need them
James Humphrey: it’s like, why create the allen wrench? now I have to have more tools in my toolbox to get a job done to maintain something. ;). I think there’s a fine line with evolving and just creating more shit
Ponch: haha you definitely carry a sentiment that many others do. The problem in our business is productivity. How can I get something done faster, better, more well tested, more maintainable, etc. Java just doesn’t fit the bill in all cases. Nor does C++ or Ruby or anything. You could use Java to make a 3D game, but you’ll probably spend more time doing it, and have worse results. The key is to figure out how to be the most productive and often that means looking at lots of different languages, frameworks, tools, IDEs, etc.
James Humphrey: I think scripting languages have their use, don’t get me wrong. I also think that they are probably a natural process to evolution within the software world. I just don’t think they are the revolution that we’re all waiting for
Ponch: I agree with that. I don’t think there ever will be one of those.
Ponch: It will just be a constant refresh of ideas and principles
James Humphrey: like anything yeah, but I disagree. I think something (like c, like java) will come to revolutionize the way software engineers do things
Ponch: maybe, I wouldn’t discount that, but I don’t think Java was a revolution. It was just C++ with a few tweaks.
(09:42:06 AM) James Humphrey: maybe yeah. I dunno though: garbage collection, exception handling, pure OO….there wasn’t much of that around, or at the very least there wasn’t anything getting a lot of visibility
Ponch: You are right about those things, but C++ had garbage collection it was just manual and dangerous, it had exceptions they just sucked and Java still isn’t pure OO because it has primitives (unlike ruby).
James Humphrey: true, I should have said ‘automatic garbage collection’ (which isn’t all that to be honest). And, yeah, java primatives…/shrug
Ponch: Maybe a revolution will happen, but it will be something like IAL, which BTW sounds like Isle, which is kinda a cool name.
James Humphrey: whoa, never looked at it that way before
Ponch: A DSL for a very common domain (web aps)
James Humphrey: that would rule
James Humphrey: it’s also very very very very fucking complicated. even with your and my experience combined, we can’t figure it out
Ponch: probably not completely, but we can make good steps and then get people interested and helping out.
James Humphrey: and we have over what…at least 15 years combined web experience (I have 9 or 10 I think)
Ponch: I started building web apps in 98 I think.
Ponch: Maybe 97. hmmm not sure
Ponch: so 8-9 years for me
Ponch: BTW this conversation is really good. Mind if I post it?
James Humphrey: sure, I don’t mind
James Humphrey: good luck organizing the flow of this though
James Humphrey: hehe
Ponch: I was just gonna copy and paste. ;)
James Humphrey: haha
James Humphrey: ugh
James Humphrey: kinda funny…you spend your ‘free’ time blogging. I spend my ‘free’ time playing games
Ponch: yeah, moved from games to dork-dom
Ponch: hehe