The best articles and links to interesting posts for technical team leaders building sophisticated websites, applications and mobile apps.
Think about: software architecture, hardware architecture, design, programming, frameworks, scalability, performance, quality assurance, security, resolving issues, fixing bugs and Android.
One of many architecture and design diagrams for an application built on Struts2, Spring, Hibernate and ExtJS. Could be a good starting/reference point.
SpringSource announced a maintenance policy for SpringSource Enterprise. Definitely check Rod Johnson's clarification comment in this thread on The ServerSide. Important to verify when you're using Spring in your company.
Don't use iBATIS when you are in full control of both the application (with its domain model) and the data model.
Don't use iBATIS when the database is non-relational
Use Hibernate to leverage end-to-end OR mapping
A potential reason to use it could be that it is more easy to use for object-oriented programmers who are less familiar with SQL
Use JPA when you need a standards-based persistence solution
My own recommendations:
With Hibernate it might be harder to tune the queries because they are generated by Hibernate. You can't really "just handover" the queries to the DBA. The DBA will have to monitor the database for bad queries.
Hibernate gets quite complex when you have to map more complex associations (like a unidirectional many-to-many association with custom columns added to the link-table). I've never used iBatis so can't tell how hard it is for that framework.
When trying to only use JPA defined elements, you'll find that JPA's possibilities are quite limited (e.g. caching is not well defined in JPA), and that you quickly will start to use (ORM-tool) implementation specific features. A good way to implement this, is to specify the full package path when using implementation specific annotations. That way you can see where you deviate from the JPA standard.
Interesting technical development: IE8 and Google Chrome are putting tabs in new processes instead of threads. The main reason for creating threads used to be that it takes a relative long time to create a new process and inter-process communication is slow. But, these days the processor speeds are so fast (following Moore's Law etc), creating processes is a piece of cake/can be done really fast.
A list of the 10 worst scalability practices/anti-patterns for large distributed systems. The areas covered are: the golden hammer: use of only 1 technology, resource abuse, big ball of mud: bad versioning/deployment management, everything or something: packaging of the application, forgetting to check the time (did you know that only just recently, since JDK 1.5, you can set timeout on reads on HTTPURLConnection? And that DNS lookups in Java are cached for the lifetime of the JVM unless configured differently?), the hero pattern: one operational "do it all", not automating deployment, build etc, and finally: monitoring of the system.
I'm a professional software designer/architect/developer/software engineer with over 25 years of experience. For many years I've been a Technical Team Lead for complex software engineering projects. My main area of focus is Java/Kotlin microservice architectures and related challenges (design, scalability, performance etcetera). Currently Kotlin has got a lot of my attention. I will be posting lessons learned, and lessons that I'll be learning during the coming years :-)