Just a quick little post in case some people out there don’t know about the note keeping feature in Rails.
There’s a rake task called “notes” that will search your codebase for any #TODO, #FIXME or #OPTIMIZE annotations and print them in a pretty list, like so.
$ rake notes
app/controllers/submissions_controller.rb:
* [ 38] [TODO] Write destroy actionapp/models/submission.rb:
* [ 5] [TODO] Integrate with Amazon S3
I’ve recently had to set up XDebug with MAMP Pro on OS X and it’s a little unintuitive. The instructions over at MacGDBp helped me tremendously, and they’ve made a nice debugger.
The latest version of MAMP/MAMP Pro comes with the XDebug binary already bundled. The unintuitive part is that you’ll need to edit your MAMP Pro php.ini file to point to the xdebug.so file in the MAMP folder. While MAMP Pro is open, go to File -> Edit Template -> PHP -> (PHP Version you use), and add the following lines to your php.ini.
; XDebug
zend_extension=”/Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so”
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
Just a quick post to share this nice rspec presentation.
I wanted to take a moment to share the slick features Jeweler has, and mention its tight integration with Github. Installing jeweler and setting up your Github credentials is simple.
$ gem install jeweler
$ git config --global github.user myUsername
$ git config --global github.token myAPIToken
After it’s set up, invoke jeweler with the following arguments to create a new project. Here, I’m setting it up with rspec and cucumber for testing and having a github repository automatically created.
$ jeweler --rspec --cucumber --summary "My Awesome Project" --create-repo myawesomeproject
create .gitignore
create Rakefile
create Gemfile
create LICENSE.txt
create README.rdoc
create .document
create lib
create lib/myawesomeproject.rb
create spec
create spec/spec_helper.rb
create spec/myawesomeproject_spec.rb
create .rspec
create features
create features/myawesomeproject.feature
create features/support
create features/support/env.rb
create features/step_definitions
create features/step_definitions/myawesomeproject_steps.rb
Jeweler has prepared your gem in ./myawesomeproject
Jeweler has pushed your repo to http://github.com/sensae/myawesomeproject
You can optionally enable your project in the Travis CI dashboard as well to get continuous integration testing and email notifications as to your test suite’s status. All this together makes it almost effortless to create new ruby projects and scripts. Couple this with Thor for easy command line arguments, and you’ve got a recipe for making awesome shell scripts at a whim.
Unfortunately I’ve been bombarded with comment spam over the last couple months. I’ve turned on Akismet, but if I’m not successful in catching more of the spam automatically the comments feature will likely be disabled.
I’ve recently discovered the wonderful git tool known as rebase (before I had just merged everything, making an awfully ugly commit history tree). Rebase is a git command which detaches your feature branch from the last common ancestor commit of another tree, and reapplies it at the head of the target tree. I’ll demonstrate with some images after the jump for more clarity.
I’m a pretty avid linux user, and I try to minimize the time I spend in Windows, even for a game as fun as Dwarf Fortress. I was very happy to hear that there are linux packages available for the game now, as that wasn’t always the case. If anyone reading this hasn’t yet played Dwarf Fortress, I implore you to grab the game from their main site and follow along.
Unfortunately, the in game GUI for managing dwarf tasks is, to put it softly, abysmal once you’ve got a decent sized fortress. That’s where Dwarf Therapist comes in, which is a great third party dwarf management tool. If you’re on a debian-based distro, they offer debian packages which makes installation trivial.
However, ArchLinux users aren’t so fortunate in terms of an easy installation, as Dwarf Therapist must be compiled. However, this is actually a benefit, as the current version of DT also has a very annoying bug in which custom professions do not work. What follows is a guide to compile DT for ArchLinux, and in the process apply a patch during the build that fixes the custom profession bug.
I know it’s been a long time since I’ve written anything here. I honestly haven’t been up to anything interesting, expect more posts during the summer.
I recently posted a snapshot of my current Boebot build. I wanted to take the opportunity to write a longer post about my brief experience with both the Vex robotics system and Parallax’s offerings, most notably the Boebot.
My team had the opportunity in my robotics class to switch from the Vex platform to the Boebot platform, and we jumped at it. This highlights the general attitude that I and my team had regarding Vex.
The restriction of using EasyC for programming the Vex units proved to be a large stumbling block. As I said in an earlier blog post, I see the utility of providing an easier platform for programming, but it becomes a headache for competent programmers. Additionally, the only true programming API for these units is an open source project which hasn’t been maintained for years and primarily runs on FreeBSD. The nuances of other nix-based platforms causes major problems in the proper compilation of this library, and as such I was only able to use it in a FreeBSD virtual machine. This causes a large gap in usable tools versus target users, as EasyC is too watered down and the OpenVex library I would dare say is too complicated to easily set up and use for the average programmer without a competent understanding of Unix systems. I won’t be going into further depth about how I was required to configure my programming environment, because even operable it was clunky, unwieldy and we quickly moved on to the Boebot.
On the other hand, the Boebot provides unique challenges that I feel more accurately represents the difficulties of robotics. It utilizes the Basic Stamp 2 micro-controller, and programming for this platform involves writing in a decently flexible Basic-style programming language. Additionally, there is virtually no API to speak of, for good reason. The configuration of the boebot is much more flexible because of the hand wiring required, and programs for the boebot are concerned with toggling voltages on pins and communicating over serial with other modules. I feel that this allows for a much more broad skill set to develop versus learning on the Vex system. Instead of issuing a single command to move a motor at a certain speed, such as on a Vex unit, a BS2 program would be required to send high voltage pulses at different intervals to control the speed and direction of the included continuous rotation stepper motors. Instead of hiding away the basic electronic functionality of the robot, this bare-bones approach allows the user to control every functionality of individual circuits, increasing creativity and the fundamental understanding of the basic principles and pitfalls of robotics.
I know this post sounds like simply a plug for Parallax and their Boebot, but I feel that they’re put together a superior product and I feel this is apparent in the usability and flexibility of each platform. While on the Vex platform, additional functionality can only be obtained by purchasing more modules. While this is true to some extent on the Boebot platform, a simple trip to Radioshack to purchase additional electronic components is a viable option. To highlight a specific difference in attitudes and platform openness, one only needs to look at the offerings for shaft encoders. On the Vex platform, shaft encoders are standalone units that must be purchased. While it is true that Parallax sells shaft encoder add ons for the Boebot, the wheels included with the unit already have slits for an encoder and all documentation for the encoder units is freely available in PDF and ZIP formats. A cunning individual would be able to take some wires, infrared LEDs and receivers and rig up their own shaft encoder solution.
In summary, the Boebot is a much more pleasant and flexible platform to work on, and I’m glad we had the opportunity to utilize it in place of the Vex system. As an additional plus, there are currently maintained community tokenizers (compilers) for the PBASIC syntax language that the micro-controller on the Boe-bot uses. The Vex EasyC IDE is only available on Microsoft Windows, and as I’ve mentioned the only community compiler/API for the platform is a stagnant library which only compiles nicely on FreeBSD. I dare suggest this also potentially highlights the popularity of both platforms in the hobbyist robotics community.
Just a quick snap my girlfriend took of my current boebot build with a Hitachi HM55B compass module, LED and pushbutton. I might upload a schematic sometime.
