On the TechBeacon site they've posted an article about choosing the right testing tools for your codebase and why making the right choice matters.

Fast end-to-end tests are the next big thing. The tooling has improved tremendously, and the productivity and insight gains are too good to ignore. Modern tools such as Cypress and >TestCafe are becoming quite impressive and can give you confidence in your product's quality.

As with most facets of software development, there is a balance to be strived for between speed and test confidence. The leverage point depends on the project, and the two most common types of software project these days are web services and enterprise software.

They talk about some of the differences between the testing of web services versus enterprise software as well as some of the practical advantage of fast tests. They also cover the advantages of broad tests and cover some of the current tools for testing including Cypress.io and Laravel Dusk.

In this post to his site Christian Mackeprang shares what he calls "Newton’s 3 Laws of Software Craftsmanship" - some guidelines to follow in your development to help make things a bit more sane.

Are there unbreakable laws ruling the process of software development? I asked myself this question while reflecting on a recent project, and the answer leads to many conclusions, some already known and some more revealing.

Scientific laws reflect reality and cannot be broken. They have strong implications onto how we build things. For instance, there is no point in building a car with vertical propulsion once you’ve observed that the law of gravity will prevent your car from drifting into space anyway. But software lives in the logical world. Does it really follow any laws?

He shares his three laws and provides a bit of background for each:

• "Under fixed circumstances, every solution will behave the same way, unless it has been modified."
• "The impact of a technical decision is directly proportional to the size of the project and to how much of it is affected."
• "Every technical decision comes with an implied tradeoff."

He also includes a "how to be mindful" section for each of the laws, giving you both practical and mental tips to help you follow it.

On the Laravel Daily site there's an interesting article that shares some opinions on when to use Laravel and when to use WordPress as a base for your applications.

In PHP world there are two big groups of developers – those who work with Content Management Systems (WordPress, Drupal etc.) and those with frameworks (Laravel, Symfony etc.). And rarely people work with both worlds – cause their philosophy is fundamentally different.

But when you get a new project from a client – how to decide whether Laravel is the best choice? Or maybe simple WordPress would be enough and would save time/money? Sometimes it’s not that easy to decide. So here are my tips – questions you need to ask.

In the remainder of the article he suggests four questions to ask yourself to help make the decision one way or another:

• Content or user actions?
• Plugins or packages?
• MVP or serious project?
• Who will work on the project?

He elaborates on each point with a bit more context and criteria that could help answer the question in your case.

In a new post from the QaFoo blog they talk about a developer's life as a trade-off, the amount of work to put into one technology or approach before deciding it's not worth the trouble and moving on.

At Qafoo, we train a lot of people on topics like object oriented software design, automated testing and more. [...] There is no silver bullet and one of the most important skills every developer needs to hone is to assess possibilities and to find the best trade-off for the current challenge.

He uses personal experience to illustrate the point, a struggle they had with choosing a storage system for their application's data. While one technology seemed to be an ideal fit (Cassandra) the trouble it caused made them fall back to something more reliable. He also talks about another instance where he had to make a decision around using a state machine...or not, because of the overhead and time consumed around it.

One of the most important tasks of a developer is to make trade-offs. They occur wherever you look in your every day life. It is a highly important step to realize and accept this. And it is important to hone that skill. You need to open your mind for new technology and techniques, learn and try them wherever you can. But then you need to step back, analyze the current situation and then find the best trade-off between all possible approaches.

On the MayFlower blog today there's a new post looking at two ways to do software architecture (the easy way and hard way) and some of the traditional practices behind its development.

When it comes to software architecture, stuff gets funny. First we learn everything about it at university. We learn to use it as a part of our main project plan. We learn how to do risk evaluation. [...] Since we didn't have a lot of experience with software back then, the resulting architecture is a badly done, but well documented. This style of software architecture is called "Enterprise Architecture" and usually done by consultants.

They talk about delivering software versus delivering documentation and list some of the actual common reasons software architecture turns out how it does including: "I read about it in a blog", "It worked for me once" and the idea of the "Golden Hammer" of standardized structures.

Cal Evans has a suggestion for all of the developers out there not happy with decisions being made at their workplace (or in the contracts they work with) - man up!

Look, it's easy. As developers, we see people we don't respect making decisions we don’t agree with. I know how difficult this position is because like every other developer in the world, I've been in this position. However, unlike a lot of developers I've talked to in recent years, I don't see "digging my heals in" or whining as alternatives.

He suggests one of two alternatives to the situation - either deal with things head-on and get onboard with the decision or jump ship and find something else that suits you better. Sometimes this is a bit easier than others (terminating contracts versus leaving a full-time job), but if you're really that upset with it, it's probably not going to get any better.

talk to a lot of people about how to build teams and the cornerstone of any good team is respect. Management has to respect developers and I firmly believe that. However, you as a developers, have to respect management as well. It is a two way street.

Brandon Savage has a new post about something that some developers out there factor into their development estimates from the beginning and others are just learning how to adjust to - the sunk cost that can be associated with writing code.

Last week, I began working on something that didn’t pan out. For whatever reason, I went down the wrong path, and ultimately abandoned the task I was working on. In discussing it with my boss, he mentioned to me that it was better to realize early on that something wouldn’t work than to trudge onward, insisting that it be finished due to the "sunk cost" of the time already spent.

There's two sides to this story - one in which the application continues to be developed and takes up more time (but still ends up as a product) and the other where the time already spent is lost as a completely new approach is taken.

PHPBuilder.com has posted the eighth part of their introductory "ABCs of PHP" series today. This time the focus is on looping and decision functionality (like if/while/for/etc).

n any given computer language (PHP is no exception) there has to be a way to allow the running code to decide between doing 2 different things. If there wasn't then software would not be able to adapt based on operating conditions, or it wouldn't be able to decide between two different users.

They look at using: if statements and operators, for loops and while loops. When they look at the operators, they talk about the differences between equals/not equals, grater than/less than and two of the boolean operators - AND and OR.

Lukas Smith has written up the FAQ for the emPHPower movement and has posted about them on his blog:

Well unfortunately due to timing issues the emPHPower BoF at OSCON fell through. So it goes. In preparation for the BoF I have however taken the time to write down an FAQ. So the submission of the OSCON BoF was at least a kick in the butt for me to get this done. Please have a look and let me know if anything is unclear or unanswered.

The FAQ includes answers to lots of questions including:

• How to I get involved?
• What is the target audience?
• Will emPHPower compete with existing community efforts?
• What is the purpose of the membership fees?
• Why should companies not be allowed to sponsor emPHPower directly?
• Who decides on what emPHPower does?

Sometimes developers just don't think about how much trouble they'd cause with a rewrite of existing software. They think that moving up to the latest and greatest is the way to go, and that it makes perfect sense to say out with the old and in with the new. Aaron Wormus disagrees. Well, sometimes - it depends on the circumstances, really.

At ZendCon I talked about "Planning a PHP 4 to PHP 5 codebase rewrite, a practical approach". The talk was based on my own experience, as well as famous discussion of the topic such as Joel Spolsky's "Things you should never do" and the examination of "famous" platform rewrites.

Aaron gives an example of a large company making a move from a COBOL system out to C for a mission critical system. Based on his tale, they didn't put the thought needed into making this move - new development time, keeping old developers on staff, etc - besides the fact that customers don't like change and making a move to another platform is almost definitely going to be noticed by them.