export ARCHFLAGS="-arch i386 -arch x86_64" ; gem install --no-rdoc --no-ri mysql -- --with-mysql-dir=/opt/local/lib/mysql5 --with-mysql-config=/opt/local/lib/mysql5/bin/mysql_config
Juratind Summit Ridge, Romsdalen
In my continuing quest for not being as slow to pack for weekends away I have included a packing list for a weekend ski touring trip.
In Need of Love and Care
I have written a number of rails applications over the past few years. While new projects are using rails 2.3 I have a number of older applications which I should have upgraded before but havent. Anyway, here is some little notes to take into account when upgrading to rails 2.3. Then from here you are placed well for the upcoming release of rails 3.
ActionController::Base.session = { :key => '_session_name', :secret => 'd00cda5710eab8sdfsdf6c5fe165780074fa5027f50168a0bd0ae2832c05bb4f804a07228b220b67e' }
In an initializer instead of environment.rb (some plugins access the session in a different manner.)
Drew packing away.
I am really slow at packing. In an attempt to reduce the time spent here is a list of stuff I took to Verbier.
Verbier is a ski resort in the Valais region of Switzerland. It is known for its extreme offpiste and lively apres ski.
Verbier Piste Map (click for full version)
There is a lot of terrain on offer and we only managed to scratch the surface in the week that we rode there. It would take a few seasons before you could really become familiar with this ski area.
Note: If you are riding / skiing off-piste you do so at your own risk and should be using the necessary safety equipment and know how to use it.
If it is snowing and visibility is bad head to Bruson. This little area which is accessible by bus will show you a good time in the trees.
Picking a route
Virgin lines above the trees.
If the snow conditions are good you can ride from Bruson to Le Chable.
When the snow is good head to the controlled off-piste runs. These give an off-piste experience with some avalanche control and preparation. Vallon d’Arbi and the Col des Mines offer some great riding. Watch out for the long ski out for the Vallon d Arbi.
Riders after the storm
roof drop
Higher up there is the genitals run which has a lot of nice varied terrain and a lot of vertical. There is the Mont Gelé cable car which takes you to the top of Mont Gele. From here there is only off-piste runs! The front side is relatively fierce with the back side offering a slightly easier route with the beginning being the most technical.
The highest lift in the resort is the Mont Fort cable car. This run takes you on a glacier so be careful to watch out for crevasses if you are venturing off piste. The snow here can be very, very lush.
For a day trip head to the top of the left Tbar which takes you to Greppon Blanc and there is a long offpiste run which takes you to a road at the edge of the 4 vallees ski area. There is a caravan here which sells tasty food and snacks. From here you can get a free bus to les masses then spend a chunk of the day getting back to Verbier. Nice open bowls followed by tight tree runs.
If you have a group of 6 or more I would recommend getting an apartment in Verbier village. You will have easy access to the lift system and to the afterski. The afterski access may or may not be a good thing ;-P
If you are on a budget then you can, like we did, stay in the village of Le Chable below Verbier in the valley. It is linked to the Verbier by a Gondola which stays open to 1830. We stayed in a ghetto hostel called Le Stop . The owner is friendly and it is in a old bomb shelter with 3 a piece bunk beds. The breakfast is relatively good and worth paying for. There is no luxury here however, it is cheap but also pretty extreme with no kitchen etc. Take your own stove!
Chillin at le stop
Pub Mont Fort and Farinet are the best places to go for apres ski. Pub Mont Fort also livens up later at night as well with a couple of happy hours happening, one and 4pm and one at 10pm where beers are half price.
We were to focused on skiing to go out clubbing!
If you hit it right this is one of the best places to ride in the world. 10/10.
On the pistes for once.
Roof drop
Boulder drop
The Crew
Summiting at Dusk
Outdoor equipment of some kind is a pre-requisite for doing most outdoor activities. Jackets, bags, bottoms, shoes, gloves, hats, skis, crampons, ice axes, bikes, ropes, wax, tents, stoves, sleeping bags, pans, food, maps and wetsuits to name but a few.
It is easy to let all this equipment get out of control, spend too much packing for a weekend away, take far too much equipment or replace equipment that doesn’t need replaced.
This is where making and mending comes in. Here are a few core elements to this philosophy.
Making and mending is best done when there is unavoidable downtime. Snowed in and got nothing to do for 12 hours? Pap on the telly? Do a bit of making and mending.
Got any making and mending experiences?
Performance tools are a great help for testing your web application deployment setup. They not only let you judge how the performance of the application is but also catch errors. Nobody wants a web application which starts to spit out errors when put under load or worse, randomly!
HTTPERF is a gift from HP which is my favourite tool at the moment.
An example httperf usage is:
httperf --num-conns=800 --rate=80 --timeout=5 --server=google.com --port=80 --uri=/
This hits the google homepage with 80 requests per second for 800 requests in total. This test will run for circa 10 seconds.
Results are as follows:
Total: connections 800 requests 800 replies 800 test-duration 10.252 s Connection rate: 78.0 conn/s (12.8 ms/conn, <=25 concurrent connections) Connection time [ms]: min 140.1 avg 237.1 max 771.7 median 240.5 stddev 40.5 Connection time [ms]: connect 111.2 Connection length [replies/conn]: 1.000 Request rate: 78.0 req/s (12.8 ms/req) Request size [B]: 63.0 Reply rate [replies/s]: min 76.2 avg 77.9 max 79.6 stddev 2.4 (2 samples) Reply time [ms]: response 125.9 transfer 0.0 Reply size [B]: header 280.0 content 219.0 footer 0.0 (total 499.0) Reply status: 1xx=0 2xx=0 3xx=800 4xx=0 5xx=0 CPU time [s]: user 0.51 system 9.64 (user 5.0% system 94.1% total 99.0%) Net I/O: 42.8 KB/s (0.4*10^6 bps) Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0 Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
This line below is important:
Reply rate [replies/s]: min 76.2 avg 77.9 max 79.6 stddev 2.4 (2 samples)
It tells us that the avg requests per second is 77.9. There is a low standard deviation, which is good. If you have a high stddev you should be worried. Lastly, it has calculated this using 2 samples. You can increase the number of samples by increasing the num-conns, which will give you a more reliable dataset.
Watch out for the errors:
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0 Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
Looking good, google is performing well on the error front. Obviously google.com handles more than 80 req/s! Now go away and performance test some of your sites!
There is some valuable further watching to be had. Episodes 15 and 16 mention httperf.
I have been keen to get my hands dirty with ExtJS, so jumped at the chance to make a christmas card list application which can print the list to labels; to stick on envelopes.
I have finally become mature enough to have a christmas card list along with my girlfriend, which is useful for keeping track of friends both in Trondheim and the United Kingdom.
To get it up and running on heroku it is pretty swift –
git clone git://github.com/pyrat/christmas-card-labels.git cd christmas-card-labels sudo gem install heroku heroku create git push heroku master heroku rake db:migrate
You are now good to go, you may need to tweak the css (labels.css) to match your specific labels which can be a painful experience.
Default username / password is god / jul which is norwegian for merry christmas!
There is a demo version online
Maybe not that ‘wicked’ but was fun running with the Reindeer last weekend. After the film was taken they got a bit angry and stopped running. I then retreated.
In todays environment of Rich Internet Applications we rely heavily on Javascript. Often this javascript is in the form of a javascript framework. These typically enhance vanilla javascript and allow you to accomplish tasks with a nice syntax and more importantly abstract the differences in browser implementation.
Despite all the positives the main negative of javascript frameworks is the browser overhead when they are downloaded. Often the size of these assets can add up to a few hundred kilobytes. Coupled with the fact that they are normally split into a number of files (increases HTTP Overhead) this has the effect of decreasing the quality of the user experience while they wait for these files to load when loading your site.
There are a number of ways to increase client side performance specifically with javascript assets.
Combining assets into single files is the best bet here. Prototype and Scriptaculous take up five or so separate uncompressed files. Decreasing HTTP overhead is one of the biggest time savers.
This involves telling browsers that they can cache a file for a time in the future. This is known as the expires header. Mod_expires is a way to achieve this with Apache. It is common to append a timestamp to the url eg.
/javascripts/defaults.js?343423434342
A technique which is applied by rails is that this number value is infact the last modified timestamp from the file so you can then set a long expires on this (maximum possible) as changing the default.js file will alter the file, change the timestamp and generate a new unique URL which can be recached.
Another big timesaver for big assets. This actually zips up the asset before pumping it down the pipe. You can configure this in your nginx configuration or use mod_deflate if you are on apache.
This area still developing, the main players at the moment at the YUI Compressor developed by Yahoo and the Closure Compiler developed by Google.
I use a basic prototype / scriptaculous framework for oentries so have used this for a little battle between the compressors.
Compilation commands are as follows for reference.
YUI
java -jar /path/to/yuicompressor-2.4.2.jar --type js -o defaults.yui.js defaults.js
Closure (Standard mode)
java -jar /path/to/compiler.jar --js defaults.js --js_output_file defaults.google.js
Closure (Advanced Optimizations Mode)
java -jar /path/to/compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS --js defaults.js --js_output_file defaults.google-advanced.js
NOTE: You need to be running Java 6 to use the closure compiler.
This experiment was performed on a 1Gb Ubuntu Hardy Heron VPS Slice.
Comparison of Compression (Kb)
YUI and Google Closure standard mode produce a similar result circa 60% of the original size. However closure with advanced optimisations leads the way at 43% of the original size!
There is however a BUT. The advanced optimisations mode actually removed methods which are not called! Have a look at these docs
In a standard RIA you will often call functions from inline HTML (onclick events) etc. This makes this form of aggressive optimisation too much for standard applications. You could however remove all javascript calls from HTML and so it all unobtrusively as it standard practice in JQuery.
Comparison of Compression Time (Seconds)
YUI is substantially faster than google closure at JS compression. If you were to add this into your deployment strategy this gives YUI the advantage.
Whilst it looks like closure is a better compressor, I just don’t think it is safe to be this aggressive with compression for production environments.
If you then run closure on standard mode, the differences in compression vs YUI are minimal. With the speed advantage of YUI, I would definitely pick YUI. YUI has the other big advantage in that it can compress CSS as well.
Has anyone had any experience with Javascript Compressors? Comment if you do.
I hope this has given an insight into the wonderful world of speeding up the delivery of your javascript assets. Now get out there and compress!
