billdybas

> If you're trying to built a local-first, mostly private service I just don't think the ATProto is the right tool for the job.

I agree! I think the "permissioned data" working group is aiming to solve the middle ground – where you want to broadcast something "publicly" but to a specific audience instead of the whole world (e.g. invite-only event, membership club). It's "private" in the sense it's not open to all but not in the sense that only you can see the data.

Nick Gerakines has been sharing some good examples of what you could build using permissioned data:

- Private Events: https://ngerakines.leaflet.pub/3mqxalpvn4k2e

- Bookmarks: https://ngerakines.leaflet.pub/3mqu653us3k2p

- Community content: https://ngerakines.leaflet.pub/3mqzsstcsok25

- Forums: https://ngerakines.leaflet.pub/3mr3uqjjaxs2d

- Polls: https://ngerakines.leaflet.pub/3mr3waxevjc24

What I don't see anyone talking about is how Private Cloud Compute is behind an iCloud subscription.

From what I can tell, this means any app that is using their foundation model is sharing against a user's pooled usage quota & Apple takes all the revenue upside if a user chooses to upgrade their plan.

Why would an app developer choose their model which has a minuscule 32K context window, might get throttled because of usage in another app, and doesn't share revenue over any frontier model vendor (where you can package/pass along token costs to your customers)?

These feeds have been going down every day around the same time for a few hours for at least the past several months.

https://www.reddit.com/r/youtube/comments/1r61jpo/all_youtub...

Really cool! Added to my collection of personal websites @ https://personal.network/

> The hardest part was convincing people to download the Discord app on their phone as most of us didn't have it downloaded.

This was surprising to me – is this typical of most Discord users (primarily desktop users over mobile)?

"Mood Machine: The Rise of Spotify and the Costs of the Perfect Playlist" by Liz Pelly goes into more detail about their origins and the culture around piracy in Sweden at the time.

https://lizpelly.info/book

Matt has a really great course on Frontend Masters [0] where he shows you how to use canvas-sketch and make generative art.

[0]: https://frontendmasters.com/courses/canvas-webgl/

Sure, but is that not what an online password manager is? :P

Yes. Mint also does this. From what I've heard, there are a lot of banks without APIs, so the next best approach is to login on behalf of users and scrape the data.

They're one of the few companies who are building GraphQL developer tools, so they have a financial incentive to have their name associated w/ GraphQL.

This piece, while somewhat valuable, is largely content marketing. First they sell you on the idea of "best practices." Then they'll follow up w/ a tool that, surprise, does all those "best practices" for you. "The modern marketer creates their own demand." Prisma is another GraphQL company that produces content like this.

Many GraphQL libraries take some sort of schema definition and then serve it at a route (eg. /graphql). To support multiple schemas, you'd just write a different definition and serve it at a different route. How you resolve the fields is up to you, but both can use shared underlying business logic in these resolvers.

In terms of maintainability, you have to take care that your changes to the underlying business logic don't break assumptions of each schema. And if you want to evolve one schema (eg. say, deprecate a mutation argument, rename a field and deprecate the old naming), you have to ensure that your underlying business logic is backwards compatible for any other schemas (and their clients) relying on it.

I agree. I think their recommendation is a bit overzealous.

I can see the argument if you have a web frontend that consumes data from multiple backend services – have one GraphQL service that manages them all instead of a GraphQL layer on each service.

But this breaks down greatly when you have different "Viewers". In a web app, the "Viewer" can be a logged in user. In an admin dashboard, the "Viewer" is very different – an employee acting on behalf of users. Service to service communication likely doesn't have a concept of a "Viewer".

I would propose that you have different schemas when you have these different views of the world or different permission boundaries. The business logic can be shared – you may just enforce different authorization checks at the GraphQL layer. You could also share GraphQL types that are common between schemas.

For those looking to understand how to choose the right database for the job, I'd recommend first reading "Designing Data-Intensive Applications" (https://dataintensive.net)

Oh, yes, definitely.

Data warehousing and ML have different requirements and needs than your typical N-tier web app. Even streaming event data warrants a different solution. It comes back to knowing how to choose the right database for the job.

The issue is around how these technologies are marketed – grandiose claims and few practical use cases. Once the marketing material permeates the industry and some part latches on, it becomes a self-reinforcing cycle. Blog posts, books, and courses bring the information to the masses. Then companies start to adopt the tools. Then they need to hire engineers who know those tools. So more information gets published about them because that's what people want to learn to get hired.

Many engineers today will turn to NoSQL for everything because of the past few years of marketing hype (and acronym-driven-development), and that's quite a shame.

> The lesson we can learn from this story is the following: start with a generic database...SQL database are a good choice because they can do many tricks...The modern and successful architecture that is commonly used today is to have an SQL database that is sometimes surrounded by some one-trick ponies to take care of a few pain points.

Yup.

I like that we now have more of these one-trick ponies to choose from our toolbox when necessary, when a relational database just won't cut it.

But, my biggest complaint around the NoSQL movement is the marketing pseudo-hype it created. So many amateurs who don't understand database selection took it as gospel and evangelized it across the web (eg. Mongo w/ Node).

It's hard to correct people's understanding when they learn things wrong the first time, especially when there's a mountain of incorrect information they can point to on the web ("These people can't all be wrong, can they?" Well...).

Ah, it's that time of the year again – always enjoy seeing where the JS ecosystem is moving.

I would like to see two categories added for next year's survey:

1. Auth – would be interested to see if Passport is still the tool of choice

2. ORM – curious how Sequelize, Knex/Bookshelf, Objection, etc. compare in usage.

I understand this survey will obviously skew towards frontend tools, but some of the categorization just feels off to me:

For example, I wouldn't consider Next.js a backend framework. Sure, it's a server-side-rendering framework, but you wouldn't typically be using it for traditional backend things like accessing a database. Perhaps consider adding a SSR sub-section on frontend frameworks.

The data layer section seems a bit confused – it's mix between client-side stores and server-side persistence which have very different use cases. I'd probably move out the databases into their own category - would be interesting to see which JS devs prefer (eg. Postgres, MySQL, Mongo).

And trying to draw conclusions from the testing category seems odd when both frontend- and backend-specific tools are bunched together.

Strategy-wise, it makes sense that they're cloning Patreon & Twitch features to keep people on the platform, but I think YouTube is going to need to innovate further if they want creators to trust them with their entire monetization strategy (i.e. ads, subscriptions, merch).

Patreon is significantly investing in creators and building tools to help them grow their online businesses. [1] It feels like YouTube wants to be too many things and has lost focus on empowering creators.

Also, $4.99 feels too steep – many people only give $1-2 on Patreon. And we'll have to see if the subscription recurs the same day of the month you subscribed or if it's aggregated to the start of the month like Patreon.

[1]: https://blog.patreon.com/manage-and-track-what-you-deliver-t...

FameBit (https://famebit.com) – acquired by YouTube

It's the same way any other marketing material may influence you to make a purchase. A lot of online influencer marketing is recommendation-based: "I like this product, so you should buy it, too." Think of it similar to celebrity endorsements in traditional media. For many Millennials and Gen Z who follow these influencers, they are like celebrities (but usually on a smaller, niche-scale).

Have you heard of the Fiesta Movement? [1] Ford essentially did that back in 2010.

With the right brand, right audience, and right production value, anything's possible. Influencer marketing can be finicky, though. A successful campaign requires authenticity – most audiences can see right through paid promotion. I think there's a different dynamic when a brand approaches a creator vs. a creator approaching a brand.

I think a lot of these self-proclaimed "influencers" seek out "luxury" type branding in an attempt to get free stuff they otherwise probably couldn't afford or to create content around a lifestyle which seems unattainable to their audience and therefore draws more views/clicks/shares/virality ("If only I could live like that one day") – mostly Internet junk-food.

[1] https://hbr.org/2010/01/ford-recently-wrapped-the-firs

I agree.

FWIW, my university had a required co-op program, so I already had some internship experience under my belt, and even so, I was getting rejected from entry-level "Software Engineer" startup positions simply on the basis that the companies wanted a minimum # of years of experience.

I just went through the startup job hunting process as a new-grad.

I think many startups have their expectations set too high for the work requirements & compensation they're offering.

Many startups want Senior Engineers with several years of experience, and they want people who live in SF.

This makes it difficult for new-grads and those who don't live in the Bay Area to get into the startup scene. Many people want to work remotely or live in other startup hubs (eg. Seattle) where the cost-of-living is less expensive.

New-grads, you could argue, are the most willing, flexible, and risk-taking to work at startups since the lure is more about experience than $ compensation. However, most startups ignore new-grads because they don't have the processes/ability to mentor them (even if the candidate could already be qualified for the position).

There is room here for:

1. A company which offers services for helping startups foster remote teams

2. A company which offers services for helping startups mentor new-grads

3. A YC apprenticeship program that takes new-grads and places them in a YC startup w/ a mentor (who may or may not be at that company) for a few months to see if there's a match and hopefully transitions that person into a full-time role there

4. YC satellites in other cities or encouragement for some YC companies to relocate out of the Bay Area

Datastore Agnostic:

- JS-Data - https://github.com/js-data/js-data

SQL:

- Sequelize - https://github.com/sequelize/sequelize

- Bookshelf - https://github.com/bookshelf/bookshelf

- Objection - https://github.com/Vincit/objection.js

- TypeORM - https://github.com/typeorm/typeorm

NoSQL:

- Mongoose - https://github.com/Automattic/mongoose

- Thinky - https://github.com/neumino/thinky

+1 for testing actions / reducers.

Snapshot testing probably makes sense if you're making a design system of component building blocks or a purpose-built re-usable component. Anything more and your tests will probably end up being brittle.

For routing, I usually recommend "connected-react-router." [1] Never heard of "redux-little-router" - will have to check it out!

[1]: https://github.com/supasate/connected-react-router

JSData aims to be a datastore-agnostic ORM inspired by Ember Data – https://github.com/js-data/js-data

MoMA's "Fashion as Design" course was pretty interesting: https://www.coursera.org/learn/fashion-design/

If you're looking to discover more videos / creators, I run https://channelsuurf.com. We curate under-viewed / under-subscribed channels from YouTube. If you have any favorites you want more people to see, definitely send them my way!

Really excited about what you're building! Can't wait to try out your API.

You may know these as "Magic Eye" puzzles. Here's a video on how they work: https://www.youtube.com/watch?v=v8O8Em_RPNg