Every so often, I read a bunch of snark on Twitter about Ruby on Rails and how it “doesn’t scale”. I think these folks are missing the point. Continue reading
Programming
There are 13 posts filed in Programming (this is page 1 of 2).
Starting to learn Processing
No new post today. I’ve been starting to learn Processing and working through some of the tutorials. Check out my first toy project.
a brief diatribe about Java’s SSL implementation
Getting back to more tactical things, I’ve been hacking on some Java code recently for the first time in a long while. I’m trying to grab some data from a vendor’s SOAP interface for trending in Cacti, and having had problems with Perl’s SOAP::Lite library, I switched to using Apache Axis in Java. However, this post isn’t really about my web service client: it’s about how much SSL in Java stinks. Continue reading
agile development and what it’s not
It seems like Agile software development methodologies (XP, Scrum) and their associated techniques like pair programming are all the rage these days. I’ve never worked for a truly successful Agile shop, nor am I actually a developer (any more) but I do want to address the delusions that some people, particularly managers, have around Agile. While I do believe Agile methodologies have their time and place, implementing these tactics do not guarantee that your project will deliver on time, on budget, or with happy developers. Here are a few of my observations about Agile and how it is misused. Continue reading
a quick reflection upon DemoCampToronto7
This evening I went to DemoCampToronto #7, a project of BarCamp Toronto. As BarCamp’s website says,
BarCamp is an ad-hoc gathering born from the desire for people to share and learn in an open environment. It is an intense event with discussions, demos, and interaction from attendees.
DemoCamp consists of a set of presentations totally no more than 15 minutes apiece (including questions) on up-and-coming software projects. It’s basically the same as a WiP session at any USENIX conference.
I don’t have enough time to summarize all of the presentations, but I’m sure others will (and I’ll try to link to some of the better summaries here). I just wanted to step back a moment and reflect on the fact that a room full of 150 passionate, articulate coders — in Toronto, no less — makes me think that we’re having a renaissance in the software development and IT industry. These are not coders who are just buzzword and Web 2.0-compliant; I sense that these folks are making real productive use of technologies like Ruby on Rails, AJAX, DHTML, Flash, and all the other gadgets that are revolutionizing the Internet by providing a true challenge to the classic thick application.
This renaissance is borne out by the increasing proliferation of jobs. Tucows just held a job fair, after which they hired a number of individuals fresh out of Computer Science at U of T (I know because two of them were sitting at my table). Exciting companies like Nurun and Critical Mass are hiring and expanding. I’ve personally been courted by one or two companies, unsolicited. Contrast this with the state of affairs five years ago, which is when I graduated from U of T. Jobs were scarce and I was lucky to land a position programming PHP for a firm that hadn’t blown its money in the dot-com crash.
It seems to be a great time to be in IT. The buzz is in the air again, and I have but one word of warning for many of the IT firms that have just barely stayed afloat for the last few years: You’d better do something to make sure you hang onto your technical staff — i.e. give them interesting, challenging work, and respect their talents — or you will lose them to other companies that are willing to make those tools available.
why has CORBA failed?
There’s a great article in this month’s ACM Queue entitled The Rise and Fall of CORBA. Since it’s authored by Michi Henning, who worked on CORBA as part of the OMG’s architecture board, and subsequently became an ORB implementer, consultant, and author of a book on CORBA Programming with C++, I had to take notice. The article itself isn’t available online, so I’m sorry I can’t suggest that you read it — instead you’ll just have to put up with my opinions, peppered with some quotes from the article.
TheDailyWTF.com on AJAX and Web 2.0
If you work in IT, and you don’t already read The Daily WTF, you should. The site bills itself as documenting “curious perversions in IT” and I have to say that this is an understatement; the code that frequently shows up there is bad enough that the word “poor” does not begin to describe it. Sadly, I think much of the code behind so-called enterprise-grade software out there in the world is of the same calibre. We should be afraid.
I had to laugh at their recent skewering of AJAX and Web 2.0. I’ve complained about such things before, but this one does it in such a brilliant way that I really don’t have to say much more:
The introduction of the XMLHttpRequest component opened the doorway for a new breed of “fancy schmancy” web applications like Flickr, GMail, etc. This, in turn, spawned an entire sub-industry and a new series of buzzwords seemingly based on the names of household cleaning chemicals. It even incremented the current version of the Internet to 2.0.
Although the Web is apparently now at version 2.0 much of the software continues to be in beta.
Unskilled and Unware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments
The title of this post is also the title of a fabulous paper published in the Journal of Personality and Social Psychology of the American Psychological Association (PDF). I mention this in the context of technology because the paper was first mentioned as a response to this post on The Daily WTF, a site exposing bad programming in a daily blog format.
First, in regards to the post — I can vouch for the fact that there is some really bad code out there, and much of that, I’m sure, comes from programmers with overinflated egos who don’t realize their own incompetence because
people who are unskilled in these domains suffer a dual burden: Not only do these people reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the metacognitive ability to realize it.
Still, part of the problem is a lack of proper management oversight — whether it be functional management, or technical management. Indeed, in many cases, bad programmers’ incompetence is rewarded because their products are seen to be "business successes" because they allegedly meet the functional requirements — never mind the fact that the applications consume far too many resources on the system, crash all the time, and cause a huge maintenance burden for the operations staff. I can provide many examples, but I’m sure I would get in trouble 🙂
I considered printing out the APA paper and anonymously stuffing it in peoples’ mailboxes — not only in the mailboxes of those programmers who I feel are totally incompetent, but also in the mailboxes of their managers who still think they perform(ed) well. I decided against it not because I think I would get in trouble — they’d have no way of detecting who was the culprit — but again because their own incompetence would prevent them from detecting that the paper is targetted at them.
As Kruger and Dunning point out, the only way to resolve this dilemma is to remove the incompetence — train the bad programmers to be better programmers, and to recognize their own shortcomings. That can’t happen if bad management is preventing even the open discussion of the poor code quality.
Today’s my last day at CBC.ca. I’m moving on to a pure systems administration position with a much smaller e-business company in Toronto called Devlin e-Business Architects. I decided that working on content delivery projects like the Torino Olympics website is really not where I want to be strategically with my career, and I don’t think I ever fit into the big company mindset very well. I’ll be writing more about that once I’m not formally under the employ of said big company 🙂
In the meantime I wish you all a very happy holidays and new year!
Java Virtual Machine Tuning under JVM 1.4.2
Here’s an article I wrote about tuning Sun Java JRE 1.4.2 some time ago. I’m only posting it now to save it from loss when I leave CBC.ca.
This page is intended to document some proposals and empirical data gathered while attempting to tune the JVM used for running web applications on CBC.ca’s Java servers.
Topics to be covered:
- Impact of using different garbage collectors
- Impact of tuning garbage collectors
- Maximum and minimum heap size settings
- [potentially] Impact of using different JVMs other than the Sun JVM. For example, compiling Java code into native OS code using gcj? among others.
vendor library bugs…
Not to engage in schadenfreunde too much, but sometimes it’s nice when something you’ve been working on to fix is actually the result of a vendor bug.
I feel I should say something about tonight’s election, but this is primarily a technical weblog, so I merely wish to point you to a hilarious satire site that I was helping to work on:
We built the site in about a day as part of a GeekEnd event.