Terry Chay has posted the answer to an interesting question about the PHP language that asks what is something very few know about PHP. The original answer was shared on Quora but he's copied it here for more visibility.

Question: What’s something very few people know about PHP? Answer: It is mind-bogglingly popular for web development. That popularity hasn’t diminished even though conventional wisdom says otherwise…

Over a decade ago, I said about 40% of the top 100 websites use PHP. [...] Overall, almost 80% of the internet is powered by PHP, and that has held steady for years! Newer web languages such as Ruby or NodeJS have only grown at the expense of other languages such as ASP, Java, or Perl.

He also shares some about the role of WordPress in these numbers (a big chunk at 30%) and a guess at how many PHP developers there are in the world right now.

On the Web-Techno.net site there's a new tutorial posted that talks about the DRY principle in development (Don't Repeat Yourself) and why you might be misunderstanding the intent.

I know what you are thinking: "Again a boring article on DRY? Don't we have enough already?". You might be right. However I see too many developers (junior or senior) applying DRY like they are doing some witch hunting. Totally randomly or everywhere they can. So apparently we never have enough DRY principle articles on Internet.

A little reminder for those in the back who don't follow: the DRY principle means "Don't Repeat Yourself" and was first introduced in the The Pragmatic Programmer. The principle itself was known and applied before this book came to life. However the Pragmatic Programmer defined it precisely and put a name on it.

He starts by defining the original intent of the principle: not repeating knowledge (not necessarily repeating code). He gives an example of a e-commerce site and the logic around "shipments". If there's logic around these shipments happening in multiple places in the application, that can lead to maintenance issues down the line. He suggests creating a single instance of the knowledge about shipment handling rather than just reducing code duplication. He gives an example of a product instance and code duplication happening in some of the data validation. After showing a possible solution for this particular issue he gets into some issues that come from over-DRYing your code including useless abstractions and premature optimization.

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.

On the Dutch Web Alliance site today Stefan Koopmanschap makes a recommendation about something that can help make you a better developer and grow in your knowledge: continuous learning.

Education. In a fast-changing environment such as the web industry, education is the single most important thing to survive. [...] We need to stay up-to-date on those subjects to ensure we keep doing the right things in the right ways. It is impossible to keep your knowledge on everything up-to-date and still have enough time to work, so we need to make choices on which topics to focus on and how to learn. In this article I’ll go into some strategies and some ways to keep the knowledge of you and your team current.

He covers lots of good topics, including a brief summary of each point as he goes (including deciding if you want to be a generalist or specialist). He goes through several places to gain this kind of knowledge including:

• Knowledge sessions
• Trainings
• Code kata
• Code reviews
• Mentoring

...and these are just some of the places. He also points out the value of learning something on your own every day, trying out something outside of your usual solutions and remembering that "no two challenges are the same".

In this new post to the SitePoint PHP blog George Fekete shares some thoughts about what it means to be a "full stack developer" and what kinds of technology and skills are involved.

The barrier of entering the web development industry as a web developer is still low, but it’s getting increasingly complex. The dynamic nature of the whole industry makes requirements shift often to the most popular and “next best thing” tools and programming languages. Gone are the days when only one programming language or a very specific process was required from a developer. Nowadays programmers must know a range of technologies across multiple platforms in order to do good work.

He starts with his own definition of what the term "full stack developer" means and how it's different from what it meant even just a few years ago (like back in 2000). He breaks up the skills and technology into a few different categories:

• System administration
• Web development tools
• Back-end tech
• Front-end tech
• Design (including UX/UI)

Each item on the list includes a bit of context around the topic and a few items that could fit inside it. He ends the post wondering if it's better to be a full stack developer or not. Is being a generalist better than being a pro in a particular technology?

In this new post to his site Mathias Verraes approaches the concept of the DRY principle (Don't Repeat Yourself) as being more about knowledge. He includes two "real world" examples where the business rules can change around you.

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

In his examples, he shows how hard-coded rules (like "a product container can only contain 3 products") could just be around certain needs, not the entire range of requests. He covers some of the principles of Domain-Driven Design and how they apply here, pointing out that changing rules in one part of the application can have an effect on other parts depending on it.

NetTus.com has followed up their previous article covering some of the basics of the HTTP protocol with this new post, part 2 of the series. They suggest that HTTP, the messaging format of the web, is the one protocol that every web developer should know.

In my previous article, we covered some of HTTP’s basics, such as the URL scheme, status codes and request/response headers. With that as our foundation, we will look at the finer aspects of HTTP, like connection handling, authentication and HTTP caching. These topics are fairly extensive, but we’ll cover the most important bits.

In this article, they talk about things like the HTTPS secure version of HTTP, server-side connection handling, identification/authorization and working with caching and cache control headers.

Daniel Ribeiro has (re)published an article he originally wrote for the Web & PHP Magazine about becoming a PHP evangelist and helping to lead change in the community.

To evangelize is to effectively transfer information regarding one set of beliefs to another, with the final goal of converting each individual to the original belief. Isn’t that what we do when we spread the word of PHP?! The idea behind being a PHP Evangelist is for an individual to speak passionately about PHP and be able to have strong and durable arguments for PHP, if questioned about his “faith” in the technology.

He talks some about the skills and things you'd need to become an evangelist - an advanced knowledge of the language, thinking "out of the box" about problems and how you can stand out from the other people in the community as a leader. He also recommends being technically adept as well and contributing to projects, either through support or actual development.

PHP evangelists are born to lead, to form opinions, influence the opinions of others and to have followers – and haters as well. Even if you think you were not born to be a leader or just don’t want to be one, you will have to get used to public speaking if you wish to become a PHP evangelist.

Michael Kimsal has a new post to his site with some recommendations for web developers as to the things they should know to do their job well.

The original question from was a 16 year old who’s been doing some basic CRUD apps, but is getting bored and wanted to move on to ‘real’ development. There were some good replies, but few went in to the depth of detail that I think beginners are even aware of. Granted, this might scare off some, but for others it might give them some ideas about what’s possible and what’s involved in professional web development. I know I’m going to leave off some topics, so feel free to add on!

He touches on topics ranging from version control to performance and even a mention of mobile development. Each section includes a brief summary of the topic and some have specific topics to check out to help narrow things down to the important parts.

In his latest post, Pádraic Brady suggests that you take PHP security seriously and start really thinking about the security of your applications, not just talking about them.

Most programmers treat security as an afterthought and engage in zero self-directed education about security in general. The most common response is actually shock, followed by denial, followed by excited elation at the idea of fixing stuff, followed by the sobering realisation that someone somewhere is an evil fucker for making their lives harder by not telling them all this sooner. Some graduate further into taking security seriously, seriously. This is actually PHP’s current failing: Knowledge.

He talks about some of the mislead beliefs that many PHP developers share about the "One True Way" to secure their applications from common things like XSS and CSRF. He also shares his thoughts on how to solve this knowledge problem...and it's not by reading the same things we have been for years now. New knowledge needs to be shared, new questions need to be asked and new methods need to be shared for effective security precautions.

Knowledge is the essential ingredient to improving PHP Security. What you don’t know can bite you; what you do know can be hunted down and shot.