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

update

Browse source
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 <nixpkgs> {} }:
{ pkgs ? import (fetchTarball https://github.com/NixOS/nixpkgs/archive/19.09.tar.gz) {} }: { 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 { pkgs.mkShell {
buildInputs = [ pkgs.coreutils buildInputs = [ pkgs.coreutils
pkgs.html-xml-utils pkgs.html-xml-utils

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

@ -4,88 +4,47 @@
#+Email: yann@esposito.host #+Email: yann@esposito.host
#+Date: [2019-08-17 Sat 20:00] #+Date: [2019-08-17 Sat 20:00]
#+KEYWORDS: opinion #+KEYWORDS: opinion
#+DESCRIPTION: Modern tools disapears #+DESCRIPTION: Modern tools disapears.
#+DESCRIPTION: I include applications, web applications, websites, editors, programming languages. #+DESCRIPTION: Some tools are worth a big time investment.
#+LANGUAGE: en #+LANGUAGE: en
#+LANG: en #+LANG: en
#+OPTIONS: H:5 auto-id:t #+OPTIONS: H:5 auto-id:t
#+STARTUP: showeverything #+STARTUP: showeverything
#+begin_notes This week I worked a lot more than usual.
This post is a reaction about a few articles I read in a short amount of time. So much I didnt take the time to take a look at HN.
So do not take that too seriously. So during my morning in the week-end, I started to read what I missed.
But it will certainly. And here are a few articles I read along their comments:
#+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=23102430][Zoom acquires keybase]]
- [[https://news.ycombinator.com/item?id=23107123][Making Emacs popular again]] - [[https://news.ycombinator.com/item?id=23107123][Making Emacs popular again]]
- [[https://news.ycombinator.com/item?id=23092904][Github Codespace]] - [[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. Accross the years, to many times I saw tools I used disapearing from my
That was also many positive HN return of experience that made me confident environment.
to use it for a serious business work. By tool it could be: applications, web applications, web sites, I think we
Lot of great advices regarding every aspect of the life and software programming. can also include programming languages, control versionning tools, building
Project architecture, etc... tools, package manager, 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. The story can be quite different.
I changed a lot accross those years. Sometimes the disparition of a tool is positive, because I found a better
And also, yes, HN is mostly see by startupers. one (for me at least).
So this is also another big bias. 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 - /bloatware/: remember digg, stumbleupon, windows?
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) - /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 ;) - /payware/: Useful free service ask for money now. Or cost a lot more.
- /crapware/: Nothing works as expected unless you pay: Twitter streaming API? - /crapware/: Stop to works, quality degrate unless you pay: Twitter streaming API?
- /dieware/: Remember Friendfeed? Google Reader™? - /dieware/: Remember Friendfeed, Google Reader™, etc...
- 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/. This is what I would call a /trapware/.
#+begin_notes #+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. first sight will ensure to entrave other tools to interoperate.
#+end_notes #+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 think the real concern is that it could become a /work framework/.
I imagine a new working environment where surveillance and control on the So if sufficiently businesses start to use this.
developer is a rule. 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 For a startup CTO/CEO this GitHub™ Codespace™ could offer the following
following advantages: 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 - /homogeneity/: all dev must use the same development environment. Thus
the integration of new dev is faster. the integration of new dev is faster.
- /cheaper/: don't need to pay for a full featured, fast machine to each new developer. - /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. 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 - /stats/: you can observe the throughput of your developers.
commits a day, how many lines of code, etc... 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 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 How much time the dev is typing, moving its mouse, how much copy/paste is
involved, etc... involved, etc...
@ -126,15 +86,17 @@ For the single developers and open source developers this offer:
But the price to pay is hidden. But the price to pay is hidden.
1. First, you are now, not able to choose your local working environment on your machine. 1. First, you are now, not able to choose your local working environment on
2. GitHub™ can still change so much to become one of the previously mentionned ~/.*ware/~ you your machine.
don't want to be involved with. 2. GitHub™ can still change so much to become one of the previously
Like forces you to pay a lot more, remove features, start to become a 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 bloatware, make it harder to interop with other platforms (prefer Azure
to AWS etc...). to AWS etc...).
3. If everything involve machines in the cloud via the browser, 3. If everything involve machines in the cloud via the browser and via
it makes it harder to play locally with your machine. authorized plugins only. A lot of tools, features will never be allowed
4. Sureveillance on meaningless or wrong metrics about your work. 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 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 level metrics. It will be very tempting for your bosses to find flaws in
your working habits. your working habits.
@ -149,85 +111,77 @@ So if the endgoal of GitHub™ is really to help open source and single
developer. developer.
And more generally provide simply a better working experience by adding a And more generally provide simply a better working experience by adding a
new tool without any hidden marketing plan. new tool without any hidden marketing plan.
Yes great. But I really doubt a company offer anything without a plan to Yes great.
make it worth it. 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. 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 The [[https://news.ycombinator.com/item?id=23102430][Zoom acquires keybase]] is just another story of a dying product.
be for me anymore. Apparently the keybase team will probably stop maintaining keybase.
Most of the top level comment in [[https://news.ycombinator.com/item?id=23092657][Name one idea that changed your life]] The idea behind keybase was pretty nice.
are about how to not fall for the trap of the [[https://nesslabs.com/confirmation-bias][confirmation bias]]. And they filled a gap in the current open source world.
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. The last article I mentionned was [[https://news.ycombinator.com/item?id=23107123][Making Emacs popular again]].
When you chose to adopt a tool. The first comment in HN was about how VSCode is easy to start with as
You should ask yourself if it is worth to invest your time and energy in it. compared to Emacs that need a lot more time to configure correctly for your
Because most of the time, the tool has a finite and short lifetime. needs.
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. Yes, VSCode certainly just work and is easy to use.
But Emacs is another beast. But Emacs is another beast.
VSCode can become bad very fast, you don't control how it will evolve. 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. The fact that this is a succesful Microsoft product does not garanty it
You are the one using libs and customizing. 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. The argument to chose VSCode instead of Emacs look similar to me to the
Framework are easier to start with, but soon you find corner cases were you debate "Frameworks vs Libraries".
cannot use them correctly and are fighting agains the framework. 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. 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. 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 The common pattern I see during choice decision is often reducible to:
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 1. Easy now, but less extensible and more difficult later
amount of time. The "Framework/3rd party tool/etc..." is certainly the best 2. Harder now but more extensible and less potential blocker in the future.
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. And mostly the answer is not hard to infer.
Hard to start, but with emacs come a huge power that you will probably If you are going to use a tool a lot, the difficulty to start learning it
never be able to get with any other IDE/Editor. is not that important.
And above this, choosing a Free Software gives you a lot more control about If in the end the tool help you to go farther.
its evolution.
I wouldn't be surprised if in a few years VSCode started to show ads during So if you're going to make a living with it.
startup ad why not in the middle of your work. And use this tool a lot I highly suggest the second option.
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]] 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 A few last words about Emacs, because for now I can state that this is an
:PROPERTIES: amazing tool which when used correctly will improve your coding experience
:CUSTOM_ID: conclusion and project management a lot.
:END:
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? The first difficult aspect when faced with open source is the lack of
- do I trust that I'll use the same tool in 5 years, 10 years? centralization.
- who is in control? Instead of having a big bundle with everything prepared to work you
- Is it worth to invest my time in it? generally need to install each part of a big system separately.
Most of these new tools from startup disapears after about 5 years. [fn:1] note I said /free software/ and not /open source/; c.f
So if you plan on using a tool for something important for you. [[https://www.gnu.org/philosophy/open-source-misses-the-point.en.html][Why Open Source misses the point of Free Software]]
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