Martin Bechtle

To the authors: I did the certification for the associate level a few years ago, in java 7. I prepared myself with a similar book and had a great score.
But even though I scored well, I found that the exam questions were quite harder than the questions on the book. What steps did you take when writing your book to ensure that the mock exams (which I'm assuming are in the book) are as close as possible to the actual exams?

I disagree on that. First of all there is no standard: JavaEE and EJB is just one of many options. And even if it was, your choice should not be based on the fact that it is a standard, but rather if it is the right technology for your use case. And if you are using it successfully, probably it is! But I suggest that any developer should try to acquire a deeper understanding of how different systems compare to each other and choose the right one for the job, even if it's not the standard one. Another thing you might want to take into consideration is documentation, community support, ease of use, etc... For example, tool X might seem right for the job, but then effectively it might be a nightmare to use.

And finally, another criterion is future proof-ness, which is where in my opinion EJB fails. For the rest, I think it's fine, especially if you know the internals and use it with care, avoiding things that can make scaling up hard (thinking about stateful beans and the need of clustering application servers rather than having a stateless design).

EJB was the most used technology in 2006 maybe, but things have fortunately quite changed. I believe Spring framework is now leading. And by the way Spring 5 works quite well with kotlin

That's an interesting one. I'd be interested to be other people's responses. In my own experience I had to deal with REST API's backed by a relational databases in a multithreaded environment (Tomcat). Some operations were a bit tricky, like
- retrieve something from the database
- if already exists update
- else create

Which would have been relatively easy with native queries but using ORM we had to deal with potential concurrency issues when 2 same requests came in at roughly the same time. So even if the code itself was not using concurrent API's, we had to deal with this race condition due by a shared resource (the database). Due to its remote nature, the network latency exacerbates the race conditions.

So essentially we ended up writing junit tests that would bootstrap our Spring application and start hammering in some kind of deterministic way with a number of threads, to make sure these endpoints were solid enough. Something very simple with a RestAssured client and a CountDownLatch and some proper try/catch/finally.

I can only speak for the java environments, but the concepts apply potentially everywhere. Keep your knowledge fresh. I've seen lots of people still sticking to old technologies like EJB and JSP and having no clue on stuff like Spring Boot, REST API's, microservices etc. Learn concurrent programming, become a guru in performance, dig deep and understand concepts like aspects, proxies, go in depth of how ORM works, when it acquires and releases connections, the different transaction isolation levels. Go further and understand distributed systems, service oriented architectures, eventual consistency, messaging. Also, work on your skills: how quick are you able to work? Is your code easily readable and maintainable? Are you able to design tests that efficiently catch regressions? Are your integration tests reliable enough to go and push the code in production?

That, mixed with some talent, will make you a really hot senior dev. And, once you get proficient also on operations (aws, docker, kubernetes, nginx, security, linux...), you might even try and go for higher positions than developer.

And don't underestimate Ritchie's suggestion, it's a very powerful method

Hi Sameer,

I have an interesting question for you. Let's say I'm a software engineer and I want to make my way up to lead enterprise architect. What's the most useful knowledge to gather in my next years working in an IT organisation? Fortunately, having studied at the university, and having worked as a freelancer for many years, not only do I know my programming languages, frameworks and design patterns, but I also have good knowledge of networking, operating systems, hardware, remote server management, cloud, etc.

What I've noticed is that even though one could study things in theory, like SOA, microservices, integration patterns, etc, you really become able to make important architectural decisions, and explain how to implement them, only when you do things in practice. Making things in practice will make you appreciate pros and cons of one approach vs another, and makes you really understand why certain patterns exist, both in software and architecture. For example, you can explain people in theory how to do dependency injection, mocking and unit tests, but only experience will make you good.

Since I'm working as team lead in my company, I have the luxury of being involved, and thus learning and becoming better, in both software implementation and design and even operations. So, among the many exciting challenges I might be facing in the near future, which areas would you suggest for me to focus and from which I can get the most bang for the buck? Security? Operations? Infrastructure? Integration patterns? Database and domain? Big data? Analytics? Strategy? Project management? Etc...

Sometimes I have the impression that, in order to make it to the top levels of an IT career, like chief architect or CTO, it is important to be (or have been) a decent programmer, but it seems that other kind of skills are relevant to these higher level tasks. If that's the case, I'd rather not spend too many years of my future career on programming. Although, sometimes it feels like programming is the best way to get your hands dirty and really understand stuff like test driven design, microservices, good db performance, continuous delivery, distributed computing, concurrent programming.

Any advice is highly appreciated. Thanks for your time.

Best Regards
Martin

I got  a purple mooseage for winning the book and replied on the 18th of September from my email. But got no response. The purple mooseage suggested that the goat might have eaten my email and that I should ask here. Am I in the right place?

Hi,

I'm quite allergic to paper. But I also hate the kindle format. Is the book also going to be published in PDF?

Hi, I've personally never used agile methodologies with my team mates. But I did sometimes do pair-programming with one of them, in order to teach a new framework under my supervision. This is a technique used in Extreme Programming, and I noticed it's mentioned in the udemy course.

What I have noticed is that, when two people are working on the same code, given that they are skilled, the quality is higher, because almost no bugs make it through and the architecture is well thought, and the speed of development is also higher, because less time is spent debugging or researching solutions to problems.

I was wondering though, in your experience: is this overall better quality and higher speed able to compete with two independent programmers? I mean, cost wise, pair programming can be quite a burden for the client's budget. But do you think that in the long run, and using the technique only for specific parts of a project, pair programming can be more convenient rather than more expensive?

Thank you. Kind Regards,
Martin

Peter Ja wrote:You can check whether Spring is building the count query by looking at the result type of the query:
if (query.getResultType() != Long.class && query.getResultType() != long.class) { //specify join fetch }

Oh dear, it was so darn simple. Thank you very much!

Hello Andreas and Michael Wittig,

Recently I've tried Heroku, which is really great because you put a few dynos online and you really forget about your deployment, it just runs! No maintenance, no load balancer configuration, easy to use, see logs and upgrade.
Although I must say that I'm not glad with the pricing and the flexibility the platform gives you. For example, you only get 2.5 Gb dynos and then directly have to jump to 14Gb as the next step. Also, for memory-intensive applications the pricing model is a real disaster.

I've had some experience with Amazon on the other side, just ran and configured a few EC2 instances, so basically IaaS. I was wondering if it is possible to easily use amazon as PaaS instead. I know for sure that there are great services like RDS for the data layer and Elastic Beanstalk. So here is the question: is it possible to easily set up and run services with Elastic Beanstalk in a kind of Heroku/Openshift way, in which you just publish the new release of your application, be it via GIT or a docker container, and then just forget about it? Which basically means having an infrastructure which automatically takes care of balancing all requests among available instances, which will of course be more than one for high-availability, and an easy way to deploy the application, like just uploading a docker container somewhere.

And of course, the most important question: does your book cover this particular topic?

Thanks for your attention.
Best Regards,
Martin Bechtle

Hello Craig,

I have a question about the Spring ecosystem, particularly now that Spring Boot is out. Have you ever heard about the Symfony2 framework? It's an MVC framework done in PHP, working very similarly to Spring because it is based on IoC. A few of my friends use it and are incredibly productive, because of the bundle system. The framework is built in such a way that you are able to create easily reusable code, even for entities, repositories and controllers. And it is super easy to customize such code by extending classes or changing yml config files. So what happened is that a major part of the PHP community started publishing bundles on github, and there is a bundle for virtually ANYTHING, from CMS to user management to paypal payments, order tracking etc.

A great example is the FOSUserBundle: it gives you right out of the box a User entity, already mapped to the database, it gives you controllers and services for anything which has to do with users: password reset, activation link, enabling/disabling, soft delete. It is highly configurable, for example you can choose to use the email address as username. It even gives you simple raw HTML templates with all necessary forms for editing and listing users. And most importantly, it is easily extensible: you can simply extend their User entity and do your own, and even extend their controllers/services to change any behaviour, or choose different url mappings.

All my friends had to do was to put some new fields in the entity, remake the templates with Bootstrap and in a matter of a few hours they had something it takes me 2 days to do in Spring. And it's like this for anything they have to do: they just use existing code from the community and extend it. They even built their own bundle to manage CRUD operations with simple Bootstrap templates. Would you believe me if I told you they built an application with 120 entities in less than 3 months of 2 people working part time? And I'm pretty sure people working on Ruby on Rails have the same kind of productivity.

I know that this isn't happening in the Spring ecosystem because of the many different ways there are to do things: many different templating engines, many different options for persistence, and so on. But wouldn't it be interesting if Spring Boot implemented a standardized way of writing reusable plugins? Just like other Spring-based frameworks like Grails already do. Maybe it needs to be slightly opinionated on how to do it, but isn't that the exact reason why Spring Boot is here?

Tim Cooke wrote:

Martin Bechtle wrote:Is it possible to keep the XML outside the war/jar package? In that case it would really make sense.

You can do that yes, but I'd not be entirely comfortable with that. Spring xml configs are heavy on implementation detail quoting class names with full package prefixes which aren't super friendly to application support and configuration maintenance people. Plenty to get wrong, and get wrong big.

In our application we use Spring xml configuration for everything but our MCV controller classes for which we use annotations. We also use Spring Profiles to selectively enable and disable certain bean wiring configurations in our xml. For example:

<beans profile="oracleDao"> <bean id="dbDao" class="com.timdrivendevelopment.dao.OracleDao" /> </beans> <beans profile="mySqlDao"> <bean id="dbDao" class="com.timdrivendevelopment.dao.MySqlDao" /> </beans>
Now the configuration switch item is outside of the Spring xml file.

Right! Profiles! I still prefer JavaConfig but at least now xml config is starting to make sense to me. Thank you for your time Tim and Salvin

Tim Cooke wrote:

Martin Bechtle wrote:Am I missing something that you find really useful with XML config?

Let's say my application supports MySQL and Oracle databases. I have written DAO's for both and I'm using Spring to inject the Oracle DAO into some other service class.

Let's say my customer now decides that they've had it with paying Oracle oodles of cash in licencing and they want to switch to MySQL. No problem, I can reconfigure my application without having to produce and version a new build. Just a Spring xml config change and a server reboot. Job done.

That's one example, of course there are others.

Right, but wouldn't you overwrite the XML file once you deploy a new version? I think this kind of configuration goes against best Continous Integration practices. Is it possible to keep the XML outside the war/jar package? In that case it would really make sense.
If I had to do an app supporting both Oracle and MySql without an ORM, I'd prefer to have JavaConfig read a configuration file somewhere, like ~/.myAppSettings/config.properties, and wire up all dependencies consequently.

And wouldn't you like to have a single Java file with a @Configuration class creating all your beans? You still get all the points you mentioned, plus:

errors at compile time

easy debugging

ide autocomplete

even a complete newbie to Spring can understand java code, without knowing how xml config works

The first time I saw JavaConfig in Spring a few years ago I though to myself: man this seems so easy!