adhoc scalable elastic virtual compute cloud using XEN Hypervisor hosts and thin server instances with effective dated code across the entire cloud.Now the real question. How much time, money and effort?
This evening I was writing a script that was to update a unix hosts file. While the file is pretty simple to process it is yet another DSL and when added to the list of other filetypes in the various etc folders you realize that there are so many different patterns and DSLs... and while they all have one thing in common - system configuration - they are all different.
I suppose that's when the Windows' admins start talking about the registry... and while it's a key/value store at it's core.... it's not an improvement.
I'm more than three quarters the way through this new book "101 Design Ingredients to Solve Big Tech Problems" and I really like it. It's easy to read, truthful, obvious, and reaffirming more than anything else. So the good news is that there plenty of text to skip and plenty to read over and over again. These affirmations are good for all tasks big, small, tech and non-tech.
My only complaint so far is that I'm still looking for the "big tech problem" reference or thread. I had skipped the introduction because in most cases they are just oral resumes so I'll have to read that section shortly.
If there weren't 100 or so affirmations they would make a great 12 month calendar.
I looked at Elixir about a year ago. At the time it was not very interesting... but let's face it, the guys at PragProg have me convinced that "if the engine is big enough even a brick will fly." Nether Erlang nor Elixir or the OTP framework are difficult. It's still a club for the one percent'ers. (the one percent who understand it completely and the one percent that know the syntax but nothing else.)
I wouldn't recommend any or either to my customers or employers unless they had a commitment to the languages and access to the one percent that get's it. (neither are truly likely and reserved for startups that are trying to get some instant geek cred.) Needless to say, I'm going to buy the book anyway.
The problem with 3rd party mailbox apps is that they do not support enough mail protocols as in exchange etc. so no matter how super fantastic mailbox fr dropbox is (same for sparrow) it's never enough. But apple should step up its game!!
That's the stupidest thing I've ever heard. The reality is that the 1TB of GoogleDrive storage costs $1200 over the 3 years that they say is free. So the way it really goes... spend $100 on a GooglePixel and $1200 on GoogleDrive. The only thing you can hope and pray for is that Google offers a new machine in 3 years that allows you to continue the model.
Google did a nice job presenting Angularjs last week but I have a number of complaints. They showed some advanced features that have not made it into production yet and in general there are very few, well written, examples. The examples are either trivial or meta. Nothing in between or real life.
Why would a game meant for toddlers have ads for dating services? Apple's AppStore is flawed in that it does not offer returns when purchasing real apps which only serves to facilitate the advert ecosystem.
We all know what twitter and tweet mean but it was not too long ago when using those words in a sentence meant having to explain them too. Clearly having a common vocabulary is very important for general understanding as well as making the connection to "prior art". The other benefit is that the term and it meaning suggest meaning and purpose to the recipient without the marketing cost. And then there is the potential that adopters or contributors know exactly how to use, built, or extend "it".
Choosing a name like "Alphabet Land" for a toddler educational toy for learning the alphabet is better than "Buddy's Bets". The same would apply for some ORM, web framework, or crypto library.
There are a number of solutions for the Zero Downtime dilema. Many of them include duplicate and partitioned systems. Others use hotpatching of code. On the one hand zero downtime resulting from some for of code and data patching has it's benefits in terms of timing and scale. However, on the other hand there is a certain benefit to performing reboots from time to time.
When it comes down to it all modern day applications have some sort of MQ implementation. Whether it's obvious as in some commercial or free implementation (MSMQ, Rabbit-MQ, ZeroMQ, IronMQ) they are the same... obvious. Compared to the less obvious MQs that are embedded in some library or 3rd party dependency as is common in many database drivers as part of some database backed/integrated application.
MQs are similar to threading in their complexity. If not implemented correctly you can lose transactions, or your mind. SOA is in the family and looks a lot like the Micro-Kernel. Distributed processing with work queues. And nearly impossible to debug.
The biggest challenge is knowing what code to write and what code to buy.
[reprinted from Nov 7]
During a phone screen this weekend I was asked to describe all of my payments experience in a 2-3 page cover letter. I quickly wrote an outline and started filling in the blanks and submitted my first draft. This morning I printed the first draft which was now 7 pages. I have since cleaned up the spelling and much of the grammar. It’s not meant to be a memoir and some descriptions are subjectively technical; and I’ve left out details that professionals should already know. Anyway here it is.
The following text represents the many payment systems I designed, implemented, supported, updated, managed, and contributed to in some way. It should be needless to say that I have worked on other projects in other vertical markets and other languages. I trust you will see the value that I bring to the business as well as the technology. One final note. These are my personal accomplishments. Sometimes I was part of a team and sometimes I worked alone it just depended on…
There are several implementations of a bootstrap layer that integrates with AngularJS. The problem is that they are close enough in name and implementation that I cannot tell them apart and cannot tell which is ready for production and which is not.
When someone says that they want zero downtime; what is it that they really want? An absolute 100% zero downtime is absolutely impossible unless the downstate is the upstate or you live in Bizaro World. Zero Downtime should cover:
facilities (the building)networkpowerserversservices (database; DNS; NTP; web servers, etc...)applications (userspace applications or REST services)monitoring toolssupport staffversions, versions, versions...What most sales people actually mean is completely different. no perceived change in service by any of the end-users What a systems manager actually means is completely different. database schemadatabase stored proceduresapplication binding to the database - in particular strong binding through shared secretsrolling service availability What most managers forget: Zero downtime is hard as evidenced by modern H.A. solutionscomes with a monster price tagThe recovery model is based on tight coupling of componentssystems are typically master->slave with one-way …