My thoughts on a process modeling tool called Hero that I stumbled upon while reading the Rails 3.2 Development Standards Guide.
Have you ever screwed up by forgetting to add an attribute to attr_accessible in a ActiveRecord model? Using some simple tools I show you how you can parse your production logs to fix this problem.
If you’re not already using formtastic, you need to check it out. I’ll give you a short run down of formtastic, but I suggest checking the README as it is very comprehensive. Then I’ll go on to explain how we extended formtastic with jQuery allowing us to keep our form construction code nice and simple.
We've been using Collective Idea's fork of Delayed Job at RecruitMilitary for quite some time now. We've processed over 2 million jobs and we're extremely reliant on it for the day-to-day operation of our site.
For a long time the compelling reason behind us using Collective Idea's fork of delayed_job was the built in support for daemonization. This functionality is added via the daemons gem, however, it is not without problems. We use monit to kill memory hungry workers and have frequently experienced issues with workers not stopping, deleting their pid file, and another duplicate worker ends up starting. Before you know it, your server is freaking out because there are 4 times the number of workers running than you want.
This has been ranted about by others many times and I never really understood the big deal. Now I do, especially after it shaved 5 seconds off our suite of specs. After some research I found out we were requiring our spec helpers in a “bad way.” Most of this is because of my own doing, but I thought I’d share with you guys. There were probably 4 or 5 variations of the syntax used to require spec_helper.
I really wanted to remember what Pratik had to say about writing good factories in his Rails Summit talk so I’m putting it up here as a reference.
After reading The Simplest Thing that Could Possibly Work I couldn’t stop thinking about how Ward Cunningham describes the difference between problems and difficulties.
A friend of mine once said that there are problems and there are difficulties. A problem is something you savor. You say, “Well that’s an interesting problem. Let me think about that problem a while.” You enjoy thinking about it, because when you find the solution to the problem, it’s enlightening.
And then there are difficulties. Computers are famous for difficulties. A difficulty is just a blockage from progress. You have to try a lot of things. When you finally find what works, it doesn’t tell you a thing. It won’t be the same tomorrow. Getting the computer to work is so often dealing with difficulties.
As a software developer I love to solve problems, yet I become frustrated when dealing with difficulties. The more I think about it, I feel like frustration is a better word than difficulty. In fact, one of the definitions for frustration from Apple’s Dictionary is:
frustration |frəˈstrā sh ən|
the prevention of the progress, success, or fulfillment of something
I don’t mind slowing down, but I hate stopping progress. As I work through practicing TDD/BDD, I find that being able to slow down and take baby steps allows me to reduce the number of frustrations in my day. I shudder any time I have to touch code without tests/specs because I am afraid I’m going to break something and not know it. I’m not sure how I lived without tests, I know I spent a lot of time clicking around doing testing in the browser.
Depending where I am at I have three possible monitor configurations for my MacBook.
- External display only
- Laptop display only
- External and laptop display
Each time I change between these three workspaces I have to manually move the windows to the correct position for that particular configuration. This can become extremely annoying, especially when you're as OCD as I am. I can't even contemplate how much time I've wasted putting each window in its "perfect" position.