LSCC Talks 2014 “Crafting DevOps: Applying software craftsmanship to DevOps”

I once again had the pleasure of presenting a lightning talk at the London Software Craftsmanship Community #LSCCtalks series. This time I presented a new talk I’m working on – “Crafting DevOps: Applying software craftsmanship to DevOps”.

The presentation (hopefully) does what it says on the tin, in that I talk about the ideas of applying software craftsmanship principles to DevOps . If the DevOps mantra of “Infrastructure as Code” is true (which I think it is), then I believe it makes sense to learn from the craftsmanship community – in particular TDD, BDD and continuous integration.

This is very much a work-in-progress talk, and I hope to develop it more over the coming weeks and months (please do send me your feedback!).

 

LSCC 2014 “Crafting DevOps: Applying Software Craftsmanship to DevOps” from Daniel Bryant

Thanks again to Sandro and Samir from the LSCC for inviting me to talk, and as usual, if you have any questions, then please do get in touch. In particular please do let me know if you would like to see more on this topic.

 

Advertisement

LJCConf “Chuck Norris Doesn’t Need DevOps” Slides

The LJC ran it’s ever-popular annual Open Conference on Saturday 23rd November, and this was the first time I’ve made it along. To say I was impressed was an understatement, and I’ll try and capture some more thoughts in a later blog post, but for the moment I wanted to share the slides from the main presentation I delivered “Chuck Norris Doesn’t Need DevOps”

 

Can’t see the presentation slides? Please click here http://www.slideshare.net/dbryant_uk/2013-ljcconf-chuck-norris-doesnt-need-devops

The original pitch for the talk was as follows:

“We all hear the term “DevOps” being thrown around on a daily basis, but what does it actually mean? With a little help from everyone’s favourite 80’s action hero, we’ll undergo a whistle-stop tour of the philosophy, culture and tooling behind this buzzword, specifically aimed at Java Developers.

We’ll also look at a real-world case study from Instant Access Technologies Ltd, and explore the key role that DevOps has played during a successful upgrade of the epoints customer loyalty platform to support increasing traffic. The core discussion will focus on the challenges encountered as we moved from a monolithic app deployed into a data centre on a ‘big bang’ schedule, to a platform of loosely-coupled components, all being continuously deployed into the Cloud.”

Thanks to everyone who attended my presentation! The feedback was most welcome, and the questions were great. If anyone wants to add anything further than please feel free to comment, email or tweet at me!

JAX London Review – Part One

This was the first year I’ve attended the JAX London conference, and I must say I was impressed. The conference struck a nice balance between discussing the latest technologies in the Java space and also the ‘soft skills’ side of what we do as developers, which includes use cases and lessons learned from everyday life as a developer

Day One
Unfortunately the combination of the UK ‘Super’ Storm and South West Trains approach to business meant that I couldn’t make the first day of the conference, which was included a series of tutorials. This was a real shame, as I had been eagerly anticipating listening to Thoughtwork’s Neal Ford talking about Continuous Delivery. Thanks to Neal’s website I managed to get hold of the slides, but I’m still gutted that I couldn’t attend.

Day Two
With the Storm well and truly behind us the conference got into full swing. @monkchips provided the opening keynote “How Java got its mojo back”, which I thought was a great start to the conference. Key takeaways:

• Java is still very much alive a kicking, even with all of the competition of other languages
• Java may not be ‘cool’, but thanks to the JVM, the execution scales very well
• Twitter et al have moved from cool technologies (Ruby on Rails) to not-so-cool JVM-based technologies (Scala + Java) in order to meet the massive scalability demands
• Java may be missing a killer web-app framework (and who can deny the JSF approach is a little clumsy), and this may hinder the hipsters from adopting the Java ecosystem
• The Java development ecosystem shows the full range of governance available within our industry, from dictatorship (OSGI) to direct democracy (Apache). I thought this was a fun fact!
• NoSQL is rapidly becoming the de facto datastore of choice – is HDFS the new relational database?
• It’s now more difficult to sell software, and instead the focus is moving towards selling services and data
• Java is the architects choice, the engineers choice, but is it the developers choice?

As @monkchips himself noted, it was a slightly tough audience, and I’m not sure why. Maybe the combination of the previous day’s storm and an early start had set everyone up badly?

Next up with @mashooq talking about “TDD at Scale”. This was an excellent talk, and there were plenty of great points made:

• Doing TDD does not guarantee that good design will emerge from the codebase
• …this is further exaggerated by the fact that good a TDD lifecycle should include “Red, Green, Refactor”, but it’s all too tempting to just go “Red, Green, Red, Green…” Unfortunately I’ve been there and done that…
• It may be easy to split an application into components, but unless a component maps to a real business process, then it will be difficult to create real meaningful acceptance tests around this. This can lead to overly fragile tests, which simply test technical functionality.
• Avoid the test fixture ‘God’ Class anti-patten at all costs. This is created with good intentions to manage test fixtures, but soon grows out of control…
• …instead you could/should invest in creating a DSL to create test fixtures
• Classify tests into Unit, Integration and Component/Acceptance, as this allow some flexibility to choose when expensive/slowest tests are run
• Regularly email the team with the 10 slowest tests. Often the slowness is due to a simple design flaw in the test. Name and shame the perpetrators until they fix the tests 🙂
• Parallelise test execution (where possible)
• System tests are very valuable, and so don’t forget them. If implemented correctly then this truly can become ‘living documentation’
• Lisa Crispin’s ‘Agile Testing Quadrants’ provide an invaluable insight to the range and value of testing that is available in any software development project. This was a great nugget of wisdom!
• The foundations to successful software development are design, code quality, TDD and constant critique

For the third session I attended one of the Big Data Con talks about the ‘Lambda Architecture’. If you haven’t read about this architectural pattern then it’s worth doing some research, as I’m increasingly seeing this adopted by many of the Big Data shops. Although interesting, I didn’t particularly take away lots to share from this, and so I’ll skip notes here.

The fourth session I chose was an explanation (and demo) of the Apache Drill project, which is an open source clone of the much discussed Google Dremel project. The talk was more of a introduction to the project, and so I don’t have lots of notes to share here either. I would recommend having a quick read about Dremel, and also watching a few of the related videos floating around the interweb, as when completed I expect the Apache Drill project to create quite a stir in how we query Big Data sources.

For the fifth and final session of day one I attended @sandromacusso‘s talk on ‘Why other people don’t get it’, focussing on how to create a great development team, how to handle situations where ‘they’ (management) just don’t get it, and also how we as developers should take responsibility for ourselves and our careers.

I always enjoy Sandro’s talks, and this one was a personal highlight of the conference for me – the scene was perfectly set when Sandro opened the session with a question “Does anyone have complete freedom to do what they want in their day job?”. Three of us put up our hands, to which Sandro replied that we “should get the f*ck out, as we shouldn’t be in this session”. Fair comment! There was a lot to take on board here, and I was was quite engrossed to the actual talk, and so my notes are a little sketchy. I’ll try my best to summaries the key takeaways for me:

• In order to create a great software development team and company you have to:
  • Define the culture you want to have in your company
  • Don’t make your problem bigger. Hire allies
  • Help people to help you
• Hiring great developers is not an easy process, but this is critical for creating a great team (and company)
• Good Developers want a good company. If you’re hiring developers then please remember this obvious but often forgotten fact!
• Don’t just rely on boilerplate job advertisements for recruitment (Sandro’s slides contained some great examples)
• If you wouldn’t promote someone on a criteria, then don’t use it for a job advertisement i.e. please don’t use the much maligned ‘X years experience of Y’
• Hiring developers should not be entrusted to the HR department. There doesn’t exist a simple process or test to find the best developers
• Look for passionate developers. Passion could/should be used as a CV filter
• If you have a problem developer at your company, ask yourself
  • How was he hired?
  • How was he nurtured when he got here?
• If you are looking for a job then publicly display examples of code you have created (OSS etc), personal projects and other involvement with the larger community. Show that you’re more than a 9-to-5er – show your passion for software development! Amen to that…
• Pairing is a vital skill to learn – this allows prospective colleagues to see how you think, how you code, and also how you will be able to transfer knowledge
• When looking to do something beneficial within your company, such as creating ‘brown bag’ technical sessions, or running software craftsman discussion groups, it is best to “ask for forgiveness, rather than beg for permission”
• If you are in a position of authority then you should lead by example
• If you are responsible, then you must also be accountable
• Managers of great teams must provide autonomy, mastery and purpose
• You are ultimately responsible for your career, therefore you must take responsibility. If you don’t like something, then take action to change it

That’s all for this first part of the JAX London review. Stay tuned for the second part later this week (hopefully… 🙂 )

[Book Review] Practical Unit Testing with TestNG and Mockito

Practical Unit Testing with TestNG and Mockito – by Tomek Kaczanowski

TL;DR This is an essential book on Unit Testing for both novice and experienced Java developer alike. Practical Unit Testing provides a well-paced and logical introduction into the world of Unit Testing, and also offers the more experienced practitioners a discussion on topics such as defining what to test and verify, how to write high-quality and maintainable tests, and also when (shock horror!) not to test. This book provides a plethora of examples and is extremely pragmatic in it’s delivery of testing in the real world. I would also strongly recommend this book to any JUnit fans that haven’t experimented with TestNG lately – you might be surprised what this framework now offers!

Practical Unit testing is divided into five primary sections: ‘Developer’s Tests’, ‘Writing Test’, ‘Hints and Discussion’, ‘Listen and Organise’ and ‘Make them better’. It’s worth mentioning here that this flavour of the book strongly focuses on using TestNG and Mockito (there is a JUnit flavoured version, Practical Unit Testing with JUnit and Mockito). As mentioned above, if you haven’t played with TestNG lately, I would recommend that you do (with this book by you side), as the framework has developed rapidly over the past few years into a genuine competitor against JUnit.

Section 1, ‘Developer’s Tests’, begins by discussing motivations and the core methodology behind testing in general. Unit testing is then defined and the basic concepts introduced to the reader. Section 2 begins by getting the reader to write their first tests, and introduces key concepts such as assertions and parameterised tests.

Section 2 of the book continues with Chapter 4, which introduces the reader to Test Driven Development (TDD), and IMHO this chapter should be read by all Java developers. The author presents an excellent discussion on when to write tests, the ‘rhythm’ of TDD and the benefits offered, and also provides concrete examples. This chapter even covers when not to use TDD, which I know can be heresy to some advocates, but as a long time practitioner of TDD I can relate to points made by the author in this chapter.

As with any technique (or philosophy) as powerful as TDD it is easy to become dogmatic about the subject, and ultimately forgot that not every problem can be solved with a single approach or solution. Paraphrasing the author, he suggests problem areas with applying TDD can include not having a good knowledge of the problem domain, not understanding the technologies, and when working on legacy code. In my experience, I have made several mistakes with applying TDD in the areas identified, and so the author’s cautions should be well received (on a related topic, I can highly recommend Working Effectively with Legacy Code (Robert C. Martin) when dealing with testing legacy code)

Next is very useful discussion Mocks, Stubs and Spies, which is obviously focused on Mockito (which is currently my Mocking framework of choice). As with all the concepts discussed in this book, the example code provided is very useful and of high quality. On a related topic, I would definitely recommend a read of the Mockito website in addition to the this chapter, as the website includes a vast array of examples, and is also updated often.

Section 3 of the book kicks off with Chapter 6, ‘Things You Should Know’, and this chapter is again essential reading. In fact I would go so far to say that this part of the book is worth the entry fee alone – it covers a lot very interesting topics, such as knowing what to test, isolating code under test, making tests timely, using external data and dealing with concurrency. It also discusses what the author refers to as ‘points of controversy’, such as limiting multiple assertions per test (the logical assertions debate) and private method testing.

The remaining two sections of the book focus on getting feedback from tests (and what to do with it), how to organise your tests, and also how to write maintainable high-quality tests. This was an often overlooked topic in a lot of the earlier TDD books, and the often (unspoken) implication was that test code doesn’t have to be as high-quality as ‘production’ code, which is obviously a complete fallacy. In my experience poorly written (and brittle) tests can often slow development down considerably, and this ultimately leads to tests being either removed or ignored…

In summary, this is an essential purchase for any Java developer serious about testing and TDD. For some reason, this book appears to be under the radar to a lot of TDD advocates, and I’m not sure why. The current favourite TDD book, of which I am also a huge fan of, is Effective Unit Testing: A guide for Java developers, and I believe this TestNG-focused book is a great complement to the JUnit-focused work presented in Effective Unit Testing. Practical Unit Testing provides a great introduction for developers new to TDD, and also offers experienced TDDers plenty to think about. The book is well-paced and logical in it’s approach, and provides a comprehensive approach to writing useful, high-quality and maintainable tests.

Click here to buy Practical Unit Testing with TestNG and Mockito on Amazon UK (This is a sponsored link. Please click through and help a fellow developer buy some more books!)

Testing Web-based Spring Applications in 2013 (Part One)

A fellow LJCer and TDD/BDD advocate has recently started developing an application using the ever-popular Spring stack, and he asked my advice on how best to implement a Test-driven methodology within this context. I started typing an email back in response, but then it suddenly occurred to me that this might be useful for other people as well… So here it is – I hope it helps 🙂

Assumptions

The rest of this post assumes the following:

• Applications will be implemented in Java using the following components of the Spring stack: Core, MVC, Data, Security etc BUT we won’t be covering Spring Integration or Batch (although the recommended testing frameworks and tools can be quite similar I find that the techniques for testing these components can be quite different, and so this will have to wait until another blog post :))
• ‘End-users’ will interact with the developed application(s) via a web-based UI and/or HTTP-based API (typically, but not exclusively REST-like)
• For production an external datastore will be utilised to persist long-lived state within the application. We assume that you will want to test how your application interacts with this too.
• We will not cover testing via remote or embedded containers, other than using a simple in-memory servlet container such as Jetty to deploy the entire packaged application. Frameworks such as Arquillian offer some really cool features that allow Unit testing against real (embedded) containers such as Tomcat, GlassFish and JBoss Application Server. This is achieved by providing mechanisms to simulate production-like packaging (“ShrinkWrapping“) and deployment of an arbitrary sub-set of components (down to the Class-level) for testing within the embedded container, all via your favourite testing framework such as JUnit.

General Recommendations

If you’re new test-driven development I recommend the following books:

• Effective Unit Testing: A guide for Java developers – This is a great (and up to date) introduction to all key concepts and technologies within Java-based unit testing. This book not only covers motivations and methodologies, but also how to write ‘good’ tests that are expressive and maintainable etc, and also advice on choosing the most appropriate technique for each use case.
• Practical Unit Testing with JUnit and Mockito and/or Practical Unit Testing with TestNG and Mockito. These are both great books that contain a wealth of practical examples on how to test Java applications, and also discusses the why and how of TDD. Both books are very similar and differ primarily in the framework used to drive the tests. My advice is to buy the TestNG version in combination with ‘Effective Unit Testing’ (which is primarily focused on JUnit), as it’s great to know the differences and strengths/weaknesses of the two most popular Java-based testing engines.
• Growing Object-Oriented Software, Guided by Tests (Beck Signature) – this is one of the classic TDD books, and it discusses all of the high-level concepts and motivations of Test-driving application design. This book also provides a great practical example of how to use the prescribed methodology by detailing the construction and evolution of an entire application based on an auction website.
• There are a few books written about Unit testing JavaScript, and although I haven’t had chance to read them all I do recommend Testable JavaScript

Testing the Core

Unit Testing

Purpose: The core of your application models the problem you are trying to solve, and typically contains domain-specific representations and associated ‘business’ rules which you are primarily responsible for writing (i.e. the opportunity to re-use third-party code here is somewhat limited).

Accordingly it is easy to argue that this code should be well tested – not only are the components you implement here likely to be unique, but you want to be sure they behave as expected before wiring them up to frameworks that offer boilerplate functionality, such as persistence. Well written tests here can also ‘document’ your code (and associated functionality) at the micro level.

Tools:

• JUnit / TestNG – de facto frameworks for running Java tests. I like to run these as part of my Maven build process via the surefire plugin
• Spock – an awesome Groovy-based testing and specification framework. If you haven’t heard of it stop reading right now and go visit the webpage. Seriously. Now check out the Spock Basics page. How awesome is that?? 🙂 And it plays well with Spring too!
• Mockito – my favourite mocking framework. Others do exist, but I find Mockito strikes a great balance betweeen ease of use, expressivity and maintainability
• PowerMock – a great extension to Mockito for use when you face a difficult situation that Mockito can’t cope with, such as mocking an old library that relies on static methods, or mocking private or final methods, or mocking object instantiation. My advice is to always double and triple-check your component design when you start reaching for PowerMock – often the desire to use PowerMock indicates a testing ‘smell’, and may indicate that your component design should be improved, or the manner in which your code interfaces with external dependency could be enhanced. For example, rather than mocking a third-party library’s static constructor method, could you not hide this method call behind your own interface (following the decoractor/adapter pattern) which will facilitate easier mocking?
• ConcurrentUnit – a great utility framework for the difficult task of testing concurrency within components
• Make-it-easy – a great little framework for creating Test Data builder (the concept of which comes from the aforementioned ‘Growing Object-Oriented Software, Guided by Tests)‘
• junitparams – a great framework for augmenting JUnits parameterised testing (or as the creator states – ‘Parameterized tests that don’t suck’)

Do:

• Isolate Classes and components under test. Unit tests should be focused on testing small units of work, and therefore have minimal dependencies (or dependencies should be mocked)
• Create test cases that cover all paths through the code, not just the happy path
• Create tests the replicate edge cases
• Use the power of parameterised tests to facilitate rapid addition of data-driven test cases as they are discovered

Don’t:

• Write trivial tests just to increase unit test coverage
• Create brittle tests that break with the slightest change to your code i.e. if your using more than 10 lines of code to set up your mocks and expectations then you may be doing something wrong
• Test getters and setters, unless they contain logic
• Directly test any interaction with the underlying OS (file, network etc), a datastore, or any container/server. This interaction should be mocked at this level of testing

Plugging it together

Integration Tests – Persistence Layer

Purpose: Think Unit testing for your persistence or DAO layer, but here you want to simulate behaviour offered by an external resource, rather than mocking this functionality.

Tools:

• All the Unit Testing tools mentioned above plus…
• Utilise Spring’s @ContextConfiguration  to manage the wiring of dependencies together, such as an EntityManager or MongoOperations, and AbstractTransactionalJUnit4SpringContextTests to manage running the tests with well-defined transaction semantics
• Embedded (in-memory) versions of your chosen datastore e.g.
  • H2 – A great embedded SQL datastore, and in 99% of standard use cases behaves like MySQL (although Your Mileage May Vary…)
  • Embedded MongoDB – for all your MongoDB datastore needs (or for older versions of MongoDB, pre 2.9, check out another project I contributed to SDFongo)
  • Embedded Solr via ZoomInfo’s InProcessSolrServer, and updated by me (shameless self-plug! 🙂 )
  • ActiveMQ – run as embedded and non-persisting

Do:

• Assert that entities persist as you expect them. I’ve lost count of the number of times I’ve incorrectly configured XToMany JPA annotations which resulted in incorrect cascading operations to child entities.
• Aim to keep test execution time reasonably small.
• Test all public methods exposed on the DAO/repository interface
• Create harnesses that allow the loading of pre-canned test data. Think executeSqlScript() from Spring’s AbstractTransactionalJUnit4SpringContextTests
• Destroy (or delete) data at the end of each test in order to prevent previous test data from influencing results. This is especially important if your chosen testing framework doesn’t guarantee the order in which tests are executed!

Don’t

• Overly duplicate coverage from the Unit tests i.e. most business logic will call the persistence layer to load data, process this, and call the persistence layer again to save the results. Tests at this level only need to focus on the load and save
• Test every conceivable permutation of data
• Chain too many operations together – this should be covered by service-integration tests or end-to-end tests

Coming in Part 2…

I’ll try and post Part 2 soon, and this will cover topics such as Service-level Integration testing, Web-based testing and API testing. Part 3 will cover end-to-end (E2E) testing and BDD.

Testing Solr 4.3.X within Spring (An update to ZoomInfo’s InProcessSolrServer)

A recent contract I was working on had decided to use Solr to implement full-text search over a product catalogue for an e-commerce platform. Naturally we were approaching development with a TDD-mindset, and were keen to implement both Unit Tests for core business functionality, and also integration tests for for a more end-to-end style of testing. The primary application stack consists of Spring (Core, Data, MVC), MySQL and Solr 4.

Just a slight aside, but for anyone looking to implement full-text search the primary candidates are Solr and ElasticSearch. I won’t discuss the merits of either implementation further as it’s best to evaluate each in respect to your use cases (and here is an excellent resource to help you decide http://solr-vs-elasticsearch.com/) 

With our chosen frameworks and datastores we found the Unit testing relatively straight-forward, and decided to use JUnit (driven via the Maven surefire plugin), Mockito for mocking external dependencies (persistence layer, API calls etc), and PowerMock for the difficult mocking (for example, mocking static method calls of several reliable-but-decidedly-old-skool dependencies).

Integration testing was also relatively easy to setup – we chose to again drive tests via JUnit (this time via the failsafe plugin), and use Spring’s @ContextConfiguration and AbstractTransactionalJUnit4SpringContextTests to manage injected sub-components (@Autowires etc) and instantiate various parts of the application for testing, and we also ran an embedded H2 database to allow realistic simulation of a SQL datastore (just an aside, in ~99% of ‘standard’ use cases I have found H2 to behave identically to MySQL, but there are a couple of corner cases to watch out for – this will be another blog post :))

The Problem – How do we run an embedded Solr?

When we first started using Solr 4 we naturally wanted to create integration tests running against this datastore, and we wanted to run this in the same manner as we did with H2 – executing as a light-weight in-memory (embedded) process that we could create, pre-load, and destroy relatively quickly.

We soon found the EmbeddedSolrServer Class distributed within the Solr package, and although useful it didn’t fit in exactly with the way we wanted to design and deploy the Solr communication layer within our Spring application. For production use we wanted to instantiate a SolrServer bean for which we supply the target endpoint on the network (and under the hood this SolrServer bean would actually be instantiated using a custom HttpSolrServer Class). We needed a way to create an ’embedded’ version that implemented the SolrServer interface, but also allowed us to override the Solr config and data directory (to load pre-canned indexes etc)

After a fair bit of searching we stumbled over ZoomInfo’s excellent blog in which they had shared their version of an embedded SolrServer that could easily be exposed as a Spring bean. They called the Class the InProcessSolrServer

We would like to offer many thanks to ZoomInfo for sharing there great work, and this Class provided us with many months of good service. However, with the latest releases of Solr (4.2 +) ZoomInfo’s InProcessSolrServer will no longer compile due to an interface change within the Solr internals.

In the spirit of sharing the wealth I wanted to blog an update to the original ZoomInfo code, which addresses the interface change, and I’ve also included the Spring scaffolding in the gist below to give you an idea of how we run this code.

	package uk.co.taidev.solrtesting.solr;
	import com.google.common.base.Throwables;
	import com.google.common.io.Files;
	import com.iat.compassmassive.normalisedproductloader.springutils.SpringProfileName;
	import org.apache.solr.client.solrj.SolrRequest;
	import org.apache.solr.client.solrj.SolrServer;
	import org.apache.solr.client.solrj.SolrServerException;
	import org.apache.solr.client.solrj.embedded.EmbeddedSolrServer;
	import org.apache.solr.client.solrj.response.UpdateResponse;
	import org.apache.solr.common.util.NamedList;
	import org.apache.solr.core.CoreContainer;
	import org.apache.solr.core.CoreDescriptor;
	import org.apache.solr.core.SolrCore;
	import org.apache.solr.core.SolrResourceLoader;
	import org.apache.solr.schema.IndexSchema;
	import org.apache.solr.search.SolrIndexSearcher;
	import org.apache.solr.util.RefCounted;
	import org.slf4j.Logger;
	import org.slf4j.LoggerFactory;
	import org.springframework.context.annotation.Profile;
	import org.springframework.stereotype.Component;
	import java.io.Closeable;
	import java.io.File;
	import java.io.IOException;
	import java.util.Collection;
	/**
	* SolrServer sub-class that manages the life-cycle of an in-process(embedded) Solr server.
	* <p/>
	* Modified from original source provided by ZoomInfo @ http://browse.feedreader.com/c/ZoomInfo_Blog/12021683
	* <p/>
	* Required dependencies: Spring 3.2.X, Solr, 4.2.X+ (or 4.3.X), Guava 14+
	* <p/>
	* User: Daniel Bryant
	* Date: 01/07/13
	*/
	@Component
	@Profile(SpringProfileName.DEVELOPMENT)
	public class InProcessSolrServer extends SolrServer implements Closeable {
	//
	//------------------ static -------------------------
	//
	private static final Logger LOGGER = LoggerFactory.getLogger(InProcessSolrServer.class);
	private static final String DEFAULT_SOLR_HOME_DIR_PATH = "./src/test/resources/solr/";
	//
	//------------------ instance-------------------------
	//
	private File solrHomeDir = null;
	private File dataDir = null;
	private SolrServer delegate = null;
	private transient SolrCore core = null;
	//
	//------------------ constructor -------------------------
	//
	/**
	* Create an InProcessSolrServer using the default Solr Home Directory.
	*/
	public InProcessSolrServer() {
	this(DEFAULT_SOLR_HOME_DIR_PATH);
	}
	/**
	* Create an InProcessSolrServer using the specified Solr Home Directory and a Solr Data Directory placed
	* beneath the system's temporary directory (as defined by the Guava method Files.createTempDir()).
	*
	* @param solrHomeDirPath path to Solr Root Directory
	*/
	public InProcessSolrServer(String solrHomeDirPath) {
	try {
	System.setProperty("solr.solr.home", solrHomeDirPath);
	System.setProperty("solr.data.dir", Files.createTempDir().getAbsolutePath());
	CoreContainer.Initializer initializer = new CoreContainer.Initializer();
	CoreContainer coreContainer = initializer.initialize();
	delegate = new EmbeddedSolrServer(coreContainer, "");
	} catch (Exception e) {
	throw Throwables.propagate(e);
	}
	}
	//
	//------------------ public -------------------------
	//
	/**
	* This method passes all queries and indexing events on to an in-process delegate.
	*
	* @param req Solr Request
	* @return NamedList
	* @throws SolrServerException if an error occurs when processing the request
	* @throws IOException if an IOException occurs when processing the request
	*/
	@Override
	public NamedList<Object> request(final SolrRequest req) throws SolrServerException, IOException {
	try {
	return getDelegate().request(req);
	} catch (final Exception e) {
	Throwables.propagateIfInstanceOf(e, SolrServerException.class);
	Throwables.propagateIfInstanceOf(e, IOException.class);
	throw Throwables.propagate(e);
	}
	}
	/**
	* Closes the Solr Core.
	*/
	@Override
	public synchronized void close() {
	if (core != null) {
	core.close();
	core = null;
	}
	}
	/**
	* SolrIndexSearcher adds schema awareness and caching functionality over the Lucene IndexSearcher.
	* http://lucene.apache.org/solr/normalisedproductloader/org/apache/solr/search/SolrIndexSearcher.html
	*
	* @return RefCounted SolrIndexSearcher
	* @throws SolrServerException
	*/
	public RefCounted<SolrIndexSearcher> getIndexSearcher() throws SolrServerException {
	getDelegate(); // force the delegate to be created
	return core.getSearcher();
	}
	/**
	* Returns the index schema used by this Solr server.
	*
	* @return delegate SolrServer primary core IndexSchema
	* @throws SolrServerException
	*/
	public IndexSchema getIndexSchema() throws SolrServerException {
	getDelegate(); // force the delegate to be created
	return core.getSchema();
	}
	/**
	* Prepares this SolrServer for shutdown.
	*/
	@Override
	public void shutdown() {
	LOGGER.debug("shutdown entry...");
	close();
	LOGGER.debug("...core closed...");
	}
	@Override
	public UpdateResponse addBeans(Collection<?> beans) throws SolrServerException, IOException {
	UpdateResponse updateResponse = super.addBeans(beans);
	super.commit();
	return updateResponse;
	}
	@Override
	public UpdateResponse deleteByQuery(String query) throws SolrServerException, IOException {
	UpdateResponse updateResponse = super.deleteByQuery(query);
	super.commit();
	return updateResponse;
	}
	//
	//------------------ protected -------------------------
	//
	@Override
	@SuppressWarnings("FinalizeDeclaration")
	protected void finalize() throws Throwable {
	close();
	super.finalize();
	}
	//
	//------------------ private -------------------------
	//
	/**
	* This method creates an in-process Solr server that otherwise behaves just as expected.
	*/
	private synchronized SolrServer getDelegate() throws SolrServerException {
	if (delegate != null) {
	return delegate;
	}
	try {
	CoreContainer container = new CoreContainer(SolrResourceLoader.locateSolrHome());
	CoreDescriptor descriptor = new CoreDescriptor(container, "core1", solrHomeDir.getCanonicalPath());
	core = container.create(descriptor);
	container.register("core1", core, false);
	delegate = new EmbeddedSolrServer(container, "core1");
	return delegate;
	} catch (IOException ex) {
	throw new SolrServerException(ex);
	}
	}
	/**
	* Sets the Solr root directory. In Solr’s documentation, this is generally referred to as "/solr-root". The "conf"
	* directory (containing schema, stopwords, synonyms etc) will be a subdirectory of this.
	*
	* @param solrHomeDir Solr 'Home Directory'
	*/
	private void setSolrHomeDir(final File solrHomeDir) {
	this.solrHomeDir = solrHomeDir;
	System.setProperty("solr.home", solrHomeDir.getPath());
	if (this.dataDir == null) {
	setDataDir(new File(solrHomeDir, "data"));
	}
	}
	/**
	* Sets the Solr data directory. This is the parent directory of the "index" and "spellchecker" directories.
	*
	* @param dataDir Solr 'Data Directory'
	*/
	private void setDataDir(final File dataDir) {
	this.dataDir = dataDir;
	System.setProperty("solr.data.dir", dataDir.getPath());
	}
	}

view raw InProcessSolrServer.java hosted with ❤ by GitHub

I hope this helps, and if you have any questions then please feel free to comment or tweet 🙂

[Book Review] Extreme Programming Pocket Guide

Extreme Programming Pocket Guide – by Chromatic

TLDR: If you’re looking for a concise guide to the philosophy and practices within the Extreme Programming (XP) movement then this is the book for you. Yes, the book was published nearly 10 years ago (which is practically a lifetime in the world of computing), but fundamental methodologies such as those documented within this book really don’t go out of date.

Even though I have worked within the software development industry for a decade I have never actually read a focused overview of what Extreme Programming is. Sure, I’ve read lots of blogs and chatted at great length to my peers about the subject, but after several heated discussions at a local Java User Group I realised it was about time I read up on the subject properly.

My goal was to learn in as short a time as possible about how the processes we all associate with the XP movement fit together, and I believe this book met that objective perfectly. There are plenty of bite-sized and quotable words of wisdom on topics such as the core XP Values, Coding Practices (TDD, pairing etc), XP events, development artifacts and XP Roles. I personally found it very helpful in clarifying my thoughts on the XP process as a whole – many of the XP practices are now common place within our industry, but often they are used in isolation or not as originally intended, and this book is a great reminder/primer on how the XP movement is not just a series of good practices, but a general philosophy for producing well-crafted software applications.

In summary, this is a very useful book for exploring XP practices and also understanding the philosophy behind the movement.

Click Here to buy Extreme Programming Pocket Guide on Amazon (This is a sponsored link. Please click through and help a fellow developer to buy some more books!  )