Archives for the month of: August, 2007

This post is probably not going to be the most interesting I’ve ever wrote. Not that I consider all my posts to be interesting but this one is going to address a very narrow problem: Ruby apps needing a tray icon on Windows. I’ve googled around and it took me a little while to find out about VRuby. It’s one of these projects that didn’t quite cross the Pacific, so it took me another little while to figure out how to use it. This post will hopefully save others’ whiles.

The English documentation is almost non existent but there are 2 good news: Nishikawa has written several good examples and VRuby is already bundled with the one click installer. Isn’t that great? Nothing to install on your Windows VM (because like most sane developers, you should keep Windows strictly in-VM and rely on better stuff).

The full code is reproduced below. I think there are enough hooks for you to plug your own.

require ‘vr/vrcontrol’
require ‘vr/vrtray’

module TrayHandler
include VRTrayiconFeasible
include VRMenuUseable
LoadIcon = Win32API.new(“user32″,”LoadIcon”,”II”,”I”)
QUESTION_ICON= LoadIcon.call(0,32514)
EXCLAMATION_ICON = LoadIcon.call(0,32515)

def construct
self.caption=”Good Stuff”
# trayicon menu
@traymenu = newPopupMenu
@traymenu.set([
["Do Stuff","stuff"],["Update Me","update"],["Exit","exit"]
])
create_trayicon(EXCLAMATION_ICON,”installr”,0)
end

def stuff_clicked
puts “Stuff done!”
end

def update_clicked
modify_trayicon(QUESTION_ICON,”modified”,0)
end

def self_traylbuttondown(iconid)
end

def self_trayrbuttonup(iconid)
showPopup @traymenu
end

def exit_clicked
delete_trayicon(0)
exit
end
end

frm = VRLocalScreen.newform
frm.extend TrayHandler
frm.create
VRLocalScreen.messageloop

If you’re looking for an example with the tray icon only appearing when you minimize, you can also check this out.

After a tasteless kayak, it seems that a shark finally found something more attractive:

The 24-year-old victim, whose name was not released, was surfing with a half dozen other people at Marina State Beach when the shark attacked him from behind around 11 a.m., according to Loren Rex, a California State Parks spokesman.

The victim screamed and started punching the shark while trying to flee, Rex said.

“Then the shark took him down under the water,” he said. “Witnesses saw a lot of thrashing and some blood coming up. Other witnesses saw the shark let him up before biting him one more time.”

Ouch! Definitely an awful experience. Luckily, the guy survived. However, you don’t need to worry about my safety, dear reader. I have more chances to die in my bathtub (about 20 times more) and infinitely more chances to be ran over by a careless driver talking on his cellular.

Humans are far more dangerous than sharks. Every year, 26 to 73 million (median value is at 38 million) sharks are killed by people in commercial and recreational fishing (wikipedia). And most shark species are really endangered with about 100 species vulnerable to extinction. Who cares? I do, I rather surf with an almost inexistent chance of being attacked on a healthy ocean than being safe on dead water.And there are many other reasons.

Picture from scotts101.

I don’t post that often about ODE but this one is a biggy. It’s our first official Apache release as a top level project. There’s a lot of goodness in there for anybody even mildly interested in WS-BPEL. And if you’re only mildly interested, you should probably try to get more interested. Orchestration should be used far more often that it’s used now, instead of business processes hard coding.

Here is the full announcement that should go here, there and everywhere pretty shortly:

Apache ODE is a WS-BPEL compliant web services orchestration engine. It organizes web services calls following a process description written in BPEL. Another way to describe it would be a web service capable workflow engine.

* Compliant with both BPEL4WS 1.1 and WS-BPEL 2.0.
* Deploys as a WAR in any web container (using an Axis2-based communication layer) or as a JBI service assembly.
* Small footprint server suitable for experimentation or  single-server production use.
* Compiled approach to BPEL that provides detailed analysis and validation at the command line or at deployment.
* Processes hot deployment and management web service interface (war deployment only).
* High level API to the engine that allows you to integrate the core with virtually any communication layer or even embed it.

Apache ODE 1.1 is the first official release of ODE since the project graduation from the Apache Incubator. It introduces several performance and stability improvements as well as many bug fixes.

* In-memory processes performance enhancements.
* Upgrade to Axis2 1.3 fixing several related issues.
* Better support for the BPEL processes generated by the Eclipse BPEL designer.
* Migrated our build to buildr completely (http://buildr.rubyforge.org)
* And many more…

Logo by Kelly Thompson. 

I’ve been exploring along the path of the design I’ve explained previously with DubYa: a Javascript (+HTML/CSS) client calling a local micro-server. And more specifically, the way REST resources should be handled on the server side. For those who are already wondering if I’m going to talk about REST support in Rails, the answer is no. One size doesn’t fit all (and that size didn’t fit me).

Basically, what I wanted was an easy way to make REST resources (all the different URLs if you will) accessible on the micro-server. In my case, resources are called by XmlHttpRequests, but a URL being pretty universal nowadays (as in the name), anything can use them, which is why I chose to go with a REST architecture to start with. I wanted all my mount points to be listed in a single place for easy maintenance and I wanted them to be very straightforward to read (no complex mapping). What I came up with is a simple URL to method mapping. When I want to add a new resource, I just add the proper method in the right class. But let me show you a bit more before I get into the details.

What seemed to me the most straightforward is a naming convention:

# Mounted on /playlist/queue
def playlist_queue(req, res)
song = req.path.split(“/”).last
if req.request_method == “POST”
# Do stuff
end
end
# Mounted on /producer/current
def producer_current(req, res)
if req.request_method == “GET”
# Do stuff
end
end

Here each of these method *directly* represent a REST resource, the first one responding to a POST request and the second one to a GET. As you’ve certainly noticed the first method method gets the song to queue in the playlist from the last part of the URL. So a client would call something like:

http://localhost:5151/playlist/queue/Placebo%20-%20Commercial%20for%20Levi

There are 2 things here that aren’t so elegant. First all those conditions for verb-specific methods (get, post, put, delete). Those should be part of the method in most cases and only provided as a parameter when they should be grouped. Second, the extraction of specific elements from the URL should be automatic.

So here is a second version of the methods signature:

def playlist_queue_x_post(req, res, song)
# Do stuff
end
def producer_current_get(req, res)
# Do stuff
end

The verb is now part of the method name. Note that this little scheme is actually pretty much the opposite of RPC as methods map resources and not the contrary.

I’m almost done with the implementation on WEBrick. Not that I don’t like Mongrel, it’s just that WEBrick is available with every single Ruby installation and doesn’t require any native library compilation. It makes distribution much easier. I just want to polish a couple more things and make sure I don’t hit an unexpected problem before I post the code here, but it should come very shortly. So stay tuned…

Cow shot by law keven.

Green Wombat reports that California regulators just came up with a new concept: Nega-Watts. For once it’s actually a pretty good idea: produce energy by not building power plants but reinforcing a reward-the-good-punish-the-bad policy. I’m a pretty strong believer that saving natural resources can only be achieved by heavily taxing big consumers and polluters to subsidize the well behaved and clean energy producers. The carrot and the stick.

Now the regulations is said to be a “mind-numbingly complex 212-page ruling”. That would also apply for quite a few W3C specs. Actually, WSDL 2.0 is only 188 pages (core+adjunct) but is twisted enough to kill the left side of your brain.  WS-BPEL 2.0 (which is OASIS, not W3C) is a comfortable 264 pages.

A recent article published by The Times is claiming that using your car is better for the planet than walking. This is a pretty good example of a very oriented article and pretty bad journalism, which is unfortunately very frequent with environmental issues. So let’s see what’s behind this article and how wrong it is.

The “scientific basis” is extracted from a book about lowering your carbon impact in your daily life. The original point in the book was that the livestock industry is one of the most polluting, even more than transportation. As an illustration, the author has made a simple (actually too simple) calculation trying to demonstrate that driving produces less greenhouse gas than walking because of the steaks you’re eating. Indeed an EU study has shown that the livestock industry has a very heavy environmental impact (which by the way isn’t really a surprise). But that’s very different to the orientation of the Times’ article which is roughly “we have all wrong so why bother?”.

The obvious mistake in the calculation is that the atmospheric pollution produced by a cow is calculated factoring in everything – deforestation, production of the grain needed to feed it, transportation of the meat and the world famous cow fart. For the car it’s only considering fuel, which basically means that your car and the road materialized from nowhere. But unless you personally know Harry Potter, producing a car is far from being carbon neutral.

The second obvious mistake is that I know very few people who eat exclusively meat. I don’t know how much calories come from meat in an average American diet but I would be surprised if it was more than 30%. Then you could also argue that the calories consumption on the human side is exaggerated: if you start walking 3 times a week to your grocery store, the human body will “tune” for this exercise (what a beautiful machine) and will be more and more efficient, eventually using fewer calories.

So the Times article is pretty much full of shit (cow shit that is). Like most articles of this kind they focus on one specific aspect ignoring the rest of the chain. They didn’t even bother reading the EU report that motivated this whole discussion. They mention cow gas emissions (read fart) as the main issue, whereas the EU study clearly states that the first problem is deforestation (pastures and feed crops).

And the list of “green myths shattering facts” is even more stupid:

Traditional nappies are as bad as disposables, a study by the Environment Agency found. While throwaway nappies make up 0.1 per cent of landfill waste, the cloth variety are a waste of energy, clean water and detergent

Actually this one is not too stupid. The study mentioned here is serious and independent, it has been slightly disputed but the results seem valid. My only issue here is that it’s hard to optimize the disposable chain as its a pure waste of material (unless you find a way to make virtual nappies), whereas there are plenty environmentally friendly detergents and economic washing machines.

Paper bags cause more global warming than plastic. They need much more space to store so require extra energy to transport them from manufacturers to shops

Right but plastic bags don’t degrade. So they’re going to be a space and recycling problem for loooong years. Paper degrades within days.

Diesel trains in rural Britain are more polluting than 4×4 vehicles. Douglas Alexander, when Transport Secretary, said: “If ten or fewer people travel in a Sprinter [train], it would be less environmentally damaging to give them each a Land Rover Freelander and tell them to drive”.

It’s no secret that the UK train system sucks. But I’ve heard that some countries have much better trains. And faster too.

Burning wood for fuel is better for the environment than recycling it, the Department for Environment, Food and Rural Affairs discovered.

Maybe but it wasn’t obvious to me that wood was what the recycling chain was focusing on.

Organic dairy cows are worse for the climate. They produce less milk so their methane emissions per litre are higher

Right but they feed on grass instead of grain. The production of grain needed to feed a cow is also a whole industry and an important cause of deforestation (the biggest factor in the livestock CO2 production calculation). I wouldn’t be surprised if organic wasn’t much better than the regular production chain in that respect but don’t build a blanket statement like “organic dairy is worse for climate” from an anecdotal fact.

Someone who installs a “green” light bulb undoes a year’s worth of energy-saving by buying two bags of imported veg, as so much carbon is wasted flying the food to Britain.

So don’t live in Britain, it’s a well known fact that islands are bad for the climate. Seriously, I don’t know where this data comes from, but the insinuation that economy efficient light bulbs are useless is once again plain silly. If this is true (which I doubt), it’s the supply chain that should be improved.

Trees, regarded as shields against global warming because they absorb carbon, were found by German scientists to be major producers of methane, a much more harmful greenhouse gas.

A study issued in January 2006 has shown that under certain circumstances, usually very warm temperatures (above 30C), plants could produce methane, which is a surprise. Plants were thought to never produce methane. The exact causes are still unknown and the quantities produced are still laboratory approximations (other mechanisms could influence the result in real world situation). The scientists author of this study have themselves pointed out that this effect wasn’t strong enough to affect the effectiveness of reforestation policies significantly. Moreover this production already existed far before we, humans, started affecting our environment. This is plain FUD my friends.

So to conclude, I believe there are 2 interesting lessons here:

  • Most journalistic productions about climate issues and global warming are of very poor quality, mostly because they try to build sensational headlines on subjects that are still being under study. And there’s also a clear editorial line from some publications… So unfortunately we still have to check the facts ourselves if we want to make sensible decisions and start build our own trusted sources.
  • What should really be a concern is the impact of livestock farming on the environment, provided that the majority of the earth population won’t agree to go veggie. There are several ways to do so and nobody bothered paying too much attention so far. So try to check where your meat comes from, be ready to pay more for it (cheap meat is usually produced at the expense of natural resources) and vote for people who care about environmental issues.

Thanks to Assaf for the pointer.

History

My first Javascript experience was about 7 years ago now, for what was at the time one of those Web 1.0 B2B platforms that were supposed to change the way economics work. Somehow, it didn’t. And Javascript on the web was mostly “script kiddies” work back then. Form validation, a few basic confirmations, page refresh on some events (like a changed combo). No fancy effects or asynchromous requests: a page refresh was a page refresh for the most part.

I didn’t enjoy the experience at all, it was just a lot of pain piled on top of more pain. Crazy differences between browsers, no way to debug, which could make you lose hours for a typo, inconsistencies in the language and the API. I decided to stick with server development (J2EE gave me more than needed) and stay away from this insanity. No more Javascript for me. Ever. And I think that’s pretty much what most developers who had to deal with the beast until, say, 2004 or 2005 experienced. And then came GMail.

It’s actually quite irritating to think that one single web application changed so much. Especially when it’s a Google application. But it did, the rediscovery of the XmlHttpRequest changed the game. And a lot more people started looking at Javascript (for the purists, replace all occurrences of Javascript with ECMAScript in this post). First, the browsers’ language implementations have been improved, the DOM APIs have been polished. There are now brilliant frameworks that shield you from most of the remaining issues (because there are of course) and some of the silly language idiosyncrasies. And the tooling has become pretty adequate (I fell in love with console.log). Debug it’s not quite as ubiquitous as in Java, but I that’s actually fortunate.

I’ve ignored these improvements for a little while, traumatized as I was with my first experience. I’m not of the masochistic kind. But I recently came up with a new pet project that included a lot of in-browser development and I have to say that I’m pretty happy by the current state of affairs. So happy that I’ve started wondering about the relevancy of desktop development (another area that I’ve always found hard to like).

The Cast

Let’s see what a web UI is made of:

  • Pure HTML. Just keep it simple, this is basically your model. No tables (unless you really want to display a table that is), stick with the real meaning of each element. A paragraph is a paragraph, you have divisions in your document, eventually lists of things (like in a menu).
  • CSS. That’s where all the rendering magic happens. All those properties can seem pretty obscure at first but it’s actually the best way, from far, to tell your browser how elements should look like. Compare to swing or SWT and those endless lines of setters with some AbstractFactoryFactory thrown in the middle. CSS beats that any day.
  • Javascript. As I’ve already said, Javascript in the browser has come a long way. It’s really easy now to alter your DOM model dynamically, react on events and do GET / POST behind the scene. But that’s just the start, whole applications are now written in Javascript. And fairly elegantly for that matter. The language supports closures, duck typing and is flexible enough to bring in a good deal of syntactic sugar.

Each of these technologies are more proven than most others, they’re all over the web and they’re robust. So why not making good use of them on the desktop as well? And there are several interesting side effects. Your application can all of a sudden run anywhere, no portability issue. There’s no compilation or long startup time anymore, just save, press F5 and you’re done.

There are 3 objections to that model that I can think of.

Your app is tied to a browser

Yep. So? Do you know anybody who don’t always have a browser running? I don’t. My co-workers (of course), my wife, my teenager brother, all of them are browser based. Plus there are alternatives to choose from:

  • Run directly inside the browser, the user will just open a bookmark item pointing to an html file on his machine.
  • Just open a new minimal browser window when the user starts your app.
  • If you really like standalone, use XULRunner. It’s a trimmed down version of Firefox with just the interesting parts. Open your main page on startup in there and you’re done.

A browser is an isolated environment

Inside a browser you can’t write a file or use any type of I/O, you’re isolated from the machine you’re running on. This used to be true. But things have changed and there are now two major alternatives:

  • Google Gears. These guys really are annoying but I’ve had a look at their APIs and it’s not bad at all. You get access to an embedded database, a worker thread pool for data synchronization and some resource management. For the great majority of desktop applications this is more than enough.
  • Local lightweight web server. Nowadays it’s dead simple to start a very lightweight web server that you can use to delegate all advanced I/O operations that can’t be done in the browser. Think Ruby with a small WEBrick server publishing a few RESTful operations (except that you can only GET and POST, unless you want to rule out Safari). Believe me, it’s fewer characters than this paragraph and a far smaller footprint than the browser itself.

You don’t have advanced graphics

Think again buddy (really try the second link, I like the Homer Simpson). And as with any web technology, there’s a wealth of small libraries available out there to save you some time.

Conclusion & Experimentation

That covers a really broad space of use cases for desktop applications. Of course, a few very graphically intensive applicationsDubYa screenshot would still be hard to run in a browser. But that’s a minority. And there will be fewer and fewer of them as browser performances improve. I can’t think of any reason to rely on desktop toolkits like SWT, Swing or Qt anymore, web technologies are simply better now, whatever the environment.

So I’m going to run my own little experience: I’ve decided to write a music player in the browser. I’ve dubbed it DubYa. I want to stream either from your local library (using text field based completion) or from internet radios (for now last.fm). And the destinations can also be either you local machine or an Airport Express (I like the wireless experience). Because there’s a lot of I/O involved I have a small WEBrick server doing the grunt work but all the UI is HTML/CSS/Javascript. Playlist management, completion, configuration, radio controls, everything. And so far it’s been a pretty enjoyable experience. It’s alpha software so there’s still several features missing (playlist ordering comes to mind) and rough edges but main features are already there, you can check it out if you are thick skinned.

So I’ll let you know how this goes and we’ll see how good the browser does on the desktop. Now I have code to write.

P.S. I’m a really bad designer, so if someone feels like designing a music player UI, let me know.

Follow

Get every new post delivered to your Inbox.