07 Feb 2016

feedPlanet Grep

Mark Van den Borre: Een monument is niet meer


Vaarwel Eddy!

07 Feb 2016 10:43am GMT

05 Feb 2016

feedPlanet Grep

Julien Pivotto: puppetlabs-concat 2.0

If you are a Puppet user, you know that you have multiple choices regarding the way you manage your files. You might decide to manage the whole file or parts of it. I presented that as part of my augeas talk at PuppetCamp London in 2014.

One of the solutions out there is concat. Concats allows you to define parts of a file as different resources, then glue them together to create a single file.

In the past, the Puppetlabs concat module was made out of defined types, such as it seemed very fragile or unreliable. It created temporary files, required a setup class, and other stuff that could have been done internally in a custom type/provider.

On the other hand, some people decided to actually write concat as a provider. They created the Puppet module theforeman-concat_native, which was a really nice solution to the concat problems. From the catalog you only see the concat resources, and not all the temporary files, directories and exec that were needed by the Puppetlabs concat modules.

What I want to tell you today is that the Foreman module, which was really great, is now deprecated because its changes are available in the Puppetlabs module itself (in the 2.x releases). And it is almost compatible with the old one, as it provides backwards-compatible defines.

What it will change for you:

This article has been written by Julien Pivotto and is licensed under a Creative Commons Attribution 4.0 International License.

05 Feb 2016 3:50pm GMT

03 Feb 2016

feedPlanet Grep

Jeroen De Dauw: Missing in PHP7: Value objects

This is the second post in my Missing in PHP7 series. The previous one is about named parameters.

A Value Object does not have an identity, which means that if you have two of them with the same data, they are considered equal (take two latitude, longitude pairs for instance). Generally they are immutable and do not have methods beyond simple getters.

Such objects are a key building block in Domain Driven Design, and one of the common types of objects even in well designed codebases that do not follow Domain Driven Design. My current project at Wikimedia Deutschland by and large follows the "Clean Architecture" architecture, which means that each "use case" or "interactor" comes with two value objects: a request model and a response model. Those are certainly not the only Value Objects, and by the time this relatively small application is done, we're likely to have over 50 of them. This makes it real unfortunate that PHP makes it such a pain to create Value Objects, even though it certainly does not prevent you from doing so.

Let's look at an example of such a Value Object:

class ContactRequest {

        private $firstName;
        private $lastName;
        private $emailAddress;
        private $subject;
        private $messageBody;

        public function __construct( string $firstName, string $lastName, string $emailAddress, string $subject, string $messageBody ) {
                $this->firstName = $firstName;
                $this->lastName = $lastName;
                $this->emailAddress = $emailAddress;
                $this->subject = $subject;
                $this->messageBody = $messageBody;
        }

        public function getFirstName(): string {
                return $this->firstName;
        }

        public function getLastName(): string {
                return $this->lastName;
        }

        public function getEmailAddress(): string {
                return $this->emailAddress;
        }

        public function getSubject(): string {
                return $this->subject;
        }

        public function getMessageBody(): string {
                return $this->messageBody;
        }

}

As you can see, this is a very simple class. So what the smag am I complaining about? Three different things actually.

1. Initialization sucks

If you've read my previous post in the series, you probably saw this one coming. Indeed, I mentioned Value Objects at the end of that post. Why does it suck?

new ContactRequest( 'Nyan', 'Cat', 'maxwells-demon@entopywins.wtf', 'Kittens', 'Kittens are awesome' );

The lack of named parameters forces one to use a positional list of non-named arguments, which is bad for readability and is error prone. Of course one can create a PersonName Value Object with first- and last name fields, and some kind of partial email message Value Object. This only partially mitigates the problem though.

There are some ways around this, though none of them are nice. An obvious fix with an equally obvious downside is to have a Builder using a Fluent Interface for each Value Object. To me the added clutter sufficiently complicates the program to undo the benefits gained from removing the positional unnamed argument lists.

Another approach to avoid the positional list is to not use the constructor at all, and instead rely on setters. This does unfortunately introduce two new problems. Firstly, the Value Object becomes mutable during its entire lifetime. While it might be clear to some people those setters should not be used, their presence suggests that there is nothing wrong with changing the object. Having to rely on such special understanding or on people reading documentation is certainly not good. Secondly, it becomes possible to construct an incomplete object, one that misses required fields, and pass it to the rest of the system. When there is no automated checking going on, people will end up doing this by mistake, and the errors might be very non-local, and thus hard to trace the source of.

Some time ago I tried out one approach to tackle both these problems introduced by using setters. I created a wonderfully named Trait to be used by Value Objects which use setters in the format of a Fluent Interface.

class ContactRequest {
        use ValueObjectsInPhpSuckBalls;

        private $firstName;
        // ...

        public function withFirstName( string $firstName ): self {
                $this->firstName = $firstName;
                return $this;
        }
        // ...

}

The trait provides a static newInstance method, enabling construction of the using Value Object as follows:

$contactRequest =
    ContactRequest::newInstance()
        ->withFirstName( 'Nyan' )
        ->withLastName( 'Cat' )
        // ...
        ->withMessageBody( 'Pink fluffy unicorns dancing on rainbows' );

The trait also provides some utility functions to check if the object was fully initialized, which by default will assume that a field with a null value was not initialized.

More recently I tried out another approach, also using a trait to be used by Value Objects: FreezableValueObject. One thing I wanted to change here compared to the previous approach is that the users of the initialized Value Object should not have to do anything different from or additional to what they would do for a more standard Value Object initialized via constructor call. Freezing is a very simple concept. An object starts out as being mutable, and then when freeze is called, modification stops being possible. This is achieved via a freeze method that when called sets a flag that is checked every time a setter is called. If a setter is called when the flag is set, an exception is thrown.

$contactRequest = ( new ContactRequest() )
        ->setFirstName( 'Nyan' )
        ->setLastName( 'Cat' )
        // ...
        ->withMessageBody( 'Pink fluffy unicorns dancing on rainbows' )
        ->freeze();

$contactRequest->setFirstName( 'Nyan' ); // boom

To also verify initialization is complete in the code that constructs the object, the trait provides a assertNoNullFields method which can be called together with freeze. (The name assertFieldsInitialized would actually be better, as the former leaks implementation details and ends up being incorrect if a class overrides it.)

A downside this second trait approach has over the first is that each Value Object needs to call the method that checks the freeze flag in every setter. This is something that is easy to forget, and thus another potential source of bugs. I have yet to investigate if the need for this can be removed via some reflection magic.

It's quite debatable if any of these approaches pay for themselves, and it's clear none of them are even close to being nice.

2. Duplication and clutter

For each part of a value object you need a constructor parameter (or setter), a field and a getter. This is a lot of boilerplate, and the not needed flexibility the class language construct provides, creates ample room for inconsistency. I've come across plenty of bugs in Value Objected caused by assignments to the wrong field in the constructor or returning of the wrong field in getters.

"Duplication is the primary enemy of a well-designed system."

― Robert C. Martin

(I actually disagree with the (wording of the) above quote and would replace "duplication" by "Complexity of interpretation and modification".)

3. Concept missing from language

It's important to convey intent with your code. Unclear intent causes time being wasted in programmers trying to understand the intent, and time being wasted in bugs caused by the intent not being understood. When Value Objects are classes, and many other things are classes, it might not be clear if a given class is intended to be a Value Object or not. This is especially a problem when there are more junior people in a project. Having a dedicated Value Object construct in the language itself would make intent unambiguous. It also forces conscious and explicit action to change the Value Object into something else, eliminating one avenue of code rot.

"Clean code never obscures the designers' intent but rather is full of crisp abstractions and straightforward lines of control."

― Grady Booch, author of Object-Oriented Analysis

I can haz

ValueObject ContactRequest {
    string $firstName;
    string $lastName;
    string $emailAddress;
}

// Construction of a new instance:
$contactRequest = new ContactRequest( firstName='Nyan', lastName='cat', emailAddress='something' );

// Access of the "fields":
$firstName = $contactRequest->firstName;

// Syntax error:
$contactRequest->firstName = 'hax';

See also

i-will-always-favor-value-objects

03 Feb 2016 7:17pm GMT

Frank Goossens: Autoptimize PowerUp sneak peak; Noptimize

In case you're wondering if those Autoptimize Power-Ups are still coming and if so how they'll look like and what they'll do;

AO powerup sneak peak: noptimize

So some quick pointers;

Next steps for me; register my "secondary activity as independent" (as I still have an official day-time job), get in touch with an accountant, decide on EDD vs Freemius, set up shop on optimizingmatters.com (probably including bbpress for support) and determine pricing (thinking a Euro/month actually for each PowerUp, what do you think?).

Exiting times ahead …

Possibly related twitterless twaddle:

03 Feb 2016 5:36pm GMT

Wouter Verhelst: OMFG, ls

alias ls='ls --color=auto -N'

Unfortunately it doesn't actually revert to the previous behaviour, but it's close enough.

03 Feb 2016 1:54pm GMT

Xavier Mertens: [SANS ISC Diary] Automating Vulnerability Scans

[The post [SANS ISC Diary] Automating Vulnerability Scans has been first published on /dev/random]

SANS ISCThe following diary was published on isc.sans.org: Automating Vulnerability Scans.

[The post [SANS ISC Diary] Automating Vulnerability Scans has been first published on /dev/random]

03 Feb 2016 8:28am GMT

02 Feb 2016

feedPlanet Grep

Johan Van de Wauw: Report of Geospatial@FOSDEM 2016


Last Sunday, during FOSDEM the second edition of the geospatial devroom was happening.
As said before we had a nice lineup with 15 presentations with topics ranging from established GIS tools, Open Streetmap, 3D visualisation and spatial databases.


Anyway, I did the first presentation on SAGA GIS, and I was happy to have some very nice slides prepared by other members of the SAGA community.

Next up was Hugo Mercier (Oslandia) who presented Tempus. Planning multimodal transportation is a very hard problem, and it was nice to see that you can actually get the sources of the whole project. Next up was Astrid Emde presenting Mapbender, an OSGeo project allowing one to create web SDI's easily.
The next talk by Zeeshan Ali, "Build a geo-aware OS" was one where I was looking forward to : the talk is not one you usually encounter during FOSS4G conferences, but an example of the crosspolination of technologies you get at FOSDEM. It shows how location can now be used in Gnome (and other projects building on FreeDesktop) using common API's.

Getting ready to add location using a raspberry zero

Next up we got a full room for the presentation of Margherita Di Leo and Anne Ghisla presenting the results of the Google Summer of code projects coached at OSGeo.
This is how we like our devroom: full!


Everything got even more crowded for the next talk by Tuukka Hastrup on open journey planning. As people kept trying to enter our room even though it was full, I decided to play doorkeeper and missed the actual talk.


For those who don't get it "FULL", stop entering!
But based on the feedback and the slides, I'm really looking forward to the video of the talk.
Still in a crowded room Ilya Zverev gave a talk about mapping with OSM with a phone . Rather than mapping using satellite imagery, it makes more sense to map when you are actually in the field.


The next talks were all focused on 3D. Thomas Bremer talked about how one could implement a flight simulator in javascript. He focused on the different components that could build such a simulator. I hope to see a demo of this soon. The next talk was on the integration of Openlayers and Cesium. I missed the talk myself (one has to get lunch at one point), but I got some nice feedback. The last talk in our 3D theme was Vincent Mora on iTowns, showing impressive Lidar scans of large parts of Paris. Even though many of us are still struggling with 2D, a lot of data collection is now 3D and I think GIS systems still have to catch up.

The next block of four presentations were all on databases. Starting of with MySQL GIS. I was pleasantly suprised by the presentation. MySQL and Oracle got some bad press in some open source communities, but I believe the way they are working on MySQL is examplary: not only is MySQL catching up quickly with other (spatial) databases, this is largely done by improving the underlying boost geometry library, which can be leveraged by other projects. Oracle is currently sponsoring 2 developers on that project.
Also Rasdaman, a raster array database extension for PostgreSQL was presented. Even though their use cases may currently be 'far from the bed' of many developers, I like the fact that they are not only implementing a product, but also shaping the standards (OGC and ISO) on the way.
The third presentation focused on the geographical capabilities of a completely different type of database: mongoDB. I see a lot of possibilities of this database for geodata which is not as structured as classic databases. Nice to see their performance is improving.
The last presentation in the on pivotal Greenplum database was sometimes hard to follow, but I will definitely check it out further: I was not aware of the database, but it is a parallel database based on Postgresql, meaning that postgis functionality can be used, but also the extensions for trajectory data which were the topic of the presentation.

Closing the devroom was a presentation on geocoding by Ervin Ruci, which is a topic where the performance of open solutions can still be improved a lot.


At the end of the day, the closing keynote of FOSDEM, which was given by the people of HOT OSM. A full Janson is always something special, and this is definitely true for a topic of a talk I'm so familiar with.


Closing Keynote about Humanitarian Openstreetmap

To conclude, I believe the devroom at FOSDEM was a great event, and I really think it has its special role compared to other events such as FOSS4G and State of the Map - the chance to meet other open source communities.

Videos of the day should be available soon, thanks to the incredible FOSDEM video team and Anne Ghisla and Thomas Gratier who helped with the camera/organisation.

02 Feb 2016 9:27pm GMT

Paul Cobbaut: ls uses quotes ?

paul@d:~$ mkdir newls
paul@d:~$ cd newls/
paul@d:~/newls$ touch a\ space
paul@d:~/newls$ ls
'a space'
paul@d:~/newls$

oh well...

paul@d:~/newls$ touch \'
paul@d:~/newls$ ls
''\''' 'a space'

What ?

02 Feb 2016 8:37pm GMT

Dries Buytaert: Dries meets the King and Queen of Belgium

A few weeks ago at Davos, I had the honor of meeting the King and Queen of Belgium. VTM, the main commercial television station in Belgium, captured the moment for the evening news. Proof in the video below!

02 Feb 2016 12:31pm GMT

01 Feb 2016

feedPlanet Grep

Jeroen De Dauw: Missing in PHP7: Named parameters

This is the second post in my Missing in PHP7 series. The previous one is about function references.

Readability of code is very important, and this is most certainly not readable:

getCatPictures( 10, 0, true );

You can make some guesses, and in a lot of cases you'll be passing in named variables.

getCatPictures( $limit, $offset, !$includeNonApproved );

It's even possible to create named variables where you would otherwise have none.

$limit = 10;
$offset = 0;
$approvedPicturesOnly = true;
getCatPictures( $limit, $offset, $approvedPicturesOnly );

This gains you naming of the arguments, at the cost of boilerplate, and worse, the cost of introducing local state. I'd hate to see such state be introduced even if the function did nothing else, and it only gets worse as the complexity and other state of the function increases.

Another way to improve the situation a little is by making the boolean flag more readable via usage of constants.

getCatPictures( 10, 0, CatPictureRepo::APPROVED_PICTURES_ONLY );

Of course, long argument lists and boolean flags are both things you want to avoid to begin with and are rarely needed when designing your functions well. It's however not possible to avoid all argument lists. Using the cat pictures example, the limit and offset parameters can not be removed.

getApprovedCatPictures( 10, 0 );

You can create a value object, though this just moves the problem to the constructor of said value object, and unless you create weird function specific value objects, this is only a partial move.

getApprovedCatPictures( new LimitOffset( 10, 0 ) );

An naive solution to this problem is to have a single parameter that is an associative array.

getApprovedCatPictures( [
    'limit' => 10,
    'offset' => 0
] );

The result of this is catastrophe. You are no longer able to see which parameters are required and supported from the function signature, or what their types are. You need to look at the implementation, where you are also forced to do a lot of checks before doing the actual job of the function. So many checks that they probably deserve their own function. Yay, recursion! Furthermore, static code analysis gets thrown out of the window, making it next to impossible for tools to assist with renaming a parameter or finding its usages.

What I'd like to be able to do is naming parameters with support from the language, as you can do in Python.

getApprovedCatPictures( limit=10, offset=0 );

To me this is not a small problem. Functions with more than 3 arguments might be rare in a well designed codebase, though even with fewer arguments readability suffers greatly. And there is an exception to the no more than 3 parameters per function: constructors. Unless you are being rather extreme and following Object Calisthenics, you'll have plenty of constructors where the lack of named parameters gets extra annoying. This is especially true for value objects, though that is a topic for another post.

01 Feb 2016 4:59pm GMT

Mattias Geniar: Slides: HTTP/2 for PHP developers

The post Slides: HTTP/2 for PHP developers appeared first on ma.ttias.be.

Last weekend I had the pleasure of speaking in the PHP & Friends room at FOSDEM, Brussels. The slides for my talk "HTTP/2 for PHP developers" are now available online at speakerdeck.

Embedded below:

I hope to be back next year!

The post Slides: HTTP/2 for PHP developers appeared first on ma.ttias.be.

Related posts:

  1. New presentation: HTTP/2: The Next Version of the Internet Last week, at a local PHP User-Group in Leuven, I...

01 Feb 2016 12:54pm GMT

31 Jan 2016

feedPlanet Grep

Mattias Geniar: A clean mailing list browser, focussing on readability

The post A clean mailing list browser, focussing on readability appeared first on ma.ttias.be.

I wrote a new frontend for viewing mailing list entries that I'd like to show you. Its focus is on readability, typography and a clean layout.

I've used Twitter's Bootstrap with Red Hat's Overpass font for a responsive and focussed layout.

Here's what it looks like. I think it's best compared against marc.info, our industry's de facto standard for mailing list archives.

First: the original.


marc_original


Next: the redesign.


marc_clean


I'm not entirely satisfied yet, but it'll do for now. More tweaks will surely follow.

My main focus was:

We often rely on mailing list communication to spread important news, there's no reason that can't have a nice and professional looking layout.

The new layout is up at marc.ttias.be (I may change the URL later, I'm not sure yet).

You're free to use it, of course. I now mirror the mailing lists that are closest to me, but if I'm missing one that you would like to follow -- just drop me a note. You'll know where to find me.

As for the technology involved, it's a pretty default setup:

To add a new mailinglist, all I have to do is add a new system user in the correct Linux group and subscribe (manually) to the mailing list. From there on, the indexing, listing etc. happens automatically.

This was a fun weekend-hack!

The post A clean mailing list browser, focussing on readability appeared first on ma.ttias.be.

Related posts:

  1. Posting my Varnish 3.0 configs to Github I've spent some time optimizing my own Varnish 3.0 VCL...
  2. Update: seo analyzer v0.3 Only a small update, I've fixed some errors in the...
  3. Introducing the Extended Mail Header Parser Time to introduce my latest (small) project: the Extended Mail...

31 Jan 2016 8:57pm GMT

Ruben Vermeersch: Show me the way

If you need further proof that OpenStreetMap is a great project, here's a very nice near real-time animation of the most recent edits: https://osmlab.github.io/show-me-the-way/

Show me the way

Seen today at FOSDEM, at the stand of the Humanitarian OpenStreetMap team which also deserves attention: https://hotosm.org


Comments | More on rocketeer.be | @rubenv on Twitter

31 Jan 2016 8:28pm GMT

30 Jan 2016

feedPlanet Grep

Jeroen De Dauw: Missing in PHP7: function references

This is the first post in my Missing in PHP7 series.

Over time, PHP has improved its capabilities with regards to functions. As of PHP 5.3 you can create anonymous functions and as of 5.4 you can use the callable type hint. However referencing a function still requires using a string.

call_user_func( 'globalFunctionName' );
call_user_func( 'SomeClass::staticFunction' );
call_user_func( [ $someObject, 'someMethod' ] );

Unlike in Languages such as Python, that do provide proper function references, tools provide no support for the PHP approach whatsoever. No autocompletion or type checking in your IDE. No warnings from static code analysis tools. No "find usages" support.

Example

A common place where I run into this limitation is when I have a method that needs to return a modified version of an input array.

public function someStuff( array $input ) {
    $output = [];

    foreach ( $input as $element ) {
        $output[] = $this->somePrivateMethod( $element );
    }

    return $output;
}

In such cases array_map and similar higher order functions are much nicer than creating additional state, doing an imperative loop and a bunch of assignments.

public function someStuff( array $input ) {
    return array_map(
        [ $this, 'somePrivateMethod' ],
        $input
    );
}

I consider the benefit of tool support big enough to prefer the following code over the above:

public function someStuff( array $input ) {
    return array_map(
        function( $element ) {
            return $this->somePrivateMethod( $element );
        },
        $input
    );
}

This does make the already hugely verbose array map even more verbose, and makes this one of these scenarios where I go "really PHP? really?" when I come across it.

Related: class references

A similar stringly-typed problem in PHP used to be creating mocks in PHPUnit. Which of course is not a PHP problem (in itself), though still something affecting many PHP projects.

$kittenRepo = $this->getMock( 'Awesome\Software\KittenRepo' );

This causes the same types of problems as the lack of function references. If you now rename or move KittenRepo, tools will not update these string references. If you try to find usages of the class, you'll miss this one, unless you do string search.

Luckily PHP 5.5 introduced the class:: construct, which allows doing the following:

$kittenRepo = $this->getMock( KittenRepo::class );

Where KittenRepo got imported with an use statement.

30 Jan 2016 10:28pm GMT

Jeroen De Dauw: Missing in PHP7

I've decided to start a series of short blog posts on how PHP gets in the way of creating of well designed applications, with a focus on missing features.PHP7

The language flamewar

PHP is one of those languages that people love to hate. Its standard library is widely inconsistent, and its gradual typing approach leaves fundamentalists in both the strongly typed and dynamically typed camps unsatisfied. The standard library of a language is important, and, amongst other things, it puts an upper bound to how nice an application written in a certain language can be. This upper bound is however not something you run into in practice. Most code out there suffers from all kinds of pathologies that have quite little to do with the language used, and are much more detrimental to understanding or changing the code than its language. I will take a well designed application in a language that is not that great (such as PHP) over a ball of mud in [insert the language you think is holy here] any day.

"That's the thing about people who think they hate computers. What they really hate is lousy programmers."

― Larry Niven

Well designed applications

By well designed application, I do not mean an application that uses at least 10 design patterns from the GoF book and complies with a bunch of design principles. It might well do that, however what I'm getting at is code that is easy to understand, maintain, modify, extend and verify the correctness of. In other words, code that provides high value to the customer.

"The purpose of software is to help people."

― Max Kanat-Alexander

Missing features

These will be outlined in upcoming blog posts which I will link here.

30 Jan 2016 9:47pm GMT

Les Jeudis du Libre: Mons, le 18 février : La recherche locale avec OscaR.cbls, expliquée à mon voisin

Logo OscarCe jeudi 18 février 2016 à 19h se déroulera la 46ème séance montoise des Jeudis du Libre de Belgique.

Le sujet de cette séance : La recherche locale avec OscaR.cbls, expliquée à mon voisin

Thématique : Algorithmique|Optimisation|Programmation|Développement

Public : Développeurs|étudiants|enseignants

L'animateur conférencier : Renaud De Landtsheer (CETIC)

Lieu de cette séance : Université de Mons, Faculté Polytechnique, Site Houdain, Rue de Houdain, 9, auditoire 3 (cf. ce plan sur le site de l'UMONS, ou la carte OSM). Entrée par la porte principale, au fond de la cour d'honneur. Suivre le fléchage à partir de là.

La participation sera gratuite et ne nécessitera que votre inscription nominative, de préférence préalable, ou à l'entrée de la séance. Merci d'indiquer votre intention en vous inscrivant via la page http://jeudisdulibre.fikket.com/. La séance sera suivie d'un verre de l'amitié (le tout sera terminé au plus tard à 22h).

Les Jeudis du Libre à Mons bénéficient aussi du soutien de nos partenaires : CETIC, Normation, OpenSides, MeaWeb et Phonoid.

Si vous êtes intéressé(e) par ce cycle mensuel, n'hésitez pas à consulter l'agenda et à vous inscrire sur la liste de diffusion afin de recevoir systématiquement les annonces.

Pour rappel, les Jeudis du Libre se veulent des espaces d'échanges autour de thématiques des Logiciels Libres. Les rencontres montoises se déroulent chaque troisième jeudi du mois, et sont organisées dans des locaux et en collaboration avec des Hautes Écoles et Facultés Universitaires montoises impliquées dans les formations d'informaticiens (UMONS, HEH et Condorcet), et avec le concours de l'A.S.B.L. LoLiGrUB, active dans la promotion des logiciels libres.

Description : OscaR est une librairie libre (LGPL) pour résoudre des problèmes d'optimisation. OscaR propose plusieurs moteurs d'optimisation : la recherche locale basée sur les contraintes, la programmation par contraintes, et la programmation linéaire. OscaR est implémenté en Scala.

L'exposé débutera avec les motivations qui ont conduit à la naissance de ce projet open source, du point de vue du CETIC, incluant la facilité de valorisation, la mutualisation des contributions, et les contributions spontanées et la crédibilité que le modèle open source donne au projet.

Après un aperçu général des différents moteurs d'OscaR, cet exposé se concentrera sur le moteur de recherche locale basée sur les contraintes. Il en présentera les grands principes avant de se concentrer sur la couche déclarative permettant de définir aisément un problème de recherche et d'exprimer de manière compacte des procédures de recherche locale.

30 Jan 2016 9:30am GMT