viernes, 30 de octubre de 2020

The Web 2.1

I've never done any kind of smart frontend. My Rails experience was more inside lib/ and app/{models,controllers} than in app/views or assets/ . 


Over the years I tried a few frameworks to see if any of those 'clicked', but I didn't give time to any of them to sink in.

I the re-frame tutorials, but I didn't have any project of any size to try it.

I tried mithrill.js when I wrote my ultimate F5 crusher.

Long time ago I also gave a shot at intercooler.js, and seemed a very orthogonal, low-risk library to sprinkle pre-baked js into elements.  And found in HN that its author moved to develop htmx.

Fast forward to this week. The article "If not SPAs, what?" in HN brought up htmx again, and it was paired with alpine.js, tailwindcss, and others.   And it seems there's a kinda underground trend following the approach of totally detattched js/css on top of old classic Rails/Laravel/Django/YouNameIt. 

Maybe this time I'll swing along with the pendulum.

jueves, 29 de octubre de 2020

Systems, Fun, Code, Dread, Drag, Chaos, GOTO 10

Here's a weird post (the links are good though).

While usual ups and downs in life and work, I try to keep my information intake as regular as I can. When I keep reading and learning from the sources I know do bring me balance, I'm giving the opportunity to get back to my regular ok-state.

 Mood is a reinforcing feedback loop (self-optimizing machine), and if you don't cut it, it can tilt the system and change the equilibrium to a completely different point. And picking the right inputs help me slowing or reverting the feedback loop.

  Few weeks ago, by a friend's recommendation I watched this talk by Jens Mönig , and today this one from _why. And talk about learning, and the fun, and the big ideas that make our profession something like explorers, tinkerers. They both question some of the pains we take for granted as inherent complexity of programming, when they are mostly incidental.

  And it's "funny" I'm taking _why's inspiration, because at some point, he disappeared from the scene. Not sure about the reasons, but probably burnout? And we go to a grey-ish article about Surviving disillusionment.

  The Soul of A New Machine, we see a case of engineering, business, pressure, people enjoying their craft at the same time that they are suffering the extreme contraints of time, tech, decisions made from upwards. But they thrive. And thriving is also a reinforcing feedback loop.

  An internet person that helped me get up in a bump I had a few months ago is Jeremy Howard and his fastai courses and code. I saw him and I could easily take him as a model for how to code, approach problems, teach people, communicate, research (APL!), and even use vim! :) And it's very sad that he got bit by today's off-the-charts Code of Conduct policies and wrong-handling-gone-out-of-hand. I feel extremely sorry for him.

  Another thing that happened recently to me is reading CHAOS by James Gleick. And again, patterns from randomness. Learning about chaos in order and order in chaos. They are part of what we are.

  We like seeing patterns, seeing patterns when others just see noise. It's listening to jazz. And it takes time to teach your ear or eye on seeing those patterns.*

  You see a series of numbers, and there's interference. or the series does not stabilize anywhere. First thing you try to do is find a pattern. Do the numbers grow always? Do they alternate between positive and negative? Maybe they are converging?

  When things do not line up yet, you try to add a dimension there. Do they move faster every time (no matter if up or down)? Can I imagine the derivative of it being constant? or, is it the derivative of something that might have a pattern?

  Can, that derivative be seen as a series, and try to apply the first analysis again? is it always growing? more extreme?.....  (That feels like the enhanced optimization algorithm in "Why Functional Programming Matters").

  So, ups and downs come in patterns, and sometimes their ups and downs come from very concrete explainable things, and sometimes they form out of a small disruption, or they start a turbulence of crazy chaotic ups-downs.

  If not understanding it, can we foresee the chaos coming from a pattern of ups and downs? do we see a pattern, a f'(x), f''(x)? Are we approaching a singularity?

  Fuck if I know.


  * If we apply the learning lessons from _why and Jens, even if there has to be a basic intuition, it shouldn't be hard to see those patterns. But it is.


EDIT: https://hbr.org/2019/07/when-passion-leads-to-burnout. so true

miércoles, 28 de octubre de 2020

Some Tcl

Wanna spend an afternoon learning a scripting language that you didn't know about?

 

Tcl has appeared in HN recently a couple of times, and every time I read about it I remember that great article by antirez showing some very cool features of Tcl. So The link that appeared in HN today was a book by Hal Abelson and Philip Greenspun. 

 

In the intro, It's funny how they compare Tcl and Lisp.

 

Anyway, the links: 

  • http://antirez.com/articoli/tclmisunderstood.html
  • https://philip.greenspun.com/tcl/index.adp

miércoles, 14 de octubre de 2020

An emacs' Feature Development

So, in https://lists.gnu.org/archive/html/emacs-devel/2020-10/msg00691.html there's a proposal for an optimization in emacs, adding empty-directory-p so that elisp users don't have to (null (directory-files dir-name nil 'nodots t))).

And it makes sense to have a faster way. The person that proposed this improvement proposed a solution too. And it was a good one!

Then, Eli proposed something else. Some alternative implementation that:

  • Allows to solve the problem at hand, 
  • Reuses existing code by adding a 'limit' to directory-files
  • Easier to implement
  • Makes the implementation more stratified. You can still create empty-dir-p by calling directory-files
  • in case of passing that limit count to directory-files, we still get a list of files instead of a boolean. It's richer information, in case we need it.

After that, the conversation goes on by trying to figure out if the partial list of files will be useful at some point, or it's adding indeterminism and no value, and finding a balance on simplicity and usefulness. 

All in all, a very good end-to-end conversation about a feature, its implications and its implementations with its corner cases and usability. Every time I see these conversations happening I feel this joy... I love when they happen in my team.


PS: Needless to say, this is a "simple" feature compared to bigger and more complex discussions going on in emacs-devel (which are hard problems that have no perfect solutions). But it's a good case study and there's something to be learned there about approaches, discussions, and building together.

Thanks to everyone involved!