titusjohnson

I would not infer that an optimal tax rate would be a maximal tax rate.

Blunders are things you _could_ or _should_ have avoided, had you only taken a moment to pause and think.

It's my belief this applies only to the custom software. I saw reviews online of people using the Famicon version on OSX, using OSX's native keymapping to switch cmd&option around.

I pre-ordered a C64 version, hopefully my suspicion is correct because I plan on taking this to work for use on a Mac.

Over the last decade+ I've been involved in the hiring process at every company I've been an employee at. I've either been a key technical interviewer, or the hiring manager. I would be able to pass all my interviews, and I'm pleased to say that (with one exception) all of my hires have succeeded in their roles. I have a very straightforward process.

- Look at every resume, pass/fail fast. Ask the Recruiter or HR to give you more resumes, not less (they typically are not equipped to assess techncal resumes)

- 15 minute phone screen. Make sure the role fits expectations, make sure the salary range is acceptable, get and give a verbal background.

- At-home code task. Something that takes an hour or so to get functional. More if the interviewee wants to put some spit-shine on it. I ask for a git repo back, and I tell the applicant up front that the code will be used to springboard the technical interview.

- 2 hour technical interview, no live-coding. In person or virtual. This involves other engineers from the org -- we code review the git repo. For each code task I have a set of 3/4 "Product Manager" style enhancement requests, we then verbally talk through the technical changes & challenges for each ask.

- 15 minute chat with the CT or VP or whomever is my boss.

- Extend an offer.

It's all very real, and very pragmatic, and shouldn't suck more than 4-6 hours out of an applicants life, total. I want to be able to extend an offer within days, assuming everyone's schedule aligns. There is 0 reason to go deeper. If you cannot asses someone's technical chops in a 2 hour conversation, you shouldn't be involved in hiring. If you couldn't complete the coding challenges to your own satisfaction, you shouldn't be involved in hiring (there are engineers I've worked with who are no longer involved in hiring due to unneeded pedantry that they themselves would not tolerate if the shoe was on the other foot).

I was so amped up when I realized Crichton wasn't going to get merged back together by the end of the episode. They took an old Star Trek trope and _didn't_ resolve it neatly by the end of the episode! They're just dealing with 2 now??

Far and away my favorite Sci-Fi TV show. I agree with another poster here, it's a character study of a normal-ish human losing his mind due to a continuous assault of The New. Poor guy can never catch a break.

    The iPhone camera modules sticks out more each generation to the point that a case is a must.

I think that's the point. You are free to choose the exterior aesthetic & feel for your phone, it's thin enough that adding a case isn't an issue. The phone is designed to have a case of _some kind_ around it.

        it "revolts when it encounters elegance" do
            expect(poster).to receive(:barf)
            poster.see(shit.like(this))
        end

That would be closer to the proper form.

> And then if you even want negation (the equivalent of some `a != b`), then which of these are correct and which are wrong?

This whole argument just seems incredibly... pedantic. You don't need to wonder which is right and wrong, if you're familiar with the DSL you'll _know_, because you write Ruby, if you're not then the first time you run the spec you'll get a nice error, and then you'll _know_.

RSpec is goddamn gold. You read far, far more code than you write. Tests (and well written Ruby) reading like English is such a velocity boost I wouldn't trade it for the world.

> "No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider." (47 U.S.C. § 230(c)(1))

While Reddit started as a link aggregator, the vast majority of useful content on the site is not external links. It is content generated for reddit, on reddit.

Not getting laid because the opposite sex finds you and your thoughts repulsive is also an effective neutering of ones gene line.

Getting snipped can at least be done after you've figured out what kind of family you want.

These are the same conservatives who complain that they ain't getting sex any more, and women are too up-tight. Espousing conservative talking points is like socially castrating yourself. 2/3rds of women won't have anything to do with you.

The liberal guys are getting laid.

Facebook itself is has no vocal cords or thought membrane. It's often easy to forget because we like to personify companies, but a company is just a piece of paper for tax and legal purposes.

You can safely think "Facebook wants me to think it thinks this" when a Spokesperson speaks.

You can safely think "Part of Facebook thinks this" when an individual employee speaks.

You can safely think "Facebook Corporate wants me to believe this" when an executive speaks.

All of these individuals speak for Facebook, because they are a part of the collective that is Facebook.

No, they did not. Reagan very much wanted to spread that lie, but no infrastructure was held hostage. The laborers who held the skills needed to run that infrastructure declined to work when their compensation negotiations were declined.

Reagan's actions have had a profoundly disturbing effect on the American middle class that is still being felt today.

Text size, just fine. A few games have had pixelated text that was obviously meant for a larger screen, but I've had zero issues reading in these cases. Note, I'm not trying to play Civilization VI or some 4X game that _wants_ a big monitor. While the screen is small (bigger than a Switch screen, bigger than my phone) the resolution is great. I'm playing games on it that I last played on a 1024x768, or a CRT TV (Fable).

Noise-wise, yeah you can hear the fan kick in but it's not really loud. No issues bothering other people nearby, no issues with the onboard speakers playing over the fan noise.

In regards to the Deck not having games designed for it, Valve has done a fantastic job laying the groundwork for this product. Go all the way back to the Steam Controller and Steam Link; while those products were not a huge commercial success for Valve, I can see all the lessons learned paying off with the Deck.

Wanna save some battery life and you're on your LAN? Stream the game from your beefy desktop. Controller layout not working? Every button is fully programable and removable. This thing has inputs out the arse. Touchpads, D-Pad, 4 extra under-side triggers. Wanna play a game that's not officially supported? 90% chance some fan has already made a community gamepad layout that's better than what the game maker would have made, you can download it and it works instantly.

Yeah they did. I hit a rut in gaming a couple of years back and the Steam Deck has really revived a lot of the joy I get from single player gaming. I've had a blast installing ancient games from my library and reliving memories.

The Deck can really take advantage of all the Xbox forward ported titles that still play better with a controller, and I've picked up a lot of those over the years on sale.

Not who you're replying to, but I have input.

  But then what's the point of an API contract if it's not describing the returned
  data? What I'm arguing is the opinionated payload provides a lot of the same 
  value. Or am I missing something?

I guarantee you that you have not actually contracted your error messages. You have a typo, you'll change the phrasing to better describe the problem, you'll need to add more info for ancillary problems, etc. I doubt you'll bump the rev on your API when "The resource you requested was not found" gets tweaked to "We could not find anything by that ID!" in the name of 'friendlyness', but that's what you would need to do for me, as a client, for me to not have to ship a hotfix because you changed your error contract and now my users are seeing "Something went wrong, our engineers are looking at it" instead of my nice branded "404 - Not Found" page.

  You try employee 1, fantastic, it works!
  You try employee 100, not fantastic, it 404’d.
  Huh?
  Why do I get a 404 here? The path is clearly correct, otherwise employee 
  1 wouldn’t have worked either.
  “Ah”, you may be thinking “but it clearly means that the employee wasn’t found!”
  No, there’s nothing clear about that. If I were to call /api/v11/employees/1 
  I would get the exact same error. As an API consumer, all I want to do here 
  is raise my middle finger.
  But as an API producer, this results in a conundrum: What am I supposed to do then?

To start off with, stop worrying about your clients fat-fingering your API namespace. That is not your concern. You don't give a shit if they spend a _week_ hammering the wrong domain and getting 404s, why the hell would you care about them hitting a non-existent v11? You don't do anything beyond direct this confused user to your docs.

If for _some reason_ you want to give more info for requests to `/api/v11/*` or whatever other non-paths you want to handle, just serve a 400 response back and let your consumers figure out what they screwed up; but I argue you have more important things to do with your time.

Also, why are you worried about differentiating your server errors from client network failure? That's for the client app developer to handle. Don't worry about it. Your obligation begins and ends with a connection to your service.

  Opionated payloads should be mandatory
  Returning a 2xx code immediately tells the client that the HTTP response
  contains a payload that they can parse to determine the outcome of the 
  business/domain request. That is to say
    - client checks HTTP response is valid (2xx status)
    - client can confidently parse the response and make a domain oriented
      decision, as opposed to a techinical one
  This makes your client happy. Very, very happy. Using our above examples, 
  here is what we would see:

If I was reviewing an API for an integration and I ran across this blog post and/or descriptions of this behavior in the API docs, your service would go straight into the "won't integrate with" pile. I'm simply not interested in the problems this paradigm will generate for us. I've gone down this road many times, these days it's use the HTTP Spec or GTFO.

  My API is clean, easy to understand and easy to debug. A client no longer
  needs to send me a request to ask for clarity on an endpoint that sometimes
  returns a 200 and other times returns a 404.

Ah, there's the nut. Instead of adding descriptive error bodies to your 404 responses you threw the paradigm out the window and added descriptive error bodies to 200 Success responses. If you're not providing API packages for your users to hide this unexpected behavior, they are not "very, very happy". No one is "very, very happy" as they add yet more Magic Strings with which to infer what their remote resource means when it says "200 Success: Failure"

Your example is just a filtered index, you would receive a 200 with no results just like any other index route with a filter applied.

Eh. I think it could have if it was a pure addition. The loss of the fn & escape was too much for me.

Ultimately I set it to display the fn keys all the time and tried my best to ignore it. I don't look at my keyboard. A display near my fingers is a display where I don't look, I never found much value in it.

> Short term, it's decidedly not good, but long term? How can we know?

History.

> If the approach is so inherently flawed that this result is an inevitability

Only an inevitability due to attitudes like yours. Please stop contributing/pushing for the end of the open web.

Not with Google hamstringing extensions w/ Manifest v3, no.

It's not a solution, but it's a kind gesture

Such a dumb problem they've made for themselves. Just adjust the price per screen in a plan if password sharing is that big of a deal. They should be encouraging password sharing. What a killer feature to mine for brand loyalty.

Handing over your Netflix deets? Next step in your relationship. It's sweet and romantic. Now you can watch Together even not on date nights.

Kid's going to college? Add a screen for them so they don't feel alone. Enable cross-profile personal recommendations so your lonesome kid gets the warm fuzzies when they see Mom and Pa enjoyed the latest Stranger Things.

Sister getting divorced? Add 2 screens for her so she and the kids have some sense of normalcy and fun as they go through the hardest part of their life they've known.

Got a huge family? Enable account payment splitting. Enable gifting free months. Allow profiles to share watched data onto a huge master profile. Generate "Everything the Howards Loved - 2022" playlists for nostalga.

Just charge per screen and lean into it, goddamn.

It's hard science because the rules are Hard Lines. Clearcut, sharp, easily communicated.

It's soft science because it's squishy. The rules are soft and malleable, depending on the context of the question.

I grew up in a firmly "independent evangelical" household. What that meant is we believed Catholics, Lutherans, Mormons, etc, were all various flavors of Sinner, Idolater, and False Prophet. The bible was 100% true, every word protected by god through the ages. Sunday and Wednesday's were filled with hours and hours of listening to overweight preachers struggle to draw a correlation to 3 out-of-context verses and whatever mortal sin they were railing against that day (it was never, ever Gluttony. Usually some sex thing)

In my experience the Bible is only hard to understand when you're frantically, desperately trying to extract a per-determined result for your modern day problems out of what are fundamentally the oral traditions of dirt farmers.

When read as a historical piece of combined fable, family history, nation history, and oral tradition, it's an interesting if hard to follow book. It's obviously written by dozens of writers at different times. Reading different translations reveals obvious bias of previous translators, making it more interesting when viewed as one of the worlds longest-lasting games of Telephone.

If you're going to take it as advice for life, well, look around you. Dozens of different religious, many fighting for centuries because their interpretation of dirt farmer words is better than yours. And they'll kill you for it too.

Proving to yourself that you are better than a housecat, and still contain some vestigial instincts for survival.

I ditched FB specifically because I was tired of my ambient information leaking out to my associates. In-person meetups literally turned into simple recaps of what everyone already knew. I figured out pretty quick that I enjoy giving my friends updates on what's happened, and receiving updates from them in kind, in person.

Since withdrawing from FB and nearly all major social media, my in-person meetups are far more fulfilling.

In my experience there's always _something_ that isn't well supported by design tools. Some validation rule, some odd required relationship, a UI that isn't at all supported, and what is supported isn't at all liked by stakeholders. Half the app is legacy and still being migrated and this new widget depends on XX legacy component, etc.. I've personally observed 3 apps start as a GUI-based application, but by the time it shipped v1, and definitely v2, most of the app was hand-rolled.

Also in my experience, basically every company out there needs or wants an app. A web app, a phone app, a TV app, a tablet app.. internal apps, external apps, apps to gap 3rd party app integrations, they're fucking everywhere. A lot of these 'apps' are just web forms over CRUD data for one reason for another, but it's custom for some reason. And the reasons for why a GUI builder gets phased out also applies to why app-farm apps also get phased out of a company. Eventually, with enough success, having an internal dev team is just so much smoother than contracting or bridging the gap with excel spreadsheets. Someone has to wire things together, and eventually they get to fixing the root cause of inconsistency and a custom app is born.

I think we will have programming jobs for basic forms for a lot longer than any one of us would suspect, for a lot of reasons. But my last and most important thought is, once something becomes easy for anyone to do it becomes common. To stand out you need to be uncommon in some way, so there will always be space for people who can do what most others cannot.

    > Senator Marco Rubio said after input from airlines and broadcasters that supporters agreed that the change would not take place until November 2023.

I have a better idea. Let's make the change _today_ and see which organizations are technically competent enough to change a clock. Survival of the fittest.

    To actually believe something as stupid as you're claiming, you'd have to assume that the giant corporations suddenly decided to crank the greed knob in lockstep with a massive amount of money being printed in the last two years.

Alternatively, it would be incredibly naive to assume flavors of this are not happening. Remember, just because collections of entities do similar actions at the same time (in lockstep) does not mean they are colluding or organized, it simply points to the fact that these entities the same motivations and same external forces at the same time.

Mostly true, image search results are shown to the user using a base64 encoded thumbnail representation of the source. Focused view results in a request made to the source image inline with Google's site. They definitely store & process copies. Color search, subject search, none of that is possible without storage of some kind. Freshness searches require polling resources with modest frequency, too.