In this recent post to his Medium.com site Subhas Dandapani shares what he sees as the top ten modern software over-engineering mistakes developers make in modern application development.

Few things are guaranteed to increase all the time: Distance between stars, Entropy in the visible universe, and Fucking business requirements. Many articles say Don't over-engineer but don’t say why or how. Here are 10 clear examples.

Important Note: Some points below like “Don’t abuse generics” are being misunderstood as “Don’t use generics at all”, “Don’t create unnecessary wrappers” as “Don’t create wrappers at all”, etc. I’m only discussing over-engineering and not advocating cowboy coding.

Points in his "top ten problems" list include:

• Engineering is more clever than Business
• Everything is Generic
• Shallow Wrappers
• Overzealous Adopter Syndrome
• In House “Inventions”

Each item in the list comes with a bit of explanation and an image or two where appropriate. There's definitely some things in here that are a bit debatable, but development has and will always have a file line between over-engineering and "just the right amount" of work. The trick is figuring out where that line is for your development work.

In the latest episode of the Full Stack Radio podcast host Adam Wathan talks with Jonathan Reinink about common API design mistakes and some recommendations on how to fix them.

In this episode, Adam talks to Jonathan Reinink of Code Distillery about common API design challenges and how to fix them. Topics include: when to use nested resources and when to avoid them, strategies for dealing with actions that don't seem to fit into REST and sing singular sub-resources and optional fields to simplify your responses.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly. If you enjoy the show be sure to subscribe to their feed or follow them on Twitter for news on when the latest episodes are released.

On his site today Ulf Wendel talks about SQL injection and some comments that came up during a recent webinar about common MySQL mistakes PHP developers make.

Never trust user input! Injection is a threat . You are the new web developer, aren’t you?. Never trust user input is the first rule I had to learn as a web developer in anchient times. Injection can happen whenever user input is interpreted or used to compose new data. A quick recap of the #3 mistake from todays Top 10 MySQL Tips and Mistakes for PHP Developers web presentation. A webinar recording should be available in a couple of days.

He points out a few "don't" things to avoid - like directly injecting superglobal values into your query and to remember that not all SQL injections are because of escaping issues. The real key? Validating input - be sure you're putting values into your query that are of the correct type and contain what you expect.

On the DeveloperDrive.com site today, there's a new post with a few reminders for PHP developers out there of things it's easy to forget when writing your applications - some common mistakes to avoid.

Despite the high expectations placed on them at times, developers are human. They were the last time we checked anyways. As humans, we are bound to make mistakes from time to time. And simple, common mistakes often slip past our filters the more comfortable we become with something. [...] But knowing what these common mistakes are and how to avoid them can really help speed up the development process and keep our clients smiling.

His list includes three big ones that, if forgotten, could end up being detrimental to your application (sooner or later) - poor housekeeping/organization of code, forgetting punctuation and forgetting to validate input from users.

On the SitePoint PHP blog today there's a new post from Craig Buckler looking at his top ten MySQL mistakes he as a PHP developer has made over time (and suggests a few things so they can keep from making them again).

database is a fundamental component for most web applications. If you're using PHP, you're probably using MySQL - an integral part of the LAMP stack. PHP is relatively easy and most new developers can write functional code within a few hours. However, building a solid, dependable database takes time and expertise. Here are 10 of the worst MySQL mistakes I've made (some apply to any language/database).

Some of the infamous mistakes that made the list include:

• Using PHP's mysql functions (instead of mysqli)
• Not sanitizing user input
• Not using UTF-8
• Not optimizing your queries
• Using * in SELECT queries

Smashing Magazine has posted an excellent security guide to get you on the road to protecting your site and its data from some of the most common mistakes applications can make. Several of the topics even come with PHP code to illustrate.

Unfortunately, unless we’re careful with the code we write, the answer to these questions can often be one we’d rather not hear. We’ll skip over denial of service attacks in this article, but take a close look at the other issues. To be more conformant with standard terminology, we’ll talk about Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Phishing, Shell injection and SQL injection. We’ll also assume PHP as the language of development, but the problems apply regardless of language, and solutions will be similar in other languages.

For each of the topics, there's a general description of how the attack works and, if applicable, some PHP code showing the right and wrong ways it can be handled. Fir things like Click Jacking or Phishing, the descriptions aren't so much about backend code as they are frontend and personal manipulation.

On the Drupal4Hu.com site there's a recent post with a complaint about the OOP functionality in PHP and how Drupal developers should deal with its limitations.

While I was always complaining of PHP's inability of adding a method run-time, the problem we face is that you can't replace one either. So if you do what I did in the previous post, namely use the hook-alter patten (already an addition to PHP, I must say) to override the classname, that works. However, if two modules try to do this for two different methods, you fail.

He suggests to those Drupal developers out there that, for version 8 of the popular content management system, they drop the "closed crap that in PHP is called OOP" and work to make something better, implemented themselves. Something that would make it simpler for Drupal developers to create hooks into the main system for their plugins. Be sure to read the comments for other opinions on the post.

In a new post to his blog today Sean Coates talks about some of his work with Iterators in PHP and how, despite a bad example in the manual, he solved his issue (and updated the PHP manual too).

In the back end, we have models that connect to CouchDB. These models implement the Iterator pattern to allow easy traversal of a record’s keys. [...] Little did I realize that this implementation is very broken. [...] Over the past few years, I’ve implemented many iterators in this way, using PHP’s implicit array manipulation functions (reset(), current(), key(), next()).

He points out some issues with how PHP handles array index tracking and how, in the previous PHP manual example, it incorrectly checked for "false" against the current array value. His updated version doesn't have this issue. You can see it here.

From the SellMix blog today there's a new post with a few "no-nos" and misconceptions when it comes to working with PHP in your applications.

We have all had that moment where we looked back on a script that we wrote years ago and thought "what the hell was I thinking?'". But it is a process. You make mistakes, you learn from those mistakes and then you move on. From my experiences of modifying other people's code, helping people on PHP help forums and making my own (many) mistakes, I hereby present this list.

There's eleven points included in the list, touching on things like:

• Superglobals being referred to inside class functions
• MySQL queries inside loops
• Brackets '" use them.
• Indent, indent, indent!
• Why are you using mysql_fetch_array?

Check out the rest of the post for more tips.

Jani Hartikainen has posted about three simple, but hard to find, mistakes that can cause you endless frustration if you're not looking in the right places.

Here's his list:

• Semicolon after a while - a small problem with big (infinitely looping) consequences)
• empty() and magic __get method - __get will hit first, then empty
• Missing semicolon after break or continue - a classic that can make switches and evaluations difficult to debug

Comments on the post include a few others: working with variables by reference, comparisons with == versus === and strpos finding the first character in a string.