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

The Mexican Standoff of PHP Frameworks
Jan 26, 2018 @ 12:24:09

On the ZFort.com blog there's a new post that talks about the "Mexican standoff" between PHP frameworks, covering some of the background behind some of the more popular ones and some of the main differences between them.

PHP is one of the most widely known and potent programming languages used today. However, despite the popularity of PHP, there are many businesses using PHP without making use of a quality PHP framework. This approach slows production time and increases costs. A PHP framework is advantageous because it provides you with modules and codebase to help structure and accelerate the web development process.

[...] For CEOs, CTOs, product owners and those in the tech industry, choosing the right PHP framework can help cut production time and costs. However, every PHP framework is unique. [...] Given the wealth of PHP frameworks available, it is important to conduct solid research in order to find the platform that’s right for you. [We'll] take a look at three of the most popular PHP frameworks (Symfony, Laravel and Yii) and break down which is the best, and why.

The article then goes on to cover three of the more widely used frameworks:

  • Symfony
  • Laravel
  • Yii Framework

For each the author covers some of the origins of the framework and some of the things that it's best at. Following these there's a section that briefly compares them and how approachable they are for developers new to frameworks. While they all have their strengths the author recommends Symfony as the framework with "the most long term potential" over the others.

tagged: framework comparison symfony laravel yii opinion

Link: https://www.zfort.com/blog/php-frameworks-standoff/

Jeff Madsen:
Your Company is Screwing Itself by Not Supporting Open Source Software
Jan 24, 2018 @ 09:30:21

Jeff Madsen has a post on his site where he shares his opinions about Open Source software and companies giving back to the projects they use and love. His basic idea is that they're "screwing themselves" if they're not contributing for a few different reasons.

This will be a short piece, so I’m not going to go down [the] rabbit hole right now [of project timing], but tell me one thing: When a construction company is handed a one-of-a-kind blueprint of a new house, do they respond, “Well, golly gee! This has never been built before? - ?I have no idea how long it would take”?

[...] If you are good at creating software estimates, you probably already know the Joel Spolsky guide to making (somewhat) accurate ones. Break it down into small bits that you can understand. [...] Now…here’s where we start honing in on my point. I may have lied to you a little bit above?—?that construction team may not know how long it takes to build a stud wall with wiring [...] because they use bloody pre-fab for everything these days!

Relating this back to Open Source, he links these "pre-fab" items back to Composer packages, Node modules, etc and how they can help make things more efficient (more than writing it all yourself). A lot of companies see OSS as a way to get free software they don't have to create or maintain. Unfortunately they don't take into account the work behind them and how nothing ever fits 100% so you end up making modifications. If you contributed those modifications back to the project that could mean never having to do it again in your own work.

He ends with a few recommendations for companies looking to contribute these fixes and suggestions back to projects including providing monetary support or looking at paid versions over free ones.

tagged: opensource software contribute back company opinion

Link: https://medium.com/@codebyjeff/your-company-is-screwing-itself-by-not-supporting-open-source-software-c0e58ff04629

Stitcher.io Blog:
Where a curly bracket belongs
Jan 19, 2018 @ 10:38:45

On the Stitcher.io blog they've shared a post that makes some suggestions about where a curly brace belongs and how that might differ from situation to situation.

Dedicating a whole blogpost to curly brackets might seem like overkill but I believe it's worth thinking about them. Not just because of one curly bracket, but because there's a bigger message in all this. Thinking about how we read and write code not only improves the quality of that code, it also increases our own and others ease of mind when working with it. It can improve the fluency of your work and free your mind to think about real important stuff.

[...] I wrote about visual code improvements a while back in a previous blogpost about cognitive load. Today I want to focus on that one little, yet very important character in our codebase: the curly bracket. More specifically, we're only going to look at the opening curly bracket, because there's little to no discussion about the closing one.

The post goes on to show several different example situations and where they think the "most correct" placement for the curly brace is. They alos talk about the difference between their use on constructors versus control structures. The main recommendation, however, is to keep things consistent across the codebase.

tagged: curly bracket constructor opinion location consistency

Link: https://www.stitcher.io/blog/where-a-curly-bracket-belongs

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/