For people like me who were late to the Google Analytics beta party, the service is finally available for general consumption. I love statistics, and I’ve been looking forward to seeing just how few people actually read my blog. So, now you know. You’re being watched.
I almost needed some Oops! I Crapped My Pants after I saw this Firefox extention. It makes writing Selenium tests dead easy. Check out the screencast. You can save the tests as local HTML files to be run in the Selenium IDE again, or you can just drop them into your Selenium installation. Sweet! I’ve only given it a try on some simple stuff so far, but it’s preformed beautifully. Too bad I won’t be working on web apps much anymore after this week. 😉
In a recent essay about how to come about ideas for start-ups, Paul Graham was able to explain to me why I feel the way I do about my life in the “Enterprise.”
In an essay I wrote for high school students, I said a good rule of thumb was to stay upwind– to work on things that maximize your future options. The principle applies for adults too, though perhaps it has to be modified to: stay upwind for as long as you can, then cash in the potential energy you’ve accumulated when you need to pay for kids.
I don’t think people consciously realize this, but one reason downwind jobs like churning out Java for a bank pay so well is precisely that they are downwind. The market price for that kind of work is higher because it gives you fewer options for the future. A job that lets you work on exciting new stuff will tend to pay less, because part of the compensation is in the form of the new skills you’ll learn.
So, there’s little future in unexciting jobs, and the least exciting ones pay the best? I don’t know if he’s right on, but I think he’s close. One thing’s for sure, being downwind of most things definitely sucks.
So, I ran across this article during a long session of blog and article reading today: Exploring Strange Languages – Programming on Linux. I found it on the wonderful blog Lambda The Ultimate. I’m not going to say much about the article, the title and its content more then speak for themselves. To give you the gist of this very content thin article, this is the introduction:
While most developers use popular languages such as C, C++ and Java to create solutions on Linux, others are using somewhat obscure or strange languages to create Linux solutions. This article will look at providing Linux solutions using such programming languages as Python, Perl, PHP, and Ruby.
Novell obviously does not monitor the articles that employees post to its “Cool Solutions” wiki. This article is an embarrassment. That this guy is a software engineer at Novell is a very scary proposition. Doesn’t Miguel work there? I feel like I should say more, but I have been rendered completely speechless.
This article over at Patrick Peak’s blog really pissed me off today, and I wasn’t even in a cranky mood. I thought I’d post my reply here since it’s longer than most of my posts anyway. 🙂 Here it is:
You’re kidding me, right? Dave and Jamis, you guys went too easy on Patrick. This was, obviously, a cloaked, underhanded put down of ruby/rails developers, or just non-Java developers in general. Passive-aggressive, anyone? I had to read the post and comments 5 times, just to make sure that I’m not blowing this out of proportion. Sometimes, I’m embarassed to say I’m a Java developer.
Do you mean to tell me that if you don’t have ANT and you’re not using Java that you can’t properly develop and deploy a webapp? Come on! Everyone, at least everyone who knows what they’re doing, keeps completely separate development and production environments. The requirements (configuration, hardware, security, etc.) for each type of environment are completely different no matter what platform you’re developing for, and it’s very difficult to not separate them. Most developers keep various other environments for testing and/or staging as well, and they use build tools, version control, and scripts to tie everything together.
Heck, it’s even the same for desktop apps. Do you know of anyone who’d ship a binary to customers with debug symbols in it and assertions turned on? Not anyone who’s software is worth paying for. Build tools, development environments, and deployment strategies are not some bright new ideas dreamed up by the Java community. They’re common, everyday tools that all (well, most) professional developers have been using for longer than Java has been around. To assume that you have to be a Java developer using ANT to understand these concepts is not only naive, it’s plain conceited.
Basically, it all comes down to whether or not you know how to properly manage your project, your sorce code, and your deployments. The process is portable to any language and any platform. “Write once, run anywhere.” 😉
Update: As usual, I can’t say it as well as Dave. He always says what’s in my head so much better than I can. I guess that’s why he writes books and I don’t!
Everyone who works with a computer has felt like this before, especially those who run Windows. 😉
Every once in a while, I run across a fabulous article that Joel (Spolsky of Joel on Software fame) wrote a while back that I’ve yet to read. This is one of those articles. In this article, Joel reminds us that, sometimes, the complexity beneath our abstractions leaks through and can cause us a world of hurt if we don’t understand those complex things going on underneath.
This has bitten me in the past with Hibernate. Hibernate abstracts the database away from us Java developers. It’s a wonderful tool, and it handles a ton of complexity under the covers, but that level of abstraction can come at a high price when you spend 2 weeks debugging what should be a simple problem. Unfortunately, if you don’t understand all of the things that Hibernate is trying to abstract away, you end up doing stupid things that you never would’ve done had you been using JDBC, for example.
Someone once said, “With great power comes great responsibility.” As software developers, we have a responsibility to at least understand the complexities that our powerful abstractions hide from us, or we are doomed to a life of debugging problems that never should’ve existed. For our first lesson, here’s a link to another Joel article that reminds us that string handling is very hard under the covers (it’s crazy that I can call C programming ‘under the covers’ these days). Aren’t you glad we have ruby, python, java, etc.?
Quick sidenote: I haven’t figured out the RSS issue yet, but I did notice that I was getting picked up in bloglines. Hmmm. Maybe it was an old cached feed from when the feeds worked. I don’t know, and I haven’t had time to dig in and figure it out yet. This is just a default install of WordPress. I haven’t even changed the damn template. Argh!
Anyway, I bet you’re wondering what that subject means at the top of the post. Well, let me set the scene…
At work, we use some stupid Novell system to distribute our licensed apps. One of those apps is WebSphere, which is the app server I have to test my code against. To get WebSphere, I have to install the WebSphere Studio (basically Eclipse 2 with a $5,000 price tag). Fine, I can live with that. Now, I want to run the app server outside of WebSphere Sutdio so I can develop with Eclipse 3.0 (the free one) and deploy with ant. Shouldn’t be too complicated, right? Well, when WebSphere Studio is first installed, a bunch of server startup scripts and xml configuration files are generated for the app server. Now, the supid Novell application distribution thingie mentioned earlier installs it to a different path then I am forced to, and all of the generated batch files have the WRONG hardcoded path in them. The “good” news is it only took me about 1.5 hours to figure that out.
Now to the point of my post. I had to replace their hardcoded path with mine in all of the batch files and xml files. These files are in a myriad of directories under the main WebSphere directory. So to make a way too long story short, I wrote a short 7 line ruby script that takes a filename as an argument on the commandline and interates over each line replacing the bad path with the good one. That took about 5 minutes. I know I could’ve used sed, but I love Ruby, and I like to write Ruby scripts whenever I can. So next, I wrote a long command line to actually call the script on the appropriate files, and BAM, all done. Grand total of about 9 minutes, 4 of which were spent refreshing myself on the awk syntax. Now, how long would that have taken me if I were pointing and clicking? 😉 Anyway, I know that this isn’t anything remarkable, I just get excited when I see great tools do their job well. The whole *nix philosophy of combining simple tools that each do their jobs very well to do complex things is so awsome.
Without further ado, here’s the command:
grep -re '[cC]:[/\]WebSphere[/\]AppServer' . | awk -F":" '{print $1}' | awk '{print "./replace_path.rb "$O}' | bash
And here’s the trivial ruby script:
lines = []
File.open(ARGV[0],"r") do |file|
file.readlines.each do |line|
lines << line.gsub(/[cC]:[\/]WebSphere[\/]AppServer/,'C:/Progra~1/IBM/WebSph~1/runtimes/aes_v4')
end
end
File.open(ARGV[0],"w") { |file| lines.each {|x| file.puts x }}
Have a nice day!