CommitStrip does it again:
“Git Workflow Basics” is yet another take on the git workflow. This subject has been covered in a variety of ways before (here, here, and here, for example), but I think it’s super important for every developer to understand, so if all the other attempts left you puzzled and confused, have a look at this one. It’s pretty straight forward.
One thing in particular that I would like to emphasize:
And hey: remember to review your own pull request before asking for reviews of your teammates. You’ll spot a lot of small things you didn’t notice (style issues, typos, etc) and will allow your colleagues to focus on what really matters.
PHP backdoors repository is a collection of obfuscated and deobfuscated PHP backdoors. (For educational or testing purposes only, obviously.) These provide a great insight into what kind of functionality the attackers are looking for when they exploit your application. Most of these rotate around file system operations, executing commands, and sending emails.
One of the things from those files that I haven’t seen before is FOPO – Free Online PHP Obfuscator tool.
I first heard about the twelve-factor app a couple of years ago, in Berlin, during the International PHP conference. It was the basis for David Zulke (of Heroku fame) talk on the best practices for the modern day PHP applications.
The twelve-factor app is a methodology for building software-as-a-service apps that:
- Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
- Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
- Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
- Minimize divergence between development and production, enabling continuous deployment for maximum agility;
- And can scale up without significant changes to tooling, architecture, or development practices.
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
Here are the 12 factors, each one covered in detail on the site:
- Codebase: one codebase tracked in revision control, many deploys.
- Dependencies: explicitly declare and isolate dependencies.
- Config: store config in the environment.
- Backing services: treat backing services as attached resources.
- Build, release, run: strictly separate build and run stages.
- Processes: execute the app as one or more stateless processes.
- Port binding: export services via port binding.
- Concurrency: scale out via the process model.
- Disposability: maximize robustness with fast startup and graceful shutdown.
- Dev/prod parity: keep development, staging, and production as similar as possible.
- Logs: treat logs as event streams.
- Admin processes: run admin/management tasks as one-off processes.
These seem simple and straightforward, but in reality not always as easy to follow. Regardless, these are a good goal to aim at.
“The traits of a proficient programmer – Bridging the gap between competence and proficiency” is a good continuation of the recent “What is a Senior Developer?” discussion. This time, the question “Do you know what the difference between competence and proficiency is?” is asked and answered:
Competence means having enough experience and knowledge to get stuff done; proficiency involves knowing why you are doing something in a certain way, and how it fits into the big picture. In other words, a proficient practitioner is always a competent practitioner, but the opposite may not be true.
There are also some tips on how to become proficient.
- Make it easy to change
- Make it really readable
- Make it work
- Make it elegant
- Learn from accomplished practitioners
He is also listing a few books to learn from (the Amazon links are those of Eric – I have no idea if they are affiliated or not, but if they are, he’ll get the credit, like he deserves):
- Clean Code: A Handbook of Agile Software Craftsmanship
- The Clean Coder: A Code of Conduct for Professional Programmers
- The Pragmatic Programmer: From Journeyman to Master
- Working Effectively with Legacy Code
- Test Driven Development: By Example
- Code Complete: A Practical Handbook of Software Constructio
TravisCI – a continuous integration service – shares some of the insights from over 2,000,000 builds they’ve run, in an blog post called “What We Learned about Continuous Integration from Analyzing 2+ Million Travis Builds“. For me, the most valuable bit is about the reasons for failing builds, which clearly indicates the need for and the importance of unit, integration, and UI tests:
Around 20% of all builds fail. There is a variation based on the language – for some programming languages, testing is part of the process and culture – for others it’s an acquired tool. Once you do implement testing, most of your builds will run. You’ll cancel very few. But about 20% will fail due to failed unit tests, configurations, or environment setups. Catching these 20% before it hits production is super important.
A few days ago BitBucket announced the re-worked dashboards, which are now much more focused on the Pull Requests that you’ve created or need to review, rather than lists of repositories that you have access to. I’ve enabled the feature for my team and it looks super awesome!
If you’ve been suffering from being lost in dozens or hundreds of projects and missing out on the Pull Requests activity, check them out. You’d be surprised.
With August, a month when so many people take their annual leave, upon us, CommitStrip nails it once again: