Diablo 3 arrive très bientôt mais en jouant à la beta, il y a un truc qui m’a un peu gêné, c’est l’explorateur de parties, c’est simple il n’existe plus.

On choisi une quête et le jeu nous trouve une partie. Dans Diablo 2 on pouvait choisir la partie et voir qui y était, ça permettait par exemple d’éviter les parties  en normal avec des niveau 80+ qui buttent tout sans qu’on puisse apprécier faire les quêtes tranquillement. De plus qu’avec les promesses de Blizzard comme quoi maintenant les rushs (baalruns, cs runs …) c’est fini et que pour avoir une partie rentable il fallait vider tout un acte en entier (ou au moins ses élites), les parties seraient à priori beaucoup plus longues.

À partir de toutes ces affirmations une petite idée m’est venue en tête. Le principe de Weplay est vraiment sympa pour organiser des parties. C’est intuitif et direct ! On s’inscrit pour une partie à telle date, le jour J on arrive on lance le jeu et on joue, j’ai donc décidé de faire un site exploitant la même idée mais uniquement pour Diablo 3 et ses spécificités.

Le site se divise en deux parties , la première est un outil pour rechercher une partie, la seconde est pour gérer ses personnages.

La partie personnage est très simple, on crée son personnage, on le met à jour et c’est tout…

Les persos sont classés par royaumes, un clic sur le personnage pour le mettre  à jour (niveau) ou le supprimer.

Blizzard ayant annoncé qu’une D3 API serait lancée plus tard, ça facilitera d’autant plus la tâche (Un équivalent de l’armurerie de WoW).

La deuxième partie est la gestion des parties. C’est encore une fois relativement simple. On crée une partie, on détermine l’heure , on choisi les options qu’on veut et on sélectionne son personnage . La liste des personnage se rafraîchie selon les options choisies, ne sont donc affichés que les personnages pouvant participer à cette partie.

Dans la colonne de droite on peut choisir les joueurs qu’on veut pour notre partie, soit n’importe quelle classe, soit une classe précise ou alors fermer l’emplacement.

Il est également possible de créer une partie privée qui n’apparaîtra pas dans le moteur de recherche et sera accessible uniquement via son URL (à l’instar d’une vidéo Youtube)

Une fois la partie créée, elle apparaît dans la recherche, la colonne de droite indique toutes les parties à venir ou récemment terminées où l’on a un personnage qui participe. Chaque partie à jusqu’à quatre icônes pour la représenter selon les classes choisies ou celle des joueurs dans la partie. Une icône transparente pour une place libre et opaque quand un joueur occupe cette place. L’icône des mercenaires est la quand la classe de l’emplacement de joueur n’a pas été spécifié.

La première partie de la colonne de droite est celle que j’ai créée précédemment, donc 3 joueurs dont moi + un babare + n’importe quelle classe.

Sur cette même page on peut rechercher une partie selon nos propres critères et y voir les places disponibles également.

En cliquant sur une partie on arrive sur la page suivante :

On peut y voir tous les détails de la parties, des joueurs avec les gamertags battle.net entre parenthèses visible uniquement si on a rejoint la partie. Il y à aussi un chat pour les participants uniquement histoire de discuter un peu avant de se lancer dans le bash de mobs.

Ci-dessous la même page mais quand on ne fait pas partie du groupe:

Pour chaque slot où on possède au moins un personnage qui rempli les critère il y a un menu déroulant pour choisir le personnage qu’on veut faire participer.

Plus tard il y aura des notifications par e-mail pour prévenir le joueur quelques heures avant que la partie commence.

Voilà pour l’instant c’est tout ce qu’on peut faire. Je vous invite à y faire un tour pour tester, me dire ce que vous en pensez et me trouver des bugs, c’est encore en développement (et bourré de fautes de frappe) et disponible ici: http://d3parties.ftpix.com

C’est à ce moment que je peux faire mon appel à l’aide. Je recherche un designer pour faire l’interface graphique du site. Pour l’instant il n’y a rien à gagner si ce n’est une ligne sur un portfolio. Si jamais il y a moyen de monétiser le site (pubs ou autres) je partagerais bien évidemment les gains.

Cet article fait suite au précédent article expliquant comment créer un équivalent Dropbox avec Unison. Ayant un peu avancé sur l’application, l’article va se focaliser dessus.

L’application est vraiment très simple, on choisi son profil unison et c’est parti. J’ai voulu ajouter un peu plus de flexibilité, jusqu’à maintenant j’utilisais la location par defaut d’Unison, ce qui peut poser problèmes dans certains cas. J’ai donc fait une petite fenêtre se lançant via le menu de l’icône du systray qui permet de préciser où est l’exécutable. Unison nécessitant d’avoir la même version entre les deux sources, j’affiche également la version de l’éxecutable.

Si jamais il y a un problème le bouton “Detailed log” permet d’en savoir un peu plus.

Histoire de pousser le vice un peu plus loin pour par exemple les utilisateurs qui synchronisent sur des serveurs différents ayant des versions différentes d’Unison, je permet également de préciser un exécutable particulier pour chacun des profils synchronisés, J’utilise la même fenêtre avec un titre different mais cette fois-ci se lance avec un clic droit sur le profil.

Le principe reste le même.

Dans la section petit détail, j’affiche une icône dans le systray différent si une synchronisation est en court. L’icône bleue pour Windows / Linux, la noire pour Mac OS X

Pour finir, je ne compte pas trop développer cette application, car ça ne va vraiment pas toucher énormément de monde, il me reste à faire un mini site et une fonction pour détecter les mises à jours ensuite, je me contenterais de corrections de bugs seulement.  Je posterais un nouvel article pour le téléchargement quand ça sera prêt.

Cet article fait suite à précédent article que j’avais écrit sur le sujet.

Ma précédente tentative en utilisant unison n’était pas super convaincante car je m’y prenais mal, ça me scanait mes 50Go de données à chaque synchronisation et c’était “un peu” lent… ok très long.

Après de longues tentatives avec des trucs genre GoodSync, Git, SVN et j’en passe, je suis tombé sur plusieurs articles (ici et ici) qui expliquent comment bien faire les choses avec unison. Et ça marche ! Mais… comme il y a toujours un mais ces articles précisent d’utiliser un script en python qui guette si il y a un changement dans le dossier, mais il y a deux problèmes.

• La detection des changements au sein du dossier à synchroniser est un peu hasardeuse (sur mes macs tout du moins)
• De cette manière on ne peux pas lancer une synchro à intervalles réguliers, et unison ne conseille pas de lancer deux synchros simultanées sur le même ordi avec le même profile.

Donc on a au choix, soit au changement dans les fichiers uniquement, soit à intervalles réguliers. Le premier choix est éliminé car si on a plusieurs ordinateurs actifs qui se synchronisent avec le dossier on est niqué car si un des ordis fait un changement, il sera bien envoyé au serveur mais le deuxième ne le recevra que quand il y aura un changement dans ses fichiers du même dossier. Le deuxième choix est donc préférable, mais si on veut qu’un fichier se propage rapidement on est niqué aussi.

Donc j’ai re-developé mon application “UniBox” qui permet de gérer les deux (écoute du dossier et synchro régulière) à la fois. Pour l’instant elle ne fonctionne que sous OS X et sans doute sur linux. Sur windows, je ne sais pas, j’ai pas testé mais je doute que ça marche. On a donc une petite icône dans la barre de menu en bonus donc pas d’encombrement de l’écran car tout peut se faire en fond. L’appli est maintenant une sorte de wrapper autout d’unison, c’est à dire que j’utilise également les fichiers de profile d’unison. L’appli proposant un petit assistant pour les gérer (créer, modifier, supprimer).

L’interface permet également, contrairement à la première version, de synchroniser plusieurs dossiers, de voir ce qui se passe lors de la synchronisation et propose un bouton qui permet d’ouvrir le dossier dans l’explorateur de fichier.

On à donc un joli dropbox sans limite de stockage qui fonctionne plutôt bien.

Mais ce serait vraiment trop facile de s’arrêter en si bon chemin…

Histoire de pousser le vice un peu plus loin, je me suis demandé comment faire si par exemple je débarque chez un pote et que j’ai besoin d’un des fichiers de mon “unibox” mais que mon pote n’a pas unison et qu’il n’a de toutes façon pas spécialement envie de synchroniser 50Go pour un seul fichier/dossier ?

Et bah c’est très simple. Sachant que unison garde une copie intacte du dossier (non compressée) sur le serveur, on va donc installer un explorateur de fichiers web. J’ai personnellement opté pour AjaXplorer. Mais pour faire les choses bien, il faut penser à quelques trucs.

• Le dossier doit être disponible en lecture et écriture sur le serveur par l’utilisateur/groupe utilisé par apache sinon, on ne peux pas uploader via l’interface web
• Du coup, unison doit être lancé en se connectant en ssh via ce même utilisateur/groupe utilisé par apache sinon les fichiers uploadés via unison ne seront pas modifiable, effaçable  via l’interface web.

Bon, alors pourquoi est-ce que j’ai choisi AjaXplorer ? Tout simplement parce que c’est le premier sur lequel je suis tombé et qu’il offre des possibilités sympa. On peut par exemple télécharger un dossier entier d’un coup, mais là où ça défonce, c’est qu’il est possible de partager les fichiers (ça demande un peu plus de configuration cependant) via un lien public protégé où non par un mot de passe, et pour une durée déterminée ou non.

Il est également possible de partager un dossier entier, pour cela ajaxplorer va nous demander de créer un utilisateur qui n’aura accès qu’au dossier qu’on souhaite partager et donner à cet utilisateur des droits de lecture  et d’écriture ou non. Donc tout ce qui se passe sur la version Web sera propagé dans les dossiers respectifs des ordis synchronisés sur ce dossier.

AjaXplorer possède également une application iOs qui permet de parcourir ses fichiers sur le serveur et d’uploader des photos de son iPhone/iPad/iPod.

On a donc une solution vraiment complète en main qui couvre tout ce que fait Dropbox (excepté le versionning). Ça demande un peu de temps et de connaissances pour tout mettre en place mais au final, ça permet d’économiser $200 par an (pour les gros consommateurs) et d’avoir vraiment le contrôle sur ses propres fichiers.

P.S: Les près-requis de mon précédent article sont toujours valables.

C’est reparti pour un tour ! Après cette année et demi de FTPix v2 il était temps de passer à l’étape suivante. Donc c’est une réécriture de 0 encore une fois, pour plusieurs raisons:

• Le code de la v2 est bordélique, moins que la v1 mais ça reste un gros bordel qui au fur et à mesure des features était devenu difficilement modifiable.
• Ca fait un an que je bosse en tant que dév JAVA contrairement à mon précédent job où j’étais web dev, du coup j’ai appris énormément de choses depuis donc je veux les appliquer.
• Mettre à jour l’interface car durant cette année et demi d’utilisation, je me suis rendu compte de quelques problèmes, réparer ça aurait été relativement long et fastidieux à mettre en place sur la v2 car ce ne sont pas des bugs mais des trucs chiants à l’utilisation.

Il n’y aura pas énormément de nouveautés majeures enfin il y en aura une en tout cas qui fera plaisir à pas mal de monde je pense, je ne vais plus limiter FTPix au FTP seul ! Au fil du développement je vais ajouter différentes façons d’uploader les images je n’ai pas d’exemple précis en tête mais pourquoi pas des services d’images en lignes, j’ai contacté le doc pour envoyer vers pix.wefrag.com mais pas de réponse pour l’instant. Les plus gros changements interviendront surtout dans le coeur du logiciel, c’est (vraiment) plus rapide et c’est ça l’important ! J’ai revu la gestion de la queue d’événement (upload, synchronisations etc…) de fond en comble. Je vais maintenant migrer toutes les données au format SQLite (je l’avais déjà fait pour les images sur la v2.4) et vraiment me servir des avantages du format pas comme précédemment. Le code est beaucoup plus propre et flexible, l’interface est ce coup-ci vraiment indépendente du corps du logiciel donc facilement modifiable. D’ailleurs, au niveau de l’interface pas mal de changements, déjà une des plus grosse merde de la v2 l’affichage des images par pages de 100 images. C’était nul, mais à l’époque j’avais pas trouvé de méthode décente de faire ça sans que ça rame ou prenne  trop de ressources. Maintenant toutes les images sont affichées ! (l’icône des galeries n’est pas encore faite)

Deuxième gros changement de l’interface, plus de petites fenêtres indépendante pour les images, c’était chiant à gérer (surtout sous windows) pour l’utilisateur des qu’on voulait en ouvrir plusieurs. J’affiche également tous les images lors d’une sélection de plusieurs images. La petite barre d’outils permets de centraliser toutes les actions possibles sur les images (ouvrir dans le navigateur, effacer, télécharger, ajouter à une galerie, annoter), l’ordre des icônes n’est pas l’ordre définitif

Plus de barre de status en bas, on peut toujours voir la progression, et le champ de recherche à changé de place. Il faudra désormais un clic pour le voir. Mais j’ai remarqué sur tous les gens que j’ai pu observer utiliser le logiciel se focalisaient surtout sur les images les plus récentes. Donc autant gagner quelques pixels de hauteur, et avoir un look un peu plus stylisé.

J’ai également fait des tooltips plus sympa que les tooltips système par défaut.

Pour la barre de status, pour savoir ce qu’il se passe, ça marche à la manière de tool tips normaux, on passe la souris sur la mini barre (en bas à gauche) de progression et l’action en cours s’affiche. La fenêtre des upload à également été un peu modifiée pour voir la taille des fichiers envoyés et la progression en KB / MB

Je ne sais pas encore quand le logiciel sera prêt, mais c’est sur la bonne voie, j’ai pas noté trop de bugs pour l’instant…  Depuis mon nouveau travail mon niveau de code à vraiment progressé, j’arrive à faire ce que je veux vraiment faire avec beaucoup plus de facilité et de performances qu’avant. Évidemment tout ce qui est montré ici est susceptible de changer j’en suis qu’au début du développement.

Le plus gros va être au niveau des galeries, je veux vraiment les rendre plus agréables à utiliser avec une interface beaucoup plus conviviale et comme je vais changer la façon de sauvegarder pour que ce soit plus rapide, le corps du code va également être sujet à de gros changements.

Bref, je vous tiendrais au jus sur ce blog comme je l’avais fait pour la v2. Évidemment je suis ouvert à toutes remarques concernant le logiciel pour le rendre le plus agréable possible à utiliser.

Dans la série fais le toi même parce que t’arrives pas à trouver ce qui te plaît ou que t’as pas bien cherché je présente le DropBox fait maison !

Ayant un serveur dédié avec 500Go d’espace disque et des fichiers que j’aimerai bien retrouver partout pareil sur mes ordinateurs (musiques, photos -> 50Go) mais qui rentre pas dans les 2Go de DropBox tout en trouvant que ça fait chier de lacher 80€ / an pour 50Go alors qu’on en a 500 qui ne demandent qu’a être remplis je me suis mis au défi de me créer mon propre DropBox basé sur Unison.

Voici un petit tutoriel de comment faire, et au final c’est relativement simple.

1) Qu’est-ce qu’on va faire ?

C’est très simple, on va se servir de notre serveur comme d’un HUB et tous nos ordinateurs vont verifier les changements sur le serveur et télécharger, envoyer, effacer les fichiers nécessaires. On pourrait faire du dossier cas par cas, mais pour faire comme DropBox et rendre les choses plus simple, on va uniquement synchroniser un seul dossier histoire de savoir où sont les choses qu’on synchronise et pour être sûr qu’on oubliera pas.

2) Les pré-requis.

• Un serveur dédié avec un accès SSH sans mot de passe
• Unison installé sur le serveur dédié ainsi que sur chacun des clients (Attention il faut la version ligne de commande sur les clients, pas uniquement l’interface)
• Et c’est tout…

3) Et ensuite ?

Ensuite deux solutions, la solutions de fainéant et facile, faire un script sur chacun des clients du style

/usr/bin/unison cheminLocalDuDossierASynchro ssh://loginSsh@urlserver//cheminDelaRacineDuServeur -fastcheck true -batch -ui text -perms 0 -times -rsync

Coller un cronjob la dessus et en voiture Simone… Le transfers de fichier se fera en utilisant rsync ce qui signifie s’il y a des modifications sur les fichiers, seules les modifications seront envoyées/téléchargées. Donc on gagne en temps de synchro. C’est bien mais je trouve que ça manque de classe.

Donc on va se diriger vers la deuxième méthode qui consiste à créer un petit programme en Java dans mon cas qui va écouter le dossier sur mon ordinateur pour être au courant dès qu’un changement à lieu. Si changement, on lance la synchronisation, si une synchronisation est déjà en cours, on dis a notre programme de relancer une synchronisation à la suite de la courante pour être sûr que tout est à jour sur le serveur.

On va également faire une synchronisation à intervals réguliers (toutes les 3 minutes ici) et on est bon. On colle tout ça dans la barre de menu et on a notre propre Dropbox en quelques heures. Pour la classe on rend le tout configurable au cas où le dossier à synchroniser n’est pas le même sur chacun des ordis. Une petite icône et c’est parti

Voilà j’ai exposé le concept et fait une petite application en alpha qui fait ce qu’il faut faire sans trop de bugs. Pour l’instant ça marche sur OS X et ça devrait marcher sur Linux, Je mettrais ça en téléchargement quand ça sera vraiment prêt !

J’avais promis la suite de lendemain, j’ai pris un peu de retard !

Intégrer une application Java à Mac OS X

2) Post-développement

2.1) Créer l’icône

Heureusement, Mac OS fournit quand même des outils plutôt pratique pour faire les choses assez rapidement et simplement. Pour créer une icône il y  a un logiciel qui se nomme “Icon Composer”. Les fichiers icône (.icns) sous OS X sont en fait plusieurs images de différentes tailles pour toutes les représentations possibles telles que dans le finder, dans le dock etc. Les icônes ont une taille maximum de 512*512 et on peut choisir des images différentes pour chaque palier de zoom : 256*256, 128*128, 32*32, 16*16. Un simple glisser déposer suffit.

2.2) Créer l’application

Sous OS X les application sont sous un format de fichier .app qui est en fait un simple dossier contenant tout ce dont l’application à besoin pour fonctionner. Pour les applications java il y a une fois de plus un utilitaire fourni par Apple sous le nom de “Jar Bundler”. C’est également relativement simple.

Ici on choisi l’icône ainsi que la Main Class qui, il suffit de choisir le .jar de notre application. notez également la possibilité d’utiliser la barre de menu Mac OS au cas où votre application ait un menu type “Fichier Edition … …”

Ici on ajoute toutes les ressources supplémentaires nécessaires pour l’application, les librairies par exemple.

Ici sont les informations diverses de l’application, quelques options de la VM Java.

On a plus qu’à cliquer sur “Create Application” et sauvegarder là où on veut et nous avons notre application .app fonctionnelle.

2.3) Créer un nouveau type de fichier (bundle)

Mon application pour fonctionner à besoin de plusieurs fichiers pour une sauvegarde. Donc je vais avoir besoin de créer ce qu’on appelle un bundle. Tout comme les fichiers .app des applications il s’agit simplement d’un dossier contenant x documents mais qui apparaîtra en tant qu’un seul et unique fichier au yeux de l’utilisateur.

Pour cela, il faut faire un clic droit sur l’application fraîchement créée et “Show Package Contents” et ouvrir le fichier info.plist

Il suffit d’ajouter les lignes nécessaires pour obtenir quelque chose comme ceci.

On peut également spécifier une icône particulière pour notre nouveau type de bundle. (tehhisFile ici) et le placer dans le dossier ressources qui se trouve dans notre application.

Et voilà on est bon, tous les dossiers qui auront un nom finissant par .tehhis (dans mon cas) apparaîtrons comme un seul et unique fichier.

Et donc lorsque l’on lancera ce type de fichier, cela ouvrira notre application et lancera l’evenement handleOpenFile de notre Mac Handler (voir partie 1 du dossier) une fois celui-ci initialisé.

Nous avons donc une application qui apparaît et se comporte comme une application native, juste les fouineurs pourront s’en rendre compte en fouillant dans le bundle .app de notre application.

Ces jours-ci je bosse sur une application qui qui doit être développée rapidement (donc pas le temps d’apprendre cocoa/obj-c) et qui ne sera utilisée que sur Mac OS  pour la boite que je suis en train de monter d’ailleurs, je reparlerais de la boite plus tard, je pense que ça intéressera certains d’entre vous.

Histoire de me faire un peu plaisir pour satisfaire mon amour dévoué à Mac OS X je me suis dis que j’allais essayer de bien intégrer l’application à Mac OS. Le problème c’est qu’il faut chercher un peu partout sur le net et c’est pas tout le temps super clair. Donc je vais regrouper tout ça ici ou au moins ce que j’ai utilisé. Car mine de rien, il y a tout un tas de petites choses qui font qu’on aime une application Mac OS.

Je vais divisé cet article en deux parties, ce qu’on peut faire pendant le développement et ensuite ce qu’on peut faire une fois le développement fini.

1) Développement

Ok, alors les habitués de Mac OS auront sûrement remarqué que par exemple les raccourcis de base sont en général tous les même quelque soit les applications tel que cmd + , pour les préférences ou le fameux cmd + q.

Également le fait de pouvoir dropper un fichier sur l’icône du Dock ou encore les notifications Growl. Tout ça c’est possible avec Java !

1.1) Le MacHandler

Bon, j’appelle ça le MacHandler, c’est pas le nom officiel. Il s’agit  d’une classe avec laquelle on va utiliser tous les événements spécifiques à Mac OS , ce qui se passe lorsqu’un fichier est lâché sur le Dock (j’y reviendrais dans la seconde partie  du dossier car il y a d’autres petits trucs à faire), lorsque les préférences sont ouvertes, lorsqu’on clique sur l’icône du dock alors que l’application est déjà lancée etc…

Je me permets un vieux copié collé de ce que j’ai déjà fait car le nom des méthodes est relativement explicite:

public class MacHandler {

public MacHandler() {
// create an instance of the mac osx Application class
Application theApplication = new Application();

// create an instance of our DockBarAdapter class (see source code below)
DockBarAdapter dockBarAdapter = new DockBarAdapter(this);
theApplication.setEnabledPreferencesMenu(true);

// add our adapter as a listener on the application object
theApplication.addApplicationListener(dockBarAdapter);

}

// our "callback" method. this method is called by the DockBarAdapter
// when a "handleOpenFile" event is received.
public void handleOpenFileEvent(ApplicationEvent e) {

}

public void handleQuit(ApplicationEvent e) {
System.exit(0);
}

public void handleReOpenApplication(ApplicationEvent e) {

}

handler.handlePreferences(e);
}
}

1.2) Growl

Tout utilisateur de Mac trouvera les notifications fort pratique et en général est content lorsqu’une application les utilise. Ici c’est du 100% fait maison avec une méthode un peu bourrine… Mais qui marche.

Le fonctionnement est relativement simple, on a un fichier AppleScript (.scpt) inclus dans le .jar et une classe qui lors de sa construction extrairera ce script dans un dossier temporaire e l’éxecutera  au besoin

La classe ressemble à ça:

public class GrowlNotification extends Growl {

File file;

public GrowlNotification(){
//lorsque on initialise les notifications, on extrait un fichier applescript du .jar et on l'execute quand on en a besoin.
try {
URL script = getClass().getResource("/applescript/notification.scpt");
script.openStream();

//model.Model.tmpDir est un dossier de fichier temporaires lors de l'execution de mon appli à définir vous même
File f = new File(model.Model.tmpDir+"/notification.scpt");
f.createNewFile();
Tools.copyCompletely(script.openStream(), new FileOutputStream(f)); //ici est une methode pour extraire un fichier du package
file = f;
file.deleteOnExit(); //on supprime le fichier quand on ferme l'appli
} catch (IOException ex) {
Logger.getLogger(GrowlNotification.class.getName()).log(Level.SEVERE, null, ex);
}
}

public void showNotification(String message, String title) {
try {
String[] cmd = new String[4];

cmd[0] = “osascript”;
cmd[1] = file.getPath();
cmd[2] = title;
cmd[3] = message;

Process proc = Runtime.getRuntime().exec(cmd);
} catch (IOException ex) {
Logger.getLogger(GrowlNotification.class.getName()).log(Level.SEVERE, null, ex);
}
}
}

1.3) L’interface

Je trouve que c’est ce qui manque le plus à java sur Mac, c’est très (trop) basique, heureusement qu’il y a un petit génie qui a créé tout ce dont on a besoin ! Ce mec nous a donc pondue une librairie qui regroupe presque tout ce dont on peut avoir besoin !

C’est disponible ici : Mac Widgets for Java et ça permet de faire des choses dans ce genre:

Mais ce petit gars ne s’est pas arrêté là sinon ça aurait été trop simple, en fouillant sur son blog super intéressant on tombe sur d’autres trucs pour pousser encore plus l’intégration tels que:

faire des barre de header à la iTunes , faire des listes au look Apple bref que du bon.

D’ailleurs pour la petite histoire ce mec à été engagé par Apple.

En parlant d’Apple ils fournissent quand même un peu d’aide à cette adresse (où il y a un exemple pour les applescripts beaucoup moins bourrin que moi)

1.4) Les system properties

il existe tout un tas de system properties qui permettent de créer des éléments d’interface qui permettent d’éviter quelques sueurs sur des trucs cons. Ca se trouve ici.

En bref, des boutons (plein), des champs de recherches, la décoration des fenêtres, des dropdown etc etc y en a pour tout le monde. C’est très facile à mettre en place et c’est du plus bel effet.

Bon, je comptais pas faire ce dossier en deux parties, mais là il est un peu tard et je me lève tôt demain donc tout ce qui se passe une fois qu’on a fini l’application arrive demain  presque sans fautes !

Intégrer une application Java à Mac OS X (suite)

Après presque 6 mois sans nouvelles de la version desktop, j’en sors enfin une nouvelle. Pas énormément de changements apparents, surtout de l’optimisation:

• Nouveau système de sauvegarde (encore une fois oui) beaucoup + rapide et sécurisé. La conversion de la sauvegarde se fera au lancement de l’application
• J’ai supprimé quelques effets inutiles qui ne faisait que bouffer de la ressource CPU pour pas grand chose.
• Optimisations diverses

Les vrais nouveautés parce qu’il y en a quand même:

• La possibilité d’associer des tags d’images aux galeries. en associant un ou plusieurs tags à une galerie toutes les images déjà existantes contenant un des tags indiqués seront automatiquement ajouté à cette galerie mais aussi dès qu’on modifie les tags d’une image si une galerie est liée a un de ces tags, cette image y sera ajouté (ça n’uploadera pas la galerie pour autant).

• Autre nouveauté qui sera encore en beta pour le moment et l’ajout d’un mode console à l’application qui permet d’utiliser FTPix en ligne de commande. Le détail des commandes est dans le fichier readme. Quand j’aurais le temps je montrerais quelques exemples de ce qu’on peut faire avec ça.

Je devrais également publier bientôt une mise à jour de la version Android de FTPix.

Bisous.

<maxkarting>

Bonjour bonjour,

Pour ceux qui me suivent depuis quelques temps, je parle beaucoup de mes projets personnels avec des échecs/abandons (smart task, colorful reader, xywriter et un de + dont j’ai même pas pris la peine de parler ici) et des trucs plus réussis (FTPix, check that later) et s’ils sont plus réussi c’est qu’ils me tiennent pas mal à coeur et c’est aussi grâce à wefrag car pas mal de commentaires m’ont poussés à continuer

Voir des commentaires du genre:

Bravo pour ton logiciel, et ton travail fourni. Je vais probablement me lancer dans la même aventure plus tard, en tout cas j’admire la performance. Tu contribues à rendre Internet meilleur, et ça c’est bien[…]

ça fait vraiment plaisir et ca donne du boost pour avancer !

Cependant j’ai l’impression d’être arrivé au bout de ce que je peux faire seul j’ai vraiment l’impression de stagner, d’avoir un paquet de choses à faire et du coup de ne pas savoir par où commencer pour au final ne rien faire. Ceci combiné à mon nouveau taff bien chargé c’est loin d’être évident et j’ai l’impression de ne pas pouvoir surmonter ce cap.

Ce cap où on a plein d’idée mais on arrive pas à les mettre en place pour les raisons pré-citées, c’est réellement frustrant.

C’est pourquoi j’en appelle aux personnes qui lisent ce blog. Pour pousser ces deux projets, j’aimerais monter une petite équipe de 2-3 personne par projet (moi inclus)  pour m’aider à finir ce qui est à finir et a pousser les concepts un peu plus loin.

Je n’ai pas uniquement besoin de personne sachant coder, des personnes pouvant aider à faire connaître ces projets une fois plus mature ou encore des personnes désireuses d’apprendre (comme pour le développement Android par exemple car je sais qu’il y a des intéressés par le sujet).

Voici en gros (j’ai aussi une liste détaillé) ce que j’ai en tête pour le moment et ce sur quoi je recherche éventuellement du monde

FTPix:

• Faire une version web de FTPix, beaucoup plus simple pour consulter les images sur son FTP (voir uploader plus tard) en PHP
• Améliorer la version Android
• Faire connaître le logiciel
• Améliorer la version desktop pour les suicidaires (Le code est véritablement bordélique, c’est pour ça que je préfère m’en occuper moi même)

Check That later:

• Finir le site autant sur le contenu (page d’accueil et autre) que sur le code du site (PHP)
• Finir l’extensions Firefox en priorité.
• Améliorer les extensions existantes
• Finir l’application android.
• Faire une version mobile du site (CSS / PHP / HTML) la structure du site existant déjà, il s’agit en gros de créer un thème sur ce que j’ai déjà fait
• Idem que FTPix, faire connaître le site.

Evidemment cela ne représente pas une liste fermée de ce qu’il reste à faire. Je suis ouvert à la critique et suggestion d’idées.

Toute personne vraiment motivée et intéressée par ces projets est évidemment le bienvenue.

Malheureusement je n’ai rien à offrir pour les bonnes âmes qui décideront de m’aider à part un nom sur le(s).  Ca peut toujours ajouter une ligne sur un CV de jeune diplômé pour un petit coup de pouce lors de la recherche du premier emploi et peut être la gloire avec des putes et des bols de coke pour plus tard.

Je pense et j’espère que je n’ai rien oublié.

Ca fait un peu post de désespéré mais tant pis, j’assume.

</maxkarting>

• Android dev #1: Définir son application
• Android dev #2: Premier écran, première action

1) Menus

Aujourd’hui on va commencer par les menus, ceux très pratiques qui apparaissent quand on appuie sur la touche menu du téléphone. Ca évite d’encombrer l’UI avec des choses pas forcément utile 100% du temps.

Avec android c’est vraiment très simple à mettre en place. File > new > other > Android xml file et choisir menu dans la liste des boutons radios.

Cliquer sur Add pour ajouter une nouvelle entrée et  remplir les champs comme demandé, ils ne sont pas tous obligatoire.

Une fois ce menu créé, il faut assigner à notre Activity ce menu lorsqu’on appuie sur la touche:

      public boolean onCreateOptionsMenu(Menu menu) {
		MenuInflater inflater = getMenuInflater();
		inflater.inflate(R.menu.site_list_menu, menu); //avec l'id de notre menu
		return true;
	}

Ensuite il faut lier des événement à chacun de ces items:

@Override
	public boolean onOptionsItemSelected(MenuItem item) {
		switch (item.getItemId()) {
		// We have only one menu option
		case R.id.menu_add: //id qu'on a spécifé dans l'éditeur de menu.
			addLink();
			break;
		case R.id.menu_refresh:
			refresh();
			break;
		case R.id.menu_logout:
			finish();
			break;
		}
		return true;
	}

Et voilà ! on a un beau menu

2) Preferences

Pour créer des préférences c’est très simple: File > new > other > Android xml file  (oui encore) et choisir preferences dans la liste des boutons radios.

Ensuite on devrait arriver sur une fenêtre de ce style :

Ca va relativement droit au but, on clic sur add pour ajouter des catégories, des fenêtres etc…  On peut choisir le type de préférence souhaité (checkbox, text…).

Ensuite il faut créer une classe Preferences quelque part dans votre projet et la déclarer dans l’androidManifest.xml (voir plus bas). Cette classe est très simple:

public class Preferences extends PreferenceActivity {

	/** Called when the activity is first created. */
	@Override
	public void onCreate(Bundle savedInstanceState) {
	    super.onCreate(savedInstanceState);
	    addPreferencesFromResource(R.xml.preferences);
	}
}

et on y ajoutera rien de plus.

Ensuite il faut lancer la fenêtre des préférences depuis notre Activity principale (exemple prit sur FTPix car je n’ai pas de préférences dans checkthatlater):

//code à placer dans le listener du bouton qui doit lancer les préférences.
Intent i = new Intent(FTPix.this, Preferences.class);
a.startActivity(i); //on considèrera que "a" est de classe Activity

3) Lancer un nouvel écran

De même ici, pas de réel problème c’est relativement simple. On considèrera que “a” est de classe Activity le deuxieme paramètre est la classe de la fenêtre cible

Intent intent = new Intent(a.getApplicationContext(), SiteList.class);
intent.putExtra("apiSession", result); //on transmet le paramètre de nom "apiSession"
a.startActivity(intent);

Ensuite il dans le onCreate(Bundle savedInstanceState) nouvelle Activity, pour récupérer les paramètres:

Bundle extras = getIntent().getExtras();
if (extras != null) {
	apiSession = extras.getString("apiSession");
}else{ //uniquement si les paramètres son indispensable, si on à pas le paramètre on ferme l'écran et retour au précédent.
	finish();
}

4) androidManifest.xml

L’android manifest est la fichier qui regroupe toutes les caractéristiques de notre application. Il faut absolument y ajouter toutes les Activity qu’on utilisera (dans l’onglet application puis dans application nodes), on peut également définir toutes sortes de propriétés comme les résolutions d’écran supportées (onlget manifest > manifest extras) ainsi que les permissions dans l’onglet permission.

Petit truc pour éviter de perdre du temps bêtement, déclarer bien la permission INTERNET si votre application en à besoin, sinon rien ne marchera. J’ai perdu quelques heures la dessus sur FTPix, ça fait bien rager.

Avec les 3 premiers articles on peut déjà faire quelque chose de sympa. Voici ce à quoi ressemble Check that later après quelques heures de taff sans trop de prises de têtes:

Bon, ça tourne sur émulateur d’où l’impression de lenteur, sinon c’est plutôt rapide.