In a recent post to his site Eduards Sizvos shares an opinion that's believed by many in the development world: stop learning frameworks.

We are developers. We need to stay up to date with technology. Every day, we learn programming languages, frameworks, and libraries. The more modern tools we know?—?the better.

Keeping up to date with Angular, React, Vue, Riot, Ember, Knockout is fun.

But we are wasting our time.

He goes on to talk about time, how important it is to spend on the right things and offers a story of his own where learning specific technologies didn't help in the long run. He then shares some resources (books) to help you learn good concepts instead of specific tools.

Remember – frameworks, libraries and tools come and go. Time is precious. Invest your golden time in transferable skills. Skills that will always be relevant.

Rob Allen has posted a new tutorial to his site sharing how you can set up route specific configurations in Slim by setting it as a part of the route definition.

A friend emailed me recently asking about route specific configuration in Slim. He wants to be able to set properties when creating the route that he can pick up when the route is matched. The way to do this is using route arguments. I’ve written about route arguments before in the context of setting default values for a route parameter, but you can also use them to set new data for use later.

In this post, I’m going to look at how to use them for configuration data, such as setting required ACL permissions for routes.

He includes code snippets showing how to set the per-route data and how to access it from inside of the request handling via the Request instance. He shows an example of this both in the basic route definition and in middleware.

In a post to his site Ewan Valentine looks at some considerations to think about when creating a domain specific language in your applications. This kind of language helps define common terms, conventions and practices for developers to follow in their code.

When you spin up a framework such as Laravel, Symfony etc. The first thing you'll notice, is that they have their own 'feel'. I often joke that Symfony2 is like Java and Laravel is like Ruby.

But what gives an application or a framework a 'feel'? Domain specific language or 'DSL'. Domain specific language is almost like a syntax or a language specific to your application and ecosystem. DSL is what makes your applications code unique and more usable.

He gives a specific example of a Laravel application he was creating and how he wanted the interface to function, transforming the result of a find() into a JSON response. He shows how it could actually be done but that introduces more maintenance and more code to cover. Instead he worked backwards into the domain context the request was operating in and found an ideal injection point for transformation that would keep it out of the controller action itself.

So, to design usable domain specific syntax, start at the front. In other words the part you'll be writing the most, and then work backwards to abstract the logic and make it actually work.

Rob Allen has a new post to his blog today looking at bootstrapping specific modules in a Zend Framework 2-based application without having to do the entire set.

Following on from the discussion on modules, we can hook into the event system to do module specific bootstrapping. By this, I mean, if you have some code that you want to run only if the action to be called is within this module, you can hook into the Application's dispatch event to achieve this.

He starts with an example of a basic module (Simple/Module.php) and shows how to define an "onBootstrap" method that calls the "onDispatch" method (when hooked to the event manager) to do some module-specific bootstrap operations. The RouteMatch feature is used to ensure that you're in the right controller/namespace combo to use the module.

Mike Purcell has a quick new post to his blog showing how you can run PHPUnit on one specific test using handy grouping functionality already built into the tool.

The other day I was debugging an error in one of my unit tests, and found it hard to track down because when I ran PHPUnit, it ran all the tests contained in the file where my problem unit test was located. After some Googling and reading the PHPUnit Api Docs, I found that you can specify a test, among other tests, by adding a comment with the @group annotation.

Using this "@group" annotation tells PHPUnit to combine these tests and allows you you specify a "--group" setting on the command line to only run those. He includes some sample code showing how it can be used. This can be very useful for combining results for certain kinds of tests (say, all related to bugfixes) without having to run everything all over again.

Cal Evans has posted the final point in his "Six Ways to be a Better Client for your Developer" series seeking to make the client/developer relationship more stable and enjoyable for both sides. This latest tip involves the paperwork part of the relationship.

Good fences make good neighbors just as good contracts make for good developer/client relations. At the very least your agreement with your developer should contain a complete description - in non-vague terms - of each feature to be built as well as a paragraph description of the overall project.

He emphasizes that, if the feature or change is not included in the documentation from the start, it's not a part of the project. Making assumptions on vague definitions will only cause problems down the road, so be specific in what you want.

If negotiating the contract with your developer is a hassle, consider it your last opportunity to walk away and find another developer.

Cal Evans has posted a sort of lighthearted beginners guide to some of the terms that those outside the software development industry might not know - five terms with their explanations.

When I venture out into the real world, the one not populated with developers, I get a lot of strange looks and odd stares when I talk. Apparently there are a lot of people out there who don’t grok grep, have never been slashdotted, and can’t tell a brown number from a WAG. [...] Today I am going to share five of our more colorful terms from the software development DSL.

Some of the terms are well-known outside of the software development world like "yak shaving", "bike shedding" and "dogfooding" but there's one unique to the PHP community - being "Rasmused"...having less people in your talk's crowd because of a talk from someone more popular at the same time (Cal explains it better).

Paul Gregg has shared a method he's come up with to determine if a given IP is within a selected range.

Unfortunately although people usually understand that an IP address is simply an unsigned 32 bit integer, and is easily determined, usually with $_SERVER['REMOTE_ADDR'], where the real challenge is - is in specifying the range within which they wish to check that IP address. IP ranges are usually specified in three common ways (in increasing complexity): wildcard, start-end range, classless inter-domain routing.

He looks at each method and includes descriptions and code examples as well as a link to the source code and a live demo of it in action.

Kae Verens has a few tips to help simplify your life with your current content management system by using one code base to run multiple sites.

I haven’t studied how other engines do it, but here’s how I do it. First off, some benefits to sharing the CMS across separate sites: reduced resource usage, easier upgrades, easier bug-fixing. Convinced yet? Of course you are. Here’s how you do it.

There's four steps to his process:

• Separate out the site-specific files from one another
• Serve all site-specific files out through a "proxy" script that can intelligently grab the needed ones based on the site
• Override the default configuration at request time (forcing it to use that "proxy" script)
• Create that proxy file that the web server can funnel the requests through (his example is included).

Padraic Brady has posted about a part of his PHPSpec library, the domain specific language.

PHPSpec implements a domain specific language (DSL) in PHP for specifying the behaviour of functional units such as methods and objects. The purpose of a DSL was to move away from the xUnit style declaration of tests towards a specification language centred on describing behaviour.

He illustrates with a bowling example - described with a sample class (with a itShouldScore0ForGutterGame test) and how to use it to fit his proposal:

My proposal therefore is to re-implement the current programming language DSL as a specification language - i.e. a new (extremely limited and narrow!) language capable of being parsed by PHPSpec into its PHP equivalent. [...] Using a specification DSL, we can simply ignore the existence of classes in PHP (well, the pretense is nice). Instead the DSL would incorporate a syntax for denoting shared behaviours.