Damien Cosset

Posted on May 13, 2019

Launch story: 1st month

#product #react #node #launch

Introduction

My application InvoiceMaker has officially been up for a month now. It is time to reflect on what I managed to do in the pas couple of weeks.

Features

Accounts

The main thing that I worked on is the accounts functionality. To handle the accounts creations and the login functionality, I chose to use passport.js and JSON Web Token. I use the local storage to keep track of the token send back from the server, coupled with an Express middleware, to verify the identity of the users.

Define your organisation's informations

So far, the only thing you can do when you have an account is to save your organisation's informations in a database. So, you don't have to re-enter your details everytime you need to create an invoice. Chances are these informations won't change too much over time, so having the possibility to save them felt natural.

About page

I added an about page, because I suppose I'll need one at some point :D I just added a few questions some people may have, and their answers. Not quite sure where I want to go with this page yet.

Bug fixes

Finally managed to make the production build for React work in production. Couldn't quite figure out why it didn't work.
Solved a font rendering problem on the generated PDF. I believe it was because I used a font that was not supported on Linux (Helvetica Neue), so the generated PDF falled back to a different font.

Conclusion

I didn't manage to set aside too much time to work on the project unfortunately. The next steps will be:

Having the possibility to add a logo on the invoice.
Start thinking about Stripe integration

Happy Coding :)

Top comments (16)

Florian Rand • May 13 '19

I've played with a few PDF libraries and font rendering in general could be a lot better.

There is not such thing as not supported font, maybe you used other format than ttf or otf, in any case probably your problem in rendering it's the library's fault, not the font (trying to keep the answer short, I don't want to bore you with typography and fonts 😅).

Damien Cosset • May 13 '19

I have a huge gap in my knowledge when it comes to that kind of things :/

I thought, and apparently I'm wrong, that because I used a Linux server, the font I was using needed to be supported by all OS to make sure the rendering would not differ.

Now, I'm only referencing fonts from the CSS, with a good old font-family property.

I don't know if I'm clear, nor if my approach is right (it's probably not). But don't be afraid to bore me, I would love to learn more :D

Florian Rand • May 13 '19 • Edited

Your approach is perfectly fine. I wanted to relieve you about the rendering bug, it's not your fault.

Helvetica is probably one of the most widely used font families (Arial is Microsoft helvetica version, but that's another story).

You're doing great taking into consideration the limitations here.

You've discovered that working with fonts is harder than you thought and that's okey!

Damien Cosset • May 13 '19

That's reassuring. I guess I'll postpone thinking about this when I would need to add support for different fonts

Florian Rand • May 13 '19

This post from Coding Horror may be of help.

Drozerah • May 13 '19

Bonjour Damien,

Pour information l'url principale retourne une page blanche sous FireFox...

Damien Cosset • May 13 '19

Oops, je regarde ça et je corrige. Merci !

Drozerah • May 13 '19 • Edited

Murphy => "Tout ce qui est susceptible d'aller mal, ira mal" - l'effet demo a priori ;) Euuuuh et pour le climat et la biodiversité on fait quoi ?

Damien Cosset • May 13 '19

Problème résolu! :)

Drozerah • May 14 '19 • Edited

Ok ! D'autre part concernant le rendu de la page principale où figurent les formulaires ceci :

la largeur de la page dépasse celle du viewport, il en résulte la présence d'une barre de scroll horizontale. Par conséquent la navigabilité se trouve compliquée/instable sans que cela soit justifié - Cela reflète à mon sens également, au stade actuel du projet, que celui-ci devrait être traité sous l'angle de l'affichage adaptatif (responsive)
dans le même ordre d'idée et par souci de cohérence avec l'argumentaire de professionnalisme que tu mets en avant pour présenter l'application (cohérence fond/forme), il me parait que tous les éléments de classe 'jss2' devrait adopter des règles de margin équivalentes car il existe des décalages de ce point de vue entre les éléments...
de manière générale et sans approfondissement de ma part du point de vue de la logique de saisie des formulaires par rapport au rendu final du pdf, il me semble qu'une application de ce type devrait offrir une présentation plus séquentielle, peut-être donc un ordonnancement des formulaires les uns en dessous des autres afin que l'utilisateur ne se sente pas perdu face à un ensemble assez copieux...
toujours sur les formulaires, un retour visuel qui indiquerait qu'un bloc est complété faciliterait le repérage pour l'utilisateur
s'agissant de la réinitialisation, il pourrait exister une réinitialisation totale de l'ensemble des blocs de champs, et je pense que pour chaque bouton de chaque bloc de saisie multiple il pourrait exister une intégration plus discrète sous forme d'icone qui apparaîtrait au survol d'un bloc pourquoi pas, ceci en sorte de ne pas mêler trop l'outillage de gestion de saisie avec la présentation générale de l'application qui devrait être au plus proche de celle du pdf...
enfin, en mode preview, au moins pour un breakpoint CSS desktop, celui-ci pourrait s'approcher au plus près du format A4 en terme de proportion. D'ailleurs pourquoi pas présenter la preview dans une fenêtre modale également et depuis la page de saisie même...
il y à maintenant quelques années j'avais fait le développement et l'intégration d'un système de facturation pdf pour un CMS, je me souviens qu'il fallait que le système soit en mesure de produire un duplicata avec mention "duplicata" pour toute facture émise. Il faudrait donc voir du point de vue réglementaire si un facturant serait dans l'obligation d'être en mesure de fournir un duplicata au facturé en cas de besoin administratif ou autre droit commercial... D'autre part l'émetteur de la facture gardait également une copie papier et pdf pour classement, coté facturant il peut également nécessiter la présence de métadonnées qui n'apparaissent pas coté facturé... Bref dans tous les cas il faut s'assurer d'un certain nombre de points et peut être faire un tour à la chambre de commerce pour avoir les infos courantes sur ces questions...

Sinon félicitation à toi pour le suivi d'évolution de ton travail, nous savons tous le temps et l'investissement personnel que cela représente ;)

Damien Cosset • May 14 '19

Wow! Merci beaucoup d'avoir pris le temps d'écrire un commentaire aussi constructif et complet ! Je n'avais pas réellement pioché sur l'UI mais ce sont vraiment des remarques très intéressantes. Ça donne à réfléchir 😮

Merci beaucoup 🙏

Drozerah • May 14 '19 • Edited

Je t'en prie c'est tout naturel ;)

Je ne voudrais pas trop charger la barque mais il y a d'autres points à aborder si tu voulais avoir une offre de service. Il faudrait produire sur le site les Conditions Générales d'Utilisation CGU de ton service, quels sont les droits que tu t'accordes vis à vis des utilisateurs mais aussi quels sont leurs droits quand ils accèdent au service... Egalement les Conditions Générales de Vente quand ils souscrivent en accès payant, on parle ici plus généralement des mentions légales au sens large et qui, par définitions, sont obligatoires... Ici par exemple l'offre de service du journal Le Monde ( Attention, je ne dis pas que la lecture de ce journal pourrait être recommandée d'aucune manière ou alors à l’extrême limite pour en faire un objet d'analyse critique à vocation de libérer les jeunes générations de la pensée dominante et de son idéologie qui conduit là où nous savons : CyberPunk post-mondialisé... )

Ensuite viennent certaines considérations techniques et sécuritaires. En effet le secteur de l'économie numérique est un secteur dit sensible, il faut donc être en conformité avec les règles du commerce en ligne et la loi sur la confiance en l'économie numérique... Enfin et très rapidement, si tu détiens de fait des informations stratégiques sur les encaissements d'un contractant, il faut pouvoir offrir un certain niveau de sécurité mais aussi d'engagement par rapport à la continuité du service, pour une raison ou une autre, un contractant pourrait se retourner contre toi s'il se trouvait en difficulté pour accéder à ses données - lui occasionnant pour une raison ou une autre des frais particuliers... En ce domaine, les clients peuvent être très créatifs.... surtout quand ils ont payé pour un service...

Enfin, question sécurité/confidentialité, il serait peut être opportun de crypter les données en base, en sorte que pas même le top admin ne puisse avoir accès aux contenus des utilisateurs au même titre que les mots de passe par exemple...

Évidement si nous vivions dans un monde de gratuité ou l'utilisation de l'argent y serait abolit, alors nous perdrions moins de temps avec ce genre de considérations, ce qui libérerait d'autant le potentiel de créativité humaine qui se trouve actuellement conditionné, et là ça deviendrait tout à coup et sans coût, alors vraiment CyberBisounours... ;)

One last note