tag:blogger.com,1999:blog-80680727366643396052023-06-20T23:57:34.178-05:00Software MavenWhen it's more than a job, it's a craft.Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-8068072736664339605.post-85021020730663045012010-04-23T01:02:00.000-05:002010-04-23T01:02:01.788-05:00How I got into Ruby (You've got red on you)<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">At the inception of our project, my colleague and I had the opportunity to choose the technology stack. Since we were both Java peeps it seemed natural to start designing the app, a REST based service, using the new <a href="http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/">Spring 3.0 MVC</a> stuff. We even started to watch some videos on <a href="http://www.springsource.org/roo">Spring Roo</a> to get it off the ground. The reality of our situation though is that we were developing one of many systems to the client. The other system is being developed in Ruby and the majority of developers at the client are also Ruby developers. Based on this, we decided that sticking with Ruby would be a better fit for the client.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">There were two factors easing the discomfort of taking on a new technology to deliver a system on schedule. The first is the relatively simple nature of the application. It's a REST service that does some simple checkout process with moderate performance requirements. Nothing brutal. The other is having an extremely talented Rubiest on my team. <a href="http://twitter.com/tobytripp">Toby's</a> been more than happy to help convert a Maven loving Java dude like me over to the crimson side. I knew with him around this was my best chance to build my first non-trivial Ruby system.<br />
<br />
So far it's been a fun ride and after a few weeks it feels like I'm finally starting to breathe some air. The syntax and conventions are starting to become familiar and the ability to navigate stack traces and documentation is improving. Another great ancillary effect is that the functional and dynamic aspects of Ruby have been connecting some of the disjointed dots which surfaced during my brief studies in Clojure.<br />
<br />
I do however miss terribly the luxuries that stricter syntax and strong typing enable, especially for tool support. Please refrain from the real coders don't need an IDE spiel. I miss strong refactoring support, especially because my newbie Ruby needs a lot of it. Static analysis and code completion are also wonderful for learning new syntax and API's. Knowing which methods are available to call on a variable is nice. Being able to click through to the source code of that method or see the doc in a tool tip on hover is very nice. <br />
<br />
But I'm always happy to learn even if it means re-learning how to learn.<br />
<br />
I will be blogging some of the things I banged my head against in order to help others new to Ruby, allow current Rubiests to laugh at my newbieness now, and most importantly allow me to laugh at myself later! Stay tuned. </div>Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-62708763309960310462010-04-21T01:09:00.001-05:002012-06-01T11:51:19.593-05:00Chicago Clojure MeetupThere's no doubt that I loves me some Clojure. Just listening to guys talk about though it honestly makes me feel like I never took a college comp sci course and I love it for that. Who would have known LISP would ultimately rule the world! Lispers, I guess.<br />
<br />
When <a href="http://docondev.blogspot.com/">Michael Norton</a> asked if I'd like to help out with the <a href="http://www.meetup.com/Chicago-Clojure/">Chicago Clojure group</a> I was quick to hop on board. Now, I'm no <a href="http://github.com/technomancy/clojure-http-client">Phil Hagelberg</a>, but few are? All I know is that playing around in FP land was a wonderful and eye opening experience after being nose to the grind in Java's OO for many years. I can't wait to get these rolling on a regular basis.<br />
<br />
<a href="http://www.meetup.com/Chicago-Clojure/">So sign up for for the group</a> and bring your self down on May 19th. We are taking recommendation on topics so please suggest something or vote for what you want to hear about.<br />
<br />
Plus, there will be pizza!<br />
<br />
<span class="Apple-style-span" style="font-size: x-small;">(I in no way guarntee the availability of pizza at the Chicago Clojure meetings). </span>Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-78130241343220061742010-04-21T00:27:00.000-05:002010-04-21T00:27:50.827-05:00Time to dust this thing off.<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">So where have I been?</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">New job. New marital status. New layer of skin (after Jamaican Sun peeled off the first layer). Most exciting to you (my 2 followers (and Minella's RSS feed)). New languages! New technologies! All that jazz.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">Since joining Thoughtworks (yay), I've been using a lot of Ruby. I've tried to do Ruby several times in the past but never had the opportunity to do anything non-trivial. The last time I tried to use Ruby was with <a href="http://musingsofaprogrammingaddict.blogspot.com/2009/08/scriptable-dataset-10-released.html">Gunnar Morling's Sriptable DBUnit DataSet</a> for the Maven/Cargo/Tomcat/H2/Selenium automated web test stack that I never blogged about.</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">So what I will be talking about in the near future is my experiences of turning to the world of Ruby, which has so far involved the battery of <a href="http://rspec.info/">RSpec</a>, <a href="http://rack.rubyforge.org/">Rack</a>, <a href="http://www.sinatrarb.com/">Sinatra</a>, <a href="http://rake.rubyforge.org/">Rake </a>(yes Rake), <a href="http://www.modrails.com/">Passenger</a>, <a href="http://gembundler.com/">Bundler</a>, <a href="http://github.com/rtomayko/shotgun/">Shotgun </a>as well as <a href="http://github.com/jnunemaker/mongomapper">MongoMapper</a> since we are using <a href="http://www.mongodb.org/">MongoDB </a>as our datastore. We needed to make use of geospatial indexing and <a href="http://www.mongodb.org/display/DOCS/Geospatial+Indexing">MongoDB </a>did one hell of a job against <a href="http://postgis.refractions.net/">PostGIS</a> for our use case. Although I do love SQL and relational as well as multidimensional data modeling , my first No-SQL experience has been undeniably great.<br />
<br />
Hopefully I'll find some time to pretty this generic template up as well. Stay tuned!</div>Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-25507267137296657892010-01-25T01:44:00.049-06:002010-03-11T14:12:07.327-06:00Top 10 reasons why Maven sucks...not!I'm having a hard time understanding all the Maven bashing that takes place these days. Maven has been a real joy for me. It could be the simple fact that I can move from colleague to colleague's project without wondering what ant tasks are available or where the files are. It could be the fact I don't have to <a href="http://wiki.netbeans.org/MavenBestPractices">configure</a><a href="http://www.jetbrains.com/idea/features/ant_maven.html"> IDE's</a> <a href="http://m2eclipse.sonatype.org/">anymore</a>, not even for <a href="https://docs.sonatype.org/display/M2ECLIPSE/Resolving+artifact+sources">downloading sources</a>. <a href="http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin">It</a> <a href="http://mojo.codehaus.org/dbunit-maven-plugin/">could</a> <a href="http://mojo.codehaus.org/sonar-maven-plugin/">be</a> <a href="http://www.terracotta.org/confluence/display/wiki/Terracotta+Maven+Plugin">some</a> <a href="http://mojo.codehaus.org/selenium-maven-plugin/">of</a> <a href="http://cargo.codehaus.org/Maven2+plugin">my</a> <a href="http://mojo.codehaus.org/sql-maven-plugin/execute-mojo.html">favorite</a> <a href="http://wiki.github.com/mrdon/maven-cli-plugin/">plug-ins</a>. Maybe it's the <a href="http://jarvana.com/jarvana/info/repository_statistics">250,739 artifacts that are available</a> in three lines of copy paste declaration. <a href="http://maven.apache.org/plugins/index.html">There's a lot to love</a>. <br />
<br />
I'll admit, it didn't make sense at first. It felt a little too large and I was leery of the potentially restrictive guidelines. I was also very nervous to commit to the predefined life cycles and directory layout. Within a short period of time I learned a minimal pom provided more function than a minimal ant script and the conventions are actually what enable you to easily add more to the build. After an objective comparison to previous projects I've worked on I determined that while less flexible, Maven's life cycle is both adequate and consistent. Over a few years of use, adequate and consistent has proven to be far more <b><i>valuable </i></b>than unique or powerful. This is the build, not the software we're building. There's plenty of business logic to make our systems complex. The statement that alternative build tools are more powerful is also debatable. <br />
<br />
Let me be clear, I'm not recommending we all use Maven or stop working on alternative tools. I am, however, asking that people give Maven a break. A lot of Maven criticism borders on ludicrous. We're all open source advocates (right?). If you dislike it, <a href="http://www.sonatype.com/people/2009/11/maven-3x-community-participation-multi-threaded-execution/">you know what to do</a>. If you have a specific need, <a href="http://maven.apache.org/guides/plugin/guide-java-plugin-development.html">write a mojo</a> (and share it, or don't). If you're going to speak out, offer constructive criticism. In the very least, try not to make your anti Maven rant based on a string of fallacies. I'm trying not to pick on any specific alternatives or individual, but let's walk though <a href="http://betarelease.github.com/2009/06/01/top-ten-reasons-why-maven-sucks.html">this one</a> item by item:<br />
<br />
<blockquote><b><i>10. maven corrupts – software, people.</i></b></blockquote><blockquote>Maven exposes circular dependencies and actually uses the checksums it generates. The software aspect isn't true. Maybe I'm a little corrupted, but I'd consider it more like being spoiled. There's also the expression that power corrupts and with a side note about absolute power. The availability for corruption seems to resonate more strongly with the thought of an entire programming language at your disposal. It's all up to how the power is used.</blockquote><blockquote><b><i>9. maven uses an archetype(appfuse) and expects that all your projects look like the apache projects – even those that are not webservers.</i></b></blockquote><blockquote>I'm not really sure what this means. I think Maven expects that your projects look like Maven projects. That's what the convention means. When I looked at appfuse projects, they looked like Maven projects to me but maybe it's a chicken and egg thing, which much like the riddle itself, doesn't have much incentive to solve. </blockquote><blockquote><b><i>8. maven has only four build stages – compile, test, install, package – if you have a requirement to automate performance testing you are out of luck</i></b></blockquote><blockquote>There are <a href="http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html">quite a bit of hooks in the build lifecycle</a>. It was added later, but I believe you want integration test (with pre and post integration hooks). I use a fully automated functional test suite that deploys and fires up selenium. I heard Terracotta was using it to fire up two instances of Tomcat to test fail over scenarios. These aren't performance tests, but I'm sure it's achievable. </blockquote><blockquote><b><i>7. maven requires you to have a standard directory structure that is 5 subdirectories deep – regardless of the fact that your project only has 10 java files.</i></b></blockquote><blockquote>src/main/java . Let's see that's 1,2,3. I think it's a good convention and so do <a href="http://buildr.apache.org/projects.html#dir_structure">several</a> <a href="http://www.gradle.org/0.8/docs/userguide/java_plugin.html#N1158A">other</a> <a href="http://code.google.com/p/simple-build-tool/">alternatives</a>.</blockquote><blockquote><b><i>6. tasks that are not implemented in maven have to be implemented in ant and need to be integrated with maven – a big nightmare.</i></b></blockquote><blockquote>The only situation where I've been forced to use Ant was to sign an applet jar to put into a war-file. That unfortunate situation was due to a defect we experienced jar:sign goal. After 10 minutes of trying to get it to work, we found a defect in a jira somewhere. To work around the issue we tossed in the Ant task from the original build script. Since then the <a href="http://maven.apache.org/plugins/maven-jarsigner-plugin/">maven-jarsigner-plugin</a> has evolved and I'm pretty sure we could remove the ant-run task if we were into fixing what ain't broke. </blockquote><blockquote>With that said, it's stupidly simple to use <a href="http://maven.apache.org/plugins/maven-antrun-plugin/plugin-info.html">ant-run</a>. You don't even have to go download Ant, nor does the n'th machine that your build will run on have to download it. Nightmare? I've spent more time setting ANT_HOME and configuring PATH variables. </blockquote><blockquote><b><i>5. maven encourages you to integrate via binaries – thus making continuous integration difficult</i></b></blockquote><blockquote>I've used Hudson and Bamboo extensively. Both have <a href="http://wiki.hudson-ci.org/display/HUDSON/Building+a+maven2+project">excellent facilities</a> <a href="http://confluence.atlassian.com/display/BAMBOO/Bamboo+2.5+Release+Notes#Bamboo2.5ReleaseNotes-MavenDependencyManagement">specific to Maven</a>. I don't even understand what the alternative to binary integration is. I wish the complaint had a specific scenario for me give a valid counter point. </blockquote><blockquote><b><i>4. every time maven builds it connects to the internet (to verify/update dependencies) – building your project without the internet is extremely hard.</i></b></blockquote><blockquote>Not true. Maven grabs it once then it never needs the internet except once a day for snapshot, which is for your convenience and can also be <a href="http://maven.apache.org/ref/2.0.8/maven-settings/settings.html#class_snapshots">disabled</a>. Don't forget offline mode. And you really should take 5 minutes to setup <a href="http://nexus.sonatype.org/">Nexus </a>for a little durability in the event of an internet outage.</blockquote><blockquote>Follow up question, how easy is doing anything without the internet? Specifically, how easy is executing code you don't have on your local machine without the internet? </blockquote><blockquote><b><i>3. maven manages the projects and subprojects implicitly (since there is convention and then there are overrides) – it makes debugging your build impossible.</i></b></blockquote><blockquote>You can always see the <a href="http://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html">effecive-pom</a> if you need to. It's not very hard to see exactly what overriding is going on.</blockquote><blockquote><b><i>2. maven manages the project dependencies in its own repository – called the .m2 repository – which is not part of your application folder – thus making it impossible to track and package development environments.</i></b></blockquote><blockquote>This repository is the local repo. It is not part of your application folder because you probably have more than one project that requires commons-logging.jar. You can <a href="http://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.html"> track which files make up your development environment</a> pretty easily. You can also <a href="http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html">copy them to your development environment</a> or <a href="http://maven.apache.org/plugins/maven-assembly-plugin/">package them for several different environments</a>. Pretty flexible facilities in place for dependency management</blockquote><blockquote><b><i>1. maven always downloads the whole internet – to keep its dependencies up to date – even though you don’t want to.</i></b></blockquote><blockquote>Whole internet? At this point I'm trying hard not to reply with sarcasm. I'm not trying to attack the author, just disprove the points. And to address the point, 2.0.9 and up has predefined plug-in versions. They do not update on their own. <a href="http://www.sonatype.com/people/2008/04/maven-209-released/">Anything else it updates because you didn't tell it not to by specifying a version for your plug-ins</a>. </blockquote><br />
This is the type of FUD you can easily find by doing a Google search for "Maven sucks". Here's why I believe it doesn't <i>suck</i>.<br />
<br />
Maven's declarative model allows you to prepare structured data, the primary application of XML, to a system that knows how to do what you want. Very <i>goal oriented</i>. The primary motivation of Ant was to have platform independent scripts for Java which was platform independent. That's why at the time, Ant was hot sauce on fried chicken! The problem for me with scripting language based build systems is that most remain <i>task oriented. </i>Staying disconnected from the tasks required to complete a goal is a <a href="http://www.ddj.com/184409952?pgno=8">great gain</a> <a href="http://www.knabedesign.com/articles/stc_article.html">in overall usability</a>. Maven stays focused on the latter and offers the flexibility to tweak the tasks when necessary. <br />
<br />
In addition to the lack of branch logic and variable declarations, the main gripe on XML is that it is too verbose. But so is the documentation for an ENTIRE LANGUAGE!!! DSL subsets make it easier but there's still a learning curve, especially if someone gets clever. Learning Maven definitely does not happen immediately, but what you are learning is domain knowledge for the task at hand, build management. Every other build tool I've given the cursory glance to required I learn about its build process in addition to a full language or DSL. XML, for all of its lousiness, is ubiquitous and self describing. Lack of cleverness can be a good thing. <br />
<br />
<a href="http://github.com/sonatype/polyglot-maven">That might all be a moot point since polyglot maven is right around the corner</a>. I'll probably stick to XML because I don't write XML, Eclipse does (so do many text editors, with syntax and error checking to boot). Still I am very interested in the project and using it as my primary excuse to get some <a href="http://clojure.org/">Clojure </a>in my life. I do have fearful thoughts regarding what tricks someone will put into their builds using these alternatives, but if it means more people are happy about Maven I'm all for it.<br />
<br />
<br />
<a href="http://www.draplin.com/pics/gary_huh.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="140" src="http://www.draplin.com/pics/gary_huh.jpg" width="200" /></a>After all, why shouldn't Maven cater to those who crave the additional power. <b>Let's not forget that it was created to help you, not make your life hell.</b> There's an age old expression I learned from Gary Coleman at a young age regarding different strokes and world domination. Some people drive stick and others prefer automatic. I prefer automatic because it allows me to do other things like spam text messages instead of shifting. A manual transmission might just encourage me to speed off the road or get a traffic violation. There's a method to the madness of preventing someone from acting foolish. Think of that traffic law as a metaphor to prevent <a href="http://svn.apache.org/repos/asf/ode/trunk/Buildfile">a rake script gone crazy</a>. I personally feel that when Maven isn't making something easy, it's because it probably shouldn't be done in the first place, not in the build at least. For all other times, there's the <a href="http://docs.codehaus.org/display/GMAVEN/Executing+Groovy+Code"><span style="color: black;"> </span>gmaven</a> plug-in, but I really really try not to make my colleagues go through the unfortunate pain of learning a new language just to execute my tests or create a custom jar file. <br />
<br />
Is the power of a Turing complete language really necessary to compile, execute tests, package and/or deploy your code?<br />
<br />
So to <a href="http://www.comedycentral.com/videos/index.jhtml?videoId=11879">wrap it up</a>, I don't understand the hatred towards Maven. Some people act like it stole their prom date. I'm happy for alternatives like <a href="http://buildr.apache.org/">buildr </a>and <a href="http://www.gradle.org/">gradle</a> and realize no matter how great any project is it will eventually be replaced. I don't discourage people from trying or developing new tools, even though I would love to see those efforts put into Maven instead. Different strokes! Opinions aside, it is and will forever be a tool that redefined build management and whatever tool replaces can only improve upon the baseline it has established.<br />
<br />
But the inaccurate, almost childish Maven ranting has to come to an end! It's downright ungrateful and disrespectful to the people who have worked very hard to provide a free and open source option. Newer alternatives greatly benefit from the groundwork laid by Maven in the first place including the repository or directory layout conventions. So in the least pay homageAnonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com66tag:blogger.com,1999:blog-8068072736664339605.post-62975870596265664302009-12-27T09:36:00.003-06:002010-03-21T11:44:56.996-05:00Scala, the passion is finally starting to take hold.I have to admit, I'm starting to warm up quite a bit to Scala. It was of interest to me but after I had seen <a href="http://www.agiledeveloper.com/aboutus.aspx">Venkat Subramaniam's</a> talk at the NFJS conference this year, I decided it was past time to pickup some books and start looking at it seriously. <br />
<br />
Usually my biggest problem with moving away from Java is the tool support. This holds little water with those who still think simple text editors are the best way to code. Maybe I'm ruined by technology, but hovering over a method to see the javadoc or hitting F3 to view the source code takes the annoying out of learning new languages. Without this support, so much time is wasted on petty syntax errors and searching though api doc that could have come with trusty ctrl+space. Well it turns out the tool support for Scala in Eclipse and NetBeans was actually pretty good. The static typing (low ceremony static typing I might add) enables the editor to do some pretty nice type checking, code completion and syntax highlighting. This was a nice change over the dynamic languages I've been dabbling in. <br />
<br />
After playing around with the simple examples in Ordesky's book, I skipped straight to the Swing chapters. I found the syntax to be nice and concise but the problem is that I can't compare it to Swing code I've written because I DO NOT WRITE GUI'S BY HAND. There's a product called NetBeans that works brilliantly for GUI design. Hopefully I'll get to use again before Oracle throws it under a bus. After that I tried looking into <a href="http://liftweb.net/">liftweb</a>. That was a less than optimal experience due to the Maven archetypes being a cross between out of date and flat out broken. I had good luck with the mailing list but my GitHub <a href="http://github.com/dpp/liftweb/issues/closed/#issue/246">ticket</a> (which is one hunky <strike>piece of crap</strike> work in progress) was closed, probably because of my lousy issue title. <br />
<br />
So after my "ok who cares about SwingBuilder", a flacid Lift-off with liftweb, and the lack of needing to build a highly concurrent HelloWorld with actors, I started to think that maybe I'll enjoy using Scala in the future but at this point there unfortunately wasn't a use for it in my daily life. Then I was put into a situation of prototyping something for someone which required handing in a fully functional application, in Java, and this is where the fondness began to grow. <br />
<br />
The thing that drove me absolutely nuts was all of these high ceremony domain objects. 150 out of 450 total lines were public getters and setters. Sure eclipse generated them but I got so distracted by the noise. The worst part is you have to JavaDoc all of those too (or should). It also makes re-factoring more of a pain. What a waste of time! The other feature that I really wanted to leverage was fine grained access control. The problem dealt with moving vehicles based on received commands. It seemed natural to put turn and move commands on the vehicles which mutated their coordinates. I think my functional friends would recommend something that takes and returns a new rover but one step at a time for me dudes. I did have a command processor which processed the inbound commands and then executed them on the rover. It would have been nice to restrict access to the turn and move methods only to this command processor interface to prevent someone who doesn't know what they're doing from moving the vehicle off a cliff. <br />
<br />
I used to hold design patterns close to my heart until I heard someone say design patterns only serve as workarounds to deficiencies in a language. The more I learn Scala the more I see these deficiencies in Java. I still don't and never will dislike Java, but I do think I'm going to start mixing a little Scala in with my everyday applications. At least for domain objects or objects that have a lot of member variables. <br />
<br />
If you're in Chicago you should try to attend the <a href="http://www.meetup.com/chicagoscala/">Chicago Area Scala Enthusiasts(CASE)</a> meetup that is hosed by <a href="http://deanwampler.com/">Dean Wampler</a>. Dean's a great presenter and top notch technologist. He covered <a href="http://code.google.com/p/scalacheck/">ScalaCheck </a>and <a href="http://www.artima.com/scalatest/">ScalaTest </a>this week and he also showed use of <a href="http://code.google.com/p/simple-build-tool/">Simple Build Tool (SBT)</a> which does some pretty nice tricks like continuous compilation and testing. It also wins points with me for supporting Maven dependency management.Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-48299111051194457112009-11-11T19:52:00.014-06:002009-11-11T23:44:08.609-06:00Pimping Cygwin part I: Terminal GoodnessMy inaugural experience with Linux as a desktop started with Gentoo in 2005. I used openbox as my windows manager. The extent of my GUX (graphical user experience) was right clicking the desktop to launch a terminal and off I went. The concept of putting a file or folder on the desktop wasn't there and I became quite fond of mv, mkdir and rm. Since then I've tried to use RHEL, Fedora, Solaris, and all the 'buntu's. Aside of the fact my games don't run and the drivers were always substandard, I was never happy with the experience of the interface. The only thing I ever miss about Linux is the shell. A big argument in the developer community on switching to Apple is the use of a <span style="font-style:italic;">real</span> bash shell. I guess that's if you consider Terminal to be a real terminal. In the interest of not losing potential followers, I'll refrain from speaking on why I hate Apple. I'd entertain some comment discussion for anyone who questions my right to hate them but that's not the point of this blog. Instead, I'm here help you configure Cygwin for some Linux goodness on your Windows machine. I'm calling this part one because it would be a tremendously long post to detail everything great about Cygwin. Ultimately it's a terminal/shell I'm after so let's start off with how to get that working. <br /><br />The first real problem with Cygwin is that by default it starts up in a DOS window. Come on Windows! Is a command line that supports line wrap copy/paste really that hard to provide? This can be a really bad first impression to the casual user who installs Cygwin. Thankfully, there's an rxvt implementation available for Cygwin, but making that useful isn't super straightforward either. <br /><br />First, you have to remember to select it during the install process. Otherwise, it is not included. Then what you need to do is modify the cygwin.bat file (or create a new one) and have it launch RXVT and bash instead of whatever crap it does by default. That is a simple one liner batch file.<pre class="source-code"><code>C:\Cygwin\bin\rxvt.exe -e /usr/bin/bash --login -i<br /></code></pre><br />The next thing to do is to make it pretty. This is what I have in my .Xdefaults file which should be in your cygwin ~(that's home you linux newbie):<br /><pre class="source-code"><code>Rxvt*geometry: 120x40<br />Rxvt*background: #000020<br />Rxvt*foreground: #ffffbf<br />Rxvt*scrollBar: True<br />Rxvt*scrollBar_right: True<br />Rxvt*font: Lucida Console-12<br />Rxvt*SaveLines: 2000<br />Rxvt*loginShell: True<br />! VIM-like colors<br />Rxvt*color0: #000000<br />Rxvt*color1: #FFFFFF<br />Rxvt*color2: #00A800<br />Rxvt*color3: #FFFF00<br />Rxvt*color4: #6090F8<br />Rxvt*color5: #A800A8<br />Rxvt*color6: #00A8A8<br />Rxvt*color7: #D8D8D8<br />Rxvt*color8: #000000<br />Rxvt*color9: #FFFFFF<br />Rxvt*color10: #00A800<br />Rxvt*color11: #FFFF00<br />Rxvt*color12: #6090F8<br />Rxvt*color13: #A800A8<br />Rxvt*color14: #00A8A8<br />Rxvt*color15: #D8D8D8<br /></code></pre><br />Last, but far from least, is fixing some keys and disabling that hideous beep. That's all part of the file also located at ~/.inputrc. Here is what I use.<pre class="source-code"><code>"\e[3~": delete-char<br /><br /># VT<br />"\e[1~": beginning-of-line<br />"\e[4~": end-of-line<br /><br /># kvt<br />"\e[H": beginning-of-line<br />"\e[F": end-of-line<br /><br /># rxvt and konsole (i.e. the KDE-app...)<br />"\e[7~": beginning-of-line<br />"\e[8~": end-of-line<br /><br /># VT220<br />"\eOH": beginning-of-line<br />"\eOF": end-of-line<br /><br />"\C-v": paste-from-clipboard<br /><br />set meta-flag on<br />set convert-meta off<br />set input-meta on<br />set output-meta on<br />set bell-style visible<br /></code></pre><br />I'm not sure if you need all of those. I've copied this .inputrc file around for a couple years now. The good thing is that it's a standard .inputrc file and you can Google through many many years of how to configure it to your liking. Same goes for the .Xdefaults. <br /><br />The last real thing to fix is the prompt. The default one is not very good. For any Linux user this should be simple but for those in need, try adding this to your .bashrc file, located conveniently at ~/.bashrc:<pre class="source-code"><code>export PS1="\[\e[36;1m\]\u\[\e[32;1m\]:\w > \[\e[0m\]"</code></pre><br />So there you have it. Bash goodness in Windows. Go ahead. Tail that logfile. Pipe it to grep. Use a for loop with find and sed to rename some files. Enjoy the beauty of symlinks (and laugh at junctions while you're at it, what a joke). <br /><br />Please comment if something doesn't work so I can update the post. This is only what I can recall from memory after having done this so many times. I'm thinking about covering X for Part II of the series. SSH + X-forwarding works quite beautifully.<br /><br />Now if only I could get Keynote and Textmate to run in Windows. I'd be in heaven! I need the polyglot OS.Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-62338470890994254292009-10-13T14:59:00.001-05:002009-10-15T19:40:59.096-05:00CLI in web based applicationsI was recently asked to do a prototype for migrating some, well, lets say not very recent user interfaces to a more web based view on them. The first test was to just make sure that a web based application could perform fast enough and we didn't need to go swing. For the record, I'm not a swing fan because of all the layout finagling and I sure don't like GWT doing all my work for me. Call me a purist or an idiot, your call.<br /><br />I check out what the users want and come up with a nice thin app using JQuery on the front end communicating via REST services responding with JSON for the datasets. Pretty standard stuff. Nothing too revolutionary there. If you're not using REST, I'd recommend it but I can get on that soapbox later. What was interesting was the request that these workers prefer to use keyboard shortcuts. In essence, I was asked to make a web based application that didn't use a mouse. Pretty interesting and different than usual.<br /><br />I toss together this prototype and demo it - first suggestion was could I make it so there was just a text box interface where users could type in shortcuts and then use key combinations to drive functionality.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.figuiere.net/hub/blog/200407/vim.jpg"><img style="cursor:pointer; cursor:hand;width: 240px; height: 320px;" src="http://www.figuiere.net/hub/blog/200407/vim.jpg" border="0" alt="" /></a><br /><br />The solution I ended up with uses the hotkeys plugin for jQuery - <a href="http://code.google.com/p/js-hotkeys/"></a> <br />It is crazy easy to use, here is binding the f4 key to execute whatever is typed in the text window:<br /><br /><code><br />$(document).bind('keydown', 'f4', function(){ executeCLI();});<br /><br />function executeCLI()<br />{<br /> var cliString = $("#prs_cli").val().trim();<br /><br /> //Process cliString, call more functions, etc<br />}<br /></code><br /><br />Its crazy simple to bind functions then to key combinations. You can even bind key combinations, i.e. <br /><code><br />$(document).bind('keydown', 'ctrl+c', function(){ executeCopy();});<br /></code><br /><br />Why would anyone do this? At first I asked the same question. The mouse is there, use it. But then I started using the CLI interface for the web. Think about how faster you, the maven, are with CLI? Think about the experienced user being able to interact with web apps this way. Pretty cool and effective stuff.<br /><br />So check out hotkeys and maybe think about some CLIs for your super users of your web apps.Tosihttp://www.blogger.com/profile/07210742577747621243noreply@blogger.com1tag:blogger.com,1999:blog-8068072736664339605.post-51482203946725485762009-10-12T12:58:00.011-05:002009-11-09T22:16:05.371-06:00Cygwin + Interpreters(Jline) + Carriage return = solved!I love cygwin. Not only is having every a bash shell and unix utility on windows awesome(grep, less, tail, awk, cut, pipe, sed, du, df, ls, ln, curl, sort, head, vi, X-Server, etc...) but using rxvt or xterm as a replacement to windows cmd window is awesome.<br /><br />However when I use some command line interpreters such as a groovy shell, maven cli, spring roo, and others, my carriage return doesn't work. When I hit enter, the cursor goes to the next line but the command is not executed. This has been bothering me for months and yesterday I finally found the answer.<br /><br />The core of the problem is with JLine, a command line API that many Java <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.penguinpetes.com/images/Underwoodfive.jpg"><img style="float:right; margin:10px 0 10px 10px;cursor:pointer; cursor:hand;width: 50%; height: 50%;" src="http://www.penguinpetes.com/images/Underwoodfive.jpg" border="0" alt="" /></a>based interpreters use. Jline queries the environment to see what OS you are running and uses that for the expected end of line input. Because the OS is windows but the terminal is xterm, cygwin (rxvt at least) will not send the command Jline is expecting to signal end of line. Therefore, you can't actually execute anything in the interpreter.<br /><br />So after searching for a solution over and over <a href="http://jira.codehaus.org/browse/GROOVY-2584">I finally stumbled upon this issue</a>. Thank god for JIRA! It ultimately led me <a href="http://sourceforge.net/tracker/index.php?func=detail&aid=1822900&group_id=64033&atid=506056">to this Jline defect</a>.<br /><br />So in order to save you a lot of trouble, all you have to do is add the following to your jvm args:<br /><pre style="font-family: Andale Mono, Lucida Console, Monaco, fixed, monospace; color: #000000; background-color: #eee;font-size: 12px;border: 1px dashed #999999;line-height: 14px;padding: 5px; overflow: auto; width: 100%"><code>-Djline.terminal=jline.UnixTerminal<br /></code></pre><br /><br /> If you are doing this for maven CLI, then you need to add the -D argument to your MAVEN_OPTS because Maven will execute the process for you.<br /><br />I didn't need to use the stty commands as recommended but I only fixed my <a href="http://wiki.github.com/mrdon/maven-cli-plugin">maven-cli plugin</a> (which is awesome btw). Maybe someone could explain what the stty commands are for and when or why you'd need them.<br /><br />So hopefully this will save some cygwin users some time and frustration.Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-15090370842362087492009-10-03T21:40:00.003-05:002009-10-05T20:44:43.878-05:00What we do knowTo the contrary of my previous post, I thought I would say what we do know. Without further ado, What we do know (an abbreviated list...well, hopefully)<br /><br /><ul><li>We know that its hard to keep an architecture simple<br /></li><li>We know that if you have a solution or tool in place that has a 'large impact for replacement' - boy oh boy, did you either eff up the use of the tool or did you purchase one sh1tburger of a tool to start with</li><li>We know that if you want your employees / team / co-workers to be engaged and highly productive, you have to allow them to be engaged and highly productive.</li></ul>Perhaps I will dive into this in more detail in future posts.Tosihttp://www.blogger.com/profile/07210742577747621243noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-25378716762472254062009-10-02T21:07:00.005-05:002009-10-05T20:51:28.942-05:00What we don't knowYou know those conversations you have in your head that always come across sounding so awesome? Well, here is the start of one that I had in my head, and a conversation that I want to have but you know, it might not be the best for work....<br /><br />Command-and-control-director: 'You don't know my world. I've worked for 10 years to make my world just right, you can't change it. You don't know the implications of the changes you are suggesting and how it would impact the company.'<br /><br />Me: 'You're absolutely right. I have no ides of the implications. And on top of that, I have no desire to know or even hear the implications.'<br /><br />By no means do I claim that this is an original thought - sometimes it is prior knowledge that blinds us from seeing and understanding other opportunities. Today, for example, my 3-year old daughter wanted to take off her shoes and socks and go stand on some wet rocks in this rock pond at an arboretum. It was 50 degrees out and breezy so I tried to convince her otherwise. But she was persistent and I let her. She loved it, she played in there happily skipping around for 30 minutes.<br /><br />The pond water was heated.<br /><br />I was basing my decision on prior knowledge. It was cold out and breezy, therefore this shallow water will be cold. Did I stick my hand in the water to test it? No, I knew it was cold.<br /><br />The pond was heated.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://downers-grove.il-restaurants.com/downers-grove.il-restaurants.com/images/medium/water-childrens-garden-mort-310x463.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 248px; height: 371px;" src="http://downers-grove.il-restaurants.com/downers-grove.il-restaurants.com/images/medium/water-childrens-garden-mort-310x463.jpg" border="0" alt="" /></a><br /><br />And so we see this in large organizations now. People of high rank that have been around for a long time - they have solved the problems of their world. They have all the experience and the knowledge. When someone challenges them - well, that challenger couldn't possibly understand the cost of such a decision and if they had, they wouldn't be making such outlandish comments. What complicates this situation more is when this type of mentality is tolerated. It leads to a stagnant flow and ultimately to a company unable to change.<br /><br />Change is difficult for anyone, let alone a company or a large company at that. At the Agile 2009 conference this year in Chicago, JB Rainsberger had an amazingly profound session where he talked about his lessons learned in 10 years doing XP. There he talked about the Satir Interaction model. In my best attempt to abbreviate it and not minimize its impact, it is understanding the other persons perception while you are interacting with them. Pretty hard to do, I suggest everyone try it.<br /><br />The example I gave at the start of this post is real. How should one deal with this scenario? Yeah, the way I mentioned sounded awesome in my head. But I'm not convinced it is the best. Perhaps it is the difficulty of having that director's perception, but I really believe that he wants empirical data. Change is hard for him to value because he doesn't have metrics and historic examples in his world that he can call up...and that's fine. That's what he needs, and ultimately you have to believe that he wants to do what is best. But that's what he needs and what he knows. Given that, how should I address the situation? Probably with no response. Keep doing the skunk works, show the value in the change until it is too big to ignore, and then help him think it was his idea.<br /><br />In the theme of this blog set - that man is not a maven. But that shouldn't stop the mavens from progressing along. They just need a better salesperson. And if you can't find that salesperson at your current location, then you find it somewhere else.<br /><br />In summary - sometimes the best thing to know is that you don't want to know. You just might find out the pond is heated.Tosihttp://www.blogger.com/profile/07210742577747621243noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-3029737641329549752009-09-29T14:55:00.018-05:002009-09-30T02:32:41.622-05:00What The Software Maven is all about<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://upload.wikimedia.org/wikipedia/en/7/73/Thetippingpoint.jpg"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 150px; height: 235px;" src="http://upload.wikimedia.org/wikipedia/en/7/73/Thetippingpoint.jpg" border="0" alt="" /></a><br />Are you in a state of <a href="http://en.wikipedia.org/wiki/Weltschmerz">weltschmerz </a>due to dealing with the proponents of accidental complexity that prevent us Software Mavens from enjoying our craft? Welcome home.<br /><br />Here, we use the term Maven as described by <a href="http://en.wikipedia.org/wiki/Malcolm_Gladwell">Malcom Gladwell</a> in <a href="http://www.amazon.com/Tipping-Point-Little-Things-Difference/dp/0316346624">The Tipping Point</a>. Since wikipedia does such an excellent job paraphrasing it I'll quote:<br /><br /><blockquote> Mavens are "information specialists", or "people we rely upon to connect us with new information." They accumulate knowledge, especially about the marketplace, and know how to share it with others. Gladwell cites Mark Alpert as a prototypical Maven who is "almost pathologically helpful", further adding, "he can't help himself". In this vein, Alpert himself concedes, "A Maven is someone who wants to solve other people's problems, generally by solving his own". According to Gladwell, Mavens start "word-of-mouth epidemics" due to their knowledge, social skills, and ability to communicate. As Gladwell states, "Mavens are really information brokers, sharing and trading what they know".<br /></blockquote><br /><br />Unfortunately, as a Software Maven, we rarely get the level of respect deserved. Pathologically helpful? That really only means we fall victim to the sycophants who praise our ideas to benefit from our grunt work. "What a great idea. It just needs my two cents before I reply-all and become a member of this movement." This can be a manager, a shoddy architect or head of the fabulous committee. They will typically want to take the simplicity of your solution, the simplicity you worked so hard to boil the problem down to, and introduce a little overhead, called process, so it's ready for the enterprise. <br /><br />Would you like an auto complete widget with that sir? Super size implied!<br /><br />Us poor Mavens are left in the dust because we've concentrated more on solving the problems than how to market and promote our own ideas. Especially if the idea is too simple. While it should be ideal, the non-Mavens tend to gravitate towards more complex and elaborate ideas because it makes them sound smarter. Kiss K.I.S.S. goodbye! These same people also tend to blindly gravitate toward "proven technology" because it's safe. The pencil is proven technology, but it wasn't safe for the companies that fell behind the computer bandwagon. <br /><br />So with this blog I'm striving to achieve a community of what I'm coining Software Mavens so it can serve as a connector for the people who like us, have a real passion for the field. Because it's not just a job, it's a craft.Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-50168276972724415062009-09-13T19:43:00.019-05:002009-09-30T02:30:54.645-05:00Running tests from a Maven test-jar in your buildSo one of the less frequently used features of Maven is that it allows you to <a href="http://maven.apache.org/guides/mini/guide-attached-tests.html">package and deploy the test classes and resources to the repository</a>. While the documentation suggests it's to reuse the tests, you can only use these as a standard dependency, not to re-execute them.<br /><br />Well I was recently challenged with the task of re-executing the tests. I won't discuss the motivation behind the request as I'm not certain it's worthwhile. For now let's just assume you've been asked to do this too. I'll save you some time and share some of the things I discovered when trying to accomplish this.<br /><br />So obviously we'll need to have the test-jar in the repository (see link above). We'll then need to pull it down and have surefire to execute it. The problem is that surefire does not have a "test jarfile" goal. So we'll need to leverage the unpack goal of the dependency mojo. Here is the xml for that:<br /><br /><pre style="border: 1px dashed rgb(153, 153, 153); padding: 5px; overflow: auto; font-family: Andale Mono,Lucida Console,Monaco,fixed,monospace; color: rgb(0, 0, 0); background-color: rgb(238, 238, 238); font-size: 12px; line-height: 14px; width: 100%;"><code><build><br /><plugins><br />...<br /><plugin><br /><groupid>org.apache.maven.plugins</groupid><br /><artifactid>maven-dependency-plugin</artifactid><br /><executions><br /><execution><br /><id>unpack</id><br /><phase>process-test-classes</phase><br /><goals><br /><goal>unpack</goal><br /></goals><br /><configuration><br /><artifactitems><br /> <artifactitem><br /> <groupid>com.hirn</groupid><br /> <artifactid>projecta</artifactid><br /> <version>1.0-SNAPSHOT</version><br /> <type>test-jar</type><br /> <outputdirectory>${project.build.directory}/additionaltests/projecta/</outputdirectory><br /> </artifactitem><br /></artifactitems><br /></configuration><br /></execution><br /></executions><br /></plugin><br />...<br /><br /></code></pre><br /><br />I'm assuming some basic Maven knowledge here but please comment if you have more questions about how this is configured. There are a couple personal selections worth discussing here.<br /><br />The first is the outputDirectory within the artifactItems section. It may be tempting to unzip into src/test/java so that surefire will just execute the tests as a normal part of the cycle. This isn't good though because you could potentially clobber a test that already exists there. You can't create a separate directory within /src/test/java either because the package names wouldn't be correct anymore. I choose to use ${project.build.directory}/additionalTests/<artifactname> (aka target) so that things get cleaned up naturally. It's also important to unzip each artifactItem into a separate folder to avoid possible namespace collisions.<br /><br />The second is when to execute the goal. Process test resources seemed like a natural selection here, even though it's slightly against purist Maven lingo as the "resources" directory non class files. Another option could be to use the pre-integration-test. Just as long as it's before the phase we configure surefire actually execute the tests.<br /><br />Since we extracted the executable .class files to a separate directory, we need to tell surefire when and what to execute. Here's one example:<br /><br /><br /><pre style="border: 1px dashed rgb(153, 153, 153); padding: 5px; overflow: auto; font-family: Andale Mono,Lucida Console,Monaco,fixed,monospace; color: rgb(0, 0, 0); background-color: rgb(238, 238, 238); font-size: 12px; line-height: 14px; width: 100%;"><code><build><br /><plugins><br />...<br /><plugin><br /><groupId>org.apache.maven.plugins</groupId><br /><artifactId>maven-surefire-plugin</artifactId><br /><executions><br /><execution><br /><id>project-a-tests</id><br /><phase>test</phase><br /><goals><br /> <goal>test</goal><br /></goals><br /><configuration><br /><testClassesDirectory>${project.build.directory}/additionaltests/projecta</testClassesDirectory><br /> <reportsDirectory>${project.build.directory}/surefire-reports/projecta</reportsDirectory><br /></configuration><br /></execution><br /></executions><br /></plugin><br /><br /></code></pre><br /><br />Pretty straightforward. You have to make sure the phase is declared after the phase where the dependency is unpacked and point it to corresponding directory. The other piece to consider is that you don't overwrite the surefire report produced from running the rest of the tests. I couldn't find a way to aggregate the the report but wither or not you want to is personal preference. Would you even want your CI or reporting tool to track the success of executing these tests? Probably not, but you certainly don't want to affect the output of the tests within the projects.<br /><br /><a href="http://www.goodpours.com/files/test-dependencies.zip">You can download an example of this to see it in action</a>. Just `mvn install` projecta and then do the same for projectb. You'll see the test run from projecta all over again.<br /><br />Why I had to do this seemed to be pretty special case. My situation was driven by a peculiar scenario. There was a project A with dependencies A->B->C where A has a defect due to code that lives in C. Rather than create a new B, we just want to touch C and modify A such that A->B,A-C'. <br /><br />One way to look at it is that there's no code change in B so why build it? The alternative is to say why not? Not only is rebuilding cheap (or should be), version numbers are free and it communicates to other projects using B that they need to upgrade to B'. <br /><br />So if you have a good reason for executing tests from a deployed test-jar, I'd like to hear it. The whole time I was doing this it felt unnatural. I've never had to do this in over two years of extensive Maven use. The thing I love about Maven is that if it doesn't work automatically, you probably shouldn't be doing it. If this were truly useful, there would be a surefire:execute-jar goal.Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com6tag:blogger.com,1999:blog-8068072736664339605.post-12819873503654053272009-09-02T07:38:00.008-05:002009-09-02T09:12:09.000-05:00JQuery vs. PrototypeWell thank you Michael for my first comment. <a href="http://blog.thinkrelevance.com/2009/1/12/why-i-still-prefer-prototype-to-jquery">Michael Minella had posted this article</a> in response to a comment I made about telling Prototype I was never coming home after being with JQuery. I thought Glenn made a nice fair argument that Prototype is NOT dead and JQuery isn't such a god send that we should never look at it again.<br /><br />I'm still not coming home.<br /><br />Without going into specific differences between the two (I think there are plenty of articles on that), what I personally enjoyed about JQuery was the almost configuration based approach to instrumenting events on the DOM elements, thus keeping all of the JavaScript in one place. Sure I learned after the fact that you can do it in Prototype too but JQuery kinda prescribes it with the $(document).ready() function. So I thank JQuery for opening my eyes to this style of instrumenting DOM elements.<br /><br />Many people seem to use performance in this debate. I never noticed Prototype to be "slow" <a href="http://mootools.net/slickspeed/">unless benchmarked against JQuery (slickspeed)</a>. But 1ms vs. 6ms? Come on it's the web! Where else do developers get so say to hell with shaving milliseconds? Most of my performance concern is server side where you are saving seconds or preventing a complete meltdown during peak hours. Sure if I were building an ACID compliant DB in JavaScript I might profile my JavaScript it but for making a <div> wiggle, the differnce in imprecivable. So any points about JQuery performance hold little water with me.<br /><br />If performance were the primary concern, I would have prefered Dojo over Prototype. I'm sure Dojo's excellent in its own ways but the syntax always felt more geared towards developers instead of designers . When I'm knee deep in content, I prefer to keep my designer hat on. JQuery and Prototype/Scriptaculous both seem to keep me in my happy place, which is especially necessary for me when doing any front end development.<br /><br />When it comes down to it, the tangible reason I now prefer JQuery was its suggestion that one should instrument elements in the ready() function, which in turn keeps event based function calls out of the HTML. That little trick was enough to make me really enjoy JQuery and I haven’t missed anything that would make me come home. Honestly, I wouldn't mind using either or at this point. They really are pretty similar as far as what you can get done and community support, even though JQuery seems to have the momentum at this stage in the game.<br /><br />So, I’m sorry Prototype. I’ll never forget the awesome times we shared . Should we meet again, don’t be surprised if I pull out some tricks I learned while away.Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-4481663688525342132009-08-21T12:06:00.003-05:002009-09-06T21:02:11.653-05:00Off to vacationNot to <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">disappoint</span> my numerous followers, but I'll be traveling for the next two weeks in South America. So there probably won't be any activity, nor will I be able to return e-mails or respond to comments.<br /><br />Do stay tuned though.Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-52804877492856194212009-08-19T03:40:00.013-05:002009-08-21T12:37:47.422-05:00Neal Ford Keynote - Quite entertaining<a href="http://it-republik.de/jaxenter/news/Neal-Ford-ueber-Software-Aus-der-Vergangenheit-lernen-049702.html">Here's a link to an awesome keynote speech delivered by someone who I'm a big fan of, Neal Ford.</a><br /><br />Relax! It's hosted on this German site so no I'm not trying to give you <span class="blsp-spelling-error" id="SPELLING_ERROR_0">spyware</span>. Then again if your browser can infect your computer because of visiting a site you probably deserve it.<br /><br />I really liked this presentation. A lot of this stuff really hit home with me. The <span class="blsp-spelling-error" id="SPELLING_ERROR_1">O'REALLYS</span> Accidental Complexity book was terrific. I had to hear the term "<span class="blsp-spelling-error" id="SPELLING_ERROR_2">NextGen</span>" all year last year. Blowhard Jamboree? Brilliant. It's just great.<br /><br />I had a stronger than usual dose of the daily <span class="blsp-spelling-error" id="SPELLING_ERROR_3">wtf</span> at work and this presentation actually prevented me from hitting the bottle immediately at 5pm. Perhaps the serenity it was able to grant me could save some other livers... or marriages.<br /><br />Everyone should stop occasionally to ask themselves, WWNFD?Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com0tag:blogger.com,1999:blog-8068072736664339605.post-14047377242870046442009-08-19T00:21:00.014-05:002009-08-19T21:31:41.126-05:00What is this blog for?After many moons of considering it, I done went and set me up a blog. I though about doing something nifty and original, but when it comes to blogging it's really about the content isn't it? Thus the canned blogger site suits my needs well and what an opportunity to rip off some nice design!<br /><br />In my petty amount of time as a software developer I've managed to expose myself to quite the laundry list of languages, libraries, servers, engines, middlewares, theories, methodologies... It's a laundry list of laundry lists.<br /><br />So without further ado... This is my blog, Software Maven. Wikipedia defines maven as:<br /><div style="margin: 4%; font-style: italic;">a trusted expert in a particular field, who seeks to pass knowledge on to others. The word maven comes from the Hebrew, via Yiddish, and means one who understands, based on an accumulation of knowledge.</div>I'm not proclaiming myself as "trusted expert". I don't even trust myself. The accumulation part sure rings true. I love to dive deep into whatever I'm working on and plan to return here to share it with whoever is willing to read.<br /><br />No guarantees on what the actual content will be. As of now integration testing seems to consume most of my non-project time. Specifically I'm talking GreenPepper and Selenium. But who knows? I may just instead talk about how I slept with JQuery and told Prototype I'm never coming home.<br /><br />Thanks for coming. Hope to see you again!Anonymoushttp://www.blogger.com/profile/04826831792509834425noreply@blogger.com2