elmomalmo

Running JavaScript unit tests headlessly in CI.

An agile process isn't just there to manage the developers, it's there to engage and manage the customer as well.

In my experience, customers rarely know exactly what they want out of a software project, large or small. Complicated documents, produced up front get ignored because of TL;DR and projects start on faulty specifications that describe a solution to illusory requirements. So, inevitably, there will be a disparity between documented requirements and the desired outcome.

Iterative delivery - a key feature of agile as I have experienced it - gives the customer multiple chances to try-out and feedback on working software along the way. Furthermore, by making the customer part of the solution early they are as instrumental as the implementers in ensuring the validity of the software and - therefore - the success of the project.

Incidentally, I think this is why many customers (internal and external) are suspicious of and hesitant to engage in a truly agile process. That is, they would become equally liable for the success of the project because of the decisions they are required to make. They are part of the solution and therefore potentially party to the blame for any failures. It's much safer for them to be more likely to fail and avoid the blame than it is to risk complicity in a failure, however less likely that failure might be as a result of the process.

What agile does that the author missed (or at least declined to mention) is that it gives a name to and formalises an approach that attempts to manage the customer as well as the implementers. It compensates for the fact that customers can't always be expected to fully understand their own requirements and for the inevitability that they change their minds.

Agile Developer (Python, Mobile, UI)

Myspace / Specific Media

Cardiff, United Kingdom. Full time.

Specific Media are recruiting TDD evangelists and clean code junkies to help create the next generation of social entertainment - Myspace TV. Would you like to discuss what you're watching in real-time on your iPad? Browse music on the Web and throw it to your TV? Invite your friends to watch the same sports games? Pause that film and carry on watching it on your mobile? You get the idea.

What's even better is that (with the help of the creative talents like Justin Timberlake) you get to use this great technology to help transform Myspace. Your code being used every day by tens of millions of users worldwide.

Here at Specific Media, you will work in truly Agile, small teams using Scrum, working in short iterations. You will have unparalleled opportunity to contribute your ideas and have real influence over how we work and on the awesome applications we create. If you're a passionate software developer who is interested in software development both inside and outside work; and you want to be part of the most exciting software projects currently happening in South Wales... Myspace needs YOU!

More details are available if you send me an email at emalethan [at] specificmedia dot com

I figured out you could use the space bar to advance through the "slides", which made the presentation just about usable. I then instinctively - and possibly stupidly - tried to use backspace to go back a slide. Obviously, I arrived back at HN. I didn't go back to finish reading.

Interesting subject matter, poor presentation.

Personally, I'd prefer to live in a society that dissuades the irresponsible from taking risks with other people's lives every time they get behind the wheel.

I'm pretty sure not all deaths are featured on this map. I checked stretches of road where I know there have been deaths near my spot of rural North Wales. Those deaths weren't on this map for some reason.

Cardiff, Wales, UK. Full time

Xumo (part of Specific Media/MySpace) is hiring TDD evangelists, JavaScript maniacs and clean code junkies to work on smart TV applications.

More information available upon request. Please email emalethan [at] xumo dot com

Stephen Fry has a talent with the written word that rarely disappoints. Of the many articles, obituaries and anecdotes about Steve Jobs I've read today, that one is the most compelling read.

This is a common misconception. TDD does not 'espouse' in any way that you write all your tests first. Nothing I have read suggests so.

For me, TDD, in practice means switching back and forth between writing tests and production code. That is, write some test code, run, fail, fix the production code, write some more test code. It is incremental.

EDIT: Fixed a typo

Dead zones are not created by overfishing but by intensive farming techniques on land and what's subsequently washed into the sea via rivers.

http://en.wikipedia.org/wiki/Dead_zone_(ecology)

I disagree, I very much read that as 'which are [environmentally] ok to eat'. However, a friend's wife is pregnant. He - being somewhat preoccupied with pregnancy at the moment - may well have read it they way you did.

Hmm, which is more valuable, $1000 or #1 on HN?

Agreed, I've always thought of it in these terms.

With a service, how much you earned is directly linked and therefore constrained by effort your able to apply. Ultimately limited to the number of hours in a day.

Alternatively, when developing and selling a product, the amount of money you can make is more limited by how good (and how well marketed) the product is than it is the effort you are able to put into developing the product.

My view is that you can make living providing s service, sometimes even a good living. You can make a fortune selling products.

We suffer from the same security hysteria here in the UK, albeit somewhat less hysterical.

There was an article on HN a while back about how 'israelification' of US airports would have a positive effect on actual security and a negligible affect on passenger experience. As a layman, it made a lot of sense to me.

http://www.thestar.com/news/world/article/744199---israelifi...

If you're shipping products and making things of value using great tools (however fashionable they are) it means you spend more time shipping and adding value and less time dealing with the limitations of your tools.

> Someone the other day was commenting on the whole 'everyone wants to be a geek now' thing and wondering what to call true geeks now.

> I told him not to worry and that another word would soon be coined to make fun of the true geeks, as always happens. People just can't resist tormenting people who are different.

> I am a little surprised that it hasn't happened yet... But then, maybe I'm too old and not hip with the new slang.

I've heard/read the word 'neckbeard' used in this context.

I think that's precisely one of the the points Zed is making. That is, that coding is a cool, rewarding pursuit. But that you shouldn't expect a coding profession to necessarily be the either cool or rewarding.

If you're happy in that profession, great. I don't think the chapter in this book says you shouldn't be, in fact I think it would suggest that you have the right disposition for such a profession and are therefore fortunate.

I'd suggest that you help your fellow developers more by writing code that needs fewer comments to make it understandable.

However, I agree that what you say is certainly true of APIs.

I've worked with a lot of legacy code over the years. I don't usually care whether code has comments or not. Comments are a very poor way of expressing semantics in code.

Usually, I'm looking for general readability and understandability. I'd much rather see short, well-named classes and methods, well-named variables and good unit tests before I see a single comment.

In the absence of clean, readable code, comments are probably a reasonable but nevertheless inferior resort. I also agree that, sometimes, they 'why' of code is often best expressed as comments.

In my experience, if you switch projects regularly you become increasingly dependent on your network of previous bosses and colleagues for future gigs. It's stands to reason that you will want to do the best job you can, produce the best code you can so that you have a better chance that you when you leave, you depart from colleagues that will be eager to work with you again in future.

Getting bored easily and professionalism are not mutually exclusive.

Edit: Grammar

Agreed, any reasonable developer looks past the magic myth. Like the article says, you read the source code and gain an understanding.

However, I'd dispute the assertion that Rails has excellent docs, it certainly hasn't always been the case. When I started with Rails, in 2006, the docs where woefully out of date. All the latest information that was available was in a variety of disparate blog posts, written by Rails enthusiasts. That was a significant barrier to learning at the time.

Thanks for the comment, much appreciated. I guess I'm not that familiar with what repels some developers as I don't recall ever feeling that repulsion towards TDD myself.

With regard to hacking something up quickly, I see no issue with this. I spike code all the time to prove a point or try out something new. If it's worthy of putting into production I'll engage in that 'ceremony' you mention. Though, theres not much that's ceremonial about it :)

Because a flawed process has worked in the past is no reason to dismiss a newer, better process as 'religion'.

The point I was trying (and I think succeeded) to make is that by employing TDD you automatically have more test coverage and therefore make refactoring and keeping your code clean that much easier.