Article RSS Feed

Hotrod Hayride

Mon, 01 Aug 2011 00:00:00 GMT

Wall of Death

Most Rated

Thu, 28 Jul 2011 00:00:00 GMT

Check out MostRated.com

ActionView date_select calendar logic in javascript

Fri, 24 Jun 2011 00:00:00 GMT

ActionView date_select calendar logic in javascript

Here's the Gist

document.observe("dom:loaded", function() {
  var DAYS_IN_MONTH = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];
  var dateEl = $('project_expiry_date_3i');
  var monthEl = $('project_expiry_date_2i');
  var yearEl = $('project_expiry_date_1i');
  if (dateEl && monthEl && yearEl) {
    var currentDateIndex = dateEl.selectedIndex;
    function leapYearAdjustedDays() {
      var daysInMonth = DAYS_IN_MONTH[monthEl.selectedIndex];
      // Leap year calc.
      var year = parseInt(yearEl.options[yearEl.selectedIndex].value);
      if (monthEl.selectedIndex == 1 && year % 4 == 0) daysInMonth = 29;
      return daysInMonth;
    }
    function adjustDays() {
      dateEl.options.length = 0;
      for (var idx = 1; idx <= leapYearAdjustedDays(); idx++) { 
        if (currentDateIndex == idx-1)
          dateEl.options[idx-1] = new Option(idx,idx,false,true);
        else       
          dateEl.options[idx-1] = new Option(idx);
      }
    }
    monthEl.observe("change", adjustDays);
    yearEl.observe("change", adjustDays);
  }
})

Javascript bitwise encoding

Fri, 17 Jun 2011 00:00:00 GMT

Here's a quick sample of how to do bitwise encoding in javascript:

var Encryption = (function() {
function generateKey(seed) {
var key = ""
while (key.length < seed) key += Math.srand(seed)
return key
}
/*
* @param 'val' - a String to encode or a byte[] to decode.
* @param 'salt' - (Optional) salt to perform bitwise encode/decode operation.
*/
function xorHash(val, salt) {
var encrypt = typeof val == 'string'
var byteArr = encrypt ? val.toByteArr() : val
var keyBytes = typeof salt == 'undefined' ?
generateKey(byteArr.length).toByteArr() : salt.toByteArr()
for (var i = 0; i < byteArr.length; i++) {
byteArr[i] = byteArr[i] ^ keyBytes[i % keyBytes.length]
}
return (encrypt ? byteArr : String.fromCharCode.apply(String, byteArr))
}
return {
/**
*
*/
encode : function(str, salt) {
var encoded = []
var bytes = xorHash(str, salt)
for (var i = 0; i < bytes.length; i++) encoded.push(bytes[i].toString(16))
return encoded.join(",")
},
/**
*
*/
decode : function(hsh, salt) {
var decoded = []
var hshArr = hsh.split(",")
for (var i = 0; i < hshArr.length; i++) decoded.push(parseInt(hshArr[i], 16))
return xorHash(decoded, salt)
}
}
})()
Math.srand = function(seed) {
if (!seed) seed = new Date().getTime()
seed = (seed*9301+49297) % 233280
return seed/(233280.0)
}
String.prototype.toByteArr = function() {
var arr = []
for (var i = 0;i < this.length; i++) arr.push(this.charCodeAt(i))
return arr
}

Independent Stove Installations

Sat, 19 Feb 2011 00:00:00 GMT

Independent Stove Installations

A good friend of mine from Bristol has trained as a HETAS engineer which means he is able to install wood burning and multi fuel stoves to the required legal standard for UK building regulations.

With heating costs climbing and bitter winter weather it's a shrewd move training in this field, plus there's nothing like a good fire.

Naturally every business needs a website and that's where I come in, I put together Independent Stove Installations another Heroku & Radiant website.

I've used the Radiant gallery extension to show the various installations ISI have completed.

RubyProf, Oink and ActiveRecord bloat

Fri, 03 Dec 2010 03:26:54 GMT

RubyProf, Oink and ActiveRecord bloat

Posted by Steve on December 03, 2010|Comments

There are some applications that are always gonna hammer the OS, I'm not talking about your common-or-garden web app, think huge amounts of I/O in the shape of huge file uploads, image processing, iso creation, hungry hungry hungry.

So what to do when you see ruby processes (spawned from passenger) gobbling up 1gb of RAM? The app was already in production so we had to be careful in our approach to profiling and code changes. Time to grab the production db and associated file data and see if the problem could be reproduced locally.

I'd say this is the hard part of profiling, where to start looking in a fairly large in-production app? A bit f common sense helped here, we knew that there were some expensive processes mainly dealing with large amounts of image processing and large amounts of copying files. My very experienced colleague pointed me at this article detailing common mistakes made when developing with active record.

So a quick search through the codebase for all.each and find(:all as mentioned in the article lit up some hotspots in the app code where potentially we could be experiencing bloat.

Next step was to wrap these code blocks in a ruby profiler block as detailed here then make the app execute the profiled code block - no changes to the code yet - this is just to get a benchmark.

Now we made a small but apparently very important change removing a programmatic filter on a large collection (one of those all.each... buggers) and swapped in a more precise active record find with conditions and some outer joins to get us the desired collection. The app was restarted and the same test run again leaving the profiling block in place and bingo processing time was one sixth of the previous run, big improvement in changing 4 lines of code.

But all this was done in a local production copy, we needed verification of what was causing bloat in production, adding profiling to production was a risk we couldn't take but what we did do was add and configure the oink gem which gave us a memory stat in the production logs and after a few hours of normal app use the ability to do $ oink -t 50 log/production.log which gives the insightful output:

---- MEMORY THRESHOLD ----
THRESHOLD: 50 MB

-- SUMMARY --
Worst Requests:
1. Dec 02 11:11:08, 143136 KB, BarController#foo

so verification of the bloat as this method was executing the all.each mentioned above. All the evidence was converging on this point in code. Marvellous!

I had never profiled a Rails app before admittedly this was not your average app but the tools used here definitely took us from hunches and presuppositions to good solid evidence and the beginnings of some simple but effective performance refactorings.

Hope it helps you when your 400lb Gorilla app starts playing up.

blog comments powered by Disqus

Fun fun fun fun fun

Wed, 24 Nov 2010 07:07:25 GMT

Fun fun fun fun fun

Posted by Steve on November 24, 2010|Comments

Say what you like about the tories, they know how to get the kids rioting...

blog comments powered by Disqus

Ruby 1.9 String encoding shitfest

Thu, 16 Sep 2010 08:56:32 GMT

There are countless posts out there, screams in the darkness by developers claiming that this gem doesn't work with that web framework using Ruby 1.9

In my case the problematic layers in the technology stack were Padrino 0.9.14 with Sinatra-1.0 and Typhoeus 0.1.31 plus some other String to byte array conversions in our codebase.

Testing had showed that when the app received input containing umlauts and other accented letters (i.e. multi byte characters) it failed. There are some lengthy and detailed explanations and discussions about how Ruby 1.8 handles character encoding differently from Ruby 1.9. The sort of thing I'd hoped I'd never have to read but some times you just have to get informed. Hopefully this article will help shortcut or reiterate some of this info.

So lets begin with the rendered view of your web app, a couple of things will help ease the pain here.

First make sure all your pages contain the correct content-type meta tag:

Secondly make sure that all your forms use the accept-charset attribute in the html form tag or whatever you use to generate the tag:

<form accept-charset="utf-8"...

now we know that the pages can display and post multi byte UTF-8 characters, the web application might be a different story...

One of the next quick fixes to apply which worked well for me was to apply a filter on all requests which forced the encoding of all incoming String params.

A branch of RKH's fork of Sinatra helped with this, there's a utility method in lib/sinatra/base.rb which does the trick...

if defined? Encoding

if Encoding.default_external.to_s =~ /^ASCII/

Encoding.default_external = "UTF-8"

end

Encoding.default_internal ||= Encoding.default_external

def force_encoding(data)

return if data == self

if data.respond_to? :force_encoding

data.force_encoding(Encoding.default_external)

elsif data.respond_to? :each_value

data.each_value { |v| force_encoding(v) }

elsif data.respond_to? :each

data.each { |v| force_encoding(v) }

end

else

def force_encoding(*) end

end

to work with this we need to set some default encodings for our webapp.

In Padrino this can be done in the app.rb file:

if RUBY_VERSION < '1.9'

$KCODE = 'u'

else

Encoding.default_external = Encoding::UTF_8

Encoding.default_internal = Encoding::UTF_8

end

if you are a padrino user who doesn't wanna touch the Sinatra gem you can create a general before filter in app.rb like this

before do

force_encoding(params)

end

there are likely other parts of your application stack that will not be UTF-8 friendly, noteably your tests might complain if you attempt to add multi byte characters to your test data.

Adding the code hint

# encoding: utf-8

to the first line of the test class files will alleviate this, it's a grubby fix but we live in a world of compromises, what can you do.

blog comments powered by Disqus

None Meaner...

Wed, 28 Jul 2010 03:07:18 GMT

The Flaming Wall of Death...

blog comments powered by Disqus

Brown Sauce for life

Mon, 26 Jul 2010 04:18:27 GMT

First up install Radiant...

$ gem install radiant

and you'll also need the heroku gem...

$ gem install heroku

you might need to install a few dependencies for radiant to work notably some cucumber versions won't play ball, mine seemed happy straight off. So create a radiant app...

$ radiant oohsaucy

$ cd oohsaucy

Assuming you have git installed on your system

$ git init

$ git add .

$ git commit -m "The all new Ooh Saucy app"

Now time to do some Heroku magic

$ heroku create

$ git remote add heroku git@heroku.com:oohsaucy.git

so now we have version control hooked up to Heroku's repo we can start developing the app.

First thing is to configure gems so that when we push to Heroku it knows our app's dependencies...

$ vi .gems

and add the lines

rails -v=2.3.5

radiant

save the file

$ git add .gems

$ git commit -m "Gem dependencies for Heroku deployment"

now do your thing with the application locally and when you are ready to hit the big red launch button...

$ git push heroku master

and because it's a radiant app we need to bootstrap the production db

$ heroku rake db:create:all

$ heroku rake db:migrate

$ heroku rake production db:bootstrap

now you might want to seed a bit of data you set up in development (no doubt some people will frown at this, frown away, this is about expedient development not chin scratching theory).

$ heroku db:push

this exports your local db to heroku's production db.

You're done. Heroku will give you back the url your app is deployed to in the console so you can configure your domain name DNS accordingly.