CITCON Blog Aggregator

ElasticSearch on EC2 in less than 60 seconds

Fri, 17 May 2013 21:24:00 +0000

Curious to see what all the ElasticSearch hubbub is about? Wanna see it in action without a lot of elbow grease? Then look no further, friend – in less than 60 seconds, I’ll show you how to install ElasticSearch on an AWS AMI.

You’ll first need an AWS account along with an SSH key pair. If you don’t already have those two steps done, go ahead and do that. The steps that follow suggest a particular AMI; however, you are free to select the instance type. Micro instance types are free to use; consequently, you can get up and running with ElasticSearch in less than a minute for free.

Now that you’ve got an AWS account and an SSH key pair, go ahead and create a new security group (or edit an existing one). It’s important that the following ports are open:

22 (required for SSH)
80 (ElasticSearch uses HTTP for standard API calls)
9200 (required for ElasticSearch)
9300 (required for ElasticSearch)

Next, fire up a Linux AMI. I, for example, prefer ami-c30360aa (this is Ubuntu Server version 13.04) and I configure the AMI to use the security group that I just covered.

Now, SSH to your newly instantiated AMI. Once on the AMI, you’ll need to install Java. Never fear though, I’ve got you covered. All you need to do is run a handy script via the Ubuntu-Equip project, that I use frequently just for this sorta thing:

installing Java

wget --no-check-certificate https://github.com/aglover/ubuntu-equip/raw/master/equip_java.sh && bash equip_java.sh

You’ll need to accept the license from Oracle. Once that script completes, go ahead and type java -version and you should see Oracle’s JDK (i.e Java version “1.7.0_21”).

Next, download and install ElasticSearch via another nifty Ubuntu-Equip script:

installing elasticsearch

wget --no-check-certificate https://github.com/aglover/ubuntu-equip/raw/master/equip_elasticsearch.sh && bash equip_elasticsearch.sh

This script doesn’t start ElasticSearch for you; thus, go ahead and change directories into the elasticsearch directory and fire it up like so:

starting elasticsearch

~/elasticsearch$ bin/elasticsearch -f

Take a deep breath (but not too deep, as I need you to finish in less than 60 seconds) and find the Public DNS of the AMI you’ve been working on. Go ahead and copy it, then fire up a browser on your local machine and go to http://YOUR_AMI_DNS_NAME.com:9200/_plugin/inquisitor/ (be sure to note the port).

By the way, Inquisitor is a handy web application that lets you query your indexes. It was installed via the Ubuntu-Equip script – this tool is invaluable in figuring out how to properly query your indexes.

And that is it. In less than 60 seconds you’ve got ElasticSearch running in the cloud for you. Want to create a cluster? No problem, just follow these steps again to fire up another ElasticSearch instance and then configure the cluster accordingly.

I’ve not gone over configuring ElasticSearch nor have I showed you how to create ElasticSearch as a service on a Linux instance, but for one minute, what do you expect?

Maintaining Play Framework 2.0.x with Select Backports from 2.1.x

Marc SiegelMarc Siegel — Thu, 16 May 2013 16:03:57 +0000

tl;dr - Our fork of Play 2.0.x with select backports from 2.1.x is available here (pre-built packages here).

Overall, we’ve had a great experience at TIM Group (f/k/a youDevise) developing new applications for the financial world using the Play Framework in Scala. It has allowed us to rapidly iterate new products, without sacrificing virtues such as production-quality performance and test coverage, and allowed us to introduce new and robust approaches to asynchronous programming (Futures and Actors).

However, there has been one sore spot: there have been no official releases in the 2.0.x series since 2.0.4 on 1-Oct-2012.

As is often the case with new, exciting, open-source software, there are a lot of changes between 2.0.x and 2.1.x. In order to migrate a product, for example, one must switch Scala versions and port all JSON serialization to a new interface, among other changes.

We’re planning to make these changes to our apps and libraries over the coming months. In the meantime, we’ve begun to maintain a set of backports of features and fixes that we need:

Fix for #692 Jaxen / maven-cobertura-plugin dependency error
Fix for #470 Deadlock in DEV mode
Fix for #158 GZip all output, not only static files
Fix for #632 Stop plugins in reverse order that they were started
Make WS timeout configurable per request
Update FluentLenium dependency to 0.8.0

In case this set of backports is useful to others, our fork is available here, with pre-built binary packages on an orphan branch here.

Conference appearances, 2013

Julian SimpsonJulian Simpson — Tue, 14 May 2013 05:27:33 +0000

My blogging break has been so long, I feel like a vampire emerging from the grave in a Hammer Horror film.

I’m interrupting my relentless working day to announce that I’ll be at:

ASWEC 2013 – I’ll be presenting the Neo4j Tutorial on the 4th of June
Agile Australia – I’ll be doing a talk that mixes up Cloud, PaaS, Devops and NoSQL. Bingo!
I’ve proposed a talk for DevOps Down Under in July
I’ll also be at Graph Connect San Francisco

Back to flogging Ruby code.

Conference appearances, 2013 is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Hold your horses! It's still only a two horse race.

Thu, 09 May 2013 16:49:00 +0000

There has been a lot of excitement in recent months regarding a few new entrants to the mobile operating systems arena including Firefox OS, Tizen, and Ubuntu Touch. These relatively nascent projects, which are all built on top of a Linux kernel, appear to have fully embraced HTML 5 apps; indeed, HTML 5 apps on these operating systems are first class citizens that can run without a browser. Moreover, the ubiquity of HTML 5 means the same app can run on all 3 of these operating systems plus Android and iOS!

What’s also exciting is that there are some major players behind these projects – Mozilla is, of course behind Firefox OS, Canonical is behind Ubuntu Touch, and quite a few large players are behind Tizen, including Samsung. Firefox OS even appears to be courting carriers with an opportunity to run their own app stores. This app store opportunity naturally has carriers foaming at the mouth to re-assert some semblance of control: behold the Verizon app store! All apps are $0.99 and we’ll just bill you at the end of the month (like we used to do for all those ringtones you were accustomed to download back when we were in control of all things device-related before Apple destroyed that cash cow).

Naturally, we’re all eager to see how these new entrants fair. It reminds me of how interested I was in learning more about Windows Phone 8 and even Blackberry’s latest and greatest attempt at regaining some composure.

But then I remember this stunning fact: Apple and Google

together control nearly 9 out of 10 smartphones sold globally.
Tomi Ahonen Can These Competitors Break Apple and Google’s Stranglehold on the Mobile OS?

Even with industry heavyweight contenders (who are not new to mobile!) like Microsoft and Blackberry (who, we all should remember, owned the smartphone market before Apple got involved) haven’t really made a dent. Granted, it’s early to rush to conclusions, however, preliminary signs don’t bode well for either company.

The co-CEO of Samsung had some stinging criticism for Microsoft:

Smartphones and tablets based on Microsoft’s Windows operating system aren’t selling very well. There is a preference in the market for Android. In Europe, we’re also seeing lackluster demand for Windows-based products.
JK Shin New Samsung CEO Says There Is ‘Lackluster Demand’ for Windows Tablets and Phones

Blackberry appears to have some demand in the UK and Canada, a recently analyst T. Michael Walkley had this to say:

While we anticipate stronger near-term results for BlackBerry as higher margin BB10 smartphones sell into the channel, we do not believe BlackBerry can achieve sell-through market share levels to return to sustained profit levels
T. Michael Walkley BlackBerry Sales Forecast Cut Despite Strong Demand for Q10

The salient point, nevertheless, is that neither Microsoft or Blackberry have yet to make a dent into the Google-Apple duopoly. And so while it’s easy to get excited about new entrants like Ubuntu Touch, the reality, at least for the time being, is that these operating systems will have little impact in the smartphone market.

After all, when your competition essentially owns 9 out of every 10 smartphones, evolutionary enhancements aren’t enough to break that stranglehold: you have to do something revolutionary. Besides, we’ve already seen this before: the iPhone was not an evolutionary offshoot of the Blackberry. It was revolutionary. Sadly, neither Ubuntu Touch, Tizen, nor Firefox OS appear revolutionary.

Two ways to react

Matt — Thu, 09 May 2013 11:37:45 +0000

Every organisation that makes software, makes mistakes. Sometimes, despite everybody’s best efforts, you end up releasing a bug into production. Customers are confused and angry; stakeholders are panicking.

Despite the pressure, you knuckle down and fix the bug.

Now it gets interesting: you have to deploy your fix to production. Depending on how your organisation works, this could take anywhere between a couple of minutes and a couple of weeks. You might simply run a single command, or you might spend hours shuffling emails around between different managers trying to get your change signed off. Meanwhile, your customers are still confused and angry. Perhaps they’ve started leaving you for your competitors. Perhaps you feel like leaving your job.

With the bug fixed, you sit down and try to learn some lessons. What can you do to avoid this from happening again?

There are two very different ways you can react to this kind of incident. The choice you make speaks volumes about your organisation.

Make it harder to make mistakes

A typical response to this kind of incident is to go on the defensive. Add more testing phases, hire more testers. Introduce mandatory code review into the development cycle. Add more bureaucracy to the release cycle, to make sure nobody could ever release buggy code into production again.

This is a reaction driven by fear.

Make it easier to fix mistakes

The alternative is to accept the reality. People will always make mistakes, and mistakes will sometimes slip through. From that perspective, it’s clear that what matters is to make it easier to fix your mistakes. This means cutting down on bureaucracy, and trusting developers to have access to their production environments. It means investing in test automation, to allow code to be tested quickly, and building continuous delivery pipelines to make releases happen at the push of a button.

This is a reaction driven by courage.

I know which kind of organisation I’d like to work for.

The Rails, CloudFront, and Heroku performance hat-trick

Wed, 01 May 2013 13:10:00 +0000

Amazon CloudFront is a pay-as-you-go global content delivery network (or CDN) that provides high availability and high performance serving of static assets. Basically, it means users have to wait less time to view your web app regardless of their location on the globe.

It’s easy to configure a Rails app to take advantage of CloudFront; what’s more, if your Rails app is hosted on Heroku, there’s a nifty gem, dubbed heroku-deflater, that’ll enable HTTP compression of static assets (other than images).

To get these three entities to play nicely together requires a few simple steps. Let me show you how.

First, if you want to enable HTTP gzip compression of static assets other than images from a Heroku app, then add the heroku-deflater gem to your Gemfile. This gem doesn’t compress images as in some cases, zipping images creates bigger ones!

Once you’ve run bundle install and deployed your app to Heroku, fire up a terminal and run [cURL](http://thediscoblog.com/blog/2013/04/18/curling-for-wget/) to verify that the HTTP response Content-Encoding is gzip like so:

cURL testing gzip response

curl -i -H "Accept-Encoding: gzip,deflate" http://your.awesome.web.app

You should see in the response this key phrase:

cURL response

Content-Encoding: gzip

If you do see the Content-Encoding set to gzip, then you are good to go. If, for some reason, you don’t see it, check your environment’s configuration file (which you will have to edit to get CloudFront working anyway) and verify that the property config.serve_static_assets is set to true.

Next, sign into the AWS Management Console and enable CloudFront if you haven’t already. From the CloudFront admin page, create a new distribution via the Create Distribution button on the top left.

Once the create distribution wizard begins, be sure to select Download as your delivery method.

In the next screen, there are some important fields you’ll need to fill out, namely: the Origin Source Name and the Viewer Protocol Policy. For the Origin Source Name, you will need to put in your app’s URL or the Heroku URL (if you do not map a custom domain name to it). If you web site supports HTTPS, then be sure to set the Viewer Protocol Policy to HTTP and HTTPS.

The only other important setting after these two is the Price Class. It’s here where you can set where CloudFront will essentially serve up your content – the default setting of Use All Edge Locations is most likely what you need.

Finally, click the Create Distribution button – once you do that, it’ll take a bit for things to initialize (basically, the CDN needs to get built and this may take up to 30 minutes).

Now to configure your Rails app, you’ll need to open up your target environment’s configuration file (i.e. production.rb). The two fields you’ll want to be sure are properly set are serve_static_assets and static_cache_control. In particular, you are setting the cache control variable to one year. This means that once a static asset, like a JavaScript file is downloaded to the browser, it’ll be cached for one year. Don’t fret, however, if you think that’ll inhibit change – the file that is ultimately downloaded has a hash attached to it (via the magic of Rail’s Asset Pipeline). Consequently, the file that is cached is something like your_js_file-asdf098203820980a980 where that last bit is a hash value that’ll change if the file itself changes.

production.rb edited to support CDN

config.serve_static_assets = true
config.static_cache_control = 'public, max-age=31536000'

The last change you need to make to your environment file is to set the asset_host to the CloudFront domain that you just created. You can find this in your AWS Management Console – it’ll be a cryptic URL like http://asdjlkj2321.cloudfront.net.

production.rb edited to support asset host

config.action_controller.asset_host = 'the domain name from AWS Dashboard'

Commit your changes and deploy your app.

To verify things are kosher, you’ll need to give it some time (check the status of your CloudFront CDN – if it’s status is Enabled then you are good to go!). If things are ready, then fire up a browser and go to your app.

In this case, I’m using Chrome. Go to JavaScript console and hit the Network tab.

Surf around and you’ll note a few things – one, that the assets like images and JavaScript files are being severed up from your CDN (just look at the URL) and that the size will often say “(from cache)” – that means the CDN is handling the load rather than Heroku. You should also note that your web app is probably a bit more snappy!

Check out your Heroku logs and you’ll note fewer hits in this case – dynamic pages are still being loaded, however, static assets are not anymore – that’s the job of your CDN!

CloudFront isn’t free; nevertheless, I think you’ll find the corresponding cost quite reasonable. Pricing will vary depending on how much content you’ll be serving up with CloudFront – this is a function of how many visitors you have along with how many static assets that are ultimately downloaded to a user’s browser. For instance, 500GB of average content will cost you less than $75/month.

CloudFront’s pay-as-you-go model makes it extremely affordable to add a nice bit of pep to your app’s performance along with using gzip compression and HTTP caching. And hopefully as I’ve shown you, it’s rather easy to do with a Rails app running on Heroku.

Kanban in Practice

Miles — Mon, 29 Apr 2013 09:48:00 +0000

In this posting I talk about my experience using Kanban, why it worked and what is required to make the use of Kanban successful in software development companies. A few things motivated me to write this long overdue posting (sorry @amazonv), specifically a discussion that I had at a recent Meetup group and also that we are thinking about adopting Kanban at DealerOn.

This experience goes back to my tenure at Apprenda, where we had successfully adopted and utilized classic Agile development practices. We adhered to a two week iteration cycle, and produced fully tested, releasable packages every iteration though we didn't necessarily release every package to the public. While at Apprenda I served as the Test / Release Manager and so some thoughts are from that perspective as well.

Why we tried Kanban

I first heard about Kanban at a conference, and around the same time my colleagues Bryan and Dan begun to advocate for it, and finally we gave it a try at the beginning of a major release cycle. There were a couple of reasons why we liked Kanban even though nothing was really "broken" with the Agile cycle:

Too much work tracking metrics for too little benefit
The two week cycle was jarring, providing an inconsistent workload throughout the cycle

With Agile we spent a lot of time tracking velocity and attempting to produce accurate and reliable forecasts for the business. We never were particularly good at producing forecasts for the business owner despite all of the time spent trying to do so, but no one noticed anyway because the forecasts were disregarded since we were a startup and change our mind all the time. We ended up manipulating the numbers to make ourselves look productive, and it worked fine for the most part. But one thing was always true: no matter what the velocity, we'd work on the highest priority items and try to release it as soon as possible. The forecasts, quite frankly, were not that useful for any sort of long term planning.

In Kanban, everyone works on the next highest priority item as determined by the business. When the release date comes, the highest priority items that could successfully be completed by the team during the release cycle are done. In otherwords the business got what the team was capable of producing at the time.

Another issue we had with our classic Agile approach was due to our strict two week iteration cycle. This was rather jarring for the team. The burden was on development at the beginning of the iteration, and it transfered to the testing team near the end of the cycle. I can remember basically blocking every other Wednesday and Thursday evening to stay late to "test stuff" and rush for basically what amounts to be a false-deadline since we would not actually release every Friday.

In Kanban, the cycle goes away. The work load is evenly distributed all throughout because there is no start and finish officially defined. There are work limiters for each phase which help prevent the sub-teams from being overburdened.

What about the ceremonies?

Rather than have one of the many "agile ceremonies" for the sake of having it on a schedule, you have them when you need them. If you have a cool new feature to show, schedule a showcase. If you need to plan out a feature implementation, gather the team and conduct a planning meeting. The benefit is the meetings are shorter and more focused. Gone are the 5-minute showcases with nothing but a half-finished feature and bug fixes.

What enables Kanban to work?

A major risk to a Kanban team is producing unstable software. Since there is no end to an iteration where the software is tested and stabilized, this has to be enforced in a different way. As a part of the adoption of Kanban at Apprenda, we implemented a policy of requiring a 100% stable trunk. Features were tested and stablized on independent branches (we used Mecurial as a DVCS) and we made the appropriate investment in our testing infrastructure to be able to automatically deploy and run regression tests on all feature branches. This was no small effort, but was absolutely necessary to keep quality high and make Kanban work for us.

Another key to enable Kanban is discipline. While it is easy to pan the agile ceremonies as artificial and wasteful in a Kanban setting it is necessary to conduct each of the meetings when it is appropriate to do so. Planning meetings are important to ellicit a full understanding of the requirements and get feedback from the business before setting out on a work assignment. The daily standup meeting is important to "walk the board" and make sure all development and testing is progressing. The retrospective is still important to the team's self-improvement. You'll find yourself having less meetings overall but if you are suddenly having no meetings after introducing Kanban that is a problem.

The final item that is important to Kanban's success is adhearing to work limiters. This forces the team to confront bottlenecks. For example, at one point the testing team had a bit too much on its plate and the development team as a result made improvements to the testing framework and infrastructure that typically would be done by the testing team. At the same time, members of the testing team assist development with advanced debugging, bug fixes, and other development that typically is done by the development team when they reached their work limit.

In this posting I talked a little bit about how Kanban contrasts with Agile and some of the items that I feel make Kanban work well for software companies. If you have any feedback or questions please feel free to comment or contact me!

Musings over lunch

Lisa CrispinLisa Crispin — Fri, 26 Apr 2013 19:30:46 +0000

Spring is finally here in Colorado. We had a decent snowstorm on Tuesday, with temperatures well below 20 degrees F, but today it is sunny and shirtsleeve weather. I’m eating my lunch at my desk, but I’m going to go out and enjoy a walk along the Platte River in a few minutes.

I’ve had little time to write lately. I traveled a lot the first quarter of 2013, with a Hawaiian vacation, Belgium Testing Days, and a trip to England for TestBash 2.0 and some advanced agile testing workshops in Cambridge.

Dreyfus Model of Skill Acquisition applied to evolving the Whole Team

This month I was lucky enough to be able to stay home for a great conference, Mile High Agile 2013. Here is a picture of the presentation that Matt Barcomb and I did on applying the Dreyfus Model to evolving the Whole Team – Matt wrote and drew the “slides” on the wall as we explained it! (And here are actual slides which are more readable if you weren’t there)

At the same time, we’re doing lots of home improvement projects, and when the weather’s nice enough, working the donkeys or going on walks with them.

And there’s my new job. In August, I joined Pivotal Labs to work on the Pivotal Tracker team. I’m on a “dream team” of testers including Marlena Compton and Jo Webb, we do support and testing along with the rest of our awesome development team. Elisabeth Hendrickson also recently joined Pivotal, though she works in a different area, doing magic with the cloud. Someone recently commented to me that we have a “Justice League” of testers here at Pivotal, and it is such a thrill to be part of that!

Though I was excited to get to work on the Tracker team, my first couple months were quite difficult for me. That’s just due to me and my ego, not my wonderful and helpful teammates. In the past, when I joined a new team, I always felt I brought something to the party. I had experience with agile and testing that the team lacked, so even without knowing the domain, I could contribute value right away. But the Tracker team already had agile and testing pretty much nailed. I hadn’t worked on a Rails project before, I hadn’t worked with Tracker before, I had so much to learn! And learning is fun, but I missed that end-of-day satisfaction of having contributed my share. I also worried that I’d never get up to speed, that I would fail.
Fortunately, lots of pairing helped me learn enough to start feeling like a worthwhile member of such a great team. My ping pong skills also helped. As with any job, there are still difficult days, but I look forward to coming to work every day.

All this learning, plus lots of personal life changes (e.g., moving to a horse property, losing my dad), took up all my time and mental bandwidth, and my writing output slowed to a trickle. However, I’m starting to slowly turn that around.

Having worked on a lot of distributed teams, that’s always a favorite topic of mine, and I recently wrote articles related to that for both SearchSoftwareQuality and Methods and Tools. In addition, Janet Gregory and I started working on our new book, with the working title More Agile Testing. I still haven’t found my writing groove. My longer commute means a lot of time away from home, and taking care of donkeys at home, though one of my favorite activities, does eat up the clock! But I’m livin’ the dream, and with enough practice, discipline and help from family and friends, I’ll find time to keep sharing my agile testing experiences and those of my team.

Happy spring!

The post Musings over lunch appeared first on Agile Testing with Lisa Crispin.

Mobile for the masses: gestures and test deployments

Thu, 25 Apr 2013 01:13:00 +0000

My second article in IBM developerWorks’ series Mobile for the Masses is out! This article covers how to go about designing a mobile interface from the standpoint of usability via gestures. In essence, eschew buttons and prefer the swipe! What’s more, I cover at a high level how to test your app on an Android device.

As the article summary states:

Mobile users are typically distracted, busy, and ergonomically constrained, so build your mobile application UIs accordingly. Andrew Glover discusses key factors that differentiate mobile apps from web apps, then guides you through the creation of a mobile application UI that uses swipe gestures for navigation rather than button clicks.
IBM DeveloperWorks Mobile for the Masses: Take a Swipe at It! Programming Gestures in Android

So what are you waiting for? Check out ”Mobile for the masses: Take a swipe at it! Programming gestures in Android” and trade buttons for swipes in your Android mobile apps! And if you missed the first article, check out ”Mobile for the masses: A gentle introduction to Android” and learn the ins and outs of Android development!

Stay tuned for more articles in this series and don’t forget to watch for mobile focused articles on this blog as well.

Cucumber 1.3.1 released

Matt — Mon, 22 Apr 2013 12:31:27 +0000

Over the weekend we released Cucumber version 1.3.0. This was quickly replaced by 1.3.1 when we realised there was a bug 1.3.0 that only appeared on Windows.

Along with masses of bugfixes, this release contains the early stages of some serious internal refactoring work planned for release in version 2.0. Although our tests continue to pass, it may be that we’ve changed untested behaviour so that’s why we’ve bumped the minor release number. We’re already aware of one minor bug that’s been introduced[1]. Please let us know if you find any other issues.

New Features

Faster features, thanks to in-process Aruba. (Aslak Hellesøy)
Add lib to default load path (#162 Steve Tooke)
Add snippet type to support different type of ruby snippets. (#390 Roel van Dijk)
Call nested steps using any language keywords (#433 Tomohiko Himura)

Bugfixes

Update WATIR example (#427) Luiz Guilherme D’Abruzzo Pereira
Ensure that cucumber.yml is only parsed once (#416) Steve Tooke
Improve rake task report on failure (#400 Andrey Vakarev
Show details of nested steps in backtraces (#69) Steve Tooke
Filter out control characters from CDATA section of JUnit formatter output. (#383 @teacup-on-rockingchair)
Fix problem with non-ascii characters in file path (#150 Oleg Sukhodolsky)
Fix problem loading ruby files in project root directory (#269 Steve Tooke)
Fix JsonPretty formatter problem (#197 Oleg Sukhodolsky)
Don’t display multi-line strings when –no-multiline is passed (#201 David Kowis)
Moved the profile information output to a callback of the formatter (#175 David Kowis)
Fix html formatter to not mark skipped/unimplemented steps as failed (#337 Oleg Sukhodolsky)
Allow duplication for format+output pair in command line (#434 David Lantos)
Better delegation to IO in Cucumber::Formatter::Interceptor::Pipe (#312 Oleg Sukhodolsky)

[1] https://github.com/cucumber/cucumber/issues/438

How to Enrich ScalaQuery with Nested Sessions and Transactions

Marc SiegelMarc Siegel — Fri, 19 Apr 2013 14:09:26 +0000

Recently, we wrote an integration test in a Play Framework application using ScalaQuery which failed in a way that surprised us: we had misunderstood the library’s interface for database sessions and transactions.

It turns out that nested usage of #withSession / #withTransaction are not supported by ScalaQuery 0.10.0-M1 out of the box. Instead, a new session and transaction are created in each nested scope. This causes data write/read inconsistencies (due to separate sessions), and failures of transactional rollback (due to separate active transactions in the nested sessions).

Rather than maintain a fork of ScalaQuery, we used the Scala “enrich my library“ pattern to add support for the nested usage in an external library. For examples and usage details, check out the scalaquery_nested github project.

For example:

database.withNestedSession {
  // add object to database here
  database.withNestedSession {
    // query same object back from database here
    // great! same connection used, so expected object is returned
  }
}

A coding dojo story

Matt — Fri, 19 Apr 2013 08:42:19 +0000

It was 2008, and I was at the CITCON conference in Amsterdam. I’d only started going to conferences that year, and was feeling as intimidated as I was inspired by the depth of experience in the people I was meeting. It seemed like everyone at CITCON had written a book, their own mocking framework, or both.

I found myself in a session on refactoring legacy code. The session used a format that was new to me, and to most of the people in the room: a coding dojo.

Our objective, I think, was to take some very ugly, coupled code, add tests to it, and then refactor it into a better design. We had a room full of experts in TDD, refactoring, and code design. What could possibly go wrong?

One thing I learned in that session is the importance of the “no heckling on red” rule. I watched as Experienced Agile Consultant after Experienced Agile Consultant cracked under the pressure of criticism from the baying crowd of Other Experienced Agile Consultants. With so many egos in the room, everyone had an opinion about the right way to approach the problem, and nobody was shy of sharing his opinion. It was chaos!

We got almost nowhere. As each pair switched, the code lurched back and forth between different ideas for the direction it should take. When my turn came around, I tried to shut out the noise from the room, control my quivering fingers, and focus on what my pair was saying. We worked in small steps, inching towards a goal that was being ridiculed by the crowd as we worked.

The experience taught me how much coding dojo is about collaboration. The rules about when to critique code and when to stay quiet help to keep a coding dojo fun and satisfying, but they teach you bigger lessons about working with each other day to day.

Sonar in the news

Olivier GaudinOlivier Gaudin — Thu, 11 Apr 2013 08:55:09 +0000

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Code Quality Tools Review for 2013: Sonar, Findbugs, PMD and Checkstyle
By Adam Koblentz, 12 March 2013
When we released our Developer Productivity Report last year, it was the first time we asked our respondents about Code Quality Tools. Code quality tools fulfill a growing need, as our code bases become larger and more complex, and it’s important to try to automate your code checks as much as possible. They are pretty versatile and customizable, and typically they are integrated into your build process, but can also be run manually in a one-off fashion.

Dependency Inversion Principle
By Monte Wingle, 13 March 2013
This 20 minute video demo shows: How to install and start Sonar, A very simple java project with no dependency cycles, What creates a red mark (dependency cycle) on the Design page, A Sonar analysis showing the cycle, How to fix that red mark using the Dependency Inversion Principle, A final Sonar analysis showing a clean design page again with the functionality unchanged.

Install Sonar – Oracle Loopback Adapter
By Jean-Pierre Fayolle, 10 March 2013
We will discuss in this post how to install a Loopback Adapter needed to use Oracle on a standalone station, such as a laptop for example. The first thing to do is to check if you already have one on your machine.

Analyze a Web Dynpro Java project with Sonar
By Tobias Hofmann, 21 March 2013
Sonar offers two “basic” profiles to analyze a project. Sonar uses Findbugs to analyze not only the source code, but the binary version for violations and possible bugs too. “Sonar way” is looking at the source code. This allows for finding the most common violations with minimum effort. “Sonar way with Findbugs” also takes the CLASS files into consideration.

Install Sonar – Oracle user
By Jean-Pierre Fayolle, 25 March 2013
Today we will use this console to create an Oracle User that will allow us to have a SONAR schema in our database. If you did not keep the url of the Oracle console, no problem. You should have a Windows menu that allows to launch it. Note that you have as many consoles as databases installed, and a corresponding Windows service. We shall see at the end of this article how to disable it.

Painless Android swipe detection

Sun, 07 Apr 2013 14:37:00 +0000

Why bother building navigation buttons in an Android app when you can easily capture finger swipes? But, if you’ve ever implemented gesture section in Android there’s the drudgery of implementing listeners and you also need to do some elementary Cartesian math. Save yourself the boilerplate bother mathematics and use a library!

Gesticulate makes it painless to detect straightforward swiping motions like up, down, left, and right. It’s a simple jar file you include in your Android libs directory. Throw Gesticulate’s SwipeDetector inside an instance of Android’s SimpleOnGestureListener, for example, and you’re detecting swipes with ease!

Gesticulate is used in Savvy Words, a flash card vocabulary app found on Google Play and Amazon’s Appstore for Android. See the Github project for more details such as code examples for how to use Gesticulate, how to build it, and to see Gesticulate’s tests. Swipe on, baby!

Learning by doing

tamasrevtamasrev — Wed, 03 Apr 2013 08:16:09 +0000

Learning by doing

This one came to me through a Scala course.

My uncle* suggested me to learn Scala because functional programming is the future of software development. Two years ago read a book about it and also learned FP in uni - I replied. I was humble enough to tell him: very likely I already forgot most of it.

So I started to take this course. It turned out, I did forgot a lot. There are some things that became clear to me during the exercises. E.g. now I really know how to write tail recursion.

Learning by doing is fucking effective, I concluded.

Learning

There are many ways of learning:

Books

You can learn by reading books
You can learn by listening to / copying others
You can learn by doing, e.g.: experimenting on things and reflecting on your results.

In the beginning of ones carrier it’s useful to copy others, like going through tutorials. It’s also useful to read books so you can learn what others discovered by doing things. This sort of things can prevent you from reinventing the wheel.

Chariot wheel

What do you mean by “learning” ?

OK, but what is learning? Memorizing a new API, e.g. finding out how to use FEST is learning of lexical knowledge. Practicing TDD is learning of tacit knowledge. On the other hand, figuring out how to track session in whatever web framework is not learning: it’s just hacking.

From these options, gathering tacit knowledge is the most important thing a developer could do. Good guess: you can gain tacit knowledge by doing things and reflecting on how those things worked out.

When do we learn

Cool! I want to learn things! When do I do that?

Uncle Bob suggests in his Clean Coder book that a professional developer spends 40 hours a week with working for the employer and another spends another 20 hours with making ourselves better developers. He suggests to read tweets during lunch, go to coderetreats, work with side projects, etc. In other words, he suggests to spend our spare time on learning. I think we have other options too:

We can learn when otherwise we would sleep
We can learn when otherwise we would spend time with our special one / kids / pets
We can learn when we would do other things like go to the theater, do sports, etc.
We can learn when we do our day job

I know officially (in a taylorist point of view) we should learn when we do not do our day jobs. It also means that when we learn then we deprive our family from ourselves. From this point of view when we learn things during our day job we rob our employers: we spend the precious man-hours on ourselves.

I disagree with this approach. Although we should learn in our spare time too, the most precious learning happens when we reflect on our day-to-day practices and change them when needed. This is what could make us more efficient. This is exactly why we practice TDD, read stuff and go to conferences. This is also the thing that makes us love our jobs and makes possible to spend time with our families.

Tenses

Before we would go on I’d like to introduce a concept. Psychologists say that a person can subjectively live his/her life in 3 tenses:

In the past, grieving for things that are gone
In the future, worrying to get there on time / in the right shape
In the present – which is the key to happiness. Some call this state of mind flow.

We can apply this approach to software development too: When we deal with buggy, dirty, untested legacy code we deal with the past. When we add new features we are in the present. When we estimate or when we redesign old stuff we are in the future.

The fine line

I believe most of you had a conversation about a trade-off between speed of development and code quality. As most of the developers learn there is no such trade-off. We should write the best quality code we can. On the other hand there is a trade-off on how much time we spend on finding better solutions on reoccurring problems.

In this metaphor living in the present is the crunch mode. Flow comes to you when you find the fine line between getting things done and uncovering better ways of doing things.

* This is the website of my uncle. He isn’t as influential on software development as Uncle Bob is. However, he is a successful researcher, a great mind and I’m very fond of him. He also agrees with Uncle Bob on the importance of functional programming.