Popular weather app and data-collection service Dark Sky has been acquired by Apple for an undisclosed sum, a blog post from the Dark Sky team announced. The post claims that Dark Sky will now “reach far more people, with far more impact, than we ever could alone.”

The iOS app will not see any changes “at this time,” and it will continue to be listed on the App Store. Android and Wear OS are a different story, though. The Android app will no longer be available for download, and “service to existing users and subscribers will continue until July 1, 2020, at which point the app will be shut down.” Active subscribers will get a refund.

As for the website, which is also popular:

Weather forecasts, maps, and embeds will continue until July 1, 2020. The website will remain active beyond that time in support of API and iOS App customers.

A lot seems to be up in the air about where this will go in the long term, though. Dark Sky is notable in part for its big data-driven Dark Sky Forecast API, which provides customers with hyper-local weather data for use in their own apps or services. That API will no longer accept new signups, though “service for existing customers is not changing today.” The API will function for existing customers through the end of 2021.

That API and the related data operation may be the main reason Apple was interested in Dark Sky; the service is known for providing smart notifications and highly localized data about precipitation, among other things, in much more detail than Apple’s own Weather app.

The blog post also notes that Dark Sky will now be subject to Apple’s privacy policy, and the app’s developer is already listed as “Apple” in the App Store.

Listing image by Dark Sky

Laravel Validation 101, Controllers, Form Requests, and Rules

A core part of any project is understanding how to validate the incoming request from your users and in this tutorial let’s look at how we can setup validation with our controllers, form requests, and rules.

Working with Controllers

By default, all Laravel controllers that extend from the Base Controller inherit the ValidatesRequests trait.

The ValidatesRequests trait gives you access to the validate method in your controller methods.

For example, say the user is creating an Article:

They may be entering a name, and some content for this article, along with a date to publish. Your controller validation may look like one of these, which are all valid:

public function store(Request $request) { $this->validate($request, [ 'name' => 'required|string', 'body' => 'required|string', 'publish_at' => 'required|date_format:Y-m-d H:i:s' ]); // The request validated and this code will get run ... } public function store(Request $request) { // Note: the array syntax is also available $request->validate([ 'name' => ['required', 'string'], 'body' => ['required', 'string'], 'publish_at' => ['required', 'date_format:Y-m-d H:i:s'], ]); // The request validated and this code will get run ... } public function store() { request()->validate([ // Validation Rules... ]); // The request validated and this code will get run ... } public function store() { $this->validate(request(), [ // Validation Rules... ]); // The request validated and this code will get run ... } 

It should also be noted, that the response to the validate method will be the data that was validated:

public function store(Request $request) { $validatedData = $request->validate([ 'name' => ['required', 'string'], 'body' => ['required', 'string'], 'publish_at' => ['required', 'date_format:Y-m-d H:i:s'], ]); // I know that the only keys in validated data are the ones that were successfully validated, i.e.: name, body, published_at $this->articleService->store($validatedData); } 

Alternatively, you can do this too:

public function store(Request $request) { $request->validate([ 'name' => ['required', 'string'], 'body' => ['required', 'string'], 'publish_at' => ['required', 'date_format:Y-m-d H:i:s'], ]); // I know that the only keys in validated data are the ones that were successfully validated, i.e.: name, body, published_at $this->articleService->store($request->only('name', 'body', 'published_at')); } 

A list of the available validation rules can be found here.

Working with Form Requests

If you would like to extract your validation logic away from your controllers, or you would like to do authorization and validation at the same time, Laravel makes the Form Request class available to you.

You can make a form request class using one of the many built-in Laravel generators:

php artisan make:request StoreArticleRequest 

This will make you the following class in app/Http/Requests by default:

class StoreArticleRequest extends FormRequest { public function authorize() { return true; } public function rules() { return [ // ]; } } 

Form request classes comes with 2 methods, authorize and rules.

Authorize

Authorize lets you prevent the controller code from running if this method returns false. Laravel will throw a 401 unauthorized exception.

An example usage might be:

public function authorize() { return $this->user()->can('create articles'); } 

Rules

The rules method will return our array of rules that was in our controller validate method;

public function rules() { return [ 'name' => ['required', 'string'], 'body' => ['required', 'string'], 'publish_at' => ['required', 'date_format:Y-m-d H:i:s'], ]; } 

Note: You can type-hint any dependencies needed into the rules method.

So, how do we use this class? We type-hint it right into our controller method:

public function store(StoreArticleRequest $request) { // Validation and Rules passed } 

If the validation fails, the user will be redirected back with the errors flashed to the session. If it is an AJAX call, it will be a 422 Unprocessable Entity response.

You may get the validated data just like before:

public function store(StoreArticleRequest $request) { $validatedData = $request->validated(); // Insert into database ... } 

Working with Custom Rule Classes

If there is a validation rule that does not exist as part of the available built-in validation rules, you can create a custom one:

Again, using one of Laravel’s make commands:

php artisan make:rule IsValidStateInUSA 

This will make you the following class in app/Rules by default:

class IsValidStateInUSA implements Rule { public function passes($attribute, $value) { // } public function message() { return 'The validation error message.'; } } 

Your passes method holds the logic for allowing this validation method through. The message method is the message that gets returned if it fails.

Using the example of Is a valid State in the USA, we would need the item passed in to be one of 50 different state codes. It could look like this:

class IsValidStateInUSA implements Rule { public function passes($attribute, $value) { return in_array(strtoupper($value), [ 'AL', 'AK', 'AZ', ... ]); } public function message() { return 'This is not a valid state code in the USA.'; } } 

Then, to use this in your controller or form request, you just add it to the list of validation rules for that key:

public function store(Request $request) { $request->validate([ 'state' => ['required', new IsValidStateInUSA], ]); ... } 

Handling Validation Errors

When validation fails, Laravel will automatically redirect back, with an $errors variables flashed in the session.

You can easily create a file called messages.blade.php and include in your master layout file like this:

@if($errors->any()) <div class="alert alert-danger" role="alert"> <button type="button" class="close" data-dismiss="alert" aria-label="Close"> <span aria-hidden="true">×</span> </button> @foreach($errors->all() as $error) <br/> @endforeach </div> @endif 

Which will display all errors flashed to the session, or if you prefer to handle them one by one on a per blade file basis, you can use the blade @error helper:

@error('title') <div class="alert alert-danger"></div> @enderror 

The $message variable will be provided to you inside the @error tag.

Customizing Error Messages

When working with the validate method, you can override the messages with the third parameter:

public function store(Request $request) { $this->validate($request, [ 'name' => 'required|string', 'body' => 'required|string', 'publish_at' => 'required|date_format:Y-m-d H:i:s' ], [ 'name.required' => 'A article name is required', 'body.required' => 'A article body is required', 'publish_at.date_format' => 'The publish at date is not in the correct format.' ]); // The request validated and this code will get run ... } 

When working with a form request class, a messages function can also be implemented to customize the error message for each specific rule:

public function messages() { return [ 'name.required' => 'A article name is required', 'body.required' => 'A article body is required', 'publish_at.date_format' => 'The publish at date is not in the correct format.' ]; } 

For the most up to date documentation and a much more in-depth look at validation, visit the Laravel Documentation.

Filed in: News

6 Laravel Eloquent Secrets to improve your code

Eloquent is the default ORM that ships with Laravel. It implements the Active-Record pattern and provides an easy way to interact with your database. Every single model represents a table in your database with which you can work. In this post, we’ll show you more or less hidden secrets, methods, and properties you might not know to improve your code.

Snake Attributes

Snake Attributes are an interesting one. Let’s take a look at what the code says:

/** * Indicates whether attributes are snake cased on arrays. * * @var bool */ public static $snakeAttributes = true; 

Very often, people make a mistake to use this property to change the way how to access properties. Many people believe that if they change this property, they can easily access the attributes using camel-case annotation. That’s not the case. We strongly advise against using it. It is merely there to define whether attributes are camel or snake-cased when the model is output as an array.

If you want to work camel-case based, we recommend you take a look at the package Eloquence by Kirk Bushell.

Pagination

If you use Laravel’s Eloquent ORM, you’re in luck. It provides an easy way to paginate results out of the box. You might be familiar with something like this:

$comments = Comment::paginate(20); 

With this method, you can paginate the comment model with 20 items per page. Changing that value gives you the possibility to define how many items are displayed per page. If you do not specify anything, the default gets applied, which is 15.

Assume that you want to display comments in several places on your website. Always 30 comments per page. Then it would be bothersome if you have to pass the parameter 30 at every place. Therefore you can set a new default value directly on the model.

protected $perPage = 30; 

Appending custom values to models

Eloquent has a great feature called “Accessors”. The feature allows you to add custom fields to models that don’t exist on the model or in the table. It doesn’t matter if you use existing values or define completely new ones. You can return anything. Here is an example of how Accessors work. Given there is a model called User where we put the code below.

function getFullNameAttribute() { return sprintf('%s %s', $this->first_name, $this->last_name); } 

Now you have access to a full_name attribute on the post model, like this:

User::latest()->first()->full_name; 

The problem is now if you return objects, like a collection, this attribute doesn’t get appended to the user model. Add the protected $appends attribute to your model. It accepts an array with one or multiple fields that should automatically be appended from now. This is how it looks like:

protected $appends = ['full_name']; 

Mutators for non-existing columns

Mutators are the opposite of Accessors. You can use them for really cool stuff. For example, to convert different inputs. Let’s show you something. Imagine you want to save a kind of time period. Usually, you always save the smallest possible unit. In our case seconds. For UX reasons, the user doesn’t want to enter seconds, but for example, minutes in one place, or hours in another place. It can all be solved very quickly.

class Video extends Model { public function setDurationInMinutes($value) { $this->attributes['duration_in_seconds'] = $value * 60; } public function setDurationInHours($value) { $this->attributes['duration_in_seconds'] = $value * 60 * 60; } } 

What does it mean? It means that you can use the non-existent column duration_in_minutes on the model, but in the background, the column duration_in_seconds is updated. The same applies to the non-existent column duration_in_hours. This results in the following logic, for example:

class AnyController { public function store() { $video->update([ 'title' => request('title'), 'duration_in_minutes' => request('duration_in_minutes'), ]); } } 

This saves you the calculation in the controller, and you can simply use a non-existent column and use a mutator to map it correctly to the correct column while performing some calculations.

Eager loading with $with

Let’s talk a little about relations. By default, Laravel uses lazy loading. What does that mean in terms of relations? The good thing is that lazy loading saves memory because not all data has to be kept, and we load the data when we need it. Consider this code sample:

$comments = Comment::all(); foreach ($comments as $comment) { echo $comment->user->name; } 

In the example above, we get all comments. Then we loop through the comments and display the username for each comment. The code works, but we run into a problem. Lazy loading now makes sure that the query to get the user is only executed when we want to output the username.

Welcome to your first N+1 problem. Why N+1? N is always the number of comments, and 1 is the query to get the comments at all. For example, if we have 500 comments, then the query to get all comments is fired once and then one query to get the corresponding user – per comment. So 500 + 1 queries. This means that as the number of comments increases, the number of queries increases as well.

To prevent it there is something called eager loading.

$comments = Comment::with('user')->get(); foreach ($comments as $comment) { echo $comment->user->name; } 

That ends in two queries. The first query fetches all comments, and the second query immediately fetches all associated users. In the background, the following happens (simplified):

SELECT id, user_id, body FROM comments; SELECT name FROM users WHERE user_id IN (1,2,3,4,5...); 

Whether 10, 500 or 10000 comments are fetched at the end is not essential. Two queries remain.

You have now seen how you can use eager loading. But only how to use it manually. You can also automate the whole thing so that certain relations are always loaded automatically by eager loading. For this there is a property on the model.

protected $with = []; 

So we can simply set the property protected $with = ['user']; on our Comment model, and from now, the user is automatically loaded at any time.

There are many more possibilities with eager loading. Loading of specific columns only, nested eager loading, multiple eager loadings, and much more. Head over to the Laravel documentation or deep dive into the core.

Model keys

From time to time, there is the need to fetch all IDs of a specific query. It does not matter whether this is a complex query or not. Most people would probably do the following:

User::all()->pluck('id'); 

This works great. But now you get a collection back. To get an array, you would have to pass it to the toArray() method again.

User::all()->pluck('id')->toArray(); 

In most cases, however, this can be shortened. Like this:

User::all()->modelKeys(); 

This method returns an array. In our case, the IDs. It is important to understand that this method does not always necessarily return IDs. It returns, as the name says, all primary keys as an array. The primary keys can be defined in the model. The default is id.

protected $primaryKey = 'id'; 

Filed in: News

First the good news during a tough time. As a result of the declaration of a national emergency, America now has thousands, maybe tens of thousands of new gun owners. Not just owners of new guns…people who are new to gun ownership.

Whether that translates into more support for gun rights down the road is a matter of debate (see this post if you want to discuss the point). We certainly hope so.

The bad news, though, is that very few of those new gun owners can get out to shoot their new guns at a range, let alone take a basic safety or marksmanship 101 type of class. Like most of us, they’re stuck at home for the foreseeable future.

That doesn’t mean, however, that they can’t do some things to prepare themselves for success before they ever fire a live round.

YouTube has thousands of training videos — some good, some not so much — that new gun owners can watch. There are also plenty of at-home drills (dry fire practice) to start learning the basics of safe gun handling, the proper grip and good trigger finger position.

Here are five short videos to get you started, beginning with the late, great R. Lee Ermey and Team GLOCK going over the Four Rules of Firearm Safety.

 

Once you have that down, you need to know how to properly grip your new handgun.

 

Getting the right grip on your gun is good, but trigger finger placement is important, too.

 

“Dry fire” practice is something every gun owner can do at home at any time. It costs nothing and is a great way to improve your shooting from the comfort of your own home.

 

Finally, here’s a dry fire drill you can do to improve your grip and trigger pull. If you can’t put an empty cartridge or a penny on your gun’s front site, try putting one on top of the slide.

G.I Joe is both one of the cheesiest and one of the most fondly remembered of the ‘80s wave of toyetic action cartoons. Does it hold up to your nostalgia? Well, now, during this period of widespread social distancing amidst the novel coronavirus pandemic, is certainly the time to find out.

And knowing is half the battle, so here’s some good info for you: Hasbro has uploaded fifteen full episodes of the classic show to YouTube. You can find them here. That’s almost seven hours of G.I. Joe joy, from the saga of The M.A.S.S. Device to the Pyramid of Darkness arc, because, apparently, this show had arcs? Lasting like five episodes each? I’m going to be real with you, I’m a ‘90s kid, I’m not nearly as much of a Joe expert as some of our other staffers.

But I know that this is the perfect time to watch a lot of television, especially television that imagines a government-like organization that’s both heroic and competent. The world is a scary, complicated place, but in the bastion of cartoons there are simple problems and simple solutions, solutions that often involved buying action figures. And since, for most of us, the most helpful thing we can do right now is just stay home, it seems entirely appropriate to indulge that sort of escapism.

Joe your hearts out, y’all.