Team-building outing for the Ruckus marketing team. My first step toward my skydive! Woot!
Category: work
With the new computer setup I have at work, I needed to have one of my monitors rotated 90° so it would fit until a better solution was attempted. The desktop wasn’t rotating though because I hadn’t installed Samsung’s MagicRotation software. So I did.
After doing so, I noticed that the context menu on my desktop was way screwed up. All the text had shifted over to the right and was unreadable.
14 feet to smoke
I came back from a weekend away for my birthday to find my cube looking like this. I have awesome coworkers.
[youtube:http://www.youtube.com/watch?v=zuG0tOrSrOU]
Inspired by the article Block a Website for Everyone But You over at CSS Tricks, I thought I’d post my way of blocking people from accessing my websites while I work on them.
Chris Coyier over at CSS Tricks uses the following code in his .htaccess file to block visitors.
RewriteEngine On
RewriteBase /
RewriteCond %{REMOTE_HOST} !^71\.225\.113\.171
RewriteCond %{REMOTE_HOST} !^71\.185\.239\.212
RewriteCond %{REMOTE_HOST} !^69\.253\.223\.254
RewriteCond %{REQUEST_URI} !/comingsoon\.html$
RewriteRule .* /comingsoon.html [R=302,L]
What he’s doing there is checking for specific IP addresses that are allowed to see the website but everyone else is sent to the “comingsoon.html” webpage. This is great for people who have specific IP addresses but if you’re behind a proxy like I am at work then everyone else with you behind that proxy can still see the site.
I find it much easier to redirect everyone but check for a custom cookie that I can set using the Webdeveloper Firefox extension. That way I can check to make sure that the redirect to the maintenance page is actually working. Here’s the relevant code that I use (taken from a RoR tutorial of old)
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteCond %{HTTP_COOKIE} !^.*access_cookie=1.*$
RewriteRule ^.*$ /maintenance.html [L]
where the text “access_cookie” (sans quotes) would be whatever cookie name you want to use. I just create a “session cookie” set to a value of “1” (or whatever you want to make it) and check for it’s existence.
That gets around the problem of DHCP granted or spoofed IP addresses. Sure a cookie is easy to add but if you make the name and/or value sufficiently difficult to guess, no one is getting in.
Now just add your cookie.
Note in the image that I have set it to be a “session cookie”. This helps when you forget to delete the cookie. Just close your tab (FF) or browser (IE), reopen it and the cookie will be gone.
Oh yeah. The other thing that my .htaccess code does is, on the first line, check for the existence of the “maintenance.html” file. I don’t want to have to add and remove this code everytime I want to take the site down. It’s much easier to just have this code permanently in my .htaccess file and then upload the file that people will see when the site is down. I then delete it when the site is ready to be reopened. This is all performed using a custom Capistrano command that I run when I’m ready to deploy a new version.
note to self re: git unpacker error
when you get an unpacker error “unpack failed” and git is being RIDICULOUSLY CRYPTIC (as usual) about it’s error, try this.
git repack remote/origin/master
I’m sick of pulling my hair out over this.
I recently started playing around with the log_buddy gem for Rails and because my development machine is on windows, the “d” method wasn’t playing nice with some paths. it didn’t like paths that included the drive letter.
this is a sample of a line that would cause log_buddy to barf. it just so happens to also be the line that causes the error. 🙂
c:/ruby/lib/ruby/gems/1.8/gems/log_buddy-0.0.5/lib/log_buddy.rb:98:in `read_line'
the original line looked like this…
file, line_number = frame.split(/:/, 2)
the fix is to replace that line with
file, line_number = frame.reverse.split(/:/, 3)[1..2].map(&:reverse).reverse
yeah. ugly, and maybe could be written better but it works for me.
now if only I could get log_buddy to output good inspections of objects I toss to it… like “current_user”. I’m prolly using it wrong right now, but this isn’t helpful…
current_user = '#<User:0x47143d8>'
just saying. 🙂
UPDATE: I monkeypatched log_buddy to fix this functionality. I created a “RAILS_ROOT/lib/log_buddy_extensions.rb” file with the following code.
class LogBuddy
private
# Return the calling line
def self.read_line(frame)
file, line_number = frame.reverse.split(/:/, 3)[1..2].map(&:reverse).reverse
line_number = line_number.to_i
lines = File.readlines(file)
lines[line_number - 1]
end
end
and I figured out that the “current_user” line above shouldn’t be …
d { current_user }
it should be
d { current_user.inspect }
that outputs what I want …
current_user.inspect = '#<User id: 1, login: "matte", email: "matte@localhost", crypted_password: "...", salt: "...", created_at: "2007-08-30 18:23:32", updated_at: "2008-07-08 18:57:45", remember_token: "...", remember_token_expires_at: "2008-07-22 18:57:45", name: "...", password_reset_code: nil, company_id: 2, active: true>'
My view at ‘work’ today
XSendFile note
Note to everyone using Apache and the XSendFile module. If you’ve included the module and are getting 0-byte files, like I was today, make sure you have the following lines in your VirtualHost config
XSendFile on
XSendFileAllowAbove on
The website needs to know you want to use the module. Duh. 🙂