Category: technical

Posted on

Being a service centre or a nerd club?

It is quite hard to map the direction when you create organically. But the two central themes of RD are: Service and Technical brilliance.

Service

  1. Our services are more in touch with the client
  2. Our services are more flexible and agile
  3. It is not expensive to change your ideas
  4. It is not unknown for us to start again and reinvent badly shaped wheels

Technical Brilliance

  1. We can adapt our software to add any clients requirement into an option
  2. We love agile as it keeps the work variety and intensity of technical application very smart
  3. Change gives us opportunities to refactor
  4. Smart frameworks make Project level refactors far easier to consider

There is a fit between these objectives.

Therefore are products are:

Intro Site: a one year excercise using WordPress with the Client defining what they want

which then progresses to either:

  • CMS Site: a hosted continuation of the Intro site
  • Development Site: we either develop to staging for a commercial client OR we extend the WordPress CMS with a sub-domain hosted Laravel instance (or GOlang/NodeJS based server depending on the team).

Development Sites are hosted on a Cloud.   CMS sites – we use shared hosting for email and DNS as the support is essentially free.  NS point at the CMS host.

The www domain can be switched to point at the Cloud site easily with an A record.

Additional Products

We can add new products by adding new Enquiry types.  The proposal can only propose CMS/Dev solutions – so some Enquiry types include an Order form bypassing the proposal system: So an Enquiry->Proposal->Order->Project can be Enquiry->Order->Product instead (i.e. for SSL certs, etc).

 

 

Posted on

Laravel API

RESTful Laravel API Tutorial

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.

Posted on

WordPress: plugins

A list of what we install with WordPress images:

  • Jetpack (free)
  • Akismet (free with wordpress.com registration)
  • WooCommerce (free)
  • Stripe for WooCommerce (client must start a stripe account)
  • WooCommerce Subscriptions (£150)
  • Ultimate Member (free)
  • UM Subscription (£250 ?)
Posted on

VueJS: Revisiting components

One of the things about software development you do not reallse until later is now important well thought out encapsulation and clarity is when you revisit old code.

One factor is predictability, what else can the programmer have possibly meant?  One of the good artifacts of programming is the contained universe and in a Vue JS or Angular component, you have just that.  An entity that defines itself in strict terms: an entity that is clear in its meaning and intent.

Because it follows the rules, you find it remarkably easy to understand what the component is and what its interface with the outside is.

That is all you want to know.   Vue JS makes designing interactions between front end input components that make sense in their own light.  Contained predictability is an asset in exposed interfaces.  Vue JS intervenes just enough that Javascript starts to make sense.

 

 

Posted on

Ideas section

Recording a methodology section of WordPress plugin installs.  Anyone can contribute pages: in menu

Anyone can contribute pages: in menu Methods: Relationships: Developers: ideas


Simple format is:

* Audience
* Idea
* How tested
* Conclusion
* Recommendation

Posted on

Software Construction

Why not build the front end using WordPress with Angular. And build the backend with Laravel and VueJS. Or, the other way around? What do this even mean?

What do people mean by Back-end and Front-end in software development? It can be M vs VC or it can mean a database vs a display terminal, or it can mean the communications relationship responsibility and rules you apply to open channels between modules. Lost you yet?

Software can be hard to maintain if it is constructed in a monolithic fashion.

Or, software can comprise individually constructed components that interact, supported by backend state recording and other processes. Messages are the bits of memory flying between the clusters of logic. The reason the “dashboard” metaphor gets so much use if that it reflects this model. We want to see and control the software from one place.

The software we use to create environments that are constructed in this way are more resilient to change as they are always being made to work properly with a current set of scheduled changes.

“Reusable software” is a bit of a scam. It is not that you can literally reuse the universe of software assuming everything perfected needs to be forgotten about and simply linked to in various documented service connections. It is in the design of a software module: a concept of code reusability is important, but you do not have to do it just for the sake of it. Sometimes it is better to write with other priorities: speed, results, accuracy, and testability may be important, but generally will become less of a problem if you develop with usability as the primary objective.

We segment software into MVC patterns and the like because we know they fit the functionality we are looking for, abstractions are useful as we can fit them together.

Posted on

Agile

Agile Software Development was developed by some of the best minds in our industry. Years ago. Since 1998 it has become the way to do things.

Short Iterations
We use 10 day sprints (over two weeks). During each Sprint, we follow a sprint plan. We need two basic sprint plans for the initial sprint for a CMS site or a Development project. These can be patterns, something like:

CMS

  • collect design components from the client using survey page*
  • Create WordPress Instance, connect to domain and email addresses
  • Using a base template* and the core set of plugins* create pages and menus for the Core Items*
  • Liaise with client to collect core information for Contact us and About us page

Development Project

  • Get basic info from the Client
  • Instantiate base site on Cloud
  • Implement User Registration and Auth
  • Client specific steps…

These are not complete! Discussion with the client over Slack is required for 2 – 4 days to flesh out the project.

*there are common elements we can write to make our lives far easier and expand on what we can implement during the first sprint. Each item we develop, we share across the network so that we have constantly rising standards of delivery for that all important first sprint.

TDD (Test Driven Development) – Laravel has an excellent TDD method. Development Projects benefit in quality and speed by using TDD. 100% test coverage is the goal with TDD. It is best practice. If you develop without TDD, then you will spend more time debugging when adding a new feature later.

Sprints – Each ticket on Trello is in a subject column. Each ticket has a label which has a status. These are

Research
Concepts
In DESIGN
ACTIVE
DONE
BUG

When a ticket is done, it stays around until the end of the sprint, and then it is Archived. We do not resurrect a ticket, we create a BUG ticket if the problem arises in a new Sprint or reset the DONE flag if it is not really complete.

Tickets
Each ticket you pick up at the Scrum meeting – you complete that day. Each ticket is given another tag during Sprint Planning which is simply a projection of how many hours the ticket can be done in. This is a planning expectation and helps us organise work. Each ticket is completed with QUALITY first, meaning the deadline is not as important than it is completed professionally and forever. Each Developer has a Label which is used to assign the task.

Example

Scrum
Every day at a strictly appointed time, the team review the Trello board over a Google Hangout. Get your coffee before the meeting, and anyone who does not join the meeting on time will get assigned work. Anyone at the meeting assigns their own work. If work is not completed from the previous Scrum, then it is continued and NO NEW TICKET can be assigned. If it is near the end of the Sprint, other developers may collaborate but most tickets are the singular responsibility of the assigned developer. If you want to claim a share of the reward, then you have to do the work!

Posted on

A new Developer

Initialisation

When a new developer joins our team, these steps must be completed.

1. The developer must fill in their basic profile and upload their CV as a PDF.
2. Create full.name@remotedevelopment.co.uk and forward it to their email address.
3. Invite to Slack and welcome them with a conversation.
4. Invite to Trello and get them to register BUGS after reviewing the LIVE site app.
5. Github TBA
6. Google Hangouts TBA

The developer should now be ready to be invited to projects.

Trello

Developers can originate tasks for the LIVE or CMS sites by adding cards

The red label (if you can not see the caption, click on one) ACTIVE – there should be one per board (per application) – this is the Agile method – only one job is done at once – so if you originate a card – you do not set it as ACTIVE unless there are none set as active and it is urgent. That way it is clear what the Developer is working on right now.

The Remote Development board is an example of an active board. Each RD project gets its own board.