On 7PHP.com today there's a new interview with Jakub Vrana about his tool Adminser, a lightweight alternative to things like phpMyAdmin for database management.

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.

PHPMaster.com has posted a bit less of a technical article than usual and shares some of the concepts behind scrum, the project management style that's currently quite popular with development groups.

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.

On PHPMaster.com today there's a new post that takes a different approach to PHP development than some of their articles in the past. It comes at it from the project management side of things, talking more about how to run the project and less about the technology it involves.

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.

Luis Atencio has continued his series on continuous delivery with this second post. It focuses on the first step (and one of the most important) - keeping everything configuration-related in a version control system.

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.

On Reddit.com there's a discussion that centers around the management of VMs and PHP projects in a multiple-checkout environments.

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.

On the Web Mozarts blog there's a recent post from Bernhard Schussek looking at some of the recent talk about dependencies in the PHP community sharing some of his thoughts on the subject and the Not Invented Here thought pattern.

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).

If you're a PHP developer and have been looking for a good way to manage 3rd party dependencies in your applications, look no further than Composer. If you're already using it, you know how useful it can be, but you might not know about some of the extra features that come with it. In this new tutorial on PHPMaster.com, they describe the automation that is also possible as a part of Composer's management process.

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.

If you haven't taken a look at the Composer tool for package management in your PHP applications, you owe it to you and your development process to check it out. PHPMaster.com wants to help you out and has posted a new tutorial telling you all about the system and how to use it in your applications.

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.

Phil Sturgeon has a new post to his site talking about how he added image upload and management support to an application with an easy integration of two packages (pulled in via Composer).

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.

Laura Thompson has a new post to her site about the "dark craft" of engineering management and of her thoughts as to why it's as much a "craft" as writing the actual code.

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.