<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.vitarara.org/cms" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>Vita Rara: A Life Uncommon - Java</title>
 <link>http://www.vitarara.org/cms/taxonomy/term/5/all</link>
 <description></description>
 <language>en</language>
<item>
 <title>Get the Running Version of Groovy</title>
 <link>http://www.vitarara.org/cms/node/182</link>
 <description>&lt;p&gt;This isn&#039;t documented in the Javadoc. (There is not javadoc on this method.) It seems to return the running version of Groovy when called:&lt;/p&gt;
&lt;p&gt;org.codehaus.groovy.runtime.InvokerHelper.getVersion()&lt;/p&gt;
&lt;p&gt;Helpful if you really need to know.&lt;/p&gt;
</description>
 <comments>http://www.vitarara.org/cms/node/182#comment</comments>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/68">Groovy</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/7">Programming</category>
 <pubDate>Sun, 22 Nov 2009 19:31:04 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">182 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>Testing Non-Ruby Applications with Cucumber</title>
 <link>http://www.vitarara.org/cms/testing_non-ruby_applications_with_cucumber</link>
 <description>&lt;p&gt;Yesterday we got Cucumber working to test an older J2EE application that uses EJB 2.1 for its persistence layer. This application because of the J2EE EJB 2.1 beans has been very hard to near impossible to test in the past. I&#039;ve been hearing about Cucumber for a while and we decided it was time to take a deeper look. &lt;/p&gt;
&lt;p&gt;We plan on adding new features to this application using Rails, and over time porting the existing functionality to Rails. So, having a test suite written in Ruby that can test the application regardless of the underlying implementation was necessary. Cucumber with Webrat to the rescue. The general outline below will work with web applications written in any language. All of the interaction with the application happens at the HTTP protocol level.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://www.vitarara.org/cms/testing_non-ruby_applications_with_cucumber&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.vitarara.org/cms/testing_non-ruby_applications_with_cucumber#comment</comments>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/102">Cucumber</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/12">EJB</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/62">J2EE</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/82">Ruby</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/83">Ruby on Rails</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/104">Testing</category>
 <pubDate>Thu,  5 Mar 2009 17:38:35 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">175 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>Why I Chose JRuby Over Groovy</title>
 <link>http://www.vitarara.org/cms/why_i_chose_jruby_over_groovy</link>
 <description>&lt;p&gt;After reading &lt;a href=&quot;http://www.khelll.com/blog/ruby/the-power-of-jruby/&quot;&gt;The power of JRuby&lt;/a&gt; and the discussion that ensued I was inspired to write about why I chose Ruby and particularly JRuby as my company&#039;s primary development platform.&lt;/p&gt;
&lt;p&gt;I didn&#039;t write this post as a knock on Groovy. If it wasn&#039;t for Groovy I doubt I&#039;d be working in Ruby today. For me Groovy was my &quot;gate-way drug&quot; into the dynamic language realm. My reason for this post is to explain why someone might want to use Ruby on the JVM over Groovy.&lt;/p&gt;
&lt;p&gt;After working with Groovy for quite a while I started dabbling in Ruby. At first I really didn&#039;t get it. Then I watched a &lt;a href=&quot;http://www.infoq.com/presentations/metaprogramming-ruby&quot;&gt;presentation by Dave Thomas&lt;/a&gt; and the lights went on. A world of possibilities opened up for me, and they were easily in reach.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://www.vitarara.org/cms/why_i_chose_jruby_over_groovy&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.vitarara.org/cms/why_i_chose_jruby_over_groovy#comment</comments>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/68">Groovy</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/93">JRuby</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/82">Ruby</category>
 <pubDate>Mon, 12 Jan 2009 15:13:44 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">171 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>How I Got Over &quot;import java.util.*;&quot;</title>
 <link>http://www.vitarara.org/cms/node/164</link>
 <description>&lt;p&gt;It&#039;s taken me years, but I finally got over import java.util.*;. First, I don&#039;t use an IDE. I know an IDE could manage my imports, but I&#039;m not an IDE guy. So, for years I&#039;ve managed my imports manually, or given up and done import java.util.* and felt guilty about it.  Well, I&#039;m over that, and I can give Groovy the credit. By default Groovy imports java.util.*. I&#039;ve been using Groovy every day now for about a year and a half and the house is still standing, our code compiles, we haven&#039;t had name conflicts. Things work, and it&#039;s a lot easier.&lt;/p&gt;
&lt;p&gt;I used to worry about name clashes and compilation speed, and other shiboleths spoken of around coder camp fires and in hushed tones. After all everyone &quot;knows&quot; that the * should be avoided. Well, I&#039;m over it, import java.util.* is just fine with me. Now when I start a Java source file I almost always just add java.util.*.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://www.vitarara.org/cms/node/164&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.vitarara.org/cms/node/164#comment</comments>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/68">Groovy</category>
 <category domain="http://www.vitarara.org/cms/java">Java</category>
 <pubDate>Tue, 11 Mar 2008 14:43:35 -0400</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">164 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>Using Dynamic Method Invocation to &quot;Script&quot; Java</title>
 <link>http://www.vitarara.org/cms/using_dynamic_method_invocation_to_script_java</link>
 <description>&lt;p&gt;Although Java isn&#039;t thought of as a dynamic language now a days, what with Ruby and Groovy being all the rage, Java does have support for dynamic features. (See my &lt;a href=&quot;/cms/whats_wrong_with_javas_dynamic_dispatch_and_how_to_fix_it&quot;&gt;previous blog post&lt;/a&gt; on the subject and the solution I came up with.)&lt;/p&gt;
&lt;h2&gt;A Use Case for Dynamic Java&lt;/h2&gt;
&lt;p&gt;Currently I&#039;m wrapping about a hundred EJB 2.1 LocalHome classes in DAO&#039;s, and having them transform local EJB entities into POJO&#039;s. Much of the code is largely boiler plate. Actually it&#039;s mind numbingly boiler plate. Here&#039;s a sample of wrapping a finder:&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://www.vitarara.org/cms/using_dynamic_method_invocation_to_script_java&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.vitarara.org/cms/using_dynamic_method_invocation_to_script_java#comment</comments>
 <category domain="http://www.vitarara.org/cms/java">Java</category>
 <pubDate>Tue, 26 Feb 2008 00:03:56 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">163 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>What&#039;s Wrong with Java&#039;s Dynamic Dispatch or &quot;How I Implemented sendMessage()&quot;</title>
 <link>http://www.vitarara.org/cms/whats_wrong_with_javas_dynamic_dispatch_or_how_i_implemented_sendMessage</link>
 <description>&lt;p&gt;(Related article using this technique to &quot;script&quot; some Java objects: &lt;a href=&quot;http://www.vitarara.org/cms/using_dynamic_method_invocation_to_script_java&quot;&gt;article&lt;/a&gt;.)&lt;/p&gt;
&lt;p&gt;The following code quickly illustrates an issue with the Reflection API&#039;s in the Java language. At run time finding methods on classes requires that the types passed to Class#findMethod() exactly match those found in the method declaration. The JavaDoc and language spec refers to these as the &quot;formal parameter types&quot;.&lt;/p&gt;
&lt;p&gt;The issue is, I have a method that takes an A, and I have an object of B that extends A. If you run the following code it will fail, being unable to find the method.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://www.vitarara.org/cms/whats_wrong_with_javas_dynamic_dispatch_or_how_i_implemented_sendMessage&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.vitarara.org/cms/whats_wrong_with_javas_dynamic_dispatch_or_how_i_implemented_sendMessage#comment</comments>
 <category domain="http://www.vitarara.org/cms/java">Java</category>
 <pubDate>Mon, 25 Feb 2008 23:33:24 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">162 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>Closures and Bindings in Groovy</title>
 <link>http://www.vitarara.org/cms/closures_and_bindings_in_groovy</link>
 <description>&lt;p&gt;You can learn something every day. That&#039;s what is so nice about being a software developer.&lt;/p&gt;
&lt;p&gt;Today I was looking at some Grails code, seeing how some of the metaprogramming features of Groovy are used in the framework. After poking around I decided to look at the ServicesGrailsPlugin to see how the automatic wiring of services was done, and ran across the following code:&lt;/p&gt;
&lt;pre&gt;
def doWithSpring = {
  application.serviceClasses.each { serviceClass -&amp;gt;
      def scope = serviceClass.getPropertyValue(&quot;scope&quot;)

    &quot;${serviceClass.fullName}ServiceClass&quot;(MethodInvokingFactoryBean) {
      targetObject = ref(&quot;grailsApplication&quot;, true)&lt;p&gt;&lt;a href=&quot;http://www.vitarara.org/cms/closures_and_bindings_in_groovy&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.vitarara.org/cms/closures_and_bindings_in_groovy#comment</comments>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/74">Grails</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/68">Groovy</category>
 <pubDate>Fri,  8 Feb 2008 13:06:57 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">161 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>Yes the JVM is a Multi-Language Platform</title>
 <link>http://www.vitarara.org/cms/node/160</link>
 <description>&lt;p&gt;Although talk about multiple languages running on the JVM has grown over the past few years, the reality of it really hit home with me this morning. I turned to one of my employees who has been doing JVM development for me since April of last year. The interesting thing is probably 95% of the JVM work he has done isn&#039;t in Java, it&#039;s in Groovy. Here&#039;s to the multi-language Java platform and a thank you to those developers who are making it a reality.&lt;/p&gt;
</description>
 <comments>http://www.vitarara.org/cms/node/160#comment</comments>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/68">Groovy</category>
 <category domain="http://www.vitarara.org/cms/java">Java</category>
 <pubDate>Thu,  7 Feb 2008 11:52:50 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">160 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>The Future That Has Already Happened</title>
 <link>http://www.vitarara.org/cms/node/153</link>
 <description>&lt;p&gt;January second&#039;s Daily Drucker dealt with the future, but not as most business prognosticators or futurists might. As Drucker states it, &quot;The important thing is to identify the &#039;future that has already happened...&#039;&quot;&lt;/p&gt;
&lt;p&gt;The action point for the day is to identifying those trends in our market that have already happened, write about their longevity and their effect on our life and organization.&lt;/p&gt;
&lt;h2&gt;Software as a Service For the Rest of Us&lt;/h2&gt;
&lt;p&gt;Over the past few years, and particularly in 2007 Software as a Service (Saas) has really broken out and has become a force in the software industry. The first large scale SaaS offering that really broke through to my consciousness was Salesforce.com, then for me came Basecamp from 37signals.com. Salesforce.com represented a high level enterprise offering, with a high level of complexity and expense. Basecamp brought software as a service home to us all.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://www.vitarara.org/cms/node/153&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.vitarara.org/cms/node/153#comment</comments>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/68">Groovy</category>
 <category domain="http://www.vitarara.org/cms/java">Java</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/85">Management</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/86">Peter Drucker</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/83">Ruby on Rails</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/88">Scala</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/87">Software as a Service</category>
 <pubDate>Fri,  4 Jan 2008 14:59:42 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">153 at http://www.vitarara.org/cms</guid>
</item>
<item>
 <title>2007: A Retrospective</title>
 <link>http://www.vitarara.org/cms/2007_retrospective</link>
 <description>&lt;h2&gt;Personal Life&lt;/h2&gt;
&lt;p&gt;Sylva and I got married on April 28. It&#039;s been a real whirl wind since then. We are expecting our first child on April 1, 2008. My time with Sylva is special and precious. I have a great partner, and look forward to raising a family together. &lt;/p&gt;
&lt;p&gt;Overall business issues have dominated this year. I doubt that will be that case next year.&lt;/p&gt;
&lt;h2&gt;Business&lt;/h2&gt;
&lt;p&gt;It was a hard business year, but prospects for the future look good.&lt;/p&gt;
&lt;h2&gt;Quadran&lt;/h2&gt;
&lt;p&gt;Quadran has arrived. About 63,000 lines of Groovy, Java and JSP, with some XML files to wire it all together, and it&#039;s up and running. We turned on our first Quadran installation on December 5, 2007. This was the culmination of a process that began with an initial meeting in September of 2004, and the consummation of the development agreement in July of 2006.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://www.vitarara.org/cms/2007_retrospective&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.vitarara.org/cms/2007_retrospective#comment</comments>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/38">Freemasonry</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/68">Groovy</category>
 <category domain="http://www.vitarara.org/cms/java">Java</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/17">Quadran</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/82">Ruby</category>
 <category domain="http://www.vitarara.org/cms/taxonomy/term/83">Ruby on Rails</category>
 <pubDate>Sun, 30 Dec 2007 14:51:33 -0500</pubDate>
 <dc:creator>Mark</dc:creator>
 <guid isPermaLink="false">151 at http://www.vitarara.org/cms</guid>
</item>
</channel>
</rss>

