However looking for tutorials and example code online, I found some resources that weren’t that good, and then looked some more and found some better stuff. I did find that it took a bit of effort to find decent learning materials – there is a fair amount of confusing and sporadic KnockoutJS content around – so I thought I’d blog what ended up being the most helpful content, in order to save you the hassle. So if you’re wanting to get going, consider the following resources above others.
First, definitely go through the tutorial at Learn Knockout. This covers the basics and leads you to the official documentation that will serve as a great reference to the various building blocks you’ll need to refer back to (and copy code from!) when building your page/site. By the time you finish the tutorial you’ll understand the basic structure of a Knockout page, and the steps involved in building the necessary parts.
Second, definitely view Steve Michelotti’s excellent PluralSight tutorial “Knockout Fundamentals“. I actually watched the TekPub Knockout screencast first but found this didn’t actually cover the fundamentals as well as required to actually build a non-trivial page. It covered Knockout in an ad-hoc manner, missing some key pieces around handling arrays, rather than the logical and cumulative treatment (building up a big app over several videos) that Steve’s video provides. Steve’s course covers all the basics systematically, so you will cover everything you need to build a proper page. The Pluralsight course also ends up with more sophisticated app than the one in TekPub, stretching your KnockoutJS knowledge further on completion. If you are not a subscriber to PluralSight, I would heartily recommend signing up (lots of great content) but failing that, the trial will give you free access to your first 200 minutes, which will cover the 1h40m KO course.
Just these two resources should be enough to get your first Knockout page/site built, but once you start hitting those edge cases and yearning for some advanced features, the following posts helped round out my Knockout knowledge even further:
Ryan Niemayer’s blog is generally pretty good, but here are two articles that are worth reading first:
- 10 Things To Know About KnockoutJS On Day 1 – using ko.toJSON() for debugging is really useful (number 9 on the list)!
- Utility Functions in KnockoutJS – don’t be caught writing your own utility functions, especially regarding arrays!
Hope that helps! Next up I am going to discover how DurandalJS builds on top of KnockoutJS to make developing SPAs even easier!
I could’ve written this post at least 6 months ago, if not more, as it was really later last year / earlier this year that I began to cotton on to a new area of expertise opening up in the world of Software Development: that of Product Management.
Being the Dev Team Leader of a team that has really good engineering but is pretty light on product management skills led me to tweet a quote from Marty Cagan’s book “Inspired: How to Create Products Customers Love” earlier this year:
“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.”
Increasingly these days I think the problem is (generally) becoming less about building stuff that “doesn’t break” and much more about the problem of building relevant, dare I say useful, software. In the world of enterprise it is still Project Managers and Business Analysts that occupy this space, and these skillsets don’t seem to include the ones that help us determine whether our users are delighted or our stakeholders are enfranchised (eg. Analytics / Customer Feedback, Stakeholder Prioritization models, UX/Usability skills, Agile product development skills like MVP, etc).
I think part of the problem is also wrapped up in the configuration of the present-day large organisation (at least in mine), where the PM/BAs do not act as champions of the product but rather as relatively disenfranchised interfaces between the developers and the ‘business’ users, who for far too long we have mistakenly believed understand how to build software applications. This configuration doesn’t allow for the PM/BA to really own the product, or own a vision for the product, thereby not shouldering the actual responsibility of user satisfaction and resulting in an incoherent or indeed non-existent product strategy, and generally little value derived over a period of time.
I now see two parts to a successful software team. The first part is the software delivery part: Good engineers, good engineering ethic (TDD, refactoring / tech debt payoff, etc), Continuous Delivery capability enabling fast-feedback, etc etc. Input here is requirement (probably a story or epic in Agile terms), output is a piece of working software in production, with hopefully a very short duration of time between these two things. The second part is the product discovery part – “What should we build?”. Input here is things like customer feedback both quantitative (analytics) and qualitative (surveys), the vision of the product (from a Product Management team with a strong sense of what should/could work!), and of course any other stakeholders you might have (people that have a stake in the product but might not use it directly – eg. call centre agents that get more demand when the website goes down). Output here is of course, a new requirement/epic/story.
These two parts are as critical as each other. A cracking product manager might as well go home instead of be frustrated by a team of developers that repeatedly churn out broken software un-timeously. Likewise, customers can see little value in a cracking software development team churning out irrelevant features.
I recommend the reading of two books that talk a lot about this space:
Marty Cagan is part of the Silicon Valley Product Group, and his site has a lot more information about Product Management. This books succinctly summarises what a good Product Manager is and isn’t, and provides a lot of practical advice to get going with better product management practices immediately.
The second book is also hugely popular and focuses on how Lean Principles-inspired product development results in products that matter – must read material for any aspiring Product Managers! Eric Ries also blogs at startuplessonslearned.com.
These two books will fast-track your introduction to this area, and allow you start thinking about whether the activities undertaken by those who are telling you what to build really the ones that uncover what users want.
I’m looking forward to watching how the Product Management space evolves and discovers more about how we can incorporate insight gained from better knowledge of our users into the development of ever more useful software!