Prestation : Développement du front office et du back office (wordpress). Refonte complète du système de datation pour permettre la plus grande flexibilité possible dans le choix des dates et des périodes. Ajaxification des pages d’accueil et de programmation. Développement d’un moteur de recherche avec suggestion basé sur Xapian. Site entièrement en deux langues (anglais/français). Version Desktop/Mobile avec détection automatique. Optimisation du SEO et intégration de microdata. Système de cache basé sur APC.

PHP5 / Javascript / CSS / html5

Site réalisé en collaboration avec ofeworks.com



Client : La Cigale, 2012

http://www.lacigale.fr/

Prestation : développement du front office et du back office (wordpress).

PHP5 / Javascript / CSS / html5

Site réalisé en collaboration avec ofeworks.com



Client : Klapshop, 2012

http://www.klapshop.com/

Prestation : développement du front office et du back office (wordpress).

PHP5 / Javascript / CSS / html5

Design par ofeworks.com



Projet Perso

http://www.songonomy.com/

Prestation : développement du front office et du back office (wordpress).

PHP5 / Javascript / CSS / html5

Client : Smartvalue, 2012

http://www.chic-mon-placard.com/

Prestation : développement de la carte interactive en Javascript / CSS3.

Client : FNE, 2011

http://www.fne.asso.fr/fr/nos-dossiers/elections-2012/la-carte-de-france/#LaCarte

Context

WordPress has a semi built-in search system that basically issues a “LIKE” query on the posts and comments contents to the SQL database that backs WordPress. This is usually considered very slow (there are some examples and performance comparisons to this end here) and if you need to search something else than the contents of the posts (which I did) you need to write a custom query anyway. So I started out trying the full-text indexing capabilities of MySQL (version 5.1).


To do this, and so as not to touch the basic WP table structure (to reduce risks of breaking on upgrade and things like that), I created a new table which would hold only the post ID and the data I wanted indexed (in this case the post title) in a column with a MySQL FULLTEXT index for natural language processing. Then throwing something like this :

$wpdb->get_results(
  $wpdb->prepare(
     "SELECT wposts.*
      FROM $wpdb->posts wposts, indexed_content_table ict
      WHERE
        wposts.ID = ict.post_id
        AND MATCH (ict.title) AGAINST (%s);"
     , $search)
);

would result in a set of posts that correspond to the query.


There are two issues with this though, the first one being that it is still relatively slow (you at least have to start up the WP system, 200ms minimum from what I have measured) and the second one being that it performs a search on full words only. That means that we have to expand the query somehow if we want to have a suggestion list as soon as the user types in text. There are a number of options you can pass along with the SQL query, but nothing that really does the job straight out of the box. One way of getting around this limitation is to reformat the indexed data and the query into something that can be processed and matched quickly (i.e. usually without wildcard expansion), and which yields coherent results. This can be done, at least in part, by using a trigram (or more generally n-gram) representation of the data. But we are still too slow for a practical suggestion box (about 300ms per query, i.e. per entered character in the search field) and, although we could bypass the WP loading scheme to tap directly into the database, I didn’t want to do that for several reasons, one of which is that using MySQL for full-text searches is really no fun at all. Ultimately, in my opinion, it would be nice to achieve something well below 100ms per query to make the experience as fluid as possible (the human eye has a refresh rate of about 100ms).

About Xapian

Xapian “is an Open Source Search Engine Library” (as defined on the website). It is written in C++ and has a great number of features and customisations available (I am using version 1.2.7). From what I’ve been able to gather, although without any real study I can find to back this up (and I may very well be totally wrong about this), Xapian is slightly outperformed by Lucene/Solr in larger settings (i.e. millions of documents distributed over a number of servers). On the other hand, Xapian is ultra light and has a small memory signature compared to Lucene based projects.


What I’m interested in here is that it is also magnitudes easier to set up than Lucene/Solr and that few WordPress sites grow to such a point that we could actually start having the kind of issues that appear with large sets. Finally, what really set me to using it is that it has fast, robust and simple PHP bindings (WP is PHP).


I’m not going to go into the details of Xapian here, they have all the documentation you might need for any setup and they have very responsive mailing lists from what I understand (haven’t actually used them myself though). What I can say is that it is very straightforward, and the basics (being insert, delete and search) are very easy to access and super fast.


Entries are called documents. To every document can be attached information in three different “forms” : term, value and data. The three forms have different uses which you can read all about here. The terms are generally the indexed part, but you can very easily induce extra text indexing with respect to the document however you like (i.e. the trigram representation already mentionned). Search results are filtered and sorted through the use of values (e.g. date range and such). And finally, the data is a blob that cannot be used for searching.

Putting Xapian into WordPress

To use Xapian on the system where WP is set up means you need to be on a proper server where you can install xapian-core and xapian-bindings for PHP (i.e. you can’t use simple hosting services, unless they support Xapian, which, I’m sure, is rare). Once installed, a very good source of inspiration to start interacting with Xapian through PHP can be found in the XapianWrapper.php script which can be found here. It would need to be changed a bit to fit your needs, but I think it’s a good base to start with. I recommend getting yourself acquainted with Xapian (if not already) and especially figuring out the proper query procedure you want to use and test it thoroughly before you put it into WP. I made the mistake of putting it in too early and lost a lot of time trying to figure out if bugs where coming from WP or Xapian.


The first thing to do is write (or not) your own wrapper to Xapian. In my case I wanted titles to be indexed while needing date as well as other filterings. So I started by creating my basic document structure with terms, values, data and indexing as needed (an example can be found in the index and index_row methods of the aforementionned wrapper). Similarly delete and, of course, search methods from the XapianWrapper script are also inspiring.


Once that is done, you need to index a document when it is published/untrashed in WordPress and remove it from the index when it is trashed and/or deleted. To do this, the usual WP way is to use hooks. To keep it simple, I’m only going to write about posts, you would have to do the same for pages, comments… For example, you can use the following hooks :

  add_action('publish_post', 'insert_into_Xapian');
  add_action('untrashed_post', 'insert_into_Xapian');

  add_action('delete_post', 'remove_from_Xapian');
  add_action('trashed_post', 'remove_from_Xapian');

where the functions can be something like this

  function insert_into_Xapian($post_id)
  {
    require_once('XapianWrapper.php');
    $x = new XapianWrapper();
    $p = get_post($post_id);

    $params = array( 'id'=>$post_id, 'title'=>$p->post_title, WHAT_YOU_NEED );
    $x->index( $params );
  }

  function remove_from_Xapian($post_id)
  {
    require_once('XapianWrapper.php');
    $x = new XapianWrapper();

    $params = array( 'id'=>$post_id, WHAT_YOU_NEED );
    $x->delete( $params );
}

That should index and delete your posts using the parameters you set up. Then you need something that calls Xapian directly to process searches upon request, which, in the form of a very simple PHP script can look like this :

  if (!isset($_GET['s']))
    exit();

  require_once('XapianWrapper.php');
  $x = new XapianWrapper();
  $search = urldecode($_GET['s']);

  $response = $x->search( $search );

  DO_STUFF_AND_PRINT($response);

With this method, on a relatively slow and moderately busy server, in testing on about 10000 documents, I have managed to bring response time down to around 50ms from 300ms which it was with the MySQL FULLTEXT version running through WP. That means that when you type in a query, you get the answer almost instantly in the suggestion box. Which is exactly what I wanted, thank you Xapian !

Some Stats

To wrap up I wanted to really test the speed difference, at the query level, between Xapian and MySQL FULLTEXT indices. To do this, I needed a lot of different titles which is basically what I’m calling a body of documents composed of texts of up to 10 to 15 words at most on average. The easiest I had on hand was to extract the titles of the articles from a dump of the English version of Wikipedia.


The methodology is as follows, I started out by extracting a certain number N of random title entries from the dump and indexing these in Xapian and in a dedicated MySQL table. Then, from this list of N documents I would extract 5 random sublists of 1000 entries and use these sublists to query the index (i.e. whatever the value of the total number of documents in the index, there will always be the same number of queries performed). I would then measure, as a function of N, the average time it would take for every query to run through the entire process (parsing and transforming the query, connecting to the DB, fetching and validating results and finally returning the answer). The graphs below show the results I obtained.








As you can see, for small database sizes, MySQL actually outperforms Xapian on my system. But, as soon as we hit the 10,000 documents mark, roles become reversed. MySQL’s performance degrades more rapidly with the total number of documents in the table than Xapian which manages to stay relatively flat. (Both in fact degrade somewhat linearly with N, but MySQL faster than Xapian).

In conclusion, it may not have been totally necessary to move away from MySQL to generate a full-text index on the pages, and actually, for reasonable database sizes (below 10,000 documents) MySQL performs better than Xapian. Why use Xapian, then ? Good question. For one, these tests are all performed locally, on a local MySQL installation on a local hard drive. It is quite standard that the database is accessed through a network which means extra lag. Xapian can be run through the network, but the idea here was to have a small enough index that it can sit locally without too much overhead. For 250,000 documents, both databases holding the same information, the complete index size was 132M for Xapian, with very little extra room needed for the library itself, vs 159M for MySQL which requires all the overhead that comes with the management system. Another reason I can think of, is that by seperating the search from the database, there is less chance of one (mainly the search) interfering with the other (the WP database). Indeed, while playing with MySQL FULLTEXT, I managed to lock the database fairly easily which meant the site was not accessible during that time. I was never able to achieve that with Xapian. I would also like to run the same tests with concurrent requests, but it’s more difficult to simulate concurrent accesses.


Overall it was more of an experiment in full-text indices and search engine performance than anything else. I am thinking, though, of maybe (if I have the time) adapting this into plugin form (with support for both Xapian and MySQL?), stay tuned for more.

Prestation : développement du front office et du back office (wordpress).

Optimisation du SEO pour la mise en avant du théâtre, adaptation du back-end wordpress pour la structure un peu particulière du site. Système de classement par date personnalisé.

PHP5 / Javascript / CSS / html5

Client : Les Gémeaux, 2011

http://www.lesgemeaux.com/

Prestation : Réalisation complète d’une ébauche pour le site avec système de pre-chargement des pages pour inclusion dans la page principale afin de présenter l’intégralité du site sur une page unique.
Conception d’un site avec cette présentation mono-page compatible SEO par gestion de liens internes crawlables mais transparents pour l’utilisateur. Développement intégral de la partie Javascript (scroll dynamique, réécriture url, AJAX…).

Javascript / CSS / HTML5

Client : Studio VASCO, 2011

Exemple en local: Etude Palais de Tokyo.

Prestation : Réalisation du player en html5 avec fallback vers flash pour les navigateurs non compatibles.
Le player est totalement skinnable et intégrable n’importe où à l’aide d’une iframe.
Grâce à la gestion de skin, ce player est réutilisable à volonté pour tout type d’utilisation.

Javascript / CSS / HTML5

Client : Because Music, 2011

Exemples sur les sites du Monde et de NME:

Ecoutez le nouvel album de Justice en exclusivité !

Hear Justice’s new album ‘Audio, Video, Disco’ in full



Une copie locale des deux players.

Prestation : développement des parties javascript et php ainsi que d’une partie de l’intégration avec WordPress. Déploiement du site.

PHP5 / Javascript / CSS / html5

Site réalisé en collaboration avec ofeworks.com

Client : Société Saint-Simon, 2011

http://www.saint-simon.net/

This means that to completely customize the transition as desired, you need to decide what coordinates you’re going to use for P1 and P2. Bezier curves are very common, but I couldn’t really find a good ‘in page’ helper solution. So I decided to build one for myself, what I came up with is below. In the left pane is the speed profile as a Bezier curve and on the right you can activate an animation that uses the corresponding profile.

In the left window you can see the current Bezier curve applied to the transformation and in the right you can see the effect in action (if your browser supports CSS3 transforms…) You can modify the Bezier curve by dragging the white points around. As you change the curve you can test the corresponding effect in the right window. The blue dot will move to the position of the click with the corresponding transition.


-> A full screen version can be found here.


Once you have those points coordinates, you need to apply the same effect to the mootools transitions. By default, there is no Bezier transition in mootools, so you need to define a custom one. This is made relatively easy through the Fx.Transitions Class provided by mootools which is a wrapper to the callback that you can use in all mootools transitions.


The way this works, relative to the Bezier curve above, the callback takes the x coordinate as a parameter and returns the y coordinate. Bezier curves are parametric, i.e. x and y coordinates are not directly linked, so you need to apply a little mathematics to get what you want (which is very similar to this).


Finally, this is done by the code below which takes the 2 points and returns the Fx.Transitions Object.

   function getBezierTransition(P1, P2)
   {
      var
        bzr = [P1.x, P1.y, P2.x, P2.y],
        bzrM = (function(p){ p.push(3*p[0], 3*p[2]-6*p[0], 1+3*p[0]-3*p[2]); return p; }.bind(this,bzr.slice(0)))(),
        bzrTrans = new Fx.Transition(
          function(x,p)
          {
            var t = x,
                nRefinementIterations = 15;

            while(nRefinementIterations--)
            {
              var t3 = Math.pow(t,3),
                  t2 = Math.pow(t,2),
                  currentx = t*p[4] + t2*p[5] + t3*p[6],
                  den = (p[4] + 2*t*p[5] + 3*t2*p[6]),
                  currentslope = (den==0)?.1:1.0/den;
              t -= (currentx - x)*(currentslope);
              t = Math.max(0, Math.min(1, t));
            } 

            var y = 3* Math.pow((1-t),2) * t * p[1] + 3 * (1-t) * Math.pow(t,2) * p[3] + Math.pow(t,3);  

            return y;
          }, bzrM);

          return bzrTrans;
      }

Once you have this, you can use the returned Object as the transition property of any of your mootools Fx effects.


On a final note, the calculations between the CSS3 and the Javascript transitions are being done independantly in the browser, there is a little jitter between the two, but in the end it’s all for fun anyway… It’s also a possible fallback solution when CSS3 transforms are not supported by the browser, although it seems like this would be overkill unless you really need the transition to be exactly the same.

Prestation : Le but de ce projet est de permettre de diffuser des tweets utilisateurs en direct lors d’événements. La prestation comporte donc plusieurs facettes.



La première consiste en la récupération de tweets en direct. Ceci est réalisé grâce aux APIs fournies par Twitter avec l’utilisation en parallèle du Streaming API et du Search API classique par souci de redondance. Ces tweets sont filtrés par l’intermédiaire d’un ensemble de mots clés modifiable à volonté par l’utilisation d’une interface dédiée. L’ensemble des tweets obtenus est sauvegardé en base locale sur le back-end et devient immédiatement disponible pour le traitement dans l’interface d’administration. Lors des tests, sur les mots clés les plus communs, le système est loin d’être saturé à déjà 100 tweets par seconde.



La deuxième facette consiste en une interface d’administration par page web. Celle-ci se doit d’être claire et précise avec une optimisation poussée du code pour permettre des aller/retour peu coûteux et rapides entre l’interface et le serveur de back-end. L’interface consiste en trois colonnes, la première fait défiler les tweets, la deuxième est une étape intermédiaire où l’on peut stocker et organiser les tweets par drag’n'drop avant de les envoyer dans la dernière colonne qui est la file d’attente finale. Les options de défilement, de temporisation, de play/pause et de filtrage sont aussi présents. Une version future prévoit l’utilisation de websockets pour améliorer encore la fluidité de communication avec le serveur.



La dernière facette correspond à l’affichage des tweets. Ceci est réalisé par l’utilisation d’une deuxième page web qui est intégralement contrôlée par l’interface d’administration à travers le back-end. Les 2 pages n’ont donc pas besoin d’être sur le même ordinateur ni au même endroit. Celle-ci est de plus paramétrable à souhait.

A venir, un blog post complet sur le sujet.

PHP / Javascript / HTML5 / mySQL

Client : Because Music, 2011

<script type="text/javascript">

  var _gaq = _gaq || [];

  _gaq.push(['_setAccount', 'UA-XXXXXX-X'])
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

Breaking this down, the first line defines the _gaq global Array without destroying any potential previous affectations. Then it pushes two sub-arrays into it with, the first setting the account info and the second the default behavior. Finally, the third step is what I am interested in here.

Enclosed within a scoping auto-executing function, the three lines create a DOM script element, define it as async and give it a src. Then it is inserted before the first script tag that exists on the page (which we know exists since we are calling this within a script tag).

As this is done from within an inline script, it can only be executed once the page has been parsed and javascript has started to execute.

Why do I find this interesting for my use? When using frameworks like Mootools or jQuery, you need to wait for the DOM and the framework to load before you can do anything. This usually requires attaching the init function to an event triggered by the framework when it is loaded. This, in turn, only happens after the DOM (or at least part of it) is ready. It can also be that you are waiting for the onreadystatechange event discussed earlier before triggering something.

In any case, you have to wait for an event before you trigger your init. Which is fine, but hardly as necessary as it would appear by how popular it is if you are factoring the whole page.

Indeed, when an asynchronously called script has loaded through the technique I am discussing, the DOM is already ready, that means you can immediately init as soon as it is reached. Although, when using a framework, you still need to insure you are loading it prior to any usage you might have of it. To do this I simply append my code to that of the framework. And thus it also has the side effect of reducing the total number of script files to retrieve to a single file.

This can only really be used if it is not imperative that the javascript be ready before the page is loaded in itself, but I usually find it is good practice to always code with this objective. I have often found that, in any case, it is better to have something quickly loaded and displayed.

In practice, what does it look like? All pages don’t necessarily need the same code to be executed, but as I want to cache everything client-side as early as possible and limit the number of file retrievals, I want to load the whole javascript in one go early on. So, I further the inspiration from the analytics, I create an Array object onto which I push the parameters of the page and then these are read once the async source is ready.

Here’s an example adapted from one of my projects :

<script type="text/javascript">

  var gVar = gVar || [];
  (function() {
    gVar.push(["function1",['param1','param2']]);
    gVar.push(["function2",['param1','param2','param3']]);
    ...

    var d=document,g=d.createElement("script"),s=d.getElementsByTagName("script")[0];
    g.type="text/javascript";g.defer=true;g.async=true;g.src="source.js";s.parentNode.insertBefore(g,s);
  })();

</script>

In this, case, the global array is called ‘gVar’. The bulk of the javascript is contained within “source.js” and this is where gVar is interpreted to load the corresponding objects to deal the dynamic elements on the page. The interpretation could look something like this :

  for (var _el=0, gl=gVar.length; _el != gl; ++_el)
  {
    if(gVar[_el][0] == "function1")
      dealWithFunction1(gVar[_el][1]);
    if(gVar[_el][0] == "function2" && gVar[_el][1].length == 3)
      dealWithFunction2(gVar[_el][1]);
    ...
  }

Which in effect takes over the role of a global init function. This is my way of doing it, but there are plenty of other ways. If you don’t need the parameters, you could just initialize a variable to a certain value, which, once read, will trigger a certain chain within your code. Also, I’ve tried this on all relatively recent browsers.

That wraps the gist if the idea. Again, this requires complete control over the page’s code. If you don’t have that, a number of fallbacks are possible and are becoming more and more popular which can only be a good thing towards making the net a faster place…

Prestation : réintégration complète des deux pages pour les rendre à la fois compatibles html5 avec fallback flash et pour intégrer le contenu médias de ces pages avec l’interface d’administration de WordPress.
Développement des players pour permettre l’inclusion des médias directement dans les articles à partir d’une interface simplifiée de la partie admin.
Mise en place d’un nouvel uploader html5 pour que les utilisateurs puissent partager leur musique sur le site.

PHP / Javascript / CSS / HTML5

Client : Because Music, 2011

Tevelina sur manuchao.net

Radiolina sur manuchao.net

  <div id="global">
    <a href="bigpic.jpg"><img src="thumbnail.jpg" alt="some text about the image"/></a>
    ...
  </div>

For those unfamiliar with mootools, once everything is loaded, to launch the Wall you simply need to write (replacing ‘global’ with the id you have chosen for the container) :

  <script type="text/javascript">
    var gallery;
    window.addEvent('domready',function(){
      gallery = new Wall('global');
    });
  </script>

and you’re done.


As a mootools Class, there are options you can pass upon instantiation of the gallery. These are mostly useful to control the ‘title’ text of the added elements. The complete list and defaults :

showAlt: true   => displays the alt text of the thumbnail on hover within the gallery
magnify: true   => if set to false, you cannot go to zoom mode (not really of any use...)

magnifyText: 'Magnify'   => the title text of the magnify icon
closemagnifyText: 'Back to gallery mode'   => the title text of the close buttons

callbackOnImLoad:null   => a callback function for image loads, it takes one argument : the image element

(and a few more only those that know mootools will want to see and they are self explanotory within the code...)

To use these options, you need to modify the syntax of the instantiation to something like this :

gallery = new Wall('global', {option1:value1, option2:value2...});

If, like me, you use an analytics, you might find useful the ‘callbackOnImLoad’ option. It allows the definition of a callback function triggered when a picture is ‘seen’ by the user. As an example, in the demo it is integrated with my google analytics tracker and sends an event whenever an image is loaded (in zoomed mode only, the hover doesn’t do any tracking). That way, in the “Event Tracking” submenu of “Content” on my analytics page, I can see what pictures are the most popular.

As for styling, most of it is done via CSS. The classes you might need to modify are all present in the wall.css included in the bundle. The parts that are not in the CSS concern image positionning and things like that, so shouldn’t be of concern.


Please feel free to contact me with any feedback and/or suggestions you might have using my contact page. Have fun…

Prestation : refonte complète du site d’une version flash vers une version html/css/javascript pour assurer la compatibilité avec les devices (iphone, ipad, android…)
Développement d’une interface pour insérer tout type de player vidéo/audio le plus simplement possible. Dans le cas présent intégration de l’API iframe Youtube et création d’un lecteur audio html5 avec fallback flash (jwplayer) quand le navigateur n’est pas compatible. (Développement prévu d’une API javascript complète). Optimisation d’une partie du PHP.

PHP / Javascript / CSS / HTML5

Client : Because Music, 2011

http://www.molotov4.com/

Prestation : développement d’une page unique dans le but de présenter l’ensemble des informations utiles le plus simplement possible.
Mise en place d’un back end adapté et personnalisé (à partir de wordpress) afin de facilité les mises à jours et la cohérence du site. Site en deux langues (français / anglais).

PHP / Javascript / CSS / HTML5

Client : Le PADAC via Basilic Studio, 2011

http://www.padac.fr/

Prestation : développement d’une page unique où le contenu est affiché par le déplacement de la souris au dessus de la page (ou du doigt sur les devices).
Intégration d’un player audio html5 avec fallback flash (jwplayer) si non supporté. Pour être compatible avec tous les browsers, le “pinhole” est géré uniquement en javascript sans l’aide de canvas.

Javascript / CSS / HTML5

Client : Because Music, 2011

Lien vers une copie locale

(En page d’accueil sur http://www.amadou-mariam.com/ durant le mois de juillet 2011)

Prestation : développement du front office et du back office (wordpress).
Gestion (front et back) de l’arborescence des menus et sous-menus, slider photos, intégration d’un player vidéo local.

PHP5 / Javascript / CSS / xHTML / HTML5

Client : Nathalie Canguilhem, 2011

http://www.nevermind.tv/

Prestation : développement intégral de la page TV. Refonte d’une partie des pages News et Artistes ainsi que de la page d’Accueil.
Installation complète du site sur un nouveau serveur avec gestion du cache et optimisation pour rendre la navigation plus fluide.
Intégration de la partie vidéo sur la page d’accueil et de la partie photo/video sur les pages artistes. Ajout des fonctionnalités rendant le site compatible avec les devices (iPhone/iPad/Andoid…).

PHP / Javascript / CSS / xHTML / Flash / Administration Linux

Client : Because Music, 2011

http://www.because.tv/

Prestation : développement du front office et du back office (wordpress).
Optimisation du SEO pour la mise en avant du théâtre, adaptation du back-end wordpress pour la structure un peu particulière du site, mise en place d’un captcha “maison”.

PHP5 / Javascript / CSS / xHTML

Client : Les Gémeaux, 2011

http://www.lesgemeaux.com/

Prestation : développement du front office et du back office (wordpress).
Mise en place d’un uploader avec captcha pour l’espace blog participatif. Intégration de W3 Total Cache avec utilisation d’un CDN (AWS) avec répartition du site sur plusieurs serveurs “load balancés”.

PHP5 / Javascript / CSS / xHTML / Administration Linux

Client : Because Music, 2011

http://keny-arkana.com/

Prestation : développement des pages cités et intégration dans le back office (WordPress)

PHP5 / Javascript / CSS / xHTML

Client : Because Music, 2011

http://www.antoineleonpaul.com/

Prestation : développement du front office et du back office (wordpress).
Site en deux langues.
Écriture d’un module d’intégration automatique du feed Twitter.

PHP5 / Javascript / CSS / xHTML

Client : Because Music, 2011

http://www.selahsue.com/

Prestation : développement du front office et du back office (wordpress).

PHP5 / Javascript / CSS / xHTML

Client : Thomas Henault, 2010

http://cieu.fr/

Prestation : développement de la page vidéos. Intégrations des boucles vidéos de la home du site.

Javascript / CSS / xHTML

Client : Ünkut, 2010

http://www.unkut.fr/videos.html

Prestation : développement de la page unique avec feed automatique des images au cours du scroll en AJAX (combinaison Javascript / PHP). Écriture du back office pour l’upload et la gestion des images. Protection rudimentaire des images contre le linkage externe.

PHP5 / Javascript / CSS / xHTML

Client : Georges&MonBizarre, 2010

http://www.georgesetmonbizarre.com/

Prestation : refonte complète du template de la page calendrier pour permettre une mise en forme plus naturelle des jours de chaque mois et une meilleure mise en avant des sponsors de chaque jour.
Développement des parties back-end et front-end intégrées dans WordPress. Disposition automatique des jours, intégration avec l’API paypal, décompte automatique des jours restants et présentation de l’ensemble de la page.

PHP / Javascript / CSS / xHTML

Client : Torsologo, 2011

http://www.torsologo.com/?mois=fevrier (En exemple, la page du mois de février sur Torsologo)