May 22, 2013

You are here: Home / 2012 / Archives for February 2012

Testing: Value Galore

February 25, 2012

Automated testing is a key technology being incorporated into the workings of the Joomla Bug Squad. At the present, this is a somewhat specialized skill…

(http://docs.joomla.org/Automated_Testing_Team)

Specialized, indeed!

There is no glory in testing. There is no glamour in testing. But, there is tremendous value in testing. And extracting that value is what attracts us to testing.

Testing is a major PITA. It’s easier to be casual about it. The problem with casual is that your live site becomes one huge test facility. Live sites cannot be fully simulated in tests, but doing as much testing as possible before the code hits your live site increases your chances of enjoying a smooth running, money-making live site.

As Alan Langford told me, it takes time and effort to set up testing. You have to code so that your code is test-able. The reward is two-fold: quality increases hugely which reduces your operational risk; and, subsequent testing becomes easier as the initial testing set-up is done.

Since testing is not glamourous, is not glorious, is usually thankless, and delays code getting to market, it’s not only glossed over but it’s a skill that only a subset of programmers have. Indeed, a “somewhat specialized skill”.

As of February 2010, a tests folder has been added to the Joomla! SVN download. This folder contains a growing library of unit and system (or functional) tests. The unit tests use PHPUnit and the system tests use PHPUnit and Selenium. The unit tests perform tests primarily on the Joomla! framework. The Selenium system tests actually run Joomla! from a browser and test it as a user would.

http://docs.joomla.org/Running_Automated_Tests_for_Version_1.6

Hmmm, does this mean that such testing was not part of Joomla 1.0 & Joomla 1.5? The implication is that the value of such testing is recognized to exceed its costs only recently. Regardless of when this recognition occurred, we should take the hint at Club Commerce!

I cannot emphasize enough that controlling the software development process offers massive RoI. Open source software gives us the right to control the code. But the huge value resides in the development process. That’s the “Moneyball” aspect — the conventional wisdom is that the value is with the code. But the true value is the development process.

With a testing regimen, we can hire a ton of different programmers for a ton of different projects. The programmers code, and then we run their code through our tests. Code that passes is integrated into our codebase.

We need an explosion of features. So, our software development process must allow us to program an explosion of features. Up-front investment in testing allows us to achieve an explosion of testing.

Testing is a road less travelled, but rich in value. The Jenkins Server is mostly about testing.

I had no idea how deeply Alan Langford, a Founding Member, is involved with testing:

Ground work on the implementation of unit testing has been done by Enno Klasing during the Summer of Code 2007 project and has been perfected by Alan Langford from the Joomla! Development Team.

http://docs.joomla.org/index.php?title=Development_Working_Group&oldid=62385

This is going to make your eyes glaze over: http://permalink.gmane.org/gmane.comp.php.pear.devel/43667

Last week, after we recorded our “The Bob Bloom Show” interview, we chatted for a half hour about LaSalleMart and testing. Alan agreed to do a special one-on-one podcast on testing and LaSalleMart, which we’ll do in March. What prompted this post-show interview was something Alan said off-the-cuff at the recent Toronto Joomla meet-up about testing — which had nothing to do with Club Commerce or LaSalleMart.

Testing is something I did in a former life as a Business Analyst. Use-case testing, mostly, where you dream up phony numbers, manually calculate what the computer is supposed to spit out, then see if the system actually outputs those numbers. Well, we can do “use case” testing in automated tests, saving the hassle of foisting it onto end users.

So, we have a valuable testing skill-set here at Club Commerce. As much as I yearn for all the pet projects that are piling on already to be coded, I am going to devote myself to constructing the test environment. If this takes a couple of months, so be it, because the payoff is massive. We are going to be leaders in testing and Continuous Integration, with the payoff being the ability to accomodate an explosion of features — and getting this quality code to your sites so you can make money with these features.

It’s going to be very interesting, and exciting, to put other extensions through our testing before you install them on your site. This is completely in keeping with the idea that GPL software is Raw Material.

I’m rushing this blog post, because I want to squeeze it in before publishing my already-late February Hangout podcast. So a few observations…

In order to bring an explosion of features to your live site, we need a software development process that accomodates a massive amount of programming.

This software development process, by definition, cannot be like the process other extension purveyors use — because those processes have left us yearning for features.

If the road well travelled has left us frustrated, then the road less travelled is where the pot of gold is.

Most people do not like to travel on the roads less travelled.

My Club Commerce is for site owners and consultants who realize they need to travel on the road less travelled. With 140 memberships available, this is not a mass marketed club.

The “Moneyball” attitude leads us to probe where the value really resides. We identify where the value really resides; and, then we become skilled at these things that build value.

Believe it or not, we’ve concluded that coding is over-rated!

The software development process is where the value is. And, the soul of value is Continuous Integration.

Continuous Integration = test + build.

Testing is a “somewhat specialized skill” — relatively few coders are skilled at testing.

“Build” has led us to the shocking conclusion of abandoning the Joomla installer!

The Fallacy of the One Big Zip file!

We have a surprising competency in testing at Club Commerce. The Toronto Joomla Group, of which we participate, has an unusual competency in testing. So, Club Commerce will be a leader in testing; and, in building ( = Continuous Integration).

So, despite an initial up-front investment of time/effort creating a CI environment, the payoff will be an explosion of features for you.

There are a lot of programmers. Hiring programmers should be easy. We will need money to hire programmers to code.

Club Commerce is a funding model to hire programmers!

There’s an article about GitHub.com called “Lord of the Files” (clever!) at http://m.wired.com/wiredenterprise/2012/02/github/all/1. My favourite quotes: “They weren’t the only developers chafing under that Trusted Gatekeeper model of open source”, and “It’s the startup’s outright hostility toward corporate command-and-control that really sets it apart… yet it’s the most productive software development team he’s ever worked on,”.

My favourite quote from an article about how GitHub.com’s software development, http://scottchacon.com/2011/08/31/github-flow.html is, “we deploy all the time… We don’t really have ‘releases’ because we deploy to production every day – often several times a day”. Yikes! How’s that for “continuous”? No version numbers!


Late Night Thoughts on LaSalleMart

February 15, 2012

Are You Going To Continuous Integration Fair?

I caught the “Scarborough Fair” scene in The Graduate today, as Dustin Hoffman is driving across the Golden Gate Bridge. With the Academy Awards coming up, Oscar winning movies are de rigour this month.

 

 

 

That long drive over the bridge summed up my feeling today as I dug into Jenkins and builds. A long journey over a very long bridge high above the water. It’s not as if I’m going to make a u-turn, or swerve to the side.

If you think CSS is mind-numbing, then you’re really going to glaze-eye on me about software builds. It is uber-geeky. There is no pretense that a non-techie will use it. It’s a journey into geek-land.

Surveying the dev@Cloud Jenkins service, I asked myself “What the hell am I doing?”. I’ve had no occassion to get into this stuff ’til now, so what am I doing here? Can this really be the Moneyball of Joomla ecommerce?

Ladies and gentlemen, it really is the Moneyball of Joomla ecommerce. This is where the techies see real value. This is techie stuff created by techies for techies for the express purpose of creating value in the development process. It’s to make things easier, to avoid doing repetitive tasks, to reduce bugs, to increase the quality of the code, to deploy code.

The thing is, it’s a techie thing. The last thing this part of the techie world expects is “users”. But that’s exactly what we are doing. We, site owners and consultants, are driving our Alfa Romeo’s across that great bridge into the golden roadway to RoI. They are not expecting us there, where the shock on the faces of the techies will be clear on their faces. The last thing they expect here are users from the wrong side of the bridge usurping the very technology that creates immense value for their software development process.

Like many tools of the trade, these tools are FOSS. The Jenkins Server is licenced under the MIT Licence:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software…

Jenkins is available for free to anyone and everyone. It needs a lot of elbow grease though!

Continuous Integration technology used by lowly “users”, put together by lowly “users”, for the benefit of lowly “users”, is the heart of unlocking RoI for us.

And what I thought as I went travelled through software build technology, having crossed the bridge, was that this is a land that we have to live in. And, by living in it, there really is no border between “extension purveyor” and “user”. We are in the extension business, even though we are “users”. So, from code origination to our individual production websites, it’s one big integrated process.

I thought that the demarcation between “upstream” and “downstream” in the software development process is that point where it crosses into the individual website. Ah, but we are the extension purveyor! So, it’s moot. We are Vertically Integrated. We are engaged in all aspects of the software development process. Origination, testing, building, deploying… there’s no “they”. It’s all “we” now.

You know, it takes my breath away. Controlling the code, which is the underlying premise of the GPL, is just part of it. To truly control the code, you have to hold the software development process in the palm of your hand. That means crossing the bridge into geek-land for Continous Integration, the soul of the software development process.

Github.com does not release software! They deploy continuously, daily:

We don’t really have “releases” because we deploy to production every day – often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.

There are a number of advantages to deploying so regularly. If you deploy every few hours, it’s almost impossible to introduce large numbers of big bugs. Little issues can be introduced, but then they can be fixed and redeployed very quickly. Normally you would have to do a ‘hotfix’ or something outside of the normal process, but it’s simply part of our normal process – there is no difference in the GitHub flow between a hotfix and a very small feature.

Another advantage of deploying all the time is the ability to quickly address issues of all kinds. We can respond to security issues that are brought to our attention or implement small but interesting feature requests incredibly quickly, yet we can use the exact same process to address those changes as we do to handle normal or even large feature development. It’s all the same process and it’s all very simple.

Hotfix is really a Very Small Feature? Well, there is a true understanding where ecommerce profits come from! Profits come from features. Features come from code. That code must actually exist and reside — and work! — on your website. Your focus should be on buying revenue; and, in order for you to buy revenue, you buy features. To buy features, you buy code. Moneyball: You don’t buy players, you should be buying wins. And to buy wins, you need to buy runs. Value is not planning or having star programmers, which are over-valued (Alan will disagree). Value is having real code working for real on your actual website. No technology, no profit! Deploying every day — it’s a culture shock!

The implications! If you deploy everyday, then do you run big massive discrete projects? Wouldn’t we be running a continuous stream of small projects? Wouldn’t we want to run a ton of concurrent small projects? We’d have to find a way to start and finish projects, as we’d be starting and concluding projects all the time.

Theoretically, at least, revenue from the sites under our purview would be growing incrementally, as features were added incrementally every day. A portion of this growing revenue would be, theoretically, re-invested into software development, resulting in more features that create more revenue.

One of the things I learned at tonight’s Toronto Joomla meet-up is that there’s some Continuous Integration skill amongst my Founding Members.

We really are crossing the bridge. No u-turns, no swerving. The technology techies rely on to impart value to their software development process: here we come!


Toronto Joomla User Group Meet-up: February 2012

February 15, 2012
Joomla User Group Toronto

Joomla User Group Toronto

So caught up in the discussions, I forgot to take a picture.

Doug, Joe, Alan, Zach, Andrew and Yours Truly upstairs at the Yorkville Duke. Good to meet Joe’s son pre-meet-up. Guelph, Whitby, Richmond Hill outnumbered the 416 contingent.

All but Doug are Founding Members of my Club Commerce. But we did not talk much about LaSalleMart, which was good. It was more wide ranging, including a discussion about NASA, legacy programming languages, Joomla’s history, the JED, and projects currently engaged.

I asked about upgrading from Joomla 1.5 to 2.5 and appreciate the answers — thank you.

Joe had specific problems that we talked about, which led to a discussion about the idiosyncracies of individual extensions. Especially when it comes to templating & views.

Look forward to the March meet-up. Details at http://toronto.joomla.ca.


An Imperfect Understanding of Where Features Come From

February 11, 2012

Moneyball -- Where is Value?

Within an hour of publishing my latest podcast, “The Moneyball of Joomla ecommerce“, I received a tweet asking me why anyone would “invest” in my thing without a “solid development plan”.Listening to my “Moneyball” podcast, it’s obvious that I’m not looking at my Club Commerce/LaSalleMart conventionally. This is because convention has left us frustrated, yearning for code!

If we approach our own code development conventionally, then why will we avoid the ailments and pathologies we are seeking to avoid?

Chapter 1, section 1.1 of “Jenkins: The Definitive Guide” opens:

In fact it is a real game changer – when Continuous Integration is introduced into an organization, it radically alters the way teams think about the whole development process… going from a simple scheduled automated build right through to continuous delivery into production.

Circumventing the Joomla installer is a liberating idea. Using “automated builds” to created hundreds of simultaneous versions has a lot of value. Thinking of software development as “upstream” and “downstream” processes opens up a lot of value.

My original idea was to run a club of Tienda clients, so my clients could share the costs of common modifications. The software development process extended to maintaining a custom Distro of Tienda. Since the only one working on this Distro was, essentially, just me, what process did we need? Much time was spent on Live Update, so my clients can effortlessly grab the latest and greatest version.

Well, here we are, at what is the logical conclusion of our journey: that we have to be in the Joomla extension business. We have to create/maintain our own Joomla ecommerce software. This is an entirely different proposition than being in the modifications business.

The last thing I want to do is recreate the problems my clients and I are escaping – principally, vapourware. So, if a “solid development plan” means “tell me when your features will be released”, then I don’t see the point.

Furthermore, our list of features is vast. Practically bottomless. We are starved for features. It’s one thing to be the “mouse on the wheel” for a finite amount of customizations; but, it’s an entirely different thing faced with practically an infinite amount of programming using a ton of programmers for a wide spectrum of site owners and consultants. The question is not “what” and “when”. The real question is “how”.

Researching “how” unearthed surprises. There is a world of opportunity in the “how”. The “how” is where the real value is. As consultants and site owners, we can customize the “how” to suit our purposes. The right to change the code has led us to owning our software development process. Which leads us to Continuous Integration, which is involves testing and building. It is the building that we will blaze a trail.