In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:
Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
Minimize divergence between development and production, enabling continuous deployment for maximum agility;
And can scale up without significant changes to tooling, architecture, or development practices.
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Herokuplatform.
This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.
Our motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring.
Who should read this document?
Any developer building applications which run as a service. Ops engineers who deploy or manage such applications.
and truly it has always been here. More recently it seems to be coming into broader awareness and that’s a good things. It is when we collectively come together to build and improve our communities at the grassroots level, do we see the most progressive and productive processes and policies arise among the community because they all collectively are interested in a Best for All choices that support and advance everyone’s interests.
We have interests, skills, abilities, talents and gifts. How we express them in the world is how we give back to the world that we live in and on.
We all have the ability to create and contribute and give back to our community that we live in.
How, When, Where and What we do — be aligned with our personal peace and for the greatest benefit of all including yourself.
Barrier-free, Universal design, Safe and Open. Is it possible?
In an interview with an O/S2 magazine back in the day, Mike F. Cowlishaw, the father of REXX, said that he always preferred to hire electrical engineers because they designed their solutions keeping in mind minimal prototyping was available. As where, software engineers just kept ploughing away on problems and iteratively improved their code. Programmers from a hardware background developed more sound code their 1st go-round or more frequently than their purely software oriented/taught peers.
You’ve been hearing the buzz for a while now. Bitcoin, and there’s a whole slew of others, well because that’s just what happens with what appears to be a great, no wait, an amazing idea, generate your own money by becoming involved in Bitcoin “mining” or any other cryptocurrency for that matter.
Over on Bitcoin.org‘s site they list the minimum requirements as follows:
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Desktop or laptop hardware running recent versions of Windows, Mac OS X, or Linux.
145 gigabytes of free disk space, accessable at a minimum read/write speed of 100 MB/s.
2 gigabytes of memory (RAM)
A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second
An unmetered connection, a connection with high upload limits, or a connection you regularly monitor to ensure it doesn’t exceed its upload limits. It’s common for full nodes on high-speed connections to use 200 gigabytes upload or more a month. Download usage is around 20 gigabytes a month, plus around an additional 140 gigabytes the first time you start your node.
6 hours a day that your full node can be left running. (You can do other things with your computer while running a full node.) More hours would be better, and best of all would be if you can run your node continuously.Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running
Line 2 is the bomb. 145 gigabytes of free disk space, accessible at a minimum read/write speed of 100 MB/s. Yes you read that correctly. Enough space for an operating system. I will get back to that later.
200 Gigabytes a month. So over an average 30 days that’s 6.66* Gigabytes per day outbound.
Just a few thoughts for now. Will add more later.
—Update March 14, 2018
Maybe you do not want to do so much “heavy lifting” to get into Bitcoin and cryptocurrencies.
Here’s one possible option I recently was told about.