Posts
-
Is it time to stop bringing your own device to work?
-
50+ Useful JavaScript Tips, Tricks and Best Practices
-
Keep it Simple, Stupid!
-
Using Jenkinsfiles for Continuous Deployment Pipelines
-
Story Points Baseline
Bring your own device (BYOD) refers to the policy of permitting employees to bring personally owned devices, like your mobile phone to their workplace and using those devices to access and use company information, such as email.
Employees have been bringing their devices to work for quite some time, but by around 2012, it had become clear that every organisation needed a policy that would outline whether you could bring your own device or indeed not. However, these days, it’s less likely and even considered counterproductive to have such as prohibitive policy which means having a more comprehensive policy that incorporates the realities of modern technology and usage.
Read More »Here it is, the long awaited 50+ useful JavaScript tips, tricks and best practices.
I originally wrote this for fun and to help me understand more about JavaScript as well as settle some common arguments that kept coming up in the community.
Having lived with JavaScript for a long time now, I thought it was high time that I decided that I should write up some of the JavaScript tips with references to help those starting out.
Here’s some tips and tricks to help you get to grips with JavaScript.
Enjoy!
Read More »“RTBQ! RTBQ!”. This is the phrase that my high school friends shouted at me when I asked them to remind me of the phrase they remember from school. Mr Fletcher was a larger than life maths teacher and “read the blinking’ question” wasn’t the only phrase he said.
He had a whole raft of these phrases, including “log off, and bog off”, being one of the more memorable ones. For me though, he was also the source of the phrase “keep it simple, stupid” that has always stuck with me. Not just because it was somewhat amusing, but because it was actually useful advice too.
Read More »If the idea of deploying code to production makes you nervous, then this one’s for you.
Despite the fact that you may have just solved the latest business problem with the most elegant solution and the least amount of code, you know how it is when it comes to deployments and humans, we will make mistakes, we get things wrong and we break things. It happens.
However, the way we solve this is by improving processes, not blaming humans. Employing what we’ve learned, leaning on our own experiences and experts in the field, while implementing the best practices.
Martin Fowler wrote about Continuous Integration in September 2000, followed by a significant update in May 2006. He talks about conceptual ideas such as maintaining a single source repository, automating the build, testing in a clone of the production environment, ensuring everyone can see what’s happening and deployment pipelines.
These practices help to lay the foundation to why we should create pipelines as code and the approaches we should take. For example, version control is a very powerful tool. Keeping everything in version control means you can easily keep track of changes, review code and maintain a source of truth.
Read More »Given a new team or a team restructure, should you baseline? Do all teams point differently? Do the team need to baseline?
Do you need to align your pointing to be the same across teams? Should all teams point the same? Should teams be autonomous?
These are the types of questions that come up in newly formed teams that have a mix of experience with either agile or their peers.
Ultimately it should be up to you and the team. Teams should be autonomous. What works for you and your team is probably right. Nobody should tell you how to work, that is your job.
Read More »subscribe via RSS