Because it is easy to get the dates/times wrong without even realising it. Even if you don’t need to support multiple time zones, you can catch a lot of the edge cases.

How?

1. Randomise time zone when running specs
2. Run the specific specs across the different time zones

Usage: Randomise time zone when running specs

The RSpec support file (see below) will set the Rails’ Time.zone to a random time zone. So if something is wrong then your CI should eventually fail.

When it will, you should look for the message at the very beginning:

1

Current rand time zone: (GMT+06:30) Rangoon. Repro: Time.zone = ActiveSupport::TimeZone["Rangoon"]

Then go to your failing spec and in the context of it add the following (assuming you copy pasted the “Repro” part from the message):

1

  before { Time.zone = ActiveSupport::TimeZone["Rangoon"] }

Now you can re-run the spec and it should repeatably and predictably fail (much like RSpec’s random order with a given seed).

This works without changing any of the existing specs and relies on the fact that your CI is running specs often enough.

Usage: Run the specific specs across the different time zones

You may have some specs that you want to specifically test across all the time zones. That doesn’t mean you want to support all time zone, it just means that the transitions between the dates are very important. Getting it run for all timezones will give good confidence about the correctness of the functionality, even for one time zone.

This can be used, for example, with tests on reports that are quite sensitive (all financial/sales reports probably).

So how do you do it?

Just write the normal specs without thinking about the time zone. Let’s take this as an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

require 'spec_helper'

module SalesReport
  describe SalesChart  do

    it "should return chart with data for a week as daily summary" do
      create_three_reservations_per_day 0..1
      chart = SalesChart.for_company(reservations, company)
      chart.data_table.cols.size.should == 4
      rows_from(chart).should == [
        [1.day.ago.to_date, 3, 2, 1],
        [Date.current, 3, 2, 1]
      ]
    end

    # helpers ommited...
  end
end

Make sure it passes in your timezone.

Then just wrap your spec in across_time_zones, like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

require 'spec_helper'

module SalesReport
  describe SalesChart  do

    across_time_zones step: 2.hours do
      it "should return chart with data for a week as daily summary" do
        create_three_reservations_per_day 0..1
        chart = SalesChart.for_company(reservations, company)
        chart.data_table.cols.size.should == 4
        rows_from(chart).should == [
          [1.day.ago.to_date, 3, 2, 1],
          [Date.current, 3, 2, 1]
        ]
      end
    end

    # helpers ommited...
  end
end

You’ll be surprised how many things can go wrong. Especially if you have some more advanced DB queries that use (in PostgreSQL terms) dates, times and times with time zone, maybe DATE_TRUNC etc.

Now that spec will be created for each time zone with the given step.

Tips/Gotchas

• The default step here is set to 8 hours (it is optional), meaning that only 3 time zones will be tested. It may be sufficient or may not. So prefer to provide it expclicitly.
• The smaller the step is, the more specs will be created and the slower the example will become. So choose the number wisely (less than 2 hours is usually not necessary).
• Always, always use Time.zone.now (or Time.current) instead of Time.now.
• Always, always use Date.current instead of Date.today.
• Move any let! (with bang) and before blocks under the across_time_zones to ensure the correct time zone is used at all times.

You can grab the RSpec support file to leaverage it. Feedback on this is welcome.

I’m writing this after watching the Steve Klabnik’s screencast where he is working “in a wild”.

I love this idea and have done videoing how I work on a little ios-checkboxes and knockout-rails.

The world would an awesome place if more people (yes, including you) would start sharing the way they work. Well done Steve!

But today I want to focus on just a few things that should dramatically improve the productivity.

Vim productivity

Vim is one of a select bunch of tools for which I have no substitute.
It is a brilliant piece of work!

The power of vim is huge. Very small number of people actually do know how to use most of it. I’m certainly not one of them.

But let me suggest some of the things that keep myself more productive.

Remap your CapsLock key to Control

Why? Because the Control key is located extremely inconveniently while CapsLock is right under your baby-finger. All the time.

How? Follow this guide.

I blindly trusted the command given by Garry Bernhard in his DestroyAllSoftware – Some Vim Tips on this. Never regretted.

Don’t think about it. Just do it and I’m sure you won’t go back.

Use Vim jumps

Why? A lot of times you need to jump forth and back between 2 place or go to where you’ve been a minute ago. A log of people just find that line/file again. It’s a waste of time.

How?

• Ctrl-o and Ctrl-i to go to the previous/next location you jumped to.
• `` (two backticks) – jump back to where you were.
• gi – go to the last place you inserted a text.

Use appropriate Vim navigations

Why? Typing l (move right one symbol) or similar multiple times is waste of time.

How?

• { and } – jump paragraph back and forth.
• Ctrl-F/B – move one screen back and forth.
• Ctrl-E/Y – scroll the screen.
• * (star) – search for the word under cursor, then n/p to jump to next/previous.
• add imap jj <Esc> to your .vimrc and don’t use Esc anymore.

Changing case and repeating a command

Why? Because a lot of things can be done much more efficiently.

How?

• ~ (tilde) – toggle the casing of a letter/selection (upper-case/down-case).
• . (dot) – repeat the last set of commands (use in a combination with search, such as *, and jumps).

Temporarily map commands you run

Why? Because you don’t want to type the same command over and over again.

How? One example is nmap <leader>s :! bundle exec rspec % --colour --focus<cr>. This will run the current spec file when you press ,s (in my case).

Rule of thumb: if you do something more then twice in the terminal outside of Vim, map it using nmap. Don’t switch windows, don’t lose your context.

Terminal productivity

Just a couple of things here.

Use iTerm2

Why? At least because you can split window without losing the context.

How? Install it from the iterm2.com site (or even use tmux!).

Use Ctrl-D/Ctrl-Shift-D (while in Vim or any iTerm tab/window) to split the current terminal window opening a new shell but still being able to see what you are currently working on.

Use !! (double bang) or arrow up

Why? Because it repeats the previous command that you should have mapped in Vim but didn’t.

How? Just type !! and it will execute last command. This is simple, but strangely enough I can see people are actually retyping commands.

Enable Vim mode in bash

Why? Because you navigate in the terminal too. And Vim mode makes it seamless.

How? Create an inputrc file and add set editing-mode vi to it.

Useful links

• Vim anti-patterns – must-read if you want to be better at Vim.
• Smash into Vim – always awesome PeepCode series on Vim.
• Vim for Rails developers – nice overview of the plug-ins and more productive use of Vim.
• Meet the Command Line and Advanced Command Line – great screencasts if you want to get better with command line.
• DestroyAllSoftware screencasts – screencasts covering Vim, Unix, Ruby.

The DestroyAllSoftware stands out here because Gary covers range of extremely focused, professional topics that you can’t ignore.

Hope this post will help you to leverage your tools a bit better and will teach you a thing or two.

Being an introvert myself I agree with most of the points:

• Respect their need for privacy.
• Never embarrass them in public.
• Let them observe first in new situations.
• Give them time to think. Don’t demand instant answers.
• Don’t interrupt them.
• Give them advance notice of expected changes in their lives.
• Give them 15 minute warnings to finish whatever they are doing before calling them to dinner or moving on to the next activity.
• Reprimand them privately.
• Teach them new skills privately rather than in public.
• Enable them to find one best friend who has similar interests and abilities; encourage this relationship even if the friend moves.
• Do not push them to make lots of friends.
• Respect their introversion. Don’t try to remake them into extroverts.

I’m pretty sure it is just a common sense. But it helps when people do know it.

This post will cover some of the reasons for that and also will provide an overview of how to migrate from Blogger to Octopress.

What do I want to achieve?

• Merging my personal site and blog – those were totally separate, unrelated entities, not good enough.
• Write more often, using the same tools I use on a daily basis (Vim ATM).
• More hands-on kind of blogging, I actually do want to do the dirty work messing with HTML/CSS etc.

Reasons for switching:

• Markdown, HAML, bare bones HTML. I wanted to have a bit more control over how my blog looks like.
• Blogging software isn’t good enough. Unfortunately I haven’t found yet a good geeky S/W for blogging.
• Easier to write from Vim. Writing is much easier, not moving my hands off the keyboard and staying in the terminal.
• Version controlled. Nice to have, but not crucial for me.

Why I didn’t want to switch:

• Losing PageRank, which shouldn’t really be an issue (see below).
• Uncerteinities. So now I have to maintain it myself? Take care of updates? Hell, yeah!
• Self-hosted. Nothing to say here.
• I have never ever needed to do anything with the blog in terms of maintenance while being on Blogger. I really just worked.

Switching to a self-hosted blog/site will require a bit of involvement from me. But this is something I am willing to take. It’s time to take my ass out of the comfy couch of Blogger.

So how to actually migrate?

I would split it into the following larger steps:

1. Preparation.
2. Deployment.
3. Finalisation.

Preparation

At this stage you need to setup the Octopress itself, configure it and import your existing posts from Blogger.

I won’t go into details how to customise and set it up, you see the links.

I’ll go directly into the migrating the Blogger posts over to Octopress.

What you need to do is

1. Export your Blogger posts.
2. Use this script to import it into Octopress.

After you do this, all you’ll get a bunch of posts that are already part of your site. Double check whether everything is correct or not. You may want to tweak the script for your needs.

Note that the script also imports the comments, but in a little ugly way. (TIP, you may want to disable commenting before exporting the posts from Blogger).

Next thing you want to do is to update your Octopress RSS feed URL so that existing subscribers won’t be lost. I am using FeedBurner and I had to set subscribe_rss: http://feeds.feedburner.com/DmitriyNagirnyak in the _config.yml

Now that you’ve got your posts, you want to set-up the redirection from your blog to your new site.

I prepared simple Sinatra application for that. You definitely want to fork and tweak it to your needs. Note that I’m not using the blog/YYYY/MM/DD/title format. I just use the blog/title format.

Now go ahead and deploy this app. I’ve decided to use Heroku for that which is the simplest and easiest way to go.

But make sure you deploy to the domain of your blog. For example, my Blogger blog was hosted on the blog.approache.com and I deployed it to this domain.

It of course will not take any affect until you change your DNS settings. But this will enable permanent redirects immediately when you’ll do that (thus preserving all your old links).

Deployment

By now you should have:

• The Octopress site ready to go (with all the posts migrated).
• Blogger redirection deployed.

It’s time to go ahead and actually deploy your Octopress site.

I wanted to merge blog.approache.com into the approache.com so I deployed the new site to approache.com (hosted on Github Pages).

Now make sure everything is working properly and you have dome everything right. If you’ve missed something out, then go ahead and fix it. Then redeploy.

This may take a couple of iterations to get it right.

The point here is that you basically now have 2 blogs – one is the old Blogger, the other – the Octopress. You can experiment with the Octopress here, but don’t do it for too long (I would say max of 1 day).

After you’re happy with the new site and blog it’s time to finalise everything.

Finalisation

Next step is to make sure your subscribers will still receive updates through the FeedBurner. For that:

1. Sign in into FeedBurner.
2. Replace the original feed URL by the Octopress’ one (which is something like http://ApproachE.com/atom.xml).

By now you should be ready to switch your your Blogger domain to your main site.

You probably will do it simply by changing your DNS record to point to your Octopress server. In my case I had to change the DNS record from blog - CNAME - ghs.google.com to . - A - 207.97.227.245 (dot means top-level domain here).

Since you’ve already deployed your redirection app, all the old links will still work. All the PageRank should be preserved.

The very last thing to do is to disable the Blogger if you want to.

Summary

Switching to Octopress was relatively painless thanks to Blogger’s ability to export posts and the script that could import it into Octopress.

Preserving URL was relatively easy too and the rest was left to FeedBurner and DNS hosting.

Hope this is helpful for you.

Comments

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

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

Comments

Comments

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.

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

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:

1. 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.
2. 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.

1. To deploy a rails app (and any Rack based app), user should put the app under his home directory in apps/[name]/current.
2. 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:

1. Deploy the app explicitly to a particular domain (staging, production, local server etc).
2. On every deployment - backup SQLite database (I know, I’ll use something better when I’ll have 1 million users).
3. Prepare Nginx config file for the server (it depends on the domain we deploy at).
4. 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.

Comments

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.

Comments

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
==========================================

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.

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!

Comments

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:

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

Other things are:

1. MonoTouch DeepDive
2. 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.

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

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.

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

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.

Microsoft promotes it as an option. Option for what?

[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.

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.

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

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

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.

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.

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

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.

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

[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.

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

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.

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

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

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.

Comments

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.

Comments

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: