RMI Unpluged

I've just finished tuning a client's application where one of the items on the table was to find the source of calls to System.gc(). Using Censum made easy work of understanding the source of the calls. The team I was working with not only missed that these calls to System.gc() where creating havoc with their end users experience, they didn't even realize that something, some where was messing things up! It's not to say that developers are completely oblivious to the issue. Developers have gotten better about not placing calls to System.gc() in their code, but they often still don't see the call being made in their GC logs. One of the confusing causes of unwanted calls to System.gc() comes from Java (typically Java EE) applications that have remote objects, and therefore use RMI. In the early days these calls came into applications at the rate of 1 a minute and as you can imagine, it caused a lot of consternation for those analyzing the performance of Java EE applications making use of Session or Entity beans. After much discussion, the call rate was reduced to the current rate of once an hour. Better but it can still be disruptive as much as it can be useful. Lets expose a little bit of how the JVM works by digging into how RMI plays with the Garbage Collectors. The Remote Procedure Call (RPC) protocol (originally written in C) allowed one process to call an exposed function in another process. The function in the other process was expected to manage all of it’s resourses on it own. For example, if it allocated memory, it was responsible for freeing it. The only piece of management that relied on the “client” doing the right thing was to shutdown the connection. Even then, a broken socket would cause the RPC library to close down the connection on its own. Move forward and we can see that the RPC style of removing is re-implemented in Java with RMI and CORBA. Together, these protocols expose classes that you can instantiate and interact with, in a remote JVM. Without getting in too deeply into how all this works one can quickly see that this leaves us with a problem. In Java, all objects that are unreachable will be garbage collected. For a remote JVM to access an object in our heap we must hold a pointer to that object in the remote JVM's behalf. This implies that to clean up, the remote JVM has to some how signal when it's finished with the remote object. Given the nature of the resources needed to make all this work, the implementors of RMI decided that they should force a call to a collection of tenured space on a regular basis. In practical terms this means, RMI makes regular calls to System.gc(). If you look deep inside RMI you’ll run across the class ObjectTable. That class is responsible for retaining the roots of all objects that support a remote call. All of the objects added to this table are wrapped in a WeakReference. Further more, ObjectTable manages it's own = l) {                        /* Do a full collection.  There is a remote possibility                         * that a full collection will occurr between the time                         * we sample the inspection age and the time the GC                         * actually starts, but this is sufficiently unlikely                         * that it doesn't seem worth the more expensive JVM                         * interface that would be required.                         */                        System.gc();                        d = 0;                    }                    /* Wait for the latency period to expire,                     * or for notification that the period has changed                     */                    try {                        lock.wait(l - d);                    } catch (InterruptedException x) {                        continue;                    }                }            }        } The default value for latencyTarget is 3600000ms. Oddly enough, you can override this by setting your own latency target in code as follows.     public static void main(String[] args) throws Throwable {        System.out.println( “latency target: “ + GC.currentLatencyTarget());        System.out.println("turn on GC");        LatencyRequest request = GC.requestLatency( 1000);        System.out.println( “latency target: “ GC.currentLatencyTarget());        Thread.sleep(6000);        System.out.println("turn off GC");        request.cancel();        Thread.sleep( 6000);    } If you run this code with the flags -verbose:gc and -XX:+PrintGCDetails, you will see a call to System.gc() made once a second for 6 seconds. The output you should see will look something like; latency target: 0turn on GClatency target: 1000[GC (System.gc())  5243K->792K(251392K), 0.0010124 secs][Full GC (System.gc())  792K->582K(251392K), 0.0045390 secs][GC (System.gc())  3203K->678K(251392K), 0.0006147 secs][Full GC (System.gc())  678K->571K(251392K), 0.0108860 secs][GC (System.gc())  1882K->571K(251392K), 0.0006402 secs][Full GC (System.gc())  571K->568K(251392K), 0.0060488 secs][GC (System.gc())  568K->568K(251392K), 0.0003195 secs][Full GC (System.gc())  568K->568K(251392K), 0.0018367 secs][GC (System.gc())  568K->568K(251392K), 0.0005905 secs][Full GC (System.gc())  568K->568K(251392K), 0.0028363 secs][GC (System.gc())  568K->568K(251392K), 0.0003654 secs][Full GC (System.gc())  568K->568K(251392K), 0.0018081 secs]turn off GC If ObjectTable is becomes empty, it will reset the GC latency to 0 which will overwrite your settings and turn off the GC::run method. If another RMI request is made, the target latency will be set to the preset value for RMI. This implies that any settings we make in code are subject to change at any time. A safer way to set the GC latency for RMI is to set the system properties sun.rmi.dgc.client.gcInterval and sun.rmi.dgc.server.gcInterval. Generally I don’t find these extraneous calls to System.gc() to be useful so I often tune down the values to as much as Long.MAX_LONG milliseconds. However, if you are using RMI and tenured is never collected, it’s likely that you want to schedule a Full collection simply to recycle things like file descriptors. File descriptors in particular a special as they are processed with finalization, which means a full GC must run in order for these objects to be inserted into the finalization ReferenceQueue. Final note, there are other sources of JDK internal calls to System.gc(). These include: * Use of FileChannel.map * Use of ByteBuffer.allocateDirect(). The later will make the call if reference processing isn’t keeping up and you are hitting MaxDirectMemorySize. Yet Another Final Note, Yes, I know the Java API spec says that a JVM can ignore calls to System.gc() if it so chooses to. The reality is, in OpenJDK all calls to System.gc() are honoured unless -XX:+DisableExplicityGC is set on the command line. If not, the calls are synchronized resulting in all of the calls being stacked up all running one right after the other.... I have an expercise in my performance tuning workshop that does just this and believe me, it messes things up very badly. People are always looking at me very badly when they finally sort out what is happening. But then, if they were to use Censum. they'd see the problem in seconds! In a note from Charlie Hunt... he kindly pointed out that I forgot to mention that using -XX:+ExplicitGCInvokesConcurrent is an option for CMS and G1 to avoid the single threaded Full GC that typically is triggered with a System.gc() is called. Thanks for reminding me Charlie.

Posted by on 27 January 2015 | 10:44 am

Algebraic API Design

By Debasish Ghosh, Functional and Reactive Domain Modeling Save 40% on Functional and Reactive Domain Modeling with discount code jn15frdm at manning.com. One of the most important aspects of domain model API design is the specification of the API itself. The specification should be concise, clear and easily understandable by the client. While using object oriented techniques we use interfaces as the contract for API design. Interface based development is one of the primary techniques that’s used to decouple contract of an API from its implementation. When using functional programming with types, we can use algebra as a technique for specification and evolution of an API. By algebra we mean the term in the mathematical sense. In mathematics, an algebra is defined as a triplet ­: a set of objects, a set of morphisms and a set of axioms Similarly when an API in a typed functional language can be specified using a set of types a set of functions that work on those types and a set of laws that the functions must honor (typically the domain rules) We can use algebra not only to specify an API but also to evolve a set of related APIs. In functional programming, we use composition to build larger abstractions out of smaller ones. And composition is all about aligning types. Suppose we have a function that takes a customer account number, does some processing and returns the account balance if it’s a valid account number. We can specify this as the following algebra: def getBalance(accountNo: String): Option[Balance] Note we return a type Option since there’s a chance that the account number lookup can fail in case it’s an invalid one. Note we have just specified the types and named an operation for the API. We have no idea how the types or the function will be implemented. But to the client the API specification makes complete sense. Once we have the Balance, we need to do some computation, maybe calculate the interest on it and post it in some books. Here we can generate a Posting record, which will be transferred to books later. This can be specified by the following algebra: def post(balance: Balance): Option[Posting] And then we can write this Posting in some journals and books using the following function: def writeToBooks(p: Posting): Option[Unit] Without knowing anything about the implementation of the above functions or the participating types, we can compose the above steps as a larger workflow for our banking domain model: def journalize(no: String) = for {   b

Posted by on 26 January 2015 | 8:28 am

If Flipper extends Flapper, Slapper implements Slipper, and Flipper extends Slipper, is Flipper a class or an interface?

By Mala Gupta, OCP Java SE 7 Programmer II Certification Guide Save 40% on OCP Java SE 7 Programmer II Certification Guide with discount code jn15ocp at manning.com. You’ll be amazed at how easily you can identify and implement IS-A and HAS-A relationships between classes and objects, if you remember one simple rule—follow the literal meaning of these terms: 1. IS-A—This relationship is implemented when: A class extends another class (derived-class IS-A base-class). An interface extends another interface (derived interface IS-A baseinterface). A class implements an interface (class IS-A implemented interface). 2. HAS-A—This relationship is implemented by defining an instance variable. If a class— say, MyClass—defines an instance variable of another class—say, YourClass—MyClass HAS-A YourClass. If MyClass defines an instance variable of an interface—say, YourInterface—YourClass HAS-A YourInterface. EXAM TIP Representing IS-A and HAS-A relationships by using (quick) UML diagrams can help you on the exam. Though you may not see UML diagrams on the exam, creating quick UML diagrams on an erasable board (or something similar) provided to you during the exam will help you answer these questions. The exam will test whether you can identify and implement these relationships in your code, so let’s start with an example of an IS-A relationship. Identifying and implementing an IS-A relationship An IS-A relationship is implemented by extending classes or interfaces and implementing interfaces. Traverse the inheritance tree up the hierarchy to identify this relationship. A derived class IS-A type of its base class and its implemented interfaces. A derived interface IS-A type of its base interface. The reverse isn’t true; a base class or interface is not a type of its derived class or interface. Here’s a simple but long example for you to read and comprehend: interface Movable {}interface Hunter extends Movable {}class Animal implements Movable {}class Herbivore extends Animal {}class Carnivore extends Animal implements Hunter {}class Cow extends Herbivore {}class Goat extends Herbivore {}class Lion extends Carnivore {}class Tiger extends Carnivore {} Which of the following options do you think are correct? Cow IS-A Hunter. Tiger IS-A Herbivore. Cow IS-A Movable. Animal IS-A Herbivore. To answer this question, refer to the preceding code, and you’ll notice that interface Hunter is implemented only by class Carnivore. The class Cow doesn’t extend class Carnivore. So, Cow IS-A Hunter is incorrect. Similarly, you can refer to the preceding code to answer all the other options. Option 2 is incorrect because class Tiger doesn’t extend class Herbivore. Option 3 is correct because interface Movable is implemented by class Animal, which is the base class of Herbivore, extended by class Cow. Option 4 is incorrect because you can’t traverse the hierarchy tree down to determine an IS-A relationship. Evaluate it like this– A Herbivore IS-A type of Animal with some additions or modifications because a Herbivore can modify (override) methods of class Animal and add new ones. But Animal IS-NOT-A Herbivore. Animal can also be Carnivore. Phew! So we had to refer to the code multiple times to answer each option. How about representing the relationships between these classes and interfaces by using UML notation, as shown in figure 1? Figure 1 A UML representation can help answer questions about IS-A relationships between classes and interfaces. If you can traverse up, from a derived class or interface to a base class or interface, following the connecting arrows (lined or dashed), the derived entity shares an IS-A relationship with the base entity. If you think that the preceding figure seems to depict a rather polished form of a class-and-interface relationship, look at figure 2, which shows the same relationship in a rather raw form. Figure 2 A rather raw form of the UML diagram that you may draw on an erasable board while taking your exam to represent an IS-A relationship between classes and interfaces. I understand that you may not have the time or patience to draw neat diagrams during the exam because of time constraints or space available to you on an erasable board. The main point to remember is to use correct connecting lines to connect two types. Use an arrow to show IS-A relationship and a line to show HAS-A relationship. When I attempted this exam, I drew similar not-so-good-looking diagrams. Believe me, they helped me answer questions quickly, without referring to the code again and again. Also, the questions on the exam may not use names that indicate an obvious relationship between classes and interfaces. The next “Twist in the Tale” exercise will ensure that you get the hang of this point. Twist in the Tale 2 Let’s modify the code used in this example as follows: interface InterH {}interface SameY extends InterH {}class JamD implements InterH {}class SunP extends JamD {}class BreaU extends JamD implements SameY {} Your task is to identify which of the following statements are true: a) SunP IS-A InterH.b) JamD IS-A SameY.c) InterH IS-A InterH.d) SameY IS-A JamD. First attempt the exercise without drawing a UML diagram, and then by drawing and using a UML diagram. Do you think using the UML diagram helps you answer the questions quicker? EXAM TIP The key to finding the types that participate in an IS-A relationship is to find your way, up the hierarchy tree, in the direction of the arrows. This technique will not only help you with the exam, but also go a long way in your professional career. IMPLEMENTING AN IS-A RELATIONSHIP You can implement an IS-A relationship by extending classes or interfaces, or by implementing interfaces. Here is a quick set of rules for implementing inheritance between classes and interfaces in code: A class inherits another class by using the keyword extends. A class implements an interface by using the keyword implements. An interface inherits another interface by using the keyword extends. How will you implement the following relationship in code? Herbivore IS-A Animal Because you don’t know whether either Herbivore or Animal refers to a class or an interface, you have the following possibilities: Herbivore and Animal are classes. Herbivore extends Animal. Herbivore and Animal are interfaces. Herbivore extends Animal. Herbivore is a class, and Animal is an interface. Herbivore implements Animal. Figure 3 shows these three possible implementations. Figure 3 How to implement an IS-A relationship, if you don’t know whether the relationship is between classes, interfaces, or both. Now, let’s add another relationship to the previous one. How would you implement the following relationship and rules in code? Herbivore IS-A Animal. Carnivore IS-A Animal. Animal can define only abstract methods and constants. The third rules makes it clear that Animal is an interface. But you still don’t know whether Herbivore or Carnivore are classes or interfaces. So you can have the following possibilities: Herbivore and Carnivore are interfaces that extend interface Animal. Herbivore and Carnivore are classes that implement interface Animal. Herbivore is a class that implements interface Animal. Carnivore is an interface that extends interface Animal. Herbivore is an interface that extends interface Animal. Carnivore is a class that implements interface Animal. These relationships can be implemented as shown in figure 4. Figure 4 How to implement an IS-A relationship between three entities, one of which is an interface The exam may specify a similar set of rules and ask you to choose the code that you think correctly implements the specified conditions. Let’s work through another set of rules and implement the relationships in code. How would you implement the following relationships and rules in code? Abc IS-A Xyz. Abc defines methods and instance variables. Xyz can declare only abstract methods. Xyz IS-A Lmn. Rule 2 states that Abc is a class, because an interface can’t define instance variables. Rule 3 states that Xyz is an interface, because a class can declare both abstract and nonabstract methods. When you go up the hierarchy tree of an interface, you can find only another interface. In other words, Lmn is also an interface. The preceding rules evaluate to the following: Abc is a class. Xyz and Lmn are interfaces. Abc implements Xyz. Xyz extends Lmn. After the evaluation, these rules seem simple to implement. Figure 5 shows the relationships in UML notation and in code. Figure 5 Implementing a set of rules and an IS-A relationship between three entities: two interfaces, and a class When a class defines an instance variable of another class, they share a HAS-A relationship, covered in the next section. Identifying and implementing a HAS-A relationship As compared to an IS-A relationship, a HAS-A relationship is easy to identify and implement. I hope this statement relieves you! Consider this definition of the bare-bones class Engine: class Engine {} Which of the following classes (Statistics, Car, PartsFactory, TestCar) do you think shares a HAS-A relationship with class Engine? class Statistics { static Engine engine; #A}class Car { Engine engine; #B}class PartsFactory { Object createEngine() { Engine engine = new Engine(); #C //.. code return engine; }}class TestCar { boolean testEngine(Engine engine) { #D //.. code }} #A Statistics defines class variable of type Engine #B Car defines instance variable of type Engine #C PartsFactory defines local variable of type Engine #D TestCar defines method parameter of type Engine Of all the preceding classes—Statistics, Car, PartsFactory, and TestCar—only Car shares a HAS-A relationship with the class Engine because Car defines an instance variable of type Engine. Note that it doesn’t matter whether the instance variable engine in class Car is initialized with an object. The HAS-A relationship is shared by the classes. EXAM TIP Class and interfaces can share a HAS-A relationship with each other. If a class or interface—say, Type1—defines an instance variable of class or interface—say, Type2, Type1 HAS-A Type2 is correct. The reverse isn’t correct. Also, the HAS-A relationship is shared by classes, and so the relationship is not affected, whether the instance variable is initialized or not. AttachmentSize Fig1OCP.jpg38.59 KB fig2OCP.jpg18.52 KB fig3OCP.jpg45.71 KB fig4OCP.jpg43.63 KB fig5OCP.jpg16.17 KB

Posted by on 24 January 2015 | 3:49 pm

What if your logs were in JSON?

Bunyan is a NodeJS library that rethinks logging in some really useful ways. I wrote a Java port you can use in your applications. In particular, with Bunyan, logs are JSON - and Bunyan comes with a great filtering and analysis tool. The Java port uses some innovative techniques to make logging simple and foolproof - in particular, a use of AutoCloseable to make a logging code simple and foolproof. A walkthrough on my real blog on timboudreau.com.

Posted by on 18 January 2015 | 8:43 pm

Congratulations - you're a (horrible) mobile developer! from Apache Cordova in Action by Raymond Camden

Save 40% on Apache Cordova in Action with discount code jn15acia at manning.com Ok, that may be just a tiny bit over the top, but most likely there is a bit of truth to it as well. You know how to install Cordova, how to generate native binaries from HTML, and how to make use of fancy device features with plugins. That’s all fairly straightforward: Install a SDK, install the command line tool, write some HTML, and whammo, see it on your device. But that doesn’t mean you know how to create a good mobile application. Taste is subjective. While it is difficult to precisely describe what makes a good mobile application, there are definitely a set of guidelines that help define what a successful mobile application looks like. And notice I'm not saying a successful hybrid mobile application. Your users don't care what you used to build your application. They only care about the end result. Therefore the guidelines for a good hybrid mobile application are going to be same as a good 100% native built mobile application as well. A good mobile application is readable on a variety of form factors. Whether opened in an iPhone 5 or some enormous Android phablet, text should be readable and buttons easy to click with fat fingers. A good mobile application demonstrates these features: It has a simple, easily understandable user interface. By using common design idioms (a shopping cart icon for example) users have a better idea of what to expect when using your application. It performs well with little to no noticeable lag. It works in a variety of network conditions (both off and online). A Good Example of Bad UI Imagine the most simple application possible - an application that prompts you for your name and then simply tells you hello. Figure 1 is a mock-up of the UI for the application, both the initial view and what is displayed after entering a name. Figure 1 Our simple little application. Looks pretty now, right? Building this application would be rather trivial. You should create a new Cordova application if you want to test this. The source code is available in the zip downloaded from the Manning web site. You will find it in the c5/simple folder. Listing 1 represents the HTML used for the application. Listing 1 Simple application HTML (simple/www/index.html) Simple App Enter your name    #1     #2          #3                               #4   #1 Label used to prompt for your name. #2 Input field where the user enters their name. #3 Button used to submit the form. #4 Empty div that will be filled with the user's name. There isn't anything particularly interesting about this code, but note the lack of any styling via an embedded or included CSS file. That's totally OK - you don't have to style anything, but as you can probably guess, this is going to bite us in the rear in a few moments. Now look at the JavaScript in listing 2. Listing 2 Simple application JavaScript (simple/www/js/app.js) document.addEventListener("deviceready", init, false); function init() { document.querySelector("#nameForm").addEventListener("submit",  function(e) { e.preventDefault(); var name = document.querySelector("#name").value;  var msg = "Hello, "+name; document.querySelector("#result").innerText = msg; }, false); } So far so good. Since our application has one feature (get the name and display it), the code is trivial to the point of being pointless. To be clear, this is not something you want to use Cordova for, but it will be very useful in demonstrating the type of design issues you're going to be running into when building hybrid applications. Let's fire up the application and send it to an Android device to see how beautiful it looks. Figure 2 Our simple application is displayed in Android

Posted by on 18 January 2015 | 11:04 am

JSF 2.3 Using a CDI managed Validator

Just like the previous blog entry "JSF 2.3 Using a CDI managed Converter" you can now do the same thing with Validators. So how does that look in code?   @FacesValidator(value = "myValidator", managed = true)  public class MyValidator implements Validator {     @Inject     MyModel model;    ..  } Note in this example the Validator would be a @RequestScoped bean as we did not state what CDI scope needs to manage it. You can use any other scope available to CDI. Beneath the covers we do not save the actual Validator instance into the view state, but we save the value "myValidator" so upon state restore we can ask CDI for the instance. And since we now have CDI managing the Validator you can also do @Inject into the Validator. Enjoy!

Posted by on 16 January 2015 | 1:38 pm

JavaLand 2015 Conference Picks

JavaLand 2015 Conference Picks With only 44 business days to go until JavaLand 2015, I’d like to share my conference picks. I’m including my sessions for completeness, and naturally I recommend you attend them, but I’ll also include an alternate that I’d attend if I wasn’t speaking at that time. Tuesday, 24 March 2015 0900, Wintergarden, Welcome Keynote: 20 Years of Java I like to attend the plenary sessions of a conference if they are at all interesting, and Oracle Java engineer Marcus Lagergren’s looks great. It will be on the big stage. This year I’m celebrating my own 20 year anniversary with Java, since I was present at the German debut of Java at the The Third International World-Wide Web Conference in Darmstadt, Germany in April 1995. I vividly remember someone (Arthur van Hoff I think) typing, as root rm -rf /*, at the end of the demo on a Sun UNIX workstation. What flair! 1000, Schauspielhaus, Praktisches API-Design Dieser Vortrag wird auf Deutsch gegeben, aber trotzdem empfehle sie ich weil das Thema nebem meinem Hertz liegt. Hopefully I’ll get some tips for design in JSF and Servlet. 1200, Quantum 1, Java EE 7 from an HTML5 Perspective: WebSocket, JSON, & JSF This is my first session, and it is an overview of JavaEE 7 from the perspective of technologies useful to those developing JavaEE 7 backed apps with HTML5 user interfaces. If I wasn’t speaking myself, I’d attend my pal Anton Epple’s 1200, Quantum 2, Wie programmiert man JavaScript in Java. 1300, Schauspielhaus, The (not so) Dark Art of Performance Tuning My good friend Kirk Pepperdine is a global expert in this topic, and a great and entertaining speaker as well. 1400, Wintergarden, JBatch mit Apache BatchEE Batch is one of those unglamorous yet essential technologies, and also one with a very vibrant JCP community. I remember meeting Michael Minella of Spring Batch at DevNexus 2014 and he was so excited about passing the TCK. The session speaker, Mark Struberg, is a tech titan and one of the sharpest guys I’ve had the pleasure of working with. He’s also a great speaker. 1500, Wintergarden, Where Are We At with MVC in Java EE 8 I work very closely with my co-spec lead on JSF, Manfred Riem, so I’m biased, but this session is sure to be great. MVC is one of the most talked about technologies in Java EE 8. 1600, Quantum 4, Confessions of an Automation Addict I’m a bit of an automation addict myself, but the horse I picked to ride has fallen out of favor. Nonetheless, I still use it heavily. 1700, Schauspielhaus, Speed up Your Java by Turning it into Binary John is a great speaker and industry veteran, and this talk has a provocative topic, so it is sure to be worthwhile. One unique aspect of this conference is its location: a top-tier amusmement park. Think of it as a smaller mashup of Disney’s Epcot and Magic Kingdom, with German sensibilities. After the first day of the conference, some of the rides will be open to conference attendees. My favorite was Winja’s force. This is a relatively mellow roller coaster with a twist, literally. The car you sit in can rotate as it glides along the rails. Wednesday, 25 March 2015 0900, Quantum 3, Developing Native Mobile Apps Using JavaScript This is a bit outside of my bailiwick, but my friend Hazem Saleh is a great speaker and strong proponet of Open Source. He’s also a JSF Expert Group member. 1000, Schauspielhaus, HTTP 2.0 Comes to Java EE This is my second session, and I’ll explain what’s in store for Servlet 4.0, with a special view towards HTTP/2. If I wasn’t speaking, I’d definitely attend Sven Peters’s Coding Culture session in Wintergarden. First off, Atlassian makes much better products than GitHub. Second, Sven is an excellent speaker, and third the talk is likely to be keynote worthy. I’m not glad to be up against him in the schedule. 1100, Wintergarden, Enterprise and Internet of Things The Tuesday plenary is by Dr. Mark Little, who is doing a great job driving Java EE forward at JBoss. I normally don’t go in for IoT sessions, but Mark is sure to make it interesting. 1300, Schauspielhaus, Java EE Security: Let’s Make Something Useful David Blevins is a strong community voice for improving Java EE, and security is one of the most challenging areas to improve. You can tell it’s hard just by how long it’s taken for the community to get up enough steam to tackle it in a proper JSR. Well, we have one now: JSR-375, and David will tell us how we can make the most of it. 1400, Quantum 4, Productive, Effective Development? You Weak Minded fool! Simon Maple has done a great job building the Virtual JUG into a force for good in the Java Community. He is well positioned to deliver this kind of talk thanks to his role at ZeroTurnaround. 1500, Quantum 1, Softwarequalität steigern This appears to be a survey talk about how to effectively use some popular tools in practice to improve software quality. I’ve never seen Andreas G¨nzel talk, but the topic is interesting to me. 1600, Quantum 4, Puppet für Entwickler Now that Docker is all the rage, I’ll be interested to see what’s new with Puppet, or at least learn how these two popular sysadmin technologies relate to eachother. As with the previous talk, I’ve not seen Sebastian Hempel speak before this. Thursday, 26 March 2015 As mentioned in my previous entry, Oliver Szymanski and I are presenting an entry in the training day: Java EE 7 from an HTML5 Perspective. JavaLand was great fun and very professionally enriching last year. This year promises to be even more so. I hope to see you there! AttachmentSize big-room.jpg165.57 KB schauspielhaus.jpg145.3 KB winjas-force.jpg176.23 KB

Posted by on 16 January 2015 | 6:12 am

Introduction to Graphs from Grokking Algorithms by Aditya Y. Bhargava

By Aditya Y. Bhargava, author of Highlighted text Grokking Algorithms Save 40% on Grokking Algorithms with discount code jn15ga at manning.com. Suppose you are in San Francisco, and you want to go from Twin Peaks to the Golden Gate bridge. You want to get there by bus, in the minimum number of transfers. Here are your options: What’s your algorithm to find the path with the least number of steps? Well, can you get there in one step? Here are all the places you can get to in one step: The bridge is not highlighted, you can’t get there in one step. Can you get there in two steps? Again, the bridge isn’t there, so we can’t get to the bridge in two steps. What about three steps? Aha! Now the Golden Gate bridge shows up. So it takes three steps to get from Twin Peaks to the bridge using this route: There are other routes that will get you to the bridge too, but they are longer (4 steps). Our algorithm found that the shortest route to the bridge is three steps long. This type of problem is called a "shortest path" problem. You are always trying to find the shortest *something*. It could be the shortest route to your friend’s house. It could be the shortest number of moves to checkmate in a game of chess. The algorithm to solve a "shortest path" problem is called breadth-first search. To figure out how to get from Twin Peaks to the Golden Gate bridge, there were two steps: Model the problem as a graph. Solve the problem using breadth-first search. I’ll cover what graphs are. A graph models a set of connections. For example, suppose you and your friends are playing poker, and you want to model who owes whom money. Here’s how you could say "Alex owes Rama money": The full graph could look something like this: (Graph of people who owe other people poker money) Alex owes Rama money, Tom owes Adit money, and so on. Each graph is made up of nodes and edges: That’s all there is to it! Graphs are made up of nodes and edges. A node can be directly connected to many other nodes. Those nodes are called its neighbors. In neighbors this graph, Rama is Alex’s neighbor. Adit is not Alex’s neighbor, because they are not directly connected. But Adit is Rama’s and Tom’s neighbor. Graphs are a way to model how different things are connected to one another. AttachmentSize fig1.png18.07 KB fig2.png11.47 KB fig3.png10.54 KB fig4.png11.81 KB fig5.png10.52 KB fig6.png3.02 KB fig7.png6.32 KB fig8.png3.68 KB

Posted by on 15 January 2015 | 7:18 pm

Thinking about the future: What are your goals? from Soft Skills by John Somnez

By John Sonmez, Soft Skills: The software developer's life manual Save 40% on Soft Skills: The software developer's life manual with discount code jn15ss at manning.com. Now that you’re thinking about your software development career as a business, it’s time to start defining the goals you have for this business. Not everyone is alike. You might have a very different set of goals for your career than I do, but if you’re ever going to achieve any of those goals, you have to know what they are. This is, of course, easier said than done. I’ve found that most people, software developers included, drift through life without really having a concrete realization of what their goals are or what they’re trying to accomplish in life. This is the natural state of most human beings. We don’t tend to really give enough thought to what to focus on and as a result our steps lack purpose or direction. Think about sailing a ship across the ocean. You can get into a ship and raise your sails, like most people do. But if you don’t have a clear destination picked out and you don’t take steps to steer the ship in that direction, you’ll just drift aimlessly at sea. Perhaps you’ll end up sailing your ship by chance to an island or other land mass, but you’ll never really make any solid progress until you define where you want to go. Once you know your destination, you can use all of the tools at your disposal to actively steer the ship in the direction that will take you there. It seems pretty obvious, yet so few software developers ever define goals for their career—why? I can only guess here, but I’d say that most software developers are afraid of committing to a long-term vision for their career. They want to leave all options open to them, because they’re afraid of choosing one path and going down that path. What if it’s the wrong path? What if I don’t like where it takes me? These are scary questions indeed. Some developers just haven’t even really given it much thought at all. Left to our own devices, we tend to just follow the path that’s laid out for us. It’s a much more difficult job to create our own path, so we just don’t do it. Instead, we just take the first job we get an offer for and stay at that job until a better opportunity comes along or we get fired—I mean “laid off.” Whatever your reason may be for not defining goals for your career, now is the time to do it. Not tomorrow, not next week, but right now. Every step you take without a clear direction is a wasted step. Don’t randomly walk through life without a purpose for your career. How to set goals Okay, so now that I’ve convinced you that you need to set goals, how do you do it? It’s easiest to start out with a big goal in mind and then create smaller goals along the way that will help you get to the bigger goal. A big goal is usually not very specific, because it’s hard to define something that’s potentially very far off very clearly. But, that’s okay. You don’t have to be very specific when you define a big, far-off goal. Your big goal just has to be specific enough to give you a clear direction in which to travel. Going back to the ship analogy, if I want to sail to China, I don’t have to know the exact latitude and longitude of the port I want to get to right away. I can get in my ship and start heading in the direction of China, and when I get closer, I can always get more specific. All I need to know to get started out is whether I’m getting closer to China or further from it. So, your big goal should be something not too specific, but clear enough that you can know if you’re steering toward it or not. Think about what you want to ultimately do with your career. Do you want to become a manager or executive at a company? Do you want to go out and start your own software development business some day? Do you want to become an entrepreneur creating your own product and bringing it to market? For me, my goal was always to eventually be able to get out on my own and work for myself. It’s really up to you to define what your big goal is. What do you want to get out of your career? Where would you like to see yourself in 5 or 10 years? Go ahead and spend some time thinking about this—it’s really important. Once you’ve figured out what your big, far-off goal is, the next step is to chart a course to get there by making smaller goals along the way. Sometimes it helps to think backwards from your big goal to your present situation. If you had already achieved your big goal, what would have been some of the milestones along the way? What path could you imagine tracing backwards from your big goal to your present situation? At one time, I had a big goal of losing about 100 pounds of weight. I had let myself get out of shape and I wanted to get back on track. So, I set for myself smaller goals of losing 5 pounds every two weeks. Every two weeks that I was able to reach my smaller goal, it moved me forward toward my big goal. If you can make small goals that gradually move you forward in the direction toward your bigger goals, you’ll eventually reach your destination. It’s important to have various sizes of goals that lead you in the direction of your big goal. For example, you might have a yearly goal of reading so many technical books or learning a new programming language. That yearly goal might be a smaller goal that will lead you toward your bigger goal of becoming a senior-level developer. But that yearly goal might be broken up into smaller goals of reading a single book each month or making some defined amount of progress each day. The smaller goals keep you on track and keep you motivated so that you keep heading in the direction of your bigger goals. If you just set out to accomplish a big goal and don’t have smaller goals along the way, you don’t end up having time to course-correct when you’re off track. Smaller goals also give you frequent rewards that help motivate you. Small victories each day and each week help us feel like we’re making progress and accomplishing things, which makes us feel good about ourselves and helps us keep moving forward. Smaller goals also don’t seem as daunting as a big goal. Consider writing this book. Right now I have a goal for writing so much of this book each day and each week. I’m not trying to tackle the huge goal of writing the entire book, but instead I’m looking at it from the perspective of what my goal is for each day, knowing that by doing what I need to do each day, I’ll eventually reach my big goal of completing the entire book. So, if you haven’t given much time to think about your future and you don’t have at least one clear and definite goal you’re aiming toward, put down this book and define some goals for yourself. It’s not easy, but you’ll be glad you did it. Don’t be a ship floating aimlessly in the ocean. Chart a course before you set sail. Tracking your goals Periodically, you should track and update the goals you have set for yourself—and adjust them if necessary. You don’t want to travel miles off course before you discover your mistake, and you probably don’t want to travel very far down a path that turns out to be the wrong one, either. I’d recommend setting regular intervals for checking up on your goals. This will help you to make adjustments when needed and help keep you accountable. You might want to review the goals you set for each week at the end of that week before you plan out the next week. That same goes for every month, quarter, and even year. It can be very helpful to reflect on what you accomplished during small and large time periods so that you can figure out if you’re making the right amount of progress or you need to make some kind of adjustment. AttachmentSize SoftSkills.jpg16.35 KB

Posted by on 15 January 2015 | 7:02 pm

Using Magnolia with IBM Bluemix

Yay, another video blog post! Since the last one on managing campaigns with a new Magnolia app was so well liked by the audience, I figured I'd give it another try - this time, on a completely different topic, though. In just a couple minutes, I want to show you how easy it is to get Magnolia running with Bluemix - IBM's cloud platform that helps developers rapidly build, manage and run web and mobile applications. Why Bluemix when there's plenty of other clouds? For one, because I don't want to bother with a whole VM, having to take care and update all the infrastructure as soon as the next Heartbleed bug or similar stuff is discovered - or perhaps just because it's dead easy. :) Enjoy!

Posted by on 15 January 2015 | 9:11 am