jesperfj

mvn archetype:generate -DarchetypeCatalog=http://repo.t.salesforce.com/archiva/repository/releases/archetype-catalog.xml -DarchetypeGroupId=com.force.sdk -DarchetypeArtifactId=springmvc-archetype

jesperfj

java.util.jar.JarFile jar = 
    new java.util.jar.JarFile((thispackage.ThisClass.class.getProtectionDomain()
    	.getCodeSource().getLocation()).getFile());
    	System.out.println(jar.getManifest().getMainAttributes().getValue("Class-Path"));

jesperfj

A better way to set up Java web apps

If you're building a Java web app that you yourself or your organization will be deploying then you can save yourself a lot of trouble by avoiding the whole build-to-war + deploy-to-server approach. Instead, you should build your web app as a normal Java application with an embedded web app server. Don't build a WAR, just compile the code and serve the files out of their source location. This has the following advantages:

• You can code and test iteratively because you don't have to copy files and create war packages every time you make a change. This is similar to what the mvn jetty:run command is being used for by many developers today.
• You run the same exact code in production as you do in development. Hopefully I don't have to elaborate on the advantages of that. Most developers today use mvn jetty:run or similar to achieve a quick, iterative dev cycle. But come time for deployment, they build a WAR and throw it over the wall to be deployed in some app server

jesperfj

#!/usr/bin/env bash
# bin/compile <build-dir> <cache-dir>

# fail fast
set -e

BIN_DIR=$(cd $(dirname $0); pwd) # absolute path
# parse args
BUILD_DIR=$1
CACHE_DIR=$2

jesperfj

This guide will get you started using Spark on Heroku/Cedar. Spark is basically a clone of Sinatra for Java. 'Nuff said.

Create your app

Create a single Java main class in src/main/java/HelloWorld.java:

:::java
import static spark.Spark.*;
import spark.*;

jesperfj

#!/usr/bin/env bash
# bin/compile <build-dir> <cache-dir>

# fail fast
set -e

BIN_DIR=$(cd $(dirname $0); pwd) # absolute path
# parse args
BUILD_DIR=$1
CACHE_DIR=$2

jesperfj

$ mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] >>> maven-archetype-plugin:2.2:generate (default-cli) @ standalone-pom >>>
[INFO] 

jesperfj

Take a simple Maven app like this JAX-RS app:/

$ git clone http://github.com/heroku/template-java-jaxrs.git
Cloning into template-java-jaxrs...
remote: Counting objects: 348, done.
remote: Compressing objects: 100% (156/156), done.
remote: Total 348 (delta 97), reused 348 (delta 97)
Receiving objects: 100% (348/348), 39.70 KiB | 45 KiB/s, done.

jesperfj

Gigaom picked up Derek Collison's tweet about Go. The article singles out static typing as a reason why Go will become a popular systems language.

I will add another reason: It is not an object oriented language.

In the 15 years I have spent designing, building and marketing what is essentially networked services (web apps), object orientation has always feel like a poor fit. Object orientation is simply not a universally applicable modeling principle. Going further, I will argue that, in most cases, it is a poor modeling principle. Objects rarely exhibit behavior. More often, objects are subjected to behavior by some external force (functions operating on data structures).

I find that keeping functions and data structures separate yield the most well structured programs. Best practices for writing web apps follow the same pattern: Use data transfer objects, use compositi

jesperfj

The ThoughtWorks Technology Radar is full of good stuff. Here are my personal favorites:

Micro Services

There's an upfront cost in building more distributed systems with independently operated micro services but it brings so much clarity to your world. You can align small agile teams with each service, you have much more explicit conctracts, leaky interfaces becomes more rare.

The key trend here is that platform services and frameworks have come a long way to make it easier to build micro services. So you should absolutely trial it out and understand just how the cost compares to your current approach.

Perimeterless Enterprise