Hi All, this is Adi again with a Laravel related article. This time in a shorter format. As Laravel developers we need a way to back up our app’s databases somewhere for both save keeping the data and for analysis. I want to share with you a simple solution that I have devised for some of my smaller projects. I have tested this method only on MySql DB and on a VPS, but I think it’s pretty much the same for any database.
TLDR;
The outline of my solution is as follows. There’s an artisan command which handles the backup, that runs periodically using a cron. This command makes use of the mysqldump tool that comes with all MySql installations. mysqldump dumps the given DB into a .sql and we can control where it is dumped. And that’s how my solution works. Now let’s see some code.
The Code
First off create an Artisan command like so php artisan make:command BackupDatabase. This should create a class with the name you mentioned in the command and should also have some default scaffolding for the command.
Let me explain what the above code does. Within the constructor we prepare the name of the file (line 20), then we check if there’s a folder named backups within the storage folder, if not we create it (line 21). Then we instantiate a process, with the command that we want to be executed, we also pass it other details (line 23-29).
Then in the handle method runs the process and logs the output to the application logs. This handle method is executed after the constructor by Laravel itself, so you don’t have to invoke it from anywhere.
And finally you need to setup cron, you have 2 options here, either you can call Laravel’s schedule:run command or call your backup command directly.
Conclusion
This is a pretty simple and neat solution for backing up your most valuable asset, that’s the data. You can extend this feature to do more, like attach the .sql file to an email or upload it to dropbox or where ever and so on.
That’s all from me, it’s been Adi – more about me at Simplest Web.
Recently I was tasked with creating a report in a Laravel project and I thought I would share some of the things I learned along the way. I’m going to use a shop as an example with an orders table that contains the orders, but these principles should apply to pretty much any report. Firstly I want to get the number of orders for the previous week and then I want to get a count of orders by week and year so I can put this data into a report.
Orders last week
The first request is to show how many orders there have been in the past week. Sounds simple right, but even this has a few challenges you need to be aware of.
We could start by creating a query that filters the orders that are greater than the start of the week and less than the end of the week.
This returns us a number thanks to using count() instead of get(), but we have hard coded the dates in our query which is less than ideal as we would have to change the query each week.
Luckily we can make use of Carbon to automatically calculate the start and end dates for our query. We can start by finding the current date and time using now(), then subtract a week and then find the start of the week and the end of the week. We can also tell the database we only want the created_at column in this query by adding a select() rather than getting all of the fields in the order.
If we wanted to display the orders from the week before last we can change subWeek() to subWeeks(2).
Orders By Week
Now we need to get a little more complicated. We need a count of orders for each week and year.
I initially thought I could make use of the count() method like the previous query but it turns out this doesn’t work as I had expected. I could return the count of all orders, but I couldn’t use it with groupBy().
If I only had a few orders I could get all of the orders and then loop through them with some collection methods in PHP to calculate the week and year for each item and then group them how I wanted.
// Please don't do this $ordersByWeek=Order::all()->map(function($item){$item->week=$item->created_at->weekOfYear;$item->year=$item->created_at->year;return$item;})->groupBy(['year','week'])->map->map(function($week){return$week->count();});
Just to explain, I’m getting all the orders, then looping through each of the orders and set the week and year using carbon methods based on the created_at, before grouping by year and week and then looping through the weeks and returning a count of the orders for that week.
This works, but its not very efficient and could start using a lot of memory very quickly as the number of orders starts to grow. Instead, we need to make use of the power of the database. The rest of the article assumes you are using mysql as your database connection as different databases may need slightly different syntax or methods, but the principles should still apply.
We need a way of querying the database to get a count of orders. We can make use of DB::raw() in our select statement to count the order ids. To do this we need to use a mysql aggregate function called count(). We then give this the name of quantity using as.
DB::raw('count(id) as quantity)
We can use DB::raw() once more to get the week number and year from the created_at date using mysql’s year() and week() methods.
DB::raw('week(created_at) as week')
We can then group by the calculated year and week values to get the quantity of orders for each year and week.
useIlluminate\Support\Facades\DB;$ordersByWeek=Order::select([DB::raw('count(id) as quantity'),DB::raw('week(created_at) as week'),DB::raw('year(created_at) as year')])->groupBy(['year','week'])->get()->toArray();return$ordersByWeek;
The toArray() method on the end converts the result to an array to simplify the response. Something like the below would be returned in a json response format.
You could further customise the above query to only show a particular year by using the when() method. This checks if year is in the request() sent to your controller. Laravel has some handy tools for comparing dates built in, such as whereDate(), whereMonth(), whereDay() and whereYear().
$ordersByWeek=Order::select([DB::raw('count(id) as quantity'),DB::raw('week(created_at) as week'),DB::raw('year(created_at) as year')])->when(request('year'),function($query){$query->whereYear('created_at',request('year'));})->groupBy(['year','week'])->get()->toArray();
The when() method also allows you to set a third parameter which will run if the test returns false, so you could filter by the current year by default if year is not in the request().
$ordersByWeek=Order::select([DB::raw('count(id) as quantity'),DB::raw('week(created_at) as week'),DB::raw('year(created_at) as year')])->when(request('year'),function($query){$query->whereYear('created_at',request('year'));},function($query){$query->whereYear('created_at',now()->format('Y'));})->groupBy(['year','week'])->get()->toArray();
Hopefully this post has provided you with a starting point to start accessing some key metrics from your Laravel project and show you how you can refactor your queries to make them a bit more reusable, especially by using the when() method, instead of having to write separate queries for similar requests.
Build a scalable Laravel apps using event-driven microservices architecture (Pub/Sub), this tool adds the ability for your Laravel applications to communicate with each other using Google Cloud Pub/Sub.
Define your architecture.
First of all, you need to create subscriptions and topics in Google Cloud Platform, or you can use the cli.
Installation.
composer require gdg-tangier/cloud-pubsub
Configuration.
You can define multiple subscribers (queue connections) config in config/queue.php, the app can subscribe to multiple subscriptions.
Here where you can define your subscriptions jobs, events and topics mappings.
Example.
<?phpreturn [/* * GCP Credentials.*/'credentials'=> ['keyFilePath'=> storage_path(env('PUBSUB_CLIENT_KEY', 'client')),'projectId'=> env('GCP_PROJECT_ID'), ],/* * Here where you map events name with Google Pub/Sub topics. * * Means, map each event name to specific Google Pub/Sub topic.*/'events'=> ['event_name'=>'__YOUR_TOPIC_NAME__', ],/* * Here where you can tie the subscription classes (jobs) to topics. * * Means, map each subscription job to a specific Google pubsub topic. * The subscription job is responsible for handling the incoming data * from a Google Pub/Sub topic.*/'subscriptions'=> [\App\PubSub\DummyJob::class=>'__YOUR_TOPIC_NAME__', ],];
Create subscription class.
php artisan pubsub:make-subscriber <Name>
A subscription class will be created at app/Subscribers
Note: To keep the queue:subscribe process running permanently in the background, you should use a process monitor such as Supervisor to ensure that the queue worker does not stop running.
Inertia and Livewire were both born out of frustration with the current JavaScript landscape. Frameworks like Vue.js or React enable us to build incredible user interfaces, but the cost in complexity of building a SPA is incredibly high.
I see Inertia and Livewire as opposite solutions to similar problems. In a nutshell, Livewire enables you to build user interfaces by creating special components in Blade. You don’t need to write any JavaScript unless strictly necessary. Inertia replaces Blade views altogether by returning JavaScript components from controller actions. Those components can be built with your frontend framework of choice.
Livewire is a Laravel library, while Inertia has adapters for several server and client frameworks. That said, this comparison assumes you want to use Laravel on the backend.
More or less JavaScript
Let’s start with Livewire. Livewire is invisible at first. You build your application with Blade like you’re already used to. Need to add something interactive? Sprinkle in some basic JavaScript, or build a Livewire component.
Livewire components can be embedded in your existing views:
They exist out of a plain PHP file to control the data and a Blade file to control the template.
You can bind data and events to DOM nodes using wire: directives like wire:click. Events trigger an HTTP request and invoke their associated handler method on the component class written in PHP.
This allows you to write interactive components without writing any JavaScript. State and event handling gets lifted to the component class on the server.
When it comes to writing JavaScript, Inertia is Livewire’s polar opposite. After installing Inertia you stop writing Blade views altogether.
In contrast to Livewire, you return components from your controller actions.
Inertia will render a component written in Vue (or your framework of choice) matching the component path you specified in the response.
<template><table><tbody><trv-for="user in users":key="user.id"><!-- … --></tr></tbody></table></template><script>exportdefault{props:['users'],}</script>
You handle user interactions on the client like you’re already used to with Vue. If you need to transition to a new page, use the InertiaLink component. This will request a JSON response with AJAX instead of triggering a full page visit, giving your application a smooth SPA-like experience.
<template><table><tbody><trv-for="user in users":key="user.id"><td><InertiaLink:href="`/users/${user.id}`"></InertiaLink></td></tr></tbody></table></template><script>exportdefault{props:['users'],}</script>
Inertia can also be used to fetch fresh data for the current page.
<template><div><inputtype="search"v-model="search"><table><tbody><trv-for="user in users":key="user.id"><td><InertiaLink:href="`/users/${user.id}`"></InertiaLink></td></tr></tbody></table></div></template><script>exportdefault{props:['users'],data(){return{search:'',};},watch:{search(search){Inertia.visit(`window.location.href?search=${search}`,{preserveState:true});}}}</script>
Developer experience
If you decide to use Livewire, you can progressively add Livewire components throughout your application. Data fetching is also managed in the Livewire component PHP class, so it’s separate from your application’s controllers. That means you can embed multiple components on a single page, and they’ll each have their state and lifecycle.
With Inertia you pretty much need to go all-in (at least per section of your application). Data fetching happens in controllers like you’re already used to, but that means you need to think more in “pages” and less in “components” in the context of the client-server communication.
Both of these approaches have a similar outcome: you end up writing a lot less AJAX-only endpoints.
Take a classic data table component as an example. In a traditional application, you’d have a controller action to return the base view and another action to fetch data asynchronously.
With Livewire you’d write a data table Livewire component that takes care of both the template and the data fetching.
With Inertia you’d write a single controller action that returns the view with the relevant data. This works because every subsequent request is already an AJAX request.
Render performance
JavaScript is a hard requirement for Inertia to render anything at all. If you need your server to return a fully rendered document, Inertia is a no go for now. The lack of server rendering changes the initial load experience, and can potentially impact SEO. A server-rendered document will always display faster than one that only renders on the client after all assets are downloaded and executed.
This is a much-discussed tradeoff when talking about SPAs. In the context of an interactive web application, the added load time is often worth it for the optimizations you can do on subsequent renders. Note that the performance penalty for Inertia is a lot smaller than for SPAs. SPAs need to make an additional AJAX request on every page to fetch data, while data is immediately included in an Inertia response.
Livewire is a whole different beast. Since Livewire renders everything on the server, you’ll always have a short time to first meaningful paint. After the content’s downloaded, Livewire will execute its scripts and the page will be interactive. Assuming you’re not loading huge amounts of JavaScript, the time to interactive of Inertia and Livewire are quite similar.
Should I use Inertia or Livewire?
The usual answer to all programming questions in the universe: it depends.
From a personal preference perspective
Aside from the context of your project: if you prefer developing in Vue, React, or another frontend framework, you’ll prefer Inertia. If you love Blade and want to write less JavaScript, Livewire would probably be your weapon of choice. This is, however, a highly subjective measure.
From a technical perspective
If you’re building a marketing-heavy landing page, a blog, or anything else with a higher bounce rate by nature, the longer time to first meaningful paint can hurt. Livewire is a better fit for these. The same applies to pages that must display content without relying on JavaScript.
If you’re building an app it’s a more nuanced decision.
A big selling point for Livewire is that each component has its lifecycle. This is pretty big you have a lot of blocks that need to communicate to the server individually.
Inertia keeps you limited to pages, but that makes the whole thing more familiar and gives you that smooth SPA-like experience throughout your application.
From an onboarding perspective
If you’re already building apps with Laravel and Vue, Inertia feels like a step up from mounting components in Blade views without drastically changing the way you need to structure your application. Livewire’s model is a bigger shift away from the MVC monolith we’re used to building.
Closing thoughts
Keep in mind that this is a very high-level overview of the two. Both have a ton of small features that spark joy in day-to-day development.
One thing Inertia and Livewire have in common: they’re both young and very exciting pieces of technology.
Being a self-taught developer often means learning as you go, but also needing to write solid code on a timeline.
AnyMod is a new service with hundreds of ready-to-use modules (“mods”) that act as a fast starting point for your work: CMS, themes, forms, marketing sections, and more. You can add mods to any site (any tech stack) and they work automatically.
Mods make your work easier by being:
Fast: A page full of mods can load in about 20ms
Automatic: CMS & forms work without any extra setup, etc.
Pre-styled: already responsive and nice-looking, with dozens of free themes
Easy to modify: you can edit code and content directly, with live reload across all your screens
Easy to add: add mods to your site by copy/pasting one line of HTML
All of this means you can build really quickly, whether you’re adding features (like CMS) to static client sites, or integrating with React, Vue and whatever else you’re using.
AnyMod is also a great resource for continuing to learn. Because all mods are open source, you can pop open the code editor and start messing around with a mod to see how it works. Mods are generally very well-written, so you might learn a thing or two.
The live reload is also just really cool: when you change a mod, it instantly updates everywhere you’re viewing it. No additional configuration is needed, and it makes for an extremely fast workflow.
If you’re a self-taught developer looking to continue learning and complete projects quickly with a lot of polish, consider checking out AnyMod. It’s free to use and has a great community of self-taught devs building and sharing mods:
Here’s a short two-part video showing a pretty decent build of a homemade muzzleloading pistol that was created from parts the guy found in a hardware store.
Warning: Turn off the sound… the only audio is some really bad “music.”
About two minutes in, I found myself cringing at the waste, as he cuts the lock plate from the MIDDLE of a large hunk of steel plate. He should’ve cut it from the edge to conserve his material. Please tell me I’m not the only person who thinks that way?
Impressive lock, but questionable mainspring.
I won’t bore you with a blow-by-blow… the video is in two parts but they’re only about 7 and 4 minutes long. Even if you don’t like his methods, it ought to give you some ideas anyhow.
VC fund A16z’s Benedict Evans writes: We are in the middle of a wave of interesting new productivity software startups — there are dozens of companies that remix some combination of lists, tables, charts, tasks, notes, light-weight databases, forms, and some kind of collaboration, chat or information-sharing. All of these things are unbundling and rebundling spreadsheets, email and file shares. Instead of a flat grid of cells, a dumb list of files, and a dumb list of little text files (which is what email really is), we get some kind of richer canvas that mixes all of these together in ways that are native to the web and collaboration. Then, we have another new wave of productivity company that addresses a particular profession and bundles all of the tasks that were spread across spreadsheets, email and file shares into some new structured flow. […] A few years ago a consultant told me that for half of their jobs they told people using Excel to use a database, and for the other half they told people using a database to use Excel. There’s clearly a point in the life of any company where you should move from the list you made in a spreadsheet to the richer tools you can make in coolproductivityapp.io. But when that tool is managing a thousand people, you might want to move it into a dedicated service. After all, even Craigslist started as an actual email list and ended up moving to a database. But then, at a certain point, if that task is specific to your company and central to what you do, you might well end up unbundling Salesforce or SAP or whatever that vertical is and go back to the beginning. Of course, this is the cycle of life of enterprise software. IBM mainframes bundled the adding machines you see Jack Lemmon using below, and also bundled up filing cabinets and telephones. SAP unbundled IBM. But I’d suggest there are two specific sets of things that are happening now. First, every application category is getting rebuilt as a web application, allowing continuous development, deployment, version tracking and collaboration. As Frame.io (video!) and OnShape (3D CAD!) show, there’s almost no native PC application that can’t be rebuilt as a web app. In parallel, everything now has to be native to collaboration, and so the model of a binary file saved to a file share will generally go away over time (this could be done with a native PC app, but in practice generally won’t be). So, we have some generational changes, and that also tends to create new companies. But second, and much more important — everyone is online now. The reason we’re looking at nursing or truck drivers or oil workers is that an entire generation now grew up after the web, and grew up with smartphones, and assumes without question that every part of their life can be done with a smartphone. In 1999 hiring ‘roughnecks’ in a mobile app would have sounded absurd — now it sounds absurd if you’re not. And that means that a lot of tasks will get shifted into software that were never really in software at all before.
We all know that Germans love David Hasselhoff, so it makes perfect sense that the Knight Rider and Baywatch star would appear in a commercial for a German automotive website. The words may be in German, but the humor is universal. Presumably, K.I.T.T. was replaced with a moped due to fuel efficiency concerns.
CEO: I don’t understand why you are recommending blockchain for this application.
Boss: My staff are the experts, but I can explain the basic idea. You see, using blockchain is like losing a necklace on the beach. Then a seagull finds the necklace and takes it back to it’s nest. And we all like data security, don’t we?
CEO: It’s almost as if you are proposing a plan you don’t understand at any level.
Boss: Well, yes, but keep in mind that you wouldn’t understand it even if I could explain it.
CEO: But you’re sure someone on your staff understands it, right?
Boss: Define "sure".
We reported earlier how Dianna Muller made national headlines, and arguably cemented a folk legend status in the firearms community, when she told the House Judiciary Committee “I will not comply” with an assault weapon ban. Di rocked for sure. But equally impressive, in a quite measured performance, Amy Swearer delivered the most important testimony of the entire hearing.
RELATED STORY
WATCH: Dianna Muller Tells House Judiciary Committee ‘I Will Not Comply’
Amy Swearer on the Assault Weapon Ban
During Swearer’s opening remarks, she read a prepared statement that showcased her deep knowledge of the subject. As a Senior Legal Policy Analyst with several published pieces, Swearer clearly conducted exhaustive research on assault rifles. She also has facts on crime statistics and the 2nd Amendment.
Then she simply schooled those in favor of an assault weapon ban.
Swearer gave a compelling argument that previously banned features make rifles safer, not more dangerous. She argued statistics show overwhelmingly that rifles don’t pose a great danger to society. Swearer showed that law-abiding citizens purchase these guns. And they use them for lawful purposes. Finally, Amy Swearer makes a point that AR-15s and the like give law-abiding citizens a chance against assailants.
Above all, Swearer showed the hypocrisy and fallacy of the anti-gun movement. Now let’s hope the politicians will listen.
1. ‘Assault Weapons’ Characteristics Make Them Safer, Not More Dangerous
“The term ‘assault weapon’ does not have one official definition, but typically denotes firearms that have a range of features associated with modern semi-automatic rifles such as the AR-15,” Amy Swearer read from her prepared statement. “It should be noted that the phrase ‘assault weapon’ is not a technical or legal term, but rather appears to have become popular as part of a concerted effort by gun control advocates to manipulate those with limited knowledge of firearms into confusing certain semi-automatic rifles with ‘assault rifles,’ which are functionally distinct and heavily regulated by the federal government.”
We all remember the inept restrictions of the previous AWB, limiting pistol grips, bayonet lugs, barrel shrouds and more. Swearer points out that gun control advocates typically attack such accessories and features. While they in no way change the functionality or legality of the firearm, they sure look scary. But in practice, a ban on these accessories takes away accessories that promote better marksmanship and better control. In effect, it makes the guns less safe.
“In short, proposals to ban ‘assault weapons’ are, for all intents and purposes, proposals to force law-abiding citizens to use firearms that are harder to fire accurately and more likely to cause them injuries, even when being used for lawful purposes.”
2. Semi-Automatic Rifles Not Significant Factor Behind Gun Violence
The attack on semi-automatic rifles shows an incredible level of hypocrisy from gun control advocates. Statistically speaking, AR-15s don’t constitute a problem. If this is really about safety and human life, the numbers point to handguns. However, the left knows that’s a much harder sell. With that in mind, they’ve demonized the black gun, painting it the mass murderer weapon of choice.
“Far from being the weapon of choice for would-be criminals, semi-automatic rifles are statistically the type of firearm least likely to be used for unlawful purposes, particularly compared to handguns,” Swearer said. “Over the last decade, rifles of any kind were definitively used in only 3-4 percent of gun homicides, and it is not clear how many of those deaths actually involved the use of ‘assault weapons’ compared to other types of rifles. The average American is, in fact, four times more lkely to be stabbed to death than he or she is to be shot to death with a rifle of any kind.
“Gun control advocates, politicians, and the media routinely characterize semi-automatic rifles, specifically the AR-15, as the ‘weapon of choice’ for mass public shooters,” Swearer continued. This is objectively incorrect. Over the last decade, more than half of mass public shooters have used handguns alone. Of those who did use rifles, the majority also brought other firearms, such as shotguns or handguns.”
3. Semi-Auto Rifles Commonly Owned by Law-Abiding Citizens, Used for Legitimate Purposes
The left likes to paint black gun ownership as a recent phenomenon. Additionally, gun control advocates often portray the AR-15 as a weapon of war. They say it’s used only to kill innocent civilians by mass murders.
“Over the last several decades, there has been a concerted effort by gun control activists to characterize certain semi-automatic rifles as ‘weapons of war’ that have ‘no business on our streets,’” Swearer said. “Ostensibly, this is to create the impression that the cosmetic features associated with firearms like the AR-15 serve no legitimate civilian purpose, and render a firearm objectively inappropriate for lawful uses like hunting, recreational target shooting, or self-defense. On its face, this is an absurd premise.”
“Moreover, federal law enforcement agencies refer to even select-fire AR-15 style rifles as ‘personal defense weapons,’ Swearer continued. “… It is little wonder, then, that many law-abiding citizens also rely on semi-automatic rifles as their own personal defense weapons, particularly in situations where law enforcement cannot protect the. Far from needing to be better protected from these rifles, law-abiding Americans benefit when they are allowed to defend themselves with them.”
4. ‘God Forbid’
To close, Swearer told the story of a woman who grew up uninitiated to firearms. She went decades before ever handling one, until her daughter took her to the range. They shot a handgun that day. The woman, according to Swearer, proved a terrible shotgun with a handgun from a mere few yards away. But then the woman picked up an AR-15, and she produced “a fist-sized grouping of lead in the center of that target from 20 yards out.”
That woman is Swearer’s mother.
“Now, I pray that my mother is never confronted with a situation where she is compelled to point a firearm at another human being, much less pull the trigger,” Swearer said. “I would infinitely prefer to live in a world where I never have to consider the possibility that someone would threaten her life or the lives of those around her.
“God forbid that my mother is ever faced with a scenario where she must stop a threat to her life,” Swearer continued. “But if she is, I hope she has a so-called ‘assault weapon’ to end that threat.”
