Freek.dev

In a post on his Medium blog Cameron Nokes explains the two most important processes in any Electron app: the main process and the renderer process.

Central to Electron is the concept of two or more operating system level processes running concurrently — the “main” and “renderer” processes. Dealing with multiple processes is new territory if you’re coming from browser Javascript land. It was definitely a paradigm shift for me initially, and working with multiple processes may mean you make different design choices in your app that you wouldn’t otherwise.

https://medium.com/@ccnokes/deep-dive-into-electrons-main-and-renderer-processes-7a9599d5c9e2

Read more

On his blog Frank De Jonge, member of the PHP League and creator of Flysystem, explains a cool pragmatic solution how to ensure queued processes for the same user complete in the right order.

The use of multiple workers allows for much higher throughput, but it also allows for race conditions during processing. When messages for the same user are sent to different workers, handling order can no longer be guaranteed. Therefore we have failed to fulfil our business rule.

If we were able to ensure every message from the same user were sent to the same worker, the worker could ensure those messages are handled in order while the system as a whole would still benefit from the degree of parallelism. But how do we make this happen?

https://blog.frankdejonge.nl/parallelise-synchronous-business-processes/

Read more

Jens Segers, developer at Teamleader and author of the popular Optimus and laravel-mongodb packages, wrote about an alternative to controllers.

Let me introduce you to request handlers. The concept is very simple, yet very unknown to a lot of PHP developers. A request handler is basically a controller, but limited to one single action. This concept is very similar to the Action-Domain-Responder pattern which was proposed by Paul M. Jones, an alternative for the MVC pattern that focuses on a more clear request to response flow for web applications.

https://jenssegers.com/85/goodbye-controllers-hello-request-handlers

Read more

If you haven't heard about event sourcing or are unsure about what it is, Barry O Sullivan has got you covered. Recently he wrote up a blogpost that explains it very clearly.

Event Sourcing (ES) is opposite of this. Instead of focussing on current state, you focus on the changes that have occurred over time. It is the practice of modelling your system as a sequence of events. ... It solves all the big problems our team has faced when building large scale distributed business software. It allows us to talk to the business in their language, and it gives us the freedom to change and adapt the system with ease.

https://dev.to/barryosull/event-sourcing-what-it-is-and-why-its-awesome

Read more

Jeff Ochoa wrote a nice walkthrough of one of Laravels lesser known functionalities: pipelines.

Basically, using laravel pipelines you can pass an object between several classes in a fluid way to perform any type of task and finally return the resulting value once all the “tasks” have been executed.

https://medium.com/@jeffochoa/understanding-laravel-pipelines-a7191f75c351

Read more

At Spatie, we're building a multi-tenant app. Seb figured out a great way to handle theme based views.

Laravel allows you register a view vendor namespace which points to a specific directory containing Blade files. This feature is intended for package development, but it's a perfect solution to our problem.

By registering a namespace with the current theme's location, we can drop all the dynamic parts of our view names when we're calling them.

https://sebastiandedeyne.com/posts/2017/theme-based-views-in-laravel-using-vendor-namespaces

Read more

Josh Justice gives some solid advice on how to pick the right language for your next projects.

So to ask the question “should I use an OO or FP language (or style)” is to skip several steps. I think a better series of questions are: First, what properties would be beneficial for your application to have: concurrency? Immutability? Encapsulation? There are a lot of things you won’t know about your application at first, but you can at least know if it will be a backend app, JavaScript browser app, or native mobile app; if it will be CPU-bound or IO-bound; and if it will process data inputted by humans or automatically generated by machines. All of those factors can influence which properties you need.

Once that’s decided, the next question is, in a given language, are those properties guaranteed, easy, difficult, or not realistically achievable?

http://codingitwrong.com/2017/07/27/language-features-and-code-properties.html

Read more

At this year's Laracon US Adam Wathan gave a talk titled "Cruddy By Design" on how to structure your controllers better. After the conference he published a new GitHub repo that contains the demo app he refactored on stage. The 4 main tips to improve your code come as PRs on the repo with a full description on why the change is valuable. Very cool stuff.

Using this convention as a "rule" is a good way to force yourself to keep your controllers from becoming bloated, and can often lead to learning interesting new things about your domain.

For the presentation, I put together a demo app called "CastHacker" that showcases podcasts about software development. It's not a "real" app by any means (lots of imaginary features, no tests, etc.); it's just enough code to demonstrate the concepts from the presentation. Feel free to clone it and play with it locally if you like though.

I've written up each refactoring I shared in the presentation as a detailed pull request.

https://github.com/adamwathan/laracon2017

Read more

Matthias Noback explains the value of singleton objects: when used properly they can make your code more developer friendly.

I'm not advocating the use of façades and helper functions per se. I assume they may have good use in specific parts of your application (just as the Laravel documentation states, by the way). My point is that, as long as you build into your libraries both options, you can offer a great developer experience, providing an out-of-the-box working solution of a useful service, which can still be used in a project that uses dependency injection everywhere.

https://php-and-symfony.matthiasnoback.nl/2017/05/the-case-for-singleton-objects-facades-and-helper-functions/

Read more

Joshua Bemenderfer gives a nice overview on the ways Vue components can communicate with each other.

There are several methods that can be used for inter-component communication in Vue.js. Normal props and events should be sufficient for most cases, but there are other methods available at your disposal as well.

https://alligator.io/vuejs/component-communication/

Read more

There are multiple good ways to pass data from Laravel to Vue. In a new blogpost Jesse Schutt covers all the options.

It has been helpful to think of my application as "layers" or separate sections of code each with varying responsibilities. I like to think of Laravel as the intermediary between the persistent data in the database, and the Vue components comprising the front-end of the app.

Though the boundaries between Laravel and Vue may appear unclear at the outset, the only way one can know about the other's data is if it is explicitly passed. Blade templates implicitly know a lot about the application, but Vue operates on a different layer, so it only knows what we tell it. Fortunately, there are a number of ways to provide Vue with the data it needs.

https://zaengle.com/blog/layers-of-a-laravel-vue-application

Read more

Subhas Dandapni wrote an excellent overview of the most common over-engineering mistakes.

Few things are guaranteed to increase all the time: Distance between stars, Entropy in the visible universe, and Fucking business requirements. Many articles say Dont over-engineer but don’t say why or how. Here are 10 clear examples.

https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8

Read more

Keith Adams, Chief Architect at Slack, gives some background on how PHP is used at his company.

Slack uses PHP for most of its server-side application logic, which is an unusual choice these days. Why did we choose to build a new project in this language? Should you?

Most programmers who have only casually used PHP know two things about it: that it is a bad language, which they would never use if given the choice; and that some of the most extraordinarily successful projects in history use it. This is not quite a contradiction, but it should make us curious. Did Facebook, Wikipedia, Wordpress, Etsy, Baidu, Box, and more recently Slack all succeed in spite of using PHP? Would they all have been better off expressing their application in Ruby? Erlang? Haskell?

https://slack.engineering/taking-php-seriously-cf7a60065329

Read more

Earlier today laravel-news.com, the official Laravel news source, received a new coat of paint. In a post announcing the launch Eric shares how the site works behind the curtains.

During this move, I have redone the way the site is powered. Previously it ran on WordPress with a custom theme I put together, it worked fine but added new features, and sections became harder and harder, and I wanted the ability to use what I am comfortable with, Laravel. However, I didn’t want to give up the media library and editing experience of WordPress.

So to have the best of both worlds I kept the old site on WordPress and used the WP Rest API paired with the Laravel Scheduler. This allows me to automatically sync data from WordPress into my database without having to rebuild an entire CMS admin area. I have the same setup for the podcast section, and it hooks into the Simplecast API to pull those over.

https://laravel-news.com/2016/08/welcome-to-the-next-version-of-laravel-news/

I sure would like to read a tutorial on how that sync works in detail.

Read more

Frank De Jonge, member of the PHP League and author/maintainer of Flysystem, was facing a world of pain with ElasticSearch. Luckily the story has an happy ending. Read all about his journey on his blog.

For a client project we are using ElasticSearch (ES) as one of our read-models. The use-case was pretty straight forward and the amount of data was super small. However, our problems were pretty big. It got to a point where we had to reboot our cluster periodically to prevent it from crashing. So, what was going on? Let's dig in.

https://blog.frankdejonge.nl/how-a-20mb-data-set-brought-down-a-14gb-elasticsearch-cluster/

Read more

Nicolas Widart, author of Asgard CMS, created a new package called laravel-modules that can help splitting up a large Laravel app in modules.

On his blog he published an introductory post.

Just imagine having a medium sized application where everything is in the `app/ù folder, worse, every model is in the root of the app folder! At some point you will spend a lot of time looking for things because everything is bunched together.

This is what being modular is trying to resolve. You split of the business logic into different parts, which belongs together. If you're into Domain Driven Design, you can consider a module an aggregate.

Every module has its own routes/controllers/models/views/business logic/etc. Meaning every module contains a group of classes that all are related to each other in some way.

https://nicolaswidart.com/blog/writing-modular-applications-with-laravel-modules

Read more

Jerome Dalbert on his blog:

Splitting your Rails controllers when they have a very specific scope, too much logic, or too many mixed concerns can have a lot of good side effects in your code.

It doesn’t mean that you never abstract. It just comes later down the road. At some point some logic needs to be shared by several controllers. Sometimes even a splitted controller with only one public method gets too big. Et cetera. This is where concerns, model methods, possibly background jobs, and even sometimes service objects (hopefully not too many) come into play.

The more your app grows, the more time you will need to spend to understand it, no matter how clean the code is. But splitting your controllers makes things easier.

http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/

Read more

Phil Sturgeon provides a good explanation on the why and how of middlewares in PHP.

Recently there has been a lot of buzz about HTTP middleware in PHP. Since PSR-7 was accepted, everyone and their friend Sherly has been knocking out middleware implementations, some of them stunning, some of them half-arsed, and some of them rolled into existing frameworks. HTTP Middleware is a wonderful thing, but the PHP-FIG is working on a specific standard for middleware, which will standardise this mess of implementations, but some folks don't seem to think that would be useful.

Let's look into middleware a little closer, to show you why it's something to smile about.

https://philsturgeon.uk/2016/05/31/why-care-about-php-middleware/

Read more

Organizing code is a core skill for software developers and as with all skills the most effective way to improve is to reflect on your previous choices and the fallout from them. There are a wide array of different strategies for organizing code and learning to recognize both the useful and the dangerous ones is very important.

Read more

Tony Messias on the madewithlove-blog:

The other day I was listening to the FullStackRadio episode 34 which is about dealing with dependencies in Active Record models. This is a very interesting topic and they suggest a few solutions for it. I liked the suggestions and I tried to implement it differently (first try and second try).

After that, I decided to talk to my colleagues about the design implementations. And they asked “why not implementing it as a command?”. At first sight I was a bit reluctant, because I’m starting to think applications are getting more complex then it really needs. Then I decided to implement it and the end result was the best one to us. Let’s discuss it a bit.

Read more