HN user

monkey34

35 karma
Posts3
Comments9
View on HN

I made a custom golf simulator app. There's a Swift app that talks to my Garmin R10 launch monitor via Bluetooth low energy. When it records a shot, it grabs the data and throws it over to a web app running locally on my laptop, with an SVG simulated shot arc, an attached video of the shot captured from my phone (or my laptop's webcam if I'm lazy), and all of the metrics that came across. I keep all of my sessions with shot data and a little overlay of where each shot went (and which club hit it).

The reason I wanted this is because all of the existing golf simulator software I've looked into is either too expensive, requires too much computing power (E6 requires at least an RTX 3060), or both. And most of their selling points seem to be visual fidelity of playing against real courses. As I'm just looking to improve my game, that's not something I need, and Sonnet 4.6 was able to get me to a great spot (and I'm trialling some new additions like slow motion video capture and pose tracking via Apple's Vision framework using Fable 5 right now).

I hope you’re being sarcastic. If not, expecting someone’s parent to know how to use a photo app’s crop functionality just to communicate an error state is a failure of understanding typical streaming app users.

While I've not yet made the purchase, I'm eyeing a Synology RT2600ac (https://www.synology.com/en-us/products/RT2600ac) and an MR2200ac (https://www.synology.com/en-us/products/MR2200ac#specs). It seems like they'll be adding VLAN support in their 1.3 release (https://community.synology.com/enu/forum/2/post/130414), which should be nice for adding dedicated VPN and guest networks.

For me it's one of the few options available because my ISP forces me to use a transitional IPv6 technology called "MAP-E," which the UniFi products don't support. I switched ISPs after purchasing my equipment and ended up with $700 of dead weight.

I love this take.

My previous role had my title as "DevOps Engineer" but it always rubbed me the wrong way. I was just an Operations Engineer with a focus on making my developers' jobs easier, in any way I could. Having that as my North Star kept me honest about the work I was doing versus considering the role more like Operations Engineer v2.0.

In the Silicon Valley, at least, DevOps seemed to be (seems to be?) sort of in vogue; I think it's important to keep its core qualities of bridging Development and Operations in mind as opposed to just shifting an existing position's title in an attempt to attract talent.

I'm not sure I'd consider this a "failure," but related to GP, I have had a number of issues maintaining Elastic Beanstalk environments, including:

- The single container Docker platform (not sure if this is an issue with other platforms) can cause the CloudWatch agent on the environments' EC2 instances to stop streaming logs to CloudWatch. This seems to occur when a Docker container fails, for example if the process it's managing stops (e.g., if a Node.js application triggers an exception that is not caught and exits). A new Docker container will be started, but the new container's log file sometimes does not automatically get attached to/monitored by the CloudWatch agent.

- The default CloudWatch alarms created by the environment can create a "boy who cried wolf" situation. For example, when updating the application version for an environment, EB will transition the environment's state from "OK" to "Info" or even "Warning," depending on the deployment policy. This is a regular operation, but CloudWatch will still send an email to the designated notification email address about the state change. If you monitor those emails for environment issues, this normal operation could cause overload, which might lead to ignoring the emails outright. This could be problematic if the environment state transitions to an actual problem state. You can create email client rules for this, but the structure of the alarm email doesn't make this very easy, at least in Outlook 365.

An annoying example of this is when your EB environment auto-scales up due to, for example, an increase in traffic. When the auto-scaling policy scales down your instances (due to normal operation of the policy), you'll get an email that your environment has transitioned into a "Warning" state because one or more of your environment's EC2 instances are being terminated. This looks scary in the CloudWatch email that is delivered, but you have to learn that it's just the ASG doing its thing, terminating unused instances as it's been configured to do. The emails, however, do not provide good context into what has led to the "Warning" state.

- The way environments handle configuration files stored in your application's .ebextensions/ directory can cause inconsistent application state between version deployments on existing/new EC2 instances. For example, if your auto-scaling policy creates a new EC2 instance, but your recently deployed application version doesn't specify some of the commands/settings applied during a previous update to your .ebextensions/ files that might have been deployed to existing EC2 instances, you run the risk of having inconsistent state across your application's EC2 instances. This can be solved by using the "immutable" deployment type, but that's not the default deployment type. It's an edge case, but it's still something that requires you to SSH into your EC2 instances, and possibly manually terminate older instances when you eventually figure out what's going on.

Having said all of that, I think EB is still a reasonable choice for small/beginner workloads: It gives you a number of things (automated deployment, auto-scaling, load balancing, logs, etc.) that you can get by doing things on your own, but lets you get to production quickly. For mature applications, I think you could be better off managing these individual services yourself (EB is mostly just wiring together a number of AWS services with a a few deployment and monitoring agents running on each EC2 instance). If you're comfortable with the components EB is managing for you and if you have a stable CI/CD pipeline, you can get more flexibility than bending EB against its will.

Thanks! I tried Thunderbird a couple of months ago and abandoned it because its UX seemed to not have really progressed in a number of years -- I hadn't used it since the Netscape Communicator days but it seemed... somewhat the same.

Although I realize these days a number of modern clients store copies of your email on their own servers for push notifications (or more nefarious) purposes, so maybe Thunderbird really still is the best option out there. Regardless, thanks for taking the time!

I do this with FastMail and find it indispensable. However, most email applications don't seem to support sending via wildcard email addresses (i.e., if I receive an email at hackernews@mydomain.com, I want to be able to respond as hackernews@mydomain.com, not my personal email address).

FastMail's web interface lets me do this (as does its iOS client), but has anyone found any other (preferably macOS/iOS) apps that support this natively? I generally prefer native apps over web-based, and FastMail's iOS app leaves something to be desired.