Here is the problem:

I created a couple of libraries for an app I’m working on and put them in a ./lib directory and they reference each other like this:

##./lib/lib-a.rb##
require ‘lib-b’
…lib does stuff with classes included in lib-b…

##./lib/lib-b.rb##
require ‘lib-a’
…lib does stuff with classes included in lib-a…

##main.rb##
require ‘./lib/lib-a’
…use lib-a which tries using lib-b…

Well when I’m in the top-level directory and try including one of the libraries it won’t work because lib-a.rb will look for lib-b.rb in the current directory and it doesn’t know to look in ./lib

If I change lib-a.rb to call require ‘./lib/lib-b’ it will work from the main script because it knows how to get to lib-b from the top level directory.

The real problem is that the application is bound by that top level directory now. If I try to make a test in ./tests/test.rb like this:

##./tests/test.rb##
require ‘../lib/lib-a.rb’

The problem is that lib-a is looking for lib-b in ./tests/lib/ because of the ./lib reference….

The basic problem here is that, even though we are using relative paths, the paths are like absolute paths relative to the current directory. We need to avoid such relative paths as much as absolute paths in our code. How do we do this?

The solution:

The ruby require uses the global variable $LOAD_PATH to figure out where to look for libraries. $LOAD_PATH is an array of directories that you can add to to get your libraries loaded properly without any directory spec in the require statement. Here is an example:

##./lib/lib-a.rb##
require ‘lib-b’

##./lib/lib-b.rb##
require ‘lib-a’

##main.rb##
$LOAD_PATH << ‘./lib’
require ‘lib-a’

##./tests/test.rb##
$LOAD_PATH << ‘../lib’
require ‘lib-a’

This will set up the load path to be passed to everything properly so that ruby can just work its magic.

There are two approaches to writing tests and one of them is more conducive to test writing then the other.

The first way is to write your application code first then write the tests to back it up. The first problem with this is a matter of motivation really. After writing all the application code and making it work, I find it very hard to motivate myself to write the little extra bit of tests instead of diving right in to the new feature on the roadmap. Why write the tests after you know it works? Well, again, what if you have to wedge a feature in there or refactor? Then you have to recall all the stuff that you tested by hand while you were building it and then test it again, by hand, or write tests at that point and Murphy’s law says that you will forget at least one critical case the second time around.  That is why the second choice is the better.

The second way to develop with tests is to write the tests for the functionality that you want and then write the code to make the tests pass. This is the Agile approach and, in my opinion, the better. Why? Well, you are writing tests based on requirements. So you will know as soon as your code does what you want. Second, you are writing tests based on what you are encountering while writing the application. This lends itself to more coverage because you will be writing tests for all the little edge cases you will encounter while writing the application. This means that, in the future, when you refactor or go muddling around, you can verify, RIGHT THEN, if you broke anything.

I have heard managers complain about developers spending time on tests and not on features first because users and clients won’t see the tests and time should be spent on user/client features. Well, here is the reality, a little time spent at the beginning of a project writing tests saves a lot of time in the end because you don’t need to spend so much time verifying feature requirements while writing. Plus the QA process is much faster and smoother because you are handing of working code from the beginning. Writing tests at the beginning usually saves me more than 10% time on the same project where I write the application code only with no tests! That is 10% faster to release and ensures better user experience in the long run because I verified that the project is doing what it should and handling errors properly before I even wrote the application!

Today someone mentioned to me that bug or feature was down and I logged in and found that, sure enough, they had updated the rails gem. So I changed my gem requirement in my environment.rb file but my app relies on some 2.2.2 specific stuff so it wouldn’t start. So, I am forced to get the rails-2.2.2 tag from github and put it in vendor/rails to get the site back up again. I am so tired of this. I am done with bluehost and shared hosting. I am going to begin migrating everything to my slicehost slices and call it a day.

Goodbye bluehost, I would love to say it was all great but I can’t…

• spend hours/days/years making a vpn work using a consumer grade vpn router which, lets face it, is a cheapo unreliable piece of hardware.
• buy a $500+ commercial grade vpn appliance
• spend hours/days/years building your own router using linux and add a vpn server to that

OR

You can use ssh to create a socks proxy.

ssh -D 1080 -p 22 username@homenetwork.net

In the example 1080 is the port for your socks proxy to accept connections and 22 is ssh port that you are connecting to. Lastly is your username and host to connect to. Once you have logged in to the machine you can minimize the window.

That’s it. Now when you browse the internet the packet is going to the machine you connected to via ssh first. This means that you are browsing as if you were at that machine. You can then browse to local ip addresses in your home network and access those pages. For example, if your router’s status page is at 192.168.1.1/status you can type that in the url and get that page. Try it.

(substitute your parameters)

Lastly add this to your /etc/crontabs/root file:

0,15,30,45 * * * * /bin//check_dns.sh > /dev/null
0 1 * * 1 /bin/update_dns.sh > /dev/null

The first line will add your check for every 15 minutes and the second will run the update every Monday morning at 1:00A.M. to keep your account up to date.

And there you have it. Easy and simple. The lightest weight DynDNS updater for your OpenWRT router.

(P.S. You can use this on any *NIX system with a little tweaking)

Links:
OpenWRT – http://openwrt.org
DynDNS – http://dyndns.com
Gist Repo – http://gist.github.com/14091

public void static main(String[] args) {
System.out.println(“Kill me”); }

First, let’s talk about how you get a tinyurl. Tinyurl has a really simple api that you can call that will return a tiny url. It is rediculous how simple it is. You just call this url with a GET: http://tinyurl.comapi-create.php?url=http://example.com

The returned page will be a single line with the tinyurl equivalent. It is that simple. Now on to the rails part.

In your application.rb helper you would add this:

require ‘net/http’
require ‘uri’

def tinyfy(newurl)
   url = URI.parse(‘http://tinyurl.com/’)
   res = Net::HTTP.start(url.host, url.port) {|http|
   http.get(‘/api-create.php?url=’ + newurl)
   }
   if res.body.empty?
      #tinyurl is not responding properly… Return the original url
      return newurl
   else
      return res.body
   end
end

Now if you call the tinyfy method in your app, let’s say in your view, with the url you want to tinyurlify as the parameter the return will be the tinyurl. I take this one step further and have the tinyfy method make the url a link by adding the ‘a’ tags in the method like so:

require ‘net/http’
require ‘uri’

def tinyfy(newurl)
   url = URI.parse(‘http://tinyurl.com/’)
   res = Net::HTTP.start(url.host, url.port) {|http|
   http.get(‘/api-create.php?url=’ + newurl)
   }
   if res.body.empty?
      #tinyurl is not responding properly… Return the original url
      return ‘<a href=’ + newurl + ‘>’ + newurl + ‘</a>’
   else
      return ‘<a href=’ + res.body + ‘>’ + res.body + ‘</a>’
   end
end

That will return a nice linked tinyurl in your view. That is all there is to it.