Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Symfony Finland:
Choosing a front end architecture for Symfony framework projects
Aug 01, 2016 @ 11:21:42

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.
tagged: frontend architecture symfony application suggestion opinion project

Link: https://www.symfony.fi/entry/choosing-a-front-end-architecture-for-symfony-framework-projects

Peter Petermann:
Composer – What You Should Know
Jul 26, 2016 @ 12:56:21

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.

tagged: composer opinion bad practices suggestion correct

Link: https://devedge.wordpress.com/2016/07/23/composer-what-you-should-know/

FreeCodeCamp.com:
Bill Sourer - Finding Time to Become a Better Developer
Jun 30, 2016 @ 10:35:48

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.

tagged: better developer time management suggestion tips top5

Link: https://medium.freecodecamp.com/finding-time-to-become-a-better-developer-eebc154881b2#.6ojvwlad0

QaFoo.com:
Never Use null
May 03, 2016 @ 13:07:32

On the QaFoo.com blog they've made a recommendation in their latest post - they suggest that you never use null.

When doing code reviews together with our customers we see a pattern regularly which I consider problematic in multiple regards – the usage of null as a valid property or return value. We can do better than this.

Let's go into common use cases first and then discuss how we can improve the code to make it more resilient against errors and make it simpler to use. Most issues highlighted are especially problematic when others are using your source code. As long as you are the only user (which hopefully is not the case) those patterns might be fine.

They talk about some of the most common uses they see for using null in PHP applications including setters for class properties (injection). They point out that in PHP 7 a missing value on a property would result in a Fatal error and make the functionality harder to test overall. They suggest that all required dependencies be injected on object construction instead, making it easier to know the current state of the object on testing. They also talk some about using null as a return value, how it could make debugging difficult and a solution that could make more sense - throwing an exception instead.

tagged: never use null return value injection setter solution suggestion debugging

Link: https://qafoo.com/blog/083_never_use_null.html

Ted Blackman:
Lug-Nut Driven Development (LuDDite)
Mar 21, 2016 @ 11:53:27

In his post on his Medium.com site Ted Blackman looks at something he calls "Lug-nut driven development" (or, shortened LuDDite). He breaks it down into a few different suggestions including "build the whole thing badly" out to "automate stop and start".

These are practices that I’ve applauded myself for doing at the beginning of some projects, and kicked myself for not doing early enough in other projects.

The full list suggests things like:

  • Building a system that goes through the whole flow first (not perfect) then come back and refine
  • Testing as you go instead of coming back at the end and retrofitting them
  • Log everything you can then cut back and refine
  • Plan out the error handling before hand to help make it consistent
  • Be able to "stop" and "start" the system easily

While not all of these are specific to web applications there's some definite helpful advice in here, especially to those starting out on new projects.

tagged: lignut development luddite software suggestion practices

Link: https://medium.com/@belisarius222/how-to-start-a-software-project-ad51373c1510#.nfx206q5v

Paul Jones:
Command Bus and Action-Domain-Responder
Mar 10, 2016 @ 10:53:47

In this post to his site Paul Jones looks at the combination of the Action-Domain-Responder pattern and the Command Bus pattern in application development. In the post he answer the question about how they fit together.

Over the past few weeks, different people have asked me where a Command Bus goes in an Action-Domain-Responder system. While I’m not a DDD expert, after brushing up on the subject a little, my answer is: "In the Domain."

He starts by reviewing the three pieces of the ADR pattern with brief descriptions of each. The then covers the Command Bus pattern, linking to several other resources with more details about the pattern itself and a quick summary of their main points. He talks about how the overall structure is a part of the Command Query Responsibility Segregation pattern and suggests that, since the Command Bus pattern is a "fire and forget" kind of thing it belongs in the Domain of ADR. He gives a brief code example and answers other questions about validation and error handling as a part of this suggested flow.

tagged: action domain responder adr commandbus architecture suggestion

Link: http://paul-m-jones.com/archives/6268

Matt Stauffer:
How to Apply for a Web Developer Job at Tighten (and How Not To)
Oct 01, 2015 @ 09:39:03

While the advice that Matt Stauffer gives in this new post to his site is more targeted towards people applying at his company, it's full of great tips for just about any job seeker looking to land a role in web development.

I just finished reading over 200 applications for our latest job posting, a Web Developer job at Tighten Co.. We still hire infrequently enough and are small enough that the two founders (Dan and me) and our operations manager (Dave) read every single application, which is hours upon hours for work before we even get to our initial phone screen.

Some applicants, and some tendencies among applicants, have stood out as best practices, but many more things have stood out as consistent turnoffs. So, I figured I'd share some with you here.

He includes helpful hints on topics like:

  • actually reading the job description
  • writing custom cover letters
  • updating your site and resume to the latest information
  • provide up to date code samples
  • check spelling and grammar

He offers one other piece of advice that I think a lot of job seekers don't bother with: set yourself apart somehow. This may mean extra work on the application but it can yield very positive results. He ends the post with some extra tips he received as feedback on Twitter, asking hiring managers what they really want to hear from applicants.

tagged: webdeveloper job application tips useful suggestion hiringmanager

Link: https://mattstauffer.co/blog/how-to-apply-for-a-web-developer-job-at-tighten-and-how-not-to

Marc Aube:
Choosing your project's dependencies
Jun 02, 2015 @ 11:01:59

Marc Aube has shared some thoughts about picking your project's dependencies and considerations to think about when building your applications.

If you work on any non-trivial project, chances are you'll install one or many external dependencies at some point. [...] However, you shouldn't bring any library in your codebase. While Packagist has, at the time of writing, around 60000 packages you could use in your project, most of them are not production quality. Here's a list of things to look for when choosing a generic library for a mission-critical project, in no particular order.

Among the things he suggests, there's tips like:

  • Ensure it has a stable version
  • That it's extensible
  • It's active and maintained
  • The license permits the intended use
  • It has quality documentation

For each he offers a brief paragraph or two explaining the point and examples where appropriate of projects matching the topic.

tagged: dependencies project opinion list suggestion choice

Link: http://marcaube.ca/2015/06/choosing-dependencies/

Lorna Mitchell:
Code Reviews: Before You Even Run The Code
Jun 02, 2015 @ 09:50:01

Lorna Mitchell has posted a list of helpful tips to perform good code reviews on submissions before even trying to run the code for correctness.

I do a lot of code reviewing, both in my day job as principal developer and also as an open source maintainer. Sometimes it seems like I read more code than I write! Is that a problem? I'm tempted to say that it isn't. To be a good writer, you must be well-read; I believe that to be a good developer, you need to be code-omnivorous and read as much of other people's code as possible. Code reviews are like little chapters of someone else's code to dip into.

She offers several tips you can follow to make the reviews you do more effective including:

  • Ensuring you understand the change
  • Are the changes where you'd expect?
  • Does the commit history make sense
  • Evaluate the diff to ensure the changes themselves are valid

She only then recommends trying out the code. Following the suggestions above can help ferret out issues that may be hidden by just running the code and not fully looking into the changes.

tagged: code review suggestion list opinion before execution

Link: http://www.lornajane.net/posts/2015/code-reviews-before-you-even-run-the-code

SitePoint PHP Blog:
Youtube Videos in PHP: Categories, Search and Suggestions
May 20, 2015 @ 11:47:14

The SitePoint PHP blog continues their series showing how to integrate content from the YouTube API into your application with this new tutorial. It covers the use of categories, searching and suggestions.

In the first part, we introduced the Youtube API and built a small demo to list the most popular videos on Youtube. In this part, we will extend our application to have search functionality, and we’ll also list the available categories on Youtube to let the user narrow down their area of interest.

He starts with with the updates you'll need to make to the routes and controllers for the "categories" functionality and the API call needed to popular the content. He updates the "videos" page to show the category information and integrate the category into the pagination. Next up is the search, allowing the users to find videos based on a search string. The search route/controller/view functionality is added as well. He ends the post talking about a way to extend the demo and advice to keep an eye on quotas and implementing cache.

tagged: tutorial series part2 youtube api categories search suggestion

Link: http://www.sitepoint.com/youtube-videos-php-categories-search-suggestions/