Had an issue a while ago where running the capistrano deploy common would sorta run capistrano but always got the following error.
The deploy has failed with an error: No live threads left. Deadlock?
The quick and easy answer is to make sure to prefix the cap command with bundle exec. So it should look like
bundle exec cap production deploy
There is some strange behavior here that I have not found the cause of yet. Something about how bundler executes ruby scripts. So just a heads up.
One of the refrains that we all hear when the topic of code comments comes up is the refrain “My code is self-documenting.” On the surface this refrain makes sense, why write more than you have to. Unfortunately the way this is usually implemented results in the baby being thrown out with the bathwater. Leaving us in a worse off position than we were with too many comments.
I’ve never met someone who would argue that the code we create should be difficult to understand. That the how the code executes should be hidden or where the flow of control goes. Our code needs to be easy to understand so that as we maintain it in the future we do not have to rewrite entire classes just to add a bit of functionality.
“Comments should explain WHY” to paraphrase the colleague of mine who gave me this pointer.
How often have you come across some code that works but does something in a crazy way when a much more simple option is clear to you? Only when you implement your simple solution suddenly bugs appear and you finally understand why those lines existed.
An example of a superflorus comment can be found in the .NET Framework Reference Source of the String class. Range check everything. Yes, I can see that’s being done. You’ve obviously thought it important enough to point out but why? Why is it important to note that you are doing all range checks? A comment like this only results in more questions while answering none.
This sort of situation is where code comments become invaluable and will save you and your colleague’s hours in the future. Spend the time to explain why you made the design decisions you did. When you apply a workaround that is strange explain why you did this instead of the more ‘obvious’ solution.
A good example can also be found in the .NET Framework Reference Source. But this time in the DateTime class. That DateTime adjustment underneath the code is not clear at first glance why you would want to add double the day remainder in milliseconds when the time is negative. However when we read the comment above it explains why we would want to do such a thing and even uses a clear example to demonstrate the way.
This concept of explaining why finds even more value when it comes to commit comments.
How often do you see an odd design decision but when you look into the history of that file the comment is “Added files.” A comment like that is less than worthless because not only does it tell you nothing new but you get irritated or angry and it sits with you as you try to fix whatever is wrong. Again, explain WHY you have made the changes you have. Explain why you chose a pattern or design over another. When writing these comments imagine that 12 months from now you will be coming back to this. When we can barely remember why we made choices a few weeks ago how can we expect to remember why we made choices 52 weeks later?
So to conclude. “Self-documenting code” should be applied to only the how something works. In no way can it show the why changes were made of designs chosen. When you come back months or years later the why is more valuable than any amount of how or what comments.
If you've ever been stuck with the problem of trying to build anything but a simple regular expression you know how painful it can be getting it to match just what you want.
When developing for .NET on Windows I was introduced to a brilliant free tool called Rad Software Regex Designer that gave you the ability to provide an example of the text you wanted to match and an area to slowly build up your regular expression while getting instant feedback on what it was doing. It even has dialogs to add specific regular expression commands in case your proficiency with regular expressions isn't high or you just forgot how to create a non matching group. After moving to OSX for work I went looking for a similar tool for the Mac. And after a while I found it.
RegExhibit is a GUI tool of OSX that uses the Perl regular expression library to help you build regular expressions. This should be fine for any other languages that use a PCRE library but make sure you check before deploying. The core part of the program are two text areas. you place an example of the text you want to match into the lower area and build up your regular expression in the top are. There are even tabs for doing matches and splits but you'll likely find yourself in the match tab for most of time. However it doesn't offer the same built in dialogs like the Rad Software Regex Designer so make sure you've got a regular expression reference handy.
This is a great tool that has saved my sanity several times already and I do recommend to anyone that has to play with regular expressions and is developing on the Mac.
Well recently I had the fun task of using Ruby on Rails' ActionMailer to create some automated emails to send out to users. At some point it was decided to attach the original email we received from the user to the notification email we were sending out to the user.
Now you would think that using the attachments method provided by ActionMailer would make it a easy as just giving it the file you wanted to add. Turns out it's like that for Ruby on Rails 3, not for 2.
The most infuriating thing was that if you use the attachments method then the method you called attachments from will not render the default view template it would normally. This means you have to explicitly call the render method.
Instead of putting it out all nicely I'll just link to a blog post from ELCtech.com that explains it well. http://www.elctech.com/ -- [ActionMailer] Multipart emails with attachments