Entreprevelopment adventures

For anyone who works in business (especially startups), this is most probably (or most definitely) the most important TED talk that you’ll ever get to watch. Or the most important talk/piece of advice that you’ll ever get, I believe.

How great leaders inspire action

The fact is that this is what attracts me (and many people, probably) to startups. It’s just easier to find this sharing of common beliefs – and if it’s not, it’s the wrong startup.

People don’t buy what you do, they buy why you do it.

People buy what you believe in. Somehow this makes me believe in mankind a bit more :-)

Analytics.js

I don’t know whether this library is very common, but it definitely shows a lot of promise:

Segmentio’s Analytics.js

It provides provider-agnostic hooks to route to analytics services. They also have a hosted version where the analytics services can be changed without touching the code. Looks really clean and neat.

Nice video: to_proc

This video by CooperPress explains in a very clear fashion how to use the “to_proc” feature of Ruby (and understand some weird code you might come across). It is also well worth it to subscribe to their other videos.

Faster Rails partial rendering and caching

I sure will try out this gem (multi_fetch_fragments) to optimize Rails when I get to that point of my work…

Indexes in Rails databases

Extremely good article by Tom Ward on using indexes in rails associations. An excellent guide to determine what indexes your app should include (no more, no less).

Not that I am an authority in testing… this is just a compilation of the so-called “best practices” that I’ve been seeing around, as well as some extra tips from my (very limited) experience. I’d love to hear the feedback from more experienced people… I’m going to do several of these as I go along.

Gems I use

I test using rspec and shoulda, which dramatically reduces the size of the tests. But beware – rspec is a DSL, and I think that I only got a bit more intuition on what I was exactly testing after doing some tests in Test::Unit. I also use FactoryGirl for setting up the test data, instead of fixtures. Last but not least, the simplecov gem is amazing, and although you shouldn’t rely on it to determine when to stop testing, it really is good to get a (very precise) sense of what’s covered and what’s not in their beautiful html reports.

General tips

When all your tests are red for no apparent reason, it’s because you were messing around with the db and then forgot to do

rake db:test:clone

Yup, the reason I am mentioning it here even though it seems completely obvious is because I am distracted and do that a lot… :-)

Tips for running guard/spork in vagrant

I use vagrant to keep my environment all neatly in one place. However, there are downsides. When running guard inside the guest OS, use

bundle exec guard -p

Otherwise, guard won’t detect changes in the guest filesystem.

FactoryGirl tips

You can keep all factories in one file, for me that is more intuitive (and also, I don’t have to keep opening files while I’m testing, it’s all in one place.)

To try FactoryGirl methods in the console, run:

FactoryGirl.find_definitions

At least in my case, I would get a factory not registered error when I didn’t do that.

Better Errors

Not exactly related to testing, but this gem has been a life changer! When there is an error, the standard error page gets replaced by a much better and useful error page, which has a full trace, the local and instance variables that are set at the time, and a terminal that you can use to inspect and make changes to the variables in the models and controllers in real time (or code whatever you want). I know I already mentioned it in another post, but I can’t stress enough how cool this gem is!

In the next posts, I’ll give an overview of how I test the models and controllers, which I only started testing this week!

I usually have Guard running in the background with Spork, but when I’m writing tests I like to do it the old fashioned way and be able to do rspec some_test | less. The problem with that approach is that we get a monochrome version of our tests. In order to redirect the color in the pipe, edit spec_helper and add the following:

 # spec/spec_helper.rb
Rspec.configure do |config|
    config.tty = true
    config.color_enabled = true
    # ... whatever configurations you might have here...
end

And enjoy a more colorful life ;-)

This isn’t exactly my tip (well, since this is a learning / work in progress blog, none of them are), but when an article is already as comprehensive as this one, there’s nothing left to say except:

Here’s a very nice article on the options for setting environment variables in Rails

Why would you want to set environment variables in rails? There are some examples in the article, but for instance, setting passwords to access services. They should not be in any file (nor tracked in git), so that other people cannot access them. One way is to set Unix environment variables, the other way – which actually sounds like a “cleaner way” of organizing things – is to set them from Rails itself by taking the values from a yaml file.

I don’t have a USB keyboard, so my only option for controlling my Raspberry Pi is via SSH. That turned out to work quite well, since the customized image of Debian provided by Raspberry Pi (2012-10-28-wheezy-raspbian.img) already has ssh enabled by default. It suffices to discover the IP address that was assigned by the router, and connect :-)

(By the way, for those with Mac OS, the command line instructions here) are very nice and comprehensive.

So now on to the cool stuff… Initally I had installed TightVNC, but could not connect to the same session as being displayed via HDMI (which is console 0). I don’t know whether that’s possible with TightVNC, but I sort of got tired of trying. So here are the steps to make it work, which basically consist of installing x11vnc instead of TightVNC and having your desktop manager autostart it:

sudo apt-get install x11vnc
11vnc -storepasswd

# to create the autostart entry, do:

cd .config
mkdir autostart
cd autostart
nano x11vnc.desktop

# paste following text:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=X11VNC
Comment=
Exec=x11vnc -forever -usepw -display :0 -ultrafilexfer
StartupNotify=false
Terminal=false
Hidden=false

… aaand it works :-) For more details check the original link.

Very interesting remark from MIT Technology Review on how installable web apps will be the next tech background. To be honest… Hope not. This should be the next big thing, especially for developers, who can make their apps ubiquitous with a little extra effort… It will be interesting to see Apple’s reaction, though.

This one I haven’t evaluated yet, but looks promising: Rack Protection, to prevent typical web attacks such as cross site request forgery, cross site scripting, clickjacking, directory traversal, session hijacking and IP spoofing.

… and better yet: in the command line. No more messing around with slooow browsers in the Pi.

First, install mplayer if you don’t already have it:

 sudo apt-get install mplayer 

Then, open ~/.mplayer/config and pimp your player by adding the following settings:

 cache=8192
cache-min=4 

Next, clone the gsclient plugin by drakedevel:

 
git clone https://github.com/drakedevel/gsclient.git

And now… RoCk and RoLL :-)

Yes, today I am in “documentation” mode, which means “bloggation” mode :-)

Just installed this gem – Better errors. It is a gem meant to help you out in development mode that replaces the standard Rails error page with a wayyyy better and more useful error page, featuring full stack trace, source code inspection for all stack frames, local and instance variable inspection, etc.

I’m going to try it out today, but definitely beats the time spent looking at development logs (even if they are as clean and contained as mine after doing the changes described in this post).