Tomas Votruba has a post to his site sharing his top seven tips for writing exceptions that "everyone will love" and how they could be considered a more than just a programming tool.

Do you ever had that feeling, that you've seen that exception before and you know what it means and how to solve? What if that would be clear even for those who see it for the first time? It would save yours and their time.

Exceptions are not just error state. Exceptions are the new documentation.

He starts off by describing a situation just about any developer would be familiar with, the "circle" where an exception is thrown when something breaks and there's no additional information so you're back to where you started. Based on his work in the EasyCodingStandard he's come up with seven tips to help prevent this in your applications:

1. Make Exception Names for Humans
2. Use " around" Statements
3. What Exactly is Wrong?
4. What is The Wrong Value?
5. What File Exactly is Broken?
6. What Options do I have?
7. Link what You can't Fit 140 Chars

For each item on the list there's code snippets illustrating the suggestion and a brief description for more context.

In a new post to his site Matthias Noback takes a look at the concept of assertions and some libraries including some effective ways to use them in your code for validation of values.

When you're looking at a function (an actual function or a method), you can usually identify several blocks of code in there. There are pre-conditions, there's the function body, and there may be post-conditions. The pre-conditions are there to verify that the function can safely proceed to do its real job. Post-conditions may be there to verify that you're going to give something back to the caller that will make sense to them.

[...] Sometimes the programming language itself can help with these pre-conditions: for instance, the language may support strict typing, which prevents certain types of invalid input to be provided. Some languages offer more advanced ways of defining pre-conditions, like pattern matching.

Following a brief use case for assertions (at a high level) he gets more specific to PHP and mentions two assertions libraries that could be used to add these kinds of checks to your code (in addition to PHP's own assert function). He then answers the "why use assertions?" question and some basic rules around using them:

• don't use assertions to validate user input, use it to validate function arguments.
• don't use assertions to validate return values from other functions.
• don't use assertions as a replacement for exceptions.

For each of these, he provides a summary with a bit more background and code examples to help illustrate the point. He ends the post with some useful "rules of thumb" when using assertions and a reminder:

Assertions are sanity checks. When they would be left out, you should still have a correctly function application. They should never become user-facing errors.

Christian Maioli Mackeprang has a new post to his site sharing some of his recommendations of how you can deal with poor code in limited time when making changes (or adding new features) to an older codebase.

You’ve been given the task of implementing a new feature on an old codebase, but the code looks awful. How can you understand it as quickly as possible? Here are several shortcuts to help learn the important parts of new code without getting lost in the irrelevant details.

His list includes both technical and "people" related suggestions including:

• Ask for help
• Make it easy to reproduce bugs
• Prepare for automated testing
• Get on familiar ground before tackling critical code

For each item in the list he includes a summary of what's involved along with "dos" as well as "donts".

On the TechBeacon site there's a new tutorial posted sharing a list of nine ways to master awful code and make it more efficient, easier to maintain and clearer.

You've been given the task of implementing a new feature on an old codebase, but the code looks awful. How can you understand it as quickly as possible? Here are several shortcuts to help learn the important parts of new code without getting lost in the irrelevant details.

Their suggestions range from technical to non-technical and include:

• Ask for help
• Make it easy to reproduce bugs (add version control, build environments)
• Prepare for automated testing
• At first, work on a small task

For each item in the list there's an explanation and links (or screenshots) of other resources to help illustrate their point.

On the SenseDeep Security site Michael O'Brien has posted a web developer security checklist you can use as a starting place towards securing your application (and developing secure applications from the start).

Developing secure, robust web applications in the cloud is hard, very hard. If you think it is easy, you are either a higher form of life or you have a painful awakening ahead of you.

[...] After you review the checklist below, acknowledge that you are skipping many of these critical security issues. At the very minimum, be honest with your potential users and let them know that you don’t have a complete product yet and are offering a prototype without full security. This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application.

He breaks it down into different sections with items to check off for each:

• Database integration and data storage
• Development environments and security scanning
• Authentication
• Denial of Service protection
• Securing the Web Traffic
• APIs
• Validation (input and whitelisting)
• Cloud service and Infrastructure configurations
• General Operations and Testing

He ends with two points that are easy to forget when developing any application: determining what you're protecting against (threat modeling) and having a practiced security plan in place. Remember, checklists are a good place to start but by checking off each item it doesn't mean you're 100% secure.

In a recent post to his site Tomas Votruba shares some of his opinions about why he thinks that Doctrine is dying sharing three of the reasons he sees for this trend.

Do you use Doctrine ORM? If so, do you follow its evolution on Github? Symfony is evolving, Laravel is evolving, Nette is evolving, world is evolving... Doctrine not. Today I will show you 3 reasons why.

I've been thinking over 2 years about this post. I wasn't sure if it's only negative hype feeling or real thing. It's still the same so it's time to write about it.

He starts off by stating that Doctrine is "an awesome tool" but suggests that it is stuck in its legacy world and hasn't been able to evolve much past some of its original functionality. In his opinion this is because of the project's "system setup" not the code quality or maintainers. He then offers the Doctrine project three suggestions on what they could do to help change the course of the project. This includes becoming more competition to other options and consolidating the 20+ Doctrine repositories down to a much simpler structure.

The TutsPlus.com site has posted the latest tutorial in their "Building with the Twitter API" series showing how to, in a Yii2 application, automatically add friends to a Twitter account via the Twitter API. You've probably seen this in several services that offer suggestions of followers to add to your list.

Today I'll guide you through using the Yii2 Framework for PHP to access the Twitter API and automate adding friends to people's Twitter accounts. (If you'd like to learn more about Yii2, check out our parallel series Programming With Yii2.)

And, I've created a website, Twixxr.com, which will let you demonstrate the feature by adding prominent women on Twitter for your account to follow.

The tutorial starts with links to some of the other Twitter tutorials that have been posted in the past and how things have evolved to make it easier in a Yii2 application. He starts by helping you get the Twitter OAuth PHP Library installed and lists some of the goals of the end result. The code is included to authorize the user and handle the callback once they've approved the app in the normal OAuth flow. It then shows how to connect via the API using that user's information, load profiles for the suggested users and link them as a friend. The tutorial finishes with a look at performance and a bit of code used to handle the backend processing of the request instead of performing it in real time.

On the Symfony Finland site there's a new post with some suggestions on choosing a frontend for your Symfony-based applications according to your needs.

Most projects created with the Symfony framework nowadays also include quite a bit of logic done on the client side. There is a large number of options on the market and this can lead to trouble choosing between the options. The JavaScript scene is full of camps and cutting through the buzz is quite a bit of work. [...] Symfony remains neutral to what is running in the front end of the project. As with most things in web development, there is no single "right" answer to which front end frameworks to use.

They talk briefly about the history of the framework and what kinds of considerations should be made for both the front and backend technology. They also remind you that there's not a "one size fits all" frontend technology out there. They describe a few different kinds of situations (backend heavy, frontend heavy, etc) and make a few suggestions as to which way you might want to go and libraries to investigate.

The next time you're faced with starting work on a front end of a web site or web application built with Symfony, you can reflect on the experience you've got from the back end. There are usually many right answers and no absolute truths.

Peter Petermann has shared a few of his thoughts about right and wrong things to do when using Composer in your PHP-based applications. He offers suggestions based on some of the more wide-spread (but wrong, in his opinion) practices he's seen in several projects.

Last year I wrote a piece called “a few thoughts about composer and how people use it“. In that post I had a list of things which are problematic about how composer is used. That post got widely recognized, linked an visited, but in general those issues still exist.

However lately I’ve had even more people asking questions (either on related forums, irc or even irl) about problems that stem from issue number 2: people are using composer as an installer (and sometimes Number 3 because of Number 2). In that Post I already gave a quick opinion on how workflows with composer should look like, In this post I’ll try to give a few more pointers on how to use composer without creating a mess.

He then breaks up the remainder of the post into various practices he's seen and calling out developers for doing including:

• starting a project vs installing
• globally installed composer packages
• tagging and building

With each of his points he makes suggestions about what's wrong about the practice as well as some suggestions about how things could be done better.

On the FreeCodeCamp Medium blog Bill Sourer shares some tips you can use to find time to become a better developer in the fast-based, sometimes crazy world of software development.

There’s no time for anything. At least that’s how it feels doesn’t it? No time to learn all the things you think you need to learn to stay ahead of the curve. No time to go back and refactor that ugly piece of code. It works (sort of) and there’s a deadline approaching. No time to write unit tests for everything. No time to write documentation or comments for the next guy who gets stuck maintaining what you wrote. No time to think. No time to breathe. No time!

Well… if you take the time to read this article, I promise you’ll find yourself with more time for what’s important.

He breaks it down into five main tips (here's a tl;dr for those in a rush):

• You don’t need to learn every new thing in order to stay relevant.
• Writing good code takes less time than writing bad code, BUT it doesn’t feel that way.
• Working 24/7 does NOT make you a hero. Managing expectations does.
• Not all time spent “improving” code has the same ROI.
• Scheduled down time makes you more productive.

Each item on the list has a paragraph or three explaining it in a bit more detail. There's also some other interesting ideas and thoughts in the comments of the post from other readers.