Adminer, formerly known as phpMinAdmin, is a full-featured database management tool to be used as a more simple, effective and fast alternative to the famous PHPmyAdmin. Being curious about it, I had a chat with the creator of Adminer, Jakub Vrana.

They talk about the problem the tool tries to solve and where the idea to make it came from. There's also a bit about why to use it over something like phpMyAdmin and what the current status/future plans for it are. If you want to read an interview with Jakub about his work and experiences, you can check out this post.

In an earlier article I wrote, we took a general look at project management and discussed what some of its pitfalls are that should be avoided. As part of that, I mentioned that you should, as much as possible, be using an Agile methodology, particularly Scrum, to manage development. I'd like to follow that up with a look at Scrum and at how we can use it to tame our projects.

He talks about the typical "waterfall" technique of project development - requirements up front and cross your fingers for the rest. He compares this to the agile process and how scrum, in particular, helps keep things from falling apart. He then gets in to "how to scrum" by defining some of the key terms and talking about things like:

• Holding smaller meetings
• Limiting scope and time frame
• Looking for feedback
• Constant reworking remaining time

...all at the same time, multiple times during the life of the project. Agile focuses on quick changes and updates because the project is constantly getting feedback from those asking for the product, giving them (hopefully) exactly what they want.

Whether we like it or not, unless we are doing a hobby project just for our own amusement, even the most technical among us are really just project managers who can code. And, as a project manager, we can experience the heartbreak of project failure. [...] So what can you do as a technical project manager to minimize your chances of adding "leader of a failed project" to your resume? The answer is: pretty much what non-technical project leaders do.

He touches on a few key points that are important to any technology project, not just PHP ones - managing the expectations of the team and the business, using iterative processes and development and avoiding scope creep. He also drops in a bit about watching out for "weird stuff" that might be new or different to your group and their technology choices.

I will be continuing the topic on Continuous Delivery which began in my previous post: Notes on Continuous Integration; this time we will start looking at the first and most important step, Configuration Management. In the words of the authors (resource below): Configuration Management refers to the process by which all artifacts ... and the relationships between them, are stored, retrieved, uniquely identified, and modified.

He sets out four principles that can be used to set this process up in your workflow:

• Keep everything in version control
• Manage dependencies
• Manage software configuration
• Manage environments

Each point has an explanation and advice on what he's found the best way to implement the functionality. He finishes with a few other pieces of advice including avoiding branching in config repositories and having good communication practices with your ops team.

I have been using a Linux install for a couple years now and it has development checkouts (and matching databases + live data) for dozens of sites. Since I create a new virtual host for each site there hasn't been any problems piling more and more projects into this system. However, this computer won't last forever. [...] Should I setup a new VM + debian install for each project (seems like a lot of work). Should I just move everything to an external drive and point the MySQL data, MongoDB data, Nginx web folders to the attached drive? How do others handle this?

There's several suggestions made in the comments including things like:

• Using Ansible for configuration management
• Bundling the current linux install into one portable VM
• Using Vagrant for VM management
• Using source control that can be accessed from any device/VM

Have a VM management method you've found useful in your development? Share some about it here.

The general attitude of people arguing against dependencies is that dependencies are a bad thing. Why could they be a bad thing? [...] Why do libraries have dependencies at all? Is a library with dependencies less decoupled than one without?

He includes some of the common reasons dependencies might be a bad thing (including maintenance issues and space concerns) as well as comparing two similar concepts - "coupling" versus "cohesion".

What does this mean in practice? Can we just increase the amount of dependencies as we like? My personal stance on this topic is that a library should require as little as possible dependencies to run (hard dependencies) - as long as it is highly cohesive - but support as many different libraries as it can (optional dependencies).

Following Alexander Cogneau's introduction to dependency management with Composer, you now know that Composer is a resolver for managing external project dependencies and versioning constraints. But is that all it does? In this article I'll show you how Composer can also be used as a basic build automation tool.

Thanks to some handy configuration settings available in the "composer.json" file, you can execute scripts for events like "pre-install", "post-update" and "pre-uninstall". They include an example "Installer" class with methods for a few of the actions, showing some of the special methods you can use to get metadata about the current operation and environment.

In this article I will introduce you to another great project, Composer. Maybe you've experienced the pain of working on a PHP application which uses third-party libraries and then trying to keep them and their dependencies up to date. If so, Composer can soothe your pain. Composer gets you the libraries you want at the versions you need. And if those libraries use other libraries, it can install those and manage them as well. Dependency management can be a hassle-free experience using Composer.

He includes the basics like getting it downloaded and installed (via a single-line curl command) and creating a sample "composer.json" file to pull down some libraries from the Laravel framework. He also includes a bit about making your own library a package and adding it to Packagist. For more information about Composer (and Packagist) see the project's main website.

To get this extra functionality I added two packages to my composer.json. [...] The first is Upload by Josh Lockhart (who built Slim and started PHP The Right Way). It's currently very basic as it's not been alive long, but for the job I needed to do it worked perfect.

The second package is the ImageWorkshop that let him easily resize the uploaded images and add a watermark to the corner. He also points out that this method of pulling together packages, each with their own specializations, is the "early days of a PHP renaissance" in how people will work with the language.

Why is management a craft? It's a craft for the same reasons engineering is a craft. You can read all the books you want on something but crafts are learned by getting your hands in it and getting them dirty. Crafts have rough edges, and shortcuts, and rules of thumb, and things that are held together with duct tape. The product of craft is something useful and pleasing.

She goes on to fill out her description of what it really means to manage a development group including providing devs with the resources they need to master the subject and allowing them the autonomy to solve problems without having to be involved in every decision. You can read the rest of her thoughts here.