Hacker Newsnew | past | comments | ask | show | jobs | submit | cx4life's commentslogin

I think the design of a wiring harness is actually a good analogy for a well-created API, in that it provides a handful of endpoints, each of which fulfills a "contract". On modern wiring harnesses, it's pretty hard to connect the wrong thing, because the connectors are physically "typed", in that the male and female sides are uniquely shaped so only they will mate up, rather than having a generic connector that plugs in to every sensor.

On the contrary, twisting a distributor to set timing, or doing _anything_ on a carburator, will make you long for those aspects of ICE to be abstracted to control by software. Weirdly enough, that's what's happened over time in cars with direct injection controlled by ECUs.


Obviously it's nostalgia for me, but timing lights, distributors, points, carburetor ports and butterfly valves, you could really see into the mechanisms. Hell, my dad (who was a master mechanic and worked on cars and railroad diesel engines to put himself through college) took a drill to the fuel injectors on a shitty 80s Chrysler engine that was knocking and stalling when cold (no amount of adjusting the choke could fix it). I drove that POS in my college years and never had a problem with it.


If you're doing minimally invasive wrenching on stuff that is in good condition electronics are fine until you have to do serious work to them.

Grafting two engine harnesses together because you can't buy the one you need (because nobody sells that stuff for 20+yo vehicles) will make you want a carburetor.


I run (almost) every day around Greenlake in Seattle. I use a Garmin watch to track those runs, and sure enough after the 1st my route appeared to be not so much around the lake as on the lake.

Side note, DCRainMaker is an incredible resource, and has dictated every one of my fitness device purchases for the last... 5 years? It's awesome they're so plugged in to the device landscape that they have a root cause for this bug, while not working directly on the fix.


> Side note, DCRainMaker is an incredible resource...

Agreed. His thorough reveivews have allowed me to make technical purchases with confidence. Most recently in a new power meter for my bicycle.


Based on DCR and GPLama, I got the assioma pm pedals and then did the MTB pedal mod. DCR also (in effect) got me a new wahoo trainer. I also regularly recommend Hambini, Peak Torque and Durianrider (everyone mentioned is a youtuber) as honest brokers in a very shady world.


Hambini can be almost too honest. He's obviously a great engineer and really knows his stuff, but dang he rips people a new one.


Durian is a problematic person. Best to ignore him.


Does this mean he tweeted something “mean” and got on a discord hate list, or is there actually something problematic with regard to paid sponsorships / reviews?


This is your idea of contributing to a conversation?


This made me laugh my drink through my nose -- and I've had my life saved by volunteer fire fighters in the PNW backcountry. A gifted, timely amateur beats an absent professional any day.


Encarta might have been one of my first experiences doinking around with computers - I remember replacing the .WAV file for a cheetah with the sound of a car's engine and trying (but failing) to convince my brother it was the REAL sound of a cheetah. There is something about the data being bounded and explorable, both through the software and the file system that was... neat.


There could be folks holding leveraged Bear ETFs or similar after last week's downturn, who were waiting to see how the market moved Monday morning to decide whether to sell or hold. I could see those folks losing quite a bit of money due to the inability to sell off those types of positions after the market reversed course on Monday.

I suspect you're right though, that it's mostly sour grapes concerning the opposite case - inability to buy as the market rallied.


Location: Seattle, WA Remote: Yes Willing to relocate: No Technologies: JavaScript, Python, Go, Docker, React, SQL, HTML/CSS, Azure, git, Jenkins, PHP, C#, Powershell, Bash Résumé/CV: www.timwoods.dev/resume Email tim.woods.tw@gmail.com

Full Stack dev with 2 years experience. Just moving to Seattle from Bellingham, WA and looking for a position in the city. Experience with microservices in Azure, writing REST APIs, extending/maintaining/rewriting legacy code, some DevOps work with Jenkins/Azure pipelines.

I hoping my next role allows me to gain expertise in distributed systems or cloud-based services. While I have limited experience in the area, I'd also be interested in a data engineering role.


> Another price to pay is complexity; it's simply more difficult to build, deploy, and monitor serverless systems.

What do you mean by serverless systems?

My experience isn't with AWS, but with Azure, so maybe it isn't an apples-to-apples comparison.

My experience has been that building, deploying and monitoring even moderately complex, interdependent Azure Functions has been less difficult than building the equivalent services to deploy to IaaS or on-prem. FWIW, a big part of that reduced complexity has been offloading infrastructure management to Azure instead our IT guys, but deployment and monitoring has also been practically painless. Are there some complexity "gotchas" that I've missed?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: