my recent reads..

Atomic Accidents: A History of Nuclear Meltdowns and Disasters; From the Ozark Mountains to Fukushima
Power Sources and Supplies: World Class Designs
Red Storm Rising
Locked On
Analog Circuits Cookbook
The Teeth Of The Tiger
Sharpe's Gold
Without Remorse
Practical Oscillator Handbook
Red Rabbit

Monday, October 22, 2012

Building C# on MacOSX with Sublime Text

It's been a while since I last cranked up mono to compile some C#, and this time I'm on a Mac.

Fortunately, no dramas. The mono team have made it a very smooth process. I simply downloaded and installed the Mono SDK (it is packaged as a standard disk image [.dmg]). That's enough to compile and run simple projects.
$ mcs hello_world.cs
$ mono hello_world.exe

There's a whole cross-platform IDE available now called MonoDevelop and it looks great if you are doing serious C#. Right now though, I was happy enough to build from the command line .. or from my favourite editor of the moment, Sublime Text.

Setting up a C# build system is trivial. From the "Tools | Build System" choose "New Build System..." option. My version simply associates with all .cs files and passes them to the mcs compiler:
  "cmd": ["mcs","$file"],
  "selector": "source.cs"
Then when you are in a C# file you can simply ⌘B to compile. Like this:

And you get a .exe that runs under mono from the bash prompt. Wild!

Blogarhythm: Because It's There - Michael Hedges #NP

Saturday, October 13, 2012

The Full Monty - from Ruby to Python n00bie

Ruby developers are a pretty spoilt bunch these days. The community has overall done a great job of rolling many of the advances in modern development practice into the tools and conventions we unconsciously put to work every day.

Now I wonder what life is like in the Python community? Like many Rubyists, I've played around with Python and Jython on and off. But nothing serious. And although you could get into a pedantic syntax war, I suspect for the most part the Python and Ruby communities don't overlap simply because once you dive into one camp, the only real reason you would switch to the other is because of some external driver (like a client's development standards).

It was a casual discussion about testing that re-ignited my interest in taking a peek over the fence. I picked up a copy of Greg L. Turnquist's Python Testing Cookbook and enjoyed playing around with a couple of the Python testing tools. It's an excellent book for ramping up your testing skills with Python - eminently clear and practical.

I was pretty sure that if any language community came close to matching Ruby's approach to development it would be Python. But is that true?

Most comparisons of Ruby and Python (like here, here and here) focus on language syntax and features. Conclusion?
same but different!
What I find more interesting is a comparison of the fundamental productivity patterns used in each community, assuming your goal is to produce high-quality code that can be reliably distributed or deployed, and likely makes liberal use of other - probably open source - code components.

So here is a rundown for some of the common patterns I could not do without when developing in Ruby, and what appear to be the leading Python equivalents - according to my research as of Oct-2012, but I welcome corrections and further information from any Python experts out there!

Environment Partitioning

We don't like dependencies from other projects leaking over to contaminate and confound what we are trying to work on. While you could run up a separate VM for each project, it is much better if you have tools that can keep installed libraries and even the language distributions separate for each project.

The Ruby Way: rvm is the leading tool for creating isolated ruby and gemset environments. A less intrusive alternative is rbenv (compared here).
The Python Way: virtualenv creates isolated Python environments. Ref: SO.

Dependency Management

It is likely our project will make use of other packages. We want automatic dependency management so that we can easy deploy predictable compositions of code packages.

The Ruby Way: bundler
The Python Way: pip with a requirements.txt file. Ref: SO

Reusable Code Packaging

For anything more than trivial scripts, we probably want to package our project so that it can be reliably distributed or deployed.

The Ruby Way: we use gems. Easily built by hand, or bootstrapped with a tool like bundler or jeweler
The Python Way: use setuptools (enhancements to the Python distutils) to build and distribute eggs. Ref: SO

Reusable Code Distribution

Both Ruby and Python are very open-source oriented programming communities. Not only do we consume a great deal, but it's likely we'll often want to make our own contributions easily available to others.

The Ruby Way: RubyGems for distribution, with source code most often found on github.
The Python Way: pip. And source code also seems to be showing up more on github than historical use of svn repositories. Ref: quora

Project Build Tool

We'd prefer a common approach to running project build, doc, install and test tasks rather than rolling our own for each project.

The Ruby Way: rake.
The Python Way: this one I'm not so sure of. It seems most projects simply provide a custom setup script using distutils, but there are a variety of projects that support more complex build requirements. Ref: SO

Automated Testing

It's 2012 already, we know that automated testing is a cornerstone of quality software. Especially so for code that is going to be widely shared and reused. Whether you do TDD, BDD or simply unit test, we all have a good test framework or two on our toolbelt.

The Ruby Way: Test::Unit, RSpec, Cucumber amongst others. It is extremely rare to find a project these days that doesn't have tests of some flavour.
The Python Way: unittest (sometimes called PyUnit) and doctest are common frameworks for unit testing and TDD. nose is a test runner, especially good for non-trivial projects. Lettuce is the rough Python equivalent of Cucumber. Like Ruby, there are many other projects to assist testing such as mocking tools like Mockito.
Bonus: open source projects have been rapidly adopting Travis for automated continuous integration on the back of a github commit. And it works for Ruby and Python.

Blogarhythm: Always Look On The Bright Side Of Life - Eric Idle/Monty Python