Michael Dryrynda has a post to his site sharing a method for using Laravel Telescope in specific environments. Telescope provides enhanced debugging functionality to Laravel applications for introspection into data about requests, jobs, queues and more.

Whilst its primary purpose is as a debugging tool in development, it is also a powerful asset in debugging your production environment. In order to get Telescope, however, I ran in to some stumbling points in my CI environment in GitLab.

To work around this, I set out to conditionally load Telescope. I stumbled upon this comment from Mohamed Said, which suggested loading the TelescopeServiceProvider in one of your application's service providers, but doing so was not enough.

He goes on to talk about the package auto-discover functionality Telescope uses to load its provider and how this, along with the dont-discover configuration option in Composer's extra section can be used to control its loading. He also includes the code needed to register the provider classes but only in the environments other than "build" and "testing".

On the Delicious Brains site there's a new tutorial posted for the WordPress users out there sharing a case study of the performance impact of WP Offload S3 on the average page load time.

One of the great things about working at Delicious Brains is working on products that I use and love outside of work. I was a WP Migrate DB Pro customer well before joining the team and still use it daily on personal sites and side projects. However, I’ve not often had the need to use our other plugin, WP Offload S3 to offload site media files to Amazon S3.

The post starts with some of the background on why the author chose the WP Offload plugin in the first place and what features it provided. The tutorial then walks you through the installation process and how to have assets served up by Cloudfront correctly. It also includes some things you should consider when figuring out if this setup is for you. It then wraps up with some benchmarks of the results post-implementation, seeing a decrease of almost a second off of the previous page load time.

On his site Nikola Posa has a tutorial showing how to lazy load services with Zend Manager, a component of the Zend Framework. In this case, the "services" being loaded are in a dependency injection container.

Any more complex application includes a big dependency injection tree of services, some of which can have a more complicated creation logic. If the service is injected as a dependency, but not necessarily used at every execution, you may want to lazily initialize that service until it is really needed.

In those situations, you may be tempted to inject the entire Dependency Injection Container instead, and lazy-load that resource-hungry service. I find that to be an anti-pattern, and I explained my views in a blog post written some time ago.

He offers a better solution in the form of the proxy design pattern, making it possible to decouple the services from the dependency injection container. He provides examples of using this pattern along with the Zend Service Manager functionality to create the factories and the services configuration.

In a new post to his site Amit Merchant covers the difference between two functions in Laravel's Eloquent functionality that do similar things: load() versus with() for eager loading.

Today, while working with one of my projects(which is built on top Laravel) I bumped into the situation where I needed to get associated model’s data for one of the models. So here, I had two approaches in Laravel to accomplish this which are basically called Eager Loading: with() [and] load().

Both accomplish the same end results - eager loading a related model onto the first. In fact, they both run exactly the same two queries. The key difference is that with() eager loads the related model up front, immediately after the initial query (all(), first(), or find(x), for example); when using load(), you run the initial query first, and then eager load the relation at some later point.

He then goes through examples of each and the queries they produce on the backend. He shows how splitting up the queries might be a better option for some cases and finishes with the benefits of using each (use cases).

On the Stitcher.io blog there's a new article posted about a programmer's cognitive load and offers some tips to help reduce it, especially when reading code that's new to you.

Whether it's your own code or that of others, when you open a file, you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code. Doing this day by day, it's important to find ways to make this process easy. To try and reduce this cognitive load as much as possible. Streamlining the way you take in code, will allow you to not only work faster and better; but also improve your mental state and mood.

[...] Today I want to share some techniques that can help you reduce this cognitive load while coding. In contrast to some recent advocates of "visual debt", I won't talk about stripping away pieces of your codebase. We'll look purely into the visual aspect: what makes code hard to read and reason about, and how to make it easier.

The tips they article make use of some of the most common features of IDE including adjusting fonts and spacing, using code folding to reduce visual noise and effective naming. Each point has either screenshots or code examples to help illustrate the point.

Robert Basic has a new post to his site with some advice for the Behat users out there testing their Symfony applications. He shows how to easily load up fixture data with the help of Doctrine.

Performing end to end testing of any application requires from us to have a set of reliable test data in the database.

If we write a Symfony application and use Behat to do the end to end testing, the we can use the Doctrine fixtures bundle to create the required fixture loaders and load them in our Behat scenarios when required.

He walks you through the installation of the Doctrine fixtures bundle (via Composer, naturally) and how to enable it via the Symfony kernel configuration. He then includes an example of the fixture loader class from the FOSUserBundle and how it works. Next up is the installation of the Behat Symfony 2 extension and a bit of extra code to make a new feature context for Behat containing a "loadDataFixtures" method to do the heavy lifting.

Leonid Mamchenkov has a post to his site showing how he solved an interesting problem in one of his recent projects: determining the order to use items based on their dependencies.

One of the projects I am working on at work presented an interesting problem. I had a list of items with dependencies on one another and I needed to figure out the order in which to use those items, based on their dependencies.

He gives the example of database tables where it would be required to export the tables so that the relations between them are maintained when imported back in. He gives some example data, a basic nested PHP array, and defines the relationships between them (just strings in this case). While he did solve the problem, he wasn't happy with the solution. Instead he went looking for other options and found graph theory to be a good match. He briefly cover what the theory involves and links to an example that basically does what he needs...but is written in Python. He finishes off the post sharing his refactoring of this logic into PHP including a recursive "dependency resolver" and the output showing the correct ordering for loading objects based on their dependencies.

On the SitePoint PHP blog author Bruno Skvorc continues his series about using the Grav flat-file CMS to create fast, simple sites. In his previous post he talked about the use of various "must have plugins". In this latest post he focuses more on some "tweaks" you can make to prepare your site for higher load.

We previously looked at some essential Grav plugins with which to round off the installation of a personal blog. In this post, we’ll take a look at some additional, advanced plugins, rounding it all off with an installation of Varnish for supercaching, taking performance to a whole new level.

His list of "tweaks" (and other plugins) that are recommended for a more robust site are:

• The "Related Pages" plugin
• An "assets" plugin for custom JS and CSS without extending the theme
• Simple search handling
• Comments on the content with the JsComments plugin
• Image Optimization and CDNs
• Caching with Varnish

All but the last item on the list are plugins you can drop in and configure pretty easily. Varnish requires a little extra setup, however, as it's an external service/software that needs to be running in front of your web server to do its job.

Christian Mackeprang has a post to his site with some ideas about reducing the "cognitive load" of your code - basically making it easier to follow, read and understand.

Low bug count, good performance, easy modification. Good code is high-impact, and is perhaps the main reason behind the existence of the proverbial 10x developer. And yet, despite it’s importance, it eludes new developers. Literature on the subject usually amounts to disconnected collections of tips. How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!

I believe it’s possible to construct a simple mental framework that can be used with any language or library and which will lead to good quality code by default. There are five main concepts I will talk about here. Keep them in mind and writing good code should be a breeze.

His tips center around concepts like:

• following coding standards for consistency
• clarification through modularization
• overall readability and application structure
• good naming on variables and methods/functions

For each topic he gives a brief summary and some example code, usually showing what not to do and a solution or two to help with the clarification.

The Grok Interactive blog has posted a tutorial, the first part in a series, showing you how to work with large CSV files in PHP.

Importing CSV files into your application can become a problem when the file is really big, > 65,000 rows big. Each row of the file needs to be parsed, converted into an object, and then saved to a database. All of this needs to happen within a 30 second timeout window. It may sound like an impossible task, but there are actually a couple of solutions that can solve this problem. While working on a project at Grok, I was tasked with doing exactly that.

He talks about the method he tried initially for parsing the large files, splitting it up into different files and processing them as chunks. He points out that it relies on the file system, though, and this made it difficult to debug. He finally came up with a different, more simple solution: importing the files directly into MySQL via a LOAD DATA LOCAL INFILE command. He shows how to set this up in a controller and "importer" class that handles the upload and import via the importFileContents method (complete code included). He walks through what the code is doing and includes a few notes about the configuration of the database connection to specify additional options on the PDO connection to allow the local file load.