yogsototh
/
her.esy.fun
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update

This commit is contained in:
Yann Esposito (Yogsototh) 2020-05-09 00:20:44 +02:00
parent 34955e0ca4
commit b720452dbc
Signed by untrusted user who does not match committer: yogsototh
GPG Key ID: 7B19A4C650D59646
2 changed files with 101 additions and 145 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
shell.nix
View File

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

244
src/drafts/XXXX-who-control/index.org
View File

@ -4,88 +4,47 @@
#+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.
#+DESCRIPTION: Modern tools disapears.
#+DESCRIPTION: Some tools are worth a big time investment.
#+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:
This week I worked a lot more than usual.
So much I didnt take the time to take a look at HN.
So during my morning in the week-end, I started to read what I missed.
And here are a few articles I read along their comments:
- [[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.
Such article have existed for years on different products.
What is their common point?
/Software tooling and their potential change and disparition/.
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.
Accross the years, to many times I saw tools I used disapearing from my
environment.
By tool it could be: applications, web applications, web sites, I think we
can also include programming languages, control versionning tools, building
tools, package manager, etc...
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.
The story can be quite different.
Sometimes the disparition of a tool is positive, because I found a better
one (for me at least).
But too often the tool simply disapears or worse downgrade its quality.
I think we can find different names for those softwares:
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?
- /bloatware/: remember digg, stumbleupon, windows?
- /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™?
- /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...
Regarding the integration of VSCode™ inside GitHub™ I think this is even worse.
So regarding Github Codespace; the integration of VSCode™ inside GitHub™ I
think this could be worse than a disapearing tool.
This is what I would call a /trapware/.
#+begin_notes
@ -95,22 +54,23 @@ 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]].
Furthermore, the fact that Microsoft is involved has a taste of [[https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish][Embrace, Extend and Extinguish]].
So what is the real concern for me.
I imagine a new working environment where surveillance and control on the
developer is a rule.
I think the real concern is that it could become a /work framework/.
So if sufficiently businesses start to use this.
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™ full work environment offers the
following advantages:
For a startup CTO/CEO this GitHub™ Codespace™ could offer the following
advantages:
- /security/: impossible or very hard to steal the code by a single dev.
- /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 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...
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...
@ -126,15 +86,17 @@ For the single developers and open source developers this offer:
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
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,
it makes it harder to play locally with your machine.
4. Sureveillance on meaningless or wrong metrics about your work.
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.
@ -149,85 +111,77 @@ 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.
Yes great.
But I really doubt a company like Microsoft™ offer anything without a plan
to make it worth it.
Until here I mostly talked about the Github Codespace article and HN thread reaction.
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 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 [[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.
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.
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.
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.
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.
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.
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.
The common pattern I see during choice decision is often reducible to:
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.
1. Easy now, but less extensible and more difficult later
2. Harder now but more extensible and less potential blocker in the future.
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.
And mostly the answer is not hard to infer.
If you are going to use a tool a lot, the difficulty to start learning it
is not that important.
If in the end the tool help you to go farther.
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 :).
So if you're going to make a living with it.
And use this tool a lot I highly suggest the second option.
[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]]
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.
* Conclusion
:PROPERTIES:
:CUSTOM_ID: conclusion
:END:
A few last words about Emacs, because for now I can state that this is an
amazing tool which when used correctly will improve your coding experience
and project management a lot.
Choosing a tool:
If you want to start using it from something like VSCode I suggest you to
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.
And I really suggest you to take a look at org-mode.
Mastering it could change your carrier.
org-mode alone would be enough to use emacs.
But there are a lot more to discover.
- 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?
The first difficult aspect when faced with open source is the lack of
centralization.
Instead of having a big bundle with everything prepared to work you
generally need to install each part of a big system separately.
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
[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]]