@charles_merriam
Nothing here yet.
Nothing here yet.
No blogs yet.
There's unusual site I read: slideshare.net. I search for the keywords I care about (Python, React, Node, JavaScript) for presentations in the last seven days. It provides information in a dense form, rather than just entertainment. There might be five new presentations on Node in a week, takes about two minutes to look through, and usually has insight.
At this risk of sounding old, this feels like repacking all the ideas from thirty years ago about lowering coupling and raising cohesion of services. Serverless; microservices; Enterprise Java Beans; CORBA services; Remote Procedure Calls; or even RESTful interfaces are this idea that, for the subset of problems possible, the right answer is to make a tight, highly cohesive, low state or stateless block of code. The less callers need to know about blocks of code, the better. Also, the less the blocks code need to know about anything but themselves, the better. Some problems are trivial, leaf nodes of your call tree: accept a login token; get the product name given a product id; etc. These are stateless, short-lived, and call nothing. Some are orchestrating calls, but can be tricked into single chains of state. Mostly, its all about good design. Stateless appears to just emphasize the value of having no or trivial state and that blocks of code shouldn't know about the processor unless it important to its purpose. For the moment, there is a huge set of code that assumes long running processes to add state to inherently stateless protocols. I expect that there will arise easier to compute tradeoffs on the cost of a long running process, the start up costs for a process, and the cost of different coding styles. Write code cleanly; that is still the goal.
Unfortunately, not hashnode. My first comment to hashnode was someone asking about ISP providers. There were a stack of answers with discussions on the tradeoffs, e.g., AWS has its own API but more services. The discussion was deleted with no explanation. So, on StackOverflow a closed question is still accessible for a time.
Picking a service provider runs into the usual decision points: You need a good reason not to go with one of the top five: AWS, RackSpace, Digital Ocean, DreamHost, and, er, others. Is this going to be a strategic differentiator? That is, are you planning to do something different with your hosting that is a selling point? If no, ask five friends and pick one. Inertia matters. For example, I have some sites on DreamHost simply because I signed up for $80/year for unlimited sites once long ago. Not worth moving them. In practice, every application has some degree of vendor lock-in. DreamHost is special in that service may degrade, but the bill is constant. RackSpace is special in that it takes extra care to make a good CLI and OpenStack. AWS is special because it is own ecosystem: cheap to start; lots of services; but strong lock-in; hight fraud rate; and sudden large bills. You usually end up with three entities: certificate management, domain registration, and internet hosting. Of course, I primarily do software and software management for hire, so this is all talking outside my core field. Please let me know if I'm wrong.
As always, it depends. Writing hybrid mobile apps with Cordova makes good apps, not great apps. If you are working in an enterprise writing apps for internal consumption, you probably want to focus on hybrids. If you are competing for mindshare among consumers, you might need a great app. For that, you end up writing native apps. Either way, there is a lot of commonality. There is a trend away from Cordova/PhoneGap towards hybrid-native, like ReactNative. It's my favorite solution.
Oddly, for a tutorial, the answer is "do it again". This turns out to be high value for the time. You can write the code fairly quickly the second time through; error messages have more meaning and context; and you will pay attention to secondary characteristics including performance and testability. Also, you start to internalize the choices of syntax or library design the second time around. Just because you got to the end of a tutorial, does not mean you are done.