Featured FREE Whitepapers

What's New Here?


Here Is The Main Reason Why You Suck At Interviews

I’ve talked about interviews from one perspective or another on several occasions, you might even say it is a pet subject of mine. It’s fascinating because most people are no good at interviews and when it comes to developer interviews – well; let’s just say there is a whole new dimension for us to suck at with coding questions, whiteboards and whatnot. Of course, the other side of the equation is not pristine here, the interviewer can be just as much to blame for a terrible interview, either through lack of training, empathy, preparation or a host of other reasons, but that’s a whole separate discussion. So, why are we so bad at interviews? You can probably think of quite a few reasons straight away:it is a high pressure situation, you were nervous you just didn’t “click” with the interviewer you were asked all the “wrong” questions sometimes you just have a bad dayInfact, you can often work yourself into a self-righteous frenzy after a bad interview, thinking how every circumstance seemed to conspire against you, it was beyond your control, there was nothing you could do – hell, you didn’t even want to work for that stupid company anyway! But, deep down, we all know that those excuses are just so much bullshit. The truth is there were many things we could have done, but by the time the interview started it was much too late. I’ll use a story to demonstrate. The least stressful exam I’ve ever had was a computing theory exam in the second year of my computer science degree. I never really got “into it” during the semester, but a few weeks before exam time – for some inexplicable reason – I suddenly found the subject fascinating. I spent hours reading and hours more playing with grammars and automata. Long story short, when exam time rolled around I knew the material backwards – I groked it. There was some anxiety (you can’t eliminate it fully), but I went into the exam reasonably confident I’d blitz it (which I did). Practice and preparation made all the difference. Of course, this is hardly a revelation, everyone knows that if you study and practice you’ll do well (your parents wouldn’t shut up about it for years :)). Interviews are no different from any other skill/subject in this respect, preparation and practice are key. Can You Wing It? The one difference with interviews is that they are an occasional skill, almost meaningless most of the time, but of paramount importance once in a long while. It just doesn’t seem like it’s worth the effort to get good at them, especially if you happen to already have a job at the time (who knows, you may not need those skills for years). There are plenty of other subjects clamouring for your attention and anyway every interview is different, you can never predict what’s gonna happen so it would be stupid to waste your time trying. No – good communication skills and decent software development knowledge will see you through, right? Except, they don’t and it won’t. Sure, you might be able to stave off total disaster, but without preparation and practice, you’re mostly relying on luck. Things “click“; you get asked the “right” questions and are able to think of decent answers just in time. This is how most people get hired. As soon as the process gets a little more rigorous/scientific, so many candidates get weeded out that companies like Google, Facebook, Twitter etc. find themselves trying to steal people from each other since they know that those that have passed the rigorous interview processes of their competitors must be alright. The interesting thing is that the rejected candidates are not necessarily worse; they are often simply a lot less prepared and a little less lucky. Over the last few years presentation skills have seen quite a lot of press. Many a blog post and much literature has come out (e.g. Presentation Zen and Confessions of a Public Speaker are both great books). Many people have decent knowledge of their subject area and have good communication skills, they think they are excellent presenters – they are wrong. They put together some slides in a few hours and think their innate abilities will carry them through, but inevitably their presentations end up disjointed, mistargeted, boring or amateurish. Sometimes they sail through on luck, circumstances conspire and the presentation works, but these situations are not common. Malcolm Gladwell is a master presenter, he is one of the most highly sought after and highly paid speakers in the world (and has written a bunch of awesome books to boot) – this is not by chance. Without doubt he knows his stuff and has better communication skills than the majority of speakers out there and yet all his talks are rigorously prepared for and practiced. To my mind, the situation with interviews is similar to that of presentations, except the deluge of literature about interviews goes almost unnoticed since they are old-hat. The digital world hasn’t changed the interview process too significantly (unlike the public speaking process), except the internet age brings all the old advice together in one place for us and all of that advice is still surprisingly relevant. The Old-School Advice Everyone (and I mean everyone) always says that you should research the company you’ll be interviewing with beforehand. You would think people would have this one down by now, especially developers cause we’re smart, right? Nope, no such luck, just about everyone who rocks up for an interview knows next to nothing about the company they are trying to get a job at, unless the company is famous, in which case people are just full of hearsay. But hearsay is no substitute for a bit of research and it is so easy, I am reminded of an article Shoemoney wrote about getting press (well worth a read by the way, if you’re trying to promote a product/service) – there is a tremendous amount of info you can find out about a person by trawling the web for a bit and it is just as easy to learn something about a company. I mean, we do work in software, so any company you may want to work for should have a web presence and a half. And even if web info is sparse there is your social network or picking up the phone and seeing if someone will trade a coffee for some info. Yeah, you go to a bit of trouble but the fact that you did will be apparent in an interview, I mean, there is a reason why I work where I work and I’d prefer to work with other people who give a shit (everyone would) – you savvy? Of course if you do go to the trouble to find out what skills/tech/knowledge/processes a company is looking for/values you may be able to anticipate where an interview might head, the value there should be self-evident. Which leads me to interview questions. When it comes to developers, there are three types of questions we struggle with/despise:the behavioural/culture fit the coding question the Mount Fuji questionWith a bit of practice you can blitz all of these. The Fujis are the hardest, but even they can be prepared for, but I’ll get back to those shortly. Behavioural Questions The behavioural questions seem annoyingly difficult but are actually the easiest. You know the ones “Give me an example of a time when you demonstrated leadership/communication skills/problem solving/conflict resolution“. It is always the same question, with a different attribute of yours that you have to spruik. Being in essence the same question you can address all of them with what amounts to the same answer, once again substituting a different attribute. These are actually difficult to handle on the spot, but if you have something prepared it is a breeze. Example: “There was a time, when Bill the developer was being an obstinate bastard and wouldn’t buy in to the awesome that the rest of us were peddling, but I took charge of the situation and was able to convince Bill blah, blah ….” – leadership “Bill the contrary developer just wouldn’t agree with the way we were dishing out the awesome, but I took Bill out for coffee and we hashed it out one on one blah, blah …” – communication “There was insufficient awesome to go around and Bill and Joe just couldn’t share it and were coming to blows, but I stepped in and took them both to a whiteboard, we had a long chat blah, blah …” – conflict resolution As long as you think up a situation beforehand you can adapt it to answer any behavioural question, the situation can even be a fictitious, but you do need to think through it carefully for 10-15 minutes to be able to come up with something coherent. You will never have time to frame a coherent reply in the interview itself. Of course, it is best to have a few situations prepared just so you can change it up a bit, variety never hurt anyone. If the company you’re interviewing with is enlightened they won’t ask you these questions, but will instead focus on your dev skills, but there are many companies and few are enlightened, might as well prepare for the worst case and be pleasantly surprised if the best case happens. Coding QuestionsTalking about dev skills, the one thing that just about every company that hires developers will do, would be to ask a coding question at some stage. These usually take the form of a sandbox question or what I call a Uni question. You know the ones, “Reverse a list“, “Implement a linked list” it’s as if they are under the impression you studied computer science at some point, go figure :). People struggle here, because you just don’t come across this kind of question in your day-to-day work. If they asked you to implement a Twitter or Facebook clone, you could really show them your chops, but balancing a binary tree – who the hell remembers how to do that? And that’s the rub, you probably could dredge the information from the depths of your grey matter, but by the time you do the interview will have been long over. Because you don’t do this kind of question daily, you brain has dumped the info you need to tape and sent it to Switzerland (cause backups should be kept off-premises). The answer is simple; you gotta practice these questions well in advance of the interview. Preparation baby, that’s the ticket. Preferably you should be doing them regularly regardless of your employment status cause those questions are fun and bite-sized and give your brain a bit of a workout – you’ll be a better developer for it. The most interesting thing though is this, you do enough of them and you won’t really encounter anything new in an interview. There are really not so many themes when it comes to these questions, it will be the same formulae you’ll just need to plug in different numbers (a simplification but not too far from reality). I really gotta follow my own advice here. If you seriously want a leg up, there are books specifically about this, I prefer Cracking the Coding Interview but there is also Programming Interviews Exposed – read them, do the questions. Puzzles Mount Fuji questions are the most controversial, but regardless of whether you hate them or not, even they can be practiced. Yeah, alright, maybe you’re willing to walk out if any company ever dares to ask you about manhole covers, but I’d much rather answer the questions and then walk out in self-righteous satisfaction rejecting the offers they’ll be throwing at my feet, than storm out in self-righteous anger knowing deep down that I was a wuss for doing so. And anyway, I’d like to think that I’ve already demonstrated that not all Mount Fuji questions are created equal, some are coding problems, others deal with concurrency, others still might be back-of-the-envelope questions (the story of how these originated is actually pretty interesting, I am writing it up as we speak). The subset of questions that are simply a useless puzzle are a lot smaller than you might think. Doing these kinds of questions in your spare time is just another way to build your skills with a side benefit that you become an interview-proof individual. Of course, many people also enjoy an occasional puzzle – I’m just saying. There is still lots more to say, I haven’t even begun to talk about attitude, but this is already a tl;dr candidate, so I’ll leave that discussion for another time. Let’s sum up, if you feel that you suck at interviews, it’s because you didn’t prepare well enough and haven’t had enough practice – it is that simple. As an interviewer it is most disheartening to see an unprepared candidate, there are just so many of them, on the other hand a person who is clearly on the ball is just awesome. And I am well aware that practicing interviews is hard, there is no Toastmasters equivalent for that particular skill, but thorough preparation can significantly mitigate that issue. Even a few minutes of preparation will put you head and shoulders above most other people since the vast majority don’t bother at all. So, take the time to practice/prepare if you have an interview on the horizon, be smart about it and it is bound to pay off, not to mention a better experience for the interviewer as well, more fun and less stress for everyone. Reference: Here Is The Main Reason Why You Suck At Interviews from our JCG partner Alan Skorkin at the Developing in the Google Cloud blog....

Apache Thrift Quickstart Tutorial

Thrift is a cross language RPC framework initially developed at Facebook, now open sourced as an Apache project. This post will describe how to write a thrift service and client in different modes such as blocking, non blocking and asynchronous. (I felt latter two modes are less documented and needed some tutorial type introduction, hence the motivation of this post). To easily follow the tutorial it’s beneficial that you have a basic understanding of Thrift architecture consisting of Transports, Protocols and Processors. (A good paper can be found at [1]). Here I will be using Thrift version 0.7 and Thrift’s Java binding. Thrift Installation Installation instructions can be found at http://wiki.apache.org/thrift/ThriftInstallation. To sum up Ubuntu installation steps. 1. Install required dependencies. $ sudo apt-get install libboost-dev libboost-test-dev libboost-program-options-dev libevent-dev automake libtool flex bison pkg-config g++ libssl-dev 2. Go to the installation root directory. 3. $ ./configure 4. $ make 5. Become super user and    $ make install Now let’s get on with creating the service and consuming it. Service Definition Here a service with simple arithmetic operations is defined. Note the use of typedef directive to declare alternative names for base types i64 and i32. Add following in a file named ‘arithmetic.thrift’. namespace java tutorial.arithmetic.gen // define namespace for java codetypedef i64 long typedef i32 int service ArithmeticService { // defines simple arithmetic service long add(1:int num1, 2:int num2), long multiply(1:int num1, 2:int num2), }Code will be generated under ‘tutorial.arithmetic.gen’ package. Now generate Java code using following command line. $ thrift –gen java arithmetic.thrift The source tutorial.arithmetic.gen.ArithmeticService.java will be generated. Blocking Mode Let’s create a blocking mode server and a client to consume the service. First we need to implement the service using generated service skeleton. The interface to implement is ArithmeticService.Iface. public class ArithmeticServiceImpl implements ArithmeticService.Iface {public long add(int num1, int num2) throws TException { return num1 + num2; }public long multiply(int num1, int num2) throws TException { return num1 * num2; }}Now that being done let’s create the Thrift server which would server request for this service. Remember this is a blocking server so the server threads doing I/O will wait. public class Server {private void start() { try { TServerSocket serverTransport = new TServerSocket(7911);ArithmeticService.Processor processor = new ArithmeticService.Processor(new ArithmeticServiceImpl());TServer server = new TThreadPoolServer(new TThreadPoolServer.Args(serverTransport). processor(processor)); System.out.println("Starting server on port 7911 ..."); server.serve(); } catch (TTransportException e) { e.printStackTrace(); } }public static void main(String[] args) { Server srv = new Server(); srv.start(); }}Here TThreadPoolServer implementation is used which would utilize a thread pool to serve incoming requests. Now let’s write the client. public class ArithmeticClient {private void invoke() { TTransport transport; try { transport = new TSocket("localhost", 7911);TProtocol protocol = new TBinaryProtocol(transport);ArithmeticService.Client client = new ArithmeticService.Client(protocol); transport.open();long addResult = client.add(100, 200); System.out.println("Add result: " + addResult); long multiplyResult = client.multiply(20, 40); System.out.println("Multiply result: " + multiplyResult);transport.close(); } catch (TTransportException e) { e.printStackTrace(); } catch (TException e) { e.printStackTrace(); } }public static void main(String[] args) { ArithmeticClient c = new ArithmeticClient(); c.invoke();} }TBinaryProtocol is used for encoding data transferred between server and client. Now start the server and invoke the service using client to results. Non Blocking Mode Now lets create a non blocking server which uses Java non blocking I/O underneath. We can use the same service implementation as before (ArithmeticServiceImpl). public class NonblockingServer {private void start() { try { TNonblockingServerTransport serverTransport = new TNonblockingServerSocket(7911); ArithmeticService.Processor processor = new ArithmeticService.Processor(new ArithmeticServiceImpl());TServer server = new TNonblockingServer(new TNonblockingServer.Args(serverTransport). processor(processor)); System.out.println("Starting server on port 7911 ..."); server.serve(); } catch (TTransportException e) { e.printStackTrace(); } }public static void main(String[] args) { NonblockingServer srv = new NonblockingServer(); srv.start(); } }Here TNonblockingServerSocket is used which encapsulates a ServerSocketChannel. Code for the non blocking client is as follows. public class NonblockingClient {private void invoke() { TTransport transport; try { transport = new TFramedTransport(new TSocket("localhost", 7911)); TProtocol protocol = new TBinaryProtocol(transport);ArithmeticService.Client client = new ArithmeticService.Client(protocol); transport.open();long addResult = client.add(100, 200); System.out.println("Add result: " + addResult); long multiplyResult = client.multiply(20, 40); System.out.println("Multiply result: " + multiplyResult);transport.close(); } catch (TTransportException e) { e.printStackTrace(); } catch (TException e) { e.printStackTrace(); } }public static void main(String[] args) { NonblockingClient c = new NonblockingClient(); c.invoke(); }}Note the usage of TFramedTransport wrapping normal TSocket transport. Non blocking server requires client to use TFramedTransport which would frame the data sent over the wire. Fire up the server and send a request using the client. You will see the same results as before, this time using non blocking mode. Asynchronous Mode We can write asynchronous clients to call a Thrift service. A callback needs to be registered which will get invoked at successful completion of the request. Blocking mode server didn’t work (method invocation returns with an empty response) with the asynchronous client (May be it’s because we are using TNonblockingSocket at the client side. See construction of ArithmeticService.AsyncClient. So this may be the proper behaviour). Non blocking mode server seems to work without an issue. So you can use the non blocking server from earlier with the client shown below. public class AsyncClient {private void invoke() { try { ArithmeticService.AsyncClient client = new ArithmeticService. AsyncClient(new TBinaryProtocol.Factory(), new TAsyncClientManager(), new TNonblockingSocket("localhost", 7911));client.add(200, 400, new AddMethodCallback());client = new ArithmeticService. AsyncClient(new TBinaryProtocol.Factory(), new TAsyncClientManager(), new TNonblockingSocket("localhost", 7911)); client.multiply(20, 50, new MultiplyMethodCallback());} catch (TTransportException e) { e.printStackTrace(); } catch (TException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } }public static void main(String[] args) { AsyncClient c = new AsyncClient(); c.invoke();}class AddMethodCallback implements AsyncMethodCallback<ArithmeticService.AsyncClient.add_call> {public void onComplete(ArithmeticService.AsyncClient.add_call add_call) { try { long result = add_call.getResult(); System.out.println("Add from server: " + result); } catch (TException e) { e.printStackTrace(); } }public void onError(Exception e) { System.out.println("Error : "); e.printStackTrace(); }}class MultiplyMethodCallback implements AsyncMethodCallback<ArithmeticService.AsyncClient.multiply_call> {public void onComplete(ArithmeticService.AsyncClient.multiply_call multiply_call) { try { long result = multiply_call.getResult(); System.out.println("Multiply from server: " + result); } catch (TException e) { e.printStackTrace(); } }public void onError(Exception e) { System.out.println("Error : "); e.printStackTrace(); }}}Two callbacks have been defined corresponding to each operation of the service. Note the usage of two client instances for the two invocations. Each invocation needs a separate client instance or otherwise client will fail with following exception “Exception in thread “main” java.lang.IllegalStateException: Client is currently executing another method: tutorial.arithmetic.gen.ArithmeticService$AsyncClient$add_call“ So this wraps up my quick start on Thrift with different modes of operation. Hope somebody may find this useful. For any suggestions or corrections do not hesitate to comment. [1] http://thrift.apache.org/static/thrift-20070401.pdf Reference: Apache Thrift Quickstart Tutorial from our JCG partner Buddhika Chamith at the Source Open blog. ...

Building Rich Clients with JacpFX and JavaFX2

Creating fast and scaling desktop clients is always a challenge, particularly when dealing with a large amount of data and long running tasks. Although Eclipse RCP and Netbeans RCP are established platforms, the idea was to build a lightweight framework that handles components asynchronously, similar to web components. Developers should have less effort on threading topics and should be able to model the applications’ message flow on their own. These, and many other ideas resulted in the JacpFX project. JacpFX The JacpFX (Java Asynchronous Client Platform) Project is a Framework to create Rich Clients (Desktop and/or Web) in MVC style with JavaFX 2, Spring and an Actor like component approach. It provides a simple API to create a workspace, perspectives, and components; to communicate with all parts and to compose your Client application easily. What does JacpFX offer to you?Implement scaling and responsive Rich Clients against a small and simple API (~120Kb) in JavaFully integrated with Spring and JavaFX 2Add/move/remove defined Components at run-time in your UICreate your basic layout in Perspectives and define “placeholders” for your Component UIHandle Components outside the FX application thread“handle” methods are executed in a worker thread and a “posthandle” method is executed by the FX application threadStateful and stateless callback non-UI componentsOutsource long running processes and computationHandle asynchronous processes easilyNo need for explicit threading or things like Runtime.invoke()Communicate through Asynchronous Messages No shared data between Components Immutable MessagesThe following article will give you a short introduction on JacpFX and how to create JavaFX 2 based Rich Clients with it. The example client shown here, is a (pseudo) contact manager that you can try out here: http://developer.ahcp.de/demo/JACPFX2Demo.html ; The complete source code can you download here: http://code.google.com/p/jacp/downloads/list Pre-requirements : A valid JavaFX2 run-time must be installed to run the demo application (currently available on windows only). To compile the attached demo code, a JavaFX2 SDK (also available for Mac and Linux) and Apache Maven is assumed to be installed. See the detailed instructions at the end of this article:Image 1: Select a category for the first time and the client will ask you to generate 250.000 contacts. While those contacts are generated and incrementally added to the table view, you can select the next category, browse to the next table page, view the consumer chart data or just edit a contact. Keep in mind that no explicit threading was used in the demo-client codeApplication – Structure A JacpFX application is composed of an application-launcher, a workbench, minimum one perspective and at least one component. The example client uses three UI-Components and three non-UI (Callback) Components to create the data and to simulate heavy data access. The Application – Launcher (AFX2SpringLauncher) The application – launcher is the main class of your application where you define the Spring context. A JacpFX – application uses xml declaration to define the hierarchy of the application and all the meta-data, like “component-id” and “execution-target”. The Spring main.xml is located in the resources directory and will be declared in the launchers constructor: public class ContactMain extends AFX2SpringLauncher { public ContactMain() { super("main.xml"); } public static void main(String[] args) { Application.launch(args); } @Override public void postInit(Stage stage) { // define your css and other config stuff here } }Listing 1: application launcher The Application – Workbench (AFX2Workbench) The workbench is the UI-root node of a JacpFX application. Here you configure the application, set the resolution, define tool – bars, menus and have reference to the JavaFX stage. public class ContactWorkbench extends AFX2Workbench { @Override public void handleInitialLayout(IAction<Event, Object> action, IWorkbenchLayout<Node> layout, Stage stage) { layout.setWorkbenchXYSize(1024, 768); layout.registerToolBar(ToolbarPosition.NORTH); layout.setMenuEnabled(true); }@Override public void postHandle(FX2ComponentLayout layout) { final MenuBar menu = layout.getMenu(); final Menu menuFile = new Menu("File"); final MenuItem itemHelp = new MenuItem("Help"); /// add the event listener and show an option-pane with some help text menuFile.getItems().add(itemHelp); menu.getMenus().addAll(menuFile); } }Listing 2: Workbench The Perspective (AFX2Perspective) The task of a perspective is to provide the layout of the current view and to register the root and all leaf nodes of the view. The leaf nodes are the “execution-target” (container) for all components associated (injected) to this perspective. The demo perspective basically defines two SplitPanes and registers them as “execution-target” to display the content of the ContactTreeView on the left; the ContactTableView at top right and the ContactChartView at bottom right.Image 2: Three targets defined by the perspective in the demopublic class ContactPerspective extends AFX2Perspective { @Override public void onStartPerspective(FX2ComponentLayout layout) { // create button in toolbar; button should switch top and bottom id's ToolBar north = layout .getRegisteredToolBar(ToolbarPosition.NORTH); ... north.getItems().add(new Button("switch view");) ; }@Override public void onTearDownPerspective(FX2ComponentLayout layout) { }@Override public void handlePerspective(IAction<Event, Object> action, FX2PerspectiveLayout perspectiveLayout) { if (action.getLastMessage().equals(MessageUtil.INIT)) { createPerspectiveLayout(perspectiveLayout); } } private void createPerspectiveLayout(FX2PerspectiveLayout perspectiveLayout) { //// define your UI layout ... // Register root component perspectiveLayout.registerRootComponent(mainLayout); // register left menu perspectiveLayout.registerTargetLayoutComponent("PleftMenu", leftMenu); // register main content Top perspectiveLayout.registerTargetLayoutComponent(“PmainContentTop”, mainContentTop); // register main content Bottom perspectiveLayout.registerTargetLayoutComponent("PmainContentBottom", mainContentBottom); }} Listing 3: Perspective The UI-Components (AFX2Component) AFX2Components are the actual UI-Components in a JacpFX application that are rendered as JavaFX components. The demo defines a left (ContactTreeView), main-top (ContactTableView) and a main-bottom (ContactDemoChartView) AFX2Component. A JacpFX component has four methods to implement; “onStartComponent” and “onTearDownComponent” as well as “handleAction” and “postHandleAction”. While the “handleAction” is executed in a worker thread the “postHandle” runs in the FX application thread.Image 3: Component lifesycle of an AFX2ComponentYou can use lazy initialization of components and shutdown or restart components if you want. public class ContactTreeView extends AFX2Component { private ObservableList<Contact> contactList; ... @Override public Node handleAction(final IAction<Event, Object> action) { if (action.getLastMessage().equals(MessageUtil.INIT)) { this.pane = new ScrollPane(); ... return this.pane; } return null; }@Override public Node postHandleAction(final Node node, final IAction<Event, Object> action) { if (action.getLastMessage() instanceof Contact) { this.contactList.addAll((Contact) action.getLastMessage()); } return this.pane; }@Override public void onStartComponent(final FX2ComponentLayout layout) { final ToolBar north = layout .getRegisteredToolBar(ToolbarPosition.NORTH); … north.add(new Button("add category")); } @Override public void onTearDownComponent(final FX2ComponentLayout layout) { } ... } Listing 4: ContactTreeView (the left view) The “handleAction” method in Listing 4 is used to initialize the component UI. In the “postHandle” action of the demo new contacts were added; the contactList is bound to the existing TreeView, so you can’t update it outside the FX application thread and must therefore use the “postHandle” method. The Callback Components JacpFX callback-components are non-UI/service components. Similar to an AFX2Component, they have a method called “handle” that is executed in a worker thread. The result can be any type of object and will be automatically delivered back to the calling component or redirected to any other component. In these types of components you execute long running tasks, invoke service calls or simply retrieve data from the storage. JacpFX provides two types of callback components, an “AStatelessCallbackComponent” and a (stateful) “ACallbackComponent”. The demo client uses an “ACallbackComponent” component to generate the random chart data for a selected contact a table. To generate the large amount of contacts two “AStatelessCallbackComponents” are involved. One component divides the total amount into chunks and the second one just creates contacts. The result will be sent to the UI component directly and added to the table. Messaging Messaging is the essences of the JacpFX Framework. JacpFX uses asynchronous messaging to notify components and perspectives of your application. The message flow to create the initial amount of data for a category in the demo application looks like:Image 4 : Message Flow to create initial amount of data in the demo applicationThe state of a JacpFX component is always changed by messages. If a task should be handled in a background thread you simply send a message to a component and process the work in the “handle” method. The result can be sent back to the caller component or be processed by the FX application thread in the “postHandle” method (in case of UI Components). You should always avoid execution of long running tasks on the FX application thread; instead call your service- or DB-operation inside the “handle” method. JacpFX differs between two message types, a local and a global message. Local messages To trigger a local message simply get a listener IActionListener<EventHandler<Event>, Event, Object> listener = this.getActionListener(“message”);with only one argument – the message itself. This listener can be assigned to any JavaFX eventHandler (like onMouseEvent, etc.) or it can be fired by invoking listener.performAction(event);Global messages With global messages you communicate with other registered components. Callback components respond to a message by default so you don’t need to create a respond message explicitly – also you could. Messaging is the prefered way to exchange data between components and to trigger Tasks. Similar to local messages you create a listener instance but with an explicit target id: IActionListener<EventHandler<Event>, Event, Object> listener = this.getActionListener(“id“,“message”);Build the demo application from source Register JavaFX in your local Maven repository All JacpFX-Projects are Maven projects and require JavaFX 2 (jfxrt.jar). Some include JavaFX 2 as system dependency but we preferred to register the jfxrt.jar in the local repository. To create deployable files (jnlp and html) you additionally need to register the JavaFX Ant-Tasks (ant-javafx.jar). To do so change to your ${SDK-home}/rt/lib and type: mvn install:install-file -Dfile=jfxrt.jar -DgroupId=com.oracle -DartifactId=javafx-runtime -Dpackaging=jar -Dversion=2.0Then copy the “bin” directory (on linux i386) to your .m2\repository\com\oracle\javafx-runtime folder. Next change to your ${SDK-home}/tools directory and type: mvn install:install-file -Dfile=ant-javafx.jar -DgroupId=com.oracle -DartifactId=ant-javafx -Dpackaging=jar -Dversion=2.0Build the project To build the project, simply unzip the project folder and type mvn package. The jar, jnlp and the html file is created in the ${projectHome}/target/deploy. To create an Eclipse project simply type mvn eclipse:eclipse. What’s coming next? JacpFX is currently in Version 1.0; after many years of prototyping with Echo3 and Swing, JacpFX is the first stable release based on JavaFX 2 and a defined release plan. You can find a detailed documentation on the projects Wiki page (http://code.google.com/p/jacp/wiki/Documentation). Our release plan (also located at the Wiki) defines Version 1.1 in June this year. Major changes will be annotation support and an official FXML support (also you can already use FXML). Feedback is always welcome, so feel free to contact us. Reference: Building Rich Clients with JacpFX and JavaFX2 from our W4G partner Andy Moncsek....

Integration Framework Comparison – Spring Integration, Mule ESB or Apache Camel

Data exchanges between companies increase a lot. The number of applications which must be integrated increases, too. The interfaces use different technologies, protocols and data formats. Nevertheless, the integration of these applications shall be modeled in a standardized way, realized efficiently and supported by automatic tests. Three integration frameworks are available in the JVM environment, which fulfil these requirements: Spring Integration, Mule ESB and Apache Camel. They implement the well-known Enteprise Integration Patterns (EIP, http://www.eaipatterns.com) and therefore offer a standardized, domain-specific language to integrate applications. These integration frameworks can be used in almost every integration project within the JVM environment – no matter which technologies, transport protocols or data formats are used. All integration projects can be realized in a consistent way without redundant boilerplate code. This article compares all three alternatives and discusses their pros and cons. If you want to know, when to use a more powerful Enterprise Service Bus (ESB) instead of one of these lightweight integration frameworks, then you should read this blog post: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ (it explains when to use Apache Camel, but the title could also be „When to use a lightweight integration framework“). Comparison Criteria Several criteria can be used to compare these three integration frameworks:Open source Basic concepts / architecture Testability Deployment Popularity Commercial support IDE-Support Errorhandling Monitoring Enterprise readiness Domain specific language (DSL) Number of components for interfaces, technologies and protocols ExpandabilitySimilarities All three frameworks have many similarities. Therefore, many of the above comparison criteria are even! All implement the EIPs and offer a consistent model and messaging architecture to integrate several technologies. No matter which technologies you have to use, you always do it the same way, i.e. same syntax, same API, same automatic tests. The only difference is the the configuration of each endpoint (e.g. JMS needs a queue name while JDBC needs a database connection url). IMO, this is the most significant feature. Each framework uses different names, but the idea is the same. For instance, „Camel routes“ are equivalent to „Mule flows“, „Camel components“ are called „adapters“ in Spring Integration. Besides, several other similarities exists, which differ from heavyweight ESBs. You just have to add some libraries to your classpath. Therefore, you can use each framework everywhere in the JVM environment. No matter if your project is a Java SE standalone application, or if you want to deploy it to a web container (e.g. Tomcat), JEE application server (e.g. Glassfish), OSGi container or even to the cloud. Just add the libraries, do some simple configuration, and you are done. Then you can start implementing your integration stuff (routing, transformation, and so on). All three frameworks are open source and offer familiar, public features such as source code, forums, mailing lists, issue tracking and voting for new features. Good communities write documentation, blogs and tutorials (IMO Apache Camel has the most noticeable community). Only the number of released books could be better for all three. Commercial support is available via different vendors:Spring Integration: SpringSource (http://www.springsource.com) Mule ESB: MuleSoft (http://www.mulesoft.org) Apache Camel: FuseSource (http://fusesource.com) and Talend (http://www.talend.com)IDE support is very good, even visual designers are available for all three alternatives to model integration problems (and let them generate the code). Each of the frameworks is enterprise ready, because all offer required features such as error handling, automatic testing, transactions, multithreading, scalability and monitoring. Differences If you know one of these frameworks, you can learn the others very easily due to their same concepts and many other similarities. Next, let’s discuss their differences to be able to decide when to use which one. The two most important differences are the number of supported technologies and the used DSL(s). Thus, I will concentrate especially on these two criteria in the following. I will use code snippets implementing the well-known EIP „Content-based Router“ in all examples. Judge for yourself, which one you prefer. Spring Integration Spring Integration is based on the well-known Spring project and extends the programming model with integration support. You can use Spring features such as dependency injection, transactions or security as you do in other Spring projects. Spring Integration is awesome, if you already have got a Spring project and need to add some integration stuff. It is almost no effort to learn Spring Integration if you know Spring itself. Nevertheless, Spring Integration only offers very rudimenary support for technologies – just „basic stuff“ such as File, FTP, JMS, TCP, HTTP or Web Services. Mule and Apache Camel offer many, many further components! Integrations are implemented by writing a lot of XML code (without a real DSL), as you can see in the following code snippet: <file:inbound-channel-adapter id=”incomingOrders” directory=”file:incomingOrders”/><payload-type-router input-channel=”incomingOrders”> <mapping type=”com.kw.DvdOrder” channel=”dvdOrders” /> <mapping type=”com.kw.VideogameOrder” channel=”videogameOrders” /> <mapping type=”com.kw.OtherOrder” channel=”otherOrders” /></payload-type-router><file:outbound-channel-adapter id=”dvdOrders” directory=”dvdOrders”/><jms:outbound-channel-adapter id=”videogamesOrders” destination=”videogameOrdersQueue” channel=”videogamesOrders”/><logging-channel-adapter id=”otherOrders” level=”INFO”/>You can also use Java code and annotations for some stuff, but in the end, you need a lot of XML. Honestly, I do not like too much XML declaration. It is fine for configuration (such as JMS connection factories), but not for complex integration logic. At least, it should be a DSL with better readability, but more complex Spring Integration examples are really tough to read. Besides, the visual designer for Eclipse (called integration graph) is ok, but not as good and intuitive as its competitors. Therefore, I would only use Spring Integration if I already have got an existing Spring project and must just add some integration logic requiring only „basic technologies“ such as File, FTP, JMS or JDBC. Mule ESB Mule ESB is – as the name suggests – a full ESB including several additional features instead of just an integration framework (you can compare it to Apache ServiceMix which is an ESB based on Apache Camel). Nevertheless, Mule can be use as lightweight integration framework, too – by just not adding and using any additional features besides the EIP integration stuff. As Spring Integration, Mule only offers a XML DSL. At least, it is much easier to read than Spring Integration, in my opinion. Mule Studio offers a very good and intuitive visual designer. Compare the following code snippet to the Spring integration code from above. It is more like a DSL than Spring Integration. This matters if the integration logic is more complex. <flow name=”muleFlow”> <file:inbound-endpoint path=”incomingOrders”/> <choice> <when expression=”payload instanceof com.kw.DvdOrder” evaluator=”groovy”> <file:outbound-endpoint path=”incoming/dvdOrders”/> </when> <when expression=”payload instanceof com.kw.DvdOrder” evaluator=”groovy”> <jms:outbound-endpoint queue=”videogameOrdersQueue”/> </when> <otherwise> <logger level=”INFO”/> </otherwise> </choice> </flow>The major advantage of Mule is some very interesting connectors to important proprietary interfaces such as SAP, Tibco Rendevous, Oracle Siebel CRM, Paypal or IBM’s CICS Transaction Gateway. If your integration project requires some of these connectors, then I would probably choose Mule! A disadvantage for some projects might be that Mule says no to OSGi: http://blogs.mulesoft.org/osgi-no-thanks/ Apache Camel Apache Camel is almost identical to Mule. It offers many, many components (even more than Mule) for almost every technology you could think of. If there is no component available, you can create your own component very easily starting with a Maven archetype! If you are a Spring guy: Camel has awesome Spring integration, too. As the other two, it offers a XML DSL: <route> <from uri=”file:incomingOrders”/> <choice> <when> <simple>${in.header.type} is ‘com.kw.DvdOrder’</simple> <to uri=”file:incoming/dvdOrders”/> </when> <when> <simple>${in.header.type} is ‘com.kw.VideogameOrder’ </simple> <to uri=”jms:videogameOrdersQueue”/> </when> <otherwise> <to uri=”log:OtherOrders”/> </otherwise> </choice> </route>Readability is better than Spring Integration and almost identical to Mule. Besides, a very good (but commercial) visual designer called Fuse IDE is available by FuseSource – generating XML DSL code. Nevertheless, it is a lot of XML, no matter if you use a visual designer or just your xml editor. Personally, I do not like this. Therefore, let’s show you another awesome feature: Apache Camel also offers DSLs for Java, Groovy and Scala. You do not have to write so much ugly XML. Personally, I prefer using one of these fluent DSLs instead XML for integration logic. I only do configuration stuff such as JMS connection factories or JDBC properties using XML. Here you can see the same example using a Java DSL code snippet: from(“file:incomingOrders “) .choice() .when(body().isInstanceOf(com.kw.DvdOrder.class)) .to(“file:incoming/dvdOrders”) .when(body().isInstanceOf(com.kw.VideogameOrder.class)) .to(“jms:videogameOrdersQueue “) .otherwise() .to(“mock:OtherOrders “);The fluent programming DSLs are very easy to read (even in more complex examples). Besides, these programming DSLs have better IDE support than XML (code completion, refactoring, etc.). Due to these awesome fluent DSLs, I would always use Apache Camel, if I do not need some of Mule’s excellent connectors to proprietary products. Due to its very good integration to Spring, I would even prefer Apache Camel to Spring Integration in most use cases. By the way: Talend offers a visual designer generating Java DSL code, but it generates a lot of boilerplate code and does not allow vice-versa editing (i.e. you cannot edit the generated code). This is a no-go criteria and has to be fixed soon (hopefully)! And the winner is… … all three integration frameworks, because they are all lightweight and easy to use – even for complex integration projects. It is awesome to integrate several different technologies by always using the same syntax and concepts – including very good testing support. My personal favorite is Apache Camel due to its awesome Java, Groovy and Scala DSLs, combined with many supported technologies. I would only use Mule if I need some of its unique connectors to proprietary products. I would only use Spring Integration in an existing Spring project and if I only need to integrate „basic technologies“ such as FTP or JMS. Nevertheless: No matter which of these lightweight integration frameworks you choose, you will have much fun realizing complex integration projects easily with low efforts. Remember: Often, a fat ESB has too much functionality, and therefore too much, unnecessary complexity and efforts. Use the right tool for the right job! Reference: Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel? from our JCG partner Kai Wahner at the Blog about Java EE / SOA / Cloud Computing blog....

Java: Improvements to the client and desktop parts of Java SE 6 and Java SE 7 !!!

Client-Side Improvements in Java 6 and Java 7 Learn about the improvements to the client and desktop parts of Java SE 6 and Java SE 7, including the new applet plug-in, the Java Deployment Toolkit, shaped and translucent windows, heavyweight-lightweight mixing, and Java Web Start. Introduction Since the release of Java Platform, Standard Edition 6 (Java SE 6) in December of 2006, a lot of improvements have been made to the client and desktop parts of Java. In this article, we take a tour of Swing, and then we dive into some of the support technologies that let developers make great client apps, such as installation, Java Web Start, applets, and graphics improvements. Then we will take a peek at Java 7. Read more at Client-Side Improvements in Java 6 and Java 7 from Josh Marinacci....

Setup Git server with read/write HTTPS on Debian

Three months ago we decided to move our projects to Git. I guess you already know the advantages of Git over Subversion, as there are too many discussions for this subject. I will describe here a fast and minimal configuration of how to turn a Debian GNU/Linux box to a Git server that supports read and write actions via HTTP(S). Git supports 4 network protocols to transfer data: SSH, Local, Git, and HTTP(S). Many people are behind a firewall, which most of times permit access only to HTTP(S). Until recently, Git HTTP(S) was working only for read actions (only clone, fetch, pull, …). Almost 2 years ago Smart HTTP Transport came up. Using these clever cgi scripts, which now are part of stable Git, we can easily setup a Git server that supports read/write via HTTP(S). Configuration steps 1) Install all required packages on Debian: $> su - $> apt-get install git apache2 apache2-utils openssl2) As we need many Git repositories, we create a base directory that all repositories will be included. $> mkdir -p /opt/allgit/repos3) Create a bare Git repository, where developers can pull and push code. $> cd /opt/allgit/repos $> mkdir repo1.git $> cd repo1.git $> git init --bare4) We will use Apache 2 HTTP server to support HTTP(S) for Git. On Debian, when you install apache2 package, user www-data is created and is the user of Apache. As we need Apache to execute the Git actions, then www-data user must have read and write permissions on each Git repository. $> chown -R www-data:www-data repo1.git/5) The www-data user is used only by Apache and not by developers, so we need to define our Git users somewhere else. We can use HTTP authentication that is provided by Apache. We can use htpasswd, which is an Apache tool that produce an encrypted password from a plain text password for a user. These users are irrelevant to Unix users of OS. So, using this strategy we can define as many Git users as we need, without creating Unix users. Create a specific directory and file, with restricted privileges to www-data user, in order to keep git users and passwords. $> mkdir /etc/gitdata $> cd /etc/gitdata $> htpasswd -c gitusers.passwd gituser1 $> htpasswd gitusers.passwd gituser26) I choose to use secure HTTP for Git communication. So, I created a self signed SSL certificate using openssl. On the same directory create the certificate and the private keys pair. Fill all the fields you like that the next command requires. $> openssl req -x509 -nodes -days 999 -newkey rsa:2048 -keyout mygit_ssl.key -out mygit_ssl.crt7) Also, we need a few modules to be enabled on Apache, so make sure mod_ssl, mod_cgi, mod_alias, and mod_env are enabled. This can be easily done on Debian with a2enmod command, where it create symbolic links in the next directory. $> a2enmod <apache_module> $> ls /etc/apache2/mods-enabled/8) Now you only need to configure Apache site and you are ready. Assume you already have a domain name (e.g. mygitdomain.com) in order to use it for your server. A fast way to configure your Apache site(and test immediately) is to copy the existing configuration of Apache and make the required configuration changes. $> cd /etc/apache2/sites-available $> cp default-ssl mygitdomain.com9) Add (or alter) the existing configuration of mygitdomain.com file, which you just created, based on the next configuration. ServerName mygitdomain.com ServerAdmin webmaster@localhost ErrorLog /var/log/apache2/git_apache_error.log SetEnv GIT_PROJECT_ROOT /opt/allgit SetEnv GIT_HTTP_EXPORT_ALL SetEnv REMOTE_USER=$REDIRECT_REMOTE_USER ScriptAlias /allgit/ /usr/lib/git-core/git-http-backend/ <Directory "/usr/lib/git-core/"> AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all <LocationMatch "^/allgit/repos/.*$"> AuthType Basic AuthName "My Git Repositories" AuthUserFile /etc/gitdata/gitusers.passwd Require valid-user SSLEngine on SSLCertificateFile /etc/gitdata/mygit_ssl.crt SSLCertificateKeyFile /etc/gitdata/mygit_ssl.keyTest your Git server 1) Configuration is finished. Enable this site in your Apache server and then restart Apache. $> a2ensite mygitdomain.com $> /etc/init.d/apache2 restart2) Try to clone your empty git repository. $> git clone https://mygitdomain.com/allgit/repos/repo1.git repo1Certificate verification error error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://mygitdomain.com/allgit/repos/repo1.git/info/refs fatal: HTTP request failedYou have 3 options to solve this: 1. Set this variable in the current shell (will be enabled for all the following commands). $> export GIT_SSL_NO_VERIFY=false 2. Set before each git command the same variable as before. $> env GIT_SSL_NO_VERIFY=true 3. In order to treat your certificate as trusted, even it is a self signed certificate, you can get server’s certificate and install it on one of the next directories: /etc/ssl/certs/ /usr/share/ca-certificates/ Notes This is just a fast configuration that I did 3 months ago in order to evaluate Git. There are many points that you can improve (stronger security) in order to have a better configuration. All the configuration is make by root user. Reference: Setup Git server with read/write HTTPS on Debian from our JCG partner Adrianos Dadis at the Java, Integration and the virtues of source blog....

JEE7: Looking ahead to a new era

With the release of Java EE 7 scheduled for the second half of 2012, projected JSRs are all up and running. The Java EE 7 release, which will reflect the evolving needs of the industry as it moves into the cloud, is date driven: anything not ready will be deferred to Java EE 8.Here is an update and summary of the key features of different specifications in the Java EE 7 platform.1.     Java EE 7 Specification (JSR-342) §  Main theme: to easily run applications on private or public clouds §  The platform will define an application metadata descriptor to describe the PaaS execution environment such as multitenancy, resources sharing, quality of service, and dependencies between applications. §  Embrace latest standards like HTML5, WebSocket, and JSON and have a standards-based API for each one of them. §  Remove inconsistencies between Managed Beans, EJBs, Servlets, JSF, CDI, and JAX-RS. §  Possible inclusion of JAX-RS 2.0 in the Web Profile, revised JMS 2.0 API. §  Technology refresh for several existing technologies and possible inclusion of Concurrency Utilities for Java EE (JSR-236) and JCache (JSR-107). §  Status: ·         Approved by the JCP. ·         Spec leads: Linda DeMichiel, Bill Shannon (Oracle). ·         Project page ·         Mailing list archive, jsr342-expert@javaee-spec.java.net , users@javaeespec.java.net2.     Java Persistence 2.1 (JSR-338) §  Support for multitenancy. §  Support for stored procedures and vendor function. §  Update and Delete Criteria queries. §  Support for schema generation. §  Persistence Context synchronization. §  CDI injection into listeners. §  Status: ·         Approved by the JCP ·         Spec lead: Linda DeMichiel (Oracle) ·         Project page ·         Mailing list archive, jsr338-experts@jpa-spec.java.net , users@jpa-sepc.java.netRead more at Java EE 7: Key features, Specifications, Projects, Mailing List Archives from Arun Gupta....

Getting started with GWT

GWT short for Google Web Development Kit lets programmers to develop Ajax web applications with java. Java codes are converted in to JavaScript and html codes by the GWT compiler. GWT applications are called modules and modules are described using a xml file, assuming the module name as “mymodule” name of the xml file would be “mymodule.gwt.xml”. There is atleast one entry point for a module and it is same as the main method in a java program. GWT program code executes with in a HTML file and CSS file is used for alternating the look and feel. Now that we are familiarized bit with terms and stuff we can move on to writing our own GWT application. Step 1: Installing GWT plugin for eclipse If you have already installed eclipse all you have to do is go to “Help” menu, under that “Install New Software” and give the URL as http://dl.google.com/eclipse/plugin/3.6 and click next and complete installation.step 2: Creating a new project Select File > New > Web Application Project. Enter the name “com.eviac.blog.helloworld” for the project name and package. By default it will select both “Use Google Web Toolkit” and “Use Google App Engine” as we only using Google Web Toolkit here you will have to deselect Google App Engine.Now eclipse will create you a project with a package structure as shown below.step 3: Creating the entry point Inside the package com.eviac.blog.helloworld.client package create a java class named “HelloWorldGwt” package com.eviac.blog.helloworld.client; import com.google.gwt.core.client.EntryPoint; import com.google.gwt.event.dom.client.ClickEvent; import com.google.gwt.event.dom.client.ClickHandler; import com.google.gwt.user.client.Window; import com.google.gwt.user.client.ui.Button; import com.google.gwt.user.client.ui.Label; import com.google.gwt.user.client.ui.RootPanel; public class HelloWorldGwt implements EntryPoint { @Override public void onModuleLoad() { final Label label = new Label("Hello World GWT !!!"); final Button button = new Button("Click Here"); button.addClickHandler(new ClickHandler() { @Override public void onClick(ClickEvent event) { label.setVisible(false); button.setText("welcome back again!"); Window.alert("Welcome to GWT"); } }); RootPanel.get().add(label); RootPanel.get().add(button); } }Inside the package com.eviac.blog.helloworld create Com_eviac_blog_helloworld.gwt.xml file. Com_eviac_blog_helloworld.gwt.xml <?xml version="1.0" encoding="UTF-8"?> <module rename-to='com_eviac_blog_helloworld'> <!-- Inherits Web Toolkit utilities. --> <inherits name='com.google.gwt.user.User'/> <inherits name='com.google.gwt.user.theme.standard.Standard'/> <!-- Specify the app entry point class. --> <entry-point class='com.eviac.blog.helloworld.client.HelloWorldGwt'/> </module>Step 3: Creating html page Inside the folder war create Com_eviac_blog_helloworld.html file Com_eviac_blog_helloworld.html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <link type="text/css" rel="stylesheet" href="Com_eviac_blog_helloworld.css"> <title>Hello World GWT</title> <script type="text/javascript" language="javascript" src="com_eviac_blog_helloworld/com_eviac_blog_helloworld.nocache.js"></script> </head> <body> <!-- optional tag: add this if needs history support --> <iframe src="javascript:''" id="__gwt_historyFrame" tabIndex='-1' style="position:absolute;width:0;height:0;border:0"></iframe> <h1><center>Hello World GWT</center></h1> </body> </html>Step 4: creating web.xml file Inside the folder war/WEB-INF create a xml file called web.xml web.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <!-- Default page to serve --> <welcome-file-list> <welcome-file>Com_eviac_blog_helloworld.html</welcome-file> </welcome-file-list> </web-app>Step 5: Creating css file Inside war falder create a css file named Com_eviac_blog_helloworld.css Com_eviac_blog_helloworld.css h1 { font-size: 2em; font-weight: bold; color: #6495ED; } .gwt-Label { color: #0000FF; font: normal 12px tahoma, arial, helvetica, sans-serif; height:3.5em; width: 10.7em; } .gwt-Button { color: #0000FF; height:3.5em; width: 10.7em; font-size: 12px; font-family: arial, sans-serif; }Alright now we are done with coding steps but wait for it, one more step to go Step 6: Running GWT Application To run right click on the project select Run As->Web Application then it will bring up a new view “Development Mode” copy the url generated.Install GWT plugin for your web browser using this link.Now paste the url in the browser and you’ll see something like following and that’s it.Now that you know how to build a basic GWT application you can improve it by adding more functionalities and changing the look and feel using css file. Reference: Getting started with GWT from our JCG partner Pavithra Siriwardena at the EVIAC blog....

Best Of The Week – 2012 – W10

Hello guys, Time for the “Best Of The Week” links for the week that just passed. Here are some links that drew Java Code Geeks attention: * How to Hire a Programmer: Some tips on how to hire a programmer like checking fir his portfolio, having a phone screen, assigning an audition project etc. Also check out our brand new Jobs section. * Introducing Spring Integration Scala DSL: Sping introduces the Spring Integration Scala DSL, Domain Specific Language written in Scala with the goals of providing a strongly-typed alternative to XML configuration for Spring Integration, providing first class integration with various Scala frameworks and products such as Akka and providing seamless integration with Java where Scala developers can still leverage their existing Java investments. * Akka 2.0 Released!: On a similar note, Akka version 2.0 has been released. Akka is a Scala/Java framework suitable for programming for concurrency, fault-tolerance and scalability. * Zero Defects : Baking Quality into the Agile Process: In this presentation it is explained how to use testing and defect management in an Agile project to ensure product quality, addressing design quality, legacy systems, and how build management affects quality. Also check out 4 Warning Signs that Agile Is Declining and Agile’s Customer Problem. * What Every Programmer Should Know About SEO: As the title says, this article provides some insights on SEO and how to optimize it. * Continuous Integration in the Mobile World: This presentation discusses using CI for iOS and Android apps, headless emulators, tools for unit and functional testing, and mobile app deployment. The whole process is described, from creating a new project to emailing the project’s artifacts. Also see “Android Full Application Tutorial” series and The Ten Minute Build.* How sheep-like behavior breeds innovation in Silicon Valley: A nice article on how we try to apply pattern-matching in a world of low probability, usually with bad results. I liked the mention at Survivorship Bias, i.e. that we draw our pattern-recognition from well-publicized successful companies while ignoring the negative data from companies that might have done many of the same things, but end up with unpublicized failures. * Say Hello to Jelastic: This brief tutorial shows how to get started with Jelastic by deploying a simple Spring MongoDB application to the cloud. Also see OpenShift Express: Deploy a Java EE application (with AS7 support). * Speeding Up Java Test Code: An article that provides pointers on how to reduce test execution times with tips like avoiding “sleeps” in the code, reducing the hierarchy of test classes, avoiding to hit the database, minimizing file I/O etc. * DRY and Duplicated Code: This post briefly discusses the DRY (Don’t Repeat Yourself) principle and it’s most common violation, code duplication. Gives an example of DRY violation and discusses how to identify it and treat it. Also see Integrating Maven with Ivy that talks about building an infrastructure that can identify DRY principle violations. * I’m an Engineer, Not a Compiler: This article discusses phone interviews and the fact that very often “nano-questions” are used in the processed, i.e. questions that could be answered with a quick google search. Those carry a lot of disadvantages, including generating false negatives. * You can’t achieve REST without client and server participation: In this article the author suggests that when building a RESTful system both client and server have to be good citizens. A RESTful system has a shared set of responsibilities between client and server, so both sides should receive the proper attention by the developers/architects. * Basic Application Development with Spring Roo and SQLFire: This presentation introduces Roo (Rapid Application Development framework) and SQLFire (Memory-oriented clustered database) along with a demonstration of using AspectJ for SQLFire administration. *Java Book Recommendations: Top and Best Java Books: What the title says. Also see Top 10 Java Books you don’t want to miss and Java Developer Most Useful Books. * Why Do IT Pros Make Awful Managers?: A very interesting article on why IT professionals usually make awful managers. It basically boils down to choosing the computer interface over the human interface and the fact that sucessful people have the belief that success and smartness applies to pretty much everything they do. * Ask For Forgiveness Programming – Or How We’ll Program 1000 Cores: Interesting article on parallele programming and concurrency. It is stated that the only way we’re going to be able to program the new multicore chips of the future is to sidestep Amdhal’s Law and program without serialization, without locks, embracing non-determinism. In essence, removing serialization is the only way to use all the available cores. That’s all for this week. Stay tuned for more, here at Java Code Geeks. Cheers, Ilias Tsagklis...

Mentorship in Software Craftsmanship

First, a little bit of background and metaphor In the medieval times, apprentices would work in workshops an would be mentored by senior craftsmen (journeymen) or by the master craftsman himself. The apprentice had the responsibility to learn, observing the master’s and everyone else’s work, questioning everything and practising as much as he could. This was different from the teacher/student relationship where the teacher had the responsibility to teach. Here it was the apprentice that had to push his own development. The apprentice, mentored by the master, would learn and refine his skills on a daily basis. Over time, the master would reach his limit as in what he could teach the apprentice and the knowledge and skills gap between both would not be that big any more. The master would then publicly recognise the apprentice as a professional that could take on work on his own and would deliver it with the same quality that the he would deliver himself. The master, at this point, would be putting his own reputation on the line since he was the one that trained the apprentice and was now vouching for his ability. This would be the graduation point. Now the apprentice was ready to start his own journey, as a journeyman. As a journeyman, he would then go from town to town, work for and learn from different masters up to a point that he would be recognised by all of these masters and other craftsmen as a master himself. He would then be ready to have his own shop and start mentoring other journeymen and apprentices. Back to the present From now on, instead of master/apprentice, I’ll be using mentor/mentee. The main reason is that you don’t need to be a master craftsman to mentor someone. You also don’t need to be an apprentice to have a mentor. Besides that, each developer has different areas of expertise. They can be very senior in certain areas and completely ignorant in other areas. As we all know, software development is not as limited as a blacksmith’s workshop in the medieval times. The role of the mentor Deciding to mentor someone is a big responsibility. The role of a mentor is more than just be available on the phone and answer a few questions here and there. Although this can be very helpful, the role of a mentor goes way beyond than that. The mentor has the responsibility to make the mentee a good professional and that includes the technical and the personal side. More than just teaching the mentee a specific framework or technique, the mentor will also be teaching the mentee how to become a professional software developer, including ethics and code of conduct. From the technical perspective, the mentor will do his best to teach everything he knows. If they don’t work together, the mentor is expected to reserve formal time to work with the mentee. From the personal perspective, a mentor should help the mentee in his career (journey), giving some guidance, advices, opening doors or showing the doors he has already opened himself, introducing the mentee to his own professional circle and whatever else the mentor judges that can be important for the mentees. The role of the mentee The mentee is expected to do whatever he or she can to learn from the mentor. The mentee must be open-minded, be able to take criticism on board, be able to listen and also be very proactive in terms of perpetuating the knowledge. Practice is key. The mentee is expected to practice as much as possible, making him or herself better everyday. Mentees are also expected to produce something. Something where the mentor can measure their progress and possibly identify areas of improvement. Besides the direct benefits to the mentee, this is also the best way to keep mentors excited to be helping. Mentees must show passion and a clear desire to learn otherwise mentors will probably loose interest and find it a waste of time. Gains and sacrifices Mentors have the opportunity to perpetuate their knowledge since they need to organise their ideas to teach someone. Mentors will also need to be studying and practising hard to keep feeding his mentee, what obviously is a good thing. They will get the satisfaction of helping developers to progress in their careers, with good foundation, ethics and professionalism. They will be doing their part in rasing the bar of our industry, training the next generation, and this, on its own, is a very noble cause. But there are sacrifices and the main one is time. Mentors are expected to dedicate time to their mentees. If mentor and mentee work together in a daily basis, they won’t need much time outside work. However, if they don’t, mentors need to be clear they will need to find and reserve time for their mentees, ideally in a regular basis. Mentees have the opportunity to speed up their development as professional software developers. They benefit from the mentor’s experience acquired over the years, shortening the time they would take to learn something and avoiding to commit the same mistakes. They also have someone they trust that could offer a different perspective on the things they are going through (technical issue, problem with a manager, process, bureaucracy, deadlines, estimation, etc). Without any scientific evidence to back me up, I would dare to say that with the right attitude from both parts and a good amount of time together, the mentee could learn in two years what the mentor learned in ten. That gives the mentees a massive head-start in their careers. Time should never be called a sacrifice from the mentees perspective. When someone is getting a lot of knowledge and help for free, possibly saving years of their careers, complaining about time (or lack of it) would be very short-sighted, to say the least. Mutual Respect Both mentors and mentees should respect each other. In order to have a healthy and prosperous relationship, there must be a commitment from both parts. This commitment is the mutual respect. The mentor shows respect with regular interactions with the mentee and time commitment. The mentee shows respect with his commitment to excel and demonstration of progress. That’s the minimum a mentee could do for someone that is sacrificing time with family and friends in order to help him. So far I’ve given a bit of background history and also described the roles and responsibilities of mentors and mentees according to the Software Craftsmanship principles. Now I’ll be convering a few other areas related to the relationship itself. Remember that the focus here is on mentorships outside work. Let’s start from the beginning. How do we find mentors or mentees? That’s probably the most difficult question to answer. I can think in three possibilities (in no particular order):Try to find someone that works with you in a daily basis. It will make the approach easier. Via user groups and communities. If you are an active member of a user group or community you will have the opportunity to meet a lot of people and maybe find the mentor or mentee you are looking for. Via indication: A friend could recommend/introduce you to someone.Choosing a mentor Although not a rule, normally, in Software Craftsmanship, it is the mentee that chooses the mentor or, at least, start the conversation. The mentee needs to have an idea of the path he wants to take. For example, he may want to learn more about mobile development, work as a consultant, work in high-performance low-latency systems, learn about gaming development, improve his automated testing techniques or, in the best case, just learn how to become a better developer. Whatever the mentee’s ambitions are, the mentee needs to make sure that his future mentor is a person that can provide the knowledge he or she is looking for. Unfortunately, this may be easier said than done. Depending where the mentee is in his career, he may not know exactly what he wants. He may not even know what options he has. Although good developers are good developers and the foundation and priciples of software development always apply, we all know that the skills set used in different types of systems can vary a lot. A well experienced developer that spent the majority of his career doing web-development and became an expert in user experience may take a while to perform well in a completely server-side, asynchronous application with no GUI. Working on an application that heavily rely on algorithms and that don’t use any database can be totally different from developing a mobile client application. The same way that working for a consultancy company can be very different from working for a bank or a startup. Those are some of the things that developers at early stages of their careers may not even have a clue. If you are at this stage in your career, the best suggestion is that you focus purely on being a great developer and learn the basics. Things like Test-Driven Development, clean code, refactoring, Object-Oriented principles, different languages and paradigms. Once you have that, it will be easier for you to choose your next move. Choosing a mentor involves is not an easy task. Maybe a single mentor won’t be able to teach everything a mentee wants to know. Mentees should focus on their very next step(s) instead of focusing in everything they want to learn throughout their entire career. Mentees may change their minds quite often as soon as new opportunities and options are presented to them. They should keep their options open and choose a different mentors as time goes by. Choosing a mentee Mentors, before accepting a mentee, should ask themselves: Would I be able to dedicate time to this person? Can I really help his or her career? If the answer is yes, fantastic. The first thing to look for in a mentee is passion. Since a mentor will be allocating time to help someone, they should make sure that this person deserves their help. Make sure that the mentee is committed to be better. Another thing mentors need to decide is what sort of seniority level their future mentee should have. Some mentors will prefer to take graduates, others prefer juniors with one or two years of experience and others prefer to get seniors or mentees on the verge of becoming seniors. Choosing a mentee is a very personal thing and different mentors will have completely different criteria. If the mentor already knows the mentee, than it is easier. When the mentor doesn’t know the mentee I could suggest a few options that could either be combined or used independently:Introduction letter: The mentor could ask the mentee for a summary of his career so far (not a CV). In this summary, the mentee would describe what he has done, where he thinks he are in his career, the things he learnt, provide (if any) links to his public profile like github account, twitter, blog, web/mobile applications and most importantly, what he expect from the mentor. Coding challenge: The mentor can set up a challenge before considering to speak and accept a mentee. E.g. the mentee, using his preferred language, needs to write a simple blog or wiki application, have it deployed in somewhere (heroku, cloudbees, Google App Engine, Amazon Beanstalk, etc) and code should be public (github, for example). Or it could be simpler like solving a few katas using two different languages or anything along these lines. Blog: Mentee should create a blog, if he or she does not have one, and publish a few posts related to things he has been learning on his own.The mentor, if going down this route, should set the challenges according to the level of seniority he is expecting from the mentee. Once the mentor is satisfied with the initial effort by the potential mentee, he could decide if he is going to accept or not the mentee. Mentorship common misconceptions The mentor is not better than the mentee. In general the mentor will have more knowledge and experience in the areas where the mentee has chosen to be mentored. However, the mentee can easily have more knowledge than the mentor in other areas. Mentees should not expect the mentor to have all the answers to all the problems and mentors should not be naive to think that the mentee doesn’t know anything. Both mentors and mentees have skills and limitations and this needs to be understood by both parts. Mentors should not be looking for themselves a few years younger. This can be frustrating for the mentor. People are different and the mentor will be missing out when not being more open to the type of mentee he or she is prepared to take on board. There is no reason to be so restrictive. Mentoring someone with different personality, possibly slightly different ambitions can be extremelly enriching for both mentors and mentees. However it is important that both have same values and principles. Mentees should not expect that mentors will change their lives. The mentors will be there for the mentees, giving them advices and teaching what they know but it is up to the mentee to decide what to do with it. Mentees should do their part to improve and not think they are going to be spoon-fed by mentors. It’s up to the mentee to look after his or her own career. Walking the long road together (or at least part of it) Once the relationship between mentor and mentee is established, it is fair to say that they will be in a journey together. Every software craftsman is on a personal journey towards mastery. They are all walking the long road. Both mentor and mentees will be learning while they share part of their journey with each other. What mentors and mentees should do during the mentorship? Well, this may vary a lot depending of the type of mentorship. In general, they are expected to write code, loads of code. Ideally they should build something together, where the mentee should be the most active in terms of writing the code. The mentor is expected to pair-program with the mentee whenever possible and to be reviewing his code. Agreeing on creating an application would probably be the best option since that would involve not just writing the code but also thinking about requirements, being able to prioritize, defining a development process, deployment strategies, production environment and everything else that is related to a software project in the real life. Working on katas is also a valid. It’s a simpler and quicker approach for the mentee to learn basic skills. This could be used when the mentees are interested in the basics of TDD, naming, refactoring, programming languages paradigms, etc. However, after learning a few basic skills using katas, they should aim to do something larger that really can mimic the sort of applications they would be working on in their professional environments. Establishing goals and tracking progress Establishing goals is definitely a good practice in a mentorship. It keeps mentor and mentees focused in whatever they want to achieve. Working towards an objective is always the best way to study and learn something. Goals should be achievable and used to motivate and direct the menteed and not to be treated as a hard deadline. However, they should be as concrete as they can be, for example, writing an application with features X, Yand Z and have it deployed into production or doing a number of katas using TDD, write blog posts, read books, submit patches to open source projects, or whatever the pair agrees on. It’s important that progress is tracked so both mentor and mentees can see how they are getting on and how much the mentee is evolving. Tracking progress is all about feedback. The quicker and shorter the feedback loop is, the better. It’s also a good tool to trigger conversation about improvements and refinements. How long a mentorship should last? Unfortunately that’s another question that does not have an exact answer. This will depend a lot on the type of mentorship, how much the mentee wants to learn from the mentor and also how much the mentor has to offer. Some say that this should be a lifetime commitment, some say that it should last between 2 to 5 years and some say that it could be as short as a few months. Some mentorships start with very technical and specific things like learning the basics of a language or test disciplines. However they can evolve to an entire project lifecycle or even to a longer term career advice, networking, help with books and conferences, etc. I, personally, would never try to define that upfront. Just enjoy the journey and let time tell when the mentorship should terminate. How and when does it terminate? For the majority of the relationships, both mentor and mentees at some point need to continue their journey in separate ways. This does not mean that they will never talk to each other again or that they don’t like each other. This just means that they need to move on, teach or learn from other people. Also, we all change our minds in terms of what our next steps would be and we need to react to that. One important thing is that regardless who wants to terminate the relationship, this termination should be explicit. It should be clear to both parts that the mentorship is over. Professionalism, Reputation and Public recognition Software craftsmanship is all about professionalism and it is almost impossible to talk about professionalism without talking about reputation. Throughout the mentorship, it is important that the mentor advertises the progress of her mentee. Mentors should public recognise all the skills acquired by the mentee, what would help the mentee to start building her own reputation. However, mentors also need to be aware that every time they vouch for someone, they are also putting their reputations on the line. Mentees are also expected to be recognising their mentors for all the things they’ve been learning. This mutual recognition is one of the things that may help both to build their reputations. Raising the bar Mentorship is at the heart of software craftsmanship and this is probably one of the most efficient ways for us, developers, to help raising the bar of our industry. Sharing our knowledge and experiences with each other is what will help us learn from our mistakes and successes. We probably can teach many things to someone in a fraction of the time that took us to learn them. With this, mentees could absorb a lot of knowledge in a much shorter space of time, making them, overtime, a much more complete professional than any of the mentors she had in her career. Regardless of our level of seniority or if we are being mentored by someone else, if we all take the responsibility to mentor someone, we will all be helping to raise the bar of our industry. Reference: Mentorship in Software Craftsmanship – part 1, Mentorship in Software Craftsmanship – part 2 & Mentorship in Software Craftsmanship – part 3 from our JCG partner Sandro Mancuso at the Crafted Software blog....
Java Code Geeks and all content copyright © 2010-2014, 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 two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below: