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

Patrick Louys:
Become a better developer in 2018
Jan 11, 2018 @ 11:57:25

In a post to his site just before the new year Patrick Louys shared some of his thoughts about how to become a better developer in 2018 as a sort of programming-related New Year's resolution.

Do you have any programming related New Year’s resolutions? A lot of people don’t follow through with their resolutions. But don’t let that discourage you. When you make resolutions, you are much more likely to achieve your goals (10x more).

I wrote this post to show you how you can achieve your programming New Year’s resolutions. Every year I have been writing down my goals, for over a decade. It helped me grow a lot in my personal and professional life. It’s not just about setting goals and achieving them. You have to pick the right goals.

He begins by making a few recommendations when it comes to setting goals and how to set yourself up in your day to day work to achieve them. He then relates this back to programming goals, suggestion you focus more on patterns and practices rather than specific technologies (unless they're relevant to your work). He also recommends several books to read during 2018 to either learn new concepts if you're just starting out or wanting to refine your own skills.

tagged: better developer recommendation opinion newyear resolution

Link: https://patricklouys.com/2017/12/27/become-a-better-developer-in-2018/

Stefan Koopmanschap:
A rant about best practices
Jan 10, 2018 @ 13:19:02

Stefan Koopmanschap has shared a rant about best practices in a new post to his site. In it he shares some of his thoughts as presented in a lightning talk at the PHPAmersfoort meetup.

I have yet to talk to a developer that has told me that they were purposefully writing bad software. I think this is something that is part of being a developer, that you write software that is as good as you can possibly make it within the constraints that you have.

In our effort to write the Best Software Ever (TM) we read up on all the programming best practices: design patterns, refactoring and rewriting code, new concepts such as Domain-Driven Design and CQRS, all the latest frameworks and of course we test our code until we have a decent code coverage and we sit together with our teammates to do pair programming. And that's great. It is. But it isn't.

In the post he touches on a few main topics with his ideas for each:

  • Test Coverage
  • Domain-driven design
  • Frameworks
  • Event sourcing + CQRS
  • Pair programming
  • Refactoring + Rewriting

He ends the post with a suggestion to "consider all the best practices" when writing your code and developing applications. It's not just about applying them because they're defined as "best practices", it's about determining which of these practices make sense for your situation.

tagged: bestpractice rant opinion testing domaindrivendesign frameworks cqrs pairprogramming refactoring

Link: https://leftontheweb.com/blog/2018/01/10/A-Rant-About-Best-Practices/

Brandon Savage:
What version of PHP should my package support?
Jan 10, 2018 @ 10:09:46

In a post to his site Brandon Savage shares some of his thoughts about PHP package development and suggests how to figure out what versions of the PHP language it should support.

Everybody likes “the new hotness.” [...] Perhaps, then, it shouldn’t be so surprising that people get tremendously excited when a new version of PHP comes out. People look forward to the new features, whether they be the trailing commas in list() syntax or counting of non-countable objects.

[...] A new version of PHP can pose challenges to open source package maintainers. There are questions, like what is the minimum version we will support and how soon can we take advantage of the new features we’ve been waiting on? I want to offer up some thoughts, both as a package maintainer and a user of many open source packages.

He goes on to suggest that package authors should support down to the last currently supported version of the language (v5.6 at the time of this post). This allows users of the package that may be restricted and don't have the "new hotness" to keep using the package. He points out that this doesn't mean that you shouldn't use new features, just that older versions should be supported along with the newer ones for those depending on the package. He makes three suggestions as to how he thinks package maintainers should approach the issue:

  • maintainers should feel comfortable in bumping up the requirement to the latest (in a major release)
  • maintainers should also ensure that the support is still there for older versions that can't use the newer features
  • maintainers should bump up this minimum version when it falls out of active support
Supporting old versions of a language isn’t fun and isn’t glamorous. But it’s important. It’s important because there’a segment of the population who can’t upgrade yet. It’s important to make components accessible to a larger, broader audience who is struggling to find best practices and use modern packages. And it’s important for those users who are tied to a legacy version, and are struggling to get upgraded. But it’s the right thing to do for the community.
tagged: package version language support opinion maintainer old new

Link: https://www.brandonsavage.net/version-php-package-support/

Matthieu Cneude:
PHP type hinting: what you shouldn't do
Jan 04, 2018 @ 12:12:06

Matthieu Cneude has written up a post for his site that shares some of his thoughts around what you shouldn't do with type hints in your code.

When PHP 7 came up with strong types, I saw the light. I had the hope not to see anymore bugs and inconsistencies due to weak typing in PHP. I remember reading some code and having no idea what could be the type of the variables I had in front of me.

[...] Strict types are big help as well as return type hint. You know what is the data you're manipulating. You don't have to guess anymore. However, PHP 7 wasn't the end of my typing struggle. You can still add a lot of ambiguity even if apparently PHP 7 tried to fix the problem. You still need to follow a couple of rules to keep your code consistently typed.

He then goes through some examples of weird results with some return type hints and unexpected results. He then moves on to strict type mode and how it can help resolve some of the oddities he discovered with just return type hints. The article spends the remainder of the time talking about the nullable type hint and some of the other "fun" surprises that can come from its use too.

tagged: typehint opinion oddity returntypehint strict type tutorial

Link: http://web-techno.net/typing-with-php-7-what-you-shouldnt-do/

Geoff Wozniak:
What ORMs have taught me: just learn SQL
Dec 20, 2017 @ 13:51:49

Geoff Wozniak has written up a post on the "Curried lambda" site sharing his opinion on ORMs (object relational mappers) for working with databases and how, after using them in his own development work, that they're a good side benefit but shouldn't replace knowing SQL.

I've come to the conclusion that, for me, ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program, but they should not replace it.

[...] Neward, in his well known essay, lays out many cogent reasons why ORMs turn into quagmires. In my experience, I've had to deal directly with a fair number of them: entity identity issues, dual-schema problem, data retrieval mechanism concern, and the partial-object problem. I want to talk briefly about my experiences with these issues and add one of my own.

He breaks the rest of the article up into several sections, for each sharing some of his own experiences with the feature and how it could be resolved using other query methods:

  • Partial objects, attribute creep, and foreign keys
  • Data retrieval
  • Dual schema dangers
  • Identities
  • Transactions

He ends the post with a look forward, thinking about where he'll end up, mentioning stored procedures, queries as APIs and how "easy" isn't always best when it comes to ORMs.

tagged: orm mapper database layer sql opinion issues experience

Link: http://woz.posthaven.com/what-orms-have-taught-me-just-learn-sql

Romans Malinovskis:
Pragmatic approach to reinventing ORM
Dec 19, 2017 @ 13:19:57

Romans Malinovskis has a post on his Medium.com site sharing what he calls a "pragmatic approach to reinventing ORM" with his thoughts about a different approach to this commonly used database interface.

It’s been over a year, since I posted my first highly debated post on Reddit: Reinventing the faulty ORM concept. Gathered information helped me design and implement an alternative pattern to ORM with many important advantages and that has reinforced my belief that ORM is faulty.

He's broken the article up into a few sections with details and thoughts for each along the way:

  • Why ORM is important?
  • Why ORM is broken?
  • How Agile Data differ in approach?
  • How Agile Data qualify production/enterprise use?
  • Notes on architectural decisions in Agile Data (OOP vs Decoupling)

That final section focuses mostly on the decoupling aspect and the Agile Data library (a Data Mapper) that can be used and solves some of the common ORM problems he mentioned in the earlier sections.

tagged: orm database interface datamapper agiledata broken opinion package

Link: https://medium.com/@romaninsh/pragmatic-approach-to-reinventing-orm-d9e1bdc336e3

Phil Sturgeon:
A Response to REST is the new SOAP
Dec 19, 2017 @ 11:49:05

For those dealing with APIs on a daily basis (or even the casual API-er) you'll find this post from Phil Sturgeon interesting. In it he takes on the opinion that's shared in this article from Pakal De Bonchamp that "REST is the new SOAP".

Enough people have asked me about the article REST is the new SOAP that I felt it justifies a write up. [...] The entire article is full of common misunderstandings about REST and HTTP. Despite dedicating my career to trying to educate people through these confusions, they continue to be rife. Clearly I am not being loud enough, writing effectively enough, or doing a good enough job. That is the frustration you might hear in my writing, but nothing is aimed at the author.

In his post Phil goes through the original article, pulling out quotes and responding to them one at a time. He shares opinions on HTTP verb operations, REST architecture, HTTP response code usage and the use of caching and statelessness in the API functionality.

tagged: rest opinion response soap http response architecture verb

Link: https://philsturgeon.uk/api/2017/12/18/rest-confusion-explained/

Jason McCreary:
The Debugging Golden Rule
Dec 14, 2017 @ 11:41:42

Jason McCreary has a post on the Dev.to site sharing what he calls the "debugging golden rule" to keep in mind when stepping through and trying to debug your code for issues.

Developers, especially new developers, often forget this when debugging. We jump into the debugger. We add tracing statements. We review the commit log.

Such actions can be misguided. Before debugging the code we must follow a moral code. Debugging needs a Golden Rule. A rule to remind developers of a few important facts of debugging.

Boiled down to its basics the "golden rule" here is that, most of the time, it's not the tools that are the issue - it's you and your code. He shares the common thoughts we've all had when debugging ("it's the upgrade, not my code") but points out that, regardless of where the issue is, it still needs to be fixed. Even if it is something in the tool, some odd bug or weird functionality that only kicks in once in a blue moon, you still have to ultimately make it work.

tagged: debugging goldendrule code tools opinion

Link: https://dev.to/gonedark/the-debugging-golden-rule-7cb

24 Days in December:
Giving back to PHP
Dec 12, 2017 @ 10:29:43

On the "24 Days in December" advent calendar there's an article posted from Kalle Sommer Nielsen that talks about some ways that you can give back to PHP including documentation updates, contributing to the core code and just helping out the community in general.

PHP has a tremendous community behind it, that community consists of you and me, and millions of others that help promote PHP by continuing to develop awesome applications that power some of the biggest websites in the world, but within this community exists a relatively small community that actively develops PHP, such as making it run on your favorite platform or making your favorite extensions compile and work or even keeps the documentation up-to-date. Today I want to dwell into that community, and perhaps giving you flavor enough to contribute back to PHP with code.

The article suggests several places you can give back including:

  • updating and adding changes to the PHP manual documentation
  • participating in the various project mailing lists
  • reviewing pull requests on the project's GitHub repository
  • writing tests for the untested parts of the language

Kalle wraps up the article talking about his own experience with the language over the years and how it ended up that he was the one to remove register_globals from the language one day.

tagged: give back contribute language opinion 24daysindecember

Link: https://24daysindecember.net/2017/12/11/giving-back-to-php/

Toptal.com:
Tips to Attract, Manage, and Retain Software Developers
Nov 30, 2017 @ 10:57:01

On the Toptal.com site they've posted an article from Fernando Martinez with some suggestions about how to attract and retain software developers. The ideas cover the full range - all the way from the job posting/interview process out to how to keep them with the company and help them thrive in their role.

Management is all about people. Whether managers or employees, both are thinking about how to achieve their personal and professional goals. The combination of these goals and the personal traits of the people involved give shape to relationships that, in time, can be positive, productive, and fulfilling, or sometimes just plain stressful, demanding, and conflict-prone.

[...] This is especially true in managing software developers, because of their job’s technical complexity and creative nature, compressed into often narrow timelines for producing results. [...] In this article, we will focus on the main management aspects, rather than on the technical ones, that we think should be considered by anyone who wants to be successful in managing to retain software developers.

He starts with a look at how to attract and hire the right people for the roles you're trying to fill with suggestions about the interview process and the job offer. Next he gets into recommendations about managing the team itself and the importance of training, organization and communication. The article then goes on to cover other topics like conflict management, keeping up motivation and assigning objectives/follow up.

tagged: attract manage retain software developer opinion recommendation

Link: https://www.toptal.com/software/attract-retain-software-developers