Featured FREE Whitepapers

What's New Here?


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....

Agile Lifecycles for Geographically Distributed Teams

I’ve been working with geographically distributed and dispersed teams for the past couple of years. Some of them on quite large programs, some of them reasonably small. What they all have in common is that they all want to transition to agile. Most of them start this way: someone takes a Scrum class, gets all excited. This is good. Then reality hits. Scrum is meant for collocated geographically cross-functional teams. Uh oh. Almost all of these teams are separated by function: the developers are in one place, the testers are in another, the business analysts are in a third place, the project managers are in a fourth places, and if there are product owners (or what passes for product owners) they are often in a fifth location. It’s not uncommon for every single function of the team to be separate from every other member of the team. So, the teams don’t fit the Scrum criteria. Uh oh. Since Scrum has so much brand recognition, these people think if they can’t do Scrum, they can’t do Agile. Nope, not so. What they need to do is start from the values and principles of the Agile Manifesto, and go from there. They create their own lifecycle, and their very own brand of Agile. When I worked with one client, that client thought they could extend their iteration. Nope, if anything, that means you keep the iterations even shorter, because you need more frequent feedback when no one is in the same place. Well, there were words. And more words. But, if you start from the values, you see that short iterations are the way to go if you want to be agile. Otherwise, you get staged delivery, which is a lovely lifecycle, but not agile. I’m blogging a series of examples. Please don’t ask me why the people ended up in these locations. I have no idea. All I know is that’s where the people are. Example 1: Using a Project Manager With Iterations, Silo’d Teams One IT organization has teams with developers in the Ukraine, testers in India, product managers and project managers in the UK, and enterprise architecture and corporate management in the eastern US. This organization moved to two-week iterations. The developers were 3.5 hours ahead of the testers, which was not terrible. This organization had these problems:The product managers had to learn to be product owners and write stories that were small enough to finish inside one iteration. The enterprise architects had to stop dictating the architecture without features to hang off the architecture. The developers and testers had to learn to implement by feature so the architects could help the team see the evolving architecture.This organization had a ton of command-and-control to start. The project managers needed to facilitate the teams, not control them. The architects needed to help the teams see how to organize the product, not to tell the developers what to do. The testers needed to not be order-takers, as in taking orders from the developers. You might ask why the organization wanted to move to agile. Senior management wanted agile because the releases got longer and longer and longer, and could not accommodate change. Agile was a complete cultural shift. The two-week iterations, along with an agile roadmap of features helped a lot. The pilot project team consisted of the developers, testers, a product manager, and a project manager. The team rejected the enterprise architect as a member of the team because the architect refused to write code. Release planning: The project manager and the product manager do an initial cut at release planning as a strawman and presented it to the team. “Can you do this? What do you think?” Iteration planning: The team does iteration planning together, making sure every story is either small, medium, or large, where a large story can be done by the entire team in fewer than three days. The team makes sure they get every started story to done at the end of the iteration. Daily commitment: The team does a daily checkin, not a standup. They timebox the checkin to 15 minutes. They ask these questions:What did you complete and with whom yesterday? (reinforces the idea that people work together) What are you working on and with whom today? What are your impediments?The project manager who acts as a servant leader, not a command/controller manages the impediments. The pilot project has two experienced agile people: the project manager and a developer. Both act as servant leaders. Measurements: burnup charts, impediment charts The pilot team has been together for six months now, and is successful. This is not Scrum. It’s not Kanban. It’s agile and it’s working. They are ready to start another project team, working by attraction. Example 2: Using a Project Manager with Kanban, Silo’d Teams This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California. This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban. The New York developers had a problem biting off more than they could chew. So nothing moved across their board. The Italy developers had a board where the work did move across the board. The teams took pictures of their boards every day and shared the work across a project-based wiki. That allowed the New York-based developers to see the work move across the Italy board. And, that encouraged the New Yorkers to call the Italians and ask some questions. That helped the New Yorkers to change the size of their work by working with the product owners. Now, why did the New Yorkers have such trouble originally? Because the developers “knew better” than the product owners, so they changed the stories into architectural features when they had originally received them. (Now they don’t. They leave the stories as real stories.) Release planning: Management in California plan with agile roadmaps. They have features planned specifically week-by-week for the next 6 weeks, and have more of a quarter-by-quarter approach after that. Iteration planning: No iteration planning because they are using kanban. Daily commitment: No daily commitment needed because they use kanban. They do have a checkin a few times a week with each other as a technical team to make sure they don’t create bottlenecks and that they respect the WIP (work in progress) limits. At one point, both the New York and Italy developer teams created automated tests so that the testers could catch up and stay caught up with regression tests. They add a story like that every couple of weeks, and they are paying down their automated testing debt. The Project manager keeps an eye on the WIP, work in progress. Project manager also shepherds the product owner into keeping the queue of incoming work full and properly ranked. The product owner is notorious for changing the incoming work queue all the time. Project manager makes sure the team does retrospectives and is a little unclear how to do them in such a distributed team. The project manager is not so sure their retrospectives are working, and has started an obstacle list, to make sure the team has transparency for their obstacles. Measurements: cumulative flow, average time to release a feature into the product. Example 3: Using a Project Manager with Iterations and Kanban and Silo’d Teams Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration. The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you. The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent. Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts. Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?” Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough. Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs. I’ll summarize in the final part, the next entry. (Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.) Reference: Agile Lifecycles for Geographically Distributed Teams, Part 1, Agile Lifecycles for Geographically Distributed Teams, Part 2 & Agile Lifecycles for Geographically Distributed Teams, Part 3 from our JCG partner Johanna Rothman at the Managing Product Development blog....

A Tale of Two Cultures: Hackers and Enterprise Developers

Today I found myself thinking again of what I see as two distinct cultures in the development world: Hackers and Enterprise Developers. This really isn’t any kind of a rant just an observation that I’ve been thinking over lately. Hackers are really bleeding edge. They have no problem using the commandline, using multiple languages, or contributing back to open source. They’ll find and fix bugs in the opensource software they use and issue pull requests frequently. They’ll always be willing to use new tools that help them produce better software when there might not even be any good IDE support. Finally, they’re always constantly investigating new technologies and techniques to give them a competitive edge in the world. Now when I say hacker I don’t mean someone who just hacks lots of random shit together and calls it a day (that kind of developer isn’t good for anyone). Just someone who isn’t afraid to shake up the status quo, isn’t afraid to be a bit different and go against the grain. They’re the polar opposite of enterprise developers. Enterprise Developers on the other hand are fairly conservative with their software development methodology. I’m not saying that a lack of standards is a good thing, but enterprise developers want standards for doing everything and they want it standardized across the company. If there isn’t IDE support for a tool they’ll refuse to use it. Want to use mongodb, riak, etc? Not unless there’s a fancy GUI client for interacting with it. If they find a bug they’ll back away from the framework they’re using and simply declare that the company shouldn’t use the framework until the bug is fixed externally. I find this group prefers to play it safe and work on solidifying their existing practices rather than explore new ideas. Now don’t get me wrong, this isn’t another rant on IDEs or developers who don’t use the command line. But give me a couple days in any organization and I can quickly point out who the Hackers and Enterprise Developers are. The hackers are always pushing the envelope, trying new ideas out, giving presentations. Most likely they’re facing off against enterprise developers on a daily basis who attempt to rebuff their ideas. The enterprise developers on the other hand are pretty content to do their same daily routine for the rest of their lives without any change or growth. To paraphrase Q from the Star Trek episode Tapestry, “He learned to play it safe. And he never, ever got noticed by anybody.” What I’ve been considering though is whether or not both are beneficial to an organization. It’s no secret I associate myself with the hacker group (and thus I am a bit biased) but I keep wondering if enterprise developers truly are just the right fit for some organizations. I always think hackers are perfect because they push the envelop and come up with all kinds of interesting solutions to scalability problems, such as using Bitorrent to deploy to thousands of servers. Enterprise developers on the other hand rarely exhibit such innovation and would require shelling out several million dollars for an application to copy a file to multiple destinations. In a nutshell, you can really get more done with hackers (who will seek to automate manual tasks as much as possible) while you can use enterprise developers in bulk to brute force through any problem. To repeat the beginning of my post… this isn’t a rant. And I don’t mean to put “enterprise developers” in a negative light. This is all just some random thoughts going through my mind about the two cultures I commonly see in every organization I have been in. What’s your opinion? Reference: A Tale of Two Cultures  from our JCG partner James Carr at the Rants and Musings of an Agile Developer blog....
Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
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: