Si vous suivez ce blog, peut-être que vous connaissez forcément quelqu’un qui voudrait travailler chez nous. Voici la fiche :
Type de contrat : CDI
Secteur d’activité : informatique, système d’information voyageurs, transport
Lieu : Paris 12ème
|
||||||
|
Les technologies du web évoluent à une vitesse fulgurante et il devient quasiment obligatoire pour tout développeur de se tenir informé des outils et bibliothèques qui peuvent lui prêter main forte dans sa tâche. En tant que développeur / intégrateur, je suis amené à manipuler du code HTML et surtout CSS. Et même si on peut déjà faire de grandes choses avec, on se heurte à quelques difficultés et limitations qui peuvent nuire à la productivité et même à la maintenabilité. Continue reading Compass à la rescousse de l’intégrateur web ! La partie la plus visible de l’information voyageur est le calcul d’itinéraire. J’en avais déjà présenté les particularités lors d’un billet précédent : http://labs.canaltp.fr/2012/06/calcul_itineraire_chiffres_et_difficultes/. Cependant, le diable étant dans les détails, il arrive que l’on tombe sur un problème algorithmiquement difficile, en regard d’un besoin qui nous semblait trivial : afficher la grille horaire d’une ligne. C’est Vincent qui s’est attaqué à ce problème puisque nous n’étions pas pleinement satisfaits de l’existant. On adore les logiciels Libres et on s’en sert massivement (note personnelle : faire un article sur notre environnement de développement). Cependant nos contributions au monde libre s’étaient limitées jusqu’à présent à des déclaration de bugs (dans Qt Creator, Boost ou encore GEOS). On veut aller plus loin pour de nombreuses raisons (s’obliger à mieux découper les composants, les documenter, augmenter la notoriété de CanalTP, faire plaisir aux employés utopistes…), mais il était difficile de savoir par quel bout s’y attaquer. Continue reading Libération d’un ([tout] petit) bout de code Suite à la lecture de l’article de Transid ici, j’ai voulu faire un petit focus sur un scénario de l’utilisation des Google Cars : et si elles remettaient complètement en cause le transport en commun ? Bon, on est d’accord, ce serait le moindre des bouleversements engendrés. Mais tout de même, une des utilisations probables sera la mise à disposition de ces véhicules sous forme de service, comme un taxi. Oui, mais un taxi interconnecté avec ses semblables, les autres google car et probablement avec un service d’aide à l’exploitation. Ca commence à ressembler à un système de transport public Continue reading Google Car et renouveau du transport public J’adore les cartes. Depuis 2004 on peut facilement contribuer à OpenStreetMap sur un mode comparable à Wikipedia. Cependant générer sa propre carte pour mettre en avant ce que l’on veut m’a toujours semblé insurmontable. C’était pourtant pas les exemples intéressants qui manquent (Paris 8-bits, Paris en aquarelles). Suite à certaines interrogations suscités par nos clients, j’ai essayé de comprendre les différents points de vue des Autorités Organisatrices de Transport (AOT), des transporteurs, et des développeurs au sujet de l’ouverture des données. Pour mémoire, deux grandes méthodes de mise à disposition des données sont mises en œuvre aujourd’hui:
Parmi les (nombreux) intentions de l’open data, je vais me concentrer sur l’objectivité dans l’utilisation des données. Continue reading Horaires de transport en commun : Open data et Open service Etude des webbroker cross-EDI Delphi/Lazarus Cet article aborde la problématique que nous avons rencontré en migrant le code source de NAViTiA de Delphi 2006 vers Lazarus: Lazarus étant cross-Plateforme, l’EDI ne fournit pas d’interface ISAPI/IIS. En supplément les interfaces client/serveur (versionnées) du framework NAViTiA n’étant pas embarquées dans un container/structure spécifique mais directement implémentées sur le protocole HTTP, il est donc nécessaire de choisir un broker HTTP dans lequel la formalisation (via un protocole comme XML-RPC ou via schema+object binding+JSON ou autre…) de l’interface est minimum. Continue reading Migration du Webbroker ISAPI DELPHI vers LAZARUS / FPC Dans le cadre d’un projet d’alertes Mail/SMS en temps réel pour un client exigeant des performances optimisées, Canal TP a mis en œuvre un protocole d’échange des données entre ms SQL Server et des serveurs de calcul. Cet échange est basé sur le format Protocol Buffer développé par Google, format facile à lire en C++. |
||||||
|
Copyright © 2013 Canal TP Labs - All Rights Reserved Powered by WordPress & Atahualpa |
||||||
. Du coup, on pourrait imaginer de mutualiser des déplacements… Ouaaaaah. On y a tous pensé !
Commentaires récents