I learned recently about min-width and max-width css selectors that allow you to specify certain properties that are applied under a maximum width and above a minimum width. This can enable a flexible layout that works on many different screens without multiple distinct layouts (instead, just CSS). This also makes it relatively easy to spot-test by simply resizing your browser to get an idea of how it will look on different size devices. ...
I’ve recently been curating a playlist on spotify for High Energy Electronic Music so that I could have something high energy with no lyrics, or at the very least very simple ones that were easy to ignore. The big point was to have something high energy that got me into the coding groove. I have to say that it’s worked. Having a driving beat and some hard hits has made it really easy to get motivated to code on. Suggestions for similar artists/songs welcome.
When you’re in the same room, often your communication is done via waving at each other, overhearing a conversation, happening by a desk, etc. It’s accidental communication in many cases, and it’s good. But it can have detrimental side effects to productivity when interruptions can happen at any time. That was the main impetus behind deploying HipChat to our organization–having a way to allow people to communicate without directly interrupting. Let people come to the communication, rather than taking the communication to them ...
Pull Requests are used often in the open source world, but less so on private teams. They are a great way to provide an automatic, team-wide code review mechanism. If your private team doesn’t use pull requests, I’d encourage you to investiage it. Why would you move your team over to pull requests? it provides a mechanism for code and source control review it gives more visibility and accountability to the whole team you can (optionally) restrict access so only trusted members bless the merge What is the Pull Request process like? There are lots of resources about how to submit pull requests out there, but the basics go like this. ...
About a week ago, we had an elusive error that appeared when we deployed our latest app to staging. Suddenly, any submission resulted in a “Stack trace too deep” error that gave no meaningful way to determine where the issue was coming from. We were stuck for a couple of days, but then I was reminded of git bisect. git bisect is a great way to trace down problems to a specific commit for purposes of isolation or blame (though I’d suggest against the latter). Like you’d expect from a programmer, it even searches efficiently, using a binary search, hence bisect. ...
I had a Rails 2.3.X app that I migrated to Rails 3. When I did, I upgraded CanCan and Devise. Suddenly, my delete links weren’t working. I remembered that unobtrusive JS was the default so I hopped into the application.html.erb template and added the relevant javascript tags. ... <head> ... <%= javascript_include_tag 'prototype', 'rails', 'application' %> ... </head> ... Great! Now my delete links weren’t just links to the show action, but when I did click them I noticed that a CanCan error appeared. After some debug statements, it became clear that current_user wasn’t set, but only on the POST/DELETE methods. Hmmm. What could be causing this? ...
Thanks to the RubyRogues Episode on Bundler, I learned the best way to use bundler. You want to always use the “pessemistic” version numbers for a handful of reasons. gem 'rails', '~> 3.0.3' gem 'rspec', '~> 2.7.0' This allows the most efficient resolution of gem dependencies (in this case, any version of rails from 3.0.3 up to and not including 3.1, and any version of rspec from 2.7.0 up to and not including 2.8) and the added benefit of allowing you to easily patch everything safely using only bundle update. ...
If there is one thing I have said over and over again in one form or another, but never seem to learn completely, it’s “Always Fight for Simpler.” Everything could be simpler. Sure, we think it can’t, but it can. Don’t assume you need a feature in an app, a gadget in your life, or a certain amount of money… fight first for simpler. Ask yourself, for any given situation, what the simplest possible solution to the problem is. Maybe it’s not good enough… but maybe it is. Fight for the simplest solution and go from there. ...
About three or four times a year, I find myself wishing my application wasn’t so complicated. I wish I was some stud developer who always made the right architectural decisions and didn’t back myself into a corner. I read about OO ideas regarding change management and coding for change even when you don’t know what that change is and mostly, I find myself baffled. Hindsight is 20/20. I can see easily how the decision that seemed good at the time to make a Model.seed! method that allowed you to specify all the department data in the database AND change it in the app was a bad idea. I can see that allowing users to change values of reports from within the reports, like a spreadsheet without using the adjustment-as-a-line-item pattern is now a bad idea… but we’re 3 years on and it’s just not something we’re going to be able to convince the users to change or the management to invest the money in fixing. ...
I am trying out Octopress as a new blogging engine. I have seen several people use it and I appreciate the lack of PHP :)