• the rich text editors doesn’t support editing source code very well
• the most editors doesn’t support tabs (useful for XML)
• often your formatted sourcecode will be shot

But now we are living in the age of social coding. Since GitHub we are knowing that our code can be forked, commented and reviewed by all users in the internet
But GitHub has another nice feature named GIST. A Gist is a repository containing one or more code snippets. This is versioned like your other sourcecode and every Gist is public and can be used as simple code in your blog posts.

WordPress and Gists

If your are using WordPress as blogging software you can easily integrate your gists. If you search for Gist plugins you will find some: http://wordpress.org/extend/plugins/search.php?q=gist
I am using this one and it works fine. For other blogging software you can embedd your gist with a javascript (see below).

Eclipse and Gists

The current release of Egit (the Eclipse integration of GIT) offers a GitHub integration. And additionally Gists are supported, too. You can add your Gists with Mylyn and attach and remove files to/from your gist.

IntelliJ 11 has Gist support, too.

Working with Gist

There are some steps to do to use gists in your blog:

1. Login into the Gist area of GitHub (you can use your GitHub account)
2. Create a new Gist
3. Add one or more files (code snippets)
4. Embed this in your blog post:
   [gist id=12345]
   if you have only one file or
   [gist id=12345 file=myfile.txt]
   if you want to specify a file directly
5. Thats all!

Working with Gist without plugin

You can use your Gists without any plugin, too. It’s quite simple. Add this snippet to your page:

<script src="https://gist.github.com/12345.js?file=myfile.txt"></script>

Contents

• 1 The domain model
• 2 The service model
• 3 Wiring domain and service
• 4 Creating the REST service
• 5 Configuring the web.xml
• 6 Optimize the output
• 7 Conclusion
• 8 Resources

With the Spring Framework you can easily create RESTful webservices. This is built-in the MVC part of Spring. In this post I show you how to configure this and offer the consumer the response as XML and as JSON.

The domain model

First we need a domainmodel. In this sample it is quite simple. It consists of 2 classes: Constellation and ConstellationName.

Domainmodel

The Constellation describes an astronomical constellation like Orion, Andromeda and so on. The association to ConstellationName offers names of the constellation in different languages.

The service model

In this sample the interface used by clients (web, webservice) is a classical service class. This class – named ConstellationService – needs a repository class to access the underlying database.

Servicemodel

Wiring domain and service

With Spring this is quite easy. You need only a little XML file and some Annotations. In the ConstellationService you add the @Service annotation:

@Service
public class Service{
...
}

This annotation is out of the package org.springframework.stereotype.Service. To inject the repository class you can use the @Inject annotation. If you have setup your JPA environment properly you can access the database and get some Constellation instances.

Creating the REST service

Now we have a working backend. But we want to have a RESTful webservice so we need another artifact in our sourcecode: the Controller. A controller is the first item of our application. This means if a client requests data the controller gets the request foremost. The controller then is analyzing and validating the request. After this service will be called, the retrieving data prepared and returned.

In Spring you can add some annotations to a controller method to map this method to the specified URL resource:

@RequestMapping(value = "/constellations")
public ModelAndView getAllConstellations() {}

With this mapping this controller method responses to the request http://some-host/constellations only. You can map more complex URL resources too. For instance if you have an URL with parameter. In our service we want to offer a method the client can request for one constellation identified by its code. This can be done with the annotation @RequestMapping and @PathVariable:

@RequestMapping("/constellation_by_code/{code}")
public ModelAndView findConstellationByCode(@PathVariable String code) {}

With this mapping the part with the {} will be taken as parameter for the method. You can use more placeholder too. For this you can read the Spring documentation.

Now we have all informations to create the controller class.

@Controller
public class ConstellationServiceController {
 
@Inject
private ConstellationService service;
 
@RequestMapping(value = "/constellations")
public ModelAndView getAllConstellations() {
  List<Constellation> constellations = service.findAllConstellations();
  ModelAndView mav = new ModelAndView("xmlView",
    BindingResult.MODEL_KEY_PREFIX + "constellations", constellations);
  return mav;
}
 
@RequestMapping("/constellation_by_code/{code}")
public ModelAndView findConstellationByCode(@PathVariable String code) {
  Constellation constellation = service.findConstellationByCode(code);
  return new ModelAndView("xmlView", BindingResult.MODEL_KEY_PREFIX
     + "constellations", constellation);
}
 
@RequestMapping("/constellations_by_search/{search}")
public ModelAndView findConstellationByCodeOrName
                                    @PathVariable String search) {
  return new ModelAndView("xmlView", BindingResult.MODEL_KEY_PREFIX
            + "constellations", service.findAllConstellationByCodeOrName(search));
}

The last step we need to do is to configure the Spring container to get it together. For this we need a little bit XML. In this XML we configure 2 views: one for a XML and one for a JSON response. So you need to add the xml or json extension to the url to control the format of the response.

<bean class="org.springframework.web.servlet.view.BeanNameViewResolver" />
 
<bean id="xstreamMarshaller" class="org.springframework.oxm.xstream.XStreamMarshaller"
p:autodetectAnnotations="true" />
 
<bean id="xmlView" class="org.springframework.web.servlet.view.xml.MarshallingView"
      p:contentType="application/xml">
      <constructor-arg ref="xstreamMarshaller" />
</bean>
 
<bean id="jsonView" class="org.springframework.web.servlet.view.json.MappingJacksonJsonView" />
 
<bean class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver">
  <property name="mediaTypes">
    <map>
      <entry key="json" value="application/json" />
      <entry key="xml" value="application/xml" />
    </map>
  </property>
  <property name="defaultViews">
    <list>
      <ref bean="jsonView" />
      <ref bean="xmlView" />
    </list>
  </property>
  <property name="ignoreAcceptHeader" value="true" />
</bean>

First we configure the XMLMarshaller to generate XML out of the Java beans. Then we need 2 Views. One for XML and one for JSON. The most configuration needs the ContentNegotiatingViewResolver. This resolver handles the different response formats. The last property ignoreAcceptHeader you need to get JSON in your browser too. Otherwise always XML will be returned.

Configuring the web.xml

You need to activate the Spring servlet and the context listener to get the service running. This is done with a small web.xml.

<web-app>
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/rpc-servlet.xml</param-value>
  </context-param>
 
  <listener>
    <listener-class>
      org.springframework.web.context.ContextLoaderListener
    </listener-class>
  </listener>
 
  <servlet>
    <servlet-name>rpc</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
 
  <servlet-mapping>
    <servlet-name>rpc</servlet-name>
    <url-pattern>/rpc/*</url-pattern>
  </servlet-mapping>
</web-app>

Now we have all together and can start the web application. You can access the services with http://localhost:8080/rpc/constellations. As default format XML will be returned. If you want to have JSON change the URL into http://localhost:8080/rpc/constellations.json. Of course you can add .xml to get XML output, too.

If you want to have the data for one constellation you can use the 2nd controller method with http://localhost:8080/rpc/constellation_by_code/and. The last part of the URL is the official code/abbreviation of a constellation. All codes/abbreviations you can get here. If you want the output as JSON you can add the extension .json too: http://localhost:8080/rpc/constellation_by_code/and.json

Optimize the output

We have even 2 little problems:

1. The Constellation class defines a byte array containing imagedata of a starcard. If we want to retrieve all constellations the response will be great.
2. The association will not be resolved. We want to get all names of a constellation with one request to minimize the response-request cycle.

public class Constellation{
  ...
  @XStreamOmmitField
  private byte[] starCardData;
}

public class Constellation{
...

@XStreamImplicit(itemFiledName = "names")
private List<ConstellationName> names;
}

The XML result should look like

<constallation>
  <id>4</id>
  <name>Andromeda</name>
  <code>and</code>
  ...
  <names>
    <id>19</id>
    <name>Andromeda</name>
    <langCode>de</langCode>
    <code>and</code>
  </names>
  <names>
    <id>20</id>
    <name>Andromeda</name>
    <langCode>en</langCode>
    <code>and</code>
  </names>
  ...
</constellation>

Conclusion

Now you have a Spring-based RESTful service created. As you can see there are not many code you must write. The most is configuration with annotation and some XML. With the @RequestMapping you can create powerful mappings from URL resources to controller methods. Another nice feature is to deliver the response as XML and JSON.

Resources

1. Where to find a cool font with a adequate licence (OpenSource, Public Domain and so on)
2. How do I manage that all visitors of my website this font have installed?

Embedding fonts in your website

Every current browser supports loading fonts at runtime and embeds this font into the website (see Webfonts). So the visitor must not manually downloading and installing the font first.

With Google’s webfonts you can choose a cool font (all are Open Source) and embedding this into your website. This you can do with

• Adding a stylesheet link statement in your page header
• Using the @import statement in your css
• Using javascript

If you want to embed with a stylesheet link add only

<link href='http://fonts.googleapis.com/css?family=Ubuntu:300' rel='stylesheet' type='text/css'>

to your webpage header. Another approach is to use the @import statement directly in your css:

@import url(http://fonts.googleapis.com/css?family=Ubuntu:300);

With both variants you can reference the font with

font-face: Ubuntu, serif;

Ubuntu is only one the fonts Google offers.
If you want to use Javascript to add a webfont to your webpage you can use this snippet:

<script type="text/javascript">
WebFontConfig = {
google: { families: [ 'Ubuntu:300:latin' ] }
};
(function() {
var wf = document.createElement('script');
wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
'://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
wf.type = 'text/javascript';
wf.async = 'true';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(wf, s);
})(); </script>

And now you have a nice font for your website.

But how does this work?

There is the @font-face definition in CSS3. This the Google Webfont-API use, too. If you load the URL you see in the examples above  a small css snippet will be returned:

@font-face {
  font-family: 'Ubuntu';
  font-style: normal;
  font-weight: normal;
  src: local('Ubuntu'), url('http://themes.googleusercontent.com/static/fonts/ubuntu/v1/vRvZYZlUaogOuHbBTT1SNevvDin1pK8aKteLpeZ5c0A.woff') format('woff');
}

So you can see that Google reuse the current web standards.

• Package structure
• Class/Interface/Enum
• Code will be pasted into the newly created file

package a.b.c;

class A{
    public A(){}

    public void methodA(){
      System.out.println("This is a very useful class!");
    }
}

The Agile Backoffice

If you start working agile – mostly you use Scrum as first agile method – you and your team are very motivated to do this in a very agile way. The tasks are all pinned on a wall or a whiteboard, a continuous integration will be setup, the project know how will be shared in internal discussions. This works fine for a small team workingalways together in one location.

If you take a look around you see a lot of companies where this optimal conditions not exists. The teams are divided in different locations – different rooms, different floors, different locations. If your team splitted i such a way a whiteboard with pinned tasks are not a reasonable solution. Additionally to this you have a management interested in the progress of your work. For this requirements you need some tools supporting you. But you should use tools adaptable to your processes and not tools you must adaptable your processes to.

The central tool I choose for the Agile Backoffice is Atlassian Jira. It is the single proint of interest. In this tool you can see all requirements, the stories and the belonging tasks. Additionally you can get informations about changed (re)sources, running builds and – the most important – the status of a task, a story or requirement. You have a powerful reporting and a wide support for development tools: Eclipse, IntelliJ, Visual Studio.

Bit only with Jira you can’t get the result you wish. You need a continuous integration, a source control management, a repository for the deployable artifacts. Additionally you want to review and mesure the quality of your code. For this approaches there are tools but this tools should all be connected together, so there are based on the same data.

This is the goal of the Agile Backoffice and this series of articles. So stay tuned.

In verteilten Projekten arbeiten viele Entwickler eigenständig an unterschiedlichen Features und wollen
diese zu einem Gesamtprojekt beisteuern. Damit die Integration der Beiträge effizient gelingen kann,
müssen Toolchain und Prozess drei wichtige Merkmale unterstützen:

• Schnelle und technisch unkomplizierte Integration von Features.
• Review/Kontrolle der Qualität der Beiträge vor ihrer Integration.
• kontinuierliche Messung der Codequalität an einem einheitlichen und gleichbleibenden Standard.

Ich zeige in meinem Vortrag, wie sich diese Anforderungen mit GIT, Gerrit, Hudson und Sonar
erfüllen lassen und der Entwicklungsprozess in verteilten Projekten effizient gestaltet werden kann.

Git ist als Source-Code-Management-System für OSS-Projekte entwickelt worden, deren starke Verteilung
besonders charakteristisch für sie ist. Mit Gerrit können GIT-verwaltete Projekte vor dem eigentlichen Commit
in ein zentrales Sourcecode-Repository bewertet und kommentiert werden. Dies erleichtert den Maintainern die
Entscheidung, ob sie einen Beitrag akzeptieren wollen.
Hudson gewährleistet die kontinuierliche Integration akzeptierter Beiträge und integriert Sonar, um die
Entwicklung der Codequalität, gemessen an einem projektweit einheitlichen Standard, zu bewerten.

Lernen Sie, wie die nahtlose Integration dieser Werkzeuge in einem gemeinsamen Prozess gelingt und behalten
Sie die Kontrolle über verteilte Projekte.

Effizente Entwicklung für verteilte Projekte – Mit GIT, Gerrit, Hudson und Sonar die Kontrolle behalten.

In verteilten Projekten arbeiten die Entwickler eigenständig an Features und steuern diese zu einem Projekt bei. Damit die Integration der Beiträge gelingt, müssen Tools und Prozess einige Merkmale unterstützen:

• Schnelle und technisch unkomplizierte Integration.
• Review der Beiträge vor ihrer Integration.
• Messung der Qualität am Projektstandard.

Thorsten Kamann zeigt, wie sich die Anforderungen mit GIT, Gerrit, Hudson und Sonar erfüllen lassen und die Entwicklung in verteilten Projekten effizient gestaltet wird. Git ist als SCM für OSS-Projekte entwickelt worden, deren starke Verteilung besonders charakteristisch ist. Mit Gerrit können GIT-verwaltete Projekte vor dem Commit in ein SCM bewertet und kommentiert werden. Dies erleichtert den Maintainern die Entscheidung über die Akzeptanz. Hudson gewährleistet die kontinuierliche Integration akzeptierter Beiträge und integriert Sonar, zur Bewertung der Codequalität, gemessen am Projektstandard.

Weitere Informationen und Anmeldung: https://bed-con.org/index.php

In verteilten Projekten arbeiten viele Entwickler eigenständig an unterschiedlichen Features und wollen
diese zu einem Gesamtprojekt beisteuern. Damit die Integration der Beiträge effizient gelingen kann,
müssen Toolchain und Prozess drei wichtige Merkmale unterstützen:

• Schnelle und technisch unkomplizierte Integration von Features.
• Review/Kontrolle der Qualität der Beiträge vor ihrer Integration.
• kontinuierliche Messung der Codequalität an einem einheitlichen und gleichbleibenden Standard.

Ich zeige in meinem Vortrag, wie sich diese Anforderungen mit GIT, Gerrit, Hudson und Sonar
erfüllen lassen und der Entwicklungsprozess in verteilten Projekten effizient gestaltet werden kann.

Git ist als Source-Code-Management-System für OSS-Projekte entwickelt worden, deren starke Verteilung
besonders charakteristisch für sie ist. Mit Gerrit können GIT-verwaltete Projekte vor dem eigentlichen Commit
in ein zentrales Sourcecode-Repository bewertet und kommentiert werden. Dies erleichtert den Maintainern die
Entscheidung, ob sie einen Beitrag akzeptieren wollen.
Hudson gewährleistet die kontinuierliche Integration akzeptierter Beiträge und integriert Sonar, um die
Entwicklung der Codequalität, gemessen an einem projektweit einheitlichen Standard, zu bewerten.

Lernen Sie, wie die nahtlose Integration dieser Werkzeuge in einem gemeinsamen Prozess gelingt und behalten
Sie die Kontrolle über verteilte Projekte.

Navigate with finder to /Users/USER_NAME/Library/Mail. There are many directories. Here you search for the disabled mailbundle. Some of the directories are namend Bundle (deactivated*). In this kind of directory Mail moved the plugins. After you found the mailbundle open it with the command Show Contents and navigate to the Info.plist. Open it with a double click and add to entries to the section SupportedPluginCompatabilityUUID. The both entries must have this values:

• BDD81F4D-6881-4A8D-94A7-E67410089EEB
• 857A142A-AB81-4D99-BECC-D1B55A86D94E

Close the PList-Editor and restart Mail. All plugins should be enabled.

Editing the xwiki.cfg

This is the main configuration file in XWiki. You’ll find it in /WEB-INF/xwiki.cfg. The content of this file is a little bit confusing. Try to find the section marked with

#-------------------------------------------
# LDAP
#-------------------------------------------

In this section you will configuring the LDAP-Support. The following table describing the most important options:

Sample configuration

#-------------------------------------------
# LDAP
#-------------------------------------------

xwiki.authentication.ldap=1
xwiki.authentication.ldap.server=127.0.0.1
xwiki.authentication.ldap.port=389
xwiki.authentication.ldap.bind_DN=
xwiki.authentication.ldap.bind_pass=
xwiki.authentication.ldap.base_DN=dc=myserver,dc=local
xwiki.authentication.ldap.UID_attr=uid
xwiki.authentication.ldap.password_field=userPassword
xwiki.authentication.ldap.group_classes=groupOfNames
xwiki.authentication.ldap.group_memberfields=member
xwiki.authentication.ldap.fields_mapping=last_name=\
     sn,first_name=givenName,email=mail
xwiki.authentication.ldap.update_user=1
xwiki.authentication.ldap.group_mapping=\
    XWiki.XWikiAdminGroup=cn=admins,ou=groups,dc=myserver,dc=local|\
    XWiki.XWikiEditors=cn=developers,ou=groups,dc=myserver,dc=local|\
    XWiki.XWikiEditors=cn=managers,ou=groups,dc=myserver,dc=local|\
    XWiki.XWikiReaders=cn=users,ou=groups,dc=myserver,dc=local
xwiki.authentication.ldap.trylocal=1

In this configuration we are mapping 3 XWiki groups (XWikiAdminGroup, XWikiEditors, XWikiReaders) to 4 LDAP groups. The XWIkiEditors should get the members of the developers and managers out of the LDAP server.