Debugging shared library issues -
Excellent tutorial.
Are we there yet by Rich Hickey -
AWESOME TALK
This may or may not be relevant if you are using Rails 3.
If you use :include in a finder and try to access it’s association, it will load without an extra hit to the DB. However, you have to explicitly load the name of the association even if it is accessed another way. Assume products (hasmany) skus, and skus (hasmany) units:
class Product
has_many :units, :through => :skus
end
posts = Post.all(:include => { :skus => :units })
posts.each do |p|
p.units # RESULTS IN MORE DB QUIERIES?
p.skus.first.units # WORKS?
end
Oh well.
This was tricky. If you have a web service that is hitting a URL, but you’re behind a firewall, a reverse tunnel with SSH might save you. Assuming you have outgoing access to an open machine, you can do the following:
ssh -R :8888:localhost:2222 host.youhave.access.to
This will forward all interfaces on port 8888 on the remote host (host.youhave..) to your localhost on port 2222. However, SSH by default will not allow remote connections to that tunneled port. To allow that, you have to enable GatewayPorts in sshd_config:
GatewayPorts
Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd(8) binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be “no” to force remote port forwardings to be available to the local host only, “yes” to force remote port forwardings to bind to the wildcard address, or “clientspecified” to allow the client to select the address to which the forwarding is bound. The default is “no”.