“Good morning to everyone”, said Tim, smiling at the front of the table. “Before we start, we’d like to ask you to hold your questions until after each presentation. Each pitch is about ten minutes.”
“I can’t do that”, said Jobs. “I’m not built that way. So if you want me to leave, I will, but I can’t just sit here.”
— Steve Jobs (found via Signal vs. Noise).
One doesn’t have to live long in NYC to understand one of the non-obvious benefits – the ability to completely disappear into anonymity as an individual if you really need to. It’s quite easy to lose oneself, in a good way, on an island humming with the presence of 3 million people. Folks living in other places don’t seem to comprehend the typical New York City experience of living in a 500-unit apartment complex for years, and not knowing any of your neighbors. Some might shudder at the thought…I find this aspect of life in New York quite appealing.
I like the Brooklyn accent. It may not be a sound oozing sophistication or sex appeal, but it does give its owner an almost brazen air of confidence in almost any social situation. Great stuff!
From New York City by Andrey Butov.
Luke Plant pointed out that Python, in contrast to Java and C#, makes templates unnecessary most of the time. In Java, a minimal program has a class definition and a method definition. In Python, the minimal template is an empty file.
The advantage of this is the ease of diving in and writing code. You don’t have to set up and/or use templates in an IDE, copy and paste, type boilerplate code in manually, or run a command-line script to get started.
As Luke points out, Django is the same way. This is one way it differs from Rails. In Rails you run script/generate.rb to generate a model from the database definition or a boilerplate view or controller. This is the way that is taught in the tutorial.
In the Django tutorial, the reader is instructed to simply type the code in and save it in a text editor. And as Luke points out, Template Inheritance makes it so adding a new page with the theme of the main page involves only three lines of code.
I also like how the models are structured. In Rails, you run script/generate.rb and a model file is generated, along with tests and a “migration file”, and you repeat this for each class (a class corresponds to a database table). In Django, you make a module file in the “models” directory, and each module file can contain however many classes you want it to. Sometimes it makes sense to have multiple models in a file (when there are tightly coupled models) and other times it makes sense to give a model its own file. Django gives the developer the freedom to choose how to structure the model directory.
I feel more in control when I use Django, because once the initial directories are set up, I add things starting with blank files and writing them using my own style. No boilerplate comments or tests are there to distract me. Also, since I don’t have multiple files being generated at a time, in different directories, version control is much simpler.
There are a number of other design decisions in Django that I like, some which differ from how Rails is designed, and some which are the same. The success of Django, I think, comes from being a well-designed and innovative framework, written from the perspective of its creators (the same could be said of Rails). I think this is why it has more mindshare and a bigger community than imitation frameworks.
I think that starting an open source project that imitates another as closely as possible, but on another platform, is a bad idea. Not only does imitating result in copying mistakes, it also results in copying style, which inevitably get mixed with the style of the copier. I think it’s better to figure out which features are needed from the existing project’s platform, and to adapt them, one by one, to fit well into the new project’s platform, and to the style of the developers and users of the new project.
I love NYC. I visited for a week, and found the experience absolutely amazing. There is so much to see and do.
The best parts of the experience are meeting people and just walking around. Central Park is beautiful, and I like walking down the streets of Manhattan and seeing the interesting mix of new and old buildings, people, shops, and restaurants. I also like the MTA (subway system). For about twenty bucks for a week, you have a pass for a subway network covering all boroughs, except Staten Island, which is not accessible by Subway, but is accessible by a free ferry. There is more to see in those boroughs, at least when it comes to human civilization, than there is in all of Arizona. In Arizona, however, I have to drive for transportation, and it is expensive enough that going to new places is a rare experience for me, even on weekends.
Today I received a random e-mail from a recruiter about a Java web application job in NYC. I said I don’t have Oracle experience, but he was still interested and said I could probably get an interview. The mere thought of moving to NYC gave me butterflies in the stomach. How I would love to return, and visit the zoos and museums, walk around, and go to interesting clubs like LispNYC.
So I set forth to learn more about programming in Java. I am very motivated in this endeavor. One of the requirements for the job that I got the e-mail about is Spring. So I decided to pursue a project that I’d been planning to do in Java Swing (a desktop GUI framework) and do it in Spring, as a web application. I’ve been working my way through a tutorial, figuring out how to get a good setup with Tomcat, Ant, and Spring. Next I’m going to hook a PostgreSQL database to it.
I’ve heard good things about Spring. Some people like it even more than (gasp!) Rails. So far I’ve just entered the first sample code for a controller:
import org.springframework.web.servlet.mvc.Controller;
import org.springframework.web.servlet.ModelAndView;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
public class TileEditorController implements Controller {
public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
return new ModelAndView("");
}
}
A class named ModelAndView! Interesting. I imagine if Java had support for tuples, Spring probably wouldn’t have that class. I think in absence of tuples, however, it’s a perfectly valid way of doing it. Quirky, but good.
Some things are complicated. Other things are just quirky. I don’t think it’s good for a developer to let quirkiness get in the way. In fact, I think a lot of the time it’s just a fact of life, that can not only be accepted, but enjoyed.
Just as I enjoy the quirkiness of buildings in NYC, which are full of character, and take on a life of their own, I can appreciate a clever solution to a programming problem that reality brings. I think of programming now more as a series of steps. If I have to do something needlessly complicated to complete a simple step, that’s annoying. If I have to do something straightforward but a little quirky, that’s OK by me!
Dharmesh Shaw posted a humor piece to his excellent blog at OnStartups.com. I thought the part for strategy type was the funniest (particularly because I’ve had a strategy type for a supervisor before):
Strategy Type: Forget the light bulb. We need to stop skating to where the puck is, and skate to where the puck is going to be. In five years, there will be no light bulbs to change. I’m going on an executive retreat next week and plan to return with a vision statement that articulates how we will leverage our core competencies to erect a formidable barrier to entry in the $1 billion market for LaaS (Light As A Service).
Today Bruce Eckel posted a blog entry called When Reuse Goes Bad. He tells of a project he was sent in to fix, as a consultant:
The main design and technical problem (ignoring for the moment Weinberg’s maxim that “No matter what they tell you, it’s always a people problem”) was that the contractor had decided that this was an opportunity to develop a reusable software system, and that they could develop this system on the customer’s dime.
This resulted in classic framework-itis. The contractor was no longer just trying to solve the customer’s problem, they were trying to solve all problems that looked like it. So for that reason alone the project would have required 10x the original time and money.
This reminded me of a post by my friend Eliazar, where he proposes a new dictum, Use before you reuse.
As I ponder on these points, I think of Paul Graham‘s essay Taste For Makers, where he states, “Good design solves the right problem.” When I think about getting at the heart of the problem, I think of the chapter about Use Cases in The Pragmatic Programmer. If the goal is to design a non-trivial library for thousands of users with many different usage patterns, how do you get at all the use cases? You can’t. The thing to do is to make something that solves one problem well, and adapt it, one by one, to solve other problems. Eventually, it will solve a lot of problems.
I think the Linux kernel is a good example of this. The first Use Case was Linus Torvalds running it on his own computer. In time it was adapted to run on many different computers and to do many different things. It had fewer growing pains than other things that were built Cathedral-style.
