mpolichette

I don't disagree, but I think there is the otherside of that same coin... What if we could do other stuff while remaining productive.

Rather than the example of missing first steps, what if we had, "Ok Claude, prepare a few slides for my presentation, I'm going to watch my childs mid-day recital..." maybe you get a success/failure ping and maybe even need to step out for part of the event, but in another world you couldn't have gone at all.

I thought they were talking about one of their coworkers

/s

I've recently started writing an app intended for a raspberry pi that uses IMAP to automate this exact thing.

The goal is for it to apply the rules and followup with actions while still letting me interact with my email from any client I want.

I'd also consider that, for these people, getting away with the cheating _is the game_ for them. What they're cheating at might be less important.

Short of jail, nowhere in adulthood are you required to stay somewhere by law.

On top of that, I don’t think the kid quietly using their phone and ignoring class is the main issue here… it’s causing issues with the other kids and making the experience worse for a lot of kids.

I like the cataloging, but I dont see the periodic part of this.

Could dementia in congress create a security threat?

I tend to agree, however, I typically tell people that if you see longer function names, you should watch out for complexity. In fact, if I have to write some overly complex code that I can’t isolate for some reason, I will usually try to show it in the names being extra long.

Computers were invented to speed up calculations, and yet the primary thing we use them for today is to read the news and send each other messages and memes…

I think it’s totally reasonable, to expect developers to find the real use

I have the same rules

I think this option is still ripe for issues within a domestic abuse situation. The abuser would simply use their phone to “trust it”.

Maybe a longer dismissal though?

I always have to remind myself that they’re dependency arrows and not a sequence ordering.

They make it look like it flows right to left even though time (or at least sequence) flows left to right.

Oh, come on now, Zabzonk is a great name

I read this as “The book is included”

If you don’t fix it… and the code is working… what is the problem?

I leave notes like that sometime as indicators of intention… or invitation to the next reader… but if it never changes and is not causing issues… that’s fine, leave it as is.

I can empathize with the author here that types can be very challenging to get right, especially with high amounts of dynamism.

However, I think that saying it is "terrible for library developers" is a bit far. I think its terrible for developers who want to make use of advance types... which ultimately doesn't depend if you're a library dev at all.

It boils down to: "Typescript learning curve gets really steep after the basics"

The author mentions they help maintain redux-saga. I don't want to dig on them, but from my personal experience, that library takes you down quite an opinionated application path with complexity inherit to it. Heck, just making types for redux was a pain, let alone adding async and additional composability.

My take is that the author has chosen complex tech to work with, and that influences the complexity in their types.

I've been using Workflowy for years now. I really love it.

They been working lots of interesting features in but stick to the basics that everything starts as a list. You would be surprised what is possible w/ just a list!

MDN docs are the best... they should monetize via high level articles and example implementations for systems.

For example, the webRTC docs are great and explain a lot about how it works... however, there is very little information about good patterns for including it in your application. I bet people would be happy to pay for guides like that, I would.

I think these questions come from the idea baked into charitable giving. When you purchase a good, the thing you're getting is obvious, it is what you're purchasing.

However, when you're giving to charity, what are you getting? You probably want to know.

If charities are smart, I bet they could take advantage of this by creating classic ladders which encourage more contributions if people get a say of where a "portion of their donation" goes.

I've thought about hooking into messages w/ a running mac before... Do you have a high level description of your approach? I looked in the iMessage GraphQL Server server repo for docs but didn't see anything obvious...

On a quick investigation I noticed you are reading the sqlite db... but it wasn't super clear how you send/receive messages?

I'll entertain this...

Because, like it or not, you're often still sending/receiving documents? :)

Also the semantics of the actions map really well to the use cases still.

You're, of course, more than welcome to avoid the whole thing and use WebSockets or WebRTC data channels with a custom protocol.

I'm with you on this one. I prefer it to be in your face simple to understand over the terse-ness.

In the gist example, I actually prefer the SQL-92 approach where we are joining given an explicit comparison condition. Every other implementation seems to be trying to hide details, for what gain? Less typing?

In order to use FOREIGN, you will need to know not just what columns a table has, but also their configuration. Which would also require that you have properly configured your tables. While this shouldn't be a hard ask, it does add additional dependency and makes use of this "tool" slightly less "portable" between systems.

I have unfortunately seen cases where people will only have foreign keys un-enforced by their table config. As a dev, if you're introduced to a new DB, you wont know immediately if you can use this, and if things are configured wrong, you need to make a pretty significant change to be able to use it.

I don't see a lot of harm from adding this syntax however as people are free to not use it and it relies on an existing strict convention.

This ^

I feel like JS gets thrown under the bus in discussions, but no body talks about arcane file structures in Java or implicit pathing lookups which have the same kind of "historical path dependence" to why they exist as JS has for require/import.

All languages have their warts and 99% of the time they're all doing the same thing just in slightly different ways.

I want to agree with you... the problem arises because you're applying your values to those items... e.g. "yeah they're embarrassing/bad, but not really that bad"...

However, it becomes scary when the people with access are much less level-headed. There are people who think gay people or watching porn should require treatment. There have been power changes where people with drastically different views have an agenda to push, and your innocuous "not really that bad" is all of a sudden an imprisonable offense because you "think differently" and you might encourage others.

I hope it stays down... oh wait, that was yesterdays thing...

I used a fake name/email... went through the 22 questions and got meaningless results.

Questions get grouped into 3 groups and you get a numerical score... literally it only says "Result: 22". No scale, no units, at best there is maybe a color scheme green, yellow, red? (maybe? not for me)

At least the groups have descriptions...

I got zero info from this, it was a waste of time

It's wild that their demo is a real customer

This is a read-only view of real growth data from a Saascast customer — don't worry; they don't mind sharing it with you!

I wonder if it'd be easy to tell based on the payment amounts and whatnot who the customer is!

I don't think React is the problem here. I think communication and leadership is where fault lies.

1. Why hire a team of non-webdevs to do webdev. (on 2nd read, it appears they wanted to use the same team from the WPF app... ¯\_(ツ)_/¯)

2. If you build and treat React components and their APIs as the abstraction layer, then they're just components... who cares how they're implemented.

3. Just because the existing project is big, doesn't mean your new one has to be... split it up!

4. Redux... the root "technical problem"

My hot take is that the authors technical issues probably come from Redux and not React. Using redux as the core of your application is like pouring glue on a lego set. In an ideal world this is great because everything is strong and well defined. In reality, it prevents flexibility and applies hard constraints to the entire system.

That one choice of using redux effects the decisions you make in every component. You lose flexibility to encapsulate features and experiments. You're forced to bend over backwards to do things in specific ways.

Redux is the JS equivalent of the Windows Registry.

It makes it seem really bad when you say "Government takes".

The truth is, you're contributing back to people and the system which let you make and run a business that makes millions starting in your 20s.

I don't agree... I think browsers are not the weak link here. I'll agree they have a large attack surface, but the communication channel needs to be secure regardless of what client receives it.

the most an attacker can do is to change the content.

Sure , but I would argue, depending on on the content, that malicious content can be just as bad as malicious code. Just ask anyone who has been phished.