Piotr Pasich has shared some thoughts on naming in his latest post to his site today. In it he talks about one of the "hardest things in computer science" (naming things) and makes some recommendations to help you make naming in your code more effective.

Precise names for classes is notoriously difficult. Done right, it makes code more self-documenting and provides a vocabulary for reasoning about code at a higher level of abstraction. There are a couple simple tips&tricks to make the names more readable: do not abbreviate, do not add any extra informations (underscore, type), avoid single letter prefixes, etc etc.

But what if you already know and use those rules and you still want to improve naming in your code? I assume that you care, you're not selfish and you think about elses when you write the code. You ask one of the most important question to yourself, during architecture implementation - how the fellow sitting next to will behave while reading the code.

He's broken up the remainder of the post into different sections, each with a high level recommendation and some follow up description:

• Ask somebody else
• Does it have a single responsibility you can name?
• Simple Superclass Name
• Qualified Subclass Name
• Adding 'Interface' word

He ends with a few names to avoid (like *Manager, *Helper or *Handler) to help prevent ambiguity. He reinforces providing meaning in your naming and making it easier for others to understand what's going on.

On the Laravel News site there's a new post sharing a video tutorial of how to use the Glide image handling library with your Laravel-based application.

Glide is a new package by Jonathan Reinink which is an on-demand image manipulation library. In this video he shows you how to set it up and the basic usage in Laravel 5.

In the tutorial Jonathan walks you through an introduction to the library and how it wraps around the Intervention image handling. He creates a basic application that, when an image endpoint is called, output the image with any given configuration options (like height and width). Glide is one of many packages making up The PHP League.

In his new post Michael Kimsal shares some of his thoughts about framework benchmarking especially in the context of speed.

I've followed the techempower benchmarks, and every now and then I check out benchmarks of various projects (usually PHP) to see what the relative state of things are. Inevitably, someone points out that "these aren't testing anything 'real world' - they're useless!". Usually it's from someone who's favorite framework has 'lost'. I used to think along the same lines; namely that "hello world" benchmarks don't measure anything useful. I don't hold quite the same position anymore, and I'll explain why.

He goes on to talk about the purpose of using a framework and what kind of functionality they should provide. The usefulness of a framework is measured in what tools it provides and how easy it makes them to use. Benchmarks are only about speed, performance and overhead.

What those benchmark results are telling you is "this is about the fastest this framework's request cycle can be invoked while doing essentially nothing". [...] These benchmarks are largely about establishing that baseline expectation of performance. I'd say that they're not always necessarily presented that way, but this is largely the fault of the readers.

He refutes some of the common arguments about increasing performance of an application using a framework (like "just throw hardware at it"). He points out that, even with other improvements, it may come to a point where your framework of choice has become too slow and you need to move on. Think about maintainability too, though, and what you're switching from or to when considering making a move.

• swekaj/cron-expression-generator (1.0.0) Generate valid cron expressions.
  
  
• nsbucky/echosign (v0.1-beta) Library for Adobe Echosign REST APIT
  
  
• 0 comments voice your opinion now!