Most people know we churn out a good many Rails-based websites. Now one of our own, Ernie Miller, is starting to make waves with his object-based searching gem, MetaSearch. For his efforts, Ernie received a mention on the Ruby5 podcast. Go listen to the podcast, then go check out MetaSearch!
One of the frustrating behaviors of dd is that it provides no feedback about what it is doing. It does however provide a signal (USR1) that you can send to the process that will dump the current progress. Open a new terminal (I use screen) and type:
while true; do kill -USR1 `pidof dd`; sleep 2; done
(NOTE: if `pidof dd` doesn’t work for you, just use the process id directly)
Switch back to the terminal where dd is running and you should see:
9902751744 bytes (9.9 GB) copied, 732.883 s, 13.5 MB/s 9469+0 records in 9468+0 records out 9927917568 bytes (9.9 GB) copied, 734.914 s, 13.5 MB/s 9496+0 records in 9495+0 records out 9956229120 bytes (10 GB) copied, 736.941 s, 13.5 MB/s
updating every couple of seconds.
Capistrano is a tool for automating tasks via SSH on remote servers. It has many uses, I (and many others) use it to deploy their (rails) applications. The best I can tell there is no built in way to deploy a branch from your source code control system. There are a couple ways of accomplishing this. I chose passing in the branch as a parameter to the Capistrano command:
cap --set-before branch=testbranch deploy
Ajax can bring a much more responsive and intuitive feel to web applications. However, many times developers overlook error cases when using Ajax. What if the request fails? In one particular case a user’s session may have timed out before they made an Ajax call. This post describes one such way of handling this in a somewhat friendly way.
I have seen several examples of sending email using oracle with non-ascii characters floating around the Internet, but few seem to tackle sending these ‘special’ characters in both the subject and the body. Many also take a shortcut and use 8bit transfer encoding for the body. I am 99.9% sure that this will work on today’s mail servers, but basic SMTP only really needs to support 3 transfer encodings – 7bit ascii, base64, and quoted-printable.
We had the need to hook up a simple ruby web process (non-rails) to our production apache server. As Leslie Hensley pointed out, fcgi and scgi are on the way out, and mongrel + mod_proxy_balancer is the new way to go. We use mongrel extensively in our rails deploys, but always just used WEBrick to do simple serving. To make a long story short, we had to ask ourselves….is mongrel that much better (and in this case better == faster) than WEBrick?
We were helping a client push more data through their apache/tomcat web application running on a Solaris box and decided to switch from the process (prefork) to the threaded(worker) processing model. When we fired up the new apache we started getting errors like these:
[emerg] (45)Deadlock situation detected/avoided: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
Not good. After a little digging we found that the default AcceptMutex switched from pthread to fcntl between apache 2.0.49 and 2.0.52.
to httpd.conf cleared up the errors and we’ve had smooth sailing ever since.
So not only can you lookup the current volume of Google stock in a spreadsheet (=GoogleFinance(“GOOG”, “volume”)) or find out Roger Clemens’s ERA (=GoogleLookup(“Roger Clemens”,”earned run average”)) you can access those values real time using an open API. I cobbled together a quick ruby program that can retrieve values from a private or public (published) Google spreadsheet.
The recently released IE7 supports a native XMLHTTPRequest object. On the surface this can be considered a good thing and should be commended. However, to the people that erroneously (in hindsight) assumed that…
window.XMLHttpRequest == ! (not) IE
The problem occurs when the code is optimized for non-IE browsers and does not recreate the XMLHTTPRequest object on each event. Back when “window.XMLHttpRequest == !IE” was true, this code worked as expected: IE browsers created a new XMLHttpRequest object on each event and non-IE browsers reused the same XMLHttpRequest object. Now IE7 will correctly process the first event but then fails on the second (and subsequent) requests because you still can’t reuse XMLHttpRequest objects.
We chose to just remove the optimization all together and recreate the object on each event for all browsers. Others may wish to come up with some other check that will allow them to keep it.