It seems common that development tasks or projects take much more time than expected. My manager recently pointed these out to me:
The 90/90 Rule - “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” — Tom Cargill, Bell Labs
Hofstadter’s Law - “Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
I’ve been playing Minecraft for a little while now. Want to see what else this thing can do, so I want to get access to console commands. This is a challenge it seems, so I’m going to document how it’s done here.
I’m currently using Minecraft version 1.4.7. I just downloaded the latest build/snapshot (possibly unstable yet likely compatible) from Minecraft-Console by simo415 on Github. A prerequisite to this mod running is modloader, which states that it’s only for version 1.4.7.
Sometimes it really counts to restructure the queries made to your MySQL database, especially so that they do make use of indexes which are present on the table.
I just want to put this here for future reference.
There is a version control branching model known as Git-Flow, which is very similar to the model used on the team I work with. See A Successful Git Branching Model. This seems to work well for teams that make several separate commits to the ‘develop’ branch, with different versioned releases provided to the ‘release branch’ that may or may not have been tested and put through a quality assurance process, and finally only major updates (not releases) merged into the ‘master’ branch and tagged with the appropriate version number.
It’s often difficult to work with Ruby Gems that your Rails application depends on because the source code for the gem itself is packed away in a gem directory. I’ve often found myself using the command ‘rvm gemdir’ to output the path to the gem directory that my application is using, changing to that directory, and opening the source using Textmate. This is a time consuming process.
Instead, it’s useful to simply unpack a gem into your Rails application so that it loads from the vendor/gems directory. I’m currently using the following command to unpack the RefineryCMS gems into my Rails app for reference.
I’ve been telling people to check out CodeSchool.com because it has well laid out interactive courses that you can take to learn advanced web development technologies (jQuery, Coffeescript, Rails, etc).
It turns out that CodeAcademy.com covers those languages.
Of course not just anyone can be a web developer, but if you’re nerdy and this stuff excites you, then go for it. I have a job working in San Francisco as a professional developer, doing Ruby on Rails programming. No college. Just experience. Just takes will and determination, and the effort to get experience even if it means taking a pay cut for a while.
If you’re looking for something a little more low level, like algorithms or an intro to computer science, check out Udacity.
I’ve found that there is trouble working with a Spree extension when your gem set does not include the gems included with the Spree gem itself. I discovered this after generating a Spree extension, confining the extension to it’s own gem set using RVM, and then running ‘bundle install’ based on the Gemfile/gemspec configuration of just the extension itself.
To overcome this, I recommend making a folder named ‘spree’, then configuring that folder to use a shared ‘Spree’ gem set.
Since then it appears that the most automated way to create a gem is by using Bundler, via the
$ bundle gem my_tools create my_tools/Gemfile create my_tools/Rakefile create my_tools/LICENSE create my_tools/README.md create my_tools/.gitignore create my_tools/my_tools.gemspec create my_tools/lib/my_tools.rb create my_tools/lib/my_tools/version.rb Initializating git repo in /Users/jsmith/Sites/my_tools
When working with files, you can open them in one of several modes.
You can find the description of these modes in the IO documentation.
I was working on a gem a couple months ago, and it came time for my boss to do a code review before we install the gem on another teams system. My boss pointed out that there were areas where I was returning FALSE, and baking in a lot of conditional statements and other handling, instead of using Ruby’s built in feature of error handling, which is designed to bubble exceptions up the call stack. He informed me that in situation that are not expected to occur, it’s best to raise an exception to halt execution and report the issue. He even recommended that I read Exceptional Ruby, a book devoted to the subject of proper exception handling.