Albert Lea Data Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

====== General Concepts ======
===== Application Footprint =====
^Observation                    ^Jarvis      ^       ^Bluejay     ^     ^
|Number of source files         |Java:       |    123|PHP:        |   18|
|                               |JSP:        |    118|Python:     |    1|
|                               |XML:        |    134|Config:     |    3|
|                               |ECMAscript: |     27|ECMAscript: |    2|
|Number of classes              |            |    120|            |    4|
|Dependency libs                |            |     29|            |    2|
|Dependency classes             |            |  2400+|            |    4|
|Total codebase size            |            | 16984k|            | 166k|

===== Code vs. Config =====
Moving application development from highly-structured programming languages into configuration solutions has many significant drawbacks for the programming process:
  * Compile time errors are moved to runtime errors (this is the cause of many other problems)
  * Type-safety is thrown out the window
  * Refactoring is significantly more complex AND tedious
  * Modern IDEs are very adept at editing code, but such tools are usually not available for editing configuration files
  * Understanding config files requires learning a one-off DSL (Domain-Specific Language) - a waste of time
  * Understanding config files requires following a tedious 'trail of breadcrumbs' of string identifiers
  * Config files are parse-fragile - typos are easy to make, but hard to find (a bad combination)
  * Config files are often not particularly legible or concise
  * When working with revision control, monolithic config files that refer to multiple features will often be a source of contention between programmers working on different tasks

====== Java ======
  * Java is resource-intensive
  * Java is SLOW
  * Java is overkill for light-weight utility programming
  * The J2EE ecosystem is polluted with overly-complicated techniques and dependencies

====== Spring ======
An interesting read:  http://www.samatkinson.com/why-i-hate-spring
===== Spring is HUGE =====
  * The unzipped distribution is over 150 Meg.
  * **Note:** Spring has a FRAMEWORK (Spring Boot) to assist in using Spring as a framework ...
  * Spring is not a single framework. Rather, it's more of a collection of independent tools, with its Dependency Injection framework as the core item, Spring MVC as its web framework, and many other tools besides.
  * Spring is very fond of describing itself as lightweight. However, not many (sane) programmers would characterize a tool having more than 2400 classes, 82 dependencies on external jars, and a distribution size of 150 Meg as "lightweight". This stretches the usual meaning of the term beyond its comfortable limits. 
==== Consequences of Spring's HUGE Size ====
  * Spring is complex
  * Spring has no clear focus - its "everything and the kitchen sink"
  * Spring's javadoc has over 2400 classes
  * "Dependency Hell" - Spring's lib directory contains 49 other tools, totaling 82 jars
  * It takes significant time to learn about all of Spring's parts
  * Joshua Bloch's dictum of "when in doubt, leave it out" has NOT been applied with Spring at all
===== Spring requires ALOT of XML =====
  * XML complicates the programming process (see general concepts)
  * Spring confuses coding with configuration
  * "XML Abuse" - XML was intended as a tool for transfering data between systems, but Spring uses XML in a way that wasn't intended by its creators
===== Spring has "odd" Problems =====
  * Spring IoC makes "Dependency Injection" an unavoidable complication
  * Spring AOP and AspectJ have a lot of overlap between them
  * Aspect-oriented Programming in general introduces various kinds of complexity issues (more trouble than its worth, Event-Driven models are superior)
  * Spring Security is remarkably similar to existing Servlet API security (redundant)

====== Hibernate ======
  * https://empire-db.apache.org/empiredb/hibernate.htm
===== Hibernate is Java-Only =====
  * Prevents diverse programming technologies
===== ORM is Problematic =====
  * ORM in general is meant to deal with full entities separately, instead of leveraging true relational power
  * Using an ORM tends to "pollute" data model's relational integrity by encouraging entity conveniences
  * There's more than just one "layer" of abstraction engaged in Hibernate's ORM facade - what SQL Hibernate actually ends up executing is not at all transparent or accessible for modification
===== Hibernate Complicates Applications =====
  * Hibernate imposes an ORM facade instead of modeling how an RDBMS actually works
  * Hibernate tries to bridge the ORM gap with internal features, but in order to utilize these features properly many complex decisions must be made (XML or annotations, HQL or criteria API, lazy or eager fetching, and more)
  * HQL and criteria API in particular abstract direct SQL support away
  * HQL breaks down with conditional/dynamic constraints and joins
  * Hibernate generates code, which confounds retaining customizations to such code
  * Criteria API is very limited, and result beans are complex and error-prone
  * Generated code proliferates both existence and use of unnecessary get'ers and set'ers
  * "XML Hell" - XML mapping is tedious and complicated
  * "Annotation Hell" - Annotations shouldn't be used in application logic, but Hibernate forces it when not using XML
  * Everything Hibernate provides can be done much leaner and with less complexity using true interfaces and classes
===== Hibernate is Slow =====
  * Hibernate tends to map its ORM constructs to either many singular round-trip queries or full-table-join results
  * Hibernate precludes using non-entity views created by precise joins and constraints
  * Hibernate causes significant short-lived object creation

====== Misc ======
===== Jarvis =====
==== Tomcat vs. JBoss ====
  * JBoss is RedHat-native
  * JBoss has a better design and track-record
==== Recent Changes ====
  * RBAC is still changing
===== Spring =====
  * Here's a comparison of the typical meaning given to the word 'configuration', versus the meaning implied by Spring documentation:
	Item                       Normal Config        Spring "Config"
	Number of files            1                    N
	Total number of lines      small                large
	When settings made         deploy time          development time
	File format                simple text          highly structured XML
	Items interdependent       usually not          common
	Small tweaks to behavior   yes                  no
	Specify class names        rare                 common
	Specify method names       almost never         common
Albert Lea Data Wiki

User Tools

Site Tools

Page Tools
