Most interesting links of October
Recommended Readings
- Steve Yegge's Execution in the Kingdom of Nouns - I guess you've already read this one but if not - it is a well-written and amusing post about why not having functions as first class citizens in Java causes developers to suffer. Highly recommended.
- Reply to Comparing Java Web Frameworks - a very nice and objective response to a recent blog summarizing a JavaOne presentation about the "top 4" web frameworks. The author argues that based on number of resources such as job trends, StackOverflow questions etc. (however data from each of them on its own is biased in a way) JSF is a very popular framework - and rightly so for even though JSF 1 sucked, JSF 2 is really good (and still improving). Interesting links too (such as What's new in JSF 2.2?). Corresponds to my belief that GWT and JSF are some of the best frameworks available.
- Using @Nullable - use javax.annotation.Nullable with Guava's checkNotNull to fail fast when an unexpected null appeares in method arguments
- JavaOne 2011: Migrating Spring Applications to Java EE 6 (slides) - nice (and visually attractive) comparison of JavaEE and Spring and proposal of a migration path. It's fun and worthy to see.
- xUnitPatterns - one of the elementary sources that anybody interested in testing should read through. Not only it explains all the basic concepts (mocks, stubs, fakes,...) but also many pitfalls to avoid (various test smells such as fragile tests due to Data Sensitivity, Behavior Sensitivity, Overspecified Software [due to mocks] etc.), various strategies (such as for fixture setup), and general testing principles. The materials on the site were turned into the book xUnit Test Patterns: Refactoring Test Code (2007), which is more up-to-date and thus a better source.
- Eclipse tip: Automatically insert at correct position: Semicolon, Braces - in "while(|)" type "true {" to get "while(true) {|" i.e. the '{' is moved to the end where it belongs, the same works for ';'
- Google Test Analytics - Now in Open Source - introduces Google's Attributes-Components-Capabilities (ACC) application intended to replace laborous and write&forget test plans with something much more usable and quicker to set up, it's both a methodology for determining what needs to be tested and a tool for doing so and tracking the progress and high-risk areas (based not just on estimates but also actual data such as test coverage and bug count). The article is a good and brief introduction, you may also want to check a live hosted version and a little more detailed explanation on the project's wiki.
- JSF and Facelets: build-time vs. render-time (component) tags (2007) - avoid mixing them incorrectly
- StackOverflow: What are the main disadvantages of Java Server Faces 2.0? Answer: The negative image of JSF comes from 1.x, JSF 2 is very good (and 2.2 is expected to be just perfect :-)). Nice summary and JSF history review.
- Ola Bini: JavaScript in the small - best practices for projects using partly JavaScript - the module pattern (code in the body of an immediately executed function not to polute the global var namespace), handling module dependencies with st. like RequireJS, keeping JS out of HTML, functions generating functions for more readable code, use of many anonymous functions e.g. as a kind of named parameters, testing, open questions.
Talks
- Kent Beck's JavaZone talk Software G Forces: The Effects of Acceleration is absolutely worth the 1h time. Kent describes how the development process, practices and partly the whole organization have to change as you go from annual to monthly to weekly, daily, hourly deployments. What is a best practice for one of these speeds becomes an impediment for another one - so know where you are. You can get an older version of the slides and there is also a detailed summary of the talk from another event.
- Rich Hickey: Simple Made Easy - Rich, the author of Clojure, argues very well that we should primarily care for our tools, constructs and artifacts to be "simple", i.e. with minimal complexity, rather than "easy" i.e. not far from our current understanding and skill set. Simple means minimal interleaving - one concept, one task, one role, minimal mixing of who, what, how, when, where, why. While easy tools may make us start faster, only simplicity will make it possible to keep going fast because (growing) comlexity is the main cause of slowness. And simplicity is a choice - we can create the same programs we do today with the tools of complexity with drastically simpler tools. Rich of course explains what, according to him, are complex tools and their simple(r) alternatives - see below. The start of the 1h talk is little slow but it is worth the time. I agree with him that we should much more thing about the simplicity/complexity of the things we use and create rather than easiness (think ORM). Read also Uncle Bob's affirmative reaction ("All too often we do what’s easy, at the expense of what’s simple. And so we make a mess. [...] doing what is simple as opposed to what is easy is one of the defining characteristics of a software craftsman.").
Random Notes from Rich's Simple Made Easy Talk:
There are also better notes by Alex Baranosky and you may want to check a follow-up discussion with some Rich's answers.The complex vs. simple toolkit (around 0:31):
COMPLEXITY SIMPLICITY State, objects Values Methods Functions, namespaces vars Managed refs Inheritance, switch, matching Polymorphism a la carte Syntax Data Imperative loops, fold Set functions Actors Queues ORM Declarative data manipulation Conditionals Rules Inconsistency Consistency
What each of the complexity constructs mixes (complects) together
CONSTRUCT COMPLECTS (MIXES) State, objects - everything that touches it (for state complects time and value) Methods - function and state, namespaces (2 classes, same m. name) Syntax - Meaning, order Inheritance - Types (ancestors, child) Switch/matching - Multiple who/what pairs (1.decide who, 2.do what ?) var(iable)s - Value, time Imperative loops, fold - what/how (fold - order) Actors - what/who ORM - OMG :-) Conditionals - Why, rest of program (rules what program does are intertw. with the structure and order of the program, distributed all over it)
HE SIMPLICITY TOOLKIT (around 0:44) CONSTRUCT GET IT IVA... Values - Final, persistent collections Functions - a.k.a. stateless methods Namespaces - Language support Data - Maps, arrays, sets, XML, JSON etc. Polymorphism a la carte - Protocols, Haskell type classes Managed refs - Clojure/Haskell refs (compose time and value , not mix) Set functions - Libraries Queues - Libraries Declarative data manipulation - SQL/LINQ/Datalog Rules - Libraries, Prolog Consistency - Transactions, values
True abstraction isn't hiding complexity but drawing things away - along one of the dimensions of who, what, when, where, why [policy&rules of the app.], how. Abstraction => there are things I don't need - and don't want - to know. Why - do explore rules and declarative logic systems. When, where - when obj. A communicates with obj. B. => put a queue in between them so that A doesn't need to know where B is; you should use Qs extensively.
Links to Keep
- Incredibly Useful CSS Snippets - "a list of CSS snippets that will help you minimize headaches, frustration and save your time while writing css" - few float resets, targetting specific browsers & browser hacks, cross-rowser transparency/min height/drop shadow, Google Font API, link styled by file type,
- Hyperic SIGAR API - open-source library that unifies collection of system-related metrics such as memory, CPU load, processes, file system metrics across most common operating systems
- rrd4j - Java clone of the famous RRDTool, which stores, aggregates and plots time-series data (RRD = round-robin database, i.e. keeps only a given number of samples and thus has a fixed size)
- JRDS "is performance collector, much like cacti or munins", uses rrd4j. The documentation could be better and it seems to be just a one man project but it might be interesting to look at it.
Clojure Corner
- Alex Miller: Real world Clojure - a summary of experiences with using Clojure in enterprise data integration and analytics products at Revelytix, since early 2011 with a team of 5-10 devs. Some observations: Clojure code is 1-2 order of magnitude smaller than Java. It might take more time to learn than Java but not much. Clojure tooling is acceptable, Emacs is still the best. Debugging tools are unsurprisingly quite inferior to those for Java. Java profiling tools work but it may be hard to interpret the results. "[..] I’ve come to appreciate the data-centric approach to building software." Performance has been generally good so far.
- Article series Real World Clojure at World Singles - the series focuses on various aspects of using Clojure and how it was used to solve particular problems at a large dating site that starting to migrate to it in 2010. Very interesting. F. ex. XML generation, multi-environment configuration, tooling ("If Eclipse is your drug of choice, CCW [Counter ClockWise] will be a good way to work with Clojure.", "Clojure tooling is still pretty young [..] - but given how much simpler Clojure is than most languages, you may not miss various features as much as you might expect!")
- StackOverflow: Comparing Clojure books - Programming Clojure, Clojure in Action, The Joy of Clojure, Practical Clojure - which one to pick? A pretty good comparison.
- Clojure is a Get Stuff Done Language - experience report - "For all that people think of Clojure as a “hard” “propeller-head” language, it’s actually designed right from the start not for intellectual purity, but developer productivity."