jmb12686

That can be true if you are using tightly coupled event sources (like s3, SNS, etc) where you need to inspect the incoming object. If you are doing a HTTP / REST API, try to decouple the code as much as possible from the API Gateway invocation by using ExpressJS / aws-serverless-express to aid in local testing and debugging. Then testing and debugging locally becomes much easier.

Problem is, meat won't take on any smoke ring after a certain temperature (170 degrees)[1]. Thus you won't get that beautiful authentic smoked meat ring if you precook without smoke. To some, you may as well cook it in the microwave if it ain't got a smoke ring.

[1] https://amazingribs.com/more-technique-and-science/more-cook...

I have a cluster of raspberry Pis setup next to my SmartThings hub. I upgraded storage to use external SSDs via USB 3.0 cables. After that, all my ZigBee devices dropped communication with my hub. After some troubleshooting, I just moved my hub to a different room.

Docker Swarm usage here in production. Mainly a regulatory and compliance constraint, but it is relatively simple compared to other container orchestration platforms.

This was a hilarious clip. Brought me back to 15 years ago, messing around with people on Ventrilo while playing World of Warcraft. Many, many lost nights and days playing that addictive game. Comic relief thru Ventrilo harassment was necessary...

Reading thru the thread, it appears the browser they are referring to may be Cutebrowser.

Docker most definitely has ARM and multi-architecture support. That is, assuming the particular image you are attempting to pull has been published using the Manifest V2 spec and has ARM images published. The issue you mention is an issue with the image publisher/maintainer not Docker itself.

I maintain a number of Docker images that have multiarch support (as seen in the Tags view on DockerHub:

https://hub.docker.com/r/jmb12686/socat/ https://hub.docker.com/r/jmb12686/unifi https://hub.docker.com/r/jmb12686/elasticsearch/ https://hub.docker.com/r/jmb12686/kibana/ https://hub.docker.com/r/jmb12686/filebeat/ https://hub.docker.com/r/jmb12686/cadvisor/

This. Docker Swarm, and by extension Docker EE / UCP, is barely in maintenance mode. Go compare the Moby and docker projects on GitHub vs kubernetes.

To be clear, I use Docker Swarm in my home cluster due to simplicity and ease of use. Unfortunately that pattern hasn't scaled to the Enterprise.

I have over a dozen in wall GE z-wave switches and dimmers in my home. They have been working great for years.

This isn't an accurate statement. I work on behalf of a federal government agency, and no one has write access in development, let alone production. Everything is required to run thru our ci/cd pipeline. Times are changing.

Here in the entire state of Ohio, literally every dine in restaurant and/or bar operation has been shut down. Only take out / delivery is allowed: https://governor.ohio.gov/wps/portal/gov/governor/media/news...

I believe other states / municipalities have started to follow suit, but entire state shutdown has been surreal.

I was doing "devops" for Scottrade's order management system during the exact same time as the Knight implosion. If I remember correctly, the Facebook IPO was a larger mess we had to mop up for our client base...ahh the memories...glad to be out of consumer / retail finance these days.

As an architect, I am currently working on our org's first cloud deployment initiative. Due to federal compliance / regulations, we have no write access in higher / production boundaries, and everything is automated via deployment jobs, IaC, etc. Given the experience of the teams involved, I took the opportunity (burden) of writing nearly all the automation. If your architects can't handle shooting sick cattle in prod, I'd say get new architects.

I haven't written a blog, but I do have a 5 node RaspberryPi cluster running Docker Swarm. The docker stacks and compose files are on GitHub https://github.com/jmb12686/raspi-docker-stacks

Look at the 'gluster' branch for my current active work on clustered persistent storage using SSDs and docker volume plugins.

I have setup quite a few GitHub projects for building / publishing multiarchitecture ARM compatible images of open source projects (Elasticsearch, Kibana, CAdvisor, etc). Check them out if interested in running common tools on RaspberryPis.

My wife (33 years old) was just diagnosed with type 1 diabetes last month. A healthy, under 120 lbs 5 foot 4 woman, who busts her ass for our young children, now has to learn how to keep her blood sugar in check with 4 shots and 6+ finger stick tests per day. Worst of all, accidentally taking too much insulin, or not accounting for unknown variables such as stress, illness, exact carb count of meals, snacks, and exercise, can and will kill you quickly.

I'm disgusted with the current technological advances (aka lack of them) in the diabetes space. The limited tech out there to support an "artificial pancreas" was initiated by a community of hackers [1], and is only supported by a handful of outdated insulin pumps. The manufacturer (medcom) has since "fixed" the vulnerability that allowed outside control inputs. There are a couple decent continuous glucose monitors out now, one by Abbot la s, another by Dexcom, but this only solves half the equation. A true closed loop system feeds continuous glucose monitor readings straight into an insulin pump to administer, algorithmically, microdoses of insulin. This completely eliminates the risk of hypoglycemia and effectively forms an artificial pancreas.

The only reason I fear this kind of tech isn't readily available for all type 1 diabetics is sadly, what's the profit motive to big pharma? They are making a killing off of crap solutions currently available. Trust me, you'd think decades old insulin and glucose meter supplies are affordable by now. These low tech items cost 1000s a month (insurance paid portion).

1) https://openaps.org/

This repo uses the Serverless Framework. It is an excellent abstraction framework for constructing, orchestrating, and deploying "serverless" applications to AWS (and other clouds). Instead of building 1000s of lines of esoteric cloudformation yml, a few lines of higher level definition can deploy your app.

I've built quite a few lambda + API gateway based apps lately, a couple are open source. Want to replace your DDNS service for your home network? Use this app, which will cost you $0 a month (not including the cost of a domain name): https://github.com/jmb12686/serverless-ddns

Here's another repo of mine doing (essentially) the same thing, multi arch image build using GitHub Actions. There is a bit more documentation in this repo regarding local builds though: https://github.com/jmb12686/node-exporter

I've been leveraging docker buildx to create multi architecture images for a few months. It's quite nice and simple, and I've been able to even automate the multiarch builds with GitHub Actions. See an example repo of mine here: https://github.com/jmb12686/docker-cadvisor

I can also confirm that it was easy to store "notes" and write programs for TI calculators. The ability to store arbitrary ascii characters saved my butt on quite a few exams in the 2000s. Not quite sure which TI calculator I had, but I want to say 83+?

Does anyone know what power supply they are using? I am having trouble finding a good, rack-able USB power supply for my cluster of raspberryPis.

If anyone at the conference can sneak a peak at the PSU brand / model number, that would be great!

Amen to this... 3.5 yr old and twin infants here... I haven't been able to concentrate in years. When I have attempted to produce anything of value (in job or hobby), it's been at the expense of my family...

AWS announced this enhancement at 2018 re:Invent. It was slated for "sometime in 2019". I was excited, and I'm impressed that they released the feature well ahead of the end of the year (and before the next conference, which would obviously raise a few questions)

Stackdriver is remarkably awesome for log aggregation, storage, and querying. Uptime checks to arbitrary HTTP endpoints are fantastic!

Not sure about other use cases such as visualization and triggering events. I assume they have an API or integrations for such things, just haven't needed it as of yet.

Their pricing changed recently, don't remember the details, but I do remember previously that non Google Cloud nodes did incur an additional cost. Free limits are decent, haven't paid yet for personal side stuff. But YMMV, check the pricing page https://cloud.google.com/stackdriver/pricing

In my anecdotal experience, attempting / allowing "true OO" programming turns quickly into an unreadable, unmaintainable, unreliable ball of mud. After leading a team of ~30 developers in a monorepo for the past 5 years, I have been relatively successful in avoiding complete software entropy by enforcing the following "code commandments":

- Modular, layered codebase (for ex: interfaces -> service layer -> DAO layer)

- Business Logic resides in Service Layer

- Service Layer made up of collection of Transaction Scripts (https://martinfowler.com/eaaCatalog/transactionScript.html)

- Simple, immutable domain model, with distinct set of immutable objects for each layer. Unapologetically, this is an "Anemic Domain Model", but with separation and no re-use between layers. This allows for immutable objects at each layer.

- Services are decoupled and composed around the data / logic, thereby "owning" their own data. Services can communicate with each other to get data, DAOs are never to be shared among other services. This is in a sense, "microservices without the network".

- Testing at every layer, while respecting the "test pyramid" (https://martinfowler.com/articles/practical-test-pyramid.htm...). Bang for buck is important here.

- Last, but certainly not least: Composition Over Inheritance.

I have appreciated the automated notifications from GitHib for projects that have known vulnerable dependencies in my package.json(s).

I just looked up Dependabot and linked it with a repo that I already have robust testing and CI pipeline for. Preliminarily Dependabot is great!

It automatically updates by dependencies to the latest versions and submits individual PRs. Since I have TravisCI hooked up to this particular repo, I can see all the test results for each PR and can (confidently) merge the changes into master without manually firing up my personal dev machine(s) and manually performing what Dependabot just did.

Anyway, thanks for the tip!

Ok, let's exclude solar panels. WMT's business model doesn't include extreme capacity Li-ion chemical bombs traveling at highway speeds.

To be fair, I admire and hope one day to afford a Tesla. But the risks are clear. High capacity Li-ion batteries have high risks and incident rates of explosion.

And yet, somehow TSLA is only down 1.6% in after market hour trading today (this news broke after mkt close). TSLA, appears to have irrationally exuberant investors.

A (nearly) irrelevant comparison; WMT, a profitable enterprise, is down 1.53% at mkt close today, didn't experience any negative news today, and a core aspect of their business model doesn't explode into flames.

This definitely limits the usefulness of Google's "always free" tier. This will x2 some bills I have for small personal projects, though will still be a bit cheaper than an AWS alternative after the 12 month free tier.

Sigh.. I suppose it was a matter of time before they figured out the pricing loophole. Back to creating new Google accounts every year to get the year of credits...

I have twin infants, a toddler, and work in a large office unrelated to medicine. I wash my hands on average 2 * 12 times a day, every day. It's my job to keep my family healthy. I suppose we are saying it is arguable that it's not the job of medical professionals to keep their patients healthy?

Hippocratic oath must be window dressing these days.

Not sure why this was down voted. Having many medical professionals in my family, I have come to understand this particular issue. Not much different than an inexperienced airplane copilot or junior developer.

Those with less training (nurse anesthetists to be specific) tend to get themselves into trouble and only then call on a MD trained anesthetist for assistance. Furthermore, hospital networks are able to more easily "push around" nurse anesthetists which in the end creates an environment where bad decisions can occur.

To make a distilled analogy, this would be the potentially niave junior dev, pushed by management to ship code / tech debt, despite the advice or mentorship from a senior dev, and only asking for assistance when production is on fire.

However the topic of cost management and profit tactics in US medical system is a broader topic, hospital system administrators and their C-suite management in the USA love cheaper alternatives that are directly employed by the hospital (think nurses, PAs, nurse anesthetists, etc). The hospital system can directly enforce efficiency metrics (think, more money for the hospital, not better care for the patient) and doesn't have to negotiate contracts with a group of specialist doctors.