diff --git a/engine/update-file-size.sh b/engine/update-file-size.sh
index b0ce241..341ea88 100755
--- a/engine/update-file-size.sh
+++ b/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#(
)[^<]*(
)#$1'"$sizeinfos"'$2#' $fic
+ perl -pi -e 's#()[^<]*(
)#$1'"$sizeinfos"'$2#;s#()[^<]*(
)#$1'"$gzsizeinfos"'$2#' $fic
done
rm -rf $tmpdir
diff --git a/project.el b/project.el
index 34d55e1..b9a2a8e 100644
--- a/project.el
+++ b/project.el
@@ -171,7 +171,9 @@
(format "%s
"
(format-time-string "%Y-%m-%d %H:%M:%S")))
(size
- "XXK (HTML: XXK, CSS: XXK, IMG: XXK)
")
+ "XXK (html XXK, css XXK, img XXK)
")
+ (gzsize
+ "XXK (html XXK, css XXK, img XXK)
")
(generated-with
(format (concat ""
"
Emacs %s, "
@@ -195,6 +197,7 @@
("tags" . ,keywords)
("rss" . ,rss)
("size" . ,size)
+ ("gz" . ,gzsize)
("gen-date" . ,generated-date)
("get-with" . ,generated-with)
("src" . ,website-code)
diff --git a/project.el.sig b/project.el.sig
index 5b4f1b2..b1d3f50 100644
Binary files a/project.el.sig and b/project.el.sig differ
diff --git a/shell.nix b/shell.nix
index 57a9006..fad7781 100644
--- a/shell.nix
+++ b/shell.nix
@@ -1,5 +1,7 @@
# { pkgs ? import
{} }:
{ 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
diff --git a/src/drafts/XXXX-how-to-choose-your-tools/index.org b/src/drafts/XXXX-how-to-choose-your-tools/index.org
new file mode 100644
index 0000000..ef634be
--- /dev/null
+++ b/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.
diff --git a/src/drafts/XXXX-roe-colorschemes/index.org b/src/drafts/XXXX-roe-colorschemes/index.org
index 04fa819..acec92d 100644
--- a/src/drafts/XXXX-roe-colorschemes/index.org
+++ b/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:
diff --git a/src/drafts/XXXX-roe-colorschemes/mo5.jpeg b/src/drafts/XXXX-roe-colorschemes/mo5.jpeg
new file mode 100644
index 0000000..5092f5b
Binary files /dev/null and b/src/drafts/XXXX-roe-colorschemes/mo5.jpeg differ