Update: Is it just mine or are all 40k space marines right handed and turning towards the right?
Update: I should not have put them on bases and attached the guns before painting them!
I contacted Fiskars and they sent me two replacements that are awesome! The replacements are Fiskars Easy Change Fabric Knife (3 blades) 164010-1001. The only visible difference between the two is that the Fabric Knife's has a gray tinted, translucent cap (rather than untinted). I hesitate to provide a product link as none that I found show the packaging. If you do find a package image it should look like the image in this posting.
Thank you Fiskars for great customer service.
I enjoy Seth Godin's blog. The entry today is Installing the stupid filter which is about how humans don't always accept questions or directions as stated. That is, humans ask "Are you sure?" Machines don't.
The problem is that machines are given bad data all the time and most accept it verbatim. Crossref, my employer until Jan 11, handles lots of XML encoded data. So we need to manage both complicated structures and many types of data -- publication dates, personal names, country names, company names, page numbers, volume numbers, ORCID iDs, ISBNs, ISSNs, Pub Med ids, etc. Some types have a strict syntax and so we can know if the value is valid. What we can't know is whether the value is appropriate. We have to guess.
Is a publication date 2 months from now appropriate? In most cases, the answer is "yes" as the publisher is depositing the metadata for a forthcoming publication. But what about 3 years from now? If the publication is part of a book set that is expected to take 10 years to complete publication, then "yes," too. If it is a journal article then almost certainly the answer is "no." At what point is an article title too long? Is it, as we have experienced, a misplaced abstract? It seems the more data we have the more the questions we have about it.
I don't have any answers for these questions. I just want to make the comment that even in machine to machine data exchanges there needs to made sanity checks on the data and those checks have to be within the larger context of each datum.
Update, 2018-11-27: Jerry's and West Marine both sell fork terminals.
Letter to the University of Massachusetts Boston Chancellor:
The Boston Globe article "Falling elevators, raw hamburger, lax security at UMass Boston dorms" is a serious check on the trust, confidence, and enthusiasm I have for my son's continuing attendance at UMB. I do not expect new facilities to be without flaws. Nevertheless, a step to regaining the community's trust in the joint venture between UMB, Capstone, and Sodexo is to make public all the service and repair work orders, actions toward, resolutions of, and all other timeline details. Collecting and presenting this information every 24 hours would allow us all to see the extent of the problems and the pace of resolution. Let us see that Capstone and Sodexo put the health and safety of the students over profits and that UMB is a good steward.
"I will have to included the shipper funds with the payment so that you will pay them once you receive the payment."Now, I am not selling something that can be shipped USPS Priority mail for $8. The paneling is a few 100 pounds of metal and 100 or more square feet. The buyer is going to have to contract with a long distance hauler and, most likely prepay, some or all of the price. I passed on the sale. The buyer never texted back with a counter offer or a simple goodbye. Part of me wanted to see what would happen next. My expectation was that I would soon have received an email from "PayPal" having me login and collect the payment.
I have no way of knowing if Mr Anthony was or was not a legitimate buyer. But there were many signals of fraud in our interaction. If I do discover that Mr Anthony was, indeed, just trying to buy a bunch of cheap fencing quickly, then I will apologize to him and remove this posting.
- Incident Response Slack App
- Adding persistence to the Incident Response Slack application
- Who wants to perpetuate a flawed design when a proper one is just around the corner?
- Incident Response and stating requirements
- Access AWS Secrets Manager from AWS Elastic Beanstalk
Assume you have created an AWS Secrets Manager called S1 and an AWS Elastic Beanstalk called A1. What you now need to do is to
- Create an IAM Policy called P1 that enables access to S1.
- Attach policy P1 to the role aws-elasticbeanstalk-service-role.
- Attach policy P1 to the role aws-elasticbeanstalk-ec2-role.
Once this is done, restart your application A1 and it will now have access the S1 secret and its keys and their values.
Since Incident Response needs to store its data in AWS SimpleDB, I extended the S1 policy to include all access to any AWS SimpleDB domain, but this did not work. I had to restrict access to a specific domain's ARN. What bothers me about this is that I have now specified the specific domain in both P1 and as a secret S1 key "aws.simpledb.domain" value. Perhaps there is a way I can read the domain from the policy; an exploration for another day.
Tonight (Oct 5) is the last performance of The Father, performed on the outside stage at the Contemporary Theater Company. The story is told from the point of view of a dementia patient. It had the same revelatory experience for me as did reading The Curious Incident of the Dog in the Night-Time for Aspergers. Highly recommended.
Update, 2018-12-03: "Sorry, Linux. Kubernetes is now the OS that matters," by Matt Asay of InfoWorld.
Creating a globally consistent, strictly increasing, small integer number mechanism is very hard to do. A reason why ZooKeeper, atomix, etcd, consul, etc, are so widely used is because they do the hard work of implementing value consensus in distributed systems. For my hobby project these tools are overkill, but I still need the mechanism.
To restate the requirement, it is a mechanism enabling multiple processes (on a distributed set of machines) to add tasks to workspaces. But is that really the requirement? Isn't it a premature optimization to assume the need for multiple processes? Perhaps one process can handle all the task creation requests for a single workspace?  If I have 100 workspaces I can choose to enable task creation by distributing any request to any process, but I could also choose to distribute task creation to the workspace specific process. Choosing the second option vastly reduces the problem to enabling a single process to sequence the task ids. All I have to do now is direct the request to the right process and this is easily done at Slack with a different URL (option A) during application installation, or at an application layer gateway (option B).
So I am going with one process per workspace  with option A.
 An assumption is that one process is sufficient to manage the demand of a single workspace.
 Note that this does not preclude more than one workspace per process.
Network partitions are going to happen. Switches, NICs, host hardware, operating systems, disks, virtualization layers, and language runtimes, not to mention program semantics themselves, all conspire to delay, drop, duplicate, or reorder our messages. In an uncertain world, we want our software to maintain some sense of intuitive correctness.
Well, obviously we want intuitive correctness. Do The Right Thing™! But what exactly is the right thing? How might we describe it? In this essay, we’ll take a tour of some “strong” consistency models, and see how they fit together.
We do see some workflow automation tools regularly used in devops groups, but they are specialized. Jenkins, for example, is used to build and distribute applications. Rundeck manages "cron" tasks that need to be executed on all the hosts or services. Even tools like Spiniker is, at heart, a workflow automation. I suspect that all these could be implemented as workflows on top of, for example, Camunda.
Historically, workflow automation has been entwined with ERP and BPM. I don't recall anyone ever saying their company's ERP migration was a pleasure to participate in. (Which reminds me of Douglas Adams's statement that "It can hardly be a coincidence that no language on Earth has ever produced the expression 'as pretty as an airport'.") To discard workflow automation due to the historical horror stories is truly a lost opportunity for the future.
Workflow automation needs to take a more central role in our distributed systems designs. Camunda seems like a good place to begin -- search for talks by Bernd Rücker of Camunda.