How to open async calls in a new tab instead of new window within an AngularJS app

I recently wanted to generate a PDF on users demand and show it in a new browser tab.
Sounds trivial, at first not for me :) I tried it with different “solutions” and on my way my google search result got better and better. With “open window new tab without popup blocker async” I finally found in this thread a nice and easy solution. The trick is to remember the reference to the new window and change the location of that window when your asynchron call completes.

$scope.generatePdf = function () {
  var tabWindowId = window.open('about:blank', '_blank');

  $http.post('/someUrl', data).then( function (response) {
    tabWindowId.location.href = response.headers('Location');
  });
};

If you want to see it in action open this plunker. While testing this plunker, it seems that openWindow will open a tab, as long as the async call is quick enough (less than a second). The setTimeout is therefore set to 1001.

I hope you will find this solution quicker than I did. Please let me know if you have any questions or suggestions. Either per @leifhanack or comment here.

managing multiple ssh keys

Recently I wanted to connect to some remote server using different ssh keys. With the right ~/.ssh/config file this is easy and comfortable.

Easy

IdentityFile ~/.ssh/%h/%r/id_rsa
IdentityFile ~/.ssh/%h/id_rsa
IdentityFile ~/.ssh/id_rsa

%h and %r are placeholder for host and remote-user. ssh foo@bar will first check if ~/.ssh/bar/foo/id_rsa exists, next ~/.ssh/bar/id_rsa and finally ~/.ssh/id_rsa.

Comfortable

Host github
        HostName 123.45.678.90
        User myuser
        IdentityFile ~/.ssh/123.45.678.90/id_rsa

Instead of ssh myuser@123.45.678.90 the above config allows you to simply type

ssh github

You don’t need to remember all your IPs and remote-users any longer. For me this is a big time saver.

Please let me know if you have questions or suggestions. Either per @leifhanack or comment here.

Hans Dockter mit The Future of Gradle – The Ultimate Build System bei uns am 7.7. um 18 Uhr

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 7. Juli den Vortrag von Hans Dockter The Future of Gradle – The Ultimate Build System. Einlaß ist um 18:00 Uhr. Der Vortrag beginnt um 18:30 Uhr.

gradleware

Vortrag: The Future of Gradle – The Ultimate Build System

We are convinced that Gradle is already the best available enterprise build system. Yet we are far from done. We have finally the R&D bandwidth to deeply improve Gradle in the areas where it lacks. We also have the bandwidth to contribute some fundamental innovation to the domain of build and continuous delivery. All this will bring Gradle much closer to our vision of Gradle being the ultimate build system.

We start by giving an overview of where Gradle is currently in the build system market when it comes to features and adoption. We will then talk about the next generation multi-platform dependency management. A dependency management that can fully capture the requirements of Android, JavaScript and the native domain as well as to improve the dependency management for the Java world. We will talk about how Gradle will dramatically improve the performance by introducing global caches and other optimizations. Finally we will talk about the new Gradle extendability model and its upcoming native and JavaScript support.

Der Vortrag wird je nach Wunsch in englisch oder deutsch gehalten.

Redner: Hans Dockter

Hans Dockter is the founder of Gradle and Gradleware. Hans has 13 years of experience as a software developer, team leader, architect, trainer, and technical mentor in vast array of industry sectors such as automotive, finance, public transport and business intelligence. Hans is a thought leader in the field of project automation and has successfully been in charge of numerous large-scale enterprise builds. He is also an advocate of Domain Driven Design, having taught classes and delivered presentations on this topic together with Eric Evans.

Treffpunkt

Hypoport AG, Klosterstr. 71, 10179 Berlin, am 7.7. um 18 Uhr

Anmeldung

Über eine Vorabanmeldung zur Veranstaltung über das XING-Event der XING-Gruppe der JUG Berlin-Brandenburg würden wir uns freuen, jedoch ist die Anmeldung nicht zwingend erforderlich.

Wir freuen uns auf euch.

Apache RewriteRule – Rewriting URLs With Already Encoded QueryStrings

Recently we renamed a URL which was publically available. The system uses Apache httpd, so it was quiet easy to create a RewriteRule:

RewriteRule ^/oldname/(.*) /newname/$1 [R,L]

Unfortunately that didn’t work as expected. A URL like myserver/oldname?myprop=name with spaces will be encoded to myserver/oldname?myprop=name%20with%20spaces. With the above RewriteRule the rewritten URL will be myserver/oldname?myprop=name%2520with%2520spaces. It got encoded two times!.

To fix this, you need the right keywords and Google. Searching for mod_rewrite url encode revealed that adding the NE flag (for No Encoding) does the trick:

RewriteRule ^/oldname/(.*) /newname/$1 [R,NE,L]

Developing with TeamCity 7.1: from remote run to feature branches – Pavel Sher and Dmitry Neverov at Hypoport on Feb 18th

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 18. Februar den Vortrag von Pavel Sher und Dmitry Neverov Developing with TeamCity 7.1: from remote run to feature branches. Einlaß und Zeit für Networking startet ab 18:30 Uhr. Der Vortrag beginnt um 19:00 Uhr.

Abstract
Continuous integration tools play important role in software development these days. In an ideal world every commit in version control system must be checked by running a build on it, builds must be fast and broken builds must be fixed quickly. But we do not live in the ideal world, so how we can protect ourselves from breaking changes? How we can minimize effects of breaking changes on our teammates?

This talk covers effective ways of using TeamCity, a CI server from JetBrains, with different version control systems. You will see how to commit only a verified code with help of pre-tested commits, how to use personal branches if you’re using Git or Mercurial, and how to implement your favorite DVCs workflow using TeamCity feature branches support.

Speaker

Dmitry Neverov – software developer in TeamCity project. Dmitry works in JetBrains for almost 3 years and his responsibilities include wide range of tasks related to distributed version control systems, from integration with Git and Mercurial to feature branches support in TeamCity core.

Pavel Sher – senior software developer and project manager in TeamCity. Pavel started working on TeamCity almost from the beginning, 7 years ago. As such he took part in many aspects of TeamCity functionality and is responsible for many architectural decisions in TeamCity core.

Anmeldung
Anmeldung erfolgt wie üblich über die Xing JUG BB Event-Einladung.

Tipp
Zusätzlich zu dem Vortrag gibt’s noch ein Goodie von Jetbrains:) Lasst euch überraschen!

jb

Unit- und Integration-Test eines MicroService mit Maven

Was ist ein MicroService? In unserem Kontext ist es ein (kleines) Modul der Gesamtanwendung, welches seinen Dienst als Webapplikation (.war) anbietet. Das konkrete Schnittstellen-Protokoll ist für diesen Artikel nicht entscheidend. Möglich ist klassisch SOAP, REST aber auch Spring HttpInvoker. Ein MicroService ist eine gute Möglichkeit Sollbruchstellen in die Gesamtanwendung einzubauen.

Nun zum eigentlichen Thema: Wie teste ich einen solchen Service? Im Grunde wie immer, d.h. viele Unit-Tests und ein paar ausgewählte Integration-Tests. Die Integration-Tests sollen zeigen, dass die angebotenen Schnittstellen des Services funktionieren und alles richtig konfiguriert ist. Die Integration-Tests, die die Gesamtanwendung, d.h. das Netz aller Services testet, ist hier nicht Bestandteil.

Wie macht man das jetzt mit Maven? Eine Variante ist die Unit-Tests und Integration-Tests zu trennen. Vor der integration-test Phase einen Tomcat zu starten, dann seine Integration-Tests auszuführen und anschließend wieder den Tomcat zu stoppen. Tomcat, weil wir diesen nicht nur lokal einsetzen und somit “gleicher” zur Produktion sind. Eine echte Plugin-Auswahl fand nicht statt, wir sind einfach mit dem tomcat7-maven-plugin gestartet.

Mit Maven Tomcat automatisch starten und stoppen

  <build>
    <plugins>
      ..
      <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <version>2.0-beta-1</version>
        <configuration>
          <contextFile>${project.basedir}/src/test/resources/test-context.xml</contextFile>
        </configuration>
        <executions>
          <execution>
            <id>tomcat-run</id>
            <goals>
              <goal>run-war-only</goal>
            </goals>
            <phase>pre-integration-test</phase>
            <configuration>
              <fork>true</fork>
            </configuration>
          </execution>
          <execution>
            <id>tomcat-shutdown</id>
            <goals>
              <goal>shutdown</goal>
            </goals>
            <phase>post-integration-test</phase>
          </execution>
        </executions>
      </plugin>

    </plugins>
  </build>

Das Starten des Tomcats binden wir an die pre-integration-test Phase (Zeile 17). Wichtig ist fork auf true zu setzen (Zeile 19), da sonst Maven nach Start des Tomcats stehen bleibt. Das Beenden binden wir entsprechend an die post-integration-test Phase (Zeile 27). Wenn keine context.xml in der webapp enthalten ist, muss eine per contextFile angeben werden (Zeile 9).

So, unser Tomcat startet und stoppt nun beim Ausführen von mvn integration-test.

Mit Maven innerhalb eines Modules Unit- und Integration-Tests trennen

Nächster Schritt ist die Unit- und Integration-Tests zu trennen. Im Netz empfehlen einige dies in separaten Maven-Modulen zu tun. Wir finden es sinnvoller dies über die Test-Phasen zu steuern:

  <build>
    <plugins>
      ..
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <skip>true</skip>
          <trimStackTrace>false</trimStackTrace>
        </configuration>
        <executions>
          <execution>
            <id>unit-tests</id>
            <phase>test</phase>
            <goals>
              <goal>test</goal>
            </goals>
            <configuration>
              <skip>false</skip>
              <includes>
                <include>**/*Test.java</include>
              </includes>
              <excludes>
                <exclude>**/*IntegrationTest.java</exclude>
              </excludes>
            </configuration>
          </execution>
          <execution>
            <id>integration-tests</id>
            <phase>integration-test</phase>
            <goals>
              <goal>test</goal>
            </goals>
            <configuration>
              <skip>false</skip>
              <includes>
                <include>**/*IntegrationTest.java</include>
              </includes>
            </configuration>
          </execution>
        </executions>
      </plugin>

    </plugins>
  </build>

In Zeile 8 wird das Default-Test-Verhalten vom maven-surefire-plugin ausgeschaltet. Durch zwei einzelne <execution/>'s können wir unterschiedliche <configuration/>'s an unterschiedliche Phasen binden (Zeile 14 und 30). In der test Phase werden alle Klassen mit Endung Test.java ausgeführt außer jene mit Endung IntegrationTest.java. In der integration-test Phase werden nun lediglich alle Klassen mit Endung IntegrationTest.java ausgeführt. Vielen Dank an HDave, der letzteres auf Stackoverflow schön erklärt.

Hast du ähnliche Anwendungsfälle? Wie hast du diese gelöst?

Oliver Gierke von SpringSource kommt am 14. Juni 2012 nach Berlin

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 14. Juni den Vortrag von Oliver Gierke Huch, wo ist meine Architektur hin?. Einlaß und Zeit für Networking startet ab 18:30 Uhr. Der Vortrag beginnt um 19:00 Uhr.

Vortrag
Wenn Applikationen über eine bestimme Größe oder einen bestimmten Zeitraum hinaus wachsen wird Modularität ein Kernaspekt für Wartbarkeit. Designentscheidungen die getroffen wurden sind kaum noch im Code wiederzufinden, Abhängigkeiten zwischen einzelnen Modulen der Applikation wachsen oft wild. Der Vortrag Patterns und Best Practices rund um generelle Code-Organisation und Package-Strukturen vor um eine solide Grundlage für langlebige Java-Applikationen zu legen, sowie eine möglichkeit mit Spring lose gekoppelte Komponenten und dedizierte Erweiterungspunkte in Applikationen zu definieren und zu verwenden.

Speaker
Oliver Gierke ist Teil des Spring Data Teams bei SpringSource, a division of VMware und leitet dort das JPA, MongoDB und Core Modul. Seit über 6 Jahren widmet er sich dem Entwicklen von Java Enterprise Applikationen, Open Source Projekten und ist Mitglied der JPA 2.1 Expert Group. Seine Arbeitsschwerpunkte liegen im Bereich Softwarearchitektur, Spring und Persistenztechnologien. Er ist regelmäßiger Sprecher auf deutschen und internationalen Konferenzen sowie Autor von Fachartikeln.

Sonar Analyse eines Maven Projektes mit Cobertura und AspectJ

Wir verwenden unter anderem Sonar, um unsere Codequalität zu analysieren. Sonar bietet viel Spannendes. Interessant ist auch die Analyse der Testabdeckung. Hierzu kann man Cobertura verwenden. Im Zusammenspiel mit einem Projekt, welches AspectJ einsetzt kann es zu Problemen kommen, wenn man versucht das Kompilieren der Anwendung mit der Sonar-Analyse zu kombinieren.


mvn clean install sonar:sonar -Dmaven.test.failure.ignore=true

Die Lösung liegt wie so oft in RTFM. Der empfohlene Weg eine Sonar-Analyse durchzuführen ist es zuerst die Anwendung zu bauen und danach die Analyse zu starten.


mvn clean install -Dtest=false -DfailIfNoTests=false
mvn sonar:sonar

Wichtig ist hierbei beim Bauen der Anwendung die Tests auszuschalten, da diese in der Sonar-Analyse laufen und man sonst unnützerweise zwei Testläufe hat.

Nun können wir uns die Testabdeckung der einzelnen Module ansehen.

Hibernate4 verwendet jboss-logging statt slf4j. Durch die log4j Bridge leiten wir die Logs zu logback.

Bei der Migration auf Hibernate 4 haben wir festgestellt, dass Hibernate statt wie bisher slf4j nun ihre eigene Logging API jboss-logging verwendet. Glücklicherweise logt diese API standardmäßig auf log4j. Durch Einsatz der log4j-over-slf4j Bridge lenken wir die Logs wieder auf slf4j, um sie dann per logback zu loggen.

Es ist wichtig bei der Nutzung dieser Bridge keine log4j.jars im Klassenpfad zu haben! Es dürfen kein direkten oder transitiven log4j.jar Abhängigkeiten mehr existieren. Mit maven kann das leicht über ein mvn dependency:tree geprüft werden. Das exclude erfolgt dann beispielhaft so:

    <dependency>
      <groupId>sample.groupId</groupId>
      <artifactId>sample.artifactId</artifactId>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
        </exclusion>
      </exclusions> 
    </dependency>

Podcast und Slides von Chris Chedgey’s Talk Restructuring: Improving the modularity of an existing code-base

Chris hat uns dankenswerter Weise die Tonaufnahme und die Folien zur Verfügung gestellt.

Die Slides sind aktualisiert und enthalten Beispiele der Restructuring Strategies! Schaut sie euch ruhig noch mal an.