This commit is contained in:
Yann Esposito (Yogsototh) 2020-05-08 17:58:10 +02:00
parent 175612b82f
commit 34955e0ca4
Signed by untrusted user who does not match committer: yogsototh
GPG Key ID: 7B19A4C650D59646
3 changed files with 245 additions and 5 deletions

View File

@ -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:

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

View File

@ -0,0 +1,233 @@
#+Title: Who is in Control
#+Subtitle: How I started to take care of the tools I use.
#+Author: Yann Esposito
#+Email: yann@esposito.host
#+Date: [2019-08-17 Sat 20:00]
#+KEYWORDS: opinion
#+DESCRIPTION: Modern tools disapears
#+DESCRIPTION: I include applications, web applications, websites, editors, programming languages.
#+LANGUAGE: en
#+LANG: en
#+OPTIONS: H:5 auto-id:t
#+STARTUP: showeverything
#+begin_notes
This post is a reaction about a few articles I read in a short amount of time.
So do not take that too seriously.
But it will certainly.
#+end_notes
I had to work a lot this week and I mostly didn't read any news.
This morning, I started to read the article I missed.
Here are the articles and threads I read:
- [[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]]
I don't think I read those in that order.
A few years back, HN comments made me look at Clojure.
That was also many positive HN return of experience that made me confident
to use it for a serious business work.
Lot of great advices regarding every aspect of the life and software programming.
Project architecture, etc...
Most of the time, article were good, but HN comment were really great.
Of course, even after a few years, people started to explain that HN
quality dropped.
This can totally be an observer bias.
HN quality might not have really droped but the reader has changed.
So I get it.
I changed a lot accross those years.
And also, yes, HN is mostly see by startupers.
So this is also another big bias.
Still, I'm sad to see that the most popular opinions expressed in those
discussion threads have diverged so much from my point of view.
When I see those news I see a common pattern.
One big corp kill a product that should exist for the common good.
And of course, each time this is because having a common product is
incredibly hard.
Most "common good" products do not have what it takes to be sustainable
enough.
Either you create a very big open-source ness of developers that give their
work freely, or you can grab enough money from different source so you can
pay a few of them.
And this is why the startup model is a lot more efficient.
You want a great product, buy the best best people.
For that you need money and passion.
Most /Free Software/[fn:1] must deal with community driven development.
They should often find a concenssus.
They generally don't have money to pay the people working on that product.
While startup looking to create popular product must take a lot of care
about UX and UI.
What that mean is that the product should need the least possible amount of
energy and learning from the users.
And this is a great thing.
The problem with this approach is that most of the time it also forces
users to follow the workflow and limitations imposed to make it easy to use.
And sometime worse, product simply disapears or change so much I simply
didn't want to use them anymore.
So here is a non-exhaustive list of ~/.*ware/~ that, as a user you don't
want to deal with:
- /bloatware/: remember digg, readitlater, stumbleupon?
- /downgradeware/: Swagger-UI v3 (v2 is neat), reddit new redesign (looks better, but slow)
- /payware/: You rely on our feature, but now, we want you to move or to pay. Fair ;)
- /crapware/: Nothing works as expected unless you pay: Twitter streaming API?
- /dieware/: Remember Friendfeed? Google Reader™?
- etc...
Regarding the integration of VSCode™ inside GitHub™ I think this is 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 really give this situation a taste of [[https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish][EEE]].
So what is the real concern for me.
I imagine a new working environment where surveillance and control on the
developer is a rule.
For a startup CTO/CEO this GitHub™ full work environment offers the
following advantages:
- /security/: impossible or very hard to steal the 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 simple 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.
Like forces you to pay a lot more, remove features, start to become 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,
it makes it harder to play locally with your machine.
4. Sureveillance 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 offer anything without a plan to
make it worth it.
Until here I mostly talked about the Github Codespace article and HN thread reaction.
Where I saw a lot too much enthusiasm about this news for my taste.
But the other articles and their reaction in HN show that yes, HN might not
be for me anymore.
Most of the top level comment in [[https://news.ycombinator.com/item?id=23092657][Name one idea that changed your life]]
are about how to not fall for the trap of the [[https://nesslabs.com/confirmation-bias][confirmation bias]].
That's really great.
But as a former scientist, this is only the very first step.
I might be totally wrong.
But I would have expected that the same question being answered a few years
back on HN would have also provided those answers but also deeper ones.
The [[https://news.ycombinator.com/item?id=23102430][Zoom acquires keybase]] is just again a confirmation that, yes.
When you chose to adopt a tool.
You should ask yourself if it is worth to invest your time and energy in it.
Because most of the time, the tool has a finite and short lifetime.
Finally, about [[https://news.ycombinator.com/item?id=23107123][Making Emacs popular again]].
The first comment 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.
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's a bit of the same Frameworks vs Libraries argument.
Framework are easier to start with, but soon you find corner cases were you
cannot use them correctly and are fighting agains the framework.
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.
So libraries, programming languages and tools have generally subject to the
same debate.
- Easy now, but more difficult later VS harder now but easier in the future.
So if you are going to need a "solution" for a problem for a very small
amount of time. The "Framework/3rd party tool/etc..." is certainly the best
solution to choose.
If you're going to make a living with it, and pass most of your time with
this tool. I highly suggest the second option.
Emacs is like that.
Hard to start, but with emacs come a huge power that you will probably
never be able to get with any other IDE/Editor.
And above this, choosing a Free Software gives you a lot more control about
its evolution.
I wouldn't be surprised if in a few years VSCode started to show ads during
startup ad why not in the middle of your work.
On the other hand this will never occurs within Emacs unless you are doing
this to yourself :).
[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]]
* Conclusion
:PROPERTIES:
:CUSTOM_ID: conclusion
:END:
Choosing a tool:
- will I use it a lot?
- do I trust that I'll use the same tool in 5 years, 10 years?
- who is in control?
- Is it worth to invest my time in it?
Most of these new tools from startup disapears after about 5 years.
So if you plan on using a tool for something important for you.
Take care that it will exists as it is today, or even better in a few years.
* PLAN :noexport:
:PROPERTIES:
:CUSTOM_ID: plan
:END:
- common point, modern tools deprecates and disapear.
- how to chose a good tool