A Cloud9 Custom Runner combining TypeScript and Mocha

The online IDE Cloud 9 is just awesome.  It is amongst a number of online IDEs out there, of which I think it is the best.  With Microsoft also making .NET opensource and available on all platforms I can also see myself doing .NET development on this as well.  Yes I know there is Monaco from Microsoft but that is still immature and yes there is Mono on linux as well but that requires fiddling about.

At the moment I’m doing node.js development with expressjs and now with typescript in the mix as well.  Typescript looks awesome as well.  I’ve ported some javascript code over to Typescript and it feels really nice.

However, Cloud9 does not have a runner setup for typescript compilation so I decided to set one up myself.  Cloud 9 provides a way to do this by adding a New Runner from the Run Menu.  I created the following script that associates the .ts file extension with the tsc compiler.  It will also then run the associated mocha test which existed when the code was just pure javascript.  It does rely on a naming convention and directory location for the test, so as long as you stick to a convention you will be Ok.  Here is the script:

{
“cmd” : [
“bash”,
“–login”,
“-c”,
“rm $file_base_name’.js';tsc –sourcemap –module commonjs $file; mocha test/$file_base_name’Tests.js'”],
“info” : “Compiling Typescript file $file”,
“env” : {},
“selector” : “source.ts”
}

It uses bash to run multiple commands, one for the Tyepscript compiler and then followed by the mocha test runner.  Prior to running these command it deletes the previous .js file and if tsc fails the old file is still there and the test runner will pick that up still and we rather not have that.

I found when I converted the javascript implementation of the main file to typescript and compiled, my tests just worked.  The tests are still in pure javascript.  I’m still entertaining the idea of using Steve Fenton’s tsUnit but I fear it may not be as mature as the javascript test ecosystem.


Just Start It – Teaching the kids of today to become the startup leaders of tomorrow

I want to tell you all about a fantastic educational program that is running in Western Australia called Just Start It.  It teaches young people about lean startup by actually do it.

They learn to take an idea and bring it to market, pivoting to correct any wrong assumptions along the way from feedback they gain for their real products from real customers.

This year was the first year that the program ran with 11 schools taking part and some fantastic entries being created like the Beyond Bullying and Numbox applications.

Next year, Program Leader, Lainey Wesier is looking to take the program further and introduce it to more kids next year.  You know in the future we can’t rely on a generation of job dependents, we want our kids to be creating the opportunities of tomorrow in the classroom.  What a great life experience and a great way to kickstart life!  This can only be motivational :)  They build something and build important life skills along the way.

But Lainey, her team and our next generation can’t do this by themselves.  They need help also in the form of dollars.  Yes this sort of thing just doesn’t happen out of free will – there is a lot of that already been given out.  Just Start It have a crowd funding campaign underway and they are looking for your help.  Visit the crowd funding site and give what you can in an investment for the future, a future that will see your sponsorship deliver benefits in so many ways for our next generation and also for yourself.

Just Start It – Yes Lets make it happen!

Visit the site to find out more and hopefully become a sponsor.


Put the Analyst into Analyst/Programmer

I used to say for over 15 years, put the Analyst back into Analyst/Programmer. This was when many jobs where advertised as Analyst/Programmer, but the Programmer never really did any meaningful analysis. It was mainly confined to the act of writing code not so much about the understanding of requirements.

The reason it fell into disuse is probably correct when you look at the traditional ways software was produced.  Another reason could be the cognitive load required between swapping out of coding and understanding requirements. This a more like an excuse rather than looking for causes.

I’ve now come to say put the Analyst into Analyst/Programmer.  It was never really there in the first place.  A programmer can and should have valued input from the beginning of the software production process.  That does also mean being a nice person and maybe strengthening into areas not so familiar like talking to customers – it’s a communication process as much as a technical process ;)

Inspired by this talk from Martin Fowler this year that I feel aligns with this ideal, I’ve included the following call to arms that I now start my Agile Programming course with, which is to be released soon.  I hope to sharpen it up a bit more.  You can have input into it if you like.  Here’s a start:

As programmers we are more than just code monkeys​. We are motivated to create value for our customer​, so we should be on board with everything including:​

  • Being able to speak to our customers to learn the domain we are working in​
  • Being able to seek clarification from anyone​ be it Business Analysts, Customers, Product Owners, Testers or anyone else
  • To question anything that we have concerns about​
  • Expect to have a meaningful input into understanding requirements​
  • Expect to inject innovation and have it considered

Over to you.  Admittedly there is some work to do to unravel decades of silo based work practices.


About Agile wants to give back to the community

About Agile’s courses in Agile Testing and Agile Development (under development :)) work on real community projects as part of the the learning journey.  It’s a way we and attendees can give back to the community.  Your time is also directed to developing free resources that our community can use.  Over time we will integrate into other courses as well.

You can also find more at the About Agile website on this including the environment that is being used.


Create your own Manifesto

This is a reproduction and completion of a post created last year on another website.  This is my manifesto. I attach to the other manifestos still but this is my own.  Try creating your own.  It would be nice to see what you really attach to.  No doubt they will be similar in theme.  If you can make an acronym that would be even better, easier to remember.  Below is version 2.  I expect to sharpen it up over time.

Got to have GRITS

In a world full of mnemonics which seem to be just for the sake of it (e.g. S.H.I.E.L.D), I’m unabashedly introducing a new one which encapsulates a number of values and principles I hold and uphold.

No doubt there are overlaps with other values and principle systems and I gladly welcome that.  Largely it’s inspired from the Agile Manifesto, XP Values, Declaration of Interdependence and this really excellent and detailed expression of values from acQuire Technology Solutions.

This is my own personal take for which I’d take ownership in.

Here goes – it’s called GRITS

G(enuine) – Be honest and forthright rather than vague and ‘faking it’

R(espect) – To listen to and respect (not necessarily agree with) the views of others rather than jump to hasty conclusions

I(ntegrity) – Hold true to good human values rather than seek to benefit from someone else’s misfortune

T(ransparency) – Be open about why, what and how rather than deliberately obfuscate and be obscure

S(incere) –  Mean what we say rather rather than be glib and hollow

Whilst we try and be all things on the left we sometimes recognize we fall into the poor behaviours on the right and seek to correct that.


A Response to “Why Most Unit Testing is Waste”

Nick:

I believe this article on unit testing deserves reblogging in that Jim Coplien has added his comments.

Originally posted on Henrik Warne's blog:

A few months ago I came across the article Why Most Unit Testing is Waste by James O Coplien. The title is an accurate description of the contents – James considers most unit tests to be useless. He expands his arguments in the follow-up article. I was quite intrigued, since I get a lot of value from unit tests. How come we have such different views of them? Had I missed something? As it turns out, I was not persuaded by his arguments, and here is my response to the articles.

View original 1,182 more words


Why Founders Should Know How to Code

Nick:

I’d extend this idea out even further…..

Originally posted on Steve Blank:

By knowing things that exist, you can know that which does not exist.”
Book of Five Rings

A startup is not just about the idea, it’s about testing and thenimplementing the idea.

A founding team without these skills is likely dead on arrival.

—-

I was driving home from the BIO conference in San Diego last month and had lots of time for a phone call with Dave, an ex student and now a founder who wanted to update me on his Customer Discovery progress. Dave was building a mobile app for matching college students who needed to move within a local area with potential local movers. He described his idea like “Uber for moving” and while he thought he was making real progress, he needed some advice.

Customer Discovery
As the farm fields flew by on the interstate I listened as Dave described how he translated his vision into

View original 1,102 more words


Follow

Get every new post delivered to your Inbox.

Join 545 other followers