• Home
  • Events
  • About
  • Lean Groovy Full Video and an Interview

    December 23rd, 2010

    This week is a bumper week for me. I’m going away for the holidays and I wanted to clear out all the old blog posts I had in the “pending” state. Then both InfoQ and DZone finally go around to publishing a video and an interview respectively.

    First up is an interview I did with fellow JetBrains Academy Member Radoslaw Holewa. In the interview we talk about open source, Groovy, static code analysis, and of course IntelliJ IDEA. Radoslaw and I will both be heading to the 33rd Degree and GeeCon conferences this Spring, so register now and meet up with us!

    Second is a full 90 minute video of my presenting at 2gx. The topic is “Slimmed Down Software – A Lean, Groovy Approach”, based on a series of articles I wrote this year. It’s not a bad performance… but geez 90 minutes is a long time. It’s like trying to perform a one man show. I made the unfortunate decision to include a poop joke about midway through that I kinda regret. Oh well. I doubt I will ever truly grow out of potty humor.

    Enjoy and see you in 2011!

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    IDEA X for the Grails Developer

    December 23rd, 2010

    The new version of IntelliJ IDEA was released last week. I already blogged what IDEA X means for Groovy developers, and all of those features are obviously available to any Community Edition user (that’s the free one). This post looks at all the new Grails features available in the Ultimate Edition (the one you pay for). These features are a little harder for me to try out personally as my current project is EJB3 and not Grails (someone save me please!). I’ve tried quite a few of them personally, but feedback is always welcome in case I miss or exaggerate something. Without further ado:

    Grails Aware IDE Features

    Better MVC Rename Refactoring – Related artifacts are now renamed together, such as renaming a view when renaming a controller action, or renaming test cases when the main class changes (IDEA-45378).

    Functional-Test Plugin Support – The Functional-Test plugin got some love, and support is the same as normal unit and integration tests (IDEA-51853). Testing is good.

    Filter Support – There is a new action to easily create filters, code completion of actions and controllers works within the filter mapping code, and method like render() and getRequests() resolve from the filter body (IDEA-60331 and IDEA-60167).

    Mapping DSL Support – In domain class mappings you now get code completion that is aware of HibernateMappingBuilder, and the rename refactoring is aware of the mappings (IDEA-49089.

    Constraint DSL Support – Domain object constraints definitions now have code completion on common constraint names, completion on field names, and is correctly updated when using the Rename refacotring (IDEA-49115).

    Service and Bean Inference – The names and types of services and beans can be inferred in controllers and other artifacts (IDEA-49111 and IDEA-45610).

    GSP and View Improvements

    Easy Internationalization – I love this. There’s a new intention in GSP files to move a static string into a message bundle. Alt+Enter does the trick. IDEA-44846 and IDEA-59519

    Groovy Inspection Support – In the past, only some Groovy inspections worked in GSP files. Support for more of the inspections have been added, like “divide by zero”, “double negation”, and “unresolved expression”. It’s not clear if all inspections are supported, but at least more are IDEA-50414

    Better Variable Resolution – References to controllers and controller properties are now resolved within GSP view pages. I assume this means at least control click navigation and code completion. See IDEA-49731 and IDEA-48692. Also, release notes claim “Completion for value of action/controller parameters in built-in methods redirect(), render(), forward(), chain()”.

    g:fieldValue Support – g:fieldValue tags reference a field. Rename, completion, and find usages should all now work within the tag. IDEA-60858

    Debugging in GSP – Release notes claim “Preliminary debugging of GSP pages”. Not 100% sure what this means in practice.

    JavaScript in Tags – Release notes claim “support javascript in tags like “onSuccess”, “onFailure”, etc”. Again, I’m not sure what this means in practice.

    Find Usages

    Domain class fields – Find usages for domain class fields has been improved. The ticket indicates that usages of fields within GORM dynamic queries are now supported (IDEA-58025).

    Variables from tags – Find usage support for variables defined using a g:set tag within a GSP (IDEA-58185).

    Property Usages – i18n message properties are now included in Find Usages, and the corresponding “unused property” inspections should be working (IDEA-52117).

    Even More Code Completion – Besides what’s already been mentioned, we also have…

    Model Aware GSPs – Related to above, views are now aware of which model is returned from the controller, and autocomplete works for them. More info at IDEA-40926

    Variable Aware GSPs – When you define a variable in a GSP then IDEA now autocompletes it and stops pestering you for missing imports IDEA-50257

    Attribute Aware GSPs – Finally, code completion and navigation exists for the standard attributes: “action”, “controller”, “template”, “contextPath”, “plugin”, and well as variables defined in tags like g:each, g:set, etc.

    And more, and more, and more – There’s practically too many to list. Code completion works in type convertors, in named queries, in URL Mappings and their GSP attribute values, in scope objects like servletContext, session, request, params, and flash (they also appear in the debugger as well), in views references from ‘render’ and ‘redirect’ controller calls, and in hasOne mappings which was missed in the last release.

    Grails Framework Support

    Gant Script Support – IDEA is now aware than .groovy files in the scripts directory are Gant scripts. Targets are completed and imports are resolved better (IDEA-49738).

    Grails Target History – Running a Grails target brings up a dialog box. You can now use up and down arrow to scroll through your history (IDEA-46943).

    Ivy Integration – IDEA reads your Ivy cache and automatically loads source and javadoc jars if they’re available (IDEA-53294).

    UI Improvements – The “Browse to http://localhost:8080/xxx” message in the console now lets you click it to open a browser (IDEA-47166), the test console allows keyboard input in case your tests read from standard input (IDEA-57035), the gutter of controller actions show an icon that lets you jump to the corresponding view (IDEA-49320, and the “New” menu now has context sensitive sorting (IDEA-49086). How’s that for productivity boosting?

    I believe that covers it. If you want a free IDEA Ultimate license then there are ways to get them… speaking at your local Java/Groovy Users Group is usually the easiest, and many JUGs have giveaways if you feel lucky. If your group isn’t sponsored by JetBrains then you can always ask: email jugs@jetbrains.com!

    Happy Holidays everyone. I’m hoping Santa brings IDEA 10.1.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Beginner Bash: Must-Know Bash Commands

    December 22nd, 2010

    I switched full time to Ubuntu Linux last year and haven’t looked back. In this year I’ve learned to love the Bash shell (which includes the Terminal in Mac and Cygwin on Windows). At this point, I can finally say I’m faster in Bash then I was in Windows Explorer, Commander, Nautilus, or the Windows command prompt; and I prided myself on being a guy with a lot of .bat files. My goal now is to write some tips I learned in the last year. Before explaining the more advanced stuff I want to introduce some of the most basic basics.

    So here it is: "Stuff I wish someone had explained clearly to me a year ago". Almost all these apply to Cygwin in Windows as well as Mac/Ubuntu Terminal.

    1. More than just ls – "ls" lists files. But you’ll be faster if you learn the options and parameters.

    ls -l
    Lists files in long format, sort of like the default on Windows. Some systems have the "ll" command mapped to this by default. If "ll" does not work for you then open up your .bash_profile file and copy this into the last line: alias ll="ls -l". That’ll map ll for you.

    ls -CF –color
    Adds color to your directory listing. Executables, directories, and files are all listed in different colors. Yes, this is way to hard to type and remember every time. So make an alias which forces ls to be colorized. Again, open .bash_profile and stick this in there: alias ls="ls -CF –color". Now all usages of ls get colored.

    ls -a
    By default, ls ignores file starting with a dot (.). The -a option lists these files.

    2. More than just find

    find . -name
    ls does not search subdirectories by default, which the "dir" Windows command did. It takes a while to get used to is, but " find . -name "*file*" " is the same as " dir /s *file* ". It searches all directories for a given file. The period (.) must be escaped to ".". So to search for MyClass.java do "find . -name MyClass.java ". Yeah, the quotes are a hassle.

    find -exec
    You can execute a command for each result in the find result set, just use the -exec option along with some crazy notation. For instance, to open all matching files in gedit: " find . -name "*sh" -exec gedit {} ; " Again, kinda crazy syntax.

    Pipe and XARGS
    It’s a basic recipe to know. Here’s how to search all the files in your current directory for the word "mystring": find . | XARGS grep mystring . That’s all the grep I’ve ever needed.

    where
    Don’t know where a file comes from? "where" shows you the path to matching files. For instance "where java" responds with two different locations on my machine.

    3. cp, mv, rm, and all that – I warned you this was a beginners guide.

    cp – copies a file

    mv – moves a file. Please note, there is no rename command. There is only mv.

    rm – deletes a file. rm -rf does it recursively. Scared to run it? Just do an "echo rm -rf" instead to echo everything that /would/ be deleted to the console. Then you can verify that your command is correct.

    mkdir – same as Windows, makes a directory.

    touch – creates a file or updates the timestamp if it exists. Don’t bother with " echo "" > file.txt " just touch it instead.

    cat – This can be used the same as "type" on windows. It prints out the contents of a file to the console. There are tons of other uses for cat as well, but if you’re used to typing "type" then use "cat" instead.

    > and >> – Just like Windows, > pipes output to a file. >> appends to the file.

    4. &&

    Use && to chain two commands together. The second command only executes if the first command is successful. For instance, I use "svn update && svn status" to do them both in a pair. Chaining Grails commands together is nice as well.

    5. Learn some editors – Yeah you can use gedit, jedit, or ultraedit for editing and viewing text. But there are faster options.

    less
    This is a simple, scrolling file viewer. Works great on large files. I use it all the time for looking at svn diffs: "svn diff | less". Good for log files too. It can do more than this, but having scroll up and scroll down is often all you need. q key exits.

    nano
    need to edit something super simple? Nano is not a bad little editor for this. The big advantage to nano is that the arrow keys control your cursor position. I consider that a pretty basic requirement for a text editor.

    vi and vim
    Some people love vi. I don’t. If you’re convinced you must learn it, then check out Ted’s wallpaper and the keyboard stickers.

    6. chmod +x

    If you write a script you’ll want to execute the script. Set it into executable mode with "chmod +x [filename]". You need to do this sometimes to .sh files you download from the Internet as well. Mmmm… feel the bash power.

    7. Scroll with the keyboard – This is simple, but 100 million times better than the Windows console. Shift+PageUp and Shift+PageDown scroll the current terminal window without using the mouse. If you’re using Cygwin then switch to "rxvt". It’s a better shell than the default Windows one.

    8. kill

    kill
    Kills a process. But you need to know the process ID, which you can get with "ps". Hassle.

    ps -el | grep acroread
    Looks for processes matching the name "acroread" and prints out the process ID, among other things.

    pkill
    kills a process based on name. "pkill acroread" kills any acrobat reader processes.

    kill -9
    Kills a process without waiting for it to finish or interrupt properly. I’m sure I butchered the description, so search the Interwebs yourself if you want exact documentation.

    9. know your history – yeah up and down arrow keys still work to scroll through recent commands. No you should never have to resort to up and down arrows.

    history
    Lists out all your recent commands. By default, it lists 500 commands, but you can open up your .bashrc file and edit the HISTSIZE setting to change that.

    history | grep java
    Lists out all the commands you’ve used that have the word Java in it. Nice way to see a list of your recent commands pertaining to a particular program.

    !123
    This executes a recent command. For instance, of the "history" command reveals that "ps -el" is entry number 123, then "!123! will re-execute that command.

    Ctrl+R
    This is reverse search and way faster than history. Type Ctrl+R and then starting typing. Reverse search looks up any matching commands from your history, and you can hit Ctrl+R repeatedly to scroll through matches. For example, my USB stick is mounted somewhere and I always forget the path. So I Ctrl+R, start typing "media" and up comes "cd /mount/dev8/media" or something like that. I can’t remember the exact location because I never need to know it.

    Alt+.
    The Alt+period key combination repeats the last parameter from the last command. If you create a directory with "mkdir mydirectory" then you can type "cd ", press Alt+. and the "mydirectory" part will be filled in. Play with the period, using it is a big help.

    That’s It for Now

    9 tips seems like a good place to stop. I hope this helps someone. I realize I simplified the explanations of many of these commands; I wanted to make a short, useful description for beginners rather than a long, accurate description. If you have other tips or corrections then please leave a comment.

    Next up… an intermediate Bash blog post… stay tuned.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Mockito – Screencasts for Stubbing, Verifying, and Argument Matching

    December 15th, 2010

    We’re rolling out Mockito and trying to raise our testability at work and I’m set to give a presentation/training session tomorrow to a few new teams. In case you don’t know, Mockito is a mock object framework for Java. It’s competitors are EasyMock, JMock, and others if you’re more familiar with those. If you haven’t seen it then you may want to check out my old post “Mockito – Pros, Cons, and Best Practices“. To prepare for my presentation I decided to record myself practicing my material and post it on youtube. Enjoy!

    The first screencast is about creating mock objects and stubbing behavior. These are the absolute basics of mocking.

    The second screencast is about verifying behavior, or verifying side effects, using Mockito. This is a little more advanced but still an essential API in working with Mockito. YouTube reports this video as 13 minutes long, but don’t worry it is only 4:45. Some quirk of YouTube.

    The final screencast is about argument matchers, which add flexibility to your stub and verify phases.

    I hope you enjoyed these. They could be a little more practiced, but I’m happy enough with the quality. I recorded these on Ubuntu 10.4 using recordMyDesktop and mencode to convert from .ogv to .avi.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Slimmed Down Software – A Lean, Groovy Approach Part 6 – Respect People

    December 7th, 2010

    This article originally appeared in the September 2010 edition of GroovyMag, the Groovy and Grails magazine. Part 7 is currently available for download from the magazine’s site, and more will come each month. Previous articles in this series are on the Canoo website: Part 1: Eliminate Waste, Part 2: Build Quality In, Part 3: Create Knowledge, Part 4: Defer Commitment, and Part 5: Deliver Fast. Lastly, if you like this, you may want to check out some of my older blog posts from my personal site under the ‘craft’ category. Enjoy!

    The Groovy Programming Language advertises itself as an “agile and dynamic Language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each month’s article will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

    About this series

    Groovy is an agile programming language. In order to explain what this means, these articles are structured around the seven principles of Lean Software Development. The previous installments included a short introduction to Lean, explained how an expressive language can eliminate waste in unit testing, showed how the easyb Behavior Driven Development framework and Groovy Builders can build quality into your life-cycle, demonstrated how the Spock Testing Framework can create project knowledge, and discussed how tools like Real Options and dynamic languages defer commitment. This month we’ll see how Groovy’s Grapes module system, alongside modules like Groovy Web Services, streamline interactions between development and other groups like operations and QA (an important aspect of respecting people). Finally, we’ll look at optimizing the whole by applying Groovy to domains that cross department boundaries: how Gradle improves the build process and easyb serves as a collaboration mechanism between different organization roles. The series will end with a discussion on the best practices of mixing Java and Groovy.

    Some of the code examples are basic while others are advanced. The articles explore why the features of Groovy are important rather than the mechanics of any one Groovy feature. Hopefully you’ll leave with some new ideas about how to use Groovy, how to convince your team that Groovy is worthwhile, or most importantly, how to increase your productivity.

    Lean revisited

    Part 1 of this series contained a more in-depth explanation of Lean, and I won’t repeat it here. But as a quick refresher here are the 7 lean principles along with a summary for those principles covered previously:

    1. Eliminate Waste – Reduce work in progress and half done work
    2. Build Quality In – Instead of settling for finding defects, optimize your process to create fewer defects
    3. Create Knowledge – Create fast feedback cycle and encode project information in executable form
    4. Defer commitment – Delay decisions until the last responsible moment
    5. Deliver Fast – Increase velocity by working in small batches and removing bottlenecks
    6. Respect People
    7. Optimize the Whole

    Principle 6 – Respect People

    Respecting people means creating an environment where the human element drives innovation and value. Creative problem solving and spontaneity are our most valuable assets, and great companies arrange their development process to let every single employee be able to exercise these traits.

    My experience with a big Capability Maturity Model (CMM) rollout was exactly the antithesis of this: we brought in several outside consultants who proceeded to observe the way we worked, then created a disciplined process we were required to follow. In their hearts, the consultants believed they were respecting people because the process they documented and codified was the one that we ourselves, the workers, had created ad hoc over the last several years. But our ability to improvise and make changes to the process greatly diminished. Trying something new meant filling out paper work and appearing before a process change group, so most people stopped bothering. The consultants never understood why we refused to display any sort of ownership over the new process. Well, it’s hard to think you own something when you aren’t allowed to change it. A development process must be malleable and open to experimentation, not locked down. There is nothing wrong with bringing in some outside help, but be careful who you choose. Consultants leave you with a some new documents or artifacts; coaches leave you with new skills. Seek that latter.

    I’ve seen many development-led initiatives fail to respect people as well. At a previous company, we had a distinct pattern for making big technical decisions: call all the best people into a room to discuss the possibilities then assign a small group to deliver the changes. This ensured that the best developers solved the major issues, but everyone not in the council had neither input nor visibility into changes that affected their work. It was incredibly demoralizing to be a junior developer and know a big, new web framework was being developed behind closed doors, with no obvious way to influence its outcome. If you’re having a meeting with all the best people in your department, then there is only one thing you should be doing: firing everyone else. Seriously, what’s the value proposition of tolerating mediocrity? Why employ someone only to ignore their most valuable asset, their creative problem solving process?

    The open source community, and the Groovy community in particular, is an excellent case study in how to respect people. The entire Groovy product development process is open and transparent. If you want to know what is going on, then subscribe to the Groovy-Developer mailing list and the Groovy JIRA ticketing system on The Codehaus. Both resources are open to the public and almost nothing happens that is not documented in one of these two places. If you want to provide input to the future direction of Groovy then just get involved in the email discussion and start commenting on the issues. Of course, the real beauty of Groovy is how the language grows and accepts changes. More than other languages I have seen, Groovy relies on their actual users for improvements. If several users ask for the same utility method then, more than likely, that method will show up in the next release. Methods like the new tr(), stripMargin(), stripIndent, expand(), and unexpand() were all added for the forthcoming 1.8 release. Instead of relying on research papers and doctoral theses for inspiration on how to grow the language, Groovy looks directly to you, the users. Next time you need to copy and paste utility methods between projects, or somehow else share that StringUtils you have, why not just create a new JIRA ticket and attach the source? The community will thank you and you’ll feel good about yourself.

    The big question now is how you can get your company to start respecting people. Pitching an open source style work-flow isn’t going to get you very far. Most likely, the changes you need to make to start respecting people means changing a deep and long-standing business culture. Nathaniel Schutta summed up this common scenario perfectly: “Changing culture is hard, but for many organizations, it’s the critical first step towards better software.” Regardless of how open to new ideas your company is, the best approach to introducing change is often leading by example. The easiest way to convince a skeptical developer or operations team member of the value of Groovy is use it to make someone’s life easier. Repetitive environment configuration steps? Find a way to script it. Lengthy troubleshooting cycles? Ship operations some helpful .groovy files.

    Sidebar: Agile Stage 0

    Be careful promoting agility within your workplace: your company simply may not be ready. Andy Hunt of the Pragmatic Programmers describes an unwilling culture as “Agile Stage 0”, meaning it is not ready for agile. Symptoms include: behaving territorially, being inflexible, growing uncomfortable with uncertainty, treating developers like a commodity, and believing development is a linear process. If this describes your workplace, then expect a slow pace of adoption and find ways to enjoy the small victories.

    A sustainable pace for programmers requires that we are allowed to work with technologies we love. Great techies crave new technology, and good companies crave great techies. In general, which job description do you think appeals to the best programmers: one listing Java and JUnit or one listing Java and Groovy? Fostering pride in workmanship is a key part of Respecting People, and the cultural change of allowing new ideas and languages like Groovy to flourish in your workplace can improve morale, attract new employees, and retain the ones you have. I’ve seen this first hand on a past project. For companies that aren’t early adopters, that have lots of legacy code, using Groovy outside of production source code, in testing, scripting, and builds, can be a great way to energize and respect the team.

    Part of Respecting People is moving responsibility and decisions to the lowest level possible. The person most capable of making a decision about how to perform a job is the person doing that job. Creating knowledge of Groovy within your team gives everyone more and better choices for completing tasks. Consider the scenario of needing to create an ad-hoc web service client, perhaps for the QA or operations team to consume some of your web services. The GroovyWS module provides an easy way to do this, as seen in Listing 1.

    Listing 1: Deployable SOAP Web Services Script

    This script “Grabs” the GroovyWS module, contacts a web service endpoint, and dynamically creates a web service client capable of calling operations on the service. This is the entire application, nothing is hidden, including a deployment module! You can email this script to QA or Ops without a Jar and without an accompanying cryptic command line invocation. The @Grab Groovy annotation is a way to retrieve dependencies from repositories. Running this Groovy script will download the GroovyWS module and put it in the script’s classpath. The user only needs Groovy installed, one small change to the user’s HOME directory so that the Maven repositories can be found, and they will never again have to receive large Jar files or confusing scripts to run. And, unlike many Java web service solutions, there are no generated Java files that you’ll need to step through later trying to find out what is broken. The Grapes module system is a boon for anyone needing to help out other teams (which is pretty much all of us).

    Sidebar: Configuring Grapes

    Grapes needs to be told once where to find the Maven repositories. You do this in the ~/.groovy/grapeConfig.xml. On Unix systems, ~ is the user’s home directory, or $USERHOME. On Windows, this is something like “c:/Documents and Settings/username”. The GroovyWS website [4] has clear instructions on the XML to copy into this file.

    It is easy advice to tell someone they should learn a scripting language. Having Groovy available to write scripts like these, that leverage the Groovy module system and are easily run by other teams, has clear value when compared to trying to write the Java equivalent. But a problem arises when developers are allowed to use dynamic scripting languages only for scripting. How do you learn a language effectively when you can only use it for one task a month? You don’t. Using a scripting language only for scripting is a mistake. It ensures that only the most self-motivated developers will take the time to write a script, and the majority of developers will have no clue how to maintain it should anything ever break. Effective scripting will only happen after a language has been adopted, it is not a means to language adoption. Groovy testing is a better gateway towards making these other opportunities viable.

    Next steps

    W. Edwards Deming was an American statistician and professor who played a significant role in creating Japan’s reputation for high quality products. Deming emphasized a whole-systems, multi-dimensional view of the manufacturing process called the System of Profound Knowledge. Deming summarized his views in a short list of 14 points, one of which contained this: Eliminate annual performance ratings for salaried workers. I wholeheartedly agree. Annual performance reviews feed rivalry and office politics, producing an environment of fear around the first of the year. And for peer-reviews, I have never seen these amount to anything more than a popularity contest. The number one action to take to ensure a good year-end peer review is to remember to bring in treats and pastries once a month. So much for focusing on business value. Annual reviews do nothing to improve good teams and simply waste time for poor teams.

    Without reviews how will team members know how to improve? How will we know who to promote? How much do we give in raises? One of my favorite agile thinkers, Esther Derby, recently republished several articles on her website addressing just these issues [7], [8], [9]. Ongoing, face-to-face coaching sessions need to replace a year end evaluations. And if someone isn’t doing their job, then why wait for the year end cycle to fire the person? Likewise with those who are over-performing. If you don’t find ways to reward top performers more often than at year end, then you’ll find many of them move on in the middle of the year! Profit sharing is a much fairer compensation plan than raises, but most of us aren’t doing it for the money anyway. Before disagreeing too quickly, watch the YouTube video called “Drive: The surprising truth about what motivates us” [10]. You’ll realize reward is a complex subject; but reward definitely doesn’t come from a year end review process. A good step to building an honest, trust based, and high performing workplace is to throw out those cursed year end reviews.

    Next Month: Optimize the Whole

    Improving your business is too often an exercise in sub-optimization: you may spend all your effort on improving the unit testing experience without realizing it’s your interactions with operations that’s derailing the project, or you may perfect your own team’s delivery process while the rest of the company continues behaving wastefully. In either case, it pays to step back and examine the situation as a whole. If you’re optimizing your unit testing with Groovy, then step back and ask how you can improve the entire project and not just testing. If you’re working with your team on a better software life-cycle, then step back and ask how you could improve the life-cycle of all the teams. Next month we’ll discuss how to “measure up” and optimize the whole, looking specifically at how to use easyb to facilitate cross-department interactions and Gradle for full project automation.

    Learn More

    I’ll be presenting a session on Lean Groovy in Denver at the Uberconf conference in July. I hope to see you there! Otherwise, several references were used to create this article, and all are enjoyable, informative reads in their own right:
    [1] Lean Software Development – Poppendieck
    [2] Implementing Lean Software Development – Poppendieck
    [3] http://www.gembapantarei.com/2008/02/exploring_the_respect_for_people_principle_of_the.html
    [4] http://groovy.codehaus.org/GroovyWS
    [5] http://ntschutta.com/jat/2008/06/21/culture-kills/
    [6] http://blog.toolshed.com/2008/06/stage-0-not-rea.html
    [7] http://www.estherderby.com/2010/07/eliminate-performance-reviews.html
    [8] http://www.estherderby.com/2009/01/the-pay-off-in-merit-pay-not.html
    [9] http://www.estherderby.com/2010/07/performance-without-appraisal-addressing-the-most-common-concerns.html
    [10] http://www.youtube.com/watch?v=u6XAPnuFjJc

    Hamlet D’Arcy Canoo Engineering AG
    Hamlet D’Arcy has been writing software for over a decade, and has spent considerable time coding in C++, Java, and Groovy. He’s passionate about learning new languages and different ways to think about problems, and recently he’s been discovering the joys of both F# and Scheme. He’s a committer on several projects including Groovy, CodeNarc and JConch, and is a contributor on a few open source projects (including Griffon and the IDEA Groovy Plugin). He blogs regularly at http://hamletdarcy.blogspot.com and http://canoo.com/blog.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    css.php