Alex Pooley's Blog

Race conditions squished, required features complete. msgpad is ready for more beta members! Well, _almost_. I need to switch web host, Dreamhost is just too unreliable for Ruby On Rails hosting. They have this daemon that comes along every few hours and nukes lingering processes. It’s a shame that the FastCGI processes that serve my pages are lingering processes. Apparantly they handle FastCGI differently. It’s pretty clear that something isn’t right though. Every 24 hours or so, when my system seizes up, I have to kill these processes, and everything is fine again. Sup wit dat?

Anyway, I’m tired of debugging the hosting issues, that’s why I pay the hosting company. Granted, I only paid Dreamhost $20 for my first year. I’m going to give “Site5″:http://www.site5.com a go.

Further to the technology stew “spoken of previously”:http://alexpooley.com/articles/2006/05/25/web-stew I would like to propose a side dish. Asynchronous calls, network latency, and unpredictable bouts of keyboarding bashing from users can lead to… *race conditions*.

Far out, as if I don’t have enough to contend with. Those of you familiar with race conditions know debugging the bastards requires a combination of voodoo and luck. So, if you don’t have a witch doctor handy (and why wouldn’t you?), I hope you have a lepricorn, rabbits foot, or maybe a rainbow by your side. Race conditions arise when multiple threads of logic interweave with one another in unpredictable ways. Sometimes this is OK, like when the logic is accessing mutually exclusive ’stuff’. But, when you have multiple threads accessing the same ‘thing’ sometimes you never know who’s going to get there first and that can be a problem.

A race condition is like two vehicles racing toward the same unmarked cross road. In geek talk the cross road is known as the critical section. The trick is to control the flow between the critical section so you don’t blow stuff up. The problem with race conditions in programming is finding the critical section. It’s not always obvious.

I’m beginning to become very irritated with the low-tech developments methods we’re stuck with for web development.

The problem is that the view portion of web applications are applications in themselves. They also follow the MVC pattern inside the applications MVC pattern. Each view ‘thing’ has data, view (css, html), and control (javascript). We’ve gone and complicated everything by throwing other programming languages in to the stew - PHP, Ruby, ASP, Java. So when you go to create a view of your site you need to hang the following technologies together *somehow*:
* XHTML
* CSS
* Javascript
* Ruby (or your language of choice)

Let me get this straight, by weaving Ruby with all the other technologies we have _increased_ the complexity. The solution? Ruby needs to replace, and not merely complement the other technologies. Here’s an idea… replace Javascript and XHTML with Ruby. So then you have:
* CSS
* Ruby

Beautiful! That’s _two_ less things to think about while coding. OK, is it possible? Yes. You will need to weave HTML and Javascript behind Ruby, but that’s the point!

Here’s an example of what I’m after.

p1 = p {’This is placeholder one’}
p2 = p {’This is placeholder two’}
p2.hide
link do
p1.toggle_visibility
p2.toggle_visibility
end
link.value = ‘toggle’

This turns in to something like

This is placeholder one

This is placeholder two

toggle

That’s a big difference in my opinion.

Note how you will have to programmatically assign HTML ID’s to elements that are referenced. This would then bind the HTML and Javascript.