In a recent post to the Hackernoon site, Sergii Shanin shares his take on the "PHP is dead" conversations and posts out there with the expected "Viva le PHP!" (long live PHP!) following it.

The fracas over Gutenberg and WordPress is the latest installment in the death of PHP. Take a deep breath everybody. Let’s ignore the trolls and take a look at what Mark Twain, Fidel Castro and PHP have in common?—?and more to the point, why PHP is still a reasonable choice for startups and small businesses.

t looks like ‘PHP is dead’ blog posts started cropping up in 2011 (let me know if you find older ones). If you search around Medium and the coding bootcamps that are popping up like mushrooms, the only common denominator is that everyone hates on PHP or simply ignores it. Apparently, it’s impossible to code in PHP with an oiled beard and ironic t-shirt while drinking overpriced coffee.

He shares two of the most wide-spread myths about PHP - that it's slow and that it can't scale - and dispels them. He then goes through some types projects where PHP "shines" including content driven websites and e-commerce sites. He shares some the "business sense" around choosing PHP, the perspective senior PHP developers bring to teams and projects, and the seeming "nine lives" of PHP.

Lee Blue has posted his next article in a series covering some of the real costs and considerations around using PHP for your applications. In this latest post he talks about frameworks and what kind of effect they could have on the overall profitability of your business.

Last week we talked about application shelf life an aspect of PHP development that often goes overlooked. This week let's talk about how the web development framework you use contributes to the shelf life of your app and the profitability of your web application. [...] The main goal of all web frameworks is to improve the developer's ability to get ordinary things done so we can focus on the primary goals of what we're building.

He talks about how PHP was "made for the web" and why there are so many different kinds of frameworks out there (though most are generally MVC-ish). He talks about one of the standard arguments, learning curve vs efficiency, and how it compares to the "no framework framework" ideals. He then gets into some of the dark side of using frameworks, specifically how they can shorten the shelf life of an application and how difficult migration can sometimes be. He points out the irony of large frameworks: the bigger the app/framework, the harder it can be to migrate (and cost more). He encourages sticking with smaller, lighter frameworks instead and suggests coding standards, common packages and using custom libraries only where needed to create your application.

Jonathan Hill has taken an interesting perspective in his recent post looking more at some of the average financial costs around being a web developer.

With Software Development topping 2014′s top jobs list, I thought I would share how much it cost me to become a web developer, and what my monthly expenses look like nowadays.

He breaks it down into a few different categories, listing an average price for each:

• Initial (start-up) costs for hardware and software
• Training costs
• Recurring costs

Obviously, not all of the software and tools he lists are needed for every software developer, but it does give some perspective. Thankfully, he also links to some free alternatives to the tools he mentions that can reduce these costs as well.

Kevin Schroeder has a new post to his site looking at the cost of logging in web applications. It's not so much about the theory behind what to log and when to log as it is the actual performance hit various kinds of logging take on your app.

So, I was having a discussion with a person I respect about logging and they noted that often logging poses a prohibitive cost from a performance perspective. This seemed a little odd to me and so I decided to run a quick series of benchmarks on my own system.

His tests ran through the types of logging available to PHP developers (like "debug", "notice" or "info") and wrote out the same message to a file ten thousand times each. He just did a simple microtime-based benchmark and graphed out the overall time it took. The differences between the tops of the bars is the time it took for that specific level of logging. He dropped it down to a more realistic level and notes that it only took "1/1000ths of a second per request."

Eran Galperin has a new post to his site today talking about the real cost of software development, how it's more than just time spent hands-to-keyboard.

If you are a first-time entrepreneur and likely someone with little experience with software development, the chances of you successfully directing the development of a product on your own, are slim. [...] In software development, too often vision holders hand off a "vision document", i.e. "The Specifications", to a developer and expect him to translate it to the finished product they have in their mind. Most software developers or graphic designers are simply not fit for that role - they do not have the experience, skills or vested interest in transforming your vision to an actual product.

His examples revolve around the idea of outsourcing the development to another group, but a lot of the concepts still apply to in-house development too. He talks some about the idea of "you get what you pay for" when it comes to quality and how much you're willing to pay. He then gets into one of the hardest questions when dealing with development - how to find good developers. He mentions several things that need to be a part of that relationship like trust and good communication.

In his most recent post Chris Hartjes looks at the concept of "test whenever" (vs TDD) development practices and how, sometimes, writing tests for things that are may get tossed when they're done may not be the best option.

Let’s look at TDD vs. Test whenever. The trade-off being made here is not about quality of code or guarding against regressions. It’s about opportunity cost. This had occurred to me but I had dismissed it as being “anti-testing”. But I think I was wrong, and here’s why.

He talks some about a presentation from Dan North< ("Decisions, Decisions") about when to test (not whether to test or not) and how he noticed his development team was being very productive, but with a "spike and stabilize" development method. He also talks about the concept of "opportunity cost" and how it plays a factor in when tests are introduced to the process.

The key to all this is being able to identify at what stage in this particular pattern your code is at. Is it still a spike, meaning you are working out implementation details and trying to figure out if it will even have the desired result? Or is it stable, providing solid value to the application as a whole and ready to be wrapped in tests to protect against regressions?

In this new post Joseph Scott takes a look at hashing in PHP, specifically around md5 hashes, and a better alternative (that's also more secure.

The majority of the Coding Horror: Speed Hashing post talks about speed based on MD5. [...] If you are still using MD5 to hash passwords (or worse, aren’t hashing passwords at all) then please stop and go use bcrypt. For those using PHP phpass is a great option.

He talks about the crypt method, how its encryption method and "cost" value effects the speed and how difficult it would be to generate all possible hashes for a password (hint: crypt with a cost of 13 is worlds better than md5).

Brandon Savage has a new post about something that some developers out there factor into their development estimates from the beginning and others are just learning how to adjust to - the sunk cost that can be associated with writing code.

Last week, I began working on something that didn’t pan out. For whatever reason, I went down the wrong path, and ultimately abandoned the task I was working on. In discussing it with my boss, he mentioned to me that it was better to realize early on that something wouldn’t work than to trudge onward, insisting that it be finished due to the "sunk cost" of the time already spent.

There's two sides to this story - one in which the application continues to be developed and takes up more time (but still ends up as a product) and the other where the time already spent is lost as a completely new approach is taken.

On the Ibuildings techPortal site Stefan Koopmanschap has written up some thoughts on one of the eternal struggles development shops face - whether to buy or build the software they need (either for themselves or their clients).

One of the biggest struggles in any software development company is "Buy vs. Build". How do you strike a balance between writing custom software and purchasing off-the-shelf solutions. This is something that is very hard and everyone gets it wrong every once in a while. In this article we will explore the way that Ibuildings approaches this issue, in the hopes that it helps others in getting it right more often.

He talks about considerations made on both sides - how flexible is the application, what is on-hand that could be adapted - and how the base product they might have purchased can act as a based to work from (like a content management system). There's no overall recommendation, though - too much of the decision depends on what's needed at the time and the capabilities of the technical staff employed.

Sometimes power comes at a price - you get benefits from the added features and functionality, but you can lose something else along the way - the simplicity that brought you in originally. Federico Cargnelutti takes a look at a tool that can do just that - the Zend Framework.

Don’t assume that just because you’re using an object-oriented framework you are writing reusable and maintainable code. You are just structuring your spaghetti code. [...] The main problem with flexibility is that most developers give up trying to understand. I don’t blame them, no one likes dealing with complexity

TO illustrate, he gives two code snippets from two example developers - Developer A makes full use of the framework and takes a more compact approach to the problem while Developer B adds in a bit more checking and takes a different path to the same (basic) end result.