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

DaedTech Blog:
Avoid these Things When Logging from Your Application
Dec 06, 2016 @ 11:53:48

On the DaedTech blog Erik Dietrich has written up a list of a few things he suggests avoiding when using logging functionality in your application. The suggestions range from the actual contents of the message out to some logging best practices.

It seems almost strange to talk about avoiding things while logging. After all, logging is your last line of defense or your salvation in many cases. [...] Well, it turns out that, while logging may be a highly inclusive activity in terms of what should be included, there are ways to create problems. You want to be liberal in terms of what you log, but judicious and wise in terms of how you log it. You don’t want to indulge in a feckless free-for-all when it comes to the calls you make to your application’s logger.

So what are these problems, and how to avoid them? Let’s take a look at some things that can come back to bite you.

He points out the following (common) bad practices he has seen during his time developing:

  • Forgetting Context
  • Cryptic Codes
  • Spamming the Log File
  • Unsafe Logging Calls
  • Mixing Application Logic with Logging

He ends the post with a suggestion of "sensible logging" - capturing as much meaningful information as possible while not overdoing it. Logs can be a powerful ally when hunting down an issue or trying to provide documentation of a security issue. Log wisely, log on purpose.

tagged: logging practices recommendation avoid list

Link: http://www.daedtech.com/avoid-things-logging-application/

Andreas Creten:
Does code need to be perfect?
Nov 11, 2016 @ 09:55:57

On his Medium.com blog Andreas Creten has written up a post that tries to answer the question "Does code need to be perfect?" As developers we have a drive to take pride in our work and want it to be the best code possible. However, that can lead to some bad practices...

In the past months I have asked myself a lot why we always strive to write perfect code. Picking up coding again for an internal project made me realise our team (and probably a large part of the rest of the software development world) spend a lot of time on writing perfectly formatted, ordered, patterned and tested code. But is this really necessary?

[...] The engineers want to write perfect code using the latest techniques, make sure that the code is well documented so they can fully understand how everything works and that it has tests so they can easily update things later. Product owners on the other hand just want things to be done, fast and cheap, so they can ship new features or convince new clients. How can you make these conflicting views work together?

He offers a few different suggestions for those developers wanting to craft the perfect codebase including coding for "now" not the future and the fact that "perfect code" just doesn't exist. He offers some suggestions for dealing with that "non-perfect code" you come across in your codebase, when starting from scratch makes sense and thinking about how "perfect" the code needs to be at the outset.

tagged: perfect code opinion development practices

Link: https://medium.com/we-are-madewithlove/does-code-need-to-be-perfect-a53f36ad7163#.jdqre42fu

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/

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

Slashdot.org:
Book Review - Modern PHP: New Features and Good Practices
Mar 24, 2015 @ 11:29:28

On Slashdot today Michael Ross as posted a book review of Josh Lockhart's recently released O'Reilly book "Modern PHP".

In recent years, JavaScript has enjoyed a dramatic renaissance as it has been transformed from a browser scripting tool primarily used for special effects and form validation on web pages, to a substantial client-side programming language. Similarly, on the server side, after years as the target of criticism, the PHP computer programming language is seeing a revival, partly due to the addition of new capabilities, such as namespaces, traits, generators, closures, and components, among other improvements. PHP enthusiasts and detractors alike can learn more about these changes from the book Modern PHP: New Features and Good Practices, authored by Josh Lockhart.

In the rest of the review Michael provides an overview of the topics covered in the book and how it's divided up. He then covers each of these three sections, commenting on the contents and making a few recommendations for those not immediately familiar with the topics. He does point out that he felt there was some critical information missing on some topics that "would allow one to begin immediately applying that technique or resource to one's own coding." Overall, though, he found the book a good resource and recommends it to those looking for a source to learn about new trends and tools in PHP.

tagged: book review modernphp joshlockhart features practices

Link: http://books.slashdot.org/story/15/03/22/1447230/modern-php-new-features-and-good-practices

Reddit.com:
Worst practices
Sep 04, 2013 @ 11:35:52

In this recent post to Reddit.com, people have been sharing some of the "worst practices" they've seen during their PHP development (or may even be guilty of).

For shits and giggles some colleagues and I are trying to write the crappiest PHP script we can think of, using as many bad practices as we can find. Alas, it's much harder then we thought, because we all have been trained to not do stupid stuff.

Things on the list so far include:

  • Multiple class definitions in a single file
  • Saving passwords unhashed and unencrypted in a database
  • Using a global variable inside a class to get a database connection
  • One letter variables
  • Pointlessly setting the signup method to being static
  • Using GET or POST vars directly from user input
  • Mixing HTML and PHP like there's no tomorrow.
  • make liberal use of extract() after running 'SELECT *'
  • Define a custom exception class for each class and only throw it from that class.
  • Make sure your DB connection is a singleton.
  • Throw ugly constants everywhere

What are some of the worst things you've seen? Share them here.

tagged: worst practices opinion examples list

Link: http://www.reddit.com/r/PHP/comments/1lpgqk/worst_practices

Matt Frost:
Agent of Change: Part 2 Presentation
Feb 05, 2013 @ 09:20:35

Following up on his previous post about being an "agent of change" in your organization (work, open source project, etc) Matt Frost has posted his second part of the series focusing on the presentation of your ideas.

In Part 2 we're going to talk about presentation of the pitch you put together for this change. It's important that your pitch be well researched and in some regards provable, as the Agent of Change the responsibility lies with you to prove the value of your idea. As we touched on in Part 1, a well thought out plan is going to go a long way in breaking down the barriers that make change difficult to take hold.

He makes a strong point that you need to identify the problem you're trying to solve (and what solution you're wanting to propose) clearly before trying to present it to a listening audience. He recommends quantifying your solution in terms everyone can understand like "hours of work" or cost. He recommends coming up with a short "elevator pitch" version to entice and the longer version to fill in the gaps.

You've got slides, documentation, statistics and loads of other good information that is going to benefit your development process, sales people in particular are looking for that jewel that helps set your organization apart; you've got that jewel!
tagged: agent change series practices development presentation

Link:

Matt Frost:
Agent of Change: Part 1 Preparation
Jan 08, 2013 @ 09:57:35

Matt Frost has posted the first part of a series he's writing up about being an "Agent of Change" in your development organization with recommendations on how you can make changes for the better happen. In this first article, he looks at working up "the pitch" for new technology and practices.

We all to make changes that make our jobs easier, so if your change isn't meeting a need or helping to ease a pain point, it's probably not the right change. [...] Find something that makes your job harder or less enjoyable, there's a pretty good chance that you aren't the only one.

He recommends doing plenty of research before making your recommendations, especially if it's a "we should be doing, but don't know how to" kind of improvement. He uses test-driven development in his examples, with part of his pitch being that it reduces the number of bugs that make it into production.

When plans are well thought-out and researched, the element of risk that others perceive tends to dwindle. [...] It's not about pointing out the faults of others in the organization or assigning blame, it's about learning and making positive changes from the lessons you've learned.
tagged: agent change preparation series practices development

Link:

Jonas Hovgaard's Blog:
How I stopped writing awesome code
Jun 14, 2012 @ 11:55:21

In this recent post to his blog Jonas Hovgaard talks about how he "stopped writing awesome code" by dropping a few things from his usual development practices - like unit tests and interfaces.

If writing awesome code is using all the best practices I can find, writing interfaces, unit tests and using top notch IoC containers to control my repositories and services all over my application's different layers - Then I'm not writing awesome code at all! I've been that guy, the one writing the awesome code, but I stopped. I'm not awesome any more. Instead, I'm productive, I'm so damn productive!

He talks about how not writing unit tests (which "customers don't care about") gave him extra time to work on other code and how not using things like interfaces, ORMs and how he follows DRY, but only so far.

My personal result of doing all of this is productivity and better products. I can't tell if I did it all wrong, and that's why I'm writing better code now, but I truly believe that I'm not alone. In fact I think that most of us regular web developers, tend to do the same "mistakes" as I did.

The post has turned into flame bait and has pulled in lots of comments discussing his decisions and other sympathetic souls that feel the same way he does about some of the complexity of the "best practices" promoted in development today.

tagged: opinion development practices bestpractice unittest interface orm dry

Link:

PC World:
How Etsy.com Grows in a Unique Fashion
Apr 03, 2012 @ 09:08:08

Over on the PC World site, there's a new article posted about Etsy and its development practices and how it "grows in a unique fashion" because of them.

The Etsy staffers are also completely serious about their work, and these two features they share in common with their customer base, who are tying to earn side money, if not pay the rent, by designing the hand bags, walking sticks and hand-made chocolates that have made Etsy famous in the artisan and sustainable business scene. [...] The quality model for Etsy is cutting edge, but not unique. New developers are expected to push code to production on day one. That's not commit code, but push it to production.

The article gets into some of the technology they use there at Etsy (including NodeJS, Nagios and, of course, PHP), the atmosphere they try to maintain, how they do their code deployment and how they conform to various regulations, security and privacy concerns.

tagged: etsy growth developer practices interview

Link: