Process

This is simply a living method for DIY programmers aimed at eliminating latency in production.

"Your software should be agile, not your process. Your process should be "disturb as little as possible". Either you code or you get out of the way and take responsibility for the people that code by slowing them down just enough to trust them."

1. Guide

1. µSOA¹: One developer per microservice.² HTTP is the only interface between everything.
2. Agile: You need to be able to hot-deploy everywhere because you'll want to work with others remotely at high iteration speeds.
3. Architecture: The developer is completely free to choose any software (languages, tools, persistence etc.) of the service.
4. Turnaround: Maximum build & deploy time on live is how long it takes for you to switch to the test client. (1-2 seconds)
5. Ownership: The developer owns and is responsible for the service everywhere at all times.
6. Errors: Should be pushed from each live client to the service developers smart watch in realtime.
7. TDD: Test only what makes development slip due to complexity.

2. Manage

1. The data -producer, -consumer and developer trio have 1 minute per person remote**³** daily yester/morrow meetings.
2. No other mandatory scheduled meetings.
3. You should be able to work from home.
4. If you finish quicker than expected, you own that remaining time.
5. No documentation. Automatic API.

3. Store

1. If persistence can be a file, make it a file.
2. If you need: * Index;
   • Text: use the file system.
   • Number: use memory. //TODO: Build number index for ROOT. * Relations; use a file- (link) or folder- (meta) graph. * Full word search; link! //TODO: Make file index editable for ROOT.
3. Your persistence should use HTTP.
4. Synchronization of unique ids between services is either random, local or remote: * Random means you have large enough unique ids for collisions to be infinitely rare: This is decentralized. * Local means your service owns and distributes it's unique ids: This is distributed, the other services will have to store id origin. * Remote means your service gets the unique id from another service: This is centralized, allows for one unique id across a larger network of services.

4. Develop

1. Each module describes it's own use: f.ex. if you browse to /login you should be able to login! (model, view and controller)
2. Use NIO async for: * Server response; if you have high iowait or realtime services. * Client requests; if you can concurrently build the response to reduce latency. * For top performance and speed FUSE both.
3. Use the same development keyboard and OS everywhere.
4. Use JavaScript for modularity, over; chunked body response, CORS-XHR or even XSS (careful with the cookies though).
5. Use SVG, they work in every browser now!

5. Host

1. Two subdomains per service, virtually hosted and distributed. * If you have more than test and live you are over engineering. * On same machines if project is new or only one developer. * Port 80 only.
2. All services for one developer should run on many machines (for redundancy, scaling, backup) and call each other vertically (localhost).
3. Sand-boxing is better than virtualization (share memory and CPU).
4. All completely async, do not use legacy sync databases like MySQL, Oracle or Postgres.
5. Increase socket memory if you serve large files.
6. If it makes economical sense to use Akamai your software is probably bad.
7. DNS Roundrobin across backbones allows for 100% uptime. But this requires a new kind of real-time distributed persistence.
8. Install, configure, monitor and notify yourself; even the hardcore stuff.
9. AWS is "stable" but very expensive, the credit system is frustrating and the position of the regions are bad. I now use Google Cloud: host.binarytask.com

6. Controversial

1. I would stay away from HTTPS and websockets. I could argue why, but it would be a waste of time. Instead I present the solutions I built that replaces them: I hash the password with a one-time salt (RFC2289) in the client and I use simple HTTP comet-stream for real-time data.

¹ Micro Service Oriented Architecture an evolution of Microservices and SOA.
² If two people choose the exact same tools they can work on the same service; the whole point is that nobody should have to compromise with their tools. The work should not be to configure others tools, but to design a specific product with clear separation of responsibilities between developers.
³ Jason Fried, We Work Remotely, Mandy Brown, remoteok.io, gitlab/remote.