Posts Tagged ‘programming’

My new course is all about using the Heroku cloud hosting platform with Node.js. I already have a course on using PHP with Heroku, and not bragging, but it has Udemy’s “Highest Rated” badge. Okay, there is a little bragging. Hopefully, this one will receive the badge, too.

Preview the course on Udemy or watch the trailer below.

Back in the day, unit tests and code coverage were the in thing. You wrote a class, you wrote a unit test for that class. Everything was tested at an individual level and you built integration tests on top of that.

Then we realised that maintaining all of these unit tests was a massive pain in the neck, made it tedious to refactor the code and didn’t provide much value when the real business value was only concerned with everything working together so that the user being able to successfully complete a journey. So, we started writing tests to the API boundary.

Fine. Except it wasn’t fine. The problem is that per-class unit tests are really useful when it comes to understanding other people’s code.

Let’s say we have a component and it is composed of many different internal functions and classes. We write a test to the API boundary so that people can use the component and we know that it works when people use it. That is fine if you are the only person maintaining the component and you have a good memory.

But what if multiple people work on the component and somebody else needs to refactor it? You could try looking in the docs. There are unlikely to be any, though, because it is an internal function. You could try reading the code. This approach is probably the one we rely on most of the time and often works. But if often isn’t too obvious, especially in loosely typed languages with lots of callbacks (*ahem* javascript).

How do you know what goes in and comes out of a function without docs and without types? You don’t. But having a unit test demonstrating stuff being passed in and out is really useful for making an educated guess.

You’ve no doubt heard of us at Glorry, the exciting Silicon Valley startup that is taking the world by storm. We’re best known for raising £17 billion in funding on Kickstart in less than 38 minutes, despite having no discernable business model. Still, that’s what they said about Instagram and look who is laughing now. Mark Zuckerberg, that’s who.

We’re pushing the limits of Agile delivery to see how we can deliver the most value to our customers. But our Service Delivery team are also looking to ensure a consistent and stable customer experience that doesn’t allow new features to compromise on quality.

The result is a methodology we’ve called “No-Release” and I’m excited to share some details of it with you today.

What is No-Release?

Simply put, we don’t release any code.

What are the results like?

They’ve been outstanding. Since we adopted this approach, we’ve had zero bugs introduced to the live system. That’s not a misprint: zero bugs. Not one single incident has been released related to the new code we’ve been writing.

Since adopting this approach, our velocity has increased. Developers feel more confident that their work will not cause issues in live. Product Owners are happy to prioritise tech debt because they know it won’t delay new features arriving in live. Service Delivery is less jittery about degradation due to changes to the product.

How does it work?

We based our workflow on a traditional Scrum methodology. We operate in two-week sprints with a backlog of features prioritised by the Product Owner. Each ticket begins with a Business Analyst sitting down with a Developer and a Tester to work out how we can deliver and test the acceptance criteria of the ticket.

When a ticket is complete and signed off, including going through our continuous integration pipeline where a series of automated tests are run, we then merge the ticket into our develop branch. At this point, the ticket reaches our Definition of Done and we can close it.

Our master branch contains a copy of the code deployed to live, while our develop branch contains all of the new features. Because we operate under No-Release, we almost never have to deal with merge conflicts because we never merge develop into master. Or anything else for that matter.

What are the drawbacks?

One of the biggest drawbacks to No-Release is that you do not release any code. This means that no new features and improvements ever make it to the end user.

Making this work requires buy-in across the organisation. Without everyone being on board you can easily get developers saying “this is pointless, what am I doing here” every stand-up, and upper management suggesting they can fire the entire team and get the same results for much less money. Therefore, it’s important to get everything to embrace the methodology before starting.

Each organisation needs to make its own decision as to whether this drawback is acceptable to gain the benefits discussed above.

Conclusion

No-Release methodology allows you to increase your development velocity while eliminating any risk of service disruption to the end user.

I’m pleased to announce the launch of my new course, Heroku for PHP. I love Heroku as a hosting platform, and there were no Udemy courses on how to use it with PHP. So, I’ve filled the gap. For a very reasonable $29.99.

You can check it out here, and that link will save you an additional $10, too.

Many people imagine that software engineers spend most of their time writing code. Even in a perfect world, that would not be the case. A properly planned and designed system is always going to beat out a rushed and poorly designed one. But regardless, we are not in such a world. In reality, our time looks like this.

If you need to combine two arrays in PHP, you first thought might be to use the + operator. However, this is unlikely to do what you want it to to. If we look at the following example, you might expect it to output an array with all three elements.

<?php

$listA = ['banana'];
$listB = ['apple', 'pear'];
$listC = $listA + $listB;

var_dump($listC);

However, what you will actually get back is an array containing two elements: banana and pear. This is because when you use the + operator in PHP it combines it using array keys. Even though these are non-indexed arrays, PHP looks at them like this:

[0 => 'banana']
[0 => 'apple', 1 => 'pear']

Therefore when you add them together, it combines the keys, taking the earliest. In this case, to get the result you want, you want to use the array_merge function. For other scenarios, PHP has a range of different functions to combine arrays in different ways.

I’ve read Douglas Crockford’s book on JavaScript several time before, but it is always goof to have a refresher. It’s super-helpful and so short that you can easily get through it in a day if you try. I think the appendices are actually bigger than the text.

Recently, Sky did a hack day – the idea was that you could take a day to work on any project you wanted, as long as it was vaguely business related. Then at the end of the day, everyone came together to demo what they had done.

It was a cool idea, and most people really enjoyed it, though I was fairly non-plussed. I couldn’t get my project working, on a number of angles, so didn’t really have much to show by the end of it (I had a demo, but as I couldn’t integrate it into the product, I didn’t think it worth showing). I think if I had actually worked for Sky though, I would have been far more motivated by such an event.

If you’re like me, which seems unlikely as statistically you’re probably far more sensible, you’ll get really annoyed when the white spacing or indentation isn’t consistent within a file.

Because of this, I recently wrote a little Ruby script which would automatically clean up my CSS files and make them all nice and pretty. It’s now publicly available on Github if you want a copy.

At some point in the future I’m intending to do similar scripts for other file types – the SocietasPro codebase already has a similar system for PHP, though that only flags inconsistencies, it doesn’t correct them.

If you store passwords as part of a PHP script, you may be using md5() or sha1() to hash the password. This is common practice, but you may be suprised to know that actually, the PHP manual recommends against it.

The reason is that they are both fast but relatively insecure hashing algorithms that can be brute forced by modern computer systems if they get hold of the strings. A better approach is to use the crypt() function, which is a little more expensive in terms of resources, but worth it for the increased difficultly you create for any potential hackers.