The Java Index

Merging Things does not Reduce Them. It simply makes them more difficult to distinguish. It often seems intuitive that merging two methods results in a reduction of complexity. Ironically this is not true. When you merge two methods, you still have 2 conceptual tasks that can be executed by an #API. Only now, you've invented your own hidden, single use "schema" for defining them and how to invoke them.  All you've done is hide them from your declared interface. They are no longer discoverable at compile time by your compiler and knowledge of how to invoke them and what is supported is now tribal.  In fact you've added complexity and hidden critical information from the compiler. Yet this is common practice. Extremely common...  The same goes for model schema by the way.  Behavior modifiers on methods and conditionally relevant fields on models, highlight this problem. Be verbose in your contract definitions so that you don't have to be verbose over slack. #sof...

 Separate domain specific logic from framework, support or general tech specific logic.  Also, don't' write domain specific logic. :)  That sh** should be no coded.  #Software #Architecture  @MMJetpack  #NoCode

Separate Async processing compute from compute hosting end user occupied threads.  They have different scaling, security, acid compliance, eventual consistency and other concerns.  #Software #Architecture #infrastructure #microservices 

  Me, in another role, to a lead engineer on the team, who is so bogged down in code reviews now that the team is more than 3 engineers that he's become a bottleneck.   What I want to say is "You know, if we had tyepscript, we wouldn't’ need you to spend as much time reviewing. You know that right? like,  yeah, w e can be a lot more aggressive with typescript…". He felt he needed to be involved in every MR to thoroughly   vett  and scan for issues caused by a lack of tribal knowledge. He didn't catch the irony in that sentiment, given how vehemently he had rejected typescript, which does that job automatically, and near instantaneously, at compile and develop time, early in the process, and well before a complex change has come in as a merge request. Background, our lead doesn't like typescript because the first time we tried to apply it, he lost half a day trying to get  his local env building. We then had a debate on the team, on whether or not to ...

Twitter did this https://blog.twitter.com/en_us/topics/product/2023/an-update-on-two-factor-authentication-using-sms-on-twitter " After 20 March 2023, we will no longer permit non-Twitter Blue subscribers to use text messages as a 2FA method. At that time, accounts with text message 2FA still enabled will have it disabled. " Anyone who is inactive for a while, will simply have a reduction in security that they did not explicitly authorize. These people are extremely vulnerable.  This is just, bad.. really bad. Never do this. I'm curious if the motive is the cost of supporting text based 2fa. They pose it as a security improvement but if you are reducing peoples existing security levels without their express consent, that's not great. It will disproportionally affect people who are least closely monitoring their twitter accounts during this period.   It may be okay for them to say that anyone who hasn't switched to app based auth will be allowed to login "n...

Nothing helps you get your head around a problem, and convey concepts to your team like visuals.  A picture is worth a thousand words" - somebody smart said that. Being able to understand the problem(s) and the solution before ever writing a line of code is clutch. https://plantuml.com/ You want to minimize time spent discussing with other engineers? Put a diagram in front of them. DONE. It's like magic. Except more powerful. It's like coffee. #Software #Architecture #Coding #Engineering 

That's it... that's the whole post.  OH and don't use react. More on this later.  Also react hooks are not good. State management and separation of concern in react is a nightmare.  Also React doesn't read good.

Conditional blocks in code, generally mean a developer merged something.  A developer took two separate concerns, and squashed them together.  And now the compiler can't tell what data the method or model needs, because it depends. So now a developer has to read your method, or your (hopefully) well written documentation, to figure it out.  In methods, this is also highlighted by the presence of "behavior modifiers". Booleans or enums in the method signature that make the function, have another function.... In state encapsulations, these are usually fields that have different constraints or usages or meanings or requirement status, based on the value of other fields. I call this "Conditional Relevance" or "Conditional Meaning".  Essentially the developer is saying that this object  is one of two or more different objects and should be handled differently depending on what values are set on one or more of its various fields.  The problem is there again,...

 "Component Architecture" (Because I can't think of a better title ) Domain specific modules should generally not be made into libraries Generic tech frameworks can be split this way. Domains should be split vertically into #microservices. Libraries are for reusable code. If your code is domain specific it has little to no reusability TODO: More to follow... maybe

Don't build to ship, build to build. Don't ship your prototype. Iterate, on both the produced product but also the process that produces it. #Software #Coding #Engineering  

Type safe programming, is less about saving you time as the author, and more about saving your fellow and future developers time as the reader of your code. If I have to recursively scan through 3-4 ( or possibly many more ) layers of nested implementation code to understand why a parameter is used or what its constraints are.. Yeah, type safety saves you time. Also what happens if those constraints change.... Please respect your fellow devs. Use a type safe language.

 Everything is a Contract.  Methods are contracts. APIs are contracts Conceptual State encapsulations are contracts ( i.e. multi value state so non "scalar", non single value state ). Service APIs are contracts.  Framework and Library public interfaces are contracts. Internal IOC Service public interfaces are contracts.  Even the internal private interfaces are contracts to something.  SDK Interfaces Database Tables PROTOCOLS for how you actually interact with an API or database are contracts. And contracts without schema are bad. All of them. If your contract doesn't have a schema. It's bad.   Rules of Contracts No "conditionally optional" or "conditionally relevant" or "one of these fields is required" type multi-field relationships. Please use polymorphic encapsulation to declare what fields are required and what aren't, so that if something is done wrong, the developer using your library or API, knows at compile time.  What is pol...