I'm really missing something like Cisco DMVPN. A VPN mesh between different routers where all routers have a connection to each other, so that all traffic doesn't have to pass through the hub. And that runs on a router, because all these solutions only run on a regular computer with a complete OS.
I'm a big fan of Guava's EventBus. Easy to implement and straightforward to understand. This library does seem to require more setup and I don't see the immediate advantages, also why does it require an instanceProvider? I don't understand what that does.
Emissary really shines if performance is a top priority.
The setup is more or less similar, you register a bunch of event handlers when initializing the library. The main difference is that, in addition to events, Emissary also supports "request" messages. Requests enforce the invariant that only one handler should handle it - if there are multiple handlers registered for a given request, Emissary will throw an error. That, and some extension points which is only needed for more advance use cases.
The InstanceProvider allows users to let the dependency injection (DI) framework of their choice instantiate the request/event handler classes (see https://github.com/joel-jeremy/emissary?tab=readme-ov-file#e...). This is in contrast to the way EventBus does it where subscribers need to be instantiated at startup time. By leveraging the DI framework, additional services can be injected to the handler's constructor.
Even on desktop it's terrible, I wanted to protect some private keys of a Java application but there is no way to talk to a TPM using Java so handsandshouldersup gesture.
The TPM needs a way to authenticate your Java application, since the TPM otherwise does not know whether it's actually talking to your application or something pretending to be it.
This means you generally need an authenticated boot chain (via PCR measurements) and then have your Java app "seal" the key material to that.
It's not a problem with the TPM per-se, it's no different if you were using an external smartcard or HSM - the HSM still needs to ensure it's talking to the right app and not an impersonator (and if you use keypair authentication for that, then your app must store the keypair somewhere - you've just moved the authentication problem elsewhere).
What happened to me is I passed a date to an external library, and then after that library did its work, that date was changed. Super annoying even if you know that it's a mutable object.
That almost sounds insulting. Like management is the only party with vision, drive and a goal and everybody else is just there to help. When often management just manages and true innovation really comes from people of all positions.
On the contrary, it is a helpful term. Before the term, it was common to ask "are you a manager", and then you were defined oppositionally, as not-a-manager.
Whereas IC having its own identity means it has many positive connotations. "I'd much rather be an IC, so I can get things done" etc. You can still be very senior without having direct reports or having to do line management, often seen as a necessary evil.
In my reading it makes it easy to even spin managers as the bad ones: ICs contribute individually and directly something of worth. Managers contribute only indirectly via ICs.
The term isn’t used to define everyone who isn’t a manager. It’s used to define people like Lead and Principle Engineers who are a subject matter expert, have influence in defining a project, but have chosen to continue in engineering roles rather than switching to management. Often their position in the company is parallel to the managers rather than subordinates, hence the “individual” part of the term.
This requires the intentionality of the organization though. They seem to default to managers make the decisions. Ideally, managers manage people, IC execute and you get the "right" people in the room to make decisions, regardless of title or track.
> This requires the intentionality of the organization though. They seem to default to managers make the decisions.
if a company doesn’t intend to utilise IC then they don’t have ICs, just regular software engineers.
An IC is only an IC if the organisation is structured to utilise them as an IC. It isn’t a job title, it’s more to do with how an individual is utilised in a company. It’s their placement in the org structure.
> IC execute
IC plus engineers execute. IC are a subset of engineers.
As @hnlmorg mentioned, the term is only typically used for people who are at a level where they could be managers, primarily supporting others, but are instead still contributing directly themselves. It's almost the opposite sense from your "insulting", in my experience.
SME and IC are functionally different. SME informs, IC creates. Often, IC aren't SME in the space they're developing in, because they're SME of the technology instead of the business.
That's fine to do that, but kind of pointless. Everyone is then a "SME" in their own job space and thus the term is kind of useless. So, just replace every mention of SME outside of your company to "Business SME" instead of "Technology SME" and you'll understand what we're talking about.
Or, if you truly do not need anyone but a "technologist" to deliver product, you must work in a pretty simple business space! I work in healthcare and our PhD's and MD's have a very, very different knowledge space than I do, I and I deeply respect their contributions.
This whole thing reminds me why I never wanna work for someone again. From what I saw at Google it all just ends up being classist top-down BS of who isn't allowed at the big kids table, or bottom-up BS by insisting they aren't the SME just the IC and we can't do anything until the XYZ PM SME TL and/or manager approve.
It is unparsable Dilbert nonsense to anyone outside of specific scenarios. And it causes interminable discontent. Because what if the SME is the PM because they know business and tech but the SME is actually the IC because they know the tech and its tech but what if the manager is actually the SME because they're running the tech and may need to redelegate if the IC needs vacation, blah blah blah.
(job history: college dropout waiter => my own startup, sold => Google for 8 years => my own startup)
I'm sorry you've had bad experience working with other people, but in my experience as a developer, having multiple SME's available is indispensable to real alignment and fast development. I've primarily worked in startups, not big companies, and have often worked in healthcare. In healthcare, you get beyond your "I'm a big smart engineer" ego BS and you are willing to listen to the PhD's and MD's that help inform clinical workflows. From my perspective, I would never ask a clinical researcher or a doctor to understand our react app, and they aren't going to ask me to have deep understanding on medical details and clinical workflows. We work together to deliver high quality useful software quickly.
My PM SME validated my workflows and I found Jesus in them then my MBA TL PhD…bla bla bla.
A human being who avoided corporate brainrot just writes “I worked with John and he was indispensable because (insert reasons you wrote here)”
I’m 37 and never heard of this acronym. That’s the entry-level version of my point. Not that other people hurt me or people knowing things is actually bad.
True. It is part of the general industrial ritual of reducing workers to a number or a letter combination. That way, managers reduce the emotional attachment to the people, and they can fire them more easily.
If, instead, you would be Tom, Bill and Biff, there is a risk that the manager would build attachment, and make it harder to treat you bad. If you're IC1, IC2 and IC3, you can be exchanged like machine parts when you break, without anyone crying.
No that’s not really how it works in tech at all. There’s a deep recognition that individual engineers (and other functional practitioners) have important knowledge and expertise that is essential. Of course you do need some overlap and redundancy so that people can take sick days and avoid the wheels falling off through attrition, but competent shops aren’t ever treating people as numbers. To the contrary good ICs are widely recognized as being much less full-of-shit then management.
I'm still using it to distribute/update production apps and whilst the script language is a bit funky, it works reliably. And the tools work under Linux too, so I can easily integrate a "create setup" step in the CI/CD environment.
reply