Software tailored for your business
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.
The establishment of a system revolves around two core concepts:
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 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.
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.
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.
– http://agilemanifesto.org/principles.html
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.
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@softwareantelope.com/project-repo.git
git fetch1. Developer checks out Master branch
git checkout master2. Developer checks out a new feature branch
git checkout -b feature/my-new-feature3. 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-featureSubsequently:
git push5. Developer issues a pull request for the feature branch into Master
Simple?
The admin maintains the git repository, and collects ssh-keys (public) from each developer so that they can login to git@softwareantelope.com 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.
Conflicts
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.
“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.
RemoteDevelopment.co.uk 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.
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!
Laravel is our preferred development framework at Remote Development. Making Microservice APIs is often a useful way to allow software projects to proceed in a more isolated, disciplined and less bug-prone fashion.
The skill set addressed by this tutorial is important for all Laravel full stack or back-end developers. It is very basic and only starts to address the issue in the Routes and Controllers section. If you are new to Laravel, use the top link, it gives a basic grounding in the framework.