It's wild because saying that NAT is required kind of admits your machines are vulnerable on the LAN! You should have good firewall rules no matter what.
It's kind of funny our experiences are so diffent. I almost immediately surmised it's some sort of on the fly generated vm you can access via a ssh jumpserver. Which it is! It's actually really neat. It's quite obvious that the authors want us to just ssh into it and try it out first.
Are you honestly suggesting that startups should be picky about taking on customers?
That’s probably the oddest thing to read on a tech VC forum.
The lading page was garbage. It’s forgivable because designing goods landing pages is hard. But inventing wacky ideas about why a bad landing page might have some hidden genius, isnt constructive feedback
Why are you giving in to such a troll/AI/low effort comment. If the page was some genius implication and I were too stupid to get it then his comment had a good point. The page has a random ssh command and this dude thinks it's genius.
It's not interactive. It's just an extremely brief brochure for the actual service, which is available via SSH. All the useful copy is under the About link at the bottom, which is so light as to fail WCAG contrast standards.
I mean, I've done engineering work for the last 15 years on most layers of the stack. Seeing an ssh command into a fancy url does not tell me anything about what that is going to accomplish. But yeah, you must be right.
> After that incident, I created an incident review document and suggested a small review of the tasks that should be prioritized to prevent it from happening again. I got carried away and created an initial presentation for the other backend Chapter Leads with a backend strategy. I do not remember it perfectly, but it included hexagonal architecture, a testing pyramid with contract tests to avoid breaking APIs used by mobile apps, and more
Definitely got carried away. When coming to a new org, it's always good to learn the ropes a bit before fatiguing the team with more work, processes, and burdens.
> Definitely got carried away. When coming to a new org, it's always good to learn the ropes a bit before fatiguing the team with more work, processes, and burdens.
This is probably the single, most important advice for any new person joining a company in a (technical) leadership position. There are going to be missing things in any org, and bad mistakes, and people needing to learn new things. But also there are going to be tons of decisions that make "no sense" on first look that do have a reason behind, and to fix that "root cause" you probably need a 3 years plan and buy-in from C-level. So, trust the team you are going to lead.
God help me. Was on a project where this was used to justify so much extra boilerplate. Every class had an interface, and then we used dependency injection to supply the class to something expecting that interface. Actually, it was in Rust, so there were no classes, but that didn't stop us. Absolute waste of time.
Interfaces are only necessary to properly abstract away from implementation details that have different change driver assignments. Else it's overkill and arbitrary.
This doesn't invalidate hexagonal architecture, it just provides the actual good guideline to know if abstractions and information hiding are necessary.
The IVP provides two directives that help evaluating objectively design options, based on actual business decisional authority structure, not some guy's intuition. With the insights of the IVP, you'll be able to decide effectively.
The paper is long, but you can skip to the parts that you find interesting
Sounds like a regular setup, at least this is very common in modern C#/.NET when you implement REST services. Nothing to do with Hexagonal Architecture, just inversion of control. There is a very thin DI container baked into ASP.NET and the pipeline. Do you have to use that? No, but it gets complicated very quickly if you don't. So any project that is more than a tech demo/eval uses DI. In other languages/frameworks (i.e. Typescript+NodeJS) this is not very common for some reason.
I don't know much about C#, but in Rust this is very much not the norm. In fact, there are technical limitations associated with async traits. This sometimes allowed us a reprieve from the madness, but only sometimes. I guess you can write enterprise Java in any language.
The entire idea was to make it easier to mock components and therefore easier to test code, however all the code connecting the components became untestable, so we were back to square one, struggling to meet our test coverage quota because of the massive amounts of boilerplate.
The easiest thing to test will always be pure functions. Many people don't realize this, and how clean it can make your tests look. Provide input, get return value, assert/check it. Sure, at the end of the day you have some IO somewhere. But that will usually be a smaller part of the code base. Codebases that make testing more difficult than that, are making it unnecessarily complicated. Sometimes you depend on some library that forces you or heavily nudges you into another style, that can happen. But what one wants to avoid is a codebase, where one has to know to mock 5 other things because of their side effects.
> But that will usually be a smaller part of the code base.
Testing how IO composes makes up most of what you want to test because it's such a difficult problem. Reasoning about this in terms of size of the codebase doesn't make sense.
Thing is though, most of the high level languages have that part "solved" via libraries... Hence lots of people don't see the need to test it, as they expect the library to have sufficiently tested already. That leaves your tests mostly centered around your domain/business logic
Personally I'm just doing web api dev/backend atm and have to say that at least in this domain, pretty much everything actually hard is solved.
The only difficulty is the "interesting" architecture decisions people like the OP introduce, making inherently trivial problems into multi week endeavors which need coordination between dozens if not hundreds of devs
> Thing is though, most of the high level languages have that part "solved" via libraries...
> ...
> Personally I'm just doing web api dev/backend atm and have to say that at least in this domain, pretty much everything actually hard is solved.
You're skeptical that pretty much all high level languages have various APIs and libraries for almost all common IO tasks such as fileaccess, network requests and sockets, various DB integrations etc pp?
Trouble is that in an application the pure functions are just implementation details that don't need to be tested. They get tested by virtue of a correct implementation being necessary to correctly run the application. A library can be a little different story, as there the public interface is quite likely to be pure, but I expect most codebases found in the wild are applications. The discussion happening here seems to be directed at applications.
Granted, it appears Rust gets a lot of use as a cross-language library provider, where the application glue is written in other languages. Perhaps that's why?
Exactly. Divide the code in impure and pure functions. The pure functions can be easily unit tested. The impure ones can often be integration tested. The rest you'll just have to live with (or cover with whole-process integration tests). For tests spanning larger chunks of your code base it might be worth it to mock impure code. Never mock pure code - that's madness.
What is the default way in Rust to write REST endpoints and have the REST endpoint use/create handles to your database transaction that is bound in scope to the underlying HTTP request? (i.e. transaction lifetime and commit/rollback is linked to the HTTP request succeeding)
Often each API route will have its own handler function. That function will - usually through many layers of indirection and abstraction - launch queries towards your database.
That describe a REST API implementation design, but doesn't really answer the particular question: How is the scoping implemented, i.e. how would any given Rust REST API framework couple a Db transaction to a HTTP scope. I mean, I know how that would look like if the framework ofered you no abstraction or DI whatsoever. You would pass the transaction (and maybe database handle) through all sorts of functions, create some sort of context object (that holds all sort of references to the http connection, database, transaction and whatnot, and call everything manually. Eventually you will end up building a similar custom-made abstraction that the built-in DI container in ASP.NET does. But I would expect there are some frameworks for rust that already deliver that.
It is annoying when it is dogmatically followed, but for certain things it makes sense to have a generic interface between your business logic and specific library/service code.
Being all or nothing with it can be tedious though. Like if you are using Postgres... you probably don't need have abstracted adapters that makes it easier to run on some other DB later.
i read that and i was like hey wait a second, that's not how you do that? shouldn't you be having conversations with your team first to find common ground to help with buy in? and also learn from them about the org.
starting with a presentation that nobody asked for is a good way to be ignored.
I mean, why not? There's few drawbacks. Low power usage, high performance, stable OS that can about the same software Linux can. You get the added benefit of interfacing with Apple's ecosystem and iCloud, so you could e.g. back up your Photos database remotely. You can remote in and have a fully featured desktop available anywhere.
This blog post evokes feelings of deja vu. It's the same blog post every year by some guy with a pixel-perfect blog that's used macOS since the nineties.
The author, like lots of people in this thread are really triggered by the headline "awe dropping", and sure, whatever, but what did you expect? If they launched a foldable phone, the blog post would be all about how foldable phones don't make sense or that another brand already did it.
Then the author just skips over the new AirPods, a huge part of Apple's profits (but it's the products he "cares about the least", so nevermind, I guess) which are probably the best Apple has ever created with cutting edge improvements to sound and noise canceling, who cares about that, right?
Then he whines about the Apple Watch doing too much. He just wants it to be a heart rate monitor. Turn everything else off, dammit! Too many features! Yeah, this is the guy complaining about the lack of awe.
Then he goes on to say that it's tacky that Apple includes a segment about it saving lives (oh the horror). That's why I bought one for my parents! It's a primary use case for many. Why wouldn't you advertise that? Because sans-serif font blog guy says it's tacky? No, I'd say that's awesome – technology is saving the lives of my family.
Then he goes on to having some difficulty understanding why people would want a thinner, lighter iPhone. Yes, and where's the damn serial port, am I right? Yes, sure, the Mini was great, but apparently people want the Air, but the blog guy doesn't so I guess Apple is doomed?
Then there's some paragraphs about the declining software quality, and, yes, again, sure, while there's plenty of annoyances... have you tried using Windows? Android? If you like the Apple experience – and yes, it's its own thing, it's not for everyone – you'd be hard pressed to enjoy the alternatives in their current state.
So, summing up: Apple lacks awe but there's too many features. I don't understand why they create new products, but they're not innovative. They're doomed because there's some bugs in the software.
AirPods being a "huge part of Apple's profits" because people keep losing them, and they keep breaking, so you always need to buy a new pair every several months. Hardly a product worth praising.
Do you actually own AirPods or just assume that's the case? Nobody I know has really had to replace their AirPods unless they lose them, forget them in a pocket and wash them, or decide to upgrade after a few years (myself included). Certainly there are some people on the edges who replace them more often for whatever reason, but you might consider the possibility that they sell well because many people (myself again included) believe they are a pretty damn good product.
I get that some people don't like using them for whatever reason, but this is just a completely insane thing to say. AirPods are a technology marvel, there's a reason why they're so popular.
I get that not everyone is an audiophile, but this is just a completely insane thing to say. Bluetooth headphones aren't a technology marvel. Nor are true-wireless headphones, open-back earbuds, the AAC codec or wireless charging cases. Apple's greatest claim-to-fame is the pairing mechanism, but they refuse to let competitors even use that.
You're right: there is a reason they're so popular. They are the only headphones allowed to use all of iOS' features.
Danish politicians are famous here for their lack of knowledge and interest in IT-related subjects. Many danes have the uninformed "what are you hiding" perspective when it comes to privacy matters. Our government-built IT systems are also generally poor with many cost overruns. It's no surprise a Social Democrat politician would say something as ignorant as this.
reply