O’Reilly runs a nice and simple article on what is risk management. They look at it from the perspective of a web application, but the suggestions are generic enough to be applied universally. The highlights are:
- Managing risk
- Identifying risk
- Remove worst offenders
- Review regularly
I particularly liked this paragraph from the identifying risks section:
You will likely find that there are obvious entries in the list, but there should also be entries that surprise you. This is good. You want to uncover as many of your risk vulnerabilities as possible, and if some of them don’t come as a surprise to you, you probably haven’t dug deep enough.
Micro is a modern console based text editor, written in Go. Version 1.0.0 has been recently released. It’s cross-platform (installs as a single binary) and supports a variety of features:
- Easy to use and to install
- No dependencies or external files are needed — just the binary you can download further down the page
- Common keybindings (ctrl-s, ctrl-c, ctrl-v, ctrl-z…)
- Keybindings can be rebound to your liking
- Sane defaults
- You shouldn’t have to configure much out of the box (and it is extremely easy to configure)
- Splits and tabs
- Extremely good mouse support
- This means mouse dragging to create a selection, double click to select by word, and triple click to select by line
- Cross platform (It should work on all the platforms Go runs on)
- Note that while Windows is supported, there are still some bugs that need to be worked out
- Plugin system (plugins are written in Lua)
- Persistent undo
- Automatic linting and error notifications
- Syntax highlighting (for over 75 languages!)
- Colorscheme support
- By default, micro comes with 16, 256, and true color themes.
- True color support (set the
MICRO_TRUECOLOR env variable to 1 to enable it)
- Copy and paste with the system clipboard
- Small and simple
- Easily configurable
- Common editor things such as undo/redo, line numbers, unicode support…
Although not yet implemented, I hope to add more features such as autocompletion, and multiple cursors in the future.
If you are looking for a new editor, give Micro a try.
CommitStrip does it again:
From this article, I’ve learned about an excellent (for our times) 10k Apart competition:
Think you’ve got what it takes? You have until September 30th.
I can’t wait to see the submissions and all the ways to squeeze the awesomeness of the modern web into just 10 kilobytes. This reminds me of the Perl Golf posts over at PerlMonks and
Assembly PC 64K Intro from my childhood early days (here are some examples).
“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.
Eric Dietrich, over at DaedTech, explains how he writes good code. It’s a post worth a read in full, but here is a summary:
- 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):