The developer's den

Deploying to Maven Central using GitHub Actions

Wed, 03 Feb 2021 19:52:00 +0000

I have this library that I work on from time to time, that I published on Maven Central. A few days ago I released a new version, and since I always forget what the exact mvn command is, what my GPG passphrase is, etc. I thought it would be a good opportunity to automate the release process using GitHub Actions.

I came across several outdated tutorials that create settings.xml and import GPG keys manually, but as of Feb. 2021 most of this is not needed anymore, thanks to recent changes in the setup-java action.

Prerequisites

From now on, I will assume that you already know how to deploy on Maven Central via Sonatype OSSRH. This means you created an account on Sonatype’s Jira, your local settings.xml is already configured and your pom.xml has a <plugins> section that looks more or less like this:

<build>
    <plugins>
        ...
        <plugin>
            <groupId>org.sonatype.plugins</groupId>
            <artifactId>nexus-staging-maven-plugin</artifactId>
            <version>1.6.8</version>
            <extensions>true</extensions>
            <configuration>
                <serverId>ossrh</serverId>
                <nexusUrl>https://oss.sonatype.org/</nexusUrl>
                <autoReleaseAfterClose>true</autoReleaseAfterClose>
            </configuration>
        </plugin>
        ...
    </plugins>
</build>

<profiles>
    <profile>
        <id>release</id>
        <build>
            <plugins>
                ...
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-gpg-plugin</artifactId>
                    <version>1.6</version>
                    <executions>
                        <execution>
                            <id>sign-artifacts</id>
                            <phase>verify</phase>
                            <goals>
                                <goal>sign</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
                ...
            </plugins>
        </build>
    </profile>
</profiles>

Entering GitHub Actions

Java Actions workflows often use a setup-java action which… well… sets up Java in the build runner:

...
    - name: Set up JDK 11
      uses: actions/setup-java@v1
      with:
        java-version: 11

I thought this action was only used to download a JDK, but it turns out it can do more than that: it also knows how to set up the runner to publish artifacts on Maven Central (or any <distributionManagement> configured in your pom.xml, for that matter):

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8

    - name: Build with Maven
      run: mvn -B package --file pom.xml

    - name: Set up Apache Maven Central
      uses: actions/setup-java@v1
      with: # running setup-java again overwrites the settings.xml
        java-version: 1.8
        server-id: maven # Value of the distributionManagement/repository/id field of the pom.xml
        server-username: MAVEN_USERNAME # env variable for username in deploy
        server-password: MAVEN_CENTRAL_TOKEN # env variable for token in deploy
        gpg-private-key: $ # Value of the GPG private key to import
        gpg-passphrase: MAVEN_GPG_PASSPHRASE # env variable for GPG private key passphrase

    - name: Publish to Apache Maven Central
      run: mvn deploy
      env:
        MAVEN_USERNAME: maven_username123
        MAVEN_CENTRAL_TOKEN: $
        MAVEN_GPG_PASSPHRASE: $

As explained in the readme, the second invocation of actions/setup-java@v1 will overwrite the runner’s settings.xml with your Sonatype credentials and GPG passphrase, using environment variables:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>maven</id>
      <username>${env.MAVEN_USERNAME}</username>
      <password>${env.MAVEN_CENTRAL_TOKEN}</password>
    </server>
    <server>
      <id>gpg.passphrase</id>
      <passphrase>${env.MAVEN_GPG_PASSPHRASE}</passphrase>
    </server>
  </servers>
</settings>

The private GPG key stored in the MAVEN_GPG_PRIVATE_KEY secret will also be imported in a GPG keychain, allowing maven-gpg-plugin to sign your artifacts correctly.

Adding the missing pieces

In order to make the workflow run smoothly, I needed two additional pieces of information that are not (yet) mentionned in the readme:

to fill the MAVEN_GPG_PRIVATE_KEY secret, you need to export your private GPG key using this command: gpg --armor --export-secret-keys KEY_ID
to avoid a gpg: signing failed: Inappropriate ioctl for device error, you need to configure maven-gpg-plugin like this:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-gpg-plugin</artifactId>
    <version>1.6</version>
    <configuration>
        <!-- Prevent gpg from using pinentry programs -->
        <gpgArguments>
            <arg>--pinentry-mode</arg>
            <arg>loopback</arg>
        </gpgArguments>
    </configuration>
    ...
</plugin>

Final note

Setting up this workflow was not that difficult, except for the two missing pieces that I fortunately fixed very easily, thanks to issues and comments from other people who had the same problem before me. 10/10, would recommend 😜.

My final release workflow is available on GitHub.

High performance IBM MQ & JMS applications

Sun, 04 Mar 2018 21:56:00 +0000

Using the JMS API to do messaging over IBM MQ is rather easy, but writing programs that perform well can be a bit tricky. In this post, I’m going to share a few tips I’ve gathered here and there that might help you write faster MQ+JMS applications.

My examples are based on MQ 9 and JMS 2.0 but most of the tips will likely work with other versions of these products, and some of them can even apply to other message brokers.

Tuning the client part

Cache stuff

The first thing to do is make sure that you are reusing JMS objects as much as possible. Creating a connection or a session usually requires a network exchange, which means it can introduce a significant overhead. While the creation of producers and consumers has less overhead, it’s good to know that these objets were designed to be reused, so you might as well take advantage of this and cache/reuse instances as much as possible.

If you are using Spring JMS, CachingConnectionFactory can wrap your connection factory to reuse a single connection, cache sessions and producers.

If your code is running in a Java EE application server, chances are that connections and sessions are already automatically cached, and calling close() on one of these objects will put it back in a pool.

Use non-persistent messages

Performance often comes at the cost of reliability. Depending on the requirements your application has, it can be acceptable to lose messages if the queue manager crashes. In that case, your application might expect a response to the lost message, not receive it and decide to send it again. This kind of scenario is most likely privileging performance over reliability, while still having a plan B in case something doesn’t go as expected.

To improve performance in such scenarios, it is best to use non-persistent messages. Persistent messages are used by queue managers to guarantee message delivery. In practice, this means that a message will be synchronously written to disk at the same time it is sent by the producer. As you can guess, the previous sentence makes it clear that persistent messages impact performance.

Now, to debunk a common misconception: there is no such thing as a persistent queue. Persistency is configured per message, and if a given message has no Persistence field set in its message descriptor (MQMD), then a queue can define a default persistence flag.

To send non persistent messages, specify a DeliveryMode when using a producer:

// on the whole producer
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

// on a single message
producer.send(message, DeliveryMode.NON_PERSISTENT, 3, 10000);

Be aware that JMS’ default mode is DeliveryMode.PERSISTENT, which means that even if you define your queue’s default persistence as “not persistent”, JMS will not care and send persistent messages when calling producer.send(message).

If you are using Spring JMS’ JmsTemplate, you can enable explicit QOS and set a default delivery mode:

@Bean
public JmsTemplate jmsTemplate() throws NamingException {
    JmsTemplate jmsTemplate = new JmsTemplate();

    jmsTemplate.setConnectionFactory(queueConnectionFactory());
    jmsTemplate.setExplicitQosEnabled(true);
    jmsTemplate.setDeliveryPersistent(false);

    return jmsTemplate;
}

If you are using a .bindings file to look up JMS objects from a JNDI context, you can configure JMSAdmin to set a default delivery mode on producers using the persistence property:

define q(MY.JNDI.Q) queue(MY_Q) qmgr(MY_QMGR) persistence(NON)

Lose the transaction

JMS Sessions can be transactional, but this has a cost. If your application does not need to do multiple operations in a single atomic transaction, then you can make your code a bit faster using non-transactional sessions:

// transactions are configured using the first parameter
Session session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

Change acknowledgement modes

When using non-transactional sessions, the queue manager has to find an alternative to commit() to make sure that a message was successfully consumed by a client application. This is achieved using aknowledgements. When a message is acknowledged, the queue manager knows that the delivery has been guaranteed and that this message can be discarded. JMS supports several acknowledgement modes:

In the default AUTO_ACKNOWLEDGE mode, a message will be automatically acknowledged when consumer.receive() returns a message, of when a MessageListener was successfully executed on a message.
In CLIENT_ACKNOWLEDGE mode, you have to manually call message.acknowledge(). If your application does more work after having received a message, you could acknowledge it immediately to relieve the queue manager of its duty and allow it to process the next message.
In DUPS_OK_ACKNOWLEDGE mode, you tell the queue manager that it’s okay for your application to reveive the same message more than once. Now that the ‘once and only once’ constraint is gone, the queue manager might take a few shortcuts to enhance performance, which could lead to a message being sent twice on rare occasions.

In theory, DUPS_OK_ACKNOWLEDGE should be the most performant mode, but in practice it means that you have to design your application to support duplicate messages. This could add complexity on multi-threaded or multi-instances applications.

Use read ahead and put async

“Read ahead” is a concept specific to IBM MQ. When this functionality is enabled and you are using non-transactional sessions, non-persistent messages can be pre-fetched in an internal buffer so that your application can consume the next message faster.

When you call the receive() method, the IBM MQ classes for JMS will fetch a list of messages, store them in this internal buffer, and return the first message to your application. The next calls to receive() will then take messages from this buffer instead of querying the queue manager. This can work because no transactions and non-persistent messages are involved, which means there is no hard requirement for guaranteed delivery and consistency.

Read ahead can be enabled on a queue like this:

((MQQueue) myQueue).setReadAheadAllowed(CommonConstants.WMQ_READ_AHEAD_ALLOWED_ENABLED);

Similar to read ahead that allows faster MQGETs, IBM MQ has a concept of “put async” that allows faster MQPUTs. In normal conditions, the queue manager sends back a confirmation that the request was processed. In put async mode, your application can put the next message without having to wait for this confirmation. This can be useful for custom injectors, in which you might want to inject messages as fast as possible.

Put async can be enabled on a queue like this:

((MQQueue) myQueue).setPutAsyncAllowed(CommonConstants.WMQ_PUT_ASYNC_ALLOWED_ENABLED);

Use bindings mode

IBM MQ supports two transport modes, i.e. two ways to connect a client application to a queue manager. The most common one is probably the client mode, which uses TCP/IP connections to connect to a server channel. They can be fast on loopback interfaces, but can easily make your application feel “slower” on physical network interfaces.

The second mode is called “bindings mode” (not to be confused with JNDI bindings!). In bindings mode, the client application uses JNI to connect to the queue manager directly using IPC. This means that your application must run on the same machine as the one running the queue manager, because it will be working “in memory” instead of using network connections.

The transport mode has to be configured on the connection factory:

MQConnectionFactory qcf = new MQQueueConnectionFactory();

// no need to specify a host/port/channel here
qcf.setTransportType(CommonConstants.WMQ_CM_BINDINGS);

Tuning the server part

Before mentioning what can be configured on the server side, here’s a reminder of the terminology related to MQ connections. An MQ ‘server’ consists of one or more queue managers (QM), each one managing one or more queues.

To access a queue from a JMS application, you have to get a Connection to the QM using a QueueConnectionFactory. When the ‘client’ transport is used (i.e. TCP/IP connections), connections are made to a specific channel. When an application connects to a channel, the QM creates what is called a channel instance.

Increase the number of channel instances

One way to increase the throughput of your application is to listen for incoming messages in more than one thread. This can be easily achieved in Spring JMS using concurrency, but you should be aware that there are several parameters in IBM MQ that control (limit) the number of network connections (channel instances) client applications can make.

A channel can define two parameters related to channel instances:

MAXINST: maximum number of channel instances
MAXINSTC: maximum number of channel instances per client application

These two parameters can be easily viewed and modified using MQ Explorer, in the channel properties page.

A third —less obvious— parameter can be configured at the queue manager level:

MaxChannels: maximum number of channel instances all channels combined

By default, 100 channel instances (network sockets) are allowed on a given queue manager. As we will see in the next section, it is important to be aware of this parameter. To change it, add/modify the following section in /var/mqm/qmgrs/MyQueueManager/qm.ini:

Channels:
    MaxChannels=200

If a channel defines MaxInst=200 but the QM defines MaxChannels=100, then only 100 channel instances will be allowed.

IBM MQ has a notion of “shared conversations”, meaning that multiple JMS connections/sessions can be shared on the same channel instance (TCP/IP connection). By default, this parameter is set to 10, but you can change the value in MQ Explorer in the channel properties page. Sharing conversations means that less network sockets will be used, which can sometimes be a good thing because it removes the overhead introduced each time a new network connection is opened. On the other end, this can also have a performance cost on applications that do long running operations on the same Session, like message listeners, because data from different sessions has to be ‘mixed’ in a same socket, then ‘unmixed’ on the other end.

Setting SHARECNV to 1 can improve performance dramatically in some cases, because the channel instance will be dedicated to a given Session. Beware though that it can lead to ‘connection refused’ errors very fast. As we saw in the previous section, queue managers only allow 100 channel instances by default. Assuming you don’t share conversations and your application is the only one using that queue manager, this means that if you start 50 consumers on 2 queues, you will end up with 1 JMS connection + 2*50 sessions = 101 channel instances, so the last thread won’t be able to start correctly.

When using SHARECNV=1, it is recommended to carefully determine the number of channel instances that will be used by your application, and adapt the parameters we saw in the previous section accordingly.

Of course, because shared conversations and channel instances apply to network connections, you don’t have to worry about all these parameters when using ‘bindings’ transport.

Links

Best practices to improve performance in JMS

High performance messaging

Guaranteed messaging with JMS

Programming a WebSphere MQ JMS Client for performance

Avoiding run-away numbers of channels

Ceylon + jOOQ = <3

Mon, 24 Aug 2015 19:25:00 +0000

So you want to try Ceylon on a new side project, but don’t feel like writing yet another boring command line application? In this article, I will show you how to set up a new Ceylon application that uses jOOQ seamlessly. We will see how easy it is to use Ceylon’s Java interoperability, and how easy it is to customize jOOQ and adapt it to Ceylon’s conventions. The sample application will use an existing database.

Creating a new project

The first step is to create a project in Ceylon IDE. We will create two Ceylon modules:

gen.example.jooq will contain classes generated by jOOQ’s code generator
example.jooq will contain “actual” code that uses those generated classes to query our existing database

Adding dependencies to jOOQ

Since jOOQ provides Maven dependencies, we will use Ceylon’s Maven support. In the project settings, under Ceylon Build > Module Repositories we will use Add Maven Repository... to configure our local m2 repo.

Now we can add dependencies to jOOQ, to Java and to ceylon.interop.java since the code will be generated in Java:


module gen.example.jooq "1.0.0" {
    shared import "org.jooq:jooq" "3.6.0";
    shared import "org.jooq:jooq-meta" "3.6.0";
    import "org.jooq:jooq-codegen" "3.6.0";
    
    shared import java.base "8";
    import java.jdbc "8";
    import javax.annotation "8";
    import ceylon.interop.java "1.1.1";
}

Some of the imports are shared because they will be reused in example.jooq, whereas the others are here for internal use only. The other module.ceylon will look like this:


module example.jooq "1.0.0" {
    import gen.example.jooq "1.0.0";

    import "mysql:mysql-connector-java" "5.1.36";
    import "com.zaxxer:HikariCP-java6" "2.3.9";
}

Note that we also import a MySQL driver and HikariCP to connect to our MySQL database.

Generating classes

We will use MySQL’s Sakila sample database. Once the database is downloaded and installed, generating our model classes consists of creating a configuration file named jooq-config.xml, then invoking org.jooq.util.GenerationTool.

Here’s how jooq-config.xml looks like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration xmlns="http://www.jooq.org/xsd/jooq-codegen-3.6.0.xsd">
  <!-- Configure the database connection here -->
  <jdbc>
    <driver>com.mysql.jdbc.Driver</driver>
    <url>jdbc:mysql://localhost:3306/sakila</url>
    <user>root</user>
    <password></password>
  </jdbc>

  <generator>
    <name>org.jooq.util.DefaultGenerator</name>
    
    <database>
      <name>org.jooq.util.mysql.MySQLDatabase</name>
      <inputSchema>sakila</inputSchema>
      <includes>.*</includes>
    </database>

    <target>
      <packageName>gen.example.jooq</packageName>
      <directory>./source</directory>
    </target>
    
    <generate>
    	<pojos>false</pojos>
    	<daos>false</daos>
    </generate>
  </generator>
</configuration>

The important thing to configure is the output directory: files will be generated in the source directory, under the package gen.example.jooq, this way they will be automatically included in the Ceylon module:

The only missing pieces are package.ceylon files that are needed in each subpackage, otherwise Ceylon’s type checker will not recognize them. It’s very easy to create them by hand, and they won’t be erased the next time we invoke the code generator.

Querying the database

We are now ready to produce actual code to query the database. To do that, we need to configure a data source. We will be using an object, since this is obviously a singleton:


object dataSource extends HikariDataSource() {
    
    shared void setup() {
        value mysqlDS = MysqlDataSource();
        mysqlDS.databaseName = "sakila";
        mysqlDS.user = "root";
        mysqlDS.setPassword("");
        
        dataSource = mysqlDS;
    }
}

We can now query the database, for example the table Actors:


shared void run() {
    dataSource.setup();
    
    value dsl = DSL.using(dataSource, SQLDialect.\iMYSQL);
    
    Result<ActorRecord> actors = dsl.selectFrom(Actor.\iACTOR).fetch();
    
    for (actor in CeylonIterable(actors)) {
        print("Actor ``actor.firstName`` ``actor.lastName``");
    }
}

We can easily iterate over a Result<ActorRecord> because it implements java.lang.Iterable, which can be adapted to a ceylon.language.Iterable using CeylonIterable.

Let’s see how more complex cases work:


value overdueRentals = dsl.select(
        concat(customer.\iLAST_NAME, 
               DSL.val(javaString(" ")),
               customer.\iFIRST_NAME).as("customer"),
        address.\iPHONE, film.\iTITLE
    )
    .from(rental)
    .join(customer).on(rental.\iCUSTOMER_ID.eq(customer.\iCUSTOMER_ID))
    .join(address).on(customer.\iADDRESS_ID.eq(address.\iADDRESS_ID))
    .join(inventory).on(rental.\iINVENTORY_ID.eq(inventory.\iINVENTORY_ID))
    .join(film).on(inventory.\iFILM_ID.eq(film.\iFILM_ID))
    .where(rental.\iRETURN_DATE.isNull())
    .and(
        timestampAdd(rental.\iRENTAL_DATE, film.\iRENTAL_DURATION, DatePart.\iDAY)
        .lt(currentTimestamp())
    )
    .limit(5)
    .fetch();
    
for (rental in CeylonIterable(overdueRentals)) {
    print("Customer ``rental.value1()``, phone ``rental.value2()``,
            title ``rental.value3()``");
}

This time, I used import aliases to transform things like Rental.\IRENTAL into a user-friendly rental:


import gen.example.jooq.tables {
    Actor,
    Customer {
        customer = \iCUSTOMER
    },
    Address {
        address = \iADDRESS
    },
    ...
}

Making things more Ceylon-friendly

Now that we know jOOQ can be easily used from Ceylon, let’s see how we can improve things a little.

Getting rid of \i

The Ceylon specification indicates that properties must begin with a lowercase character, so when we try to access Actor.ACTOR, we actually have to escape it to Actor.\iACTOR. We saw that it can be worked around using import aliases, but it becomes tedious if we also have to alias fields like Actor.ACTOR.ACTOR_ID.

jOOQ provides nice extension points in its code generator, one of them is custom generator strategies:

[Generator strategies] can be very useful if you want to inject custom behaviour into jOOQ’s code generator with respect to naming classes, members, methods, and other Java objects.

This is exactly what we are looking for, we just have to override the default strategy to generate field names in camelCase:

public class CamelCaseStrategy extends DefaultGeneratorStrategy {

    @Override
    public String getJavaIdentifier(Definition definition) {
        return org.jooq.tools.StringUtils.toCamelCaseLC(definition.getOutputName());
    }

}

And use it in jooq-config.xml:

<generator>
    ...
    <strategy>
        <name>example.jooq.CamelCaseStrategy</name>
    </strategy>
    ...
</generator>

After having regenerated our classes, the previous sample code feels more natural and ceylonic:


...
.from(rental)
.join(customer).on(rental.customerId.eq(customer.customerId))
.join(address).on(customer.addressId.eq(address.addressId))
.join(inventory).on(rental.inventoryId.eq(inventory.inventoryId))
.join(film).on(inventory.filmId.eq(film.filmId))
.where(rental.returnDate.isNull())
...

Using Ceylon types (`ceylon.language.*`)

You may have noticed that things can get ugly when we have to “force” the use of a Java type instead of a Ceylon type, for example String:


dsl.select(
    concat(customer.lastName, 
           val(javaString(" ")),
           customer.firstName)
)

javaString is a function that transforms a ceylon.language.String into a java.lang.String. Without it, jOOQ won’t recognize Ceylon types and instead will throw a nasty

Type class ceylon.language.String is not supported in dialect DEFAULT

Luckily for us, jOOQ also allows us to use our very own custom types during code generation. We just have to implement org.jooq.Converter, then configure when to use this converter. Let’s see how we can map SQL strings to ceylon.language.String instances:


import java.lang {
    JString = String,
}

shared class StringConverter() satisfies Converter<JString, String> {
    shared actual String? from(JString? t) => if (exists t) then t.string else null;
    
    shared actual Class<JString> fromType() => javaClass<JString>();
    
    shared actual JString? to(String? u) => if (exists u) then javaString(u) else null;
    
    shared actual Class<String> toType() => javaClass<String>();
}

Next, we have to let the generator know that we would like to use this converter for every string in the database (in jooq-config.xml):

<database>
 ...
 <customTypes>
    <customType>
       <name>CString</name>
       <type>ceylon.language.String</type>
       <converter>gen.example.jooq.StringConverter
       </converter>
    </customType>
 </customTypes>
   
 <forcedTypes>
    <forcedType>
       <name>CString</name>
       <types>varchar</types>
    </forcedType>
 </forcedTypes>
</database>

Each varchar column will now be mapped to a ceylon.lang.String:

This can then be repeated for integers, datetimes, etc.

Gotcha

Until version 3.6.x, jOOQ forces us to use an identity that extends java.lang.Number. This has two consequences for us:

if we replace java.lang.Integer with ceylon.language.Integer, the generated table classes will not compile because

Identity<R, ? extends Number> getIdentity()

will be overriden with

Identity<R, ceylon.language.Integer> getIdentity()

and ceylon.language.Integer does not extend Number
if we delete those overriden methods, everything will compile and will mostly run as expected, except for a few cases like this one.

Fortunately, this will be fixed in jOOQ 3.7.0.

Conclusion

This article showed that integrating jOOQ in your Ceylon project requires very little effort, thanks to jOOQ that is flexible enough to let us customize naming strategies and data types. This also proves that the Java interop provided by Ceylon works very well and allows us to reuse existing Java frameworks.

The source code for this article is available in a sample project on GitHub.

If you plan on integrating jOOQ in your own Ceylon project, I also started ceylon-jooq-adapter which allows easy integration of jOOQ in your Ceylon project. It contains what was covered in this article, but other features will be added in the future.

Monitorer ses logs avec Logstash

Tue, 17 Mar 2015 11:55:00 +0000

Lundi matin, aux environs de 9 h 30. Vous arrivez un peu en retard, mais bon c’était pour la bonne cause, il fallait impérativement finir de merger ces pull requests sur votre projet perso et vous en avez eu jusqu’à 3h du mat’. Même pas le temps d’aller prendre une boisson chaude pour se réveiller, le téléphone sonne : une anomalie ultra-bloquante-qui-va-mettre-en-péril-le-projet-c’est-pas-possible vient d’être ouverte, c’est la catastrophe bla bla bla… Classique, me direz-vous, mais comment trouver facilement l’origine du problème ?

Les logs, bien sûr !

Comme d’habitude, le ticket a été ouvert à l’arrache, il va falloir batailler ne serait-ce que pour avoir une heure approximative à laquelle le problème s’est produit. Vous vous connectez en SSH sur la machine de prod, lancez un vim + /var/log/jboss/server.log et c’est parti pour la recherche ! Ah, en fait il y a eu plein de stacktraces depuis minuit, c’est dingue ça… et évidemment, c’est pas très lisible. Bon, depuis combien de temps le problème existe ? Il va falloir faire un grep sur tous les logs pour voir si l’erreur a déjà été rencontrée auparavant. Et puis tant qu’à faire, autant jeter un œil à toutes ces autres erreurs qu’on a trouvées par hasard…

Un analyseur de logs à la rescousse

Mieux vaut prévenir que guérir¹ . L’idéal serait d’avoir un outil qui scrute automatiquement les logs à la recherche de WARN et d’ERROR. Il existe pas mal d’outils dans ce genre, comme quoi le problème est bien reconnu et adressé : Stack Hunter², Baretail ou encore Logstash. Dans cet article, je vais vous présenter Logstash, car il est gratuit, open source et multiplateforme (et parce qu’il faut bien faire un choix, après tout).

Mais que ce soit Logstash ou un autre, les principes généraux restent les mêmes. À partir de fichiers de logs, l’outil va découper chaque évènement en plusieurs champs (date, sévérité, origine, message, …), stocker les évènements et proposer une interface permettant de les visualiser et de les requêter de manière efficace. Les outils les plus avancés sauront même vous envoyer un SMS, un courriel ou faire miauler votre chat en morse pour vous avertir d’un nouveau problème !

Ship logs from any source, parse them, get the right timestamp, index them, and search them.

Installation et utilisation de Logstash

L’installation de Logstash est simple comme hello world. Il suffit de récupérer l’archive de la dernière version sur le site officiel, de l’extraire et voilà ! En regardant rapidement le contenu extrait, on remarque que l’application est faite en Ruby (avec un JRuby pour l’exécuter), et qu’elle embarque Elasticsearch et Kibana avec elle.

Comme l’indique le tutoriel, la manière la plus simple d’utiliser Logstash est la suivante :

bin/logstash -e 'input { stdin { } } output { stdout {} }'

Le flag -e permet de spécifier la configuration dans la ligne de commande : les données en entrée seront prises dans stdin, et le résultat sera envoyé vers stdout. En tapant un message dans la console, Logstash réagit immédiatement :

hello world
2013-11-21T01:22:14.405+0000 0.0.0.0 hello world

L’évènement généré se découpe en 3 champs : une date, une IP d’origine et un message.

OK pour le hello world, maintenant il faut gérer un cas plus complexe, à savoir des logs serveur ayant une forme ressemblant à ceci :

2015-03-16 13:37:42 ERROR prod.acme.com - p.t.d.r.MyClass - Une erreur est survenue, bla bla bla administrateur bla bla réessayer dans quelques minutes

Et puis tant qu’à faire, on voudrait bien stocker les évènements parsés pour pouvoir les requêter par la suite. C’est le moment de vous expliquer comment fonctionne la configuration de Logstash. Le traitement d’un évènement se divise en plusieurs phase : les Inputs, les Filters, les Outputs et les Codecs. La configuration simpliste de tout à l’heure (input { stdin { } } output { stdout {} }) ne contenait qu’un input et un output. Au lieu de stdout, nous voulons stocker (output) les données dans une base Elasticearch. Au lieu d’un simple message, nous voulons parser (filter) des logs serveur (input). La configuration ressemblerait alors à ceci :

input {
  file {
    type => "myServerLogs"
    path => ["/var/log/jboss/server.log"]
  }
}

filter {
  grok {
     match => [ "message", "%{TIME:logtime}%{SPACE}%{LOGLEVEL:rawlevel}%{SPACE}%{DATA:machine}%{SPACE}-%{SPACE}%{JAVACLASS:class}%{SPACE}-%{SPACE}%{GREEDYDATA:message}" ]
  }

  date {
    match => [ "timestamp" , "yyyy-MM-dd HH:mm:ss" ]
  }
}

output {
  elasticsearch {
    embedded => true
  }
}

L’entrée est donc un fichier, et la sortie une base Elasticsearch embarquée. Le filtre utilise le plugin grok qui permet de structurer un texte quelconque. On lui indique que chaque message est formatté selon les placeholders indiqués, et grok va découper chaque ligne de cette manière.

La commande à lancer change en bin/logstash -f myConf.conf web. On demande à Logstash d’utiliser un fichier de configuration nommé myConf.conf et de lancer un serveur web pour visualiser le résultat. Une fois l’appli lancée, si on ajoute quelques lignes dans le fichier server.log, Logstash devrait les prendre en compte. Pour le vérifier, connectons-nous à l’adresse http://localhost:9292/. Miracle, une belle interface apparait. Il s’agit de Kibana, une interface de visualisation de données stockées dans une base Elasticseach (le monde est bien fait, hein). Kibana ne sait pas trop quoi faire, alors il nous propose plusieurs manières de configurer nous-même un dashboard répondant à nos attentes. Pour cela, nous allons cliquer sur le lien “Sample Dashboard - I don’t have much data yet, please extract some basics for me”, qui nous redirige vers un dashboard ultra générique :

La partie query permet de requêter les évènements, par exemple rawlevel:ERROR pour filtrer les logs ERROR. La partie filtering permet de filtrer les évènements affichés (semblable aux queries, mais appliqué tout le temps). De beaux graphiques permettent de visualiser rapidement les informations importantes (ici, la provenance des logs). Enfin, la partie basse liste les évènements. En cliquant sur une ligne, un tableau détaille chaque champ et sa valeur, ce qui confirme que nos logs ont bien été parsés :

Je vous laisse le soin de fouiner dans les possibilités offertes par Kibana, les dashboards seront très différent d’un projet à l’autre selon les besoins. Une recherche Google montre que l’on peut faire de très jolies choses (autant joindre l’utile à l’agréable).

J’aime pas parser les logs !

Tout ça est bien beau, mais en général les erreurs de nos chères applications Java sont accompagnées de leur fidèles sidekicks, les stack traces. Et comme on ne peut plus se passer de proxies Spring, de filtres et de toutes ces choses qui s’ajoutent à la pile d’appels, celle-ci tend à devenir gigantesque. Par conséquent, un seul évènement de log va se répercuter sur plusieurs lignes, qu’il va falloir agréger pour qu’on s’y retrouve dans Kibana. Plusieurs solutions s’offrent à nous :

utiliser le codec multiline en complément de grok pour agréger les lignes
faire en sorte de ne plus avoir à parser les fichiers de logs en intervenant en amont
??
la réponse d)

Je vous avoue que j’ai testé la première solution sans vraiment y arriver. Du coup, je me suis dit que la seconde solution serait intéressante si on avait la possibilité de se brancher directement sur SLF4J (comment ça, vous utilisez Log4J directement ?) pour envoyer les évènements à Elasticsearch sans passer par la case parsing.

C’est le moment d’appeler logstash-logback-encoder à la rescousse. Cet appender pour Logback permet d’encoder les messages loggués en JSON, puis d’envoyer le tout via une socket TCP à Logstash. Comme vous pouvez l’imaginer, le contenu JSON est directement structuré comme il faut, plus besoin de parser avec des regex, d’agréger des lignes, etc. Après avoir récupéré la bonne dépendance, la configuration du logback.xml est très simple :

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <appender name="stash" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
  	<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
  		<level>WARN</level>
	</filter>
    <host>127.0.0.1</host>
    <port>4560</port>
	<encoder class="net.logstash.logback.encoder.LogstashEncoder" />
  </appender>

  <root level="debug">
  	<appender-ref ref="STDOUT" />
    <appender-ref ref="stash" />
  </root>
</configuration>

Nous avons donc défini un appender basé sur une socket TCP, qui envoie les évènements sur 127.0.0.1:4560. L’encoder permet de sérialiser les données au format JSON. Notez que le niveau de logs par défaut est DEBUG, mais qu’il est possible de le restreindre par exemple à WARN en utilisant un ThresholdFilter, puisque nous ne sommes intéressés que par les WARN/ERROR. L’appender STDOUT continuera de logguer les niveaux >= DEBUG.

Côté Logstash, pour pouvoir recevoir correctement les évènements, on configure une entrée TCP, encodée en JSON, sur le port adéquat :

input {
  tcp {
    port => 4560
    codec => json
  }
}

Après redémarrage de Logstash, les évènements sont loggués comme prévu. Il est à noter que l’appender est asynchrone (LMAX Disruptor RingBuffer inside), il ne bloquera jamais le thread qui génère les logs. En cas de problème réseau, l’appender peut se reconnecter à Logstash. Si le buffer est plein, certains évènements peuvent toutefois être perdus.

Conclusion

J’espère que cet article vous a donné envie de tester Logstash sur votre projet. Comme vous avez pu le remarquer, la configuration est relativement simple lorsqu’il s’agit d’indexer les erreurs et stacktraces. Je n’ai volontairement pas compliqué les choses, mais sachez qu’il est possible de faire des choses relativements complexes aussi bien dans l’indexation des logs que dans les dashboards côté Kibana (largement de quoi s’adapter à votre configuration et vos besoins). De plus, Logstash est capable de parser tout et n’importe quoi, il propose par défaut une série de patterns permettant de parser des dates, des logs Apache, Syslog, Nagios, MongoDB etc.

Pour aller plus loin

Il parait que les allemands disent “La prévention est la mère de la caisse à porcelaine” ↩
Rien à voir avec mon projet perso, qui fait la même chose mais qui n’est pas aussi abouti ↩

Un switch annoté en Java

Fri, 02 Jul 2010 12:05:00 +0000

Un billet sur le blog de l’Agilitateur répondant à un billet sur le blog d’Excilys concernant les switchs en java me donne envie de parler un peu de codage en Java. Cet article est une variante du code C# proposé par Oaz en Java.

Je vais vous épargner toute la discussion sur le switch c'est bien / c'est nul, il y a déjà les commentaires enflammés sur le blog d'Excilys pour ça.

Passons directement au code : de la même manière qu'Oaz l'a fait, je dispose d'une interface Function qui définit le contrat que vont suivre les différents cas du switch. Pour que l'on sache que les différentes sous-classes sont bien des cases, on les annote avec un @Case créé pour l'occasion :

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface Case {
    String name();
}

On demande au compilateur de garder cette annotation au runtime (pour faire du scanning dynamique), et on précise qu'elle peut s'appliquer à un type (classe ou interface).

On peut alors utiliser l'annotation de cette façon :

public interface Function {
    void doYourJob();
}

@Case(name="bar")
public class BarFunction implements Function {

    public void doYourJob() {
        System.out.println("On va manger... des chips ! T'entends ? DES CHIPS !!");
    }
}

@Case(name="foo")
public class FooFunction implements Function {

    public void doYourJob() {
        System.out.println("Hi, my name is foo!");
    }
}

@Case(name="othercase")
public class OtherCase {

    public void doYourJob() {
        System.out.println("I'm not gonna be called :-(");
    }
}

Reste maintenant le plus dur à faire : scanner un package à la recherche de classes annotées @Case et qui héritent de notre classe de base (ici Function, mais on va essayer de rester génériques).

public class Switch<T> {

    private String packageName;
    private Map<String, T> cases;
    private Class<T> parentType;
    
    public Switch(String packageName, Class<T> parentType) {
        this.packageName = packageName;
        this.parentType = parentType;
        scanCases();
    }

    private void scanCases() {
        cases = new HashMap<String, T>();

        try {
            for (Class clazz : getClasses(packageName)) {
                if (clazz.isAnnotationPresent(Case.class) && isA(clazz, parentType)) {
                    Case theCase = (Case) clazz.getAnnotation(Case.class);
                    cases.put(theCase.name(), (T) clazz.newInstance());
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

        System.out.println("Scanned " + cases.size() + " cases.");
    }

    private boolean isA(Class clazz, Class<T> class1) {
        if (clazz.getSuperclass() == class1) {
            return true;
        }
        for (Class intf : clazz.getInterfaces()) {
            if (intf == class1) {
                return true;
            }
        }
        return false;
    }

    public T on(String caseName) throws IllegalArgumentException {
        if (cases.containsKey(caseName)) {
            return cases.get(caseName);
        } else {
            throw new IllegalArgumentException("The case " + caseName + " does not exist");
        }
    }

    private List<Class> getClasses(String pckgname) { ... }

J'ai fait appel au generic type introduit en Java5, cela permet d'avoir un switch acceptant n'importe quelle classe de base qu'implémentent les différents cas. J'ai été obligé de repasser cette information dans le constructeur car en Java il n'est pas possible de faire un T.class dans la phase de scan des classes (pour savoir si la classe scannée étend ou implémente T). À la place, on a donc un Class en second paramètre.</p>

La méthode scanCases va parcourir toutes les classes d'un package (grâce à la méthode getClasses() honteusement trouvée sur le forum de ~~Sun~~ Oracle). Pour chaque classe, on regarde si elle est annotée @Case et si elle étend ou implémente T. Si c'est le cas, on en ajoute une instance dans une Map avec le nom du cas comme clé.

Dernière étape : la méthode on() qui renvoie l'instance associée à un cas ou jette une exception s'il n'existe pas.

La glue entre tout ça, c'est un main assez simple :

public class Main {

    public static void main(String[] args) {
        Switch<Function> swi = new Switch<Function>("com.jansen.annotatedswitch.demo", Function.class);
        
        swi.on("foo").doYourJob();
        swi.on("bar").doYourJob();
        swi.on("othercase").doYourJob();
    }

}

Notez le dernier appel qui va planter : j'ai bien une classe annotée @Case(name="othercase") mais elle n'implémente pas Function (une ruse de sioux pour égarer le lecteur peu attentif ;-) ).

Conclusion : c'est aussi possible en Java, avec un peu de gymnastique intellectuelle pour arriver à faire ce qu'on souhaite avec les generics :P

Le logger de la mort

Thu, 04 Feb 2010 16:24:00 +0000

Parfois, au cours d'une mission chez un client, on tombe sur du code pas testé, et pas toujours prévu pour être testé non plus. Je vais présenter un cas sur lequel je suis tombé récemment, issu d'un assez gros projet Java EE en cours de développement.

Une classe de services X effectue une certain nombre de traitements. En cas d’erreur, au lieu de jeter une exception métier, un code d’erreur est loggué. Impossible d’utiliser un @Test(expected=...), donc. Fort heureusement, le champ logger dans X est une interface, potentiellement mockable :

interface Ilogger {
  public abstract void logError(final Key key, final Object... messages);
  // blabla
}

Dans tous les cas où nous sommes intéressés, la méthode logError est appelée avec un paramètre Key représentant le code d’erreur. Malheureusement, le logger n’est pas injecté dans un setter, et il est privé. On aimerait tout de même vérifier que l’erreur est bien logguée sous certaines conditions. Solution, un peu de réflexion pour forcer le champ logger à une instance que l’on contrôle :

public class MockLogger implements ILogger {
  private List<Key> loggedKeys;

  public MockLogger() {
    super();
    loggedKeys = new ArrayList&lt;Key&gt;();
  }

  public void logError(Key key, Object... messages) {
    loggedKeys.add(key);
  }

  public boolean wasLogged(Key key) {
    return loggedKeys.contains(key);
  }

  public void resetLogCalls() {
    loggedKeys.clear();
  }
}

La méthode resetLogCalls permet d’utiliser la même instance du logger sur plusieurs tests, il faut l’appeler dans une méthode annotée @After.

Il faut maintenant injecter notre propre logger dans le service testé :

Field f = serviceUnderTest.getClass().getDeclaredField("logger");
f.setAccessible(true);
f.set(serviceUnderTest, myLoggerInstance);
f.setAccessible(false);

Et voila, nous pouvons maintenant faire des assertTrue utilisant la méthode wasLogged et la Key nous intéressant ! Notez l’appel à Field#setAccessible(boolean) pour contourner le caractère private du champ logger (que l’on restaure par la suite).

Note : si le logger n’avait pas utilisé d’interface, nous aurions pu nous en sortir en créant une classe fille redéfinissant toutes les méthodes sans appels à super().

Contrôler la bande passante de sa machine linux

Tue, 03 Nov 2009 14:21:00 +0000

Le haut débit c'est bien, mais des fois on a quand même un côté nostalgique du 56k, soit parce qu'on a envie d'embêter les visiteurs de son serveur, soit parce que pour débugger une application (par exemple) on a envie que les données arrivent lentement. Sous linux, il existe la commande tc, pour traffic control, qui permet de contrôler ses connexions réseaux, notamment leur débit...

J'ai donc trouvé un script tout fait permettant de limiter la bande passante d'une interface réseau, en upload ou en download.

#!/bin/bash
#
#  tc uses the following units when passed as a parameter.
#  kbps: Kilobytes per second 
#  mbps: Megabytes per second
#  kbit: Kilobits per second
#  mbit: Megabits per second
#  bps: Bytes per second 
#       Amounts of data can be specified in:
#       kb or k: Kilobytes
#       mb or m: Megabytes
#       mbit: Megabits
#       kbit: Kilobits
#  To get the byte figure from bits, divide the number by 8 bit
#

#
# Name of the traffic control command.
TC=/sbin/tc

# The network interface we're planning on limiting bandwidth.
IF=eth0             # Interface

# Download limit (in mega bits)
DNLD=1mbit          # DOWNLOAD Limit

# Upload limit (in mega bits)
UPLD=1mbit          # UPLOAD Limit

# IP address of the machine we are controlling
IP=216.3.128.12     # Host IP

# Filter options for limiting the intended interface.
U32="$TC filter add dev $IF protocol ip parent 1:0 prio 1 u32"

start() {

# We'll use Hierarchical Token Bucket (HTB) to shape bandwidth.
# For detailed configuration options, please consult Linux man
# page.

    $TC qdisc add dev $IF root handle 1: htb default 30
    $TC class add dev $IF parent 1: classid 1:1 htb rate $DNLD
    $TC class add dev $IF parent 1: classid 1:2 htb rate $UPLD
    $U32 match ip dst $IP/32 flowid 1:1
    $U32 match ip src $IP/32 flowid 1:2

# The first line creates the root qdisc, and the next two lines
# create two child qdisc that are to be used to shape download 
# and upload bandwidth.
#
# The 4th and 5th line creates the filter to match the interface.
# The 'dst' IP address is used to limit download speed, and the 
# 'src' IP address is used to limit upload speed.

}

stop() {

# Stop the bandwidth shaping.
    $TC qdisc del dev $IF root

}

restart() {

# Self-explanatory.
    stop
    sleep 1
    start

}

show() {

# Display status of traffic control status.
    $TC -s qdisc ls dev $IF

}

case "$1" in

  start)

    echo -n "Starting bandwidth shaping: "
    start
    echo "done"
    ;;

  stop)

    echo -n "Stopping bandwidth shaping: "
    stop
    echo "done"
    ;;

  restart)

    echo -n "Restarting bandwidth shaping: "
    restart
    echo "done"
    ;;

  show)

    echo "Bandwidth shaping status for $IF:"
    show
    echo ""
    ;;

  *)

    pwd=$(pwd)
    echo "Usage: tc.bash {start|stop|restart|show}"
    ;;

esac

exit 0

Pourquoi Netbeans c'est bien

Wed, 25 Mar 2009 15:16:00 +0000

C'est un fait avéré, Netbeans c'est mieux qu'Eclipse. (comment ça, un troll tout poilu ?). Pas plus tard qu'il y a une minute, j'en ai refait l'heureuse expérience. Agacé de voir une série de getters/setters dans ma classe, qui sont triviaux à comprendre mais qui prennent de la place, j'ai voulu utiliser l'editor folding, propre à Netbeans (je crois, du moins). Ça consiste juste en deux commentaires autour du code que l'on veut folder (euh... comment traduit-on ça en français, déjà...) :

// <editor-fold defaultstate="collapsed" desc="getters and setters">
public Foo getFoo() { }
public void setFoo(Foo foo) { }
// </editor-fold>

Maintenant vous aurez un joli '-' sur la gauche qui permettra de cacher tout ça et qui affichera la description voulue (ici, "getters and setters").

Amusons-nous encore un peu, en transformant ça en code template :

Et c'est parti, sélectionnez un bloc de texte que vous ne voulez plus voir, puis cliquer sur l'ampoule dans la gutter et choisissez "Surround with an editor fold tag". Magique, non ?

Récupérer de la musique depuis Deezer

Thu, 19 Mar 2009 14:15:00 +0000

Même si je ne suis pas trop fan de Deezer pour diverses raisons (interface Flash trop lourde, beaucoup trop de pub, ...), je suis quand même bien content de pouvoir y rechercher une musique que j'ai en tête et que je peux récupérer pour la réécouter par la suite...

En effet, il est de notoriété publique que ce système met en cache la chason en cours d'écoute et la stocke dans un fichier flv nommé /tmp/Flash* sous linux.

À partir de là, il est facile de créer un script shell qui va se charger de récupérer ce ficher, puis d'en extraire la musique en MP3 et de la sauvegarder dans notre dossier de musique favori. Top du top, le script que je vous propose par la suite permet également d'éditer les tags ID3 et de renommer le fichier en conséquence, puis ajoute le morceau à la playlist Amarok en cours :D

Voici la bête :

#!/bin/bash

DEST=/home/user/Musique

cd $DEST

files=`ls /tmp/Flash* | cut -d '/' -f3`

for file in $files
do
        ffmpeg -i "/tmp/$file" -acodec copy -f mp3 "$DEST/$file.mp3"
        id3ren -quick -notrack -template "%a - %s.mp3" "$DEST/$file.mp3"
        dcop amarok playlist addMedia "$DEST/$file"
done

Security holes in symfony apps

Mon, 01 Dec 2008 21:52:00 +0000

symfony 1.2 was just released, and came along with a brand new advent calendar. The first day mentions two ways to set up your web server to host a symfony project. The ugly way seems to be very... ugly and crazy, putting your app directly in your webserver's root folder allows anyone to access all the files. But this security hole can be easily found in 'real' apps, as well as a few others...

This article will try to enumerate some of the mistakes that are often done when a symfony application is put in production environment.

Development environment is still present

These files, ending with _dev.php, are very useful when you are coding: they provide a lot of information on the configuration, the SQL queries that were executed, your PHP version etc. But on the other hand, they should never be accessible to your visitors (I mean, bad ones, you know, those who type in the darkness). They can show your kernel version, the symfony plugins which are installed, the escaping method you are using (or not using...), etc., which can lead to other vulnerabilities.

The project root is the webserver's root folder

This can also give a lot of information to an attacker, especially your database connection settings. Just search for 'web/frontend.php' in your favorite search engine, and you will have a bunch of apps which are potentially in this case. Then you just have to browse config/databases.yml and you get what you want. Just consider that if the application is unsecure, the webserver which is running it is also unsecure, and you can have a remote access to MySQL on port 3306, which will show you a lot of interesting things...

The backend is not protected

Harder to find, but not impossible. Even if this page is not indexed by search engines, it's quite easy to see if a web app is powered by symfony, and the majority of these web apps have a backend which is called 'backend' (if not, just try 'admin' :)). So it's very important to restrict access to this backend, as it can contain sensitive information (user accounts, etc.). Imagine that you didn't make a recent backup of your database, and that someone deletes all its content...

How to fix it?

It's not difficult to avoid these problems. In fact, the solutions are very well explained in the official symfony book, but nonetheless they are often not applied.

Check that *_dev.php files are not uploaded (see the rsync_excludes.txt file for example)
If you can, put the whole project (except the web/ folder) outside the web document root
Protect your backend with sfGuard, or at least a htaccess/htpasswd file :) (and do not user admin/admin or something like this)

The developer's den

Deploying to Maven Central using GitHub Actions

Prerequisites

Entering GitHub Actions

Adding the missing pieces

Final note

High performance IBM MQ & JMS applications

Tuning the client part

Cache stuff

Use non-persistent messages

Lose the transaction

Change acknowledgement modes

Use read ahead and put async

Use bindings mode

Tuning the server part

Increase the number of channel instances

Don’t share conversations

Links

Ceylon + jOOQ = <3

Creating a new project

Adding dependencies to jOOQ

Generating classes

Querying the database

Making things more Ceylon-friendly

Getting rid of \i

Using Ceylon types (ceylon.language.*)

Gotcha

Conclusion

Monitorer ses logs avec Logstash

Les logs, bien sûr !

Un analyseur de logs à la rescousse

Installation et utilisation de Logstash

J’aime pas parser les logs !

Conclusion

Pour aller plus loin

Un switch annoté en Java

Le logger de la mort

Contrôler la bande passante de sa machine linux

Pourquoi Netbeans c'est bien

Récupérer de la musique depuis Deezer

Security holes in symfony apps

Development environment is still present

The project root is the webserver's root folder

The backend is not protected

How to fix it?

Using Ceylon types (`ceylon.language.*`)