I wanted to play around with some JS

A guy at work put me on to yoeman which gives your node package manager the ability to quickly deploy a scaffold for building lots of other stuff. Mainly because I want to learn some JS (using CucumberJS at work) but also so I can start building a simple web based application for a hobby of mine.

Some stuff that was installed:

  • Sublime Text 2 – an excellent editor
  • Java for Mac – I was prompted to install this at some point, can’t remember when
  • nodejs – download from http://nodejs.org/download/
  • github – so it doesn’t matter where I am, I have access to the code
  • yoeman – With node installed, just: npm install -g yo bower grunt-cli. This installs bower (dependency management) and grunt (a JS task runner) as well
  • CucumberJS Easy with node: npm install -g cucumber for any BDD testing needs

Then added yoeman generators: – npm install -g generator-webapp followed by yo webapp

The last step creates a scaffold on which to build your web app. Or whatever it is you’re doing. There are heaps of generators available.

I needed to manually install some grunt components due to permission issues with sudo on yo webapp

Seems that the bower install done as part of the yo install didn’t quite work (on linux; worked fine on OS X). The previous post is all about fixing that.

Once that’s done, cd into the app directory and grunt serve to start.

Grunt is pretty nifty. It’ll watch your application directory for any changes and automatically update the site. No need to run anything every time you save a change; grunt takes care of everything for you.

Bower gotcha

Found this problem while trying to get Bower to work with yeoman on Ubuntu. Turns out it’s the fun corporate proxy here but the problem isn’t insurmountable.

After installing jumping into the application directory and installing Bower with

sudo npm install bower -g

attempting to run

bower install

produces a bunch of connection related errors.

Find the port you’re proxying through by

env | grep -i proxy

Now that the port is known, edit .bowerrc in the application directory

nano .bowerrc

and add the following

{
   "directory": "bower_components",
   "proxy" : "http://localhost:<port>",
   "https-proxy" : "http://localhost:<port>",
   "strict-ssl": false
}

Save the .bowerrc file, close it and re-run the bower install.

Done.

The New Place

Names? Who needs names?

Three days here so far and I’m having a blast. Not honeymooning (too cynical now) but there’s a lot to like:

  • Practical use of git
  • New tools like Gradle (whatever happened to Maven?)
  • New concepts e.g. contracts testing
  • More technical testing than I’ve ever been able to do: automation, BDD, security, API’s
  • Many things being implemented and trialed
  • Angular and Protractor
  • Little “a” agility
  • Walls with cards, stories being progressed, get togethers around whiteboards to clarify things, developers, testers, designers and BA’s excited about what they’re doing and enthusiastic about overcoming challenges

In short, much more to learn in an environment I’m more comfortable in (agile) which makes me a happy tester :)

Waterfall is still shit

Any PM – or anyone else for that matter – telling you just how awesome waterfall is as a development methodology clearly isn’t paying attention. Experience of the last 50 or 60 years in software development aside, one only needs to look at the paper that supposedly proposed waterfall as a working model to know that the process was a pile of suck from the beginning.

See, a guy by the name of Winston Royce wrote a paper titled “Managing the Development of Large Software Systems“. Go read it. It’s worth it. In the paper he describes exactly why this process is complete balls. Even though he never actually names it as waterfall, it can be clearly seen as such from the diagram.

I find it funny that there has been industry wide adoption of a process that was demonstrably inadequate to the task of building software.

DSDM Atern. What is this? I don’t even

Apparently DSDM Atern is an Agile implementation.

I really have no idea how this could ever be considered aligning with the agile values and supporting principles. Seems more waterfall with smaller iterations rather than agile. Which is fine, just don’t say it’s agile, particularly when you have as a guiding principle “Demonstrate control” that includes the gem “use an appropriate level of formality for tracking and reporting” then I’m pretty sure you’re #notAgile.

Apparently it’s all the rage among big corporates, with 1% of all those surveyed saying . . . Wait, what? One percent? One. Percent. So it’s right up there with the Agile Unified Process and agile modeling. And slightly lower than the category of “Other”.

Excellent.

 

Passing on the lessons learned

One of the things about facing the imminent end of your current employment (contract’s not being renewed as the role I’m in is effectively redundant) is that you know you’re not going to be there to help out the people you’ve been helping out for the last year. In light of that harsh truth, I started putting together a list of useful testing resources, things to read, even things that aren’t specifically related to testing but have proved useful to me at various points of my career.

The list won’t be useful to everyone and I don’t recommend going and buying every book on it. This is just what I’ve collected over time. If you have any to add please feel free to say so in the comments section.

Stuff that’s related to Agile and Scrum that you might find useful, even though the journey there will be difficult

  • Scrum Shortcuts without Cutting Corners – Ilan Goldsteins take on how to survive an agile implementation and what works in the real world (or at least what worked for him)
  • Agile Estimating and Planning – Mike Cohn’s excellent book on how to do it right. There’s a reason why the praise section reads like a who’s who of the agile world

Technical stuff that I enjoyed reading that wasn’t specifically related to testing

  • Introduction to the Command Line
  • The Phoenix Project (fiction but a great read)
  • Practical Lock Picking
  • BackTrack 5 Wireless Penetration testing Beginner’s Guide
  • Metasploit: The Penetration Tester’s Guide
  • Nmap Cookbook

There’s a bunch of stuff that I’m yet to get around to reading from a few authors who interest me. These are mainly about techniques used to eliminate waste at a number of levels, from software development to pointless management bullshit. The following authors may be of interest to you too:

If you end up leading or managing people please, I beg of you, ensure you know the essentials of the above. It might help make the next generation of leaders management types a little less dense.

My next trick is to post up a bunch of useful links, though the blogroll is a good place to start. This will include blogs, Twitter accounts, etc. that will give you insight into the craft. Some you may know, others may be unfamiliar.

Good luck.

Well that explains it

Sometimes, when reading scientific literature of the psych/social nature, there’s a tendency to think “No shit, really?” in response to the findings. However, the advantage of having a paper published on a subject that confirms what anecdotal evidence has always assumed was correct lends weight to those original, un-researched findings.

Such is the case when I came across this particular paper: Boss Competence and Worker Well-being. Or, as the original ./ lede had it: Your incompetent boss is making you unhappy.

Well, duh.

This really helps to explain the enjoyable jobs I’ve had in the past, as well as the not so enjoyable ones. All the roles I’ve occupied that have been enjoyable were in places where I work for, or report to, someone who I consider competent in the job they’re doing. And all the absolutely horrible ones – one last year springs to mind – have all been working for, or reporting to, incompetent cretins who have all the capability of an extremely stupid toaster. Either that or they’re lying scumbags.

Hmmm. That’s probably more about them being a shit person I suppose. Po-tay-to, po-tah-to.

What truly baffles me though is why, when we know all of this, when we understand why bonuses don’t work for knowledge work, that KPIs are seldom relevant to the work being carried out, that theory x type managers are bad for business, that happier employees contribute more to the value of the company than unhappy ones, that collaboration and trust are more effective than command and control . . . When we know all of this, why do we keep trying the same bullshit anti-patterns that continue to fail? Are companies addicted to failure? Or does someone at some point high up in the hierarchy think that if we just keep trying the same old thing then sooner or later we’ll get it right?

Anyway, I found the paper quite interesting. Given that my current contract is coming to an end, I’m hoping that wherever I land next will give me the opportunity to work for someone who knows their shit.

Do we need testing?

Bob Marshall (@flowchainsensei) has an interesting post up on his site about No Testing. I can assume this follows on the heels of the #NoEstimates movement.

Interesting read. I think I can see where he’s going, somewhat like the “everybody tests” idea espoused by Bolton, Bach, etc. (and me for that matter). I like the idea, even though my profession is directly affected by the approach.

To be honest, I don’t think we need a specific role to be doing testing. But in order to do this the whole organisation producing software needs to be involved in the “testing” effort. Developers need to get better at building their own checks. The business needs to be able to clearly articulate their vision. Testing is as much an arse-covering exercise in a lot of places as it is a check to ensure we developed the right thing the right way for the right target market.

The discussion needs better definition. I’d also like to get at the root of why Bob thinks testing needs to go away.

I like the concepts of necessary and unnecessary wastes by the way, particularly as a way of characterising what testing is done. Something I’ll have to look at in more depth.