{"id":977,"date":"2012-04-21T16:54:45","date_gmt":"2012-04-21T14:54:45","guid":{"rendered":"http:\/\/doanduyhai.wordpress.com\/?p=977"},"modified":"2012-04-21T16:54:45","modified_gmt":"2012-04-21T14:54:45","slug":"magics-is-evil","status":"publish","type":"post","link":"https:\/\/www.doanduyhai.com\/blog\/?p=977","title":{"rendered":"Magics is evil !"},"content":{"rendered":"<p>For once, this article will not show you any line of code or any demo application.<\/p>\n<p>Today we discuss about architecture and the recent trend in the Java (and more specifically Spring) world for abstraction and over simplification.<\/p>\n<p><!--more--><\/p>\n<h1>I Magic is everywhere<\/h1>\n<ul>\n<li>Have you ever used the <em>@Transactional<\/em> and <em>@PersistenceUnit\/@PersistenceContext<\/em> annotations in your applications ? Do you really know what happen under the hood (apart from what is said in the official documentation) ? Did you know that when used together with an <em>@Transactional<\/em> annotation, the <em>@PersistenceContext<\/em> will get an instance of EntityManager from a thead local ? If you answer no to one of these questions, you are relying on magics without knowing how it works (check my previous article about <a href=\"http:\/\/doanduyhai.wordpress.com\/2011\/11\/21\/spring-persistencecontext-explained\/\" title=\"Spring @PersistenceContext\/@PersistenceUnit\u00a0explained\" target=\"_blank\">@PersistenceContext\/@PersistenceUnit<\/a> for in depth details)<\/li>\n<p>&nbsp;<\/p>\n<li>Do you know which beans are created and configured under the hood of the <strong>&lt;mvc&gt; namespace<\/strong> ? A guy already asked a question on a Stackoverflow <a href=\"http:\/\/stackoverflow.com\/questions\/3693397\/howto-get-rid-of-mvcannotation-driven\" title=\"How to get rid of mvc annotation driven tag\" target=\"_blank\">thread<\/a> about this. As many folks he uses the <strong>&lt;mvc&gt; namespace<\/strong> without really knowing what is done under the hood and one day he&#8217;s stuck when he tries to get rid of it.<\/li>\n<p>&nbsp;<\/p>\n<li>What do you think about Spring <em>@Controller<\/em> and <em>@RequestMapping<\/em> annotations ? Cool stuff right ? But when you face a big project with many controller classes developed by different people and embedded in different jars (an extreme case I confess), how can you have a good overall view of all URL paths ? A guy faced this issue and asked the question again on Stackoverflow <a href=\"http:\/\/stackoverflow.com\/questions\/4829774\/documenting-spring-requestmapping-annotations-into-one-location-automatically\" title=\"How to put @RequestMapping annotations in one location\" target=\"_blank\">here<\/a>.<\/li>\n<p>&nbsp;<\/p>\n<li>Do you know how flexible parameters for <em>@RequestMapping<\/em> methods are achieved in <strong>Spring MVC 3.1<\/strong> ? Do you know that you cannot have a <strong>Model<\/strong> map as parameter for an <em>@ExceptionHandler<\/em> method  although the <a href=\"http:\/\/static.springsource.org\/spring\/docs\/current\/spring-framework-reference\/html\/mvc.html#mvc-exceptionhandlers\" title=\"@Exceptionhandlers\" target=\"_blank\">official documentation<\/a> let you think so ?<\/li>\n<p>&nbsp;<\/p>\n<li>Do you know how to inject a custom filter or to plugin a custom behavior in the Spring Security filter chain with the <strong>Spring Security namespace<\/strong> ? Are you able to configure the whole filter chain by pure XML configuration ? (some help to do this <a href=\"http:\/\/doanduyhai.wordpress.com\/2012\/01\/22\/spring-security-part-i-configuration-and-security-chain\/\" title=\"Spring Security part I : Configuration &amp; Security\u00a0Chain\" target=\"_blank\">here<\/a>) <\/li>\n<p>&nbsp;<\/p>\n<li>One day a guy in my office came and asked for some help to set up a multi-channel JMS queue. I advise hime to emulate virtual queues using JMS selector but he was totally stuck because he used to work with the <strong>Spring Integration namespace<\/strong> and did now know how to fine tune a JMS message listener to use selector.<\/li>\n<\/ul>\n<p> For each of the above situation, we&#8217;re are dealing with magics. What is cool with magics is that it makes your life simpler and easier. Magics helps you to bootstrap a project very quickly, to focus on the functional design instead of wasting your time in technical configuration. Magics is just an additional layer of abstraction added on top of technical framework to help people &#8220;<strong>deliver value<\/strong>&#8220;. It&#8217;s perfectly inline with the &#8220;<strong>agility<\/strong>&#8221; trend.<\/p>\n<p> In most cases (<strong>80%<\/strong>) all these statements are true. But if you dare to stray from the main path of <strong>80% use cases<\/strong>, you are a dead man unless you accept to dig in source code and spend hours (if not days) to understand the underlying logic.<\/p>\n<p>&nbsp;<\/p>\n<h1>II Understanding the magics<\/h1>\n<p> The idea of my talk is not to bash magics (also called <em>convention over configuration<\/em>) but to remind you that the key rule in this world (and mostly in the IT world) is: <strong>you must understand what you are doing<\/strong>. Too much abstraction can be dangerous. Reading an online tutorial to implement a solution is far from enough, you must also understand the underlying technology.<\/p>\n<ul>\n<li>Using <strong>ElasticSearch<\/strong> is great, understanding (not necessarily in details) how <strong>Lucene<\/strong> works is better<\/li>\n<li>Mastering SQL queries is good for your CV. Understanding how execution plans are built, how indexed are created and used will leverage you skills<\/li>\n<li>Knowing <strong>Hibernate<\/strong> is good, understanding how SQL works behind the scene is best<\/li>\n<li>etc&#8230;<\/li>\n<\/ul>\n<p> At Devoxx France, Neel Ford gaves a talk on <a href=\"http:\/\/nealford.com\/downloads\/conferences\/Abstraction_Distractions%28Neal_Ford%29.pdf\" title=\"Abstraction Distraction\" target=\"_blank\">Abstraction Distraction<\/a> where he emphasized that we must be aware of too much abstraction and do not let it distract us from the real thing, the real technology behing the scene.<\/p>\n<p>&nbsp;<\/p>\n<h1>III XML is not bad!<\/h1>\n<p> XML was very trendy during the last decade. At that time, during a job interview, if you did not know what is SAX\/DOM, XSLT, XPath and all of the kind you got no chance being hired.<\/p>\n<p> Nowadays the hype has changed, XML &amp; XML-based Web Services is being criticized, sometime for good reasons, for its verbosity, difficulty to setup, heavy weight etc. The new star for cross-application exchanges is the JSON format along side with RESTfull architecture.<\/p>\n<p> In frameworks, the trend started with <strong>dedicated namespaces<\/strong> (<strong>Spring Security<\/strong>, <strong>Spring MVC<\/strong>) to alleviate the burden of configuration. Then they switch to <strong>Java annotations<\/strong> (<strong>Hibernate<\/strong> with Entity annotations, <strong>Spring<\/strong> &amp; <strong>CDI<\/strong> with <em>@Autowired<\/em> &amp; <em>@Inject<\/em>) and finally the idea for the next few years is <strong>full java configuration<\/strong>.<\/p>\n<p> Do you remember how XML was sold to developers in the past ? They said that we must separate configuration (XML) from code (java). It helps the devops because they can fine tune the application with XML without having to rebuild the code.<\/p>\n<p> Now with the full java config hype, we&#8217;re doing exactly the contrary, putting all configuration in the code !<\/p>\n<p> One big advantage of XML is its centralization benefit. No matter in which package you put your code, no matter from which jar the classes come, all the instanciation and wiring are done in one big or some split XML files.<strong> With XML config you have a global overview of what is going on in your application, of what being injected into which bean and so on<\/strong>.<\/p>\n<p>&nbsp;<\/p>\n<h1>IV The future<\/h1>\n<p> It&#8217;s quite soon to predict what&#8217;s gonna happen in the next few years. The over-convention and over-abstraction trend is just starting. What I can say for sure is that step back from the hype and have good understanding of what&#8217;s lying behing the scene. Always <strong>stand out from the crowd<\/strong> and <strong>beware of the hype<\/strong> !<\/p>\n","protected":false},"excerpt":{"rendered":"<p>For once, this article will not show you any line of code or any demo application. Today we discuss about architecture and the recent trend in the Java (and more specifically Spring) world for abstraction and over simplification.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,6],"tags":[],"_links":{"self":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/977"}],"collection":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=977"}],"version-history":[{"count":0,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/977\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}