tmstieff

It does use React for rendering the terminal UI.

I have the same issue. It gives this very weird minor sense of public speaking anxiety where I almost feel the need to write down what I'm about to say, which negates the whole purpose. Only solution I've found is using push-to-talk with some of the system wide STS applications.

The easiest alternative is using a where clause and filtering by an ID range. Eg: "WHERE id between 1000 and 1200". But this introduces a ton of limitations with how you can sort and filter, so the general advice of not using LIMIT and OFFSET has a ton of caveats.

Firefox also started moving away from a shared memory model towards sandboxed tabs during that period, which had an effect on memory consumption.

Curious if you're referring to Maya the 3d application or something else?

This seems like an outrageous statement on its face. They probably have React on their resume because that is where the job market has drifted. No one is getting hired these days, even at old-school Fortune 500 type companies, for listing "Java-Server-Pages" or "Jinja SSR templates" on their resume for a frontend position.

Good point, I immediately read it and replaced "role" with programmer since it was posted on HN.

Isn't the point of having a PM to bridge the gap between leadership that knows the domain of "it" and IT who knows how to implement general business needs onto a technical solution? Of course that would require having a PM to begin with, instead of expecting your developers to become subject matter experts in your obscure domain.

The article actually argues the opposite. Developers should move their focus to integration / "real-world" tests. The major summary bullet point being:

"Aim for the highest level of integration while maintaining reasonable speed and cost"

My experience mirrors the author's. In any "real" business application, the unit tests end up mocking so many dependencies that changes become a chore, in many cases causing colleagues to skip certain obvious refactors because the thought of updating 300 unit tests is out of the question. I've found much better success testing at the integration level. And to be clear this means writing a tests inside the same project that run against a database. They should run as part of your build, both locally and in CI. The holy grail is probably writing all your business logic inside pure functions, and then unit testing those, while integration testing the outer layers for happy and error paths. But good luck trying to get your coworkers to think in pure functions.

I'm working on a codebase that evolved at the same pace as React, but without any thought for idiomatic principals. As a result, you have class-based components, purely functional components, hook based components, HOCs, Redux state passed in through the older functional way, Redux state passed in through an HOC, styled components, traditional CSS styled components, and anything else you can think of that was in vogue at some point. It's a mediocre code base that generally works as advertised, but the performance is trash due to misuse of styled components, and the state management is a nightmare to traverse. I think this is the reality of a lot of 3 - 5 year old React frontends, and it has definitely soured my opinion on React / Redux a bit. I'm not sure if this effects other frontend frameworks as much, but it does seem like React was always pushing for a "new way to do things" every year.

I think I agree with you as well. Although it is hard for me to picture exactly how you've structured your dependency graph. In any case, extracting the business logic into some sort of static method / class has definitely been one of the only useful things I can carry across projects that works in nearly all use cases. It also makes unit testing the actual business logic extremely easy. That said, you can end up with a static method that takes 20 parameters, which is always fun. But, in those cases, you are lefty dealing with complexity that is intrinsic to the business, rather than complexity introduced through some bad architectural decision, so at least it is isolated.

I've tried this now on my 2019 Macbook pro, and my 2018 Thinkpad T480 running Linux. On Mac, I can't say I really noticed a difference. Also there were quite a few font rendering issues that were resolved with whatever patches Jetbrains has applied. On Linux, certain actions are definitely faster. For instance, Ctrl+Tab to either quickly tab switch or bring up the tab switcher menu was always instantaneous, where-as beforehand there was sometimes a pretty long delay.

SHA-1 collisions have been proven as an attack vector for a few years now.

https://security.googleblog.com/2017/02/announcing-first-sha...

Anyone have production experience with Crystal? I know it's not 1.0 yet, but there are some fairly mature web frameworks available that make the language look pretty attractive.

Germany and Sweden are the top 2 most litigious countries in the world, so I guess perception is off.[1] The USA is still in the top 5 though.

[1] https://www.academia.edu/35495485/The_Most_Litigious_Countri...

I've been on a few projects now that attempted to implement most of these patterns wholesale. The idea is simple to grasp and implement with a small team, but it's been nearly impossible maintain any cohesion for larger organizations. Most enterprise programmers are at least familiar enough with MVC that it's not an issue. But very few in my experience have actually worked on a project that adopted DDD. Some have never even heard of it.

Personally, even following all the guidelines laid out by the famous book and other ancillary documentation and articles, such as this one, the whole thing can fall apart quickly when you have a business requirement that doesn't match your technical architecture. You will at some point have to cross-contexts and communicate between domains. In Martin Fowler's article, this is literally hand-waved. I think there's maybe a few sentences on it?

Here, the suggestion is to use 'event storming' to make sure you design your services correctly from the start. Okay, what about if your business pivots your initial assumptions are wrong. Our team has adopted an action approach, but it goes by different names (channels, user actions, business actions) which model a single action and compose sub-actions from different domains, usually in a single transaction. This seems to work, but now we're operating in some non-aggregate space that couples all the domains.

So basically, the most difficult to manage and complex scenarios, where you model your cross-context flows, are never described beyond, use async (not always possible) and re-organize your services (also, not always possible). Would love to hear if anyone else has any experience here, or maybe I'm missing some fundamental part of DDD.

The article mentions they had someone else sit in on the test rather than take it themselves.

Seems many commenters missed this statement. It's also troubling how common it is to hear assertions that async is king especially on projects where your future scale is unknown. Based on https://web.archive.org/web/20160203172420/https://www.maili... presentation, it looks like there is a stronger case for a sync model as the default.

The left hand side only reserves the memory, the right hand side actually initializes the object. A bit redundant I agree, but to the compiler it is two atomic operations.