I came from a Microsoft background, when I was there I complained about some aspects of it, but in hindsight one thing I miss a lot is a good IDE for SQL and database related development. SQL server didn’t have anything amazing, but it did the job and was stable.
I’m a big believer in visualisation and easy visualisation when working with data. It’s there to be used and if you can’t visualise it simply, if you can muck around with it and fiddle and massage it into various shapes and sizes easily then it’s more likely to be left alone. Data that’s left to rot is like leaving gold to rust. If gold rusted.
In short data is valuable, but only if it’s used.
In my quest for tools I’ve tried a few and found none that I would actually pay for, except the one I’ve been using now for a couple of months without a problem. DBVisualiser Free edition, I’d pay for that. It’s lucky too because they make a paid version with a bunch of extra features.
I’m always on the lookout for better applications to improve my performance and more importantly my enjoyment at work. So far this has been the closest application I’ve found to make MySQL a joy to use on the Mac. The free version does 99% of what I want to do, the pro version just seems to add features to make life even easier.
I’d urge people working with a database on the Mac to give DBVisualiser a try.
Last week Gregg Pollack from the Rails Envy Podcast put out the call on Twitter for reviews of their latest product, the Ruby on Rails 2.2 Envycast. I was happy to oblige and had been looking forward to checking out their unique take on screen casting for a while. Here’s what I thought.
Is it really a screen cast?
Firstly, I don’t even know if it’s correct to call it a screen cast. The viewer is not presented with a computer screen once during the 44 minute presentation. Most screen casts record the presenter’s computer desktop and have an audio commentary to accompany the video. Gregg and Jason have instead gone the “weather-man” approach and are using a green-screen as their canvas. This has some immediate benefits, but also has some downsides.
It develops the duo as the “face” of Envycasts. I first learnt of them through their audio podcast but they’ve done video before. I think this is important as it presents a teacher-student situation, and I’d expect there’s a bunch of psychology proving why face-to-face teaching succeeds. I think it works well for them, but would expect that other tech-screen casters might not be as comfortable in front of the camera.
The green-screen also allows them to manipulate the background as they see fit. For the viewer of this episode that means you’ll be treated to a world tour as they “travel” to various capital cities around the globe. It allows them to use their unique style of humour with ease too. I actually laughed out loud at a few moments, and enjoyed thembeing chased by the large ball of yarn in particular.
More importantly though, the green-screen also means that transition effects and attention-grabbing techniques (like exploding or rotating text) can direct your attention to the exact part of the code they’re discussing.
By not filming a mouse-cursor style screencast they’ve chosen to give up the opportunity to pass on subtle information outside of the scope of the specific topic that viewers might find useful. What do I mean? I’ve picked up on keyboard shortcuts or other techniques people use in their day-to-day programming by watching traditional screencasts. The best example I’ve found of this is Ryan Bates’ excellent Railscasts. I liken it to looking over the shoulder of a seasoned developer – you’ll pick up on nuances which are sometimes just as interesting.
Both Gregg and Jason speak clearly and are presenters that I enjoyed viewing. As an Australian, I didn’t find their accents overpowering in anyway.
It’s all about the content
The actual content is conveniently split into chapters (I viewed the 260MB MOV) which makes navigating between topics easy. I viewed the video on both a MacBook Pro laptop and 42″ plasma. I found the colours sometimes a little dark on the laptop but didn’t have the same issues on the plasma display. I suspect that my colourblindness was to blame :)
I would have appreciated a wide-screen format for the plasma, though I presume that the majority of viewers are watching on a computer screen.
The content is broken into the following seven sections:
ActiveRecord
ActiveSupport
ActionPack
ActionController
Railties
Internationalization
Performance
The 38 minutes (85%) are spent focussing on the code-heavy components which make up the changes to Rails 2.2. The examples given are very clear and consistent across the sections and I found the afore-mentioned transition effects helpful at tracking the exact part of the code the presenter was discussing. Your eyes are drawn to the moving parts of the code. Because you’re looking at Ruby code there’s nothing that will hurt your brain, or eyes.
The last few minutes in the presentation are spent discussing the other things that have changed with Rails 2.2 in details beyond just code examples. I enjoyed Jason explaining why gems are preferred over plugins, and Gregg’s explanation of etags and how they’ve changed in Rails 2.2 was fantastic.
Wrapping up
I was skeptical that this format would would for a such a technical topic but I’m glad to say they boys pulled it off. Their lame jokes are sometimes actually funny, though I think I’ve heard enough about Rails not scaling to last me a lifetime :)
My final thought: above all else they jammed a stack of detail into an easily-digestible format that was entertaining and informative. If you’re working with Rails then you really should be checking this out.
This took me a few minutes today to work out and find an answer on Google so I thought I’d share it.
I had a string that I was posting from a form and while Firebug on the client said that the string was valid, on the server side PHP’s json_decode() function was returning me a NULL indicating invalid JSON. I spit out the string using good old var_dump() and I could see straight away that I would need to strip some slashes from it, but I couldn’t figure out why.
I don’t like to simply know how to fix something, I like to know why it was broken in the first place! A bit of Googling gave me the answer, it turned out to be because of the magic_quotes setting in PHP.
Instead of just wrapping everything in a stripslashes() call I decided to write a wrapper function that will take into account whether magic_quotes is on or off. It will also allow me to do whatever I want later one if I wanted to parse a particular type of data or something.
Here is the code. As you can see it’s nothing fancy, but it works and hopefully it saves people some time.
function _json_decode($string) {
if (get_magic_quotes_gpc()) {
$string = stripslashes($string);
}
return json_decode($string);
}
We have deployed a new Zimbra server to gradually replace our existing mail server. We’ve moved all of The Frontier Group’s mail over to use the new system, which gives us a good chance to run it through its paces before moving clients over.
I have been signed up to a mailing list of a Perth-based mining company, and with complete (and illegal) disregard for the Spam Act of 2003, their removal process doesn’t work. They should really use Raven Communicator.
I have rules in my mail client on my Mac that filter out this nonsense when it’s open. However, I’m also using my iPhone to retrieve mail, and the mail filtering rules you set up in Mail on your Mac don’t translate to the handheld.
All of these combine into a situation where I needed to have mail filtering applied before it hits any of my clients; iPhone, Mac Mail or the Zimbra web interface.
Thankfully this is trivial to set up in Zimbra. You login, select the Options > Mail Filters tab and create filters as necessary. The interface is very self explanatory, and any filtering rules are applied before you see your mail.
I can rest assured knowing that this mail is being marked as read and funneled into my trash.
Sometimes you’re working on a server remotely and the ssh connection gets interrupted. Usually when that happens, ssh will stall until the socket times out and you’re stuck with an unresponsive terminal. To get back to the terminal from your stalled ssh session, use this key sequence:
Firstly, I don’t even know if it’s correct to call it a screen cast. The viewer is not presented with a computer screen once during the 44 minute presentation. Most screen casts record the presenter’s computer desktop and have an audio commentary to accompany the video. Gregg and Jason have instead gone the “weather-man” approach and are using a 
The actual content is conveniently split into chapters (I viewed the 260MB MOV) which makes navigating between topics easy. I viewed the video on both a MacBook Pro laptop and 42″ plasma. I found the colours sometimes a little dark on the laptop but didn’t have the same issues on the plasma display. I suspect that my colourblindness was to blame :)