picardo

Agree with you. Nudging is a type of user experience design. UX designers nudge with every design decision they make, and the effectiveness of those decisions is quantifiable. So it's hard to argue that all nudges are ineffective, just like one can't argue that all UX design is ineffective.

I'm not very familiar with how "nudging" is defined in the behavioral economics, and perhaps someone can enlighten me, but personally I find it hard to believe that it can be disproven that the way a choice is presented doesn't play any role in one's decision. The Goldilock principle is well-known. Most people instinctively choose the middle option, when given a three things to choose from.

Does this study imply that choice architecture plays no role in our decisions? Or am I mis-understanding it?

YouTube has a great personalization algorithm and a lot of content. Content and personalization make up a virtuous cycle, and drive higher engagement rates, which drives ad rates higher. Medium has neither the scale, content nor the engagement to be as valuable a platform for advertisers.

I think Medium showed the world that you can't build a subscription business by commoditizing the content. I've read a lot of great content on Medium, but I don't remember who it was by, and that's why I never considered subscribing to Medium. Their content lacks the personality that platforms like Substack, and even traditional online newspapers like NYTimes, possess.

I mentioned that AppSync is a different service but VTL is tightly integrated to Amplify workflow because of AppSync. If you use `amplify-cli` to generate your project, you get a folder full of VTL templates. The only way to modify the default behavior of your Amplify API is to override those templates. So I'd say it's very relevant.

Biggest drawback for me was having to use VTL to write my resolvers. Normally, I wouldn't mind using a template language for UIs, but not for business logic. This isn't Amplify's fault. They use AppSync, which made the design decision to use VTL. Until AppSync adds support for TypeScript, I wouldn't consider using Amplify toolchain to start a new project.

As an aside, you can still use Lambda resolvers rather than pipeline resolvers, but that's tedious to set up and it's also more costly than pipeline resolvers.

The creator of GIF file format spent years trying to get people to pronounce it JIF. You know, just saying... It didn't work.

Besides, EEEY-vo is more fun to say than UH-vo.

Why did you call it Avo? I'm curious because I know of at least 4 SaaS companies called Avo.

I found TLA+ syntax unapproachable as a beginner. I did more digging and discovered Alloy[0], a "lightweight" formal verification system, which is much simpler, and has industry adoption as well. It's working nicely for me so far.

-----------

[0] http://alloytools.org/

Superb tool. I used Comby to create a massive (3000+ changes) PR in which I ported JS type annotations into TS typings.

They make high quality explanatory videos, too! Their video on the Riemann hypothesis is a true gem.

https://www.youtube.com/watch?v=zlm1aajH6gY

Good luck. My family emigrated to US from Turkey in the 90s. Back then, the inflation was over a hundred percent. It costs millions of liras to buy a dollar. Now the history is repeating itself. The value of lira is tanking and inflation is running amuck. The people governing the country have changed, but the systemic rot is still there.

By that definition, any software project that is driven by a BDFL wouldn't be open source, including Linux.

The terminology hasn't drifted that much. I think there is a small and vocal group of people who are trying to take back "open source" by reframing what it means, so as to exclude corporate projects. It doesn't make sense to me.

Being assigned an office doesn't mean that it's not remote. It entirely depends on the team. I worked for a team that wanted me in office for three days a week last year. My current team is entirely remote, but I'm still assigned to an office that I can go to anytime I want, which is totally optional.

I've worked on dozens of large React codebases, and never once came across a performance problem that was caused by VDOM overhead. Performance lag was always caused by bad application design. In most cases, the performance lag was due to over-rendering caused by a badly designed component architecture and state management system.

What Rich Harris said sounds very nice and interesting, but I'd take issue with it being "not the best solution for a scalable UI." As long as the slowdown caused by the Virtual DOM remains below limits of human perception, it doesn't really matter whether something can do without Virtual DOM or not.

> VC backed companies have a tendency to focus way too much on vanity metrics.

Well-run companies focus on the right metrics. Badly run companies focus on vanity metrics. There is some of both everywhere in the business world, not just among VC backed companies.

I agree with this. The emphasis of any product that wants to democratize ML should be on making it easy for lay people to train models, and to collaborate with ML experts.

You can make Postgres scale, but there is an operational cost to it. DynamoDB does that for you out of the box. (So does Aurora, to be honest, but there is also an overhead to setting up an Aurora cluster to the needs of your business.)

I've found also that in Postgres the query performance does not keep up with bursts of traffic -- you need to overprovision your db servers to cope with the highest traffic days. DynamoDB, in contrast, scales instantly. (It's a bit more complicated that that, but the effect of it is nearly instantaneous.) And what's really great about DynamoDB is after the traffic levels go down, it does not scale down your table and maintains it at the same capacity at no additional cost to you, so if you receive a burst of traffic at the same throughput, you can handle it even faster.

DynamoDB does a lot of magic under the hood, as well. My favorite is auto-sharding, i.e. it automatically moves your hot keys around so the demand is evenly distributed across your table.

So DynamoDB is pretty great. But to get the the best experience from DynamoDB, you need to have a stable codebase, and design your tables around your access patterns. Because joining two tables isn't fun.

It might be useful for sourcers and recruiters, but the interviewers never look at your Linkedin profile.

Everyone wants to be multi-AZ, multi-cell, but it's a multi-year project, especially for services that have been around for a while. My last team had been working on it for a couple of years when I left.

MuscleWiki is cool, but it's not very helpful during a workout. I like that Darebee builds a set of routines and includes a timer into each routine to keep you on track.

NoSQL was overhyped. SQL is awesome.

> For a start, you're going to have to define your schema. Does one tree have one row or is it one case has one row?

It seems to me you're defining a schema regardless, but with event sourcing your schema is embedded in your events rather than your database. And you're putting off the reconciliation to projection phase. I get it. But you still need to worry about writing transformations for your data to bring it up to date with your latest schema... That is often the most frustrating part.

> Synchronising data at row level when offline becomes online is extremely hard to get right and reliable.

Why? Are the users in different time zones? If the time on their devices are synchronized, why is it hard to get right? I'm not trying to pick an argument with you, but trying to figure out if you've considered all the possible alternatives.

> A good example would be a tree inspection application where jobs can be pushed out to mobile inspectors who might not have phone signal but can still collect the data. Once synchronised, views are simply additive. More data can be added to cases simply by adding events.

This isn't a great use case for Event Souring either. An inspector must be in front of the tree to inspect it, right? And they can see each other inspecting the tree.... Why would several inspectors inspect the same tree?

Assuming they inspect the same tree at different times, you can sync offline data at the row level, and let the last update win, provided that they're entering the same data.

What are some interesting startups in Austin area?

Some of these questions are a bit personal. Others are silly or irrelevant. I wouldn't use them on my team.

They're like pajama party questions...

package.json integration isn't mentioned, but that is probably my favorite feature. You can add a `volta` block to you package.json with all the versions of node and npm and volta automatically installs them for you.

This is just a DOM manipulation library, with some animation support thrown in. It's doing the same stuff that you can do with a few D3 libraries: d3.selection + d3.transition.