While trying to build and install PHP 5.4 in a OS X 10.7.5 in order to test Laravel, I found myself updating several things with Homebrew. It seems that one of the things updated was my brew installation of MySQL.
The thing is that later, I tried to boot the Rails console for a project and it puked this fearsome line:
/Users/icwiener/.rvm/gems/ruby-1.8.7-p370@sumproject/gems/activesupport-2.3.17/lib/active_support/dependencies.rb:466:in `load_missing_constant':NameError: uninitialized constant MysqlCompat::MysqlRes
As delicate as installing MySQL in Mac OS X and getting it to work is, I knew this was a bad omen. Yes. I couldn’t make any query using the rails console.
So, after checking the Internet, the first probable cause is that after changing the MySQL installation you would need to rebuild the mysql gem. So, after checking ‘which MySQL’ was in use, I reinstalled the gem with some options:
env ARCHFLAGS="-arch x86_64" gem install mysql -v=2.8.1 -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
Everything went smoothly, but I had the same error when firing up the console. Damn. The next thing I found about it was about the libmysqlclient not being installed or found. But ‘locate libmysqlclient’ gave me three different paths… so it had to be about the library not being visible. After researching, the library is usually looked for in the $DYLD_LIBRARY_PATH. Set the proper path in your .bash_profile (something along ‘/user/local/mysql/lib’) and you’ll get going.
“May you live in interesting times”, they said
You surely know the drill by now: update yaddayaddayadda.
* YARSI: Yet Another Rails Security Issue.
This one is for the IT boys in the dark basements. Love y’all
The results when using df and the sum of du are not the same. Example:
‘Hey! I’m getting a 100% disk usage from df but I know I have free space, I’ve just rm-ed 10GB worth of files.’
The (probable) cause
The df results sync with the actual usage of hd space from time to time. Also, you might have processes that have that file still opened for some reason, even if it’s deleted. Most probably those processes are dead, undead, zombies, infected or whatever you might want to call them. I’ll call them ‘roamers’.
When the computer is rebooted, the roamers are killed along with any other process in the system, and the deleted files are finally purged, but let’s say you can’t afford to reboot the machine, i. e.: you’re working on a server.
What would Grimes do?
Use this command:
It lists the opened files, and the +L1 filter will leave only those which are being used by just 0 or 1 processes. You might also want to add some grep magic to be sure that you are working only with files that are marked for deletion.
$lsof +L1 | grep "deleted"
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
roamer 38 rgrimes txt REG 14,2 51288 0 58754819 /blah/meh (deleted)
On the left you get the process name and pid, so the only thing left to do is to go all ‘kill -9′ on it’s arse. Be careful though, and kill processes only when you’re sure you won’t break anything else or you don’t have any other exits available.
This one is pretty simple too, and very easy. Specify the version of the gems you are using in the Gemfile. Or in your environment.rb if you are into Rails Archaelogism. Wait, SPECIALLY if you’re dealing (or know that someone will) with old projects.
Let’s say you start developing a project and you want to use a gem.
gem "capistrano-tasks" # shameless plug LOL
At that time, you’ll probably just go with whichever version rubygems throws at you. That’s ok. But when you deploy into staging for the first time, make sure to note down the version of the gem that’s being used in the staging machine and specify that version in the Gemfile.
gem "capistrano-tasks", "~> 0.1.0" # shameless plug LOL
You’ll make your life a little easier when going into production for the first time because you’ll be using the same gem version (and dependencies), and A LOT easier for the next guy in line trying to get the project up and running.
Be a good guy and just try to think a little in advance and be nice to the future devs, or your future self. Anyway, it seems that you’re going to need to do this in Rails 4.
Yet Another Rails Security Issue
You know the drill: update yaddayaddayadda.
The “Ruby on Fails” joke seems to be living up to reality lately
Oh BTW, Aaron Patterson has put up a nice post at Tenderlovemaking explaining all about this ongoing YAML issue that is worth reading.
I’ve put up a teeny little gem which compiles some Capistrano tasks I’ve developed and been using for a while. Just to learn how to compile a gem by myself and also how to create a cookbook.
It’s also the first time I make public some of my code, and well, it’s exciting. Forking, testing, comments, suggestions are of course welcome. I’m willing to listen to everything you might suggest, from changing names of symbols, using other commands, or even changing the license. That’s the point of releasing it into the wild Thanks in advance.
You can get the gem at github.com/jantequera/capistrano-tasks. Where else?
I used this article (bit outdated, tho) by Tim Riley and the Webficient Capistrano Cookbook to learn the how-to. The second link provides a gem/cookbook much more suitable for production use, if you’re looking for one. I consider my gem for personal use and learning.
Two weeks ago my friend Juan Pablo helped me refurbish my cv and created a html version of it, updating and upgrading his cv template.
I wanted to have it online ASAP, so I got it uploaded to github making use of the wonderful github:pages engine. Check it out!. Awesome, isn’t it?
I’m also thinking of moving this blog to a jekyll-bootstrap powered blog over at github, but sincerely, I think that wp.com offers more visibility, apart from services like, RSS and social media integration, that are pretty much basic for blogs IMHO. I don’t want to overcomplicate the technical-blog thing just for the sake of being geekier, edgier or whatever.