Many Java developers have vowed to fight back against the unwelcome opening of their open source. League of Agile Methodology Experts (LAME) spokesperson Billy Blackburn says that work has begun on a new, even more complicated Java build system that will refuse to link in Opened Source Java code. The new build system will be released as soon as several third-party Java library vendors can refactor their code to make certain classes more reusable. Blackburn declined to describe these refactorings, claiming it was “none of y’all’s business.”
Guy Faulkner, a 51-year-old Python developer in Seattle, was amused by the Wikileaks announcement. “When Python developers release Open Source code, they are saying: Here, I worked hard on this. I hope you like it. Use it however you think best. Some stuff is documented as being subject to change in the future, but we’re all adults here so use your best judgment.”
Faulkner shook his head sadly. “Whereas Java developers who release Open Source are code are saying: Here, I worked hard on this. I hope you like it. But use it exactly how I tell you to use it, because fuck you, it’s my code. I’ll decide who’s the goddamn grown-up around here.”
Which is even funnier because I was having exactly this conversation last night at the HV Programmers Meetup.
On January 17, 2010 · Comments Off
Want to get a geek roiled up? Tell them you develop code in proportional fonts. The comments on that article are a text book example of irrational geek argument try to get the higher ground.
Remember, there is one wholely optimal way to develop code, just like there is only one best editor, and only one best programming language. Your decision of best would in no way be defined by the preferences of the skilled people you looked up to when you first learned this whole software development thing.
For the record, I prefer Arial.
This is a really great blog post on Talent vs. Practice:
I am sick of hearing people say, “Oh, I love your code, I wish I could do that.” You can. The only reason you can’t is because you don’t practice enough. I used to think that I wasn’t smart enough. I was jealous of those that did crazy code stuff that I couldn’t even comprehend. Then, one day, I ran into something I did not understand and instead of giving up, I pushed through. I sat there in front of my computer for hours and wrestled with class and class instance variables.
That day was a turning point for me. It was the last time I thought that whether or not I was successful depended on my talent or intelligence. It really comes down to hard work people. Ever since then, I have attacked each thing that I do not understand until I understand it.
The real moral of this story, stop talking about things you wish you could do, just knuckle down and do them. It’s hard work, but it’s the way you make an impact.
On January 12, 2010 · Comments Off
I first heard of Conway’s Law last week:
Conway’s Law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1968:
…organizations which design systems … are constrained to produce
designs which are copies of the communication structures of these
organizations.[1]
Enterprise software architectures make a lot more sense now, though not in a good way.
I’ve finally wrapped my head around the blocks, views, and content construction kit model for Drupal, which we’re going to be using for the upcoming relaunch of the Poughkeepsie Farm Project website (you can see the work in progress here). It took a number of days to make a mental breakthrough that let me understand what it was that Drupal wanted me to do to get results. The big break through was getting that custom content types is really what I wanted and then how to use views to display them correctly.
The exercise was one of programming with constraints. As a veteran software developer, I’m used to getting a blank page where I can happily build up features from scratch. That has the advantage of the end product doing exactly what I want, but has the disadvantage of having to do everything from scratch. While from scratch is often satisfying, it’s also often really tedious. By the time you’ve written your 3rd password reset system for a web application, you’ll feel that way as well. Life is too short to keep repeating yourself.
The alternative is something like the drupal approach. Start with a lot of the application done, and just complete the pieces you need for the project. As a veteran software developer, I’ve been there too. I’ve come into many a project late in the development cycle, and had to work inside the constraints that are already there because of decisions made in the past. These decisions might have been based on money, expertise, timing, politics, or any number of other reasons. At the end of the day it doesn’t really matter, you just have to accept what is, and figure out how to work with it.
Building on top of a framework like Drupal is like being brought in late on a project, where the rest of your team is the drupal community. They made decisions on how things will work, and you just need to figure out what those were, and if you can work constructively inside those contraints. It’s a different skill than the “from scratch” skill, but is just a valuable. The real world has a lot more half finished projects out there than blank slates.
People love to complain about frameworks, especially tech folks, because they feel the constraints are hampering their productivity. As any tech person knows, when you switch up what you are working on substantially, you go through the “wow I’m stupid” phase again. Your output suffers, and you feel like you are never making any forward progress. It takes weeks to months to get familiar enough with the new skill set, and actually start creating anything of value. No one likes to feel stupid, so a very standard reaction is to lash out at the tools, say they are the issue, and go back to your comfort zone. You get a lot of hating in tech on exactly that. But not all frameworks or tools are bad, and writing things off as evil because you never invested the time to understand how they work are as silly in web frameworks as they are with compound miter saws and belt sanders.
At some point in the next couple of months I’m going to write up my own “getting your head around drupal” blog post, because I have to admit I did it by brute force. Eventually I got enough insites to start getting productive. It took a while. I’ve been actively working on the farm site since september, and did a whole drupal layout back in the sprint just to kick the tires. But overall, this was definitely worth it, and I’m quite happy with the output levels I’m getting now.
On June 12, 2007 · Comments Off
I was just doing my morning catchup on RSS feeds with trusty Liferea, and ran across ingimp in my freshmeat feed, which has a rather interesting idea.
The standard method for usability testing in proprietary software is to pay to bring in a bunch of people “off the street” while your product is in beta, sit them down in front of your program, and give them a list of tasks to accomplish. You record the whole thing. Then you go back and figure out how long each of those tasks took, but more importantly, what sort of mistakes people made. When asked to Enable Grumocks, what menu did they guess grumock controls would be in?
While this is all good and fine for people with a bucket of money, in open source, something like this really can’t happen. Ingimp is a modified version of gimp (not a plugin), that provides transmits back to a central server what you are doing with gimp. This lets them get a snapshot of users as to what kinds of images they most often modify, which tools are most often used, etc. From their website:
Who uses GIMP? What do they use it for? What size images do they work on? How many layers do they have in their images? What tools do they use? How frequently do they use the software?
These are all important questions to consider during design. However, precise answers to these questions are generally unknown for the GIMP. While usability studies of the GIMP exist, and mailing lists and bug tracking software host ongoing discussions regarding the GIMP’s design, it is difficult to characterize how the GIMP is actually used in the real world, on a day-to-day basis.
ingimp is an instrumented version of the GIMP designed to gather this information, with minimal effort required. Just use ingimp as you would the normal version of GIMP and it will automatically collect information about how you use it — the commands you use, characteristics of your documents (number of layers, image width/height, etc.), and so on. When you quit the application, your usage data is sent to this website where it is publicly available for anyone to analyze.
ingimp is part of human-computer interaction (HCI) research at the University of Waterloo investigating new forms of sustainable open usability. In particular, our goal is to research new tools that assist open source projects in their efforts to make more usable software, without creating significant new overhead to end-users, developers, or other project members.
Unfortunately their instrumented version is still Gimp 2.2, and I’m on a 2.3 build in my distro. Perhaps after the next stable series I’ll give it a go.
