On his Medium.com site, Adnan Ahmed has shared some of his thoughts about being a modern backend developer in 2018. In it he talks about the current state of backend development and makes some recommendations for those wanting to get started.

Web development today is completely different from what it was a few years ago; there are lots of different things that can easily baffle anyone entering into the web development. It was one of the reasons that we decided to make these step by step visual guides demonstrating the bigger picture and to give anyone a clear idea about what they have to follow to be in certain roles in web development.

The post starts with a large infographic showing the basic steps and some of the related technologies and concepts to go with them. Following this they break it down into more detail in a text form with summaries attached for each. There are a lot of topics in the list (24 of them) but here's some of the highlights:

• Learn a Language
• Learn a Package Manager
• Standards and Best Practices
• Security
• ?Learn about the Relational [and NoSQL] Databases
• Learning a Framework
• Caching
• RESTful APIs
• Different Auth Methods
• GraphQL [and Graph Databases]

His final recommendation is one that's good for beginners and veterans in the software development world alike: "keep exploring". If you stop learning and stop trying new things you'll stagnate in your own work and career. Challenge yourself to learn something new - a new language, tool or technique - as often as possible and apply it to your work.

On the ClearCode blog today there's a new post for the Synfomy2 users out there with some recommendations about taming your project to make it more manageable and maintainable.

When managing projects based on Symfony2, from the technical side, it is a good idea to establish a set of rules for the project. If you haven’t established and implemented such rules yet, then they should be created as soon as possible. Why? Well, no matter how many people are working on the project, the code needs to look like it was written by one person. [...] Symfony documentation doesn’t specifically focus on this issue, and the bundles that are written by the community have their own set of rules. [...] Learning from mistakes as you go along cannot only be costly, but also time consuming. It is good to have a starting point, something that at least has worked for someone else. This is how the idea to share the guidelines on the Taming Symfony Project came about.

They list out some of the guidelines of the project centered around various aspects of the implementation and the directory structure. They also talk about standards around the use of Doctrine, Twig and Services.

Phil Sturgeon has posted a set of best practices he follows when building out new APIs. It covers a wide range of topics at a high level, but it's a good checklist to get you started.

PHP developers are increasingly moving over to API development, as are a lot of server-side developers. It's a trend thats been happening for the last few years and it's getting to the point where everyone and their dog are putting articles showing off how to build "awesome" API's. Unfortunately most of these are either woefully inadequate or are promoting bad practices.

His recommendations include:

• Use the URI sparingly, and correctly
• Resources are EVERYTHING
• Authentication
• Background all the things
• Version your API like an adult

Each item in his list has some points to back it up and provide a bit more detail on what it's all about.

7PHP.com has posted a new article where they asked Lorna Mitchell for some of her advice for those wanting to take the Zend Certified Engineer exam, including what the test is like and how you can prepare effectively.

This is the 2nd set of Zend Certification Tips and Advice to help anyone taking either of the two Zend Exams powered by Zend Technologies: the Zend PHP Certification Exam and/or the Zend Framework Certification Exam. The aim being to help people who want to sit for those exams and inform them what it is all about & what to expect by hearing it from (pro) PHP Guys who have already been through it, that is => Hear It From Zend Certified Engineers!

They start with a little background on her and her experience with PHP and get quickly into the questions about the exam. Topics include things like:

• What the test is about and hopes to achieve
• Some things you can do to prepare
• A recommendation to make the most of your time exploring topics you might be weak in
• Whether or not the ZCE training classes help in the learning process

You can read the rest of the interview here.

On PHPMaster.com today David Shirey is back with the third part of his series looking at using PHP on the IBM i (formerly the Series i) platform. In his previous articles he's introduced the platform and shown what knowledge you'll need to get started. In this latest post, he talks about some implementation ideas to keep in mind.

No one ever talks about how to create quality pages, what they should look like, how should they be structured, and so on. The reason for that is simple: we don't need no stinkin' instructions for that! Everyone knows how to design good screens (opps, pages). That's the easy part, right? Well, maybe not. [...] Of course, business pages are different from the pages that we may develop for a blog or website.

He goes on to talk about things like the number of "switches" (shifts in context between just using the keyboard vs using the mouse as well) and how you should "mirror the task" not the database that lives behind it. He also makes a recommendation about keeping the important things "above the fold". He notes that, unlike some of the usual sites out on the web, business applications are a bit more about usefulness and less about style.

In this new post to his site Vinícius Krolow shares some tips he thinks will help to make your PHP code more readable in the long run.

What about code readability, from my point of view is one of the most important thing in the code. Who writes code that is easy to read, writes good code. Probably reading code is where you spent most part of your time, and not only your code, probably code of your team mates, or maybe code from the open source community, so write code that is simple and is easy to understand it’s really important.

His tips (seven of them) are:

• Comment before write your code (DocBlock)
• Return frequently, Return early
• Break, Continue
• Code Standard / Name conventions
• Throw Exception
• Comment often, but not write stupid comments
• Methods can be always smaller than they are

It's a little difficult to read as the English isn't the speaker's native tongue, but it gets the point across. He also recommends reading this if you'd like more information about writing better OOP code that's easier to read.

Smashing Magazine has a great new article that's a must read for anyone looking to start up an open source project with some guidelines to follow as you get things set up.

At Velocity 2011, Nicole Sullivan and I introduced CSS Lint, the first code-quality tool for CSS. We had spent the previous two weeks coding like crazy, trying to create an application that was both useful for end users and easy to modify. Neither of us had any experience launching an open-source project like this, and we learned a lot through the process.

The article reads like a checklist of things you'll need to consider as you create your project - things like:

• Determining what your goals are
• Choosing a license
• Code structure and organization
• Documentation

There's also a few other suggestions that may or may not be useful depending on the project like "use a mailing list" or "use version numbers" but they're all good ideas. Even if you're already working with an open source project, this is a good overview and could give you food for thought on things you might have overlooked.

Lars Tesmer and his coworkers have been working on improving their development skills lately, specifically related to unit testing. In his latest post he shares some of what they've discovered along the way.

The plan was to try and write as many tests as we could for the Constraint classes PHPUnit uses to implement its assertions. [...] Well, our plan didn’t work out that way, we didn’t really succeed in writing a considerable amount of unit tests. However, it still was a valuable experience, as it turned out the unit tests of the Constraints are a good example of how not to unit test.

He includes three of the major points they came across in their practice development:

• Don’t use one single test case class to test several different classes
• Name your tests well
• Avoid to test more than one behaviour in one single test

For each, there's a summary answering the "why" question behind them including an example test (testConstraintIsType) that shows a bad, multiple assertion practice that should be avoided if possible.

For those out there wanting to make the move from PHP4 up to PHP5, Robert Ames has posted a few things to watch out for.

He breaks it down into to categories - the good and the bad. Some of the items on either list include:

• static methods (good)
• E_STRICT (bad)
• random passing by reference gone (good)
• replacing is_a() with instanceof (bad)

He also offers some of his personal suggestions for guidelines for future language updates.

For those out there wanting to make the move from PHP4 up to PHP5, Robert Ames has posted a few things to watch out for.

He breaks it down into to categories - the good and the bad. Some of the items on either list include:

• static methods (good)
• E_STRICT (bad)
• random passing by reference gone (good)
• replacing is_a() with instanceof (bad)

He also offers some of his personal suggestions for guidelines for future language updates.