Merge branch 'master' of gitea.esy.fun:yogsototh/her.esy.fun
This commit is contained in:
commit
6ae31cc7fa
7 changed files with 275 additions and 7 deletions
|
@ -32,6 +32,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)
|
||||
hxclean $fic > $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
|
||||
|
|
|
@ -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)
|
||||
|
|
BIN
project.el.sig
BIN
project.el.sig
Binary file not shown.
|
@ -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
|
||||
|
|
245
src/drafts/XXXX-how-to-choose-your-tools/index.org
Normal file
245
src/drafts/XXXX-how-to-choose-your-tools/index.org
Normal file
|
@ -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.
|
|
@ -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:
|
||||
|
|
BIN
src/drafts/XXXX-roe-colorschemes/mo5.jpeg
Normal file
BIN
src/drafts/XXXX-roe-colorschemes/mo5.jpeg
Normal file
Binary file not shown.
After Width: | Height: | Size: 18 KiB |
Loading…
Reference in a new issue