Holosun just introduced their new RML Rail Mounted Laser. It’s tiny and affordable and will come in both red and green laser versions. The RML will come in five models with MSRPs ranging from $105 to $162 and is expected to hit stores in March or April.

Here’s their press release . . .

Lasers are becoming invaluable to verify an accurate and effective aim, especially in low-light environments. Pistols and rifles fixed with lasers have been shown to improve fast target acquisition. With the growth of red dot optics, lasers have fast been growing in the industry as an alternative to mounted optics. Not only does this help to improve users’ response time, but it also makes a potential Point of Impact clear.

Holosun is known for optics and lasers. This year, Holosun releases the RML (Rail-Mounted Laser). The RML comes in at a very manageable 1.97″×1.18″×0.91″ and 1.3 ounces. Made with a durable polymer housing, the RML is IPX8 rated for water and dust resistance. Additionally, Holosun tests each unit to 2,000G shock resistance. This guarantees that the RML is suited for use in extreme environments.

The RML is available in either a red or green laser version, both of which are class 3R and <5mW output power. The RML package includes one CR1/3N lithium battery. The laser can be adjusted by 4MOA per click and can travel a total of +/-60 MOA. The rate of travel makes it ideal for a primary or even secondary zero, providing an alternate distance point of aim from iron sights or a pistol mounted optic.

With many features, it is easy to see why the RML is a strong contender. Holosun has made it easy to utilize the laser in multiple roles with multiple color options. For the hiker who carries a defensive pistol, the uniformed officer that relies on an alternate color laser and red dot, and everything in between, the RML fills their needs.

Specifications:

• 520nm Green or 635nm Red, class 3R laser
• Cr1/3N removable battery
• Durable Polymer housing
• 4 MOA adjustment per click
• +/- 60 MOA laser W&E travel range
• IPX8 water & dust resistance
• 2000G vibration resistance
• Dimensions: 1.97×1.18×0.91
• Weight: 1.8oz

The Laravel team released 8.80 with the ability to define a route group controller, render a string with the Blade compiler, PHPRedis serialization and compression config support, and the latest changes in the v8.x branch.

Specify a Route Group Controller

Luke Downing contributed the ability to define a controller for a route group, meaning you don’t have to repeat which controller a route uses if the group uses the same controller:

1Route::controller(PlacementController::class)
2    ->prefix('placements')
3    ->as('placements.')
4    ->group(function () {
5        Route::get('', 'index')->name('index');
6        Route::get('/bills', 'bills')->name('bills');
7        Route::get('/bills/{bill}/invoice/pdf', 'invoice')->name('pdf.invoice');
8    });

Render a String With Blade

Jason Beggs contributed a Blade::render() method that uses the Blade compiler to convert a string of Blade templating into a rendered string:

1// Returns 'Hello, Claire'
2Blade::render('Hello, ', ['name' => 'Claire']);
3 
4// Returns 'Foo '
5Blade::render('@if($foo) Foo @else Bar @endif', ['foo' => true]);
6 
7// It even supports components :)
8// Returns 'Hello, Taylor'
9Blade::render('<x-test name="Taylor" />');

PHPRedis Serialization and Compression Config Support

Petr Levtonov contributed the ability to configure PHPRedis serialization and compression options instead of needing to overwrite the service provider or define a custom driver.

The PR introduced the following serialization options:

• NONE
• PHP
• JSON
• IGBINARY
• MSGPACK

And the following compressor options:

These options are now documented in the Redis – Laravel documentation.

Release Notes

You can see the complete list of new features and updates below and the diff between 8.79.0 and 8.80.0 on GitHub. The following release notes are directly from the changelog:

v8.80.0

Added

• Allow enums as entity_type in morphs (#40375)
• Added support for specifying a route group controller (#40276)
• Added phpredis serialization and compression config support (#40282)
• Added a BladeCompiler::render() method to render a string with Blade (#40425)
• Added a method to sort keys in a collection using a callback (#40458)

Changed

• Convert “/” in -e parameter to “” in Illuminate/Foundation/Console/ListenerMakeCommand (#40383)

Fixed

• Throws an error upon make:policy if no model class is configured (#40348)
• Fix forwarded call with named arguments in Illuminate/Filesystem/FilesystemAdapter (#40421)
• Fix ‘strstr’ function usage based on its signature (#40457)

Introduction

When you are still in that learning phase with any technology, your focus is to make your app work, but I think the exponential progress starts coming when you begin to ask yourself “How can I make this better?”. One simple principle that you can immediately apply to your existing or new codebase for cleaner and more maintainable code is the Separation of Concerns principle.

Most of the server-side codebases I have come across have controllers that contain code specifying the real-world business rules on how data can be created, stored, and changed on the system. If you want to learn how to build controllers that are clean, concise, and easily maintainable, then this series is for you.

What you will learn after reading this article

1. You will have a solid understanding of the Separation of concerns principle

2. You will be able to identify the major steps involved in the lifecycle of a request on the server-side

3. You will understand the role of the controller on the server side. This will ensure that the lines of code present in your controller functions are the ones that absolutely need to be in the controller

Prerequisites

1. Understanding of client-server architecture
2. Familiarity with model-view-controller architecture
3. A basic understanding of Object-Oriented Programming

With all that out of the way, let’s move 🚀

Understanding Separation of concerns

What is a concern?

A concern is a section of a feature or software that handles a particular functionality in the system. A good example of a concern in a well-designed backend system is request validation, which means there is a part of the code that accepts the data coming from the client to make sure all the information is valid or at least in the right format before sending it to the other parts of the system.

What does the term Separation of concerns mean?

Since we know what a concern is, understanding the idea behind the Separation of concerns will not be difficult. Separation of concerns promotes the idea of building software in such a way that our code should be broken down into separate components or layers such that each layer handles a specific concern. An example is a feature that retrieves data from the database and then formats the data based on the client’s request. Placing both logic in the same function is a really bad idea since retrieving data from the database is a specific concern, then formatting the retrieved data is another concern.

Lifecycle of a request on the server

I have worked on building many backend systems that provide services to clients and many of them usually follow a similar pattern with 3 major steps which are mainly.

1. Request validation: This refers to the part of your code that ensures that the data sent by a client is in a valid and acceptable format. A simple example is making sure that a value sent from the client as an email is actually a valid email address.
2. Business logic execution: This is the section of your codebase that contains the code that enforces real-world business rules. Let’s use an app that allows a customer to transfer money from one account to another. A valid business rule is that you cannot transfer an amount that is greater than your current balance. For this app to work properly, there has to be a section of your code that compares the amount you are trying to transfer and your current balance and makes sure the business rule is obeyed. That is what we refer to as business logic.
3. Response formatting and return:This refers to the section of your codebase responsible for making sure the data returned to the client after business logic execution is properly formatted and well presented. eg JSON, XML

I have come across a lot of codebases that perform these three steps using a single function or method, where line 10 to 15 handles request validation, line 16 to 55 handles all the business logic with long if-else statements, loops, etc, then line 56-74 formats the response based on certain conditions, and finally, line 75 returns the data to the client. That’s about 65 lines of code in a single function! That is a ticking time bomb waiting to explode when a new engineer joins the team or when you come back to add more changes to the code.

Understanding the role of the controller in the backend request lifecycle

Imagine we have 3 tasks involving the same feature.

1. Fix a bug in request validation
2. Change the way data is retrieved from the database (use Eloquent ORM instead of raw queries)
3. Add extra meta-data to the response returned to the client

If our controllers are designed in a way where each method contains all these three major steps involved in fulfilling a request on the server-side, then the flow looks something like the image below

Handling these tasks become a nightmare because everyone in the team will be modifying the same function, and good luck merging all these changes without the need to resolve merge conflicts 🙄.

So, what exactly should the controller do?

The controller should serve as a delegator, meaning that the controller accepts a request with the associated data from the client, then the controller should assign the different tasks involved in fulfilling the client’s request to different parts of the codebase, then finally, the controller sends a proper response (success or failure) to the client depending on the result of the executed code.
I have illustrated this using the image below.

If our controllers are built this way, making changes will be incredibly easy, bugs will be easy to trace and the responsibility of each class and other classes it depends on to fulfill its tasks will be immediately visible even to someone looking at the code for the first time.

There is more juicy stuff to come 😋

Like I said at the beginning of the article, this is going to be a series because there is a lot of information to digest and I want to make sure you can remember a lot after reading each article. I want to separate the concerns you know 😂, so that this article does not become massive like the controllers we will be refactoring starting from the next part. If you didn’t get that joke, then maybe next time.

In the next article, Part 2. We will be refactoring a controller function with a specific focus on the Request validation concern. We will build a Request validator class and abstract all the logic involved in validating the client’s request away from the controller. I will be using Laravel in the rest of the series.

Quick Recap

1. Separation of concerns is simply a concept that promotes the idea that you should always look at your code to identify the different functionalities involved, and think of how you can break down the code into smaller components for clarity, easy debugging, and maintenance among other benefits.
2. All the logic involved in fulfilling a client’s request on the server-side should not be in a single location, like a controller.
3. The controllers should serve as classes that delegate tasks to other parts of the codebase and get’s back a response from those other parts. Depending on the response received by the controller, the controller decides if the response to send back to the client should be a success or failure response.
4. More code might be involved when trying to break down a feature into smaller components but remember, it pays off in the long run.

It’s a wrap 🎉

I sincerely hope that you have learned something, no matter how small, after reading this. If you did, kindly drop a thumbs up.

Thanks for sticking with me till the end. If you have any suggestions or feedback, kindly drop them in the comment section. Enjoy the rest of your day…bye 😊.

Despite the show’s finale airing almost 20 years ag,o the technology in Star Trek: Voyager (and even TNG) still looks convincingly futuristic, and we’d happily trade our folding smartphones like the Galaxy Z Fold 3 or the Surface Duo 2 for this incredible recreation of one of Voyager’s tricorders.

Producing a sci-fi TV series based on one of the most beloved franchises of all time isn’t cheap. You not only have to build standing sets recreating the interior of a giant starship, there’s also alien worlds to construct, loads of special effects, and mountains of futuristic props for the cast to interact with. According to Hackaday, For Star Trek: Voyager, the second follow-up to the wildly successful Star Trek: The Next Generation, there were plans to introduce an updated design for the ubiquitous tricorder—a futuristic PDA that can do almost anything a script requires of it—but concept sketches were replaced with hand-me-down props from TNG to keep costs down.

At least one Star Trek: Voyager fan felt that was a great injustice, but instead of voicing their concerns during a Q&A session at a Star Trek convention, they set out to build the Voyager Tricorder, as they call it, in real life. The first version that YouTuber Mangy_Dog (a UI designer who’s also skilled at electronics) took over a year to build was impressively capable and looked straight out of the 24th century. But when a friend commissioned a replica of the tricorder for themselves, Mangy_Dog took the opportunity to thoroughly update the prop inside and out, and while it took several years to complete, the results look even better than anything Hollywood has ever delivered.

Mangy_Dog has delved into the design and engineering process behind the Voyager Tricord V2 build in three videos. The first video goes into some of the challenges of the hardware itself, including custom PCBs and problems with sourcing high-quality displays, while the second video delves into the custom user interface and animations created for the prop, which are all generated and rendered on the fly, instead of just being pre-rendered videos played back on queue. The third video goes much deeper into the internal hardware including the custom PCB created for the project and the extensive code that powers it.

In addition to LCD displays displaying what appear to be Starfleet standard user interfaces, the Voyager Tricorder V2 includes countless touch-sensitive buttons used to switch modes or activate secret features after a long press. There’s also blinking, flashing, and pulsing LEDs all over the device, making it look like the tricorder is actually scanning and interacting with its environment, when in reality the only thing this replica tricorder can actually do is make other Star Trek fans incredibly envious.

Wondering where our RSS feed went? You can pick the new up one here.