Merge branch 'master' of gitea.esy.fun:yogsototh/her.esy.fun

engine/update-file-size.sh

@@ -31,6 +31,9 @@ for fic in $filelist; do
 
     htmlsize=$(sizeof $fic)
     debug HTML: $htmlsize
+    
+    gzhtmlsize=$( gzip -c $fic|wc -c )
+    debug GZHTML: $gzhtmlsize
 
     xfic=$tmpdir/$fic
     mkdir -p $(dirname $xfic)
@@ -49,21 +52,29 @@ for fic in $filelist; do
 
     css=( $( < $xfic hxselect -i -c -s '\n' 'link[rel=stylesheet]::attr(href)'))
     csssize=0
+    gzcsssize=0
     for i in $css; do
         isize=$( sizeof $webdir/$i )
+        gzisize=$( gzip -c $webdir/$i | wc -c )
         debug $i '=>' $isize
         (( csssize += isize ))
+        (( gzcsssize += gzisize ))
     done
     debug CSS: $csssize
+    debug GZCSS: $gzcsssize
     total=$(( htmlsize + imgsize + csssize ))
+    gztotal=$(( gzhtmlsize + imgsize + gzcsssize ))
     # the space is important before the toh total
     sizeinfos=$(print -- " $(toh $total) (html $(toh $htmlsize), css $(toh $csssize)")
+    gzsizeinfos=$(print -- " $(toh $gztotal) (html $(toh $gzhtmlsize), css $(toh $gzcsssize)")
     if ((imgsize>0)); then
         sizeinfos="$sizeinfos, img $(toh $imgsize))"
+        gzsizeinfos="$gzsizeinfos, img $(toh $imgsize))"
     else
         sizeinfos="$sizeinfos)"
+        gzsizeinfos="$gzsizeinfos)"
     fi
     print -- $sizeinfos
-    perl -pi -e 's#(<div class="?web-file-size"?>)[^<]*(</div>)#$1'"$sizeinfos"'$2#' $fic
+    perl -pi -e 's#(<div class="?web-file-size"?>)[^<]*(</div>)#$1'"$sizeinfos"'$2#;s#(<div class="?gzweb-file-size"?>)[^<]*(</div>)#$1'"$gzsizeinfos"'$2#' $fic
 done
 rm -rf $tmpdir

project.el

@@ -171,7 +171,9 @@
            (format "<div class=\"date\">%s</div>"
                    (format-time-string "%Y-%m-%d %H:%M:%S")))
           (size
-           "<div class=\"web-file-size\">XXK (HTML: XXK, CSS: XXK, IMG: XXK)</div>")
+           "<div class=\"web-file-size\">XXK (html XXK, css XXK, img XXK)</div>")
+          (gzsize
+           "<div class=\"gzweb-file-size\">XXK (html XXK, css XXK, img XXK)</div>")
           (generated-with
            (format (concat "<div class=\"creator\">"
                            "<a href=\"https://www.gnu.org/software/emacs/\" target=\"_blank\" rel=\"noopener noreferrer\">Emacs %s</a>, "
@@ -195,6 +197,7 @@
                     ("tags" . ,keywords)
                     ("rss" . ,rss)
                     ("size" . ,size)
+                    ("gz" . ,gzsize)
                     ("gen-date" . ,generated-date)
                     ("get-with" . ,generated-with)
                     ("src" . ,website-code)

shell.nix

@@ -1,5 +1,7 @@
 # { pkgs ? import <nixpkgs> {} }:
 { pkgs ? import (fetchTarball https://github.com/NixOS/nixpkgs/archive/19.09.tar.gz) {} }:
+  let my_aspell = pkgs.aspellWithDicts(p: with p; [en fr]);
+  in
   pkgs.mkShell {
     buildInputs = [ pkgs.coreutils
                     pkgs.html-xml-utils

src/drafts/XXXX-how-to-choose-your-tools/index.org

@@ -0,0 +1,245 @@
+#+Title: How to choose your tools
+#+Author: Yann Esposito
+#+Email: yann@esposito.host
+#+Date: [2019-08-17 Sat 20:00]
+#+KEYWORDS: opinion
+#+DESCRIPTION: Modern tools tend to disapears.
+#+DESCRIPTION: An app on the web will change, and could break for the worst.
+#+DESCRIPTION: Quite often investing in long living tools which are harder start
+#+DESCRIPTION: with will be worth the investment.
+#+LANGUAGE: en
+#+LANG: en
+#+OPTIONS: H:5 auto-id:t
+#+STARTUP: showeverything
+
+This week I didn't take a look at HN to grab some news.
+And this week-end, in the morning I read those:
+
+- [[https://news.ycombinator.com/item?id=23102430][Zoom acquires keybase]]
+- [[https://news.ycombinator.com/item?id=23107123][Making Emacs popular again]]
+- [[https://news.ycombinator.com/item?id=23092904][Github Codespace]]
+
+Similar articles have existed for years on different products.
+What is their common point?
+/Software tooling and their potential change and disparition/.
+
+Accross the years, too many times I saw tools disapear.
+By tools I mean applications, web applications, web sites.
+I think we can also include programming languages, control versionning
+tools, building tools, package manager, etc...
+
+The story can be quite different.
+Sometimes the disparition of a tool is positive, because I found a better
+one (from cvs to svn to git).
+But, too often, the tool simply disapears or worse downgrade its quality.
+I think we can find different names for those softwares:
+
+- /bloatware/: remember digg, stumbleupon, windows?
+- /downgradeware/: Swagger-UI v3 (v2 is neat), reddit new redesign (looks better, but slow)
+- /payware/: Useful free service ask for money now. Or cost a lot more.
+- /crapware/: Stop to works, quality degrate unless you pay: Twitter streaming API?
+- /dieware/: Remember Friendfeed, Google Reader™, etc...
+- etc...
+
+This is often quite frustrating because you lose a lot of your investment
+with that tool.
+
+Regarding Github Codespace; the integration of VSCode™ inside GitHub™ can
+be even worse.
+This is what I would call a /trapware/.
+
+#+begin_notes
+/trapware/:
+A software that is intented to put you inside a closed ecosystem.
+By slowly but surely add features that while looking great for the user at
+first sight will ensure to entrave other tools to interoperate.
+#+end_notes
+
+Furthermore, the fact that Microsoft is involved give this story a taste of
+[[https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish][Embrace, Extend and Extinguish]].
+
+My real concern is that it could become a /work framework/.
+This could impose the full tooling on a lot of developers without giving
+them the freedom of choice.
+
+For a startup CTO/CEO this GitHub™ Codespace™ could offer the following
+advantages:
+
+- /security/: impossible or very hard to steal the source code by a single dev.
+- /homogeneity/: all dev must use the same development environment. Thus
+  the integration of new dev is faster.
+- /cheaper/: don't need to pay for a full featured, fast machine to each new developer.
+  A less performant machine able to display an electron app will do the trick.
+- /stats/: you can observe the throughput of your developers.
+  How many commits a day, how many lines of code, etc...
+  How much bugs involved which part of the code and thus which dev to blame?
+  How much time the dev is typing, moving its mouse, how much copy/paste is
+  involved, etc...
+
+For the single developers and open source developers this offer:
+
+- /homogeneity/: if I learn how to work in this environment, I'll be easier
+  to recruit and I'll know how to work fast.
+- /lower barrier to entry/: for an opensource repository, it will become much
+  easier for anyone to propose a PR to fix some issue. No need to local
+  clone the project, no need to download all the dependencies to test it
+  locally, etc...
+
+But the price to pay is hidden.
+
+1. First, you are now, not able to choose your local working environment on
+   your machine.
+2. GitHub™ can still change so much to become one of the previously
+   mentionned ~/.*ware/~ you don't want to be involved with.
+   They could forces you to pay a lot more, remove features, redesign to a
+   bloatware, make it harder to interop with other platforms (prefer Azure
+   to AWS etc...).
+3. If everything involve machines in the cloud via the browser and via
+   authorized plugins only. A lot of tools, features will never be allowed
+   in this new ecosystem.
+4. Surveillance on meaningless or wrong metrics about your work.
+   Instead of being evaluated on the feature you shipped or on other higher
+   level metrics. It will be very tempting for your bosses to find flaws in
+   your working habits.
+   We are already living in a world were surveillance, metrics and stats
+   are too easy to grab about a person. And anyone involved know this is
+   all bullshit.
+   Human are very good to play those kind of games.
+   So people really working hard for the best will certainly perform badly
+   compared to other people that simply trick the system.
+
+So if the endgoal of GitHub™ is really to help open source and single
+developer.
+And more generally provide simply a better working experience by adding a
+new tool without any hidden marketing plan.
+Yes great.
+But I really doubt a company like Microsoft™ offer anything without a plan
+to make it worth it.
+
+The [[https://news.ycombinator.com/item?id=23102430][Zoom acquires keybase]] is just another story of a dying product.
+Apparently the keybase team will probably stop maintaining keybase.
+The idea behind keybase was pretty nice.
+And they filled a gap in the current open source world.
+
+The last article I mentionned was [[https://news.ycombinator.com/item?id=23107123][Making Emacs popular again]].
+The first comment in HN was about how VSCode is easy to start with as
+compared to Emacs that need a lot more time to configure correctly for your
+needs.
+Yes, VSCode certainly just work and is easy to use.
+But Emacs is another beast.
+VSCode can become bad very fast, you don't control how it will evolve.
+The fact that this is a succesful Microsoft product does not garanty it
+will keep its currently quality.
+Emacs on the other hand is 44 year old and was designed so that it adapts
+to you.
+You are the one using libs and customizing it.
+
+The argument to chose VSCode instead of Emacs look similar to me to the
+debate "Frameworks vs Libraries".
+Frameworks are easier to start with, but soon you find corner cases were
+you start to fight against them.
+
+A Library on the other hand, is just a bunch of helpers you can use.
+And if you need another functionality, just make it using the libraries.
+But you have a lot more work to do yourself.
+
+The common pattern I see during choice decision is often reducible to:
+
+1. Easy now, but less extensible and harder in the long run.
+2. Harder now, but more extensible and easier in the long run.
+
+As a conclustion I would state that when you need to choose between
+different tools.
+Take the time to think about the investment costs.
+Sometime, the bit of pain in the begining is worth it.
+In particular if you are going to use this tool every days for many hours
+during the following years.
+If on the other hand you don't plan to use that tool much.
+Going with the easy option is certainly the best choice.
+
+I consider Emacs to be of the 2nd option when compared to VSCode.
+Harder to start, but with a lot more control and potential power that you
+will probably never be able to get with most modern IDE/Editor.
+Also choosing a Free Software[fn:1] gives you a lot more control about its
+future.
+
+[fn:1] note I said /free software/ and not /open source/; c.f
+       [[https://www.gnu.org/philosophy/open-source-misses-the-point.en.html][Why Open Source misses the point of Free Software]]
+
+** Post-conclusion -- Emacs is awesome
+:PROPERTIES:
+:CUSTOM_ID: post-conclusion
+:END:
+
+To go beyong my opinion, I'd like to share my experience with editors and
+emacs.
+
+When I started to code.
+We coded with vi, not vim, vi.
+At that time I only knew, =i=, =a=, =dd= and =cw= vi commands.
+So when I started to use IDEs I was thrilled.
+After a few year I started to work for a company that forced me to use
+their shitty computers.
+I started to have wrist issues.
+So I decided to learn vim.
+And I saw the benefits only after a few weeks.
+They were tremendous.
+No more wrist pain.
+And I started to learn a lot of editing automation.
+
+Then I started a new work where we decided to code in Clojure.
+And so knowning that Clojure is a LISP and most LISPers love emacs because
+emacs plugin language is emacs LISP.
+I tried to use spacemacs.
+At that time I didn't want to invest much time in learning Emacs.
+I just wanted to learn the tricks that will make Emacs more valuable to my
+work.
+And it did after just a few days, weeks.
+I used Emacs superficially for years.
+Just Spacemacs + a few useful layers.
+And it was already quite efficient, at least as much as vim.
+
+More recently I started to dig deeper.
+In particular, I read so much praise about org-mode I was really curious.
+And it took me some time to really discover why it is so great.
+First, let's just say that, basic org-mode is already quite valuable.
+
+But you can do a lot.
+And unfortunately this is a bit hard to describe how org-mode is great
+without really digging a bit.
+
+So you can think of org-mode as an extremely versatile todo-list / note
+taker with agenda and time tracking integration.
+Mostly you are in control of your working workflow with org-mode.
+The ability to do org-capture and org-refile is also great.
+Recently there is org-roam that is a step further to make orgmode a nice
+place to keep track of all your knowledge in one place.
+
+Concretely, emacs has changed my workflow a lot and made me a *lot* more
+productive.
+It improved not only my coding workflow, but my full work environment.
+I started with the editor, a few plugins, and slowly, I integrated more
+aspect of my day to day tasks in emacs.
+Emacs is designed to adapt to your own needs you can start to automate a
+lot of small tasks.
+
+I really love Emacs and if you want to joyfully join the Emacs users here
+are my advices:
+
+Start by using either [[https://www.spacemacs.org][spacemacs]] or [[https://github.com/hlissner/doom-emacs][doom-emacs]].
+It will take a few weeks to absorb vim keybindings.
+Slowly you'll start to learn how to configure it for your needs.
+
+I really advise you to take a look at org-mode.
+Mastering it could change your carrier.
+Im my opinion [[https://orgmode.org][org-mode]] alone is a good reason enough to use emacs.
+But there are a lot more to discover.
+
+However, if you are used to tools from startups, with nice UI/UX.
+Almost no configuration cost.
+Be aware that digging in Free Softwares is a lot diffierent.
+Instead of having a big bundle with everything prepared to work you you
+will need to take the time to configure each part of a big system
+separately.
+
+Howevery I'm deeply convinced the investment is really worth it.

src/drafts/XXXX-roe-colorschemes/index.org

@@ -1,9 +1,16 @@
-#+title: My story about colorscheme
-#+date: [2020-05-03 Sun]
+#+title: Return of experience about colorscheme
+#+date: [2020-05-04 Mon]
 #+author: Yann Esposito
 #+EMAIL: yann@esposito.host
 #+KEYWORDS: colorscheme
-#+DESCRIPTION: A generalization of solarized (https://solaryzed.esy.fun).
-#+DESCRIPTION: I tried to make keep the same fundamentals and to free some variables.
-#+OPTIONS: auto-id:t toc:t
+#+DESCRIPTION: The list of colorschemes I used, why I changed.
+#+OPTIONS: auto-id:t toc:nil
 #+STARTUP: overview
+
+* Local variables                                           :noexport:
+:PROPERTIES:
+:CUSTOM_ID: local-variables
+:END:
+# local variables:
+# org-download-image-dir "./img"
+# end: