Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

and many more ....

Featured FREE Whitepapers

What's New Here?

groovy-logo

Writing Groovy’s groovy.util.slurpersupport.GPathResult (XmlSlurper) Content as XML

In a previous blog post, I described using XmlNodePrinter to present XML parsed with XmlParser in a nice format to standard output, as a Java String, and in a new file. Because XmlNodePrinter works with groovy.util.Node instances, it works well with XmlParser, but doesn’t work so well with XmlSlurper because XmlSlurper deals with instances of groovy.util.slurpersupport.GPathResult rather than instances of groovy.util.Node. This post looks at how groovy.xml.XmlUtil can be used to present GPathResult objects that results from slurping XML to standard output, as a Java String, and to a new file. This post’s first code listing demonstrates slurping XML with XmlSlurper and writing the slurped GPathResult to standard output using XmlUtil‘s serialize(GPathResult, OutputStream) method and the System.out handle. slurpAndPrintXml.groovy : Writing XML to Standard Output #!/usr/bin/env groovy// slurpAndPrintXml.groovy // // Use Groovy's XmlSlurper to "slurp" provided XML file and use XmlUtil to write // XML content out to standard output.if (args.length < 1) { println "USAGE: groovy slurpAndPrint.xml <xmlFile>" }String xmlFileName = args[0]xml = new XmlSlurper().parse(xmlFileName)import groovy.xml.XmlUtil XmlUtil xmlUtil = new XmlUtil() xmlUtil.serialize(xml, System.out) The next code listing demonstrates use of XmlUtil‘s serialize(GPathResult) method to serialize the GPathResult to a Java String. slurpAndSaveXml.groovy : Writing XML to Java String #!/usr/bin/env groovy// slurpXmlToString.groovy // // Use Groovy's XmlSlurper to "slurp" provided XML file and use XmlUtil to // write the XML content to a String.if (args.length < 1) { println "USAGE: groovy slurpAndPrint.xml <xmlFile>" }String xmlFileName = args[0]xml = new XmlSlurper().parse(xmlFileName)import groovy.xml.XmlUtil XmlUtil xmlUtil = new XmlUtil() String xmlString = xmlUtil.serialize(xml) println "String:\n${xmlString}" The third code listing demonstrates use of XmlUtil‘s serialize(GPathResult, Writer) method to write the GPathResult representing the slurped XML to a file via a FileWriter instance. slurpAndPrintXml.groovy : Writing XML to File #!/usr/bin/env groovy// slurpAndSaveXml.groovy // // Uses Groovy's XmlSlurper to "slurp" XML and then uses Groovy's XmlUtil // to write slurped XML back out to a file with the provided name. The // first argument this script expects is the path/name of the XML file to be // slurped and the second argument expected by this script is the path/name of // the file to which the XML should be saved/written.if (args.length < 2) { println "USAGE: groovy slurpAndSaveXml.groovy <xmlFile> <outputFile>" }String xmlFileName = args[0] String outputFileName = args[1] xml = new XmlSlurper().parse(xmlFileName)import groovy.xml.XmlUtil XmlUtil xmlUtil = new XmlUtil() xmlUtil.serialize(xml, new FileWriter(new File(outputFileName))) The examples in this post have demonstrated writing/serializing XML slurped into GPathResult objects through the use of XmlUtil methods. The XmlUtil class also provides methods for serializing the groovy.util.Node instances that XmlParser provides. The three methods accepting an instance of Node are similar to the three methods above for instances of GPathResult. Similarly, other methods of XmlUtil provide similar support for XML represented as instances of org.w3c.dom.Element, Java String, and groovy.lang.Writable.The XmlNodePrinter class covered in my previous blog post can be used to serialize XmlParser‘s parsed XML represented as a Node. The XmlUtil class also can be used to serialize XmlParser‘s parsed XML represented as a Node but offers the additional advantage of being able to serialize XmlSlurper‘s slurped XML represented as a GPathResult.Reference: Writing Groovy’s groovy.util.slurpersupport.GPathResult (XmlSlurper) Content as XML from our JCG partner Dustin Marx at the Inspired by Actual Events blog....
apache-hadoop-logo

Hadoop and the OpenDataPlatform

Pivotal, IBM and Hortonworks announced today the “Open Data Platform” (ODP) – an attempt to standardize Hadoop. This move seems to be backed up by IBM, Teradata and others that appear as sponsors on the initiative site. This move has a lot of potential and a few possible downsides. ODP promises standardization – Cloudera’s Mike Olson downplays the importance of this “Every vendor shipping a Hadoop distribution builds off the Hadoop trunk. The APIs, data formats and semantics of trunk are stable. The project is a decade old, now, and the global Hadoop community exercises its governance obligations responsibly. There’s simply no fundamental incompatibility among the core Hadoop components shipped by the various vendors.” I disagree. While it is true that there are no “fundamental incompatibility” there is a lot of non-fundamental ones. Each release by each vendor includes backport of features that are somewhere on the main trunk but far from the stable release. This means, that as a vendor, we have to both test our solutions on multiple distributions and work around the  subtle incompatibilities. We also have to limit ourselves to the lowest common denominator of the different platforms (or not support a distro) – for instance, until today, IBM did not support Yarn or Spark on their distribution Hopefully standardization around common core will also mean that the involved vendors will deliver their value-add on that core unlike today where the offerings are based on proprietary extensions (this is true for Pivotal, IBM etc. not so much for Hortonworks). Today, we can’t take Impala and run it on Pivotal can we take Hawk and run it on HDP . With ODP we would, hopefully,  be able  mix-and-match and have installations where we can, say,  use IBM’s BigSQL with GemFire HD running on HDP and other such mixes. This can be good news for these vendors by enlarging their addressable market and for us a users by increasing our choice and reducing lock-in. So what are the downsides/possible problems? Well, for one we need to see that the scenarios I described above will actually happen and this isn’t just a marketing ploy. Another problem, the elephant in the room if you will,  is that the move is not complete –  Cloudera, a major Hadoop player, is not part of this move and as can be seen in the post referenced above, are against it. This is also true for MapR. With these two vendors out we still have multiple vendors to deal with and the problems ODP sets to solve will not disappear. I guess if ODP was led by the ASF or some other more “impartial” party it would have been easier to digest but as it is now all I can do is hope that both ODP will live to its expectations and that in the long run Cloudera and MapR will also join this initiative .Reference: Hadoop and the OpenDataPlatform from our JCG partner Arnon Rotem Gal Oz at the Cirrus Minor blog....
docker-logo

Multi-Tier Architecture Tutorial using Docker

Background While there are many very good Docker tutorials currently available, I found that many are either too simplistic in the scenarios offered, or in some cases, too complex for my liking. Thus, I decided to write my own tutorial that describes a multi-tier architecture configured using Docker. Prerequisites This tutorial assumes that you have successfully installed Git and Docker. I’m running Boot2Docker on a Mac, which enables Docker to be run nearly as though it were installed natively on the Mac (on the PC, Boot2Docker isn’t quite as straightforward). I assume some  basic level of familiarity with Docker (a good source of information is https://docs.docker.com/articles/basics/). Scenario The scenario I developed for purposes of this tutorial is depicted below:As you can see, it involves multiple tiers: MongoDB: This is our persistence layer that will be populated with some demo data representing customers. API Server: This tier represents Restful API services. It exposes the mongo data packaged as JSON (for purposes of this tutorial, it really doesn’t use any business logic as would normally be present).  This tier is developed in Java using Spring Web Services and Spring Data. WebClient: This is a really simple tier that demonstrates a web application written in Google’s Polymer UI framework. All of the business logic resides in Javascript, and a CORS tunnel is used to then access the API data from the services layer. I’m not going to spend much time on the implementation of each tier, as it’s not really relevant for purposes of this Docker tutorial. I’ll touch on some of the code logic briefly just to set the context. Let’s begin by looking at how the persistence layer was configured. MongoDB Configuration  Note: The project code for this tier is located at: https://github.com/dajevu/docker-mongo. Dockerhub contains an official image for mongo that we’ll use as our starting point (https://registry.hub.docker.com/u/dockerfile/mongodb/). In case we need to build upon what is installed in this image, I decided to clone the image by simply copying its Dockerfile (images can be either binary or declaratively via a text Dockerfile). Here’s the Dockerfile:Line 5 identifies the base image used for the mongo installation – this being the official dockerfile/ubuntu image. Since no version was specified, we’re grabbing the latest. Note: Comments in Dockerfiles start with #. Line 8 begins the installation of the mongo database, along with some additional tools such s curl, git etc. Ubuntu’s apt-get is Ubuntu’s standard package management tool. Lines 16 and 18 setup some mount points for where the mongo database files will reside (along with a git mount point in case we need it later). On line 21, we set the working directory to be that data mount point location (from line 16). And lastly, we identify some ports that will need to be exposed by Mongo (lines 27 & 28). Assuming you have grabbed the code from my git repository (https://github.com/dajevu/docker-mongo), you can launch launch this Docker image by running the script runDockerMongo.sh (in Windows Boot2Docker, you’ll need to fetch the code within the VM container that Docker is running on). That script simply contains the following: docker run -t -d -p 27017:27017 --name mongodb jeffdavisco/mongodb mongod --rest --httpinterface --smallfiles When run, it will use the Dockerfile present in the directory to launch the container. You can confirm it’s running by using the docker ps command:As you can see from the above, in this case it launched Mongo using container Id of 4fb383781949. Once you have the container Id, you can look at the container’s server logs using: docker logs --tail="all" 4fb383781949 #container Id If you don’t see any results from docker ps, that means that the container started but then exited immediately. Try issuing the command docker ps -a- this will identify the container Id of the failed service and you can then use docker logs to identify what went wrong. You will need to remove that container prior to launching a new one using docker rm. Once the Mongo container is running, we can now populate it with some demo data that we’ll use for the API service layer. A directory called northwind-mongo-master is present in project files and it contains a script called mongo-import-remote.sh. Let’s look at the contents of this file:This script simply runs through each .csv file present in the directory, and use the mongoimport utility to load up the collection. However, there is one little wrinkle. Since mongoimport is connecting to a remote mongo database, the IP address of the remote host is required, and this remote host is the mongo container that was just launched. How did I determine which IP address to use? If you are using Boot2Docker, you can simply run boot2docker ip – this will provide you the IP address of the Docker host you are using. If you are running directly within a host running Docker, you could connect via localhost as your IP address (since that port was exposed to the Docker host when we launched the container). In order to load the test data, update that script so that it has the proper IP address for your environment. Then you can run the script (mongo-import-remote.sh), and it should populate the mongo database with the sample data. If you are using MongoHub, you can connect to the remote mongo host, and see the following collections available:Fortunately, we don’t have to go through such hurdles on the remaining containers. API Service Tier Configuration The API service is a very simple Restful-based web service that simply exposes some of the mongo data in a JSON-format (granted, you can access mongo directly through it’s restful API, but in most real-world scenarios, you’d never expose that publicly).  The web application, written in Java Spring, uses the Spring Data library to access the remote mongo database. The project files for this tier are located at: https://github.com/dajevu/docker-maven-tomcat. While I won’t cover all of the Spring configuration/setup (after all, this isn’t a Spring demo), let’s briefly look at the main service class that will have an exposed web service:Using the Spring annotations for Spring web services, we annotate this controller in line 5 so that Spring can expose the subsequent services using the base URL /customer. Then, we define one method that is used to expose all of the customer data from the Mongo collection. The CustomerDAO class contains the logic for interfacing with Mongo. Let’s look at the Dockerfile used for running this web service (using Jetty as the web server):As you can see, in line 2 we’re identifying the base image for the API services as Java 7 image. Similar to the mongo Dockerfile, the next thing we do in lines 8-15 is install the various required dependencies such as such git, maven and the mongo client. Then, unlike with our mongo Dockerfile, we use git to install our Java web application. This is done in lines 21 thru 26. We create a location for our source files, then install them using git clone. Lastly, in line 28, we the shell script called run.sh. Let’s take a look at that scripts contents: #!/bin/bash echo `env` mvn jetty:run As you can see, it’s pretty minimal. We first echo the environment variables from this container so that, for troubleshooting purposes, can see them when checking the docker logs. Then, we simply launch the web application using mvn jetty:run. Since the application’s source code was already downloaded via git clone, maven will automatically compile the webapp and then launch the jetty web server. Now, you maybe wondering, how does the web service know how to connect to the Mongo database? While we exposed the Mongo database port to the docker host, how is the connection defined within the java app so that it points to the correct location. This is done by using the environment variables automatically created when you specify a dependency/link between two containers. To get an understanding of how this is accomplished, let’s look at the startup script used to launch the container, runDockerMaven.sh: docker run -d --name tomcat-maven -p 8080:8080 \ —link mongodb:mongodb jeffdavisco/tomcat-maven:latest \ /local/git/docker-maven-tomcat/run.sh As you can see, the -link option is used to notify docker that this container has a dependency an another container, in this case, our Mongo instance. When present, the -link option will create a set of environment variables that get populated when the container is started. Let’s examine what those environment variables look like by examining with the docker logs command (remember, before you can launch this container, the mongo container must first be running): MONGODB_PORT_28017_TCP_PROTO=tcp HOSTNAME=f81d981f5e9e MONGODB_NAME=/tomcat-maven/mongodb MONGODB_PORT_27017_TCP=tcp://172.17.0.2:27017 MONGODB_PORT_28017_TCP_PORT=28017 MONGODB_PORT=tcp://172.17.0.2:27017 MONGODB_PORT_27017_TCP_PORT=27017 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/local/git/docker-maven-tomcat MONGODB_PORT_27017_TCP_PROTO=tcp JAVA_HOME=/usr/lib/jvm/java-7-oracle MONGODB_PORT_28017_TCP_ADDR=172.17.0.2 MONGODB_PORT_28017_TCP=tcp://172.17.0.2:28017 MONGODB_PORT_27017_TCP_ADDR=172.17.0.2 The environment variables starting with MONGODB represent those created through the link. How did it know to prefix was MONGODB? That’s simply because, when we launched the mongo container, we specified the optional —name parameter that provided a name alias for that container. Now, how is that incorporated into the API service? When we define the Spring Data properties for accessing mongo, we specify that an environment variable is used to identify the host. This is done in the spring-data.xml file (located under src/main/resources in the project code). threads-allowed-to-block-for-connection-multiplier="4" connect-timeout="1000" max-wait-time="1500" auto-connect-retry="true" socket-keep-alive="true" socket-timeout="1500" slave-ok="true" write-number="1" write-timeout="0" write-fsync="true" /> So, when we startup the container, all that is required is to launch it using runDockerMaven.sh. Let’s confirm that the service is working by accessing the service via the browser using:http://192.168.59.103:8080/service/customer/In your environment, if you are using Boot2Docker, run boot2docker ip to identify the IP address in which the service is exposed. If running directly on a docker host, you should be able to specify localhost. This should bring back some JSON customer data such as:Now, let’s look at the last of the containers, the one used for exposing the data via a web page. Web Application Tier The web application tier is comprised of a lightweight Python web server that just serves up a static HTML page along with corresponding Javascript.  The page uses Google’s Polymer UI framework for displaying the customer results to the browser. In order to permit Polymer to communicate directly with the API service, CORS was configured on on the API server to permit the inbound requests (I wanted to keep the web app tier as lightweight as possible). Note: The source code/project files for this tier can be found at: https://github.com/dajevu/docker-python Here is the relevant piece of code from the Javascript for making the remote call:Obviously, the VMHOST value present in the url property isn’t a valid domain name. Instead, when the Docker container is launched, it will replace that value with the actual IP of the API server.  Before we get into the details of this, let’s first examine the Dockerfile used for the Python server:This Dockerfile is quite similar to the others we’ve been using. Like the mongo container, this one is based on the official ubuntu image. We then specify in lines 11-14 that Python and related libraries are loaded. In line 23-24, we prepare a directory for the git source code. We follow that up by then fetching the code using git clone in line 27, and then set our working directory to that location (line 28). (the CMD command in line 31 is actually ignored because we specify in the launch script which command to run (i.e., it overrides what is in the Dockerfile). Let’s look at the startup script now used to launch our container: docker run -d -e VMHOST=192.168.59.103 --name python -p 8000:8000 \ --link tomcat-maven:tomcat jeffdavisco/polymer-python:latest \ /local/git/docker-python/run.sh A couple of things to note in the above. Notice how I’m passing the IP address of my Boot2Docker instance using the environment flag -e VMHOST=192.168.59.103. Similar to what we needed to do when configuring the API service tier, you will have to modify this for your environment (if using Boot2Docker, run boot2docker ip to find the IP address of your docker host, or if running natively on Linux, you can use localhost). Notice the other thing we are doing is exposing port 8000, which is where our Python web server will be running under. Lastly, we are instructing the docker container to run the run.sh shell script. We’ll look at this next. The run.sh script contains the following: #!/bin/bash# replace placeholder with actual docker host sed -i "s/VMHOST/$VMHOST/g" post-service/post-service.htmlpython -m SimpleHTTPServer 8000 The sed command is used for replacing that VMHOST placeholder token with the environment variable passed to the docker container when it was launched ($VMHOST). Once the html file has been updated, we then launch the python server using the command python -m SimpleHTTPServer 8000. After running the startup script, if everything went well, you should de able to then visit in your browser: http://:8000 (where dockeriphost is equal to your boot2docker ip address, or local docker host if on Linux).  You should see something like:You’ve now completed the tutorial! You have a docker container running mongo; another running an API service; and the last running simple web service. I hope you’ve enjoyed this tutorial, and I hope to have a follow-up to it shortly describing how these the contains can be more easily managed using fig (learn more at: http://www.fig.sh/).Reference: Multi-Tier Architecture Tutorial using Docker from our JCG partner Jeff Davis at the Jeff’s SOA Ruminations blog....
android-logo

Android Text to Speech (TTS)

This post describes how to use text to speech (TTS) in Android. It isn’t so common to find a post explaining how to use it and it is a part of Android not much covered. In my opinion, TTS is very interesting because it can add some nice features to an app. Text to Speech is a feature of Android platform that can be used to “read” the words and make the app talking, or more in detail to synthesize text. In this post, i want to cover how to implement TTS in Android and how we can control some interesting aspects of speech engine. We want to code an app that has a EditText widget so that we write the words that have to be read and some controls to modify the speech engine.Text to speech Engine The first thing we have to do to use the TTS in our app is initialise the engine. The class that controls the engine is called TextToSpeech, engine = new TextToSpeech(this, this); where the first parameter is the Context and the other one is the listener. The listener is used to inform our app that the engine is ready to be used. In order to be notified we have to implement TextToSpeech.OnInitListener, so we have: public class MainActivity extends Activity implements TextToSpeech.OnInitListener { .... @Override public void onInit(int status) { Log.d(&Speech&, &OnInit - Status [&+status+&]&);if (status == TextToSpeech.SUCCESS) { Log.d(&Speech&, &Success!&); engine.setLanguage(Locale.UK); } } } We use the onInit as callback method, and when the engine is ready, we set the default language that the engine used to read our sentence. Read the words Now our engine is ready to be used, we need simply pass the string we want to read. To this purpose, we use an EditText so that the user can edit his string and when he clicks on the microphone the app start reading. Without detailing too much the code because is trivial we focus our attention when user clicks on the microphone button: speechButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { speech(); } }); where private void speech() { engine.speak(editText.getText().toString(), TextToSpeech.QUEUE_FLUSH, null, null); } we simply have to call the speak method to make our app reading the text! Control Text to Speech Engine parameters We can have more control on how the engine read the sentence. We can modify for example the pitch and the speech rate. In the app, for example we used two seek bars to control the pitch and rate. If we want to set the voice pitch we can use setPitch passing a float value. On the other hand, if we want to change the speech rate we can use setSpeechRate. In our app, we read this value from two seek bars and the speech method become: private void speech() { engine.setPitch((float) pitch); engine.setSpeechRate((float) speed); engine.speak(editText.getText().toString(), TextToSpeech.QUEUE_FLUSH, null, null); }Source code available @ githubReference: Android Text to Speech (TTS) from our JCG partner Francesco Azzola at the Surviving w/ Android blog....
apache-spark-logo

Streaming Big Data: Storm, Spark and Samza

There are a number of distributed computation systems that can process Big Data in real time or near-real time. This article will start with a short description of three Apache frameworks, and attempt to provide a quick, high-level overview of some of their similarities and differences. Apache Storm In Storm, you design a graph of real-time computation called a topology, and feed it to the cluster where the master node will distribute the code among worker nodes to execute it. In a topology, data is passed around between spouts that emit data streams as immutable sets of key-value pairs called tuples, and bolts that transform those streams (count, filter etc.). Bolts themselves can optionally emit data to other bolts down the processing pipeline.Apache Spark Spark Streaming (an extension of the core Spark API) doesn’t process streams one at a time like Storm. Instead, it slices them in small batches of time intervals before processing them. The Spark abstraction for a continuous stream of data is called a DStream (for Discretized Stream). A DStream is a micro-batch of RDDs (Resilient Distributed Datasets). RDDs are distributed collections that can be operated in parallel by arbitrary functions and by transformations over a sliding window of data (windowed computations).Apache Samza Samza ’s approach to streaming is to process messages as they are received, one at a time. Samza’s stream primitive is not a tuple or a Dstream, but a message. Streams are divided into partitions and each partition is an ordered sequence of read-only messages with each message having a unique ID (offset). The system also supports batching, i.e. consuming several messages from the same stream partition in sequence. Samza`s Execution & Streaming modules are both pluggable, although Samza typically relies on Hadoop’s YARN (Yet Another Resource Negotiator) and Apache Kafka.Common Ground All three real-time computation systems are open-source, low-latency, distributed, scalable and fault-tolerant. They all allow you to run your stream processing code through parallel tasks distributed across a cluster of computing machines with fail-over capabilities. They also provide simple APIs to abstract the complexity of the underlying implementations. The three frameworks use different vocabularies for similar concepts:Comparison Matrix A few of the differences are summarized in the table below:There are three general categories of delivery patterns:At-most-once: messages may be lost. This is usually the least desirable outcome. At-least-once: messages may be redelivered (no loss, but duplicates). This is good enough for many use cases. Exactly-once: each message is delivered once and only once (no loss, no duplicates). This is a desirable feature although difficult to guarantee in all cases.Another aspect is state management. There are different strategies to store state. Spark Streaming writes data into the distributed file system (e.g. HDFS). Samza uses an embedded key-value store. With Storm, you’ll have to either roll your own state management at your application layer, or use a higher-level abstraction called Trident. Use Cases All three frameworks are particularly well-suited to efficiently process continuous, massive amounts of real-time data. So which one to use? There are no hard rules, at most a few general guidelines. If you want a high-speed event processing system that allows for incremental computations, Storm would be fine for that. If you further need to run distributed computations on demand, while the client is waiting synchronously for the results, you’ll have Distributed RPC (DRPC) out-of-the-box. Last but not least, because Storm uses Apache Thrift, you can write topologies in any programming language. If you need state persistence and/or exactly-once delivery though, you should look at the higher-level Trident API, which also offers micro-batching. A few companies using Storm: Twitter, Yahoo!, Spotify, The Weather Channel... Speaking of micro-batching, if you must have stateful computations, exactly-once delivery and don’t mind a higher latency, you could consider Spark Streaming…specially if you also plan for graph operations, machine learning or SQL access. The Apache Spark stack lets you combine several libraries with streaming (Spark SQL, MLlib, GraphX) and provides a convenient unifying programming model. In particular, streaming algorithms (e.g. streaming k-means) allow Spark to facilitate decisions in real-time.A few companies using Spark: Amazon, Yahoo!, NASA JPL, eBay Inc., Baidu… If you have a large amount of state to work with (e.g. many gigabytes per partition), Samza co-locates storage and processing on the same machines, allowing to work efficiently with state that won’t fit in memory. The framework also offers flexibility with its pluggable API: its default execution, messaging and storage engines can each be replaced with your choice of alternatives. Moreover, if you have a number of data processing stages from different teams with different codebases, Samza ‘s fine-grained jobs would be particularly well-suited, since they can be added/removed with minimal ripple effects. A few companies using Samza: LinkedIn, Intuit, Metamarkets, Quantiply, Fortscale… Conclusion We only scratched the surface of The Three Apaches. We didn’t cover a number of other features and more subtle differences between these frameworks. Also, it’s important to keep in mind the limits of the above comparisons, as these systems are constantly evolving.Reference: Streaming Big Data: Storm, Spark and Samza from our JCG partner Tony Sicilian at the Tony’s Blog blog....
netbeans-logo

JBoss Forge NetBeans integration – Getting Started

JBoss Forge is the Fastest way to build Maven-Based Java EE projects. And as such it already has awesome features to make your life as a developer even easier. For the most part, people looking at Forge are likely interested in creating web-applications. There are plenty of ways to get started with the Forge basics. You can look at the quickstart section or look at the github repository. Just some short days ago Forge got even more awesome. George Gastaldi (@gegastaldi) created a NetBeans Plugin for Forge which allows you to execute all forge commands via the build in NetBeans quick-search.Run JBoss Forge commands straight from your Netbeans IDE Commands are rendered as native Netbeans Wizards Create your own addon and deploy it inside the Netbeans IDEInstalling The Forge Plugin To install the plugin just download the latest version from the netbeans plugin portal and unzip the two nbm files to a folder of your choice. Start NetBeans and navigate to “Window>Plugins” select the “Downloaded” tab and click the “add Plugin” button. Navigate to the folder in which you unzipped the two files and select them. Click the “install” button bottom left and click through the wizard. Restart NetBeans and you’re ready to go. The following video gives you a brief overview about what is possible already.Reference: JBoss Forge NetBeans integration – Getting Started from our JCG partner Markus Eisele at the Enterprise Software Development with Java blog....
software-development-2-logo

XML Manipulation With XML Copy Editor

The XML document format, created in 1996, is still widely used to facilitate communication between disparate systems (though for certain implementations is somewhat being replaced by JSON). As a Java developer, I generally interface with data in an XML document via a DOM parser, but there are occasions where being able to manipulate an XML document directly is advantageous or even necessary. This might be achievable in a simple text editor in unlikely cases where the document in question is particularly small, but often these documents can be quite large. Thus, it would be beneficial to be able to manipulate the document in a program specifically designed for that type of job. In my case, I don’t need to do this type of thing often enough to justify paying for such a piece of software, but I have found that XML Copy Editor has fulfilled my needs for free. A project I am working on communicates with another piece of vendor software through SOAP calls. Sometimes the vendor software does not behave as expected, data gets corrupted, and must be remedied. With no way to facilitate this through the client’s UI, the solution is to directly manipulate the XML data and return it to the vendor system via a SOAP call. This process involves often several pieces of data, delineated by locality (in this case, the state). These files can be up to 10 MB in size, with entries for all 50 states. In my experience, XML Copy Editor has never had any struggle in handling large files, which is of great benefit. In the proceeding paragraphs, I will be describing not only XML Copy Editor, but will also be providing a quick tutorial of XML/XSLT/XPATH. Taking the following as an example, which is a simplified representation of the type of file I usually work with: <Header1> <Header2> <Detail> <State> <Name>Missouri</Name> </State> <SubDetail> <Premium>500</Premium> </SubDetail> </Detail> <Detail> <State> <Name>Kansas</Name> </State> <SubDetail> <Premium>600</Premium> </SubDetail> </Detail> </Header2> </Header1> Usually the first action I take upon opening the file in XML Copy Editor is to execute the “XML → Pretty Print” functionality (F11), since the file is generally meant for communication between systems, and not human readability. “Pretty Print” formats the document with appropriate line breaks and indentations, making it much easier to read and interpret. Now, to find the data that needs to be altered, we employ XPath. What we are looking for in this case is the “Premium” element for Missouri. From the same menu where we accessed “Pretty Print”, we can also access “XML → Evaluate XPath…” (F9), which presents us with a modal dialog containing a single text entry field. The XPath statement we enter is “\\Header1\Header2\Detail\SubDetail\Premium”. Let’s parse this XPath out, shall we? This statement is fairly straight-forward; simply stated, it says to return every node with the ancestry, “Header1 → Header2 → Detail → SubDetail → Premium.” However, this will return both “Premium” nodes for Missouri and Kansas, which is not what we want. Keep in mind that every XPath statement has the potential to return multiple results; it’s up to the developer to make the statement concise enough to return the desired result. In other words, every XPath statement makes the request, “Give me all elements that meet this criteria.” So, we refine this statement in the following manner: “\\Header1\Header2\Detail\SubDetail\Premium[../../../@State='Missouri']”. The addition of the “[../../../@State=’Missouri’]” at the end of this statement can be a bit confusing, but it is a very valuable part of XPath. The “@State=’Missouri’” is a qualifier that says to return the Premium element where the value of the “State” node in the shared ancestry is equal to “Missouri”. If the “State” node were a child of “Premium”, then the statement would look like this: “\\Header1\Header2\Detail\SubDetail\Premium[@State='Missouri']” However, since the “State” node is higher up the ancestry and is a sibling of one of the elements on our XPath (the second “Policy” node), the qualifier has to “step back” in order to identify where in the XML the “State” node resides. Every “../” in the qualifier is one step upwards. Think of it as similar to “cd..” in the Windows command line. Now that we have found the data we want to change, we must alter it. XPath is not capable of this on its own, but using XPath along with XSLT can accomplish our goals. XSLT “transforms” an XML document by reading the rules defined by “templates,” which are defined in a separate XSLT file. The format of the XSLT file is very similar to that of XML. We can create an XSLT file in XML Copy Editor as follows: <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:XSL="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:template> <xsl:template match="\\Header1\Header2\Detail\SubDetail\Premium[@State='Missouri']">100</xsl:template> </xsl:stylesheet> Then, we instigate the “XML → XSL Transform…” (F8) action from the menu. This presents us with an open file dialog, from where we select the XSL file we just defined. This will produce a new XML document with the following contents: <Header1> <Header2> <Detail> <State> <Name>Missouri</Name> </State> <SubDetail> <Premium>100</Premium> </SubDetail> </Detail> <Detail> <State> <Name>Kansas</Name> </State> <SubDetail> <Premium>600</Premium> </SubDetail> </Detail> </Header2> </Header1> So, how does this work? Well, there are two “templates” defined in the XSL file. Templates apply the rules defined to the indicated XML. In this case, the first template instructs to copy the entirety of the XML to the output file. The second template instructs to change the value of the node at the indicated XPath to the value defined.CodeProjectAnd there we have it. I hope that you’ve found this helpful! Leave a comment if you have any questions.Reference: XML Manipulation With XML Copy Editor from our JCG partner Robert Rice at the Keyhole Software blog....
java-interview-questions-answers

Playing with Weld-Probe – See All of your CDI Aspects in One Place

Weld 3.0.0.Alpha4 was released, while I’ve been sitting in a conference room at DevConf.CZ. More or less next to Jozef Hartinger ( @jozefhartinger) who told me about the new awesome features of this latest release a few minutes before in a shared break. There is one particular feature, that really caught my attention which is the new Weld Probe mechanism.     What Is Weld? Weld is the reference implementation of CDI: Contexts and Dependency Injection for the Java EE Platform which is the Java standard for dependency injection and contextual lifecycle management and one of the most important and popular parts of the Java EE platform. Weld is integrated into many Java EE application servers such as WildFly, JBoss Enterprise Application Platform, GlassFish, Oracle WebLogic and others. Weld can also be used in a Servlet-only environment (Tomcat, Jetty) or plain Java SE environment. Weld 3.x marks the versions in first experimental stages for the next CDI 2.0 version which will be included in Java EE 8. As you already might have guessed, there is no server pre-configured and ready to run any of the upcoming Java EE 8 RIs no matter stage they are in. Particular Weld is way ahead of the crowd and starts to experiment with not even specified features these days. To not disrupt the WildFly 9 team with their improvements, the latest versions are NOT part of it yet. Test-driving CDI 2.0 with Weld 3.0.0.Alpha4 In order to test Weld today, you need the stable version of WildFly 8.2 and patch it accordingly. If you want to go with latest WildFly 9, there’s a patch for that, too. Let’s go and download latest WildFly 8.2.0.Final and unzip it to a location of your choice. Next download we need is the Weld 3 Alpha4 Patch for WildFly 8.2. The patch can be applied via the WildFly build in patching mechanism: $>/WildFly/bin/jboss-cli.bat|sh --command="patch apply /path/to/wildfly-8.2.0.Final-weld-3.0.0.Alph4-patch.zip" The successful outcome should look like this: {     "outcome" : "success",     "result" : {} } Now you’re ready to start WildFly. Please keep in mind, that this isn’t an official patch! So, for now consider this an easy way to update your Weld version. Nothing more. If you want to learn more about patching WildFly take a look at Arun’s blog post about patching. $>/WildFly/bin/standalone.bat|sh Now it’s time to play around with it a bit. A good place to keep an eye on is the new features is the Java EE 8 examples project on GitHub. Still in the very early beginnings, it has at least one new CDI 2.0 example which can be run out of the box. But I am looking at showing you one other new feature of Weld, which is the new Weld-Probe mechanism. So, we need a little web-application first. There are a couple of examples in the weld/core/master branch on Github. One of them is the famous number-guess example. Weld-Probe Answers All Your CDI Questions Why isn’t my field injected? Why isn’t my interceptor triggered? What extensions do third-party libraries register? Have you ever found yourself asking a similar question? Making Weld developer-friendly and helpful in troubleshooting is one of the main goals of the new 3.x version. Today, I am introducing to you a new tool called Weld Probe. Probe is a built-in tool that provides a detailed view into internals of a CDI application. Weld Probe has a web UI and is provided out-of-the-box. Probe makes it easy to inspect the following CDI aspects. Even more are planned for the future.beans, their properties such as qualifiers, stereotypes and name a graph of bean dependencies observers and producers declared by beans interceptors and decorators bound to a bean extensions information about current contextual instances tracking of invocations and invocation treesProbe is not meant to replace tools such as a debugger or profiler. It’s more about understanding the application and giving a high level view about the inner workings. Probe consists of a REST API and a default (single-page application) client. Therefore it’s only available in a web application. You need to explicitly enable it for development proposes only by adding a servlet initialization parameter org.jboss.weld.development and setting it to true:  <context-param>         <param-name>org.jboss.weld.development</param-name>         <param-value>true</param-value>     </context-param> Go, build the example and deploy it. Now you can see the number-guess example working. But there’s more to it. Just change the application url a bit and add “/weld-probe” to the end of the context: http://localhost:8080/weld-numberguess/weld-probe and you will see this:Looking over the navigation on top gives you the following areas: Bean Archives The initial view shows all the bean archives in your application. You can decide to hide external archives and the accessibility graph gives you a very useful overview for complicated deployments. Configuration Weld can be configured per application through the set of properties. Overview of the Weld configuration properties and their final values (complete reference Weld Configuration). Beans This view shows all the beans Weld is aware of. Note that  built-in beans and other Java EE specifications that integrate (e.g. for JSR 352: Batch Applications for the Java Platform) are shown as well. There are various filters to find the beans you’re interested in. The bean detail shows all important attributes, declared observers and producers, declaring bean for producers, and also dependencies and dependents.Observer Methods Discover all the registered observer methods, even those declared on extensions or the ones from other Java EE specifications. Contexts This view lets you inspect the bean instances in application and session contexts. Invocation Trees Finally, the invocation tree shows all invocations within the given entry point. Where the entry point is the first business method invocation captured by the monitor in a certain thread. That was it. If you are missing something or would love to leave comments on existing features, feel free to contribute by filing an issue in the Weld JIRA. Keep in mind, this is still pretty much work in progress and will change and enhance with every new version. CDI 2.0 Wants You! But that is not all! CDI 2.0 needs your help and input. There are multiple ways for you to contribute and the specification lead Antoine did a great blog post about what you can do and how to participate. Also feel free to reach out to the Weld community and provide your feedback.Reference: Playing with Weld-Probe – See All of your CDI Aspects in One Place from our JCG partner Markus Eisele at the Enterprise Software Development with Java blog....
software-development-2-logo

Five easy steps to improve your database performance

January 30, 2015: Based on reader feedback, section 4 “Do you have enough database connections?” has been revised. Database access is a core feature of most applications. Based on our experience, it seems that for at least 80% of all applications we see, simple database performance tuning can speed up applications significantly. Fortunately, there isn’t a lot of rocket science involved until you get really deep under the hood of database tuning. When you’re ready to take database tuning to the next level, there are many great tools around for you to consider, for example from our friends at Vivid Cortex. For this post however, we will only focus on quick wins that you can easily achieve without any help from third parties. Step 1. Is your database server healthy? First and foremost, make sure that the host that’s serving your database process has sufficient resources available. This includes CPU, memory, and disk space. CPU CPU will most likely not be a bottleneck, but database servers induce continuous base load on machines. To keep the host responsive, make sure that it has at the very least two CPU cores available. I will assume that at least some of your hosts are virtualized. As a general rule of thumb, when monitoring virtual machines, also monitor the virtual host that the machines run on. CPU metrics of individual virtual machines won’t show you the full picture. Numbers like CPU ready time are of particular importance.Memory Keep in mind that memory usage is not the only metric to keep an eye on. Memory usage does not tell you how much additional memory may be needed. The important number to look at is page faults per seconds.Having thousands of page faults per second indicates that your hosts are out of memory (this is when you start to hear your server’s hard drive grinding away). Disk space Because of indices and other performance improvements, databases use up a LOT more disk space than what the actual data itself requires (indices, you know). NoSQL databases in particular (Cassandra and MongoDB for instance) eat up a lot more disk space than you would expect. MongoDB takes up less RAM than a common SQL database, but it’s a real disk space hog. I can’t emphasize this too much: make sure you have lots of disk space available on your hard drive. Also, make sure your database runs on a dedicated hard drive, as this should keep disk fragmentation caused by other processes to a minimum.One number to keep an eye on is disk latency. Depending on hard drive load, disk latency will increase, leading to a decrease in database performance. What can you do about this? Firstly, try to leverage your application’s and database’s caching mechanisms as much as possible. There is no quicker and more cost-effective way of moving the needle. If that still does not yield the expected performance, you can always add additional hard drives. Read performance can be multiplied by simply mirroring your hard drives. Write performance really benefits from using RAID 1 or RAID 10 instead of, let’s say, RAID 6. If you want to get your hands dirty on this subject, read up on disk latency and I/O issues. Step 2. Who is accessing the database? Once your database is residing on healthy hardware you should take a look at which applications are actually accessing the database. If one of your applications or services suffers from bad database performance, do not jump to the conclusion that you know which application or service is responsible for the bad performance.When talking about inferior database performance, you’re really talking about two different things. On one hand, the database as a whole may be affected. On the other hand, the database may be just a single service that’s experiencing bad performance. If all of the database’s clients experience bad performance, go back and check if your host is truly healthy. Chances are that your hardware is not up to the challenge. If there is only a single service that’s suffering from bad database response times, dig deeper into that service’s metrics to find out what’s causing the problem. Step 3. Understand the load and individual response time of each service If an individual service is having bad database performance, you should take a deeper look into the service’s communication with the database. Which queries are executed? How often are the queries executed per request? How many rows do they return?It’s important to know that issues that materialize on the database level may be rooted elsewhere. Very often there is an issue related to the way a database is accessed. Look at how often queries are called per request. Maybe you can reduce the number of actual database queries by improving the database cache of your service. Question everything. Is there any reason why a single query should be executed more than once per request? If there is, maybe you can unlock some potential performance by applying smart caching strategies. Step 4. Do you have enough database connections? Even if the way you query your database is perfectly fine, you may still experience inferior database performance. If this is your situation, it’s time to check that your application’s database connection is correctly sized.When configuring a connection pool there are two things to consider:What is the maximum number of connections the database can handle? What is the correct size connection pool required for your application?Why shouldn’t you just set the connection pool size to the maximum? Because your application may not be the only client that’s connected to the database. If your application takes up all the connections, the database server won’t be able to perform as expected. However if your application is the only client connected to the database, then go for it! How to find out the maximum number of connections You already confirmed in Step #1 that your database server is healthy. The maximum number of connections to the database is a function of the resources on the database. So to find the maximum number of connections, gradually increase load and the number of allowed connections to your database. While doing this, keep an eye on your database server’s metrics. Once they max out—either CPU, memory, or disk performance—you know you’ve reached the limit. If the number of available connections you reach is not enough for your application, then it’s time to consider upgrading your hardware. Determine the correct size for your application’s connection pool The number of allowed concurrent connections to your database is equivalent to the amount of parallel load that your application applies to the database server. There are tools available to help you in determining the correct number here. For Java, you might want to give log4jdbc a try. Increasing load will lead to higher transaction response times, even if your database server is healthy. Measure the transaction response time from end-to-end to see if Connection Acquisition time takes up increasingly more time under heavy load. If it does, then you know that your connection pool is exhausted. If it doesn’t, have another look at your database server’s metrics to determine the maximum number of connections that your database can handle. By the way, a good rule of thumb to keep in mind here is that a connection pool’s size should be constant, not variable. So set the minimum and maximum pool sizes to the same value. Step 5. Don’t forget about the network We tend to forget about the physical constraints faced by our virtualized infrastructure. Nonetheless, there are physical constraints: cables fail and routers break. Unfortunately, the gap between works and doesn’t work usually varies. This is why you should keep an eye on your network metrics. If problems suddenly appear after months or even years of operating flawlessly, chances are that your infrastructure is suffering from a non-virtual, physical problem. Check your routers, check your cables, and check your network interfaces. It’s best to do this as early as possible following the first sign that there may be a problem because this may be the point in time when you can fix a problem before it impacts your business.Very often, over-stressed processes start to drop packets due to depleted resources. Just in case your network issue is not a hardware problem, process level visibility can definitely come in handy in identifying a failing component. Database performance wrap up Databases are sophisticated applications that are not built for bad performance or failure. Make sure your databases are securely hosted and resourced so that they can perform at their best. Here’s what you’ll need to optimize your database:Server data to check host health Hypervisor and virtual machine metrics to ensure that your virtualization is okay Application data to optimize database access Network data to analyze the network impact of database communication.There are many tools that can provide you with this information. I used ruxit for my examples here because it provides all the data I need in a single tool. Though, obviously, I am a bit biased. This post is sponsored via Syndicate Ads. ...
software-development-2-logo

Refactoring to Allow Test Doubles

Sometimes, when you make a class, it directly instantiates an object to use in its methods. For example:                   public void myFunc() { MyType object = new MyType(); object.doSomething(); this.thingy = object.getSomething(); } This is generally viewed as bad, since you’re tightly coupling your class to the instantiated one. “But,” you say, “I know that I will never use any other class, and I certainly don’t want users of the class to be supplying alternatives to use.” These concerns are mostly valid, but they leave out a very important thing to pay attention to: testing. You should be able to replace that object with a test double (often mistakenly called mocks; mocks are a specific type of double), for all the usual reasons for having doubles. But, as is, you can’t replace it. Doing so would allow all users of my class to do it too, wouldn’t it? What if I told you that you could have your cake and eat it too? (such a strange phrase…) Well, you can, and I’ll give you a nutshell explanation about how, then go into the details. Keep in mind, it doesn’t require any sort of annotations or DI frameworks (I’m not a big fan of trusting “magic” to do what I should be doing; I have nothing against those who do, but I just don’t like doing it). The Nutshell Assuming you’re doing your tests the typical way of having them in the same package as what they’re testing but in a different directory, you can actually very easily set something up to replace your “unchangeable” object with a test double. All you need is a package-private (default access) way to supply the class with the double and a private way to access it. Then you can use the package-private calls in your tests to supply the class with the test double. There are a few ways to do each part of it, so I’ll dig into that. Suppliers I can think of three different ways to tell the object being tested what double to use, and it turns out that they’re exactly the same three basic ways of doing typical dependency injection:Constructor Setter (aka Mutator) FieldYou may notice that I used numbers instead of bullet points. This is because I consider some to be superior to others. You should consider each method in the order that they appear. Constructor Injection Make a package-private constructor on your class that accepts the normal parameters, plus the test double. Then your existing constructor(s) and/or static factory method(s) can delegate to that constructor with the default object. This is often the best option, especially for immutable types. By passing it in through the constructor, the object will not need to change, which immutable types aren’t supposed to do. Granted, passing it in later doesn’t break the class’ effective immutability, since the changes you are applying aren’t possible in the production code, but it removes the “awesome side benefit” that I mention at the end of the article. Using the constructor also reduces the number of lines required in your tests, since it is a line that you’re already going to be typing. The only real downside to constructor injection is that it doesn’t allow the ability to change out the test double without creating a new object. This is rarely a problem, though, since you usually don’t need more than one per test, and each test should be creating a new instance to ensure test independence. Setter Injection Make a package-private setter method that the test can call to set a field to the test double. The constructor sets the field to a default or null (the technique for accessing the test double can test for null and use the default if it is). This isn’t a horrible option, but, as stated above, is definitely not ideal for immutable classes. The best part of it is its obviousness. Seeing the setter being called makes it clearer about what the test double is doing there, but not usually a lot clearer. Its other benefit, as the previous section states, is the ability to change the double out without creating a new instance of this class. Again, this isn’t all that helpful, really. Field Injection This is done by making the field that stores the double package-private and directly assigning the double to it. You pretty much shouldn’t do this, for the same reasons you don’t make fields public. You may think that it’s harmless to do this, since it’s only for testing, but it removes the “awesome side benefit” at the end of the article. Technically, it’s an option that works, but that’s the only reason I even bothered to include it in the article. It’s bad design; avoid it at all costs. Please. Accessors The accessors are almost always private. This is usually because we didn’t even want them until we started to refactor our code to use the test doubles. I can only think of two types of accessors, which are mirrors of the suppliers. Since you can’t do a mirror of the constructor, there are only two:Getter FieldAgain, the two are in the preferred order, although the difference between how much I prefer one over the other is significantly less. Getter Access Make a private getter method that returns the test double or the default object, which any code that originally used the default object can call to get their object. Truth be told, I find very little benefit to using a getter over direct field access. The biggest help it provides is when you have the field set to null to signify to use the default, which, in itself, is not usually the best design, since a null check is slower than straight access. There is a time where this might not be the case, which is brought up in the section, Instances and Factories. Field Access Just use the private field when you need to use the double or the default. It’s really simple. This is okay as access largely because it’s only happening within the class, which is allowed to use its own implementation details. Overload Wrapping or “Hidden Call Injection” This technique ignores the idea of using package-private suppliers and private accessors and works in a very different way, not even needing the addition of a field to the class. It’s especially useful if only a single method uses the object that needs a double (though, that situation might suggest that your class is breaking the SRP). The technique involves overloading the method you want to test with a package-private method that accepts the dependency as a parameter. You then move all the logic from the original into the overload, replacing the locked-in dependency with the one passed in by the parameter. Then the original method simply calls the new overload and passes in the original object. For example, you can turn this public void myFunc() { MyType object = new MyType(); object.doSomething(); this.thingy = object.getSomething(); } into this public void myFunc() { MyType object = new MyType(); myFunc(object); }void myFunc(MyType object) { object.doSomething(); this.thingy = object.getSomething(); } Now you can pass in test doubles and isolate the functionality of myFunc(). Instances and Factories There is one thing you’ll have to watch out for when refactoring like this: how often new instances are needed. If you need a new instance of the depended-on object every time you run a function, then all suppliers need to pass in a factory for creating the object instead of instances of the object. With overload wrapping, you can usually pass in single instances, unless the individual method itself makes multiple copies of the object. If you haven’t read it yet, I wrote a post a little bit ago about making simple functional factories in Java and Python. Test the Defaults Don’t forget: you still need to test whether the it works with your default instance, too. If it runs slowly, I’d put it into your integration tests. Disappointing Side Effect Your tests are supposed to be living documentation about how your class can be used. Using these techniques, unfortunately, teaches the reader about ways that aren’t actually available to them. Maybe, just maybe, you should consider not being so stubborn about what specific class is used inside? It’s totally up to you; I was just providing a disclaimer (and a hint :) ). Awesome Side Benefit? One really cool side-effect of refactoring like this is the fact that, if you ever change your mind and want to allow your code users to inject their own versions of the dependency, all you need to do is set your suppliers and overloads to public. In fact, you can take this entire article and replace every instance of “package-private” with “public” to make it a general article about providing dependency injection.Reference: Refactoring to Allow Test Doubles from our JCG partner Jacob Zimmerman at the Programming Ideas With Jake blog....
Java Code Geeks and all content copyright © 2010-2015, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.

THANK YOU!

Close