throwawaythekey

Mostly guessing but -> duration is usually inversely correlated with throughput.

If you require high throughput and have a high duration then partitioning/distribution are the normal solution.

I agree that cloudwatch is dogturds, but want to dive deeper for illustrative purposes:

Your dynamodb solution isn't foolproof. It has throughput limited to the partition granularity -> in your case the lambda name. It's also relatively expensive and fairly slow to query in bulk (DDB is designed for OLTP).

I don't have direct experience here, but I expect slapping grafana on top of any disk basked source is likely to be cheaper, faster, and have better ergonomics. Once your logging is too much for a disk to handle (this will be later than you would've outgrown ddb, but before you would've outgrown cloudwatch) then you can bring something fancy in.

Yup. Just wanted to say that as someone who worked in the space for 5 years and attempted to integrate with google ad tech products:

1. I could never fully understand how all the google products integrated with each other.

2. The guys we talked to at google were often unable to recommend which product was correct for our use case (it seemed like there were multiple entry points but they all funneled back to one or two common sources)

3. Many of the integrations we wanted to do had no clear criteria for whether google would accept you or not. This led to us wasting lots of time.

4. Our whole company focused on an integration with google for 6-9months. When we were validating our implementation google pulled out, citing antitrust concerns. A few months later they announced a product that competed with us. As google is a big org I'm not really sure if this was coordinated on their side.

A decent portion of the Australian population think the realpolitik of our situation means we should adopt a neutral approach towards China, even if it means a weakening of our relationship with the US.

The need to act as world police (re uyghurs, taiwan) can be a game for the major powers.

> Keating said the “great sin” China had committed in the eyes of the west was developing its economy to equal the size of the US

This is somewhat supported by some of the wikileaks releases, but it's a little hard to disentangle if the economy is the sin or just an intensifier.

> At the lunch, Mrs Clinton confided in Mr Rudd about America's fears about China's rapid economic rise and Beijing's multibillion-dollar store of US debt, asking Mr Rudd: ''How do you deal toughly with your banker?''

https://www.smh.com.au/national/explosive-wiki-rudd-cable-20...

One of our former prime ministers, Paul Keating, came out strongly against the submarine deal. IIRC two important dimensions are that Australia has shallow waters which are not a good fit for the chosen submarine technology and that tactically it makes limited sense for Australia to focus on weapons to be used on our largest trading partner.

https://www.theguardian.com/australia-news/2023/mar/15/paul-...

I am not an expert on any of the above.

Not sure if you're being intentionally cheeky by pointing out a use case one wouldn't use Go for but will answer anyway.

A language with a GC (like go) typically isn't a good fit for a 3d engine. Almost all serious engines are C++, at least for the core code, for that reason.

The wiki article you are quoting from really buries the lede. To give one example in the debates there were plants in the audience to ask prearranged questions for Clinton.

https://www.politico.com/story/2017/03/donna-brazile-hillary...

Journalists consider Julian to be a journalist.

> WikiLeaks wins top Australian journalism prize... The Walkley Award is one of a number of journalism prizes won by WikiLeaks in recent years, including Amnesty International’s UK Media Award and the acclaimed Martha Gellhorn Prize. The latter award is given to journalists who reveal “an unpalatable truth that exposes establishment propaganda.” These prizes undermine the Obama administration’s claims that Assange is not a journalist and that the publication of thousands of secret US diplomatic and military cables is illegal.

https://www.wsws.org/en/articles/2011/11/assa-n30.html

The UK have already heavily bent (broken) the extradition rules in the favor of the US. I don't think the UK will mind as long as it doesn't cause public uproar.

Most notably, the UK-US extradition treaty, which has exemptions for political offenses (e.g. espionage), has been found not to apply.

This article is decent https://theconversation.com/julian-assange-how-british-extra..., but from the middle of the trial. Craig Murray's blog is also a good source of info.

I'm trying to work this out myself. Julian's wiki page has

> He was granted asylum by Ecuador in August 2012[10] on the grounds of political persecution and fears he might be extradited to the United States.[11]

It seems to me like the Trump administration simply mainted the status quo of what came before them. One theory could be the timing of the charges was more aligned with Ecuador changing PM/kicking Assange out of the embassy. https://thegrayzone.com/2019/04/14/lenin-moreno-julian-assan...

1) The common stock that employees get via options is the last in line for the pot of gold.

2) There's plenty of bullshit that can be used to cheat an employee out of their options. One example here [1].

[1] https://techcrunch.com/2011/06/26/skypes-worthless-employee-...

I'm not the GP but was one of the first engineering hires in a startup. In my case I got caught in the cross-fire of one of the co-founders backstabbing the other which meant that by the time we closed the series A I had been diluted by 80%. To 'make this up to me' the company gave me a new grant that would counter the dilution. The downsides were that this restarted the vesting clock and the new options would cost a year worth of savings to exercise - this was much more than the few hundred dollars my original grant cost.

Fast forward four years of toil with multiple cycles of doubling and then halving headcount as well as endless leadership changes. We are now on our fourth CTO in as many years. On the upside things are starting to look up! The newest sales team have worked out how to sell the original product we built, not the bells and whistles we pivoted to on the wisdom of the overpaid CPO. We can now celebrate as we have about a year's worth of runway and can confidently project being cash flow positive in about six months.

The new ex-FAANG CTO earning three times as much as anyone in the original team has great news! As a result of the positive development we are now able to hire an extra development team in South America! This shouldn't cost us too much and they can start on the next greenfield effort. The existing developers need not worry about being replaced as the existing team has all of the experience with the money making side of the business, and besides the new devs will be working on a parallel offering anyway.

Four weeks later and we've onboarded two offshore devs. The VCs have demanded we cut our burn rate and my position is being made redundant. I have 90 days to exercise but my options are underwater, both when compared to the funds we raised a few months ago and also the FMV. Essentially to buy them now I would be worse off than someone walking straight off the street.

Innovation and standards/large companies tend to be at opposite ends of the spectrum. Hence the need for startups!

I hope that you're correct however.

There's a classic blog covering this that has done the rounds here a few times. I recommend giving it a read if you don't think becoming a top achiever is possible through non-heroic amounts of sustained practice.

https://danluu.com/p95-skill/

I've become that person. In small teams a lot of magic happens and the feeling is somewhat addictive. I don't think it's wrong to long for times when the company had more output, at a higher quality, while using fewer resources. The past will never repeat itself but it seems meek to not attempt to preserve the good parts.

I'm not sure if it's unique to my place of work but most requirements are made up. If something is or isn't implemented in the final solution has no real bearing on happiness. The thing that everyone seems to be after is a well thought out solution with empathy for the users. Strict requirements get in the way of that in my experience.

I'm going through this at the moment at a startup...

I thought I could count on the charismatic leader to save my bacon by only calling on them for help when when things are visibly on fire and my own minor charisma hasn't been enough. In the end the leader didn't show up and now I've got a HR complaint against me for following up consistently when the fire didn't get put out. The whole thing has been fairly stressful because I'm struggling to understand the particular social dynamics, my best guess is it's just power protecting power, but I am naive/delusional enough to want to believe there is more to it. Now I'm taking a month off from work to try and unwind a bit.

All of that was just a long way of saying that you never know when you'll need to call on your stress/conflict managing skills, so best to keep them sharp at all times. I thought my skills were already good, but that was quickly revealed as false when challenged by tougher opponents :).

I'm still unconvinced that tiktok holds much data that is valuable to any government. As a node in the information tree it might have some marginal utility but my understanding of tiktok is that the data primarily is how much you enjoy cat videos. Maybe the chinese government can work out your sexual orientation, or that you are anti communist, but this is only a problem if you live in China.

Even if the data is valuable, as far as I know there are no backdoors available to tiktok that aren't available to other apps (e.g any tencent game). The security model at the os level seems to be the proper place to ensure privacy, and the witch hunt against tik tok seems to only exist because it is popular.

This is known as a zero bug policy [1]. I've had decent success implementing it with my team. The main advantages are:

- Prioritizing is hard, so avoid wasting brain cycles deciding how important your bugs are

- It encourages all of your team to get things right the first time, because if they don't they know they will be going back to fix it immediately.

- If you want to create a culture of quality then it's an obvious first step.

- It saves time in the long term by addressing problems when you have the most context and by avoiding building hack upon hack upon hack

In extreme cases you can relax the policy, but be aware that if you don't quickly correct course then things will be permanently worse. Also accept that hard external deadlines are not suited to this approach, but using triage some of that can be mitigated.

[1] https://sookocheff.com/post/process/zero-bug-policy/

There have been several cloudfront outages that have effectively been semi global outages

If you have the right team maybe 10M (to pay for the SaaS you bootstrapped off) and 1 year. If you have the wrong team then God help you.

It's been a while now but we saved about 10-100x moving from aurora to dynamo for a pure/simplish OLTP use case. Lost a lot of flexibility but the aurora costs were going to send us under.

We also had a few issues where aurora was giving us *incorrect query results* and aws support were not helpful. Most of the issues were denied, even with simple reproductions, and then got fixed years later (~2-3) after we had given up. We still use it today but stay away from cutting edge features, unusual query patterns, and high volume use cases.

Having said all that, SQL still seems like the correct choice for getting an MVP out quickly.

If the story is of public interest then it's fair game to run it regardless of the source (once verified)

I'm not sure if I buy this. Any sufficiently motivated leaker could just release to another source if wikileaks were blocking important information.

For consumer markets the newest AMD products (Zen 4) are great chips but simply too expensive. Logical increments [1] is pretty good at showing what is the best choice at various pricepoints (taking into account local pricing) and has Intel and AMD trading blows across the range with Intel taking the majority of the wins.

All of the tech youtubers have been making similar points lately (LTT, GamersNexus, HardwareUnboxed).

Data centre does seem to be in AMD's favour at the moment, but I don't know enough about the space to know if their advantages will be long lived.

[1] https://www.logicalincrements.com/

It sounds like you've identified the issue yourself. You are relying on ordering when processing events. You need to either loosen that requirement or do better testing to prevent head of line blocking.

I don't know much about your application but the fact that you can mitigate the problem by scaling the number of workers suggests that the order requirements might actually be fairly weak. As a worst case outcome you may be able to push all events interdependent to the one with an error to a DLQ using a temporary blacklisting mechanism, but by that stage I think I would just prefer better testing.

It would be an interesting case study for leaders around the world - confiscate a huge chunk of liberty and you will have a fringe protest, lose a few thousand pounds from chequebooks and you will have blood.

Do you know of any good resources that explain why smoothing should be used?

My intuition is that in your given example (stock prices) smoothing would probably be doing yourself a disservice as it would hide the optimal hour or day of the week to make purchases/sales.

Is it mostly related to the timeframe of your analysis and needing to trade off near term precision for longer term precision?

A possible explanation is that the mellowing is due to the loss of acuity with age. The more likely explanation is that it's an evolutionary adaption in response to how ones function in society changes with age.

If you combine layoffs the reduction in burn can be pretty significant. The exact numbers vary per company but for a startup delaying layoffs by one month can be the difference between having one year of runway remaining or one month once all is said and done.

This is not the exact link I was looking for but goes into it somewhat https://www.ycombinator.com/library/3Z-advice-for-companies-...