Finaliser la dernière touche pour devenir écrivain
Depuis petit, raté ou pas, j'avais envie de devenir écrivain. Et grâce aux 26 lecteurs assidus de ce blog (dont 25 robots), et bien dans un paragraphe c'est chose faite.
Voilà : tadam https://github.com/jul/faire_un_livre/blob/main/exemple/sherpa.pdf Un livre écrit par un de ceux dont l'absence de réussite, de gloire ne permet que l'accès à l'édition planquée sur un github en cédant tout les droits sauf celui de paternité.
Le pitch est : sherpa du code : voyage au centre de la soute à charbon des technologies de l'information, vous y trouverez de la drogue, du rock'n roll, mais pas de sexe.
Maintenant, je suis officiellement un écrivain, une oeuvre -bonne ou mauvaise- ne commence sa vie qu'à publication et je dois avouer que me décider à publier publiquement a pris plus de temps qu'écrire, ce qui me fait réviser mon jugement sur la véritable barrière à l'expression publique.
Notre population n'a jamais su autant écrire, n'a jamais été autant cultivée, pourtant, la diversité sociale dans l'édition n'a jamais été autant biaisée en faveur de « ceux qui réussissent », générant une boucle d'amplification malsaine que je me devais -pour le fun- de casser par la ruse.
En faisant le projet « faire un livre » sur lequel est hébergé le livre, je pensais avoir fait le gros du boulot en fournissant mes outils afin que d'autres me copient.
Ici, le plus important n'est pas le livre, que convaincre les gens de s'auto-publier afin de foutre un coup de pied dans la fourmilière.
Le message de ce livre n'est pas tant le livre lui même que la démarche d'auto-publication visant à servir d'alternative à l'édition classique et de tenter de faire de la propagande par le fait en montrant que ça marche.
En ce qui me concerne, j'ai coché, rêve d'enfant inclus de devenir écrivain patenté, toutes les cases de la réussite littéraire : je suis enfin publié.
La cerise sur le gateau serait qu'une personne le trouva bien, mais si je suis écrivain raté, je suis raté que voulez vous que je vous dise ? Peut être que le prochain sera mieux ? Il n'y a pas de risques de réussir sans accepter le risque de l'échec, voir du rejet, et je suis okay avec ça.
Voilà : tadam https://github.com/jul/faire_un_livre/blob/main/exemple/sherpa.pdf Un livre écrit par un de ceux dont l'absence de réussite, de gloire ne permet que l'accès à l'édition planquée sur un github en cédant tout les droits sauf celui de paternité.
Le pitch est : sherpa du code : voyage au centre de la soute à charbon des technologies de l'information, vous y trouverez de la drogue, du rock'n roll, mais pas de sexe.
Maintenant, je suis officiellement un écrivain, une oeuvre -bonne ou mauvaise- ne commence sa vie qu'à publication et je dois avouer que me décider à publier publiquement a pris plus de temps qu'écrire, ce qui me fait réviser mon jugement sur la véritable barrière à l'expression publique.
Notre population n'a jamais su autant écrire, n'a jamais été autant cultivée, pourtant, la diversité sociale dans l'édition n'a jamais été autant biaisée en faveur de « ceux qui réussissent », générant une boucle d'amplification malsaine que je me devais -pour le fun- de casser par la ruse.
En faisant le projet « faire un livre » sur lequel est hébergé le livre, je pensais avoir fait le gros du boulot en fournissant mes outils afin que d'autres me copient.
Ici, le plus important n'est pas le livre, que convaincre les gens de s'auto-publier afin de foutre un coup de pied dans la fourmilière.
Le message de ce livre n'est pas tant le livre lui même que la démarche d'auto-publication visant à servir d'alternative à l'édition classique et de tenter de faire de la propagande par le fait en montrant que ça marche.
En ce qui me concerne, j'ai coché, rêve d'enfant inclus de devenir écrivain patenté, toutes les cases de la réussite littéraire : je suis enfin publié.
La cerise sur le gateau serait qu'une personne le trouva bien, mais si je suis écrivain raté, je suis raté que voulez vous que je vous dise ? Peut être que le prochain sera mieux ? Il n'y a pas de risques de réussir sans accepter le risque de l'échec, voir du rejet, et je suis okay avec ça.
Working in the direction of the wood : the View Controler paradigm
I -don't- like to write boilerplate code and repeat myself.
I'am gonna illustrate my technique to code less boring stuff in web in order to be able to focus on where the fun is : THE BACKEND !
For this journey we are gonna reason by working in the « direction of the wood », meaning trying to assess how to take advantage of the whole web stack.
I don't know how you begin a web project, but having been raised and taught some nice tricks by my fellow frontend coders, I like to begin with the most concrete : a form to put stuff in the system.
The form gives me the text step (action) to code which is the backend controler.
By reading the form I can guess each form goes in a « record » that looks like a database table, and each input in a column.
For the sake of discussion, let's use a SGDBR as a backend we miss a lot of features of a column like : is it nullable, does it have an ondelete cascade clause, a default value, a foreign/primary key constraint.
But ... we can still add non HTML5 attributes to the input and regular browser will hide them while they are still in the DOM.
So, it's totally ok with any HTML parser/browser to write
You can set by convention that id is a primary key, it won't shock anyone.
Which generates with an easy to write html parser the following SQL :
Given you have a set of convention based notably on the syntax of specialized input (such as datetime-local) for transtyping, then you not only advertise to user the data model, but also it's most accepted string encoding. Like for telephone, urls, dates in the standard of the WEB.
A textarea can be mapped because is has a size to a VARCHAR(column x raw), select box to enum (or else according to the SQL dialect) ...
With HTML as a model (which is a mean and not and end) we achieve at least one important part of SQL most important features : creating a concrete datastore without wich all is just abstraction.
Now we miss the delete/update/create/search that are expected at the end point ...
That's the easy part, just add a few input type=submit with the name of the operation and your controler can now deduce the operation from the name of the table given by the name of the form, with the parameters of the form as an input with the operation on the table described as the value of the input of type submit.
Writing a controler that does just this generically is quite a walk in the parc.
So then, you add a templating engine to write custom views, and you can copy paste your HTML form from your model/CRUD to have a ready to use human/ajax interface :D
Here are 2 examples of the form copy pasted :
And in some Information Technology fields sharing data is more important than hiding them : science, metrology, openData, libraries reference.
It means that by sharing a single page you give to your partner the exact description to your data model to duplicate it locally and with the provided search endpoint given in the depedency order ... the mean to fully duplicate the WHOLE database.
Of course this makes storing password and private data a bit tricky :D
That you can solve by removing from search operation all column table having the word secret or private in it ...
I told you HTML as a model aka the View Controler Paradigm (getting rid of the M of MVC), VC : c'est pas à chier. And at the end you just need a few dozains of line of code to produce this interface having fun where it is :
I'am gonna illustrate my technique to code less boring stuff in web in order to be able to focus on where the fun is : THE BACKEND !
For this journey we are gonna reason by working in the « direction of the wood », meaning trying to assess how to take advantage of the whole web stack.
I don't know how you begin a web project, but having been raised and taught some nice tricks by my fellow frontend coders, I like to begin with the most concrete : a form to put stuff in the system.
The form gives me the text step (action) to code which is the backend controler.
By reading the form I can guess each form goes in a « record » that looks like a database table, and each input in a column.
For the sake of discussion, let's use a SGDBR as a backend we miss a lot of features of a column like : is it nullable, does it have an ondelete cascade clause, a default value, a foreign/primary key constraint.
But ... we can still add non HTML5 attributes to the input and regular browser will hide them while they are still in the DOM.
So, it's totally ok with any HTML parser/browser to write
<form action=/comment >
<input type="datetime-local" name=created_at_time default="func.now()" />
<input type=number name=id />
<input type=number name=user_id reference=user.id nullable=false />
<input type=number name=comment_id reference=comment.id ondelete=cascade >
<textarea name=message rows=10 cols=50 nullable=false ></textarea>
<input type=url name=factoid />
<select name="category" nullable=false >
<option value=comment >Comment</option>
<option value=story >Story</option>
<option value=story_item >Story Item</option>
<option value=delivery >Delivery</option>
<option value=answer >Answers</option>
<option value=question >Questions</option>
<option value=test >Tested</option>
<option value=finish >Finish</option>
</select>
</form>
which ... with some tricks of JS/CSS is presented this way :
You can set by convention that id is a primary key, it won't shock anyone.
Which generates with an easy to write html parser the following SQL :
CREATE TABLE comment ( created_at_time DATETIME DEFAULT (CURRENT_TIMESTAMP), id INTEGER NOT NULL, user_id INTEGER NOT NULL, comment_id INTEGER, message VARCHAR(500) NOT NULL, factoid TEXT, category TEXT NOT NULL, PRIMARY KEY (id), FOREIGN KEY(user_id) REFERENCES user (id), FOREIGN KEY(comment_id) REFERENCES comment (id) ON DELETE cascade );you can use the non existings tags in HTML such as reference, ondelete to piggyback the lax HTML parsers we all use and infers 95% of all the data needed to set an SQL schema.
Given you have a set of convention based notably on the syntax of specialized input (such as datetime-local) for transtyping, then you not only advertise to user the data model, but also it's most accepted string encoding. Like for telephone, urls, dates in the standard of the WEB.
A textarea can be mapped because is has a size to a VARCHAR(column x raw), select box to enum (or else according to the SQL dialect) ...
With HTML as a model (which is a mean and not and end) we achieve at least one important part of SQL most important features : creating a concrete datastore without wich all is just abstraction.
Now we miss the delete/update/create/search that are expected at the end point ...
That's the easy part, just add a few input type=submit with the name of the operation and your controler can now deduce the operation from the name of the table given by the name of the form, with the parameters of the form as an input with the operation on the table described as the value of the input of type submit.
Writing a controler that does just this generically is quite a walk in the parc.
So then, you add a templating engine to write custom views, and you can copy paste your HTML form from your model/CRUD to have a ready to use human/ajax interface :D
Here are 2 examples of the form copy pasted :
It means that by sharing a single page you give to your partner the exact description to your data model to duplicate it locally and with the provided search endpoint given in the depedency order ... the mean to fully duplicate the WHOLE database.
Of course this makes storing password and private data a bit tricky :D
That you can solve by removing from search operation all column table having the word secret or private in it ...
I told you HTML as a model aka the View Controler Paradigm (getting rid of the M of MVC), VC : c'est pas à chier. And at the end you just need a few dozains of line of code to produce this interface having fun where it is :
Subscribe to:
Posts (Atom)