rio517

Really wish they had shared more details. It was so high-level that we didn't really learn anything substantive.

They say they are collecting the water, not dumping it. They say they even collect rain water that lands in the ponds in case it is contaminated.

The https://elixirforum.com/ might get you quicker/better answers.

Gattaca, because so many people limit themselves by what they think is possible.

Great. Now Samsung can put these on my Frame TV and charge me $5.99 a month for the privilege of accessing them.

Isn't this concern independent of the language?

Requiring me to churn out 3-5 features a week in the first 6 months is the best way for me to hand my resignation a mere two weeks after starting.

Seems like a slap on the wrist.

Seems like the right call to me. I really know almost nothing about this case, but seems like gofundme isn't doing something illegal and the officer hasn't been convicted. Are folks presumed innocent in France? Even if he is convicted, does that blacklist his children as being unworthy of support?

No everyone is aware, but SpaceX mass to orbit is close to the rest of the world put together. Hey are massively reducing costs to access space. The point of the starship is to continue to reduce costs.

Perhaps I'm missing something, what are the enormous environmental consequences? Are you referring to just those from the photo? I feel like a fishing trawler does more damage every day than I see in these photos.

I don't know.... I would imagine they have a lot of control. After all, the engines nozzels rotate. The entire areas was empty of people and they were aware of the high probability of an explosion - potentially before lift off. There was a ton of assumed/acknowledged risk, all of which was eventually signed off on by Nasa(?) and the FAA.

Imagine being one of the companies impacted by this. It becomes a lesson in not partnering with Google.

It kinda feels like you're searching for attack vectors. Maybe that's not what you mean. ??

Either way, the avg person productivity bit is rather subjective. I picked phoenix/elixir. It helps me be productive. Good for me. Maybe you'd pick something else that you can be maximally productive in. That's great! We're both productive! ... It isn't a zero-sum game.

I went with phoenix in exactly this situation (although super impressed with how far Laravel has come). We have been enormously pleased with our choice and productivity.

Disagree with the advice your responding to, but I really don't agree with the premise of being a sloppy programmer... "Not sloppy" is faster at anything except prototyping. Coming from a different starting point probably has a lot to do with my different conclusions.

Edit: Grammar/Spelling

I moved to bitwarden and was happy at first, but after a while the app UIs were really annoying. They save/update password functions kept messing up and I would lose the password.

I eventually decided that the UI was too clunky to move my whole family onto and opted for 1password. Very happy with that choice.

I'm amazed at how few ad pages there were.

Cool website. So you want me to subscribe to a news letter so I can book a train? Very confused.

Came to these comments to figure it out. The following important bit should be more obvious.

In 2024 we will launch the first line from our Paris hub. This will lay the foundation for our ambitious plan to create a network of more than 10 destinations, each between 800 and 1,500 km from Paris.

You think he didn't build anything? He wrote the code for his first startup and is the Chief designer at SpaceX. Listen to some of his interviews, especially by everyday astronaut. He is indeed the Chief Deigner.

I don't think he is a good marketer - he is more middle of the road. I think people say that to discredit him. Have you watched any of his full length presentations. He is terrible. What he is good at is having a vision he believes in. He sells that well.

I struggle with a lot of the arguments made here. I think one key thing is that staging can mean different things. In the authors case, they say "can’t merge your code because someone else is testing code on staging." It is important to differentiate between this type of staging for development testing development branches vs a staging where only what's already merged for for deployment is automatically deployed.

Many of the problems are organizational/infrastructure challenges, not inherent to staging environments/setups. Straightening out dev processes and investing in the infrastructure solves most of the challenges discussed.

Their points:

What's wrong with staging environments?

* "Pre-live environments are never at parity with production" - resolved with proper investment in infrastructure.

* "There’s always a queue [for staging]" - is staging the only place to test pre-production code? If you need a place to test code that isn't in master, consider investing in disposable staging environments or better infrastructure so your team has more confidence for what they merge.

* "Releases are too large" - reduced queues reduces deployment times. Manage releases so they're smaller.

* "Poor ownership of changes" Of course this happens with all that queued code. address earlier challenges and this will be massively mitigated. Once there, good mangers's job is to ensure this doesn't happen.

* "People mistakenly let process replace accountability" - this is a management problem.

Solving some of the above challenges with the right investments creates a virtuous cycle of improvements.

How we ship changes at Squeaky?

* "We only merge code that is ready to go live" - This is quite arbitrary. How do you define/ensure this?

* "We have a flat branching strategy" - Great. It then surprises me that they have so much queued code and such large releases. I find it surprising they say, "We always roll forward." I wonder how this impacts their recovery time.

* "High risk features are always feature flagged" - do low risk features never cause problems?

* "Hands-on deployments" - I'm not sure this is good practice. How much focus does it take away from your team? Would a hands-off deployment with high confidence pre-deploy, automated deployment, automated monitoring and alerting, while ensuring the team is available to respond and recover quickly?

* "Allows a subset of users to receive traffic from the new services while we validate" is fantastic. Surprised they don't break this into its own thing.

Our team uses notion as well. We're not at the scale that you are with owned pages , expiry. How does your team feel about the effort-to-value of maintaining it? It seems rather onerous.

We tend to keep more ephemeral project management stuff in our tracker or google docs and more long-lived content in our Notion tool. I'd be curious how your team balances that.

Living in Berlin, 60k isn't really possible anymore for new hire. I bet there are people in their old jobs making that much, but for our backend hires we had to offer around 70 to find people.

I thought I'd find you in here! Wishing you well friend.

-Mario

What's your take on Elixir/Phoenix?

I really hear you on the product quality, but that is more the result of business systems.

I find it so frustrating that I struggle or fail find quality products - for everything from forzen pizza to jeans. For some cases (frozen pizza) I just opt out. Others, I just give up and accept that I'll have to replace my jeans every 2-3 years. I try to buy recommendations from Wirecutter and do slightly better, but still so annoyed that everything is made so damn cheaply.

We can look this up quite easily, right? Looking at the past 5 years, I don't see any crashes on/around Thanksgiving

Wow. That works like really poor technical leadership. Fixing flaky tests (as opposed to deleting them) is indeed time consuming, but it is a far cheaper choice than getting to the point your test suite is untrustworthy.

There may be a point where the cost of ownership for a specific test exceeds its utility, but the way to resolve that is usually to reevaluate your code and supporting tests. Suppressing flaky tests seems a very unwise choice.

Perhaps under extreme circumstances and with unhealthy code bases there may be a case for this, but I struggle to imagine it.

Didn't they say their operating margin is 14.7% and automotive is indeed close to 30?

That's good to hear.

Oh man, https://github.com/elastic/elasticsearch-py/issues/1734 is a disappointing read. I know ES wants to save their business, but alienating users isn't exactly the path to success.

I think I saw this one. In many cases there are some crazy good, purpose built solutions that are better than what Erlang/Elixir can offer, but that requires learning and managing all that tooling. Often, good enough is fine - especially for small productive teams.

I'm on my second team that has adopted Elixir and it has really helped our productivity being able to keep so many capabilities in one kit.