amdelamar

https://www.nwtime.org/current-members-donors/

I also really enjoyed reading this; the mix of computer science & history was well balanced and kept my interest.

It makes me think there should be a CompSci history class taught in college.

The amount of salt in photo #6 is too much salt. Its very easy to over-salt anything and ruin it. Better to under-salt until you gain enough experience with judging how much you actually need.

As for putting the meat grinder in the freezer, I'd like to know if restaurants do that or not. Because I highly doubt it. Seems very silly.

A 25% restocking fee seems like a better solution.

My blog https://amdelamar.com/blog/ Focusing lately on Scala and programming articles, but struggle to publish more frequently.

Physical NFTs! Sounds like a cool idea for a website...

4. Fail small, reducing blast radius

One more thing not mentioned here, is that using a microservice architecture can naturally help isolate outages to small parts of your app/website. Rather than take it down entirely.

My team supports a large microservice system, and while there are definite drawbacks to the architecture, one of the major benefits is that its never 100% down at any given time. Usually a prod incident will make one particular button flakey or one view/page fail to load. Some users won't even notice theres an outage. Oncall is paged and can quickly rollback the squeaky microservice to a previously deployed version, and let an engineer investigate the root cause in a test environment later.

This is my top issue with open-source nginx. Nginx plus has the solution though with its `resolver` directive. https://docs.nginx.com/nginx/admin-guide/load-balancer/http-...

I think there's a good analogy to a wedding ceremony I read from DDIA.

"Do you take X? I do. And do you take Y? I do. I now pronounce you X+Y".

A year ago I had a coworker build a CRUD app with an API that required GET with a body. Something simple like:

    GET /api/query
    Host: example.org
    Content-Type: application/json
    
    {
      "a": "valueWith$pecialChars",
      "b": "valueWith$pecialChars",
      "limit": 100
    }

If QUERY was around I'm sure I could've made a stronger case to fix it sooner.

And [Brew](https://brew.sh)

My team had migrated about 35 codebases from a mix of Play, Scalatra, Ruby, and Python, to Akka HTTP. The unification definitely made it easier for juniors to start work on unfamiliar codebases, but the same could be said if we unified on something else. That being said, a portion of the services did make use of Akka streams & actors and we’ve found a lot of success there that otherwise would’ve been complex code with locks or synchronized blocks. Stuff that I’d rather not have to onboard engineers with or review their PRs and miss an unlock(). It’s probably a steeper learning curve by teaching them about actors and futures, but it means they’ll be writing safer code by design, and reviewing their PRs becomes easier for me.

Just make sure the actors are small and have one focus. When they get too large and do too much is when they become unwieldy and difficult to maintain.

I've had a similar phase and just switched back to Ubuntu a week ago after having used a number of different distros since 2011. As a software developer myself, I think there is a mix of two emotions that lead to this; fear of missing out (FOMO) and imposter syndrome. I was trying to learn as much as possible for a while, adding skills to my resume, thinking my peers were doing the same. (They were not). All that time I ended up suffering from some pretty poor UX issues (Audio/Bluetooth/Wifi) that I tried fixing unsuccessfully or ignoring for the longest time, that I forgot what it was like to use a system THAT JUST WORKED out of the box.

The best part is that the cubicle doesn't have tall walls so I can literally see/hear everything, including other people's monitors.

Open offices are awful. In my experience most people end up wearing headphones all day, and I did too. My ears would get red and irritated after a while. But I'd keep them on because it was like an unspoken social rule; that if you looked busy and had headphones on, people won't interrupt you as much.

Monolith, sure.

Microservices, no.

I did this and still feel gross about it even though I don't regret the decision. Accepted an offer for a Java/Spring developer, but a week later I got a better offer for a Scala engineer at Apple that had swept me off my feet. I don't know why I still feel gross having to renege after accepting the first offer; I think its because I annoyed the recruiter. That even if the first offer had salary-matched the other offer, I'd rather be programming in Scala than Java/Spring and that wasn't something they could compete with.

It really boils down to trust. My manager trusts I will make up lost time after my doctor's appointment, as they generally know if I've been falling behind work or not. We also give daily standup status updates so its obvious if work isn't progressing after some time.

This also works in reverse. If I work on Sat/Sun for some system maintenance then my manager tells me to swap time off during the week. But in my experience, What usually happens is I work my full week anyway because something important arose and I push that "time off" to the next week until I forget I had it.

59 miles range? That's not going to cut it for most commuters in California.

I prefer the original quote as it doesn't imply any leader/manager stereotype.

"Efficiency is doing things right; effectiveness is doing the right things." ~ Peter Drucker

If I remember right, GrubHub/Doordash will undercut restaurant prices to gain more customers for short-term, then later adjust prices back up once they establish a more stable audience.

Imagine if a site like AppleiPhone.com was setup and selling iPhones as a front to Apple.com, complete with their own shopping menu and phone number that they owned instead of Apple.

When I worked at IBM I heard about this RA tactic before. To get rid of an unwanted employee a company might promote them frequently/repeatedly until they quit.

What's the logic behind that? Why not fire them if their performance is poor? Is it because its cheaper for the company?

That's a great metaphor for OOP. What is the full quote or reference from? This is all I could find: https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...

This basically outlines my current job. Huge system with many, constantly moving/upgrading parts and services across teams, all while utilizing dozens of internal services, tools, and navigating corporate policies. I’m thriving in it, but totally recognize it’s a steep learning curve and takes longer to onboard newcomers.

Eventually you get to enjoy deprecating old services as much as building new ones, simply because you never have to teach others about them again.

I've used Linux at home for 2-3 years now. Most of my games library works fine or is tolerable with certain issues, e.g. Terraria I run in windowed mode 1080p, because full-screen mode is weirdly cropped where the mouse can move to. Besides that, I've considered dual-booting just to play the few remaining games with friends that keep pressuring me to join them and "just get Windows". Its very tempting, but I first need to buy a larger SSD to do it. (My Small FF case doesn't have room for 2.5" Drives.)

Digital Ocean starts at a $5/mo buy in.

Heroku is $0/mo to start. heroku.com/free

Given how small-scale it is, maybe he could opt for lights/LEDs and an ac motor to rotate the tapes.

The awkward name is an immediate turnoff IMO.

Just take a look at all the variations in this HN thread on the spelling of it. "Pop", "PopOS", "Pop OS"... I only counted two that used the full name "Pop!_OS".

Looks neat. One recommendation, before the section "Influenced by", could you put a code snippet of what Chaos would look like? It can be HelloWorld, but a more real-life example would be appreciated. (A few example sites that do this: https://vertx.io, http://www.scala-js.org)

This book looks great, and I can't wait to pick up a physical copy. Thank you lihaoyi!