Art of Programming

KnockoutJS Validations Screencast

2011-12-22T20:31:00.002+11:00

If you wonder how you can use KnockoutJS with Rails in a similar way to Backbone.js or Spine.js then watch the video. It also shows how easy it is to apply client side validations that work alongsite with the server-side validations.

Have a look at the knockout-rails project for more details.

Issues switching to JRuby from MRI 1.9

2011-11-29T11:51:00.001+11:00

UDPATE: The reason for switching to JRuby the native neo4j API. Have to use REST API with MRI.

This is just a quick recap of what issues I have had trying to switch existing app from MRI Ruby (1.9.3) to JRuby (1.6.4).

Unfortunately I stepped back and didn't want to spend more time as it felt an unbreakable chain of issues. Resolving one, you think "huh, awesome". But very soon you hit the next.
And I couldn't see it stopping.

But PLEASE bear in mind that I only spent a couple of hours on that. With a little bit more persistence, you may be able to the end of the tunnel.

The overall impression is that it is not a big deal really. The problems arise when trying to use other libraries. And unfortunately, not all of the gems care deep enough to support JRuby. And this is the biggest issue in my opinion, there are very little issues with JRuby itself. The transition (from the syntax perspective) was extremely easy.

The application is pretty standard Rails 3.1 app that uses gems like Dragonfly, inherited_resources, cancan, paper_trail, Authlogic, CoffeeScript, Haml, Sass, Formtastic etc. For testing - things like rspec-rails, cucumber-rails, capybara-webkit, guard (rspec and cucumber), database_cleaner etc.

So here is a quick list of the things that I faced on my way.

Before everything else I enabled support for 1.9 syntax in JRuby (export JRUBY_OPTS=--1.9).

It all first started with the weird issue where the wrong arguments were passed to RSpec shared example.
Unfortunately I did not figure out why it happened and just patched it as you can see in the comments there.

After fixing this issue I had another one related to database_cleaner. So I ended up with a pull request that worked for me.

The other issue was a huge stack trace. I scrolled 3 pages in the terminal to get to the top. Most of that stack trace is deep inside Java. Additionally I got wrong line number on exception. This "features/step_definitions/company_steps.rb:234" makes me thing that the exception is at line 234. But that file only had 49 lines of code. Now, go figure.

Going on... SimpleCov gem didn't work out of the box and gave the warning that I need to enable debugging. That's fine and understandable. But after half an hour of debugging of unrelated exception, it turned out that SimpleCove threw an exception because of that. So had to go and explicitly disable it.

Then I managed to run all of my specs. But I was pretty surprised how slow it was:


# rvm use 1.9.3
# time rspec # real=14s, rspec time ~ 12s

# rvm use jruby
# time rspec # real=52s, rspec time ~ 30s

But this is expected as JRuby doesn't have enough time to optimise here. It should be much better in production. But it will be also shit slow after deployment.
Ok. That's fine. I can trust it's fast.

Then I tried running the cucumber specs and had to file the issue to support new Ruby 1.9.3 syntax (a = b = f 1). Not a big deal, easily fixed with parens: a = b = f(1).

Next and the final issue - I could not run the headless cucumber specs (capybara-webkit). It just got stuck (no CPU used) and feels like there is a dead-lock or something similar.

I couldn't see way of fixing it easily and decided that for now I am done with it. So going back to Ruby 1.9.3.

To summarise, I did not feel like it's a problem to switch to JRuby. But it's really a big deal to actually use it due to the number of C extensions that JRuby doesn't really support.

Again, to emphasise, there is nothing horribly wrong with JRuby and it seems to be pretty good. But the real showstoppers are the C extensions.

Rails Plugin with Tested Assets Screencast

2011-11-19T20:47:00.000+11:00

Some of the most valuable things you can learn are not written in books, not shown in the presentations and demos. Those come from seeing how others work.

How do they do all those small things? What tricks do they have? How would they approach that problem?

Unfortunately, I can't remember seeing people sharing the way they actually work (unless they pair). I want to see what mistakes they make, how they fix those, how they try to come up with a word erasing a line 10 times.
I believe all this is of a great value for a lot of us.

What I described is partially done by PeepCode's Play By Play series and Tekpub. Those are amazing (usually). But that's not exactly what I am after. Those screencasts are high quality, polished and prepared ones. YOU are NOT featuring there. I want to see YOU there. All of you, guys.

So I decided to make a first step (or maybe not so) and screencast myself while working on a Rails Plugin.

This is mostly real-time work. You'll see how I fail, you'll spot the mistakes I've done and did not even notice, you'll see how I write README. And, most importantly, you will hopefully see some of the things that will help yourself.

This video features the following tools/technologies:

Ruby, Ruby On Rails
CoffeeScript
SASS
Git, Github
Vim (MacVim and Terminal)
Jasmine and basic testing of JavaScript and even CSS assets
etc

Additionally, before watching, make sure you Turn On the Volume. Rare person doesn't like the music that my wife helped me prepare. Even if you don't not like the video, you should like the music :)

I hope you enjoy it. UPDATE: Please watch it in full screen as the quality is lower than I expected.

P.S.: Screencasting is really hard. And that's my first. So apologies if something isn't in-place.

(If you can't see the video here, open it on Vimeo. Alternatively, try YouTube - it should work with HTML5-only browser).

Use your Terminal like a Pro

2011-10-04T12:53:00.000+11:00

Keep your config in a separate dotfiles directory and under source control with the structure like:


~/dotfiles:
--+ bashrc, bash_profile
--+ ssh/config
-->--bash -> (env, config, aliases). bash has source bach/env, bash/config etc.

Then:
ln -s ~/.bashrc ~/bin/dotfiles
echo ". ~/.bashrc" > ~/.bash_profile

Put everything into .bashrc except any long running tasks.
.bash_profile - for interactive shells. But you can just usually source .bashrc.
Now some keyboard shortcuts:

Cntrl-a - go to the beginning of line
Cntrl-e - go to the end of line
Cntrl-k - delete everything to the right
Cntrl-w - delete previous word
ESC->-b - go back one word
ESC->-f - go forward one word

If you often connect via SSH like so: ssh -p 2323 username@my-server.example.com Then you can shorten it to ssh my-server if you will add entry to ~/.ssh/config:


Host my-server
    HostName my-server.example.com
    Port 2323
    User username

Then you can use it as:


# Tunnelling
ssh -L7997:127.0.0.1:7979 my-server

# Copy folder to server
scp my_folder my-server:my_other_folder/

# Or even use it with git
git clone my-server:repo-name.git

Now some useful things you can do in the terminal:

!! - run previously executed command (you can do `sudo !!` for example)
!$ - last argument of previous command
!60 - run the command #60. Number comes from history command

tail file.log

cat !$

cat file.log

!echo - rerun last command starting with echo
Ctrl-r - interactive search on history of commands; Use Ctrl-j to abandon.
!?file.log?! - run the last matching command (not interactive)
^file.log^another-file.log - run the last matching command replacing file.log with another-file.log
!?file.log?! - run the last matching command (not interactive)
mv README.{txt,markdown} - same as mv README.txt README.markdown.

You will also appreciate power of the shell when using aliases and functions:


alias ss="./script/server"
alias s="git status"
alias gca="git commit -am"
alias zipr="zip -r"

function take {
  mkdir $1
  cd $1
}
# take create-and-go-here

function gg() {
  git commit -v -a -m "$*"
}
# gg Commit message with no quotes

But when functions get more complicated, you might want to use a scripting language (Ruby, Python etc).
Put those scripts into your ~/bin directory and add it to your PATH variable.

There are also number of Mac specific tricks.
One is is open anything command that will open the file/directory in the default application.
You can also force it to use a specific app: open -a /Applications/Firefox.app index.html.
This one becomes a good candiate for an alias.

You can also pipe output of any command into pbcopy command to copy it to the clipboard.
For example: cat index.html | pbcopy will copy the content of the file into clipboard.

You can also do it the other way around: pbpaste > index.html or pbpaste | grep "jquery".

Another useful thing OpenTerminal (drag the app to finder toolbar). It allows you to open terminal with the current directory set to the Finder window.

You can also use the keyboard to open terminal using LaunchBar. It does much more though. It acts like a global terminal for the system.

You can also try to use zsh shell. It will work with the existing bash aliases just fine.

Most of the tips here come from the PeepCode's Advanced Command Line screencast.
Hope this helps you on your way to becoming a Terminal Guru.

Templating done easy - JavaScript HAML with Rails

2011-08-19T19:26:00.000+10:00

HAML templating with no worries: native, precompiled HAML. Blazing fast and as easy to use as it can be.

UPDATE: this functionality moved into ruby-haml-js gem, please use it instead.

Recently I have been working on a Ruby gem that packs a set of common JavaScript libraries in one place so you can just reference those easily from Rails 3.1 app. But now I want to write a bit about a very handy tool that the gem includes. I needed to work on a Backbone app and, unfortunately, there was no very simple and easy way of using HAML markup for my client side templates. Main problems:

I don't want to embed the template into the document.
The Underscore.js templating is ok, but it is too verbose for me (as most of others).
The haml-js is great, but I do not want to bother precompiling the templates.
I do not want to think about templating as another layer or component. I want it to just work.

Fortunately it was pretty easy solve these problems with the Sprockets and Rails 3.1.

So from now on you can just write normal HAML templates and consume those with no worries from JavaScript.

All you need to do, is to add pakunok gem to your Rails 3.1 Gemfile. This will give you templates as native JavaScript functions that you can use.

It's better to see than hear

Feel free to head to the issues and provide some feedback or read more.

Easy Rails deployment with Capistrano and custom Nginx configs

2011-05-19T00:58:00.000+10:00

In my previous post I provided some info about setting up the server for rails app.

Now I am going to describe the Nginx configuration and example of Capistrano deployment file.

One thing that I don't want to do for every new app I deploy is to go to the web server and change the settings (as a root user) so that the web server picks the Rails application.

In order to avoid that I decided to use nginx's include command. It allows to add include multiple nginx config files using UNIX wildcards.

So by simply adding this line to the nginx.config I make it possible to configure Nginx from Rails applicatoins themselves: include /home/*/apps/*/current/nginx.conf;. I decided to include all configs within http tag so that a Rails app can configure multiple servers for itself.

There are obvious drawbacks for this:

It is less "safe" as on application might affect others if you will start adding Nginx settings outside of the server tag. But I am ready to sacrifice this for the sake of having more flexibility by assuming all server citizens are good guys.
We still need to have root access to restart the Nginx. We shouldn't need to do it often, so that's ok with me.

Now relying on a very simple conventions, I can configure Nginx from within the app. Just in case you've missed it, the conventions are:

To deploy a rails app (and any Rack based app), user should put the app under his home directory in apps/[name]/current.
To "enable" an app, user should put nginx.conf file in apps/[name]/current.

But for now, all this cool structure isn't very helpful unless we deploy the app.

I went with the Ruby de-facto deployment tool - Capistrano. There are enough resources on the net on how to "Capify" your application, so I won't go into details. I assume you have just done capify . and understand what is going in there.

Briefly, what I need to do is following:

Deploy the app explicitly to a particular domain (staging, production, local server etc).
On every deployment - backup SQLite database (I know, I'll use something better when I'll have 1 million users).
Prepare Nginx config file for the server (it depends on the domain we deploy at).
Pre-Compile assets (SCSS in my case).

So grab the gist (embedded below) with all the details and let me know what can be improved there. The usage is pretty simple:

cap deploy user=dnagir domain=connecty.approache.com
You can deploy the same app multiple times to the same server with different subdomains and they will not conflict:
cap deploy user=dnagir domain=staging.connecty.approache.com
cap deploy user=dnagir domain=demo.connecty.approache.com

The most interesting I think is that the nginx.conf file is created during deployment using default Ruby templating engine and transfered over to the right location on the server. (But still remember root-ed Nginx restart is still required).

You can look at the complete source in the Connecty project at Github.

Please feel free to tell me what you think about this process.

Setting up Ubuntu 11.04 server for Rails with RVM

2011-05-19T00:09:00.001+10:00

I had to set up the server (Ubuntu 11.04) for running couple of Rails apps and thought I could share the notes I've written while doing that. Any feedback and improvements are welcome.

apt-get update ; apt-get upgrade

# set timezone
dpkg-reconfigure tzdata


# RVM
bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

# update /etc/bash.bashrc


# -y to answer YES for questions
aptitude -y install build-essential bison openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev

rvm install 1.9.2; rvm use 1.9.2 --default

# while ruby is being installed prepare nginx
cd /usr/src
wget http://nginx.org/download/nginx-1.0.0.tar.gz
tar -xf nginx-1.0.0.tar.gz
cd nginx-1.0.0

# Use one place for installation
rm -r /opt/ && ln -fs /usr/local /opt

gem update --system ; gem update
gem install bundler
#install imagemagic
apt-get -y install imagemagick

# proceed with passenger
apt-get -y install libcurl4-openssl-dev
gem install passenger
passenger-install-nginx-module
# additional otions:
# --prefix=/opt/nginx
# --with-http_gzip_static_module --with-http_stub_status_module --with-http_sub_module


# add nginx autostart script: http://wiki.nginx.org/Nginx-init-ubuntu
# verify the correct paths
cd /opt && \
wget -O init-deb.sh http://library.linode.com/assets/602-init-deb.sh && \
mv /opt/init-deb.sh /etc/init.d/nginx && \
chmod +x /etc/init.d/nginx && \
/usr/sbin/update-rc.d -f nginx defaults


# add to /opt/nginx/conf/nginx.conf
include /home/*/apps/*/current/nginx.conf;
/etc/init.d/nginx restart



# copy ssh keys (from local computer)
cat ~/.ssh/id_rsa.pub | ssh root@my.server.com "mkdir ~/.ssh ; cat - >> ~/.ssh/authorized_keys"

# change default ssh port from 22 to something to get rid of nasty attacks
vim /etc/ssh/sshd_config # change the port number
service ssh reload

#install firewall?? No need for now as only openning 80,443 ports
# apt-get install ufw

That should be enough for you to start using the server. In the future post I plan to describe my setup to make deploying new applications easier.

Unix - do not reinvent the wheel

2011-05-19T00:00:00.000+10:00

One of the most interesting videos I watched from the Scottish RubyConf 2010 is Unix: Rediscovering the wheel. If you use Ruby/Rails and POSIX systems you gotta know those things. This is just a quick list of notes to keep it mind. So you will have to Google if something catches your attention.


Scheduling tasks with Cron
==========================
- define all tasks in cron
- don't make Ruby do scheduling


Background processing with ATD daemon
======================================
echo "convert image.jpg image.png" | batch


Logging with syslog
======================================
- don't use rails log

Resource limiting with rlimit
======================================
ulimit -v 102400
ruby -e "' ' * 1024 * 1024 * 1024 *1"
failed to allocate memory (NoMemoryError)

CPU and Disk IO priorities
======================================
nice -n 19 rake xapian:update # run rake with priority 19
ionice -c3 rake xapian:update # same for disk IO


Atomic renames
======================================
- don't use locks
- write to temp then rename

Secure self-cleaning temporary files
======================================
- create temp fie
- delete it while holding it open
- write/read securely


Page cache expiry with find
======================================
find public/cache -type f --mmin +10 -delete # del all files 10 mins old in a "transaction"

Log rotation with logrotate
======================================
- Rails sucks at it, use time proven and tested UNIX


Managing daemons with start-stop-daemon
==========================================
- don't reinvent the wheel starting/stoping daemons (mogrels etc)
    start-stop-daemon -d $railsdir -b -o -p $pidfile --start --starts rake xapian:update
- run cron tasks using start-stop-daemon to avoid race condition (it will exit if process already runs)


Real time signals
==========================================
use it in ruby:
trap("USR1") { reopen_xapian_db }


Raliable messaging with... SMTP!
==========================================
Due to atomic and reliable delivery it can be use as a message queue.
Can replace RabbitHQ etc


dbus
==========================================
UNIX based Messaging system


Self-organising systems with AVAHI
==========================================
Bonjour??


Modularised config files
==========================================
/etc/cron.d/rails-myapp
/etc/logrotate.d/rails-myapp


Watchdog daemon
==========================================

What I've learned from Scottish RubyConf

2011-05-18T23:52:00.000+10:00

I watched the videos from the Scottish RubyConf 2010 and thought I could share some interesting moments as simple notes. So there you go:


Harmony for browser testing

Capybara.driver = :rack_test # uses Harmony and can run JS

Good talk about Arel: 1LT_04-mp4_500mbs.mp4

Rack GeoIP.
Rack GoogleAnalytics
Rack::Cache (standard)
Rack::CacheBuster

Server side include to render page without parts of content that fail
(Nginx + Rack)

EvenMachine:: WebSockets add-on uses JS like API.
Other options:
-em-websocket
-cramp (higher level websocket)
-sunshowers
-node.js
pusherapp.com

Initialise multiple variables in JS:
var a = 1, b = 2, noInitialised;
jQuery has "end" method to go up in the chain.



VIM
:copen - opens the console output
f - find next occurence of char in this line
dap - delete paragraph
cap - change
yap - yank
ytCHAR - yank from here to next CHAR
Ctrl-v - visual block mode
:split, :sp, :vspilt, :vsp - split into 2 wins
ls - list buffers touched
q1, q2, q3... - record macro into register
@1, @2, @3... - play the macro from register

:R - Rails related file
:A - Rails alternate file
:Rextract - Rails partial extract
Shift-k - integrated Ruby ri

figutive.vim - more extensions: Glog, Gblame, Gstatus, Gdiff, Ggrep etc
snippets.vim
nerdtree.vim - files tree view
surround.vim
unimpaired.vim - auto-brackets
Hashrocket configured Vim at Github hashrocket/dotmatrix
Vimium, Vimperator - Vim in browser
Remotely connect and pair in Vim


UTF-8 is backwards compatible with ASCII
Ruby doesn't know about UTF-16 - it's messy

Globalization TODO:
- Do same as .NET CultureInfo
- Do different ways to localize different kinds of langs


You can generate UML model of Rails model using:
railroad -M | dot Tpng > model.png
uml dumper

Metrics:
- rake stats # LOCs
- FLOG Weighting the code AST - Assignment Branch Condition (ABC)
- FLAY - code similarities
- Saikuro - cyclomatic complexity
- Roodi - design issues
- Reek - design issues and specific smells
- Churn - changes to file with Git
- Rcov - test coverage
- Heckle - test coverage with code mutation
- metric_fu

You can also grab the Gist. Hope you find some moment useful.

Unit test actions with ValueProviderFactories in ASP.NET MVC3

2011-03-18T11:35:00.001+11:00

The problem: In the process of upgrading from MVC2 to MVC3 we have faced an issue where some of the ValueProviders gain explicit access to static HttpContext thus making it too hard to test complex actions.

The solution was not obvious at first and I want to provide enough context before the solution. The way I test the controllers is this:

[TestFixture]
public class CurrentUserControllerTest : BaseTestFixture {
    private CurrentUserController controller;
    private Mock<ICurrentUserService> userService;
    private FakeHttpContext http;
    protected override void Init() {
        userService = new Mock<ICurrentUserService>();
        controller = new CurrentUserController(Services.Account, userService.Object)
            .FakeContext(context => http = context);
    }
    [Test]
    public void CanSeeSecuritySettingsPage() {
        userService.Setup(x => x.ViewUser()).Returns(new User {SecurityQuestion = "sq"});
        controller.SecuritySettings()
            .ShouldHaveModel<CurrentUserController.SecuritySettingsInfo>()
            .User.SecurityQuestion.Should().Be("sq");
    }
    [Test]
    public void SuccesfulUpdateRedirects() {
        controller.UpdateSecuritySettings()
            .ShouldRedirectTo(action: "Index", controller: "Dashboard");
    }
}

The most relevant piece of code here is the extension method FakeContext. It ensures the controller is not going to access real HttpContext. The main difference between MVC2 and 3 is that the latter uses HttpContext in FormValueProviderFactory and QueryStringValueProviderFactory. So we need to get rid of it. And of course we don’t want to modify all our tests and complicate them providing explicitly FormCollection. Additionally we definitely do not want to go into trouble instantiating HttpContext.

Fortunately MVC is extensible enough and has number of hook that we can use. In this case we need to replace those two bustards (FormValueProviderFactory and QueryStringValueProviderFactory). Which can be done with this simple extension method:

public static class ValueProviderFactoresExtensions {
    public static ValueProviderFactoryCollection ReplaceWith<TOriginal>(this ValueProviderFactoryCollection factories, Func<ControllerContext, NameValueCollection> sourceAccessor) {
        var original = factories.FirstOrDefault(x => typeof(TOriginal) == x.GetType());
        if (original != null) {
            var index = factories.IndexOf(original);
            factories[index] = new TestValueProviderFactory(sourceAccessor);
        }
        return factories;
    }
    class TestValueProviderFactory : ValueProviderFactory {
        private readonly Func<ControllerContext, NameValueCollection> sourceAccessor;
        public TestValueProviderFactory(Func<ControllerContext, NameValueCollection> sourceAccessor) {
            this.sourceAccessor = sourceAccessor;
        }
        public override IValueProvider GetValueProvider(ControllerContext controllerContext) {
            return new NameValueCollectionValueProvider(sourceAccessor(controllerContext), CultureInfo.CurrentCulture);
        }
    }
}

And the final implementation of FakeContext extension that I use (you will need to trim it to your particular case) is:

public static TController FakeContext<TController>(this TController controller, Action<FakeHttpContext> exposeAction = null) where TController: Controller {
    ApplicationMetaData.RegisterAll(); // Additionally register all ModelBinder so tests behave is in production
    if (ViewEngines.Engines.Where(x => x is SparkViewEngine).Empty()) {
        // We only use Spar view engine that can render view during testing
        ViewEngines.Engines.Clear();
        ViewEngines.Engines.Insert(0, GetTestViewFactory());
    }            
    // That is the entry to all the fakes, implementation is trivial so not here
    var context = new FakeHttpContext();
    controller.ControllerContext = new ControllerContext(context, new RouteData(), controller);
    controller.Url = new UrlHelper(new RequestContext(context, new RouteData()));
    // And finally, here we ensure no ValueProviders access HttpContext
    ValueProviderFactories.Factories
        .ReplaceWith<FormValueProviderFactory>(ctx => ctx.HttpContext.Request.Form))
        .ReplaceWith<QueryStringValueProviderFactory>(ctx => ctx.HttpContext.Request.QueryString));
    if (exposeAction != null)
        exposeAction.Invoke(context);
    return controller;
}

Hope that helps. Have fun!

Screencasts for this weekend

2010-12-13T09:53:00.001+11:00

This weekend I was watching the screencasts instead of Sunday movies. It left me with a lot of inspiration and impressions. So I thought I would share the stuff you might also be interested in:

ASP.NET MVC vs Ruby on Rails - The .NET Rocks Smackdown
Why Ruby?
Testing C# and ASP.NET Applications with Ruby
Ruby for .NET developers (Scott Belware is awesome BTW)
Riding IronRuby On Rails

Other things are:

MonoTouch DeepDive
Meet Rails 3 by PeepCode (a producer of high-quality screencasts)

I think if you are a software engineer with open mind then you do need to watch some of the videos. This is especially true if you are a .NET developer who wants to explore other areas and technologies.

Stuff learned today - Ruby and Rails

2010-12-09T09:50:00.000+11:00

Ruby ignores underscores in numbers, so you can write 53782156 as 53_782_156 which is much nicer.
Suggested localisation for Formtastic's collections. Not sure whether it is important as it is still pretty easy to workaround.
To use all the ActiveSupport (v3), do require 'active_support/all' (note the underscore!).
We can add methods to associations by opening a block and (but scopes are much cleaner on the other end of association class).
Testing "access denied" and "requires user" is easier with custom matchers.
Rails URL helpers are not available in custom matchers for some reason.
Shoulda's RSpec matcher validates_presence_of does not work with non-persistent models.
Rails params hash has string keys, not symbols. Got issues with it when relying on keys being symbols.

Rules of Productivity

2010-11-29T15:29:00.000+11:00

How do we get more work done? It is a question that every manager and every passionate worker faces. Yet, for the most part, teams operate on gut instinct and habit. The results are less than optimal. [source]

What is productivity?

+ Work accomplished
- Work required to fix defects
- Work required to fix bad design decisions

Productivity can be negative when there is more harm than good.

Experiment 1: Overtime

Working more than 40 hours a week leads to decreased productivity.

< 40 hours/week – working not “enough”.
> 60 hours/week – small productivity boost.

The boost only lasts for 3 to 4 weeks and then turns negative. Though can be used for a short-time productivity increase.

So, work 40 hours a week with time for rest and family. Never work 2 months of 60 hrs/week. Overall productivity will be lower, despite the initial boost.

Experiment 2: Work harder in bursts.

Take advantage of the burst during overtime.
Crunch for a week and work only 40 hrs on another week.
Any more efficient work patterns?

Anything over 40 hrs/week results in a recovery period, no matter how you split it up. 40 hrs/week can be 10 hrs/day for 4 days and one day off. This pattern of work can increase productivity by 10-70%.

So:

Raise productivity immediately with short spurts < 3 weeks.
Overtime temporarily to meet deadlines.
Plan for the reduction in productivity immediately afterwards.
Consider 4-day work week as a flexitime option.

Experiment 3: Performance for knowledge workers declines after 35 hrs, not 40.

Creativity and problem solving decreases faster with fatigue than manual labour.
Grinding out problems by working longer on average result in inferior solutions.
Lack of sleep is particularly damaging.

So:

Overtime kills creativity.
If you are stuck on a problem, go home or take a break.
Get 8 hrs of sleep to improve your problem solving abilities.

Experiment 4: Teams on overtime feel like they are doing more, but actually accomplish less.

Team with overtime feels like they are doing much more than the team without overtime.
Team without overtime produces the better product and accomplishes more.

Humans ignore the systematic costs and physiological biases:

Failure to measure (cost of defects, bad design decisions, missed opportunities).
Linear extrapolation (initial productivity boost is seen as same in the future).
Habit (a bad one!).
Self reported excellence (behaviour rewarded independent of the results).

So:

The feeling of increased long-term productivity is FALSE.
Use customer metrics to determine the productivity.

Experiment 5: Productivity is maximised in small teams of 4-8 people.

Productivity of a small group is 30-50% higher than groups over 10 people.
Too high cost of communication for groups with > 10 people.
Smaller teams don’t have enough breadth to solve a wide array of problems.

So:

Split your teams into cross-functional teams.
Link small teams using '”scrum-of-scrums”.
Create processes for:
- growing new teams;
- splitting large teams;
- transitioning to new projects;

Experiment 6: Seat people on the same team together in a closed team room.

100% increase in productivity.
Faster communication and problem-solving.
Fewer external interruptions to the team increase overall productivity.

So:

Seat the team in their own room. With walls.
Give at least 5 sqr/meters per person.
Create side rooms for private conversations, phone calls, meetings.
Minimise non-team distractions.

Experiment 6: Cross-functional teams outperform siloed teams

Produced more effective solutions in the same time.
Much more likely to generate breakthrough solutions.
Short-term loss of negotiation of norms.

This is why:

Fewer external dependencies mean fewer lengthy blockages.
Team has the breadth to see the forest, not just the trees.
Different perspectives mean lower chance of groupthink.

So:

Create the team where every skill needed to solve the problem at hand is in the same room.
Limit the charter: “Do everything = big team”.
Fulltime: focused team member efforts. Multitasking = 15% drop in productivity.

Experiment 8: Scheduling at 80% of team capacity produces better products.

Scheduling at 100% doesn’t give space to creativity.
No lost time: passionate workers keep thinking.
The 20% goes into new idea generation and process improvements.
Producing 20 great features is usually far more profitable than 100 competent features.

Why?

Allows employees to explore many options cheaply.
Gives time to prototype breakthrough solutions that sound crazy on paper.
Allows people to pursue passions.

So:

Schedule 20% below possible velocity.
Hold periodic reviews of side projects and award interesting ideas.
Publicise and reward side projects that make their way into production.
Keep a public list of important things if anyone runs out of work (happens rarely).

Other productivity Techniques

Experimentation culture:

Fail faster to find success sooner.
Short iterations.
User metrics such as A/B testing.
State gate portfolio management.

Safety nets:

Test-Driven-Development.
Daily/weekly access to real customers.

Empower the team

Constraints-based requirements, not mandates from above.
Training.

See the original PDF.

Ruby On Rails vs ASP.NET MVC

2010-11-28T23:59:00.002+11:00

I have been watching the ASP.NET MVC vs Ruby On Rails talk from the Norwegian Developers Conference 2010 and just want to make a number of quotes that I particularly liked. My apologies if I missed something, but I believe it would be interesting to read it for those who don’t want to spend 48 minutes to watch the whole thing. I believe the quotes here really summarise the atmosphere during the talk.
So here we go:

Rails was extracted from the real world work sweat, blood, tears, everything..

And it feels like it is.

ASP.NET MVC is a "me too" framework - trying to compete with other solutions. ASP.NET MVC is not part of the story for WebForms, not quite fit.

Aha. Try to tell WebForms guy about MVC :)

Microsoft promotes it as an option. Option for what?

These words from Rob Conery probably mean that MVC is something that was not “designed” to be mainstream. But rather an “option” for… well web development on .NET.

[About TekPub]…rewrite point for startup - reconsidered BizSpark. We wanted to stay small.We needed fast, easy framework. Up in the cloud, scalable, zero cost, everything.

There was a lot of buzz behind the decision to move to Rails by Rob Conery who was a .NET advocate. But it was a happy business AND technical decision.

Rails came out of a need. MVC hasn't. NHibernate came out of a need. Entity Framework hasn't. It's always the same: solving problems they personally don't have, so they are not in the context of their problems.
Microsoft projects often come out of suppositions.

That is very common with Microsoft. They have to be everywhere and at the same time nowhere. Anything “new” that comes out from Microsoft has already been adopted and they are just catching up.

Dell is rebuilding everything in ASP.NET MVC (instead of WebForms).

Good for them. In any case, ASP.NET MVC IS a good thing to have in .NET world. And that’s my preference for Web development in .NET. Probably same goes with Dell.

MVC redirected the attention back to .NET after .NET Web developers started moving to Rails.

True. And in fact, most of the features of ASP.NET MVC were borrowed from Rails. So that was one of the easiest ways to hold .NET gurus back.

Why would .NET developers move to Rails?
Testing in rails is…uhh… it’s something you realise when you do it. Testing tools like RSpec and Cucumbet are just natural.
Deployment – Capistrano, Heroku – just unbelievable.

Cannot agree more on this. Testing “just works”, deployment “just works” it all “just works”.

In .NET we like to overcomplicate ourselves. Something too simplistic can’t be good. [No worries with SRP principle – objects aware of the persistence and similar].
In .NET we question more.

Speaking about myself, I do agree with it. Partially due to the nature of .NET (C#), partially because testing is harder, but also just because .NET developers try to solve problems in advance assuming those will exists (while in many cases they will not).

The MVC/MonoRail and Ruby On Rails have the same features.

Read on…

You have the same names of the features, but the experience is dramatically different. There’s incredible amount of software out of the box to do anything.
ASP.NET NVC hasn’t even got a plug-in mechanism.

So true! So true!

Why do we have to wait for 2 years to get the innovation that we already have available to us right now in Rails?

The rails community moves with small changes all the time, while .NET – with large in couple of years time. So for Rails it is a normal evolution, while for .NET it is rather a revolution.

[about Rails]… it means you are building a web site, and you are not rebuilding the stuff that has already been built. You are building Business.

Oh, yes. Having higher level plug-ins (nearly as Service-Oriented-Architecture components) it opens much more opportunities for business.

Not everybody is fortunate of making decisions at work [on choosing technology].

Try to push a new technology in a corporate environment with all the bureaucratic procedures. No f…ing way! Unless you are the one who decides.

Building web sites on .NET is about building web sites in a corporate environment. And that’s not about productivity. That’s not about really, really, really compressed budget where every decision is your life and death decision…[and then] It’s like we have a budget, but is is rather a suggestion.

Not much to comment on here. Don’t care about money – you are a .NET shop. Otherwise – probably Rails.

It’s about how fast you can turn your ideas into money.

Well said!

Most of the cost of long lived projects is re-learning. Ruby code is just scan and get it.

Indeed, Rails, would not even exist without such a beautiful language as Ruby. It makes code easy to understand.

In Ruby there is just less code to see where a problem might be. A lot less code! And the code is so usable that you can really spot the problems really quickly.

Again so true. Just have a look, for example, at some OSS projects. They do so much with so little code. That’s just amazing.

At the end, I must admit that I do like the .NET platform, but Ruby and Rails just feels much better to me and ALL of the things I currently do for myself, I do using Ruby/Rails.
It is just much more fun!

Render any ASP.NET MVC ActionResult to a string

2010-11-11T17:05:00.001+11:00

I often see questions on the net about how to render a view to a string so it can be used somewhere.

My approach allows doing it without thinking about all the boilerplate code. Additionally not only the ViewResult can be rendered into a string but just about any type of the result. Here is example on how to return a JSON including the result of the view as additional information:

// Controller Action:
public JsonResult DoSomething() {
    var viewString = View("TheViewToRender").Capture(ControllerContext);
    return new JsonResult {
        JsonRequestBehavior = JsonRequestBehavior.AllowGet,
        Data = new {
            time = DateTime.Now,
            html = viewString
        }
    };
}

This can be done with 2 simple utility classes below. Just include them somewhere into your project.

    public class ResponseCapture : IDisposable {
        private readonly HttpResponseBase response;
        private readonly TextWriter originalWriter;
        private StringWriter localWriter;
        public ResponseCapture(HttpResponseBase response) {
            this.response = response;
            originalWriter = response.Output;
            localWriter = new StringWriter();
            response.Output = localWriter;
        }
        public override string ToString() {
            localWriter.Flush();
            return localWriter.ToString();
        }
        public void Dispose() {
            if (localWriter != null) {
                localWriter.Dispose();
                localWriter = null;
                response.Output = originalWriter;
            }
        }
    }
    public static class ActionResultExtensions {
        public static string Capture(this ActionResult result, ControllerContext controllerContext) {
            using (var it = new ResponseCapture(controllerContext.RequestContext.HttpContext.Response)) {
                result.ExecuteResult(controllerContext);
                return it.ToString();
            }
        }
    }

Enjoy and let me know if it works for you.

RSpec 2.0 cheat sheet by example

2010-11-05T20:33:00.001+11:00

The Ruby developers know and hear a lot of buzz about RSpec BDD framework. The RSpec specifications code is so easy to read, but for my it is often hard to write. So I intend to produce a small cheat-sheet for RSpec syntax for myself.

Most of it come from the RSpec Book in rather unusual way. As a RSpec itself (unfortunately not runnable for now).

Please feel free to use it in any way you want and correct the mistakes.

So here we go:

Securities and Exchange Commission – comment on comment

2010-10-19T10:30:00.001+11:00

I have been going through the comments submitted to the US Securities and Exchange Commission.

I feel like I have to add my 2 cents on it. My first impression is that the analysis was not performed in full and the authors are being very affiliated with a company (which seems to be Microsoft).

One and most important issue with this document is that authors do not seem to fully understand the dynamic languages and they have not even taken into account (possibly) the most suited language for the task – Ruby. Of course I may be wrong.

I have to say that I have nothing against authors or anything like that.

My point is that I believe that the analysis could have been performed more deeply with close interaction with professionals of the particular languages.

So now, I would like to comment on the submission:

Safe execution of code written by one party on a machine owned by a different party was not a strong concern in the design of Python. It was a strong concern in the design of other systems, including Java and the .Net framework

This is neither sufficient nor necessary to achieve the security. The security is the effort of the developers, IT administrators and the people working with the system. Even when using an interpreted language it can be executed inside a virtual machine (be it JVM, .NET, SmallTalk etc) providing that sandbox mentioned above. Most common examples are – Jython, IronPython, JRuby, IronRuby etc. This cannot be served as a decision point.

A domain-specific language would support writing waterfall programs that are shorter and easier to read, and should help ensure consistency between the program and the narrative description.

This is exactly what Ruby, Python and other dynamic languages are good at. And this is exactly what C#, Java and other static typed languages are bad at. Not sure why having it as a crucial requirements the wrong tool for the job is advocated.

Efficiency. … Java, C#, and F# are designed to be executed efficiently, Python and Perl implementations are significantly less efficient.

This is true in many cases. But having the requirements in mind, the language inefficiency can be compensated with additional hardware. Its cost is significantly less than the cost of development time using strongly/statically typed languages.
If additional performance needed – then the just-in-time compiler can be used instead of interpretation (this includes Rubinius, IronRuby, JRuby, MacRuby etc)

Typing. Statically typed languages are generally considered to produce more reliable and easier to maintain code, while dynamically typed languages are generally considered to produce more flexible code and to be better suited for prototyping. Java, C#, F# are statically typed; Python and Perl are dynamically typed.

This can phrase exactly the other way around and is neither sufficient nor necessary to achieve supportability.

The wording is rather weird here: “…languages are .. considered to produce more reliable and easier to maintain code”. The languages do NOT produce code. It is a developer who does it.

Security. Some programming languages have been designed with security in mind, and some of their implementations include “sandboxes” that can securely execute untrusted code. Java, C#, and F# are such languages; Python and Perl are not.

As I mentioned above it cannot be the the deciding point because most of the dynamically typed languages can be easily run inside that sandbox using either a JVM, JIT or just a virtual machine; also sandboxing in the sense above does not eliminate the security issues. And we have a fairly recent example of that.

Domain-specific languages. Any programming language can serve as a basis for a domain-specific language by augmenting it with suitable libraries. Experience seems to show that higher-order programming languages such as F# provide a particularly good basis for domain-specific languages. There are financial domain-specific languages available in F#.

I don’t understand why F# is the only recommendation here. Ruby is one of the greatest languages to produce DSLs. Clojure may also be considered. For that matter Martin Fowler’s Domain Specific Languages book can be used as the starting point.

I do advocate Ruby language here and believe it can be used with a great success. Only one huge disadvantage of it is the absence of a formal specification (which in my opinion is the advantage as it allows better evolution of the language).

And of course there are many factors that have to be taken into account that may roll Ruby out, but it must be considered at least.

Additionally inviting professionals from Ruby, Python, Perl communities to suggest on the subject will provide much more information and will allow making an informative decision.

Ruby Challenge for Newbies reborn

2010-08-09T18:53:00.001+10:00

A question has been raised whether or not Ruby Challenge for Newbies should exist or not. The main concern is:

…today, probably due to lack of time or other commitments, not many experienced Rubyists are willing to set a Ruby challenge for the newbies

I guess many Rubysts DO want to set the challenges, but unfortunately very few people these days have enough time.

Another problem with such challenges is that they are somewhat “detached” from the real life. Though I am not saying they are not interesting or educating. Don’t get me wrong, definitely they ARE. But still, I guess, many people would love to see how Ruby should be used correctly (the Rubyish way) in real-world applications. Especially in web apps.

So if there is the problem trying to find new challenges, then either WE need to set up new challenges and recommend people who can do that or, if that is not possible, the challenge itself might need to be "converted" to something different.

It seems the latter is the better choice at this moment.

Having said that, I believe that a good challenge should have attributes:

driven by people;
not dependent on one person (though may be controlled by one or a group);
winner(s) appointed by the people (though influenced by the owner/controller);
collaborative;
“shareable”;
role-playing;

These are the ideas from the top of my head, but it is possible to play around those…

I personally feel like it brings us to the following idea of a challenge: Ruby Project Development challenge.

Somebody suggests an idea to implement (interesting web application, some kind of useful tool, etc). Then the challenge becomes a project that people have to deliver. There are main two roles in this challenge:

product owners;
development team.

The product owners group consists of number of people who do like the idea but may not have time, ability to develop that. This group decides where the development team is heading to, and negotiates the requirements.

The development team is a group of self-organised people who do the actual development. Multiple development teams may exist to develop the same application.

The duration for the challenge may vary from weeks to couple of months. The winner of the challenge is the person who gets most number of votes from either product owners/development team or both (not sure yet). If there are multiple teams – then the winning team may also be chosen.

So the process of the challenge would be something like this:

Somebody comes up with a project idea.
People join this project either as product owner or as development team.
People get organised in couple of development teams and a couple of product owners if too many guys have joined.
The countdown begins: product owners and development teams start working together (not necessarily at the same time).
During the work people should be able to see what others do, and help each other to deliver the product.
At the end of the challenge winners in following categories may be selected:
- best developer;
- best team;
- best team-mate;
- incredible inventor;
- etc

This of course is the basic idea, but it has sooo many variations.

So I propose the first challenge of this kind: Web applications supporting the challenge itself.

Caring, selling and appreciating technology era

2010-07-24T15:32:00.001+10:00

I have watched the RailsConf 2010 by Gary Vaynerchuk and I believe that was one of the best presentations I have seen in a very long while.

Gary is just outstanding and I highly recommend you to watch this video it (but be prepared - there is a log of swearing, which I actually like).

There is nothing about Ruby (On Rails), .NET, Java or any other technology.
This is just a talk about what you should care about as a business owner, this is about appreciation of the digital era we are living in. Also it is about caring about people, and cutting bullshit.

Sit, make yourself comfortable and DO WATCH it:

Hope you'll enjoy it.

Razor - ASP.NET MVC View Engine - first impression

2010-07-05T22:48:00.006+10:00

The new view engine is being released by Microsoft and looking at the announcement I feel a bit confused. Two questions flying in my head:

Why not take existing one and just help to make it better/sponsor?
Is it going to be a new productive thing or will it just make the view to be more spaghetti-like?

Not sure now. Time will show, but there are some things I feel I just must comment on. I'll try to look at it as a developer with no any politics and trying to think how it can help me.

Unit Testable: The new view engine implementation will support the ability to unit test views (without requiring a controller or web-server, and can be hosted in any unit test project – no special app-domain required).

For me this one would probably be enough to jump onto that with head. I still have the question on StackOverflow about testing the view hanging around. It looks like now I have the answer.

the start of a code block with Razor using a @ character. Unlike <% %> code nuggets, Razor does not require you to explicitly close the code-block

This is a huge typing and "mistake" saver. I like it, but still have the concern about the readability and ambiguity of such syntax. I need to give it a try first to tell whether this helps to do the job or screws things up. But the intention is definitely good.
Next, the code blocks mixed together with HTML:

  <ul>
    @foreach(var p in products) {
      <li>@p.Name ($@p.Price)</li>
    }
  </ul>

Currently it looks a bit weird to me. We need to get used to it.

So you can do lots of interesting things using such syntax. Additionally I have to state that the engine has a special tag - text. It is used actually to avoid adding any wrapping tag to markup serving the purpose of grouping things together.

By default content emitted using a @ block is automatically HTML encoded to better protect against XSS attack scenarios.

That is something that I would expect from any view engine - encode by default. So far so good.

create re-usable HTML helpers using a more declarative approach.

I like this part a lot (and I mean it), I won't repeat what it is said in the post, but will explain how I can benefit from it.
Currently I create a whole bunch of HTML helpers (written in .cs file in C#) which look very ugly should you have more than just a couple of them.
It just becomes messy, hard to change, support and maintain. And the fact that C# generates HTML is very annoying for the same reasons. That should be the view's concern.
Now we have it - just create a file, mark its content as helper and it is available on all the pages. Beauty!
(NOTE: actually after a bit more thinking we can do similar in Spark or NHaml. The word similar is used intentionally).

One other useful (and extremely powerful) feature we are enabling with Razor is the ability to pass “inline template” parameters to helper methods. These "inline templates" can contain both HTML and code, and can be invoked on-demand by helper methods.

Previously we, generally, injected C# code into the template. Now we can do the other way around. Absolut power. Only God knows where it can bring us :)

What I want from it

One of the most frustrating things working with views in ASP.NET MVC is passing the values from a controller to a view. So the syntax that would read values from ViewData dictionary would the biggest time saver. Something along this:


@currentTime.ToString("d")

which would be equivalent for


((DateTime)ViewData["currentTime"]).ToString("d")

So that we do not even need to provide the time of the object in the ViewData.

Summary

The first impression is very positive. Though I have some doubts in the syntax acceptance.
But I have no doubt that this engine is the way better than WebForms. Can't yet say it is better than NHaml and Spark (and would not be fair to say that as they solve a bit different problems).
This time I feel that Microsoft has listened to the developers and produced something that really brings value, productivity, less frustration and more fun (and fun is the starting point of being a happy developer who can bring value to a company).

IBM is moving to Firefox

2010-07-02T08:54:00.002+10:00

The big corporations are usually very conservative and in order to change something inside the huge bureaucracy people have to go through many obstacles and justify their decisions.
I wonder how ones could justify that IBM is moving to the Firefox web browser. Whatever the justification is I believe it the positive decision for the word-wide-web and normal people using the web.
Do the corporations still have a passion and not only the financial benefits? Maybe both: complementing each other? That would be an idealistic world.

HTML5 and CSS3: Develop with Tomorrow's Standards Today

2010-07-01T09:31:00.002+10:00

If you are not living under the rock, you must know a lot of buzzing around HTML5 and CSS3.
And if you want to keep up with technologies so that you won’t become a grand daddy saying “I work with HTML1 and no CSS which works on all browsers”, then you DO HAVE to learn HTML5.
And there is one more opportunity for that, a great book from the great publisher (PragProg):
HTML5 and CSS3: Develop with Tomorrow's Standards Today
Looking at the excerpts, I do like it for now and will get it as soon as I will have finished some of my other readings.

Agile Manifesto to Agile Principles

2010-06-19T21:22:00.003+10:00

A while ago I wrote about agile manifesto everybody should keep in mind (when they claim to be agily-ish). Now I want to quote the principle of the Agile. This is another reminder for my after reading the great book - The Agile Samurai. Highly recommend it.
So here they are:

Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity - the art of maximizing the amount
of work not done - is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Quotes: Moving from ASP.NET MVC to Ruby On Rails

2010-05-24T09:33:00.001+10:00

I am being reading the Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rail. There are number of interesting things in there that I would like to quote.

First most notable is COST. ASP.NET MVC and thus Microsoft stack is pretty expensive and you cannot always justify the cost:

RB: If the platform [ASP.NET MVC] was holding up fine, what prompted the change of architecture?

RC: Money. We were enrolled in Microsoft BizSpark Program and it was great for getting off the ground, but projecting into the future we realized that everything - from our database down to our development environment would have to be paid for after 3 years. This might not be an issue for a large company, but when we sat down to assess what the bills would be - well let's just say that it was about 5 figures. We put our business hats on and tried to justify that cost - and we couldn't.

Additionally the tooling around Ruby On Rails is just great:

RB: Why did you choose Ruby on Rails?

RC: It's what James and I both knew, and the plug-in story is very compelling. For instance - New Relic is a god-send. I don't worry about the server freaking out, and I can see the "choke points" of all the code. They also track the highest-occurring queries and will even suggest improvements.

MongoMapper is an incredible data tool and MongoDB itself is faster than lightning. The Rails platform has matured to the point where it's almost difficult to justify *not* using it.

JA: All the problems we had (licensing, testing, deployments) could have been overcome. We could have used workarounds, written our own deployment framework, etc. What is comes down to is that we both really enjoy working with Rails and we enjoy the Rails community and the tools and libraries available. One of the best parts about running the show is that we get to do what makes us happy.

And the benefits seem to be huge. I am looking at that from the perspective of a TDD developer:

RB: What immediate benefits have you seen from the rewrite and the new design?

RC: Immediate - the first thing people notice is the speed of it all. They also notice a bit of a "tighter" design which we were allowed to focus on a bit more as the server-side stuff is really trivial, to be honest.

Not only that - but we've had some issues that we were able to iron out within seconds as the deployment story is so very, very simple with Capistrano. Issue a fix and push - takes seconds.

Our testing suite grew tremendously as well - Cucumber is a joy to use and lets you do some things that are a bit hard with ASP.NET MVC. For instance - testing PayPal's IPN posts are pretty tough with ASP. It's possible to do - if you create a FormCollection and push it through - but couple that with the anti-forgery protection and the story gets a bit more difficult.

With Rails/Cucumber/Webrat, it's a matter of filling out a hash and posting it….

JA: The most immediate benefit has been the speed at which we are making changes and pushing them up to production. On the ASP.NET MVC site I would often write SQL scripts to handle complicated support requests, like changing someone's OpenID or combining accounts, but now I just spend the 30-60 minutes to write a couple of lines of Ruby and push it up.

And of course I could not miss quoting the comparison of Microsoft-based technologies with Ruby-based:

RB: How does your current testing methods compare to what you had on Microsoft?

RC: 100% difference. It was a pain to test with the Microsoft stuff and when you're poor and have 3 months until the money runs out, testing is something that you have a hard time justifying... [Then talking about ASP.NET MVC testing]… So I had some tests, but nothing to gives me the comfort I wanted. We did wrap the PayPal stuff in a ton of tests, you have to. When it comes to their API and I torched their sandbox environment for 3 straight days and STILL had issues rolling live.

JA: Microsoft testing is always a fight, mainly because C# and static languages don't lend themselves well to testing. It always feels like you are jumping through hoops when testing on .NET. That being said the SpecFlow framework on .NET does look very promising, but I doubt it can overcome all of the drawbacks of testing in .NET.

And this is probably really what it means to be Agile:

RB: What lessons or takeaways have you gotten from a total redesign?

RC: None really - I think both James and I knew that we'd hit a point where we would need to adjust and rewrite…

We were lucky in that the idea took hold - we then moved into "OK let's plan for the next 3-5 years and go into controlled-growth mode" - which is where we are now. We don't want to be huge, we don't want IT people or a group of developers who work on stuff. We want to do it ourselves and stay small - focusing on the idea that got us here.

And the lessons learned are just a ton of satisfaction:

RB: Do you see any weaknesses to the current architecture? What would you change if you were starting over again today?

RC: Nothing on my end - I love it all. It's weird for me - I've been a Microsoft person for a long time but putting on my business hat... well it just doesn't make any sense at all for us. I like the idea that scaling comes at the cost of hardware - and it will be a really long time that we'll need any. Our servers are essentially "liquid" and we can buff as needed. Can't do that with the Microsoft boxes (from what I know) and if you try to latch on separate machines, you end up with a big bill.

JA: The only change I would like to the current architecture is to break out MongoDB from our single server, it makes sense to run MongoDB in a pair whenever possible but with replica pairs being depreciated it makes sense for us to wait on the MongoDB team to develop their new pairing strategy and start with that. The cost of an addition two VMs and the fact that everything is running fine on our single server also deters us from doing this right now.

HTML 5 Readiness

2010-04-20T20:55:00.002+10:00

A friend of mine just sent me the link: HTML 5 Readiness.
Check it out - it shows browsers support for HTML5.

As always Internet Explorer is far behind. Chrome is doing very, very well.

And one more link (not really related) for myself as a note: visual time zone representation.