JavaScript Automation with Gulp

As web developers, we sometimes find ourselves repeating the same tedious tasks again and again. If you consider how much time is wasted by running a build command or hitting refresh on your browser, you will realize that you can be saving a lot of time. Additionally, by automating your processes, you can stay focused on the task at hand instead of temporarily leaving “the zone” (your state of productivity).

In this JavaScript automation tutorial, you will learn how to automate your design and development process with Gulp. If you are more design-oriented, I encourage you to overcome any fears you have and to read on. On the other hand, if you are a developer you will be able to sweep right through this once you understand the logic behind it.

Gulp is a build system that employs Node.js’s streams to implement an asynchronous source-destination approach to automation. Everything is written in JavaScript, so it is easy for anyone with intermediate coding knowledge to get started. A Gulp build process consists of a collection of watchers and tasks. Additionally, the community behind Gulp maintains a huge plugin directory within npm which helps accomplish any task from concatenating JavaScript to creating icon fonts from SVGs.

Alternatives to Gulp

There are plenty of alternatives out there, most of which have spawned in the past couple of years - the most notable one being Grunt. The contest between Gulp and Grunt will never have a clear winner, since they both have their pros and cons, hence I will avoid delving deep into that. In a nutshell, Grunt’s heavy reliance on config is what steers people towards Gulp’s JavaScript approach. In the meantime, native GUI implementations such as Koala have gained some ground, mostly from people that withhold getting into coding. However, with the bundled applications it’s impossible to reach the level of customizability and extendability that Gulp offers.

Process Automation Fundamentals

Plugins are the means through which gulp accomplishes each process. Plugins are installed through npm and initiated using “require”.

Tasks

For Gulp, tasks always have a source and a destination. In between them lie the pipes that call each plugin and output the transmuted results to the next pipe.

Globs

Globs are wildcard patterns that refer to files. Globs or arrays of globs are used as inputs in task source.

Watchers

The watchers watch the source files for changes and call tasks whenever a change is detected.

gulpfile.js

This is the JavaScript file that the “gulp” command points at. It contains everything from the tasks to the watchers or other pieces of code used by tasks.

Read more

Slim PHP MVC Frameworks with a Layered Structure

Fat controllers and models: an inevitable problem for most large-scale projects based on MVC frameworks such as Yii and Laravel. The primary thing that fattens controllers and models is the Active Record, a powerful and essential component of such frameworks.


The Problem: Active Records and Its Violation of the SRP

The Active Record is an architectural pattern, an approach to accessing data in a database. It was named by Martin Fowler in his 2003 book Patterns of Enterprise Application Architecture and is widely used in PHP Frameworks.

Despite the fact that it is a very necessary approach, the Active Record (AR) pattern violates the Single Responsibility Principle (SRP) because AR models:

Deal with querying and data saving.

Know too much about the other models in the system (through relationships).
Are often directly involved in the application’s business logic (because the implementation of data storage is closely linked to said business logic).

This violation of the SRP is a good tradeoff for rapid development when you need to create an application prototype as soon as possible, but it is quite harmful when the application grows into a middle or a large-scale project. “God” models and fat controllers are difficult to test and maintain, and freely using models everywhere in controllers leads to tremendous difficulties when you inevitably have to change the database structure.

The solution is simple: divide the Active Record’s responsibility into several layers and inject cross-layer dependencies. This approach will also simplify testing because it allows you to mock those layers not currently being tested.

The Solution: A Layered Structure for PHP MVC Frameworks

There are five primary layers that we’ll cover:

• The controller layer
• The service layer
• DTOs, a subset of the service layer
• View decorators, a subset of the service layer
• The repository layer

The Controller Layer

Modern MVC frameworks like Laravel and Yii take on many of the traditional controller challenges for you: Input validation and pre-filters are moved to another part of the application (In Laravel, it’s in what’s called middleware whereas, in Yii, it’s called behavior) while routing and HTTP verb rules are handled by the framework. This leaves a very narrow functionality for the programmer to code into a controller.

The essence of a controller is to get a request and deliver the results. A controller shouldn’t contain any application business logic; otherwise, it’s difficult to reuse code or change how the application communicates. If you need to create an API instead of rendering views, for example, and your controller doesn’t contain any logic, you just change the way you return your data and you’re good to go.

Read more...