mpetrovich

The classic solution-in-search-of-a-problem.

If the founder had started by talking with people in the problem space, he could have discovered what problems were actually worth solving before investing any money and effort into a product.

Everything after that happened were downstream effects of creating something without a defensible reason why and for whom.

I suspect they ask for email first in order to determine whether to log you in via SSO vs. require a password.

I found php’s array methods lacking as well. The inconsistencies are a pain. I ended up porting many of the methods from lodash, underscore, etc. to php: https://github.com/mpetrovich/dash

Maybe you’ll find it helpful

Seems inferior to C2PA, which is actually an open standard: https://contentauthenticity.org/

If that’s true and they do intend on shredding their copy on sale, what stops GitHub from buying it back themselves? (through a proxy, obv)

AI isn't changing the fundamentals of building software. It's changing the speed. Don't confuse the two.

Some feedback: show example input & output without requiring me to create an account.

Looks interesting, best of luck!

Reminds me of this open source library I wrote to do the same thing: https://github.com/nextbigsoundinc/imagely

It uses puppeteer and chrome headless behind the scenes.

Good point. What if we combined the best of both: more realistic images from tpdne.com and API-accessible metadata from your site?

Seems like a matter of crawling the former to get all the images and then tagging them and serving them via your API.

Anyway, I think your approach is great and only wanted to propose a possible approach to the original feedback above :)

Perhaps something powered by thispersondoesnotexist.com would better for that. That site returns completely AI-generated faces that seem much more realistic and candid.

The demos on the Jolly Roger site are hilarious. The bot sounds so realistic, and the bot even had the audacity to ask the scammer, “Are you a real person?!”

“Hold on, there’s a bee on my arm”

In my career, the biggest problem with ORMs I’ve used is something the author touched on:

They can be terribly leaky abstractions. It seems that many ORMs end up re-implementing SQL in their own domain-specific language.

However, an understanding of SQL is often needed to debug and optimize ORM queries.

So why not just use SQL directly then?

My goodness, this describes me perfectly as well. The countless choices of a blank slate brings anxiety to a recovering perfectionist like me. Do I choose A or B or Z?

I prefer improving things rather than creating them from nothing. I’ve come to a similar conclusion as the author as far as how to get out of the fog of greenfield: Satisfice instead of optimize.

In this context, optimizing refers to choosing the best among N options. In contrast, satisficing means choosing the first option that’s good enough. Often, the opportunity cost saved from satisficing is greater than the marginal value gained from optimizing.

No, he’s talking about the movie. You know, the one with the sub.

Oh, so you’re saying that omitting the version from the header will ALWAYS return this specific version, NOT the latest version?

That certainly addresses the footgun I mentioned.

EDIT: From the docs: Requests without the X-GitHub-Api-Version header will default to use the 2022-11-28 version.

You’re saying that it’s LESS likely to specify the API path at the callsite than the HTTP header? o_O

I agree with you, so then why not stick with the previous /api/v2 url approach?

And it would annoy me far more if my app that talks to GitHub inexplicably breaks in a few years because of a release I wasn’t aware of.

These changes make no sense to me.

Making the version optional is a bad idea, IMO. It lets consumers use your API without versioning, which is like telling them, “here, create a time bomb that may or may not explode when the next breaking api change is released.”

There’s zero practical user benefit to NOT specifying the version, so why not enforce it? You’re creating a footgun otherwise.

Furthermore as others have pointed out, this is a purely cosmetic change. Using /api/$UNIQUE_STR in the URL vs. X-GitHub-Version: $UNIQUE_STR in the header are functionally equivalent, so…

Why bother making this change then? What was suboptimal about the previous way? What benefit does this bring?

EDIT: Serves me right for not reading the docs more carefully. From the docs [1]:

Requests without the X-GitHub-Api-Version header will default to use the 2022-11-28 version.

See phphphphp’s reply below for context.

[1] https://docs.github.com/en/rest/overview/api-versions?apiVer...

The systems angle mentioned later in the article may seem a bit …engineered, but it works!

I’ve moved a ton in my life, and I have an annoying habit of losing touch with friends when I move away. Out of sight, out of mind, ya know?

Anyway, to combat this annoying habit, I started scheduling monthly phone/video calls with each of those friends. It’s been a game changer, especially as folks have kids and busy lives.

I hadn’t considered it since it’s mobile-first, but that’s a great idea to try!

I imagine that the arrow keys would control the movement of the empty space, right?

Really fun! This inspired me to create my own version of the sliding-tile puzzle game that I used to play as a kid: https://tileslide.com/

Anyone else remember playing Glider? As a young kid, I gladly lost countless hours trying to navigate a paper airplane through a Rube Goldberg mess of obstacles. What a fun, imaginative game.

Would be cool if there was an emulated version somewhere. Or we could borrow the author’s book and transcribe it to a modern language, ha.

Back in college I wrote a 3D rendering engine using what seems to be a similar method as the OP. I always thought the results looked a little strange... https://github.com/mpetrovich/CUB3D

Pandora + SiriusXM | Product Manager | Remote | Full Time

Product Manager, Data Platform & Enablement

Want to be a product manager on a team that helps the largest audio entertainment company in North America understand and act on its listenership?

Apply here: https://jobs.jobvite.com/careers/siriusxm/job/oU6KffwJ

100% remote friendly. NO formal product management experience required. Folks with non-traditional backgrounds should apply!

You might also be interested in Dash: https://github.com/mpetrovich/dash

The author makes an unvalidated assumption that the users of this service care MOST about bandwidth efficiency.

I suspect that users care more about a service that works reliably. An extra 50-100k every 5 minutes (assuming the user keeps their mobile browser open during this time) does not seem like it would be problematic.

Ironically, the alternatives he proposes make the service LESS reliable, since many users may be behind firewalls that block WebSockets, HTTP streaming, etc.

HTTP polling works for a larger percentage of users and can be scaled horizontally more easily than these other methods during high-volume spikes like the World Cup.

In short, I think Google made the right tradeoff between dumb, boring, accessible vs. clever, complex. Especially for a product that probably doesn’t meet the threshold for investing in a more sophisticated architecture.

I add articles to Instapaper using the Chrome and iOS extensions. Then in Instapaper I highlight key phrases/takeaways which get automatically added (via IFTTT) to a new Evernote note for each article. I periodically review these notes to reinforce the takeaways (ie. spaced repetition).

REMOTE or NYC | Senior Data Engineer | Next Big Sound @ Pandora

--- About Next Big Sound

Next Big Sound (https://www.nextbigsound.com) is the leading provider of online music analytics and insights, tracking hundreds of thousands of artists around the world. We use our expertise in prediction research and cross-network performance measurement to deliver analytics and insights to music makers as well as Pandora's listeners and advertising partners.

Next Big Sound operates like a startup within Pandora: autonomous and self-directed with the freedom to explore novel directions and to experiment with the way we work. We're a geographically distributed and interdisciplinary team of data scientists, designers, engineers, client services, and product leads who are passionate about solving challenging problems with data at a massive scale.

--- About the role

We're looking for a senior data engineer to work directly with our science and product teams to ingest and integrate large volumes of disparate music and social data from a variety of sources. This involves rapid innovation in large-scale data pipeline design and development to ensure critical datasets are audited, normalized, and made available to our users and predictive models in a timely manner.

This role might be for you if:

- You have experience with and enjoy designing, building, and owning data architectures and ETL pipelines end-to-end

- You can work effectively on small, interdisciplinary teams with other data scientists, data engineers, web engineers, designers, and product managers

- You're hungry to learn new technologies and teach us a thing or two about building world-class data platforms

- You're excited by the challenge of extracting value and insights from large, disparate music and social data sets at scale

Our team is based in New York City but working remotely is an option. In fact, one third of our team is remote.

Apply here: https://pandora.com/careers/position?id=oJaQ6fwz

I love this. Recreating old games makes you really appreciate the techniques and effort put into even the small things that one often takes for granted. Doing it yourself is a great way to learn real-world applications of abstract math/compsci algorithms.

I hope others build on this in the future and add the worms gameplay mechanics. One of my favorite games when I was younger.

New York, NY | REMOTE OK | Sr. Web Engineer, Sr. Data Engineer | Pandora / Next Big Sound | Full-time

My team is hiring! Next Big Sound is like a startup within Pandora--autonomous, interdisciplinary, small, and nimble--with a big impact in the music industry. We're remote and travel-friendly, too.

If you're interested in novel data and web engineering challenges at scale, reach out to me or apply using the links below.

Senior Web Engineer: https://pandora.com/careers/position?id=op106fwg

Senior Data Engineer: https://pandora.com/careers/position?id=oJaQ6fwz