wakamoleguy

(I'm not a tax advisor... just reading the IRS website.) The annual limit for gifts from one individual to another is $17,000 for 2023. Even so, nothing kicks in until you cumulatively gift enough to cover the "Basic Exclusion Amount" is reached, which is currently north of $10 million.

Further, that tax is payed by the donor, not the recipient.

In other words, the IRS won't care if you can't pay rent and somebody gifts you $1000.

Specifically, the site seems to follow the system's preference for light mode or dark mode. The link style against the dark mode background is very difficult to read.

In Haskell, replacing the symbolic operations doesn't imply we have to abandon infix operations:

(and (eq (subtract u v) 10) (eq (mult u v) 1)) could be:

(u `subtract` v `eq` 10) `and` (u `mult` v `eq` 1)

I’ve been finding this to be the case with the fediverse so far. I have different accounts on Mastodon and Bookwyrm, since Bookwyrm is more tailored to book reviews and quotes. But I can follow Mastodon, Bookwyrm, Peertube, and Pixelfed accounts from one main “reader” feed, providing more of a mix than I ever got on one platform alone.

I suppose one answer is that the diagram does still work for non-crypto companies. Reading the analysis that way, the simple conclusion is that they didn't see the value being created. However, it's not impossible that it could have been created.

What part of that diagram would break down for a company within the 'real economy'? Naively, if I am running a SaaS company, I receive fiat in and pay fiat out. It's the same two pipes. It's just that some of the fiat coming out is going to shareholders. The 'value' that the service is providing only justifies who the fiat is going to, not how much there is.

Yes, around 2000 they swapped the numbers. Most recent versions treat the Spy as 1 and Marshal as 10. Classic versions ranked the Marshal as 1 and Scouts as 9, with the Spy designated as S.

One difference seems to be in the size of the domain. In the interactive example, you know the possible edges to begin with, and selecting them is straightforward. The confidence is calculated based on that. For graph isomorphism, you would have little confidence that you can pull from the full set of graphs, and so you would have a hard time building confidence.

If there is a way around that, I'm genuinely curious as well.

I suppose if you choose edges at random, then it's as likely to fail early as it is to fail late. So if you get to 70% confidence, that does seem reasonable to believe it's probably 3-colorable (but still with a big chance that it is not).

With the second graph, Turbo mode often gets up to 60% or 70% confidence before detecting an issue. That seems odd, since I'd expect most edges in a graph to be colorable and only a few to have issues, so I'd "expect" most graphs to look fine up to that level. Is this an issue with the confidence equation and prior, or is it just expected that nobody would stop until they hit 99%+ confidence?

In other words, perhaps I'm just asking for the answer to Exercise 2!

And that’s ok! I am happier with my current life of balance than I ever would be with that level of singular focus. The hard part is not comparing yourself to people who have made those choices differently than you. I often find myself saying things to myself like “Sure, if I put that time in, maybe I could be like that. But I choose not to, because that is not important to me.”

Since the Y axis only goes to 80%, the chart appears at first to have a bigger absolute jump than it actually does. For example, it makes it harder to tell at a glance that there are about as many (percentage-wise) remote-not-ok postings now as there were remote-ok postings several years ago.

The actual change is amazing, though! It wouldn't be possible to tell from the posts themselves, but I wonder how many of these roles are actually filled with remote workers. Do you think employers in that middle 60% seriously consider remote candidates, or are they just including it to fit in? Or perhaps the move towards remote work has led to more postings overall.

Over time, I'm curious if we'll see statistics on tenure and engagement across remote and in-person employees. Are there similar examples from history where multiple small talent pools were (relatively suddenly) merged together into one big market?

Of course people publishing papers are responsible for the quality of the underlying data. If the data is bad, you don’t get to pretend it’s good. You write a paper describing how it is bad.

This is cherry-picking numbers to make vaccines look ineffective. It focuses on attack rate, rather than the risk of hospitalization and death, and it ignores the importance of lowering the attack rate in slowing the overall spread of the virus.

Luckily, flash isn't needed any more: https://html5zombo.com/

We should have always known, as anything is possible at ZomboCom.

It isn't necessarily any worse for public/cafe computers. Just like any login system, the UI should have the ability to remember you or not.

With the browser acting as your user agent, it can manage multiple contexts (work, personal) and let you choose which is sent to each site, without the need for separate browsers for each.

As an added tangent, consider that browsers are one of the few places where we can do things like "temporarily log me out of everything" (Incognito Mode / Private Browsing). They have some level of sophistication in session management already.

This is really cool, and its an interesting way to try to monetize what would otherwise be a relatively small service.

The big issues here are trust and security. Before using a third-party login, especially if it isn't one of the big ones, I would need to understand more of how it is handling the data. A breach in your service translates directly to a breach in mine, and the intro page does not describe many of the details.

Does using your service offer the end users any benefit compared to a third party login or built-in login service? As it stands, it seems like they will be giving their email address to yet another company, which may erode their trust in my own service.

That sounds very much like the goals of Mozilla's Persona service. While it required a separate service and some JavaScript, the idea was that it could be supported natively by browsers in the long run.

Unfortunately, it was shut down in 2016 due to lack of interest. (Coincidentally, I just spent this past week hacking on its source code.)

If it is important to the operation of the function, from an outsider perspective, the intermediate call should be tested. Oftentimes this isn't the case, though. Most often, I see intermediate calls spied/mocked when they have side effects to be avoided. This is actually a sign of tight coupling between modules, and patterns like dependency injection can help make it easier to test.

The trick for me is focusing on what the unit does from a consumers perspective. Avoid testing implementation details (unless they are important side effects), and test the behavior that does not change. If you do that, then refactoring becomes easier, because tests will only break when the contract of the unit changes.

The integration tests that you are describing behave much like I would expect unit tests to behave. Give an input, assert the results (return value or state change). The example of optimizations breaking the unit test could be either a poor test (If the function doesn't need to call that intermediate with that data, why is it being tested?). Oftentimes the spy is added to the test because there is unnecessary tight coupling between two units.

This isn't to say that integration tests aren't great, too. They all tell different stories. I like unit tests, as they force me to think about modules as units. If a unit is hard to test or brittle, it may need more attention to its design.

One trick you could use is to add a setTimeout or asnyc/await somewhere during the recursion. By forcing a step to be asynchronous, the stack count will be reset.

Rebinding `this` is the key for sharing methods using prototypal inheritance. It allows methods on the prototype object to dynamically dispatch to methods depending on the child you are calling it on.

Directors are under a fiduciary duty to make decisions they feel are best for the company and its shareholders. That's does not mean they have to do every legal thing to make more money. There are several things that may make money in the short term that are not in Google's overall interest in the long term. Imagine if they suddenly added 1000% more ads to Gmail, for example. The monetary gain would not be worth losing the users and their good will.

Now, I would hope that use of tax havens, selling user data, etc fall into that same category, but clearly the math is different when we are talking about billions of dollars.

It sounds to me like it is a temporary holdover from the earlier plan to speed up the implementation of Phase 1. The idea is that it's better not to add the complexity to parsing while the minimal kernel is figured out, and then layer it on in Phase 2 once the most important bits are working.

I do find it a little annoying personally, and it will hurt my personal adoption slightly...but I understand why they would tackle it in that order.

What about the other perspective, from the company's side? They set up their processes, expectations, and pay based on a 40 hour work week. It's great that you want to work and be paid more, but they have no obligation to be the ones to provide that. Maybe they are trying to actively discourage that feeling of animalistic competition within the office, because it will have a negative impact on the organization, external to the individual's choice to work longer.

I believe it is referring to things like stock option buybacks, so that early employees can reap some of the rewards from their equity compensation.

It may not directly help investors, who are buying into the company as a whole. It may just be an important tool to holding quality talent, to help Asana be as valuable as it can be in the long run.

However, from a monetary perspective, the investors are willing to buy in today at $1.5B. Option buybacks are usually at less than full valuation. Employees are trading value for a sure payout today. Therefore, using the money to buy back those options from early employees reduces outstanding shares and options and improves the value of remaining investors' ownership.

Ex-Asana here. Asana has written about the lack of leveled titles in the past[0]. I believe the use of titles is a separate issue to pay transparency. At around the same time, there was an effort to improve the transparency in pay bands. I have since left (for unrelated reasons), and so I cannot definitively speak to whether that was successful.

[0] https://blog.asana.com/2017/03/job-titles-asana/

Yeah, I wish I could call myself an expert there, too, but I've still some exploration to do before I'm really happy with how I have it set up, let alone recommending it to others.

Awesome that you're here responding, though. Great post, overall! (Sorry if my points were mostly critical...I glossed over the parts I liked.)

This is OK. It compares some of the features of Web Components and React components as they stand today. Having recently used Web Components in a side project, I will say that I wish it touched more on how to give Web Components reactivity. The author touches on data binding, but doesn't really go too deeply into what will be one of the most customized (ergo hard to maintain) pieces of the VanillaJS code.

Polyfills also add an interesting twist. You can use them to enable Web Components in Firefox, but they mimic shadowdom behavior imperfectly. You need to be very careful of how you use CSS in that case.

Lastly, there seemed to be some gotchas in ES6 module loading a few months back. Perhaps those have been fixed. At the time, I found it hard to debug modules that failed to load.

In any case, I'm always happy to see Web Components and more powerful/useful features being added to JavaScript in the browser. Frameworks like React serve useful purposes, and it's great that we have a platform that allows us to move quickly and bring new patterns to life without waiting for browsers. In the long term, though, I will always be an advocate for standards and making vanilla implementations feasible.

Awesome, thanks. My searches must have missed these, as I was focusing on UV radiation rather than outdoor activity. It looks like there's still a ways to go to understanding the causes of myopia.