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

Laravel News:
Habits of Highly Productive Tech Teams
Jan 27, 2017 @ 10:18:22

On the Laravel News site there's an article posted from Sharon Steed covering some habits of highly productive tech teams including topics like trust, meetings and understanding roles.

There’s always a lot of talk about “culture” on tech teams. And that makes sense: managers generally hire people that will fit in well with the group they’ve assembled because they know there’s more to work than just doing the job. Being able to get along with your coworkers, being reliable, and looking the part are also important. A big part of building a solid company culture is about creating an environment which helps your employees be productive. Unfortunately, a lot of what we do in tech has the opposite effect.

She talks about the role of perks in an effective workforce and how, despite some seeming very nice on the outside, can cause burnout as it encourages longer work hours than normal. From there she moves into some suggestions about "meeting culture" and some of the major drawbacks to meetings (including how they can distract from "real, paying work"). There's a nice flow chart included in the post too that can help you determine if a meeting is really necessary or not. From there she goes on to talk about the other two topics mentioned above - employees knowing and understanding their roles and fostering trust between them through things like delegation and effective listening.

tagged: highly productive teams technology opinion trust meetings roles

Link: https://laravel-news.com/habits-of-highly-productive-tech-teams

Adam Wathan:
Methods Are Affordances, Not Abilities
Jan 25, 2017 @ 09:58:45

Adam Wathan has a new post on his site about a different way of thinking he's coming around to about methods, affordances and abilities.

In one of my current projects, I needed to be able to broadcast email announcements to all of the users in the system. If you've read about enough patterns and principles, there's a decent chance you saw [the line allowing an Announcement to perform the "broadcast" operation] and immediately thought to yourself: "What?! An announcement shouldn't be able to broadcast itself!"

I used to think that too, but over the last few years I've started to think differently.

He talks about "do-er" classes that normally would take in something like an announcement and perform the operation to broadcast it. He suggests that this comes from a misunderstanding about the point of methods: abilities versus things you could do with an object. He goes on to give some examples of double standards with DateTime handling, the complexity it could introduce and how, despite it sounding like an immediate action, the "broadcast" method could just be deferring to a background queue anyway.

tagged: methods affordance ability difference misunderstanding thinking opinion

Link: https://adamwathan.me/2017/01/24/methods-are-affordances-not-abilities/

Stefan Koopmanschap:
Best practices on bundles in Symfony
Dec 29, 2016 @ 10:53:39

Stefan Koopmanschap has a new post to his site sharing some best practices with bundles in Symfony including structure of both the bundle and the application it lives in.

On one of my recent commutes I started listening to the Sound of Symfony podcast. As I had just discovered that one, I decided to listen to their most recent episode, which is on best practices for bundles. I quite disagreed with what was being said in the podcast. I started voicing my disagreement on Twitter but quickly decided that 140 characters is not enough to really explain my disagreement. So here's a blogpost.

He starts by talking about some of the current "best practices" documentation (like this book) and the parts of it he disagrees with. He talks about the use of the AppBundle, the general structure of a Symfony project and the use of bundles to provide better structure to your own code. He covers the placement of you code (your "domain") and the integration of the idea of bounded contexts. He finishes the post with some of his own experience with various frameworks and both good and bad project structures - and how sometimes the default framework structure isn't really what's needed.

tagged: symfony bestpractice bundles structure application opinion soundofsymfony

Link: http://leftontheweb.com/blog/2016/12/29/best-practices-on-bundles-symfony/

Laravel News:
Just-In-Time Knowledge: How to learn what you need to know and forget the rest
Dec 23, 2016 @ 10:27:17

On the Laravel News site there's an interesting post about learning "just in time" so you can not only keep up with the latest knowledge but not have to worry about things you don't actually need to know.

Technology—including the web—moves insanely fast. It can be intimidating (often annoyingly so) to try to not only consume the content constantly served to us, but also retain it. After all, isn’t the point of sharing information to learn from it? This just-in-time knowledge can be an unfriendly reminder that, no matter how hard we try, we will have a difficult time keeping up with the newest trends and tech.

[...] Luckily in tech, most of us have to keep up to date on software and hardware to be successful at work. But what if we’re swimming in a project at work and don’t have time to look into the new technologies? What if it’s nearly impossible to bake new knowledge into our jobs?

The article talks about methods for "knowledge gathering" you can do in small bites during your day, making use of them to keep up with the latest trends and technology. It also talks about retention, how sleep and training play into it and the where researching topics more in-depth can help.

tagged: justintime knowledge learning research retention opinion

Link: https://laravel-news.com/just-in-time-knowledge

Amine Matmati:
Symfony: the Myth of the Bloated Framework
Dec 20, 2016 @ 12:25:50

Amine Matmati has written up a post with a few quick points refuting the "bloated framwork" myth as it relates to the Symfony framework.

At work, we’re trying to choose which PHP framework to use for our next project. As we’re breaking up our monolithic app into services, only micro frameworks were considered by the team. This choice was made to avoid the pain points we’ve encountered using our current full stack framework.

Not all full stack frameworks are created equal, however. Having worked with Symfony before, I proposed it as an option. As expected, I’ve had some pushback from my fellow coworkers. The main reason being that Symfony is bloated and overkill for our needs.

He then goes on to talk about how, despite many Symfony components being used individually by other projects, the overall framework still has the reputation for bloat. He goes through some of the main points usually mentioned by the opponents:

  • Doctrine is complex/bad/slow
  • Symfony is too verbose
  • Symfony uses too much configuration

He does agree with some of the points made but usually not in the general way they've been stated. For example, while he does agree that Symfony is verbose he also points out that this verbosity provides more control to the developer as to exactly how things hook together.

tagged: symfony myth bloated framework opinion doctrine configuration verbose

Link: http://matmati.net/symfony-myth-bloated-framework/

Paul Jones:
Package Development Standards: "pds/skeleton" Now Open For Review!
Dec 16, 2016 @ 10:54:14

Paul Jones has a post to his site with a proposal for a standard structure for PHP packages to help provide consistency across the PHP package ecosystem. His proposal - the Package Development Standards initiative - defines the structure of the repository instead of conventions to be used in the package itself (like naming or object structure).

The new pds/skeleton (and the related research) for public review. If you are a package author, you are invited to post your comments and criticisms of the publication as issues on the relevant Github repository.

The pds/skeleton publication describes a set of standard top-level PHP package directories and files. If you are an author of more than three packages on Packagist, chances are you already follow the standard! That’s because PDS initiative researches the PHP package ecosystem to recognize commonly adopted development practices.

He's putting it out there for public review for now until he can get some feedback from the community on the structure and recommendations made. He also recommends going a head and adding "pds/skeleton" to your "require-dev" section to indicate your compliance to the suggestions he's presented.

tagged: package structure repository standard definition opinion composer

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

Laravel News:
Building a culture of trust: Why sharing is good for you and your career
Dec 12, 2016 @ 11:20:17

On the Laravel News site there's a recent post by Sharon Steed talking about building a culture of trust and why sharing is good on both a personal and corporate level for your career (and not just in technology).

I speak about empathy on teams and why vulnerability is a great asset in your professional life. Sharing ideas falls right in line with my own ideology, but I also understand why people are so terrified to offer up opinions.

[...] I’m constantly amazed at how many people refuse to talk about projects they are working on for fear of others trying to swipe the idea. I’m even more so surprised at people who go out of their way to not share ideas with bosses or coworkers. Yes, there is absolutely a chance that someone else will take credit for that idea. The nature of working with other people, however, is that of collaboration.

She goes on to give some example situations, how sharing and trust between people plays and role and how many are realizing the value of being open. She gives examples of companies that are following this same idea on a corporate level like Buffer, Zappos and Landmark (an oil and gas software company). She ends the post with some practical advice on how you can help foster this culture of trust in your own company and career.

tagged: culture trust career opinion sharing personal corporate

Link: https://laravel-news.com/sharing

Matthew Turland:
On Remaining Employable
Dec 09, 2016 @ 10:49:40

Matthew Turland has an interesting new post to his site sharing some of his own thoughts on how you can stay employable as a developer with some great suggestions both on the technical and personal side.

Following my post on changing jobs, I communicated with a friend who’s in the market for a job. His circumstances inspired me to write a post for a slightly difference audience. So, here’s some advice on remaining employable as a developer.

His suggestions touch on topics like:

  • length of employment at one company (sometimes based on the type of company)
  • the balance between being a generalist and fitting only into a niche role
  • constant learning (and spending time "off the clock" doing professional development)
  • networking with other people

There's a lot of good content in the post so be sure to give it a read, especially if you're a developer that's been in the same role for a while...

tagged: opinion employable advice tips personal technical

Link: http://matthewturland.com/2016/12/07/on-remaining-employable/

Christian Mackerprang:
How terrible code gets written by perfectly sane people
Nov 30, 2016 @ 12:16:26

Christian Mackerprang has an interesting post to his site sharing some of his thoughts about why terrible code gets written by sane people - developers that know what they're doing but, for other reasons, write code that's a mess of anti-patterns and inconsistency.

What I discovered after some months working there [on a legacy Python project], was that the authors were actually an experienced group of senior developers with good technical skills. What could lead a team of competent developers to produce and actually deliver something like this? What I’ve come up is a list. These are some bad habits that even experienced teams can get into which will severely affect your end product, more than any static code checker or development methodology could rescue it from.

His list of reasons covers six of the reasons he sees for the "good people, bad code" situation happening:

  • Giving excessive importance to estimates
  • Giving no importance to project knowledge
  • Focusing on poor metrics such as “issues closed” or “commits per day”
  • Assuming that good process fixes bad people
  • Ignoring proven practices such as code reviews and unit testing
  • Hiring developers with no “people” skills

For each item in the list he briefly covers why it's a bad thing for your engineering group and references to other sources on good suggestions to fix the situation.

tagged: terrible code sane people opinion reasons

Link: http://chrismm.com/blog/how-terrible-code-gets-written-by-perfectly-sane-people/

SitePoint PHP Blog:
Pay the Price for Open Source
Nov 25, 2016 @ 15:18:18

The SitePoint PHP blog has a post from the godfather of the PHP community Cal Evans about paying the price for open source - giving back to Open Source projects that you use every day.

Back in the early days of Open Source – when Dinosaurs roamed the earth and Rasmus was a young man – there were two types of open source projects we talked about: those that didn’t cost any money, and those that gave you the freedom to redistribute and modify the code.

[...] Fast forward a few dozen years and here we are, Open Source is now an ecosystem, not a user group that you and five friends attend, or a magazine to which you subscribe. The problem is that most of us have stopped talking about the different types of open source, we just assume it is both.

He talks about how PHP is technically both kinds of free but also points out that open source will potentially die out (as it is now) without one major piece - users contributing back, giving their time and effort to keep it (and related projects) free. He talks about how you can give back, and not necessarily monetarily. He talks about one of his own experiences with giving back (to WordPress) when his work wasn't accepted, but he also points out that even though it may be rejected it doesn't mean you should stop.

What ever project you are working with, take the time to give back. Don’t let Open Source die in our generation.

Preserve this great concept; this ecosystem that we have helped build and that has allowed us to build so much. If you are a developer, find your favorite project and give back. If you run a company or a team of developers, give them time on your dime to give back to a project. Help keep the Open Source ecosystem thriving for the next generation of developers.

tagged: opensource pay price giveback contribute opinion

Link: https://www.sitepoint.com/pay-the-price-for-open-source/