The latest news, project announcements, etc.
I'm pretty excited - I just sent my first circuit board layout off to Fritzing Fab
! (I mean, I've probably messed the header holes or the through connections or something - it is my very first attempt - but I'm still psyched.)
I've got a pack of headers and LEDs coming from Little Bird Electronics
to drop into the board when everything arrives, then it's just the fun parts - soldering and programming. :)
If you have any interest in Arduino you can probably tell from the picture that it's designed as an extension shield - if all goes according to plan it will drop into place on top of my existing Arduino Uno.
I noticed recently that Mozilla are running a competition
to create JS games with Goo Technologies' new toolkit
, so I thought I'd try it out. (It has a lot in common with Unity3D, so I thought I'd be able to adapt a few ideas across and have *something* in a single, time-bounded session.)
It was great practice for my JS skills, and I learned a lot about serious web apps - but mainly I learned the difference between a good JS library and a *great* JS library.
My experience with Unity has always been - if I need something, there's documentation for it, and MonoDevelop can autocomplete for me in C#-land, giving me a super easy way to explore the API. The Goo Engine, on the other hand, only seems to be available a minified JS file, and the documentation is sparse to say the least, making discovery incredibly difficult. This was thrown into strong contrast when I decided to fold in a physics library, and chose CannonJS (which is actually bundled with Goo): Cannon has significantly more readable documentation, and is also available unminified, so I could just jump into the code to unpick some misunderstanding or bug. (This is a habit I've picked up from Ruby on Rails - learning and debugging by just digging into the library code directly.)
Goo, in their favour, provide some recipes for various common tasks
- but these are inconsistent, and if your problem isn't covered, you're out of luck. It all points to a library that has grown incredibly fast - they have an impressive amount of functionality (a substantial chunk of the core Unity stuff, I suspect) but the rest of the project is struggling to keep up with the rapidly changing code. I'll certainly be following their progress, and look forward to playing with the Goo Engine again when it's a little more mature.
I've had the idea for an animated cube character for a long time, and recently I finally built a basic version in Blender
Since then I've been experimenting with a few different things in Unity3D, resulting in this Cubiques Prototype
It's my first time using Unity's particle effects and animation state tools - I'm hoping to add more animation behaviour, and ultimately expand this into a game.
My most recent narration has landed on Protecting Project Pulp #59
- 'The Opener of the Way' by Robert Bloch is, "A tremendous tale about the dread doom that overtook an archeologist in that forgotten tomb beneath the desert sands of Egypt". Enjoy. :)
Chronic and Chronic Duration are super useful gems for parsing natural language descriptions of dates into Ruby objects (DateTimes and Fixnums, respectively). They're both popular with Rails developers, but when new developers ask about integration into their app, the answer is usually 'roll your own
After adding support by hand in this manner a few times I knew it was time to break my work out into something I could re-use. Thus, Chronorails
. Let's start with an example.
For a hypothetical Rails model:
class RomanticMeeting < ActiveRecord::Base
attr_accessible :length, :start # Integer and DateTime DB fields, respectively
chronic_field :start, :required => true
…include the accessors module, and configure Chronorails to wrap your attributes with either Chronic or Chronic Duration virtual attributes.
Then in your form:
<%= f.text_field :chronic_start %>
<%= f.text_field :chronic_duration_length %>
…you can use the virtual attributes for your fields, entering natural language date and duration information that will be parsed into the regular fields (or will generate validation errors).
The ‘required’ option prevents setting the attributes with blank values; the ‘validates’ option controls the generation of validators (defaults to true) and the ‘accessible’ option controls the generation of Rails 3 ‘attr_accessible’ calls (also defaults to true.)
I've workshopped this concept and code with a few developers, now I'm hungry for feedback from a wider field. Let me know if it suits your needs, and preferably, if the code inside makes sense. Fork it on github
and have a play. :)
Brand New Media
's web department works primarily in Ruby on Rails, and Rails apps (like all apps) always have a certain amount of configuration. Host names, API keys - there's always some settings you want easy, central access to, or need to vary for different environments.
Rails' default behaviour is to use a central code file (application.rb) and a series of per-environment code files (development.rb, production.rb) for configuration, and that will serve the needs of a lot of Rails apps. Once you outgrow that, however, there's a lot of options - I personally like railsjedi's rails_config
, which employs a structure of YAML files to provide a clear and expressive way to capture large amounts of configuration data. One feature I particularly like its concept of 'local' configuration files
- files that capture install-specific (particularly, developer-specific) configuration, keeping it out of the code repository where it might clash with other developers set-ups.
The next level beyond this, though, is instancing - deploying the same application multiple times, with configuration tailored to each instance. At this point another of rails_config's features comes to the fore - customisable configuration paths. The pattern we decided to pursue was to set an environment variable for each instance, and use that value in in the configuration stack to find and load an instance-specific configuration file. This needs to happen after rails_config has been initialised, though, so a naive approach would be to add this logic into our application.rb, in an after_initialize block.
But this quickly leads to a chicken-and-egg problem - in the configuration stack we're both setting up rails_config, and attempting to use information from it (for example, configuring the excellent Devise authentication gem
for Facebook authentication requires the credentials of our instance-specific Facebook application.) We obviously need a more fine-grained approach to our initialisation process - one that will allow us to knit our instance configuration into the initialisation process at the right point (most naturally right after rails_config initialises itself.)
Luckily, Rails gives us this fine-grained access in the form of initializers
So here's an example of an initializer that solves the problem I've described.
class Application < Rails::Application
# Normal Rails app configuration
initializer :add_instance_config_to_rails_config, :after => :load_rails_config_settings, :before => :load_environment_config, :group => :all do
Initializers allow us to pick a place in the initialisation stack and insert ourselves there, based on the named steps described here
. In this case, we're creating a new step (add_instance_config_to_rails_config) and inserting it before the default Rails environment load event, but after
rails_config's own internal custom step.
I'm writing this mostly to remind myself that, despite the frustrating lack of gender diversity among technical workplaces, I think it's getting better, and I should remember the positives while working to overcome the negatives (like the men I've had to remind not to use the word 'rape' casually...)
For instance, in my career as a web developer:
- The first place I worked (Fraynework Multimedia) was a technical company run by and mostly staffed by women,
- The second place (MyInternet) had a female sys admin,
- The third place (Obsidian) had a female developer,
- My current workplace (Red Ant) recently acquired a female developer,
- I've worked with quite a few power-house female project managers who were very tech savvy, and
- I've just discovered two very technical women working in quite different fields - Doctor Kristen Stubbs of the Toymaker Project and Garann Means (a web developer who I discovered via her work with Node.JS) - who together inspired me to write this post.
So I'd like to applaud all the technical women in my life who've stuck it out in what can be a less than inviting field - I think our work is a lot richer for your participation.
Just started playing with MongoDB
(in association with a new NodeJS
project - more about that later) and I've noticed a 'small loveliness' in the mongo command line client - brace-highlighting.
This might seem like a small thing, but it makes it that much nicer a tool to use, and it's a level of attention-to-detail that bodes well for the rest of the tool. Bravo, guys. :)
I've been wanting to model this up for a year or two now (and gen'rally wanted to up my Blender skills while I was at it) so I was super happy to get time yesterday to sit down and have a hack at it.
...and super happy with the results, too, once I wrapped my head around Blender's Bezier curves (thanks primarily to this BlenderNerd
video.) The trick was tying a Bezier curve to a circle as a Bezel object, and then tweak the curve until I had the inside and outside shape I wanted. Copy and paste for the engines, add some extruded Bezier curves as engine supports, and bake out the result as polygons in an STL file, and voila - now it's a product in my Shapeways store!
Ultimately, though, this for a single purpose. My podcasting alma mater, Starship Sofa
, is about to reach it's three-hundredth episode, and I'd really like to present Tony with something to celebrate this milestone - I think one of these rocketship in shiny stainless steel (preferably engraved with 'SSS 300' or something like that) would be awesome. It'll cost about $400 AUD to do, though, so I'll need some help - anyone interested in chipping in? Should I run a Kickstarter or something?