Laravel and VueJS

Full stack development means we create a structure or framework that carries the application data and create views of it to manage resources or client information.

Using Laravel, we are able to progress an applications “back end” swiftly and evolve the database. This means that during a sprint we can add new data to core tables or add new ways to store data.

Using Laravel’s template system, we can rapidly create Views of that data on sophisticated screens that allow user interactions. This is not enough, today’s applications require interactivity and for this we employ the very powerful and fast VueJS framework.

For example: you run a booking system for hotel rooms. You want the end customer to drag and drop features visually into a search listing to find their idea room. This requires a display that interacts both with the data and the user.


Lovely to work with, clean and fast.  Laravel is one of the most popular PHP frameworks for MVC system development.

Developers are encouraged to stay fully up to date with Laravel and pounce on work opportunities.  With Remote Development, we can provide what you need right now, a server, bandwidth and a Laravel account and git repository.  When you are working with Remote Development clients, you can sell our site hosting services.  

How to Specify

The establishment of a system revolves around two core concepts:

  • the data model
  • the view of it that is manipulated by users

To achieve an interactive front-end system, it pays to have a backend that is very clear, a testable data model that acts predictably.

You can of course link in unlimited data to the core of predictable modules, using their individual or a combination of key fields together and attaching unformatted data to that, providing unlimited expansion.

  • The developer has to look at the data model from an inside first perspective.
  • The user wants to explain the view and how it is manipulated by users, often in an abstract or fictional manner.

The trick is to understand the interactions between entities in an abstract way but to not try an explain implementation detail in any way but to explore how the primary elements of the system interact. By defining these interactions, it is possible to make a machine that treats data in the same fashion, although implicit rules are no longer a complication in the process.

It is probably best to define the data elements to increase understanding of the form of the system. Then the front-end (the content of the dash-boards) has some logic behind it. The very basic thing is data.

Or is it better to define data in the abstract pattern afforded by NOSQL style database records. The central part of the database should be expressed in language without difficulty. It is important to enable interactivity to be written without it being stuck in conceptualisation phase.

Why Laravel?

Fourteen years ago I used a remarkable programming tool that implemented many of Unix’s tools like awk, sed and regular expression parsers in a language called Perl.  It also implemented objects but suffered from a philosophy TIMTOWTDI – “There is more than one way to do it.”

In other words, it allowed you to implement processes that altered data in alternative ways and some of them were more expressive, some more “elegant”.  Programmers could boast “I did that in only three lines of code.  Yes, they are really difficult to read, that is a demonstration of how clever I must be.”

In 2004 I found PHP.  Strange language that it was then, version 3 had just become version 4.  Lots of predefined functions, you could make the mistake of thinking it was a functional language.  Like Perl, it was an interpreter.  It was very fast and generally, there was an effort to increase code clarity.  Then Version 5.x arrived and its Object model allowed Inheritance and abstracts like Java.  It had a method of implementing Polymorphism, but it was “proper” polymorphism.

In the last couple of years, it skipped Version 6.x and PHP Version 7.x boasted double the speed of the stable version 5.6.  It was a trouble free upgrade.

Over the years, various “frameworks” sprung into existence, Zend was the best, most comprehensive and allowed you do use pre-written modules to utilise well written code that was stable to do tasks like making a queue system or talking to a database.  Then I learned Symfony and felt like it was a better expression of good coding methods, with excellent tools to more rapidly create systems.  Symfony was created by one person.  He is French but I found that the documentation and path into it was too many examples and not enough reference.  Sometimes hard to find answers or a path into great app development.

And then I discovered Laravel.  It reached version 4.2 when I started but the Version 5.x series of revisions made it a brilliant framework.  Why?  Because its author, Taylor Ottwell is a brilliant developer who created modules that are very well written and documented.  Because the Laravel documentation was fastidiously prepared, clear and factual.  Because its command line tool, Artisan, had very useful functions.  Because you could create a Laravel project with “laravel new project-name”, just like that.

And it used the Symfony component infrastructure.  So you can easily create a test database from artisan commands, and migrate new features into your database progressively.  Because you can create test data with database seeding and painlessly rebuild your tests.  Because it implemented PHPUnit so Test Driven Development (TDD) was painless.  Because it integrated successfully with socket-based event handlers and the also elegant Javascript framework VueJS to create systems where client browsers could update each other (dashboards which are live updated were now possible).

And now I have focused on Laravel and its supportive cast of helpful documentation, online training, where features and benefits are easily adopted and each version adds useful features.  We are now up to Verison 5.5.

It is a work of artistic genius.

BDD Framework for WordPress

An end-to-end test detects issues whenever there is a major system change. In software development, with every release, a battery of unit tests must pass or business can be lost.

Yes, software testing is difficult. It sounds like it is reactive but it is preventative.

Do you have a defined end-to-end test path you can implement in a code replay – a commercial one is Selenium – you can make it record your “happy path” from home-page to shop order to basket acceptance to payment page, do you have certainty that the new plugin you are testing will not break something you rely on?

The reason for code isolation is to prevent this, but WordPress operates in a global namespace – know that the basics are not broken by a plugin update. If it is a server-side script, it can for instance test certain URLs work (return 200 OK instead of 404 or more to the point when it returns a 500 or a 502 HTTP error in a plugin function you may not know something is failing).

With a “headless-browser” on the server, we can automatically test it is working. It could simply be an app that tests URLs that you can visit, or paths you can get 200 OK responses for – rather than a WordPress plugin that has overhead on every request.

Principes of Agile

Principles behind the Agile Manifesto

We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective then tunes and adjusts
its behavior accordingly.


Git workflows

Confused about how to work with Git? You soon will not be confused, it is a well designed and versatile essential tool for remote development.

1. Comparing workflows

2. Gitflow architecture (also covered in article 1.)

Remote Development uses the Gitflow branching model. Simply put:

0. Initial steps
git init
git remote add origin
git fetch

1. Developer checks out Master branch
git checkout master

2. Developer checks out a new feature branch
git checkout -b feature/my-new-feature

3. Developer work on and commits to feature branch

4. Developer pushes the feature branch to origin

First time:
git push -u origin feature/my-new-feature

git push

5. Developer issues a pull request for the feature branch into Master


The admin maintains the git repository, and collects ssh-keys (public) from each developer so that they can login to without a password.

The git admin checks the new feature branch, and notes any migrations that are required. When the PR is approved it is merged into the staging branch. Developers can now check their branches have been correctly merged into the staging branch and flags the branch as releasable if it does not cause issues.

At the end of the sprint, the admin builds a new server instance for live and switches to it after applying any updates. The staging branch is now merged with the Master branch. Developers can continue to work in their feature branches by merging master into their branch on the new sprint.

ANY FAILURE along the way is immediately notified to the admin so it can be fixed before it becomes a major exercise. Remember keep your branch atomic and up to date with the latest master.


Provided that developers work on separate concerns conflicts are kept to a minimum. Conflicts are resolved by the Admin using the simple “important branches first” principle.

Solo Developers

These rules apply to teams. They are also adhered to for developers who are single-handed on a project. It allows control, accountability, backup and many other advantages.

Action Speak

“Next, we are going to add the ability of the user to …” promises the website.

What do you think? Is the promise of something new necessary?

Or a developer raves, “the next version will increase sales with this very smart new widget”.

Can you use something promised before it is released?

Or a client asks “Will you get this, and this … oh, and this … done by the deadline?” – the correct answer is “no”. A promise is not something that has much value when it is not followed by action. You hear it all the time, “we are going to…”, “the next version will…”

How do we do better?

We only talk about what we have done, what is included in a Sprint, and then only after we have tested it on an integration test on the staging server. If it fails, it fails. We want failure during testing because it means we have coverage. There is no point in releasing code to deliver on a “promise” if, in the end, it is not going to work. There is far more pain for releasing code that is not yet quite right. does not make promises (except in Javascript code). We plan to deliver integrated functionality when it is ready and tested. We plan what is in our Sprint and then it is our own professional pride that delivers those results.

Okay, we do not know what the client will ask for during a Sprint, we add these new ideas to the next Sprint rather than delay planned and agreed to stages of a delivery.

Instead of raving about how it will look in the future, deliver results you have agreed to now. Stable, proven results. Then your client can rave about them for you.

Making Youtube video responsive

This solution was pioneered by Thierry Koblentz and presented on A List Apart in 2009: Creating Intrinsic Ratios for Video. With this technique, you wrap the video in another element which has an intrinsic aspect ratio, then absolute position the video within that. That gives us fluid width with a reasonable height we can count on.

.videoWrapper {
	position: relative;
	padding-bottom: 56.25%; /* 16:9 */
	padding-top: 25px;
	height: 0;
.videoWrapper iframe {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;


Development Story

Adding new kinds of products to Remote Development

Products had been kind of rushed and too specifically sewn together while getting the latest version of VueJS working for me instead of against me!

It is tricky to debug but very informative, it basically is telling you if you have configured it incorrectly, so it produces only working Javascript that effectively abstracts to make a logical component architecture.  Sometimes you have to fiddle to get things right, like any architecture you have to get used to the tool set.

We went from three or four basic products to being able to add products to generate enquiries without much configuration and importantly by only creating the product and its membership in certain groups.  Configuration changed things.

Next, we have to think about a sales presentation – the component architecture is now taken to its elemental pieces – they can be organised into prettier boxes without breaking everything!