Auteur : Morgiver

Pour commencer cette lecture, voici un petit rappel de ce qu’il se passe lorsqu’on dispatch une action dans l’application.

On dispatch une action, qui appel une méthode, cet appel envoie un event dans l’application, la méthode appelée par le dispatch peut elle même dispatcher une autre action, qui enverra elle aussi un event, les méthode dispatchée peuvent commit des données dans le state, ce qui appellera d’autre event, etc., etc. Un bon petit schéma fait pas de mal :

Une chaine de méthodes dispatchées, de commit et d’event, ça peut vite devenir gourmand en ressources ou simplement prendre du temps, ou encore on aura peut-être besoin d’appeler certaine méthode en boucle sans avoir à bloquer tout le reste de l’application.

Lire l’article en entier

Dans l’article précédent, j’abordais avec simplicité le pattern Model/View et j’expliquais comment on pouvait avoir une structure robuste en quelques lignes de code.

Aujourd’hui on va améliorer ça en ajoutant une gestion de composants, la gestion d’un tout petit espace de nom, une injection d’un contexte d’application dans les actions, les mutations et les évènements.

L’idée d’un composant c’est d’avoir une partie d’application qui puisse avoir les mêmes méthodes de base que l’application racine et les autres composant.
On va donc commencer par créer une classe abstraite qui nous permettra d’imposer cette structure.

class AbstractComponent:
    def __init__(self, name, root):
        self.name = name
        self.root = root

        self.state = {}
        self.actions = {}
        self.mutations = {}

    async def dispatch(self, namespace, payload={}):
        return await self.root.dispatch(namespace, payload)
    
    def dispatch_sync(self, namespace, payload=Payload()):
        return self.root.dispatch_sync(namespace, payload)

    def commit(self, namespace, payload={}):
        self.root.commit(namespace, payload)

    def on(self, event_name, callback):
        self.root.on(event_name, callback)

    def emit(self, event_name, payload):
        self.root.emit(event_name, payload)

Chaque composant détient donc un state qui lui appartient, et de même pour les actions et les mutations.
De plus le composant pourra appeler les méthodes du Root Application.
Donc peu importe dans quel Composant on se trouvera, les fonctionnements de base sont les mêmes.

Lire l’article en entier

Voilà un moment que je n’ai pas écrit d’article, plusieurs raisons à cela mais je vais entrer dans les détails. 

Le plus important est que j’arrive avec du neuf et de nouvelles idées pour l’application.

Je me suis remémoré la façon dont j’utilisais le Store VueX de VueJS en Javascript et je trouvais l’algorithme vraiment léger, rapide et complet. Du coup, je me suis dit que ce serait une excellente solution pour notre application et sa structure fondatrice.

L’algo se base sur le pattern Model/View qui est lui même une variante du pattern Model/View/Controller. L’idée est d’avoir une vue (View) constamment mise à jour à chaque modification des données en mémoire (Model).

Pour débuter cet article j’aimerais revenir sur une image de la structure globale de l’application telle que je la voyais :

Lire l’article en entier

Comme on a déjà pas mal parlé de l’interface graphique et qu’on commence à avoir une bonne idée de ce qu’on veut, je pense que cette itération est le moment de créer le squelette sur lequel les autres packages pourront se reposer pour afficher des vues.

Phase d’inception :

L’Interface c’est principalement un moniteur d’informations et une télécommande qui permet d’envoyer des actions à faire, des informations ou encore des évènements.

Et tout comme l’application entière cette Vue Globale est divisée en plusieurs parties. Chacune d’entre elle offrant une panoplie d’informations et d’outils permettant de contrôler et agir sur l’application.

Par exemple on aura la vue des charts qui va afficher les données d’un marché, et on aura la vue des actions permettant d’afficher des sous vues différentes dont par exemple la sélection du marché à afficher, ou la vue qui permettra de configurer un indicateur à afficher, etc..

Reprenons le schéma que j’avais fait dans un précédent article, avec quelques modifications :

Lire l’article en entier

Au fil des quelques articles je me suis senti bloqué par un manque de recul. Je pensais pouvoir établir plein de Use Case, les relier entre eux et voir une architecture sortir d’elle même des schémas. 

A mon avis, c’était une erreur de penser comme ça. Du coup, j’ai pris un peu de recul et je me suis penché sur l’architecture globale que pourrait prendre l’application, et voilà ce que ça donne sous forme d’un schéma :

Pour l’instant, c’est la vision globale de l’architecture que j’ai dans ma tête.

Lire l’article en entier

Maintenant qu’on sait comment manipuler les use case de manière basique, concentrons nous sur une base simple d’interface graphique sur laquelle on pourra s’appuyer pour faire le reste des use case. Et surtout, une base qui puisse nous permettre d’ajouter facilement les fonctionnalité au fur et à mesure du développement.

Avant de me lancer dans le reste de l’article je voudrais préciser que le développement UX (pour User eXperience) c’est une discipline vraiment à part et que je risque fortement de faire des erreur de débutant à ce niveau.
Je vais me concentrer sur ce qui me parait logique et/ou intuitif, il se peut donc que des modifications radicales interviennent dans le futur si je me rend compte que j’ai fait de la merde.

Comme vous pouvez le voir, j’ai essayé de faire très simple. Je me suis inspiré d’interfaces que j’ai déjà pu voir, et en général les app ou les site web traitant des charts se présentent de cette façon.

Lire l’article en entier

Nous voilà dans notre première phase de listing de cas d’utilisation et je dis première parce qu’il va y en avoir pas mal à mon avis.

En commençant la préparation du projet et de ma démarche telle que je vous la présente, j’avais déjà tenté de créer quelques petits visuels possibles de l’application. Voilà un exemple avec une potentielle vue de gestion de téléchargement de données historiques :

Alors, soyez rassurés je ne vais pas du tout afficher les choses comme ça, j’ai déjà d’autres idées et je compte vous montrer d’autres visuels un peu plus user friendly, mais prenons ce visuel pour avoir quelques premiers cas d’utilisation possibles.

Lire l’article en entier

N’étant pas encore vraiment habitué au Processus Unifié, il se peut fortement que je fasse des erreurs d’interprétation et d’utilisation de ce concept. Donc pour les puristes, ne m’en voulez pas trop fort :p

Rappelons qu’une itération est composée de 4 phases, l’Inception, l’Élaboration, la Construction et la Transition.

Etant donné qu’un projet est une succession d’itérations organisées en poupée russe, pour moi la couche principale d’itération est forcément la succession des versions majeurs d’un projet. Et il me paraît logique de commencer les itération par “ 0 “, car avant d’avoir une version “1”, on passe par le développement entier d’une itération. Une fois l’itération finie et le projet livré, on peut prétendre être en version 1.

Lire l’article en entier

Maintenant que le projet est introduit, que les motivations sont expliquées, on va pouvoir commencer à entrer dans le vif du sujet.

Avoir un langage commun : UML

Etant donné la nature Open Source du projet et qu’à terme j’aimerais pouvoir accueillir des contributions de manière sereine, je pense qu’il est important d’installer des bases solides d’organisation. Cela permettra à tout le monde d’être sur la même longueur d’onde.

Pour cela je voudrais maximiser l’utilisation du langage UML (Unified Modeling Language) et du Processus Unifié. 

L’important pour moi la dedans est de pouvoir intégrer un processus de développement structuré en différentes phases. Mais également de permettre à tout un chacun, surtout les non développeurs qui n’y connaissent rien en code, de pouvoir suivre l’évolution du développement en ayant un support lisible et compréhensible pour eux.

UML est un langage schématique que n’importe qui peut facilement apprendre et comprendre et il peut être utilisé dans tous les domaines, même ceux n’ayant rien avoir avec l’informatique.

Lire l’article en entier

Il y a quelques mois, je me suis lancé dans la recherche et le développement d’outils qui pourraient me permettre de soutenir un travail de ce que j’appel un Crypto Trader, un mec qui trade des crypto monnaies quoi.

J’ai fait tous mes premiers travaux avec ce que je connaissais, c’est à dire Javascript et NodeJS. L’idée était assez simple, trouver des voies d’investigations qui me permettraient de déléguer le travail d’analyse de graphiques à une machine. 

Je me suis donc lancé corps et âme dans l’apprentissage du développement d’une Intelligence Artificielle. Et à vrai dire c’était assez naïf au départ, je partais sur un idéal d’une IA qui apprendrait par renforcement parce que mes recherches me permettaient de réaliser des exercices simples assez prometteur. Imaginez, une IA qui lit des données historique qui fait des fake positions et qui apprend toute seule de ses erreurs, le rêve.
Non, c’est beaucoup trop complexe à réaliser tout seul x)

J’ai bossé un moyen de pouvoir gérer et afficher des chandeliers de données, avec la gestion d’indicateurs calculé à partir des données récoltée. Je pouvais reprendre mes recherche sur la création d’un moteur 2D sur Javascript plutôt sympa.

Je me suis vite confronté à des problèmes de performance que Javascript et NodeJS ne pouvaient pas vraiment régler sauf en apprenant à aller encore plus profondément en apprenant la gestion des Shaders et l’utilisation des cartes graphique, boulot beaucoup trop lourd à mon goût et trop complexe sur NodeJS. Enfin, question développement Desktop, même en utilisant ElectronJS, ça devenait vraiment vite compliqué comparé à ce que peuvent faire des Java ou Python.

Du coup, j’ai bouffé une formation rapide sur Python pour intégrer la syntaxe et commencer à rechercher des Packages intéressants qui me permettraient de réaliser tout ce que j’avais déjà fait sur Javascript et NodeJS.

Et me voilà, avec tout un projet en tête, beaucoup de choses à faire et partager.

Lire l’article en entier