The Holy Java

Building the right thing, building it right, fast

Posts Tagged ‘productivity’

Tools for Editor – Browser Integration for Interactive JS/HTML Development

Posted by Jakub Holý on March 25, 2013

Chrome Development Tools and similar ones are great for interactive, exploratory coding of JavaScript, HTML, and CSS – but the changes aren’t persistent and the tools haven’t the power of a programmer’s editor. I’d like to be able to use a powerful editor yet be able to see changes to JS/HTML/CSS without having to save-[compile]-reload and I want to be able to execute pieces of JS in the context of the browser. Fortunately, there are ways to get at least some of this and it is getting continually better. Let’s see what tools we have now.

These tools usually use either remoting capabilities of the browser or a long-polling connection to the web site, sending and executing JavaScript.

Read the rest of this entry »

Posted in Tools | Tagged: , , , | 3 Comments »

Most interesting links of October ’12

Posted by Jakub Holý on October 31, 2012

Recommended Readings

  • David Veksler: Some lesser-known truths about programming – things newcomers into the field of IT don’t know and don’t expect, true and an interesting read. Not backed by good data but anyway. F.ex.: “[..] a programmer spends about 10-20% of his time writing code [..] much of the other 90% thinking, researching, and experimenting”. “A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average [..]” “Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor.” “Continuous change leads to software rot, which erodes the conceptual integrity of the original design.” “A 2004 study found that most software projects (51%) will fail in a critical aspect, and 15% will fail totally.”
  • Brett L. Schuchert: Modern Mocking Tools and Black Magic – An example of power corrupting – interesting for two reasons: a good analysis of a poorly written piece of code and discussion of the code injection black magic (JMockIt) vs. actually breaking dependencies to enable tests.  The author presents a typical example of low-quality method (mixing multiple concerns, mixing different levels of abstractions, untestable due to a hardcoded use of an external call) and discusses ways to improve it and to make it testable. Recommended to read.
  • It’s Not About the Unit Tests – Learning from iOS Developers: iOS developers don’t do much testing yet they manage to produce high quality. How is that possible? The key isn’t testing itself, but caring for the code. (Of course, iOS is little special: small apps, no legacy, a powerful platform that does lot for the apps, very visual apps.) “It’s not about the practices. It’s about the spirit and intent behind them, and how they are applied.” (M. Fowler had a similar observation about a team that used mock-based testing exclusively and thus lacked integration tests yet all worked. [I've lost the link to the post and would be grateful for it])
  • Java Code Quality Tools – Overview – brief descriptions of 44 quality-related tools including some interesting tools and Eclipse plugins I didn’t know or knew but forgot. F.ex. analysis of dependencies with JBoss Tattletale or JarAnalyzer, Clirr to check libraries for source and binary backwards compatibility, JDiff generates JavaDoc-based report of removed/added/changed in an API. Spoon – read and check or transform Java code. Java PathFinder (NASA) – special JVM capable of checking all execution path to discover concurrency defects etc.

Tools

  • DirB, Directory Bookmarks for Bash (home) – moving efficiently among favourite directories (s <name> to create a bookmark for pwd, g <bookmark | relative/abs dir path> to enter a dir (=> works both for bookmarks and as a replacement for cd); also support for relative path bookmarks & more; sl lists bookmakrs in the last used order) (You might also want to check out Autojump, described in Dec 11; bashmarks is another similar project. Another similar project is rupa’s z and j2 and the fish clone z-fish)

Clojure Corner

  •  Jon Pither: Clojure at a Bank – Moving from Java -  the justification (productivity, dynamism, FP a better match for the domain) and process behind moving from Java to Clojure with a monolithic 1M LOC Spring/Hibernate app. (Random quotes: “I had used some dynamical languages before and it was quite obvious that we were essentially forcing lots of schema and type definition on to a problem domain that just didn’t want or need it.” “[..] it [dependency injection] just looks redundant in retrospect now that I’m working 95% with FP code.”) There is also a EuroClojure talk about their experiences one year later (35 min).
  • Prismatic’s “Graph” at Strange Loop – an interesting desing problem, its solution, and a resulting OSS library. The problem: How to break a large function into independently usable small ones that might depend on each other without ever needing to recompute a value once the function producing is called. The solution: Graph – “Graph is a simpledeclarative abstraction to express compositional structure.” (Enabling explicit declaration of data dependencies and pluging in different implementations.)
  • The Oblong: Blog about 2/3 D game programming in Clojure, starting from scratch (w/o an engine); interesting experiences
  • Ironclad: Steam Legions – Clojure game development battle report (the game on Github)
  • Building the Wishlisted.org webapp in Clojure – experiences from learning Clojure for real by building a webapp in Noir
  • Clojure vs. Scala smackdown (“Just kidding with the title of this post :-)”) – a short post with interesting discussion. Dmitri Sotnikov’s opinion resonates with me: “I found that for me Clojure wins on simplicity and consistency. While it looks more alien initially, once you learn the basics, you just reuse the same patterns everywhere.” Some more comments: “One major concern was maintainability, since it’s fairly easy to write very dense code. This turned out to not be a problem in practice. Because Clojure code is written as a tree, refactoring it is very easy.” REPL seems to be a big win (applies to Scala too). Scala’s type system might get tedious and learning its quirks takes time but there is lot of potential and both have they strong sides.
  • Code Fatigue – discussion of the advantages of learning, using, and combining the (many) standard Clojure functions instead of a “basic solution” using recursion etc. The argument is in favor of higher-level code with less complexity in the form of branching, recursion, nested expressions etc. and thus less mental fatigue.

Favorite Quotes

A classic test only cares about the final state – not how that state was derived. Mockist tests are thus more coupled to the implementation [emphasis mine] of a method. Changing the nature of calls to collaborators usually cause a mockist test to break.

- Martin Fowler in his classical Mocks Aren’t Stubs

I’m afraid of code. When I see a big pile of code, I get scared ;-). Some classes and method make me cry. I had troubles explaining why I prefer short pieces of code keeping the same level of abstraction, cohesive and loosely coupled. The following quote captures the essence – improved communication.

One way to improve communication is to reduce the need for it and the same can be said for code. [...] Since we tend to read code more than write it, anything we can do to reduce the need to read code is time well invested in the life of a project.

- Brett L. Schuchert in Modern Mocking Tools and Black Magic – An example of power corrupting justifying extraction of code into another class or method

Posted in General, Languages, Testing, Tools, Top links of month | Tagged: , , , , , , | Comments Off

Only a Masochist Would Write Unit Tests in Java. Be Smarter, Use Groovy (or Scala…).

Posted by Jakub Holý on October 18, 2011

If this post irritates you, here's st. positive to concentrate on

I like writing unit tests but Java doesn’t make it particularly easy. Especially if you need to create objects and object trees, transform objects for checking them etc. I miss a lot a conscise, powerful syntax, literals for regular expressions and collections, conscise, clojure-based methods for filtering and transforming collections, asserts providing more visibility into why they failed. But hey, who said I have to write tests in the same language as the production code?! I can use Groovy – with its syntax being ~ 100% Java + like thousand % more, optional usage of static/dynamic typing, closures, hundreds of utility methods added to the standard JDK classes and so on. Groovy support for example in IntelliJ IDEA (autocompletion, refactoring …) is very good so by using it you loose nothing and gain incredibly much. So I’ve decided that from now on I’ll only use Groovy for unit tests. And so far my experience with it was overwhelmingly positive (though few things are little more complicated by the positives more than compensate for them). Read on to find out why you should try it too.

(The arguments here focus on Groovy but I guess similar things could be said about JRuby, Scala etc. – with the exception of Java code compatibility, which you only get in Groovy.)

Few examples

Some of the example below use some Groovy magic but don’t be scared. You can write Groovy just as if it was Java and only learn and introduce its magic step by step as you need it.

Bean construction:

def testBean = new Customer(fname: "Bob", sname: "Newt", age: 42)
// Java: c = new Customer(); c.setFname("Bob"); c.setSname("Newt"); c.setAge(42);

(Of course this starts to pay of if either you don’t want to create a constructor or if there are “many” properties and you need to set different subsets of them (constructor with 4+ arguments is hard to read).)

Reading a file:

assert test.method() == new File("expected.txt").getText()
// Java: buffered reader line by line ...; Note: == actually uses equals()

Checking the content of a collection/map:

assert customerFinder.findAll().collect {it.sname}.sort() == ["Lizard","Newt"]
// Java: too long to show here (extract only surnames, sort them, compare ...)
assert getCapitalsMap() == ["UK" : "London", "CR" : "Prague"]

Regular expressions:

assert ("dog1-and-dog2" =~ /dog\d/).getAt([0,1]) == ["dog1", "dog2"]
  • Or more fail-safe regexp:
    assert ("dog1-and-dog2" =~ /dog\d/).iterator().toSet() == ["dog1", "dog2"].toSet()
    
  • With a match group:
    assert ("dog11-and-dog22" =~ /dog(\d+)/).iterator().collect({it[1]}).toSet() == ["11", "22"].toSet()
    

Read the rest of this entry »

Posted in Languages, Testing | Tagged: , , , , | 11 Comments »

Note to Self: Running GroovyConsole with a Maven Project’s Classpath

Posted by Jakub Holý on October 2, 2011

It’s pretty useful to have the ability to eperiment interactively with some API using the (desktop) Groovy Console. If the API is in a Maven project, just add dependency on Groovy to your pom.xml:

<dependency>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy-all</artifactId>
    <version>1.8.2</version>
</dependency>

And execute the console from the project’s folder using the exec plugin:

mvn exec:java -Dexec.mainClass="groovy.ui.Console"

Enjoy.

Posted in Tools | Tagged: , , | Comments Off

Inspect Your Webapp in a Live Environment Interactively with GroovyConsole

Posted by Jakub Holý on September 27, 2011

Have you ever needed to check the state of your webapp’s objects/Session/.. to find out why the hell something doesn’t work or have you had to learn a weird 3rd party API that is only available on the server? Then you were doomed … until the publication of GroovyConsole. JeeUtils GroovyConsole provides a JSP page that let you execute any Groovy/Java code on the server side, with access to server-side objects like request/session etc.

Here is a screenshot of my recent troubleshooting session, where I needed to check the state of a session-scoped JSF Managed Bean:

Read the rest of this entry »

Posted in j2ee, Languages, Tools | Tagged: , , , , | Comments Off