Vale Conversations Network
(blogarhythm ~ end roll 浜崎あゆみ)
So I just listened to the last IT Conversations podcast of all time All's Well That Ends Well.
I'll miss the curation they provided. Did you know that 8 out of 10 interesting facts I quote at dinner parties I learned on the network? ;-)
And still learning: IT Conversations was the 2nd podcast ever? Apparently Doug Kaye uploaded a feed the day after Dave Winer posted his first example of using the RSS enclosure tag.
I'm not sure the Conversations Network couldn't have remained relevant and valuable for years to come, but it is an admirable decision to go out on a high and close down gracefully - importantly taking the time and care to ensure that the content archives remain available indefinitely.
read more and comment..
Building C# on MacOSX with Sublime Text
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:
Blogarhythm: Because It's There - Michael Hedges #NP
read more and comment..
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.
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
read more and comment..
Are You Experienced?
How many times have you seen a webdev job ad that asks for things like:
Minimum 5 years experience in Ruby on Rails, html5, JQuery, Mongo DB, and building andriod and iphone/ipad apps
So it just came up again on a mailing list, and we all had a good lol.
When people ask for more years experience than the technology has even existed, at one level the incongruity simply tickles our geeky funny bone like a classic joke setup.
At another level however - and one that HR professionals the world over still struggle with - specifying job requirements in terms of many years experience with a certain technology betrays a fundamental lack of understanding for what developers do. Like advertising for doctors "with 5 years experience prescribing naltrexone" - I don't think I want to be treated by one who was selected on that basis!
When when specifying technical job roles, it comes back to the key question of how do we ask: "Are you experienced?"
In the IT realm, these jobs tend to be those involved with more stable back-end technologies (e.g. relation databases), or developers doing application maintenance on legacy systems (e.g. 6 year old java applications used by a bank).
However, the closer you get to front-end technologies and the more dynamic your needs (read: startups), the more irrelevant - and often misleading - the "judge experience by years with a technology" rule becomes. The rate at which technologies change is just too fast. I've been doing this for many years (more than I'll admit here!), but:
- I'm still learning new things every month - probably at an even faster rate than when I was a fresh grad
- Half of what I learned last year is now obsolete, probably never to be called on again
- I've lost count of the number of times I've developed mastery in something for 1 project, and never used it again
IMHO, the fundamental skill that great developers share is the ability to learn and assimilate. You don't want them stuck in a rut.
So how do we measure it? Rather than years of service, we need indicators of applied learning, for example:
- A single significant project delivery (i.e. that goes live) is often enough to develop a good mastery of a technology
- Multiple project deliveries demonstrates the ability to hone and apply that knowledge in different scenarios
- Working with various technologies over time demonstrates flexibility and adaptability to the new
- Founding an open source project shows that the individual not only has the creativity and inspiration to create something new, but has the tenacity to get it done (without a boss looking over their shoulder)
- Contributing to an open source project demonstrates that the individual has pounded it enough to identify something that needs fixing, has had the mental firepower to figure out the root cause and how to fix it, and the collaborative skills to get the contribution merged.
So when I write a job ad for a technical role, I'd suggest defining the technical requirements along these lines:
- 5+ years professional web development experience
[a guide to the level of seniority within the general professional discipline] - Delivered multiple projects and current experience using: Rails 3.x, PostgreSQL 9.x, git
[the specific technical skills you expect people to have on day 1. Reference major version numbers where they represent significant evolutions of the technology, and make sure you use the correct nomenclature to avoid more lolz;-)] - Ideally, recent project experience using one of more of the following technologies: capistrano, redis, and MongoDb.
[technologies you use or are planning to use, but it won't kill you to allow the person time to get up to speed] - Experience contributing to or founding open source projects
[it's almost getting to the stage where developers really have to be quite uninterested in their career to avoid some involvement with open source projects - see comments above]
I haven't asked for all the technologies they've used in the past - assuming that this will come out when they explain exactly what they've been doing during those "5+ years professional web development".
Of course that still leaves a whole range of matters such as soft-skills and how you actually go about selling your startup vacancy. You can find this and more in the most excellent JFDI Hiring & Firing guide.
Blogarhythm: Are You Experienced? - Jimi Hendrix
read more and comment..