PHPMetrics is yet another tool for static analysis of your PHP codebase. It aims to provide a simpler and easier to understand report, than all those other tools in the PHP ecosystem today.
Headless Browsers is a list of (almost) all headless web browsers in existence. These are browsers without graphical user interface, controlled programmatically, and useful for testing, automation, and other similar tasks.
I’ve used one or two. I’v heard about three of four. I had no idea there was such a variety though.
CommitStrip strikes again! Brilliant.
Software Engineering Tips shares some tips on how to figure out if you are a bad programmer, and how to remedy that.
Signs that you’re a bad programmer
- Inability to reason about code
- Poor understanding of the language’s programming model
- Deficient research skills / Chronically poor knowledge of the platform’s features
- Inability to comprehend pointers
- Difficulty seeing through recursion
- Distrust of code
If you are not a bad programmer, check if you are mediocre one.
Signs that you are a mediocre programmer
- Inability to think in sets
- Lack of critical thinking
- Pinball Programming
- Unfamiliar with the principles of security
- Code is a mess
And, finally, here are some signs that you shouldn’t be a programmer.
Signs that you shouldn’t be a programmer
- Inability to determine the order of program execution
- Insufficient ability to think abstractly
- Collyer Brothers syndrome
- Dysfunctional sense of causality
- Indifference to outcomes
The article also suggests some alternative career paths for you.
- Command-line flags, with the link to gflags.
- A/B flags
- Dynamic flags, which are more difficult
- More complex systems.
I’ve dealt with feature flags before, but never found an elegant way to scale those. Some of the issues that I came across were:
- Naming conventions. With more and more features added to the system, naming things becomes more and more difficult. Especially, when features cross over from one part of the system into another and need to be supported in different sub-modules. In a way, this reminds me of the old argument in the blogging community about using hierarchical categories vs. flat tags, with categories providing more order and tags providing multiple paths to the destination.
- Modularization issues. Feature flags are often need in the larger applications. The kind that provides a lot of features (duh!). But those large applications often consist of smaller parts, or modules. Deciding whether or not to implement the feature on the application level, and/or on the module level is difficult. Especially if those module features will need to be later grouped into application features.
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
— Jeff Atwood (@codinghorror) August 31, 2014
In terms of implementation, I haven’t used any special tools or libraries. It was basically a set of configuration files, with feature variables defined per environment and altered during the deployment.
These days, something more robust than that is necessary for some of the projects at work. Gladly, there are plenty of available tools to choose from – no need to reinvent the wheel. For a good starting point, have a look at PHP Feature Flags website. The ones listed so far are:
- LaunchDarkly PHP Feature Flag SDK, to integrate your application with LaunchDarky service.
- Etsy Feature Flagging, not officially supported by Etsy anymore, but still popular and useful.
- Dzunke Feature Flags, which is a bundle for Symfony2. It’ll require Symfony-Configs for the actual features configuration.
- Qandidate Feature Flagging Library
- Rollout, a port of ruby’s rollout.
- PHP Feature Flags
- SoCloz Feature Flag Bundle
So, I guess, PHP is well covered when it comes to feature flags tools. The above cover cookie-based, IP-based, URL-based dynamic features, configuration-based features, and A/B features.
The point now is to actually utilize them in the project. After all, the lack of feature flags is one of the 5 toxic things for the scalability, as per this page:
- Object Relational Mappers (ORMs)
- Synchronous, Serial, Coupled or Locking Processes
- One Copy of Your Database
- Having No Metrics
- Lack of Feature Flags
I haven’t decided which library to use yet – will need to try them all and see which one is the most appropriate, but for now I don’t think I’ll dive as deep as cookie/URL/IP based features or A/B testing. Even the simplest configuration-based implementation will be helpful.
Warning: you will lose a lot of sleep if you follow the link below. :)
No matter how well you know Vim, bash, git, and a whole slew of other command line tools, I promise you, you’ll find something new, something you had no idea existed, something that will help you save hours and hours of your life by shaving off a few seconds here and there on the tasks you perform on a daily basis, in the repositories link to from this site.
I think I’ve spent most of my Sunday there and my dotfiles are so different now that I’m not sure I should commit and push them all in one go. I think I might need to get used to the changes first.
Some of the things that I’ve found for myself:
- PHP Integration environment for Vim (spf13/PIV).
- myrepos – provides a
mrcommand, which is a tool to manage all your version control repositories.
- bash-it – a community Bash framework.
- Awesome dotfiles – a curated list of dotfiles resources.
… and a whole lot of snippets, tips, and tricks.
P.S.: Make sure you don’t spend too much time on these things though :)
Wait, what? That’s exactly what I said when I read this blog post. I am still making my way through the JSON API specification. And now it seems I might be wasting my time, as I should be learning HAL.
Whereas JSON API is almost like an “ORM over HTTP”, HAL does a lot less for you though, so it’s not really an apples-to-apples type of comparison.
HAL really is just a document format for a hypermedia API, like HTML is for hypertext. It doesn’t tell you how to express your domain model, and doesn’t really tell you how to use HAL to submit changes.
Sometime I think that I should just stop learning. What’s the point? By the time you learn a thing or two, it’s already obsolete and somebody somewhere has created something better, or wiser, or cheaper.
This initiative researches the PHP package ecosystem to recognize commonly adopted development practices. It rationalizes and refines those practices, then publishes them as PDS packages for reference by PHP package authors.
PDS publications are derived from and supported by common practices existing in real packages, as adopted by existing authors who have a continuing interest in the quality and consistency of their own work.
Have a look at php-pds/skeleton GitHub repository.
Personally, I welcome this initiative. PHP ecosystem exploded in the recent years with the help of composer and Packagist.org. There are over 120,000 packages just on the Packagist.org. I think, it’s good to have some standards and best practices. The PHP Framework Interop Group (PHP-FIG) is doing its best with the PHP Standards Recommendations (PSRs). But we could have some more guidelines in order to have some consistency.
PHP Package Development Standards takes, in my opinion, the right way of looking at what’s out there, what works and what doesn’t, and than setting the guidelines based on the real world practices. They cover things like file and directory naming conventions, versioning, changelog and licensing – which are common issues for pretty much every package.
Looking at the packages that I am involved with, only a few minor changes are necessary to comply. Mostly, the “config” folder instead of the Unix-style “etc“, CONTRIBUTING file, and a CHANGELOG file, which I’m still to find a good way to semi-automate.
Peteris Krumins, of the Browserling fame, has a series of blog posts on his top favorite programming, computer and science books. It’s an excellent selection of titles, from which I’ve read only a fraction. Good timing for the Christmas shopping too. Here are the blog posts in the series so far (5 books per post):
- Part one. Note to self: read “The New Turing Omnibus”.
- Part two.
- Part three. Note to self: read “The Unix Haters Handbook (free pdf)“, buy (again!) “Unix and Linux System Administration Handbook” or find who has any of the three previuosly purchased copies.
- Part four.
- Part five.
- Part six. Note to self: read “The Unix Philosophy”.
Even with the 30 books mentioned so far, there are new things to read and learn. I wonder how many of the notes to self I’ll have by the time the whole 100 are listed.