When it comes to conventions regarding how to structure your packages in Java (or any other language in fact) there is a wide variety of opinion. Making the right decision can promote productivity, understandability, quality, flexibility and the construction of reusable frameworks. I've seen some people promote 'package by feature' over 'package by layer' but I've used quite a few approaches and found 'package by layer' much better than 'package by feature' but further from that I have found that a hybrid: 'package by layer then feature' strategy works extremely well in practice and here's why I think that's so. Package by layer then feature The 'package by feature' people tend to want to put all user interface, model classes, persistence classes (eg., DAO - if you're into self torture ;]) for a particular feature into the same package and according to many examples, the same directory. i.e. they don't us...
Oh, the humanity! If we were not in the software engineering game but, rather, in the civil engineering game then the equivalent of this article would be called 'Classic Civil Engineering Mistakes' and contain graphic videos of buildings and bridges collapsing and thousands of people running for their lives. It's hard to get emotional about something you can't see Unfortunately software is a rather intangible asset that doesn't lend itself to dramatic and emotional visualizations. When it comes down to it the life work of a software engineer, when reduced to it's lowest conceptual level, is the specific arrangement of sequences of 1's and 0's on one or more hard disks (or some form of solid state storage) residing on a server or desktop computer. How those 1's and 0's get there and 'which' sequences work and which don't is not really a black art but it definitely requires some intelligence but surprisingly a lot more common sens...
Our web hosting application platform Pagebloom has been running on MySQL 5.7 for some time now and it runs brilliantly - it's exceptionally responsive and provides great user experience. The performance of the underlying MySQL 7 has been great except... Clustered indexing: The double edged sword Part of MySQL's great read performance is due to an "under the hood" design feature that most software developers who use it are blissfully unaware of. In the automobile world it would be the equivalent of fuel injection or a turbo/super charger or in German - a Kompresser! These are features that can be added to the design of an engine to provide a significant boost in performance. For MySQL this feature is what is known as a "Clustered Index". The main concept of a clustered index is that the core data of each record is actually stored within the primary key index. Yes, you heard correctly - actual record data is embedded into the B-tree frames that make up the ind...
Comments
Post a Comment
Please add your comment: