davidjfelix

My bad. I didn't realize it was my fault. Let me go help that mega-conglomerate ad company make their product bearable.

I think they're referring to firebase which sells itself as a "realtime database" or rephrased, a database designed with "realtime" (automatically updating) websites/apps in mind.

The use of the word "realtime" for web tends to trigger a lot of systems developers who use the term to indicate that you can predict the actual real world time that something will take to compute, typically used in automotive and robotic settings. That being said, I didn't invent the word and words have multiple meanings and contexts. In this context it simply means push-delivered data that is pushed when updated. /disclaimer

It seems like the org has a collection of rules, but I just now searched by the topic and got a bunch - https://github.com/topics/vale

This might not be a fair argument against this design system, since it was created to combat the inconsistencies between products in the console, and I believe it's doing a good job, perhaps just slower than we'd all like.

Having been in the AWS console on a nearly daily basis for the past 3 years, I've definitely seen some of their screens that are terrible, some services that are hard to use and I've also seen screens get worse/harder to use with design updates even if they're more consistent. Often this is followed by consistent and better functionality, but that varies per service. I definitely understand where you're coming from as it feels like support for any given service in AWS is a game of chance, but the designs are absolutely converging over time.

I usually do data sources to get access to the attribute I might need and output arns or unique ids (that will allow people to use the data source reliably) but not guess every output they might need.

I think outputs are fine and are only a smell if you have many "peer" stacks that rely on each-others outputs. For stacks that have dramatically different cadences (IE - your vpc stack vs app stack) I don't see any issue with outputting something like VPC arn. We use a naming scheme to locate "peer" references that might be smells and try to resolve them.

As part of our DR plan, we regularly run all tf stacks from nothing to ensure they stand up without issue and that the instructions for stack order are actionable. This helped us sort out early cyclic cross-references and develop a tree/DAG style multi-stack approach. When workspaces start to settle down, we typically adopt an init-style naming system for the workspace, eg: 000-prod-vpc or 010-dev-my-web-app which allows us to ensure that we recognize which workspaces occur before and after a workspace. These names are kinda hard to predict while you're writing them, so we defer that process until it's stable since changing names is more process than it's worth. Typically we advise: xyz numbers where z increments if it's a peer but after y, y increments when it depends on a parent, x increments when there are human involved tasks. Most of our workspaces are named with the prefixes 000, 010, 011 or 020 with very rare exceptions being 012 or 021, 030 etc. This helps us identify bottlenecks or late-recovery items in our stacks as well as dependent stacks.

We're talking about deprecating this naming system with the pulumi automation api to manage deploy order when we move to pulumi, but I think the way we have it forward loads a lot of operational helpers and I'm not sure if the team will push back on pulumi or not.

I want to emphasize that I don't normally use counts, it's just one tool in the toolbox. Normally I try to isolate env specific apps to their own stack and I simply don't have a workspace for the env they're not deployed in. Assuming a traditional 3 tier env setup (which I don't do either -- I only have 2) it might look like:

Workspaces:

- PROD-us-east-1-All-the-VPC-stuff

  - NAT count = 3

- PROD-us-west-2-All-the-VPC-stuff

  - NAT count = 3

- PROD-us-east-1-Enterprise-Network-Tool

  - var instance count = 2

- PROD-us-west-2-Enterprise-Network-Tool

  - var instance count = 2

- STAGE-All-the-VPC-stuff (us-east-1)

  - NAT count = 3

- STAGE-Enterprise-Network-Tool (us-east-1)

  - var instance count = 1

- DEV-All-the-VPC-stuff (us-east-1)

  - NAT count = 0 (maybe since we don't have the network tool we're transit vpcing or something else in dev)

It's a little contrived but the idea is that normally workspaces align to these borders:

- Env

- Cloud region (not always -- and the cross region ones are usually called out)

- Loosely de-coupled app border

Workspaces provide really easy "manholes" for servicing your IaC quickly when there's a mistake. They don't encourage you to manually change resources, but rather work in a smaller area and reduce blast radius. The issue I see with a lot of teams is when they're not sure how to handle cross-stack references or what they should output. I think that's an area for training and leveling up in TF.

Alternatively, consider splitting your environment up into multiple stacks which can run independently and deploy each to a workspace per env. If one env lacks the app, don't have a workspace for it.

It sounds like a lot, but it ends up being fewer files to manage and edit and your workflow can be captured in github/terraform rather than in some arbitrary file structure. It also helps prevent mistakes like updating dev and having prod rerun by accident which I've seen happen.

branch or tag from main if they have different release cadences. control the creation or non-creation ENTIRELY thru env vars with either boolean or count. If you have some thing that doesn't exist in all envs it should be obvious and maybe painful. Having to define it in the vars file makes it clear what differences each env has at a glance.

I feel like teams should be using tfe workspaces and env vars to instantiate environments rather than having a folder per-environment. It's pretty easy to replicate this workflow and results in substantially less env drift and code duplication when we do it.

It's worth noting that a lot of the early database designs, including this 2018 video pre-date some dramatic improvements to dynamodb usability.

I think the biggest ones were:

- an increase in the number of GSIs you can create (Dec 2018) [1]

- making on-demand possible [2]

- an increase in the default limit for number of tables you can create (Mar 2022) [3]

I don't think these new features necessarily make the single-table, overloaded GSI strategy that's discussed in the video obsolete, but they enable applications which are growing to adopt an incremental GSI approach and use multiple tables as their data access patterns mature.

Some other posters have recommended Alex DeBrie's dynamodb book and I also think that's an excellent resource, but I'd caution people who are getting into dynamodb not to be scared by the claims that dynamodb is inflexible to data access changes, since AWS has been adding a lot of functionality to support multi-table, unknown access patterns, emerging secondary indexes, etc.

- [1] https://aws.amazon.com/about-aws/whats-new/2018/12/amazon-dy...

- [2] https://aws.amazon.com/blogs/aws/amazon-dynamodb-on-demand-n...

- [3] https://aws.amazon.com/about-aws/whats-new/2022/03/amazon-dy...

Ah, the age old HN pass-time of feeling like everything needs to fit your niche, leaving a comment about how a website didn't fill in your blind spot for you rather than googling what something is with the time.

I've been staring at the supposedly readable and memorable uuid for like 4 minutes without any idea what it says.

Spoiler - they probably know and don't want to destroy their reliable spam channel. I turn them off and either keep the app open when I've ordered a car, or temporarily turn them back on while ubering and turn them back off when I get a trash notification. This definitely strikes me as one of those comments you see on HN that is wildly impractical at scale, but it's what I do.

There are several states that have adopted a worker-coop LCA (Limited Coop Association) law from the ULC LCA https://www.uniformlaws.org/committees/community-home?Commun.... There are also a couple of states not listed here that adapted the ULC draft to better fit existing corporate laws, for example, IL.

Coops interest me a lot because of the autonomy and I think codified autonomy is critical to longevity of health within an organization.

I think the underlying mantra is actually "if I lose compilation speed and simplicity, go is no longer the correct language choice for this problem" which is why cgo can be a non-starter for many.

Honestly I prefer Apple Maps over Google these days. This is mostly opinion and feel, but it "feels" like:

* Google is becoming less correct

- ex: "use the right 3 lanes" when only the right 2 lanes work

* Google is taking me on routes that are much less safe and more challenging

- ex: taking small side roads to a left turn onto a busy road with poor visibility and no light rather than right turns to the main road and signaled lefts

* Google is hammering me with unimportant details

- ex: I don't care that I'm on the fastest route

- ex: I don't care that something 4 hours away has a traffic jam

- ex: I don't need to be told to stay on just because an exit ramp has a disappearing lane

* Google tries to send me on wild boondoggles literally all the time. It sends me off highway in an attempt to avoid traffic, along with several other poor lost souls who are aimlessly listening to the same computer as me while we drive through some rural thru street.

So I stopped using google. Apple isn't perfect but it's unsurprising for long road trips and provides reliable instruction that follows major road paths.

> If Zoom was to one day shut Keybase down, your private key is now gone. Otherwise for security over convenience, if you store it on your own computer you're more likely to lose it.

I'm not so sure about this. Each of my devices absolutely has a key stored on it that is offline capable. Loss of keybase servers would matter but not the extent that you're claiming, from what I can tell. https://book.keybase.io/security#your-private-keys-are-only-...

its also worth noting that evicting this common knowledge from our collective sysadmin brains doesn't just leave our brains unoccupied. Now we can worry about a new class of things. Making meat available at the grocery didn't mean suddenly our lack of hunting knowledge left a void of stupidity -- we learned new things to fill that time and energy we used to spend on common things.

Thanks! I did a little research and it seems like there are some Kotlin coroutine to nio mappings (it looked like some were experimental though) and that OkHTTP is aiming to use coroutines, so I wonder if these will converge in the future.

What wasn't clear to me was if the coroutine/nio mashup still used threadpools because coroutines do.

What do you want to hear? That you're right? Communication is a two way street, try treating it like one. "To be on thin ice" is an expression which means in a precarious or risky situation, but is commonly used in reference to personal regard or favor. !!!!!!YOU'RE RIGHT!!!! (congratulations!) Java is not at risk of falling out of use - it's a very heavily used language with lots of job opportunities. Congratulations again on being technically correct. If that's all you wanted stop reading.

I'm saying that writing, maintaining and deploying Java in a manner that is fast, pleasant, sustainable, performant and desirable for developers is already at risk, in my opinion. As a developer, Java is *not* the best solution and taking away the niceties listed puts Java in a place where it is at risk of being unsuitable for the task. This isn't solely a fault of Java, some of this is simply better solutions for problems existing around Java. Java moved quite slowly for a long time and solutions filled that gap. I understand a business' desire to have a uniform programming language that they can hire for, but these days languages look very similar and polyglotism isn't that hard to find. Choosing the right language for the task is an engineering decision just like preserving language uniformity is. I don't think either is wrong, but the more people try to make Java a place that is worse than it's competitors, the more I'll favor choosing a different right language over preserving uniformity. I hope this helps clarify what I saw to be an extremely benign opinion to voice.

Nice, I haven't seen this one. We've been using Dagger to get people off of runtime DI for migrating to serverless, but I'll take a look. I assume it's compile-time DI?

The reason I'm being terse with you and perhaps a bit rude is that you started this reply thread by insulting my opinions for no reason and then continued to reply with what I believe to be both bad faith readings of my comments and naturally argumentative. I know HN values skepticism, but honestly it's tiresome. Anyways, here's my clarifying my previous comment. Please keep in mind that I fully expect you to read this in bad faith, so I've added sarcasm overtly.

Java, for me, personally, in my opinion, is on thin ice. I personally, in my opinion, would never work at a "Java shop" because in my opinion, personally, it conveys a disregard for technical suitability and individuality and supports the idea that engineers should be expendable. I believe, in my opinion, personally, that Java is, as you say, "popular" because it's forced on many workplaces by management. I don't think, in my opinion, personally, that it's a "bad" language, but its heavy use is not proportional to how "good" it is. I don't think my willingness to respond but refusal to be berated by an internet stranger is rude, and yes, I believe you have a vendetta, just like I have a vendetta against Java. If you have to use it, fine -- the above will insulate you from the really terrible things java does, in my opinion, personally. My real advice is don't use java, but see how that's a bad faith response? That's why I kept it to myself.

It's okay to have a different opinion, but personally I'd never work at a place that did that. Java is already on thin ice and this is simply how I tolerate it and how I've seen successful java teams operate in cloud environments. If you are really seeing dramatic build times, I don't blame you for investigating them, but I'm not going to forgo years of DX improvements just because I heard on the internet one time that it's slower. I'm not going to keep arguing against your Kotlin vendetta, just don't use it, I don't care.

Admittedly it's been awhile since I've written Java, so most of this is what I remember and what I've seen successful teams using -- got any links to a "true async" in Java? I was under the impression that all Java async work was backed by thread pools.

I disagree that it's easier to write than read. I tend to think Kotlin is much easier to read than java but harder to write because it tries to enforce good Java patterns at a language level.

I agree that these will slow down your build, but not significantly, and at the benefit of developer comfort to make changes. Incremental compilation largely erases these slowdowns.

* Use SDKMan for runtime and sdk management https://sdkman.io/

* Try to use Kotlin where allowed (Maybe unpopular and bad faith response given that you asked about Java, but I don't care -- kotlin's Java interop is way more seamless than Scala or Clojure to the point that its often not even noticable) https://kotlinlang.org/

* IntelliJ

* Spring is pretty popular, I've seen a lot of people using Vertx

* Square libraries like Okio, okhttp, retrofit, wire https://github.com/square

* If you're not using spring, use Dagger for DI https://dagger.dev/dev-guide/

* Overlook netflix abandonware (another unpopular opinion, I'm sure)

* Use gradle, not maven. Use kotlinscript as the config language, not groovy

Maybe I'm missing something but this repo looks like it's exclusively Javascript with no typescript.

seriously -- their development churn makes yarn and npm development look hypersonic.

It's pretty easy to derive longitude with some accuracy simply from active hours. Combine that with population densities and your guesses might get closer, combine that with how long you dwell on some videos or what videos you like and you get closer. Your Opsec isn't as good as you think, it's just nobody has been watching. If you combine statistical guesswork across hundreds of vectors its very easy to narrow your target to a creepy extent. Eliminating some easy leaks is the first step to good opsec but so is reducing your interaction and adding a little chaos.

I totally agree here. We have used Dagger in a couple of translated Java/Kotlin lambdas but for the most part, controlling your setup scripts tightly matters which is the opposite of DI.