Text

· · to read

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.

Text

· · to read

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!

Text

· · to read

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).

Text

· · to read

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.

Text

· · to read

Here’s a few things that I think would have made my undergraduate career more successful:

  • Consider waiting until after your first semester to declare a major. I started my first semester majoring in Computer Science and never really considered majoring in something else until I was a sophomore. My friends and I were proud that we knew what we wanted to do. Actually, it’s better at this stage to keep your options open. For every degree there are related degrees. The related degrees may have a better department, with more professors, more money, and more research opportunities. Math or Physics would probably have been better choices for me.

    If you’re undeclared, you will have an advisor who’s job is partly to help you pick what to major in. You also may get useful advice from teachers in what to major in when you talk to them after class.

  • Get to know your professors, not just in your the field you’re majoring in, but in one or two others. You may find, after you graduate, that you want to go to grad school or work in the field you have a minor in. It will be a lot easier if you have several references from the new field. In my case, I got a job working on a fascinating project that would greatly benefit from both programming and mathematical expertise. I decided to pursue a graduate degree in Mathematics. I’m applying for admissions right now, and wish that I had built stronger relationships with the faculty in my school’s Mathematics department.

    The learning itself is also a good reason to get to know people in another department. Organizations everywhere want people who are good in multiple disciplines. For example, anyone with a science degree should have a good mathematical background, and that comes partly from getting to know your professors and excelling in courses in the Math Department.

  • Don’t skip classes just because you’ve already taken them at a community college or high school. To me it seemed obvious. Since I’d taken Calculus I and II at the community college, I was ready to take Calculus III. I heard of some other students that were taking Calc I even though they took two semesters of AP calculus. I asked a guy why and he said that he didn’t think he was ready for it. I foolishly assumed that his class must have been a joke and was glad I took it from a fairly good teacher. Only later did it sink in that it may have been a good idea to start with Calc I. First of all, I could have got sorely needed A’s in my first two semesters. Secondly, I would have had more time to build relationships with Math professors. Finally, I would have been less stressed and had more free time for academic exploring during my freshman year.
  • Keep your scholarship. “I can do anything I put my mind to.” It’s good to think this, but only to a certain extent. Confidence is good, but so is rational thought. If you got two A’s, one B, and three C’s your first semester, and need to have a 3.5 GPA by the end of your second semester in order to keep your scholarship or tuition waiver, don’t do it simply by trying to work harder. Do it by taking a lighter load and/or easier courses. If you’re a science major, take business courses, if you must. I made the mistake of taking what the advisor recommended for completing the degree in the shortest time possible, and lost my tuition wavier. For the next several years I worked, and the distraction brought down the quality of my education considerably. I also ended up with a mediocre GPA of 3.01.
  • Have study buddies. I’m not the person to give advice on social skills, but I have seen how important they are. Seek advice on this matter. I’ll be doing the same. I am trying to put into practice the advice in the book Never Eat Alone, which has a lot of interesting suggestions.
  • Go to the library. Chances are, the university library has fewer distractions than your dorm or apartment. So if you’re having a hard time concentrating, go there. Also, browse the bookshelfs in any subject area that interests you. Even if you’re looking for books on Computer Science and most of the books are old, there are sure to be things you haven’t learned yet, even if the examples are in archaic programming languages.
  • Exercise frequently and maintain a balanced diet. One big danger for college students is turning into insomniacs. Sure, you will probably have to pull the occassional all-nighter. But don’t let that become a habit. Frequent exercise and a healthy diet will help you to balance out your sleep schedule. It will also help you to avoid sickness, and to concentrate on your classes.
  • Learn to ask for help. Don’t wait to ask for help until you’re deparate. Ask for help from your teacher if there’s something you don’t understand. Ask for help from your advisor if you’re worried about your grades. Ask for help or advice from parents or other relatives if you see financial troubles on the horizon. Don’t wait until you’re desparate to ask for help. If you do, you will make it harder on yourself and on those who care about you.
Text

· · to read

Anyone who has poked around in the Scheme or Functional Programming community has no doubt heard about PLT, or at least one of its projects, which include DrScheme and the book How To Design Programs. PLT is a group of people spread across four universities that works on a number of projects, some of which involve making really cool software, and others which involve teaching programming.

They’ve created a complete graphical programming environment called DrScheme, which includes a Scheme interpreter, various Scheme libraries, and an IDE written in Scheme using their libraries. It even has its own HTML renderer that is used to implement the Help Desk feature of DrScheme.

They’ve used PLT Scheme (the umbrella name for the different distributions of their Scheme implementation) to build:

  • A PLT web server, which presumably is used to host their own website, which is well designed.
  • A Slideshow application, which Matthew Flatt uses for in-class presentations
  • PLaneT, a package repository for PLT Scheme

Four of them wrote a great introductory programming book, How To Design Programs, (HtDP) which covers a lot of practical programming concepts that were sadly skipped over in my C. S. program.

Using HtDP, they have a TeachScheme! project, which aims to “turn Computing and Programming into an indispensable part of the liberal arts curriculum” [1]. This is an important goal. Even if most people in other fields don’t program as part of their job, I think it’s a good idea for them to learn enough to understand the process of programming, as it often effects their work. HtDP starts at a level that most high school student ought to be able to understand, while still being interesting to a graduate of a state university’s C. S. program. That is an impressive achievment.

I think that in order to make a really good learning organization, you’ve got to have ambitious projects and invite all members to participate. PLT certainly has more than its share of ambitious projects – a Scheme compiler, language extensions, a portable GUI framework, a web server and application framework, a package repository, and an HTML renderer. The same could be said about MIT, with their wide variety of operating systems, graphics, and compiler projects. It should be possible for any school to work on something along those lines. The first step would be for a member of faculty to start an ambitious project, and invite students to participate (hopefully with pay for anyone who does substantial research).

To start an ambitious project, you need something to work on. Fortunately, there are a lot of ideas already out there, and it’s not that hard to come up with an idea. In the words of John Locke:

The acts of the mind, wherein it exerts its power over simple ideas, are chiefly these three: 1. Combining several simple ideas into one compound one, and thus all complex ideas are made. 2. The second is bringing two ideas, whether simple or complex, together, and setting them by one another so as to take a view of them at once, without uniting them into one, by which it gets all its ideas of relations. 3. The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction, and thus all its general ideas are made.

John Locke, An Essay Concerning Human Understanding (1690)

A lot of programming projects are started by a programmer noticing problems that take lots of repetetive work to solve, and coming up with useful abstractions. Ruby On Rails was started this way. There’s a very good chance that the next big thing will as well.

[1] http://www.plt-scheme.org/

Text

· · to read

I went to my Alma Mater’s library in search of a book on Common Lisp and found Paradigms of Artificial Intelligence: Case Studies in Common Lisp by Peter Norvig. The book is 946 pages long and covers both AI and Common Lisp in depth. I started working through the Common Lisp chapter and found that it is much richer in features than I expected. I’ve always heard that Common Lisp is quite a contrast to Scheme, but hearing isn’t the same as experiencing it.

One thing that I like about Python is the cleverly designed def (define function) syntax, which gives the programmer all kinds of convenience and flexibility in defining functions (for example, having an arbitrary number of arguments, having explicitly named arguments, or having a combination of positional and explicitly named arguments — details here). Common Lisp has clever function-defining syntax too. Here’s an example of declaring a function with three explicitly named parameters, one of which is optional:

> (defun foo (bar &key (baz 30)) (list bar baz)
FOO
> (foo 30)
(30 30)
> (foo 30 :baz 90)
(30 90)

Another thing Common Lisp has in common with Python is doc-strings. I’ve seen them in emacs before. A doc-string is a piece of documentation that can be put in the function declaration and accessed at run time (or from within the REPL). In both Python and Common Lisp the doc-string goes in between the argument list and the function body.

One cool thing about Ruby is the ability to call a method with a minimal number of keystrokes. If bar has a method named baz with 0 parameters, the code to call it is “bar.baz”. There’s no need for empty parenthesis! In Python “bar.baz” would refer to the method itself. In ruby, to refer to the method itself, it’s “bar#baz”.

Common Lisp uses a hash symbol to refer to a function, but it is for a different reason. Common Lisp, like elisp (Emacs’ built-in scripting language), has a separate namespace for functions and variables. It’s possible (but arguably bad style) to have functions and variables with the same name. To refer to the functions, you add a hash and a single quote before them (e. g. #’foo).

It looks as though Python and Ruby both have inherited from Common Lisp. And that shouldn’t be a surprise – the designers of Python and Ruby have been programming long enough to remember a time when Lisp was more popular.

One thing about Common Lisp that’s often cited when someone mentions how big it is compared to Scheme is the format function. The format function practically has its own language for printing out text, and as Norvig notes, it’s not a very Lisp-like language. But there is also the loop macro, which was given its own chapter in Common Lisp the Language, 2nd Edition.

While I might just skip over learning to use the loop macro, I think that there are a lot of really cool functions and macros in Common Lisp that you could do without, but make things more convenient. It has some things that might seem redundant, but that can be used to code more clearly what you are trying to do. For example, there is a when macro, which is like if, but without the else clause. A Common Lisp programmer that comes upon “when” knows not to expect the else clause.

Another neat thing about Common Lisp implementations in general is that there tends to be debugging and optimization support accessible from the REPL (read-eval-print loop).

My first impression is that when I use Common Lisp, it feels like a mature language. I can tell why Norvig chose it to do lots of AI projects. It has a lot of features people want — it “lets hackers have their way with it” [1]. It’s multi-paradigm. Scheme is a little too focused on one paradigm (functional programming) for my tastes.

[1] Paul Graham‘s essay The Dream Language, form Hackers & Painters, which is not available online (yet). In my opinion, it’s one of his best essays.

Text

· · to read

Eric Sink posted an article bemoaning the current state of the web. In his footnotes is this observation:

I think we need to stop saying that the spammers only continue because they make money doing it. Virus writers don’t make money. They write viruses simply for the joy of causing harm to others. I don’t see much reason to believe that spam would stop if the financial incentive were magically removed somehow.

I agree with him. The idea that spammers will quit if they can’t find any more suckers is yet another piece of conventional wisdom I get tired of hearing. I also think it’s fairly useless to talk about something that’s not going to happen. As long as there are people, there will always be people getting suckered into making bad decisions. It’s human nature.

Text

· · to read

No longer am I going to cringe every time I hear the word “enterprise”.

Before looking it up, enterprise to me meant “big” or “expensive”, as in Visual Studio Enterprise Edition.

But today after wondering what kind of a software developer people are looking for when they use the word “enterprise”, I had a look in the dictionary. The fourth meaning in The American Heritage Dictionary’s definition is:

Willingness to undertake new ventures; initiative

This is a great quality to have, on both the large scale and the small scale.

I found a good example today of large-scale enterprise today, from the Daily Sun’s (Flagstaff’s local newspaper) revamped online job listings. A year ago, they were using their own setup. It worked, but had poor search functionality and a clunky UI. Now they’re simply linking to a customized portal by NowHiring.com. They have their logo up there, some generic graphics, and a website that works well. I applaud the developers of this software for seeing the problem the newspapers had and coming up with a elegant solution.

A good example of small-scale enterprise might be taking on a project to document or refactor some code, or implementing one of the things on The Joel Test.

Now when I hear people talking enterprise, I’ll give them the benefit of the doubt and listen to what they say, in hopes that they’re talking about true initiative, and not just trying to sound big.

Text

· · to read

I’ve been using Gmail lately. Overall it’s a great user experience, but two kinds of windows popping up annoy me.

First, why do links in the message body pop up in new windows, and why is there no way to change that?

Second, why use old-fashioned question popups for “there is no subject, are you sure?” messages? I’ve seen some cross-browser javascript for modal boxes in front of a page that seems to work fine. And unlike the standard popups, they aren’t modal across the tabs, only modal across the browser page.

I think there’s a geek consensus about the annoyingness of pop-up windows. Why is Google going with the stuffy, professional way of doing things?

Text

· · to read

Right now I’m reading David Heinemeier Hansson’s Blog back to front, and it got me thinking:

It’s a common practice to close down blog comments after a certain amount of time, especially on popular sites. I noticed that DHH’s site still allows people to enter a comment and press submit, even on the oldest entries. I think it’s a good idea to encourage commenting on old posts, because someone who’s reading an old post might have some insight about it. But on the other hand, people just aren’t going to notice comments from an old post.

My idea is that after a month, instead of allowing someone to add to the old post, or just saying “comments are closed”, the old post should have a form for e-mailing the author. It could say something like this before the form:

The time has expired to leave comments on this page. However, you can still fill out a comment form and your comment will be sent to me via e-mail (with an automatic link to this post). It may even inspire a new blog entry!

I’m going to implement this for my blog after I change my blog engine (I’m planning to either grow my own in Ruby or move to Typo), but if you like this idea, feel free to implement it yourself.

Also, thank you elzr for giving me the idea to read DHH’s blog back to front.

Text

· · to read

Olifante posted instructions for setting up TextMate to edit TextArea’s in Firefox using the recently updated Mozex Extension.

This is a huge improvement. I was already doing the same thing much of the time by copying and pasting. I heard about the extension and thought about what it would take to get it working well with the latest versions of Firefox and everything myself, but was glad to see that I don’t have to – the author made the necessary improvements. Great work, Vladimir Marek!

With extensions like these, Firefox beats Safari and Camino by leaps and bounds (It’s the Ecosystem, Stupid!).