Edit: you can find a cheat sheet in this post
The use of coupling in the physical world is connecting two shafts to transmit torque. Coupling can be rigid or flexible. Gears can be used to exchange torque for speed. A clutch in your vehicle with manual transmission allows slippage between the main shaft and the gearbox to allow force to gradually build up not to halt the engine, and to synchronize the gears during shifting. A torque converter in your automatic transmission vehicle lets you stop at the red light while effectively still in gear.
What would be your…
My best microservices experience is running a dozen of services on a single machine and I have learnt a lot about eventing.
In the past year I have been part of a big team engineering software for self-service checkouts.
Full disclosure: This article by no means represents the opinion or views of the company I consult for.
These things, not specifically this brand:
Nowadays every checkout in the world has to support:
Suppose a startup with huge ambitions and lots of venture capital, or an established firm that fires up a new project that will solve everything. When project stars from ground zero, business and product people see themselves as the driver of a great product. They want to have every feature, and envision a great success the new software will bring when finished. Engineers think same. They see an opportunity to create the perfect system, an engineering marvel they will be proud of, that can be a highlight in their carreer.
The bigger the scale and budget, the greater the ambitions…
Disclaimer: Please don’t continue if you are easily discouraged by cynicism
The term microservices has been around several years now. In the beginning it was a way of creating distributed systems that are more agile and less monolithic than the old-school SOA architecture. SOA was about connecting big monolithic systems with big and robust ESBs and batch jobs. Whereas in microservices you would have smaller and leaner components with more p2p connections and dumb channels.
But nowadays I really dislike the terms Microservices or Microservices architecture. I rather say, a distributed architecture. I don’t like it because when people started…
When you start creating a CI pipeline, you have to recall your knowledge about the different kinds of tests you know. You do some research, you realize you will need some functional and performance tests, some unit, component and acceptance tests, you also need end-to-end tests. Then of course these are all automated (as opposed to manual tests), then you go further down in the methodology, you encounter black box and white box testing and so on.
Whenever I read an article about testing, I have always felt that terminology is unclear, and one term can have different meanings depending…
Just to get it straight: It’s Jakarta EE now :)
Popular belief is that Java EE is only for the big, monolithic, legacy applications, whereas Spring Boot is for the microservices and cool new ventures, startups. (Not considering non-java stack now). This belief also drives fundamental technical decisions in businesses and projects.
I don’t think today (end of 2019) either of them are more technically superior to the other. If you can solve something with Spring Boot, you can also solve it with Java EE and vice versa.
Disclaimer: This post is not about which one is technically better and…
At one of my previous jobs we started a greenfield project with small team (about 10 developers) with an anticipation to grow to 30–40. It was what I like to call an ‘enterprise-grade web application’ with heavy server-side logic. I was in the backend team in a technical lead role. There were some key strategic decisons about technologies in the beginning. We would go for a microservices architecture, using Java EE specifications (no, the point is not whether Java EE can be considered microservice :), Maven, a couple of Python-based services. Our services would be delivered as Docker images. …
You have a legacy software project or one that started only a couple years ago. You choose the technologies that were considered mature or maybe cutting edge at the time. But today there are newer frameworks, tools, servers, libraries, concepts available that are hot and trending.
Should you switch?
Deciding which tool to integrate into you technology stack is a delicate process. It should be preceded by careful research, comparison and proof of concepts. Upgrading surely brings new challenges for developers but what benefits does it bring beyond the technical advancements?
Good engineers don’t like to waste their time with…
Engineers, programmers work best when they can immerse in tasks, solving a particular problem for several hours without interruption is when they can perform the best. But as a tech lead or mentor, you have to step up, your task is not to be the best engineer but to be a force multiplier engineer who facilitates the work of others, who can make others perform better.
The more senior you are, the more considerate you must be about your behavior. Junior and professional colleagues will seek your advice, copy your actions, try to learn the skills you know, and listen…
Software engineer, technical lead. Interested in distributed systems and soft skills. I don’t have to prented to be always right, I just am.