When I asked on IRC I was told that the new icon is permanent. It's really nice in my opinion, but I do find it a somewhat odd choice for a text editor.
I founded Collective Idea (http://collectiveidea.com) a successful and growing Ruby shop in West Michigan (Downtown Holland). We are actively looking for programmers, and I know many other companies in the area that are too. The ones I've talked to recently are looking for Ruby, Objective-C, and PHP, but I'm sure there are many, many more.
West Michigan is actually a fantastic place to be a programmer right now. We have dirt-cheap cost of living, beautiful scenery and a number of top-notch software companies working for major companies. (We count Fortune 100 & 500 Companies in our active client list.)
How do you get a job here?
1.) You could have emailed me. My email is on our website, and so are the heads of companies at our competitors. I have interviewed a number of people over the years even when we weren't hiring. I talk with our competitors frequently, so I know who's hiring and will gladly recommend people we can't hire.
Software companies are hiring. Ad agencies are hiring. Manufacturing & Medical companies are hiring. Nobody needs to leave Michigan to get a great job.
Go to any of these. Talk to people. You don't need to know "contacts in the industry" you need to meet people. They'll tell you who to talk to, where to apply, and how to brush up your skills.
3.) Write some code.
In the age of GitHub and SourceForge (who has coders in Grand Rapids and is often hiring http://geek.net/about/careers/) there's no excuse for not having code that you've written. Find some small project and make it better, or contribute documentation. Don't get discouraged if you can't find a project to hack on right away, you will. Blog about it. Talk about it.
Michigan, and especially West Michigan has some amazing programming shops, some of the best coders I've met anywhere, and everyone is hiring. I know many people have moved away, but there is no reason to anymore. This is a great state, a bit underrated, with an under-the-radar software scene that is ready to explode.
Anyone know Ruby and want to work for a Michigan company in a lakeshore town? Talk to me.
I disagree. Cron is meant to run at specific intervals, not at specific, arbitrary times.
In apps where we're using this technique, we may have hundreds or thousands of jobs scheduled at various times in the future (appointment reminders are a great example). Cron would have to check every minute or two, whereas we have Delayed Job already running a queue. They just get pulled in when their time is right.
I doubt your jobs get pulled into the queue. You probably enqueue them and just inform your workers to execute them when the worker's Time.now > the job's run_at. This mean's you may have thousands of jobs in your queue at any moment. An advantage of using cron to schedule is that you won't have as many jobs in your queue at arbitrary times.
I couldn't agree more, which is why I wrote the post ;)
Most of the time we do lots of rapid iterating (we're in Ruby and JS, mainly) and it goes great. That's why I thought it important to highlight when we do it wrong.
That's why I thought it important to highlight when we do it wrong.
I've also had the experience where I pulled out a lot of the refactoring tricks from Martin Fowler's book applied them, then looked at what I did and found it had made it worse! Instead of good code, I had an "anti-pattern" sometimes called "Macaroni." Things were done, like replace conditional with polymorphism, which one would expect to result in well factored code, but instead we just chopped up the code into little pieces that didn't make much sense and fatigued us when reading and debugging.
Refactorings are experiments. Some of them need to be thrown away.
A surprise asset to my refactoring process has been git with its ultra-lightweight branches. When I start thinking that maybe this refactoring was a bad idea, I check my changes so far into a new branch, go back to trunk and start again.
Then an hour or a week later, when I realize my idea wasn't so bad, it's easy to switch back to the branch and continue from where I left off.
Refactorings which have unlimited "Undo" and "Redo." There's also the "Change Log" which is like a DB transaction log for your code state. You don't even need to think to check in a new branch. (Mostly, you save images when you're done for now, or you want to save log-replay time.)
