Ivan Grishaev's blog

Thoughts on keyboards

Jan 24, 2018 keyboard, emacs, typing

Recently, Nikita Prokopov, a friend of mine, published a great post about remapping arrow keys. I highly support that idea; we really move cursor often. It is too time-consuming to shift a palm to and fro across the keyboard. But this material inspired me to share my own ideas about keyboards and typing. Please read Nikita’s post first before we go further.

The main statement I’d like to highlight is all the modern keyboard are useless in general. Literally, I mean: a typical typing device might be used only in ineffective way. Once you start explore it trying to be productive, your very body will alarm you with pain saying “please don’t do that”. And this is not a joke.

There is such a metaphor as “share you pain”. That’s exactly what I’d like to do: to discuss the real pain caused by keyboards. The thing is, I’ve been trying to be productive with Emacs, an ergonomic keyboard and blind typing at the same time. (That was too much for a single pair of hands, now I see that clearly; but not those days.) What I’ve got was unbearable ache in my left palm. It started a year ago and I still have it. Surely, that could be my personal trait. I do not blame anybody. But I know for sure, our modern keyboard might be a bit better then now.

Ok, take a minute and look down at your keyboard. It does not really matter if it’s a computer one or your laptop. It is likely you’ll see a device like this:

What is wrong with it you may ask? Well, lot of things.

First, the keyboard does not fit your body, your natural forms. Put your hands down on the table. Look at the angle of each hand. Do you see symmetry? Both of your hands are tilted on the same angle relative to the invisible axis in the middle. Now try to find such symmetry on your keyboard. You won’t. All the buttons are tilted on an angle what is good for your right hand. But you’ve got yet another hand, the left one! The buttons’ angle does not satisfy that left hand at all.

The fact of ignoring human anatomy looks quite strange to me, really. Because nowadays, every piece of design that is used by people is being adopted for them. About 20 years before, it could be a feature maybe. Look, ergonomic camera! Ergonomic fridge! Today, everything we produce for human beings must be ergonomic. It has become a default option, not a feature.

In a car, a steering wheel is put on the left if it is a European car, but not on the right. Digital cameras have a special thick fragment put on a handle to let a palm cover it with the whole surface and thus prevent if from falling down. Long ago, a computer mouse was just a brick with sharpen edges. Today, it has got curly and quite complicated form that respects anatomy. And so forth and forth.

We, programmers, designers, managers, spend lots of time in front of a computer. It’s our working tool. With its help, we get money to live and care our families. I’d rather say that having a good computer is more important than having a car. So why the input device is still so poor? We deserve something better I believe.

The second flaw is a standard keyboard forces us to press utility buttons with your little finger on the most of devices. That’s sick: it’s the most weakest finger of your palm. Press Ctrl+C several times. Do you feel how high tension between the finger is? The more fingers are closer to each other, the more it is healthier for a palm. Thanks Apple, on Mac, we mostly operate using thumb and forefingers. But still, Alt, Shift, Control or Fn make my hand hurt again.

Since I’m a developer, I cannot complain on programming languages that force you to use all the types of parentheses, colons and semicolons, single and double colons and even apostrophes and backquotes, slashes and backslashes. The funny fact is, all of them require your right little finger to work hard. I used to improve my blinding typing skills some time ago; the program prompted particular fragments of classical prose to train me. I moved fast. Once I started to write code with blind ten-fingers method, almost all the typos were related to those symbols I mentioned above. Say you’d like to complete a function call in Javascript: return 42, semicolon, closing paren; curly closing paren. Damn, it was the square one. Delete. Now it’s minus. Damn!

Python has been some sort of a victory: it showed that a programmic language may be free from machinery symbols still being elegant and expressive. Any Lisp dialect is also good: say, Clojure requires quite fewer of them. Yes, there are three sets of parens when declaring data structures, but on the other hand, semicolon is not used at all. Racket considers any type of parentheses as round ones. So putting square parentheses inside round ones is just a matter of personal choice.

The next thing, there are to many utility buttons I believe. Let’s count them: Control, Shift, Alt, Caps, Function key, Command on Mac. On Windows keyboards, there is an Application key with the Windows^TM Logo^TM. We do not really need them all at once! Seriously, when I used to develop on Windows the main modifier was control: Ctrl-C, to copy and paste, Ctrl+O to open a file, etc. On Mac, the main button is the Command key, right? But still, the Control has not gone yet, we have in on Mac keyboards. In terminal, every process listens for Ctrl+C or Ctrl+D to be terminated. As the result, I need two buttons instead of one.

And that’s more. I may say I know for sure why do we need Shift, for example. But I’m not sure about Alt. Really, why do we need that for? The same about the Function key. The button with the Windows^TM Logo^TM looks hilarious to me: a dedicated key to open the “Start” menu, oh dear.

Capslock is totally useless and takes too much room for itself. I don’t see any reason for its existence. Every single text editor may convert selected fragment from lower to UPPER case and vice versa.

I have a feeling that most the shortcuts could be made with just two utility keys: Command and Alt/Option/Whatever. That would be enough. The only reason we won’t ever rich that is developers would never come to agreement or any sort of standard.

What makes me totally insane is those keys are named differently on various platforms. On Mac, Alt is not Alt, but Option. In Emacs (which is really almost an operation system) Alt is Meta, and the Command key is Control by default. I know, there is a long story behind each of those namings, but I don’t have any intention to dive into it.

Another thing I cannot tolerate is when a key is marked with a pictogram instead if its name. Their forms are so complicated and really say nothing! At lest Shift has some sort of sense behind its pictogram: a thick arrow that says “press me and I’ll move the layout up”. Now take Mac’s Command key: ⌘. I don’t have a clue what does that figure mean. It isn’t better then the Windows^TM Logo^TM. Alt is the worst case: ⌥. I even cannot find proper words to describe those lines where one of them breaks for no reason. For me, it always takes about five to ten seconds to parse an expression like “press ⌥⇧T to open a new tab”. Even Perl code looks better to me.

Moving on, there cannot be an excuse for such huge space button. Yes, it appears quite frequently in European languages, no matter if a text is a prose, a poem or Linux source code. But the greater frequency is still not an option for increasing size of a button! For example, the “e” letter appears quite often in English; bit its size as little as “j” or “x” that have the lowest rate.

If your keyboard is not just from the shop, look at your spacebar carefully. Or even detach it and move it closer to the light. You’ll see that there is some fixed area where your thumb finger hits the surface constantly; but the rest of it is untouched and probably covered with dust (or food, to be honest).

Here is mine spacebar: it’s plain to see that both left and right sides are polished with my fingers. The left side is even more because of Emacs. But the center of the button is dirty. (I used to shift levels in Photoshop to let you see it better.) I cannot even remember when I pressed it in the center. It is just a waste of useful space.

It’s clear to me that huge spacebar was just borrowed from ancient typewriters. They had it probably because of two reasons. The first one is there was just unused space on the lowest row; it should be filled with something. The second is, pressing mechanical keys required significant physical effort in those days. So the thumb finger moves could be a bit inaccurate. But all of this do not relate to our days anymore.

You may look at Asian keyboards that have tiny spacebars. The reason is, in hieroglyphs, spaces appear quite rarely. Pay attention, a spacebar still might be pressed without any troubles whereas now a user has got some additional keys.

The image was taken from that great post: “Tiny Space Bar on Japanese Keyboards”. There are far more interesting layouts there.

That was the main reason I had to abandon my MS Sculpt keyboard. Its spacebar key is really huge as I’m not a human but an elephant. In Emacs, almost every single operation requires holding Command key. As the result, my thumb finger have been in such a position for minutes or even hours:

Every single coding session ended up with pain in my palm. My intention was to remap the left space button to the Command key. That would be a great success if it was possible; but it’s not. The keyboard sends the same machine-wise signals for both spacebars. So every remapping tool considers them as the same physical button.

At the moment, I’m dreaming of some sort of keyboard with a tiny space. It would be great to press both space and Command keys without moving my thumb finger far from each other.

It is 2018 behind my window, but none of operation systems has good remapping tool out from the box. Starting with a fresh system, I need to download and install some software and set it up somehow. On Mac, we’ve got Karabiner which is the most developed tool so far. But as far as I see, hacking a keyboard input is a tricky stuff that can be prevented by the manufacturer at any moment. Apple does have any intentions to care about Karabiner + Mac compatibility.

Karabiner was rewritten from scratch several times due to major Mac OS releases. Although they have done a great job so far, some occasional bugs still appear from time to time. For me, the keyboard input just hangs sometimes. The keyboard seems to be turned off completely for ten seconds. Then it tries to play all that key sequence that has been delayed at once causing unpredictable behavior: windows close and open, dialogs pop up and so on.

The standard key remapping dialog in Mac is ridiculously poor and may satisfy only beginners.

Most of the “ergonomic” keyboard are terrifying. They are huge, quite expensive, and full of features I will never use. One of them has a LED layer what shines with different colors as a wave. Great. Another one looks and weighs like an anvil. All of them cost like an aircraft. You cannot buy it at your neibour shop. After all, there is no any guarantee that you won’t put it on your shelve to collect dust for ages.

More and more keyboard startups appear and try to solve those problems. They make a website, a single YouTube video and launch Kickstarter program. I do not have any knowledge if some of them have come to success. I mean, if Apple or any other manufacturer started to produce their keyboards. I tend to think that most of them are just charlatans, to be honest.

Computer manufactures do not care about the keyboards they produce at all. At least they could split the buttons on two groups and change the left’s one angle properly. Or maybe remove Caps or Control on Mac. They’ve already wiped Escape that was quite small and didn’t cause any troubles. Oh by the way, now we’ve got that keyboard screen on Macbooks. It is a feature that completely relies on marketing but not user experience at all.

The last thing that worth be mentioned is even a great external keyboard consumes free space and forces you to re-invent your workplace. Mac’s touchpad is amazing, but a custom keyboard lets you either to shut your Macbook down and use external monitor or put it on top of the built-in one. In both cases, you lose touchpad access. Go by an external one for $100. Now you completely depend on additional devices and the workspace has become few.

I don’t know if I expressed my experience in a clear way, but altogether those points make me upset. I hope at least something will change in the future. Maybe, they will start to improve default keyboards to let us work without suffering one day.
Зарядка

Jan 19, 2018 life, workout

Мне кажется странным, что утренняя зарядка воспринимается как превозможение. Типа, я такой молодец, в 35 лет начал делать зарядку. Или в контексте обещаний на следующий год: клянусь начать с января. Ну офигеть теперь.

Нет ничего проще, чем делать зарядку. Ее просто нужно делать, а не обещать. Организм привыкает мгновенно. Сделал раз, два, а потом организм скажет: давай-ка еще. И так на всю жизнь.

Зарядка занимает от силы 5 минут, а пользы вагон. Весь день чувствуешь себя лучше. Нет постоянного желания размяться. Перестают болеть спина, мышцы. Это отличный способ прогнать сон вместо кофе и сигарет.

Если поделить пользу от зарядки на потраченное время, число приблизится к бесконечности. Поход в зал или бассейн займут часа два, а зарядка, даже самая долгая – минуты.

Зарядку можно делать даже когда болеешь или не выспался. Просто размять суставы и потянуться уже огромная польза.

Улучшается порядок в жизненном укладе. Теперь есть дело, которое совершаешь регулярно. Вообще, лучший способ улучшить жизнь – это регулярно делать что-то хорошее. Зарядка – одно из таких дел.

Я делаю ее по утрам уже лет семь-восемь, за все время пропустил не больше десяти раз. Делаю в командировках, в поездках на конференцию. Организму просто надо. Постепенно приучил всю семью.

Все банально: голова, руки, пояс, наклоны, ноги. Можно поприседать.

Зарядка автоматом исключит вредные привычки. Совмещать не получится, тело скажет – хорош, либо кури\бухай, либо зарядка.

Это же прекрасно: все хорошее происходит само, от вас только 5 минут участия.
Почему я против объектов. Часть вторая, техническая

Jan 19, 2018 oop, programming
Это продолжение предыдущего поста на тему ООП. Напомню, что пишу его под воздействием книги Егора “Elegant Objects”. Прошлая публикация была немного абстрактной и слегка резковатой. Полагаю, так случается со всеми после чтения какого-либо из текстов Егора. Недаром его идеи будоражат интернет: каждый пост становится предметом бесконечных обсуждений.

В этой части поговорим на более технические темы, поэтому тональность будет поспокойней. Напомню, это не полноценная рецензия на книгу; их уже написано достаточно. Скорее, ниже приведены возражения к некоторым тезисам из “Elegant Objects”.

Сама по себе книга очень понравилась. Хоть я и далек от ООП, но прочел с удовольствием. Польза от материала в том, что он действительно продвигает вперед, заставляет задумываться о смысле обыденных паттернов и приемов. Через всю книгу красной нитью проходит тема поддержки кода, что редко встречается в любой другой литературе на тему разработки.

Выражаясь терминами Ильяхова, в книге описан (и вызывает в читателе) чувственный опыт, то есть все то, что автор пережил и испытал лично. Это делает материал очень убедительным. Возникает особое доверие, которого нет при чтении очередного руководства.

Напомню, Егор предлагает строить программы при помощи неизменяемых объектов. Каждый такой объект представляет интересы реальной и, возможно, меняющейся сущности реального мира. Объект должен запрашивать минимум входных данных, в противном случае он становится композицией других объектов поменьше. С этими же “элегантными” объектами связан отказ от NULL, getters/settets, наследования и других вещей из промышленного ООП, с чем я полностью согласен.

В то же время не могу не возразить по следующим тезисам.

В стремлении дробить объекты на мелкие сущности мы неизбежно придем к ситуации, когда их станет очень много. Знания о каждом объекте будут просты, но потребуется знание о том, как их совмещать. Эту информацию можно будет зафиксировать разве что в readme или wiki к какой-нибудь библиотеке, и большая часть кода будет набираться банальной копи-пастой.

Думаю, каждый сталкивался с ситуацией в проекте на Java, когда на каждый квант информации заведен класс, и совершенно не ясно, как построить общую картину. Аргумент выше я позаимствовал из блога Дмитрия Бушенко, который тоже писал отзыв на книгу. Здесь мне нечего добавить к аргументу Дмитрия: помню, разбираясь с Хаскелом, я тоже был поражен взрывному росту типов по мере роста программы. На каждую пару есть функция-конвертор, но пока ее найдешь…

Примеры, которые приводит Егор с классами Cash и пр. действительно смотрятся красиво. То же самое можно сказать про класс Max, который инкапсулирует два числа и сам притворяется числом, производя вычисления только когда к нему обращаются как к числу. Сама элегантность! Но все же у меня остались сомнения, что средних размеров проект, выстроенный на маленьких объектах, не начнет пошатываться из-за множества внутренних связей.

Рассмотрим код, который соответствует критериям Егора на элегантность. Вот он. Это копирование данных из одного источника данных в другой. Взят из блога Егора.
```
new LengthOfInput(
  new TeeInput(
    new BytesAsInput(
      new TextAsBytes(
        new StringAsText(
          "Hello, world!"
        )
      )
    ),
    new FileAsOutput(
      new File("/tmp/hello.txt")
    )
  )
).value(); // happens here
```
Оставим за скобками вопрос о длине кода (императивная версия займет три строки); нас пока это не интересует.

Главное преимущество подхода Егора выражается в декларативности: мы выстраиваем дерево объектов, которое ничего не делает при создании. Такое дерево можно построить, где-то хранить, передавать куда-то или даже сериализовать. Типичному Lisp-программисту это напомнит принцип “код как данные”, хотя очень условно.

Остается только нажать на крючок, который каскадно спустит весь механизм.

Недостатки метода вытекают из его же достоинств. Прежде всего, дерево лениво. А ленивость не всегда хороша. Чем ленивей структура данных, тем больше будет дистанция между исполнением и ошибкой.

В примере выше все действие совершается в финальном вызове .value() верхнего объекта. Сказать, что это неочевидно, значит ничего не сказать. Помню, мне приходилось отлаживать схожий код с отложенными вычислениями. Много сложности вносило то, что при выводе объектов в консоль совершались скрытые действия, например, итерация по коллекции, чтение потоков. Это было очень не очевидно, а потому тяжело в поддержке.

Те, кто программирует на Питоне, должны помнить, что с выходом третьей версии все методы, ранее возвращающие списки, теперь стали возвращать ленивые итераторы, по которым можно пройтись один раз. Приходилось каждый такой вызов оборачивать в list(), чтобы скопировать элементы в фиксированную коллекцию. Фактически это борьба с ленивостью. Особенно раздражало, когда в интерактивном сеансе выводишь коллекцию в терминал, она считывается целиком, выводится на экран и становится пустой.

Словом, я не уверен в достоинствах дерева объектов.

Следующий момент, на который я бы хотел обратить внимание: приглядитесь к именам классов из примера выше. Мне бросается в глаза одинаковый паттерн именования: ThisAsThat, то есть Одна сущность в Другую. У экземпляров этих классов всего лишь один метод .value() (или .text(), .bytes(), что угодно), который возвращает результат типа второй сущности.

Налицо утилитарность таких объектов: их жизненный цикл состоит исключительно в том, чтобы перевести данные из одного типа в другой. Нужен ли этот класс в дальнейшем? Нет. Это просто преобразование из А в Б. Такой объект даже не заслуживает “уважительного”, как пишет Егор, отношения. Это просто преобразователь, конвертор, читатель, что угодно.

Такие утилитарные объекты нарушают принцип из статьи “перестаньте писать классы”, на которую я ссылался в предыдущей части. Если у класса один метод, то он должен быть функцией. Потому что если мы заинтересованы в одном методе, нет смысла хранить состояние и вообще оборачивать исходные данные в какую-то абстракцию.

Этот принцип кажется мне слишком весомым, чтобы его нарушать.

Взгляните на код: буквально на ровном месте мы возвели множество сущностей: Text, Bytes, Input, TeaInput. А ведь всего-то требовалось скопировать данные. С точки зрения программиста, у которого в проекте десяток библиотек и фреймворков, это должна быть автомарная операция.

Сейчас я попрошу вас, не перематывая страницу вверх, мысленно построить это же дерево. Что было первым? Пишу по-честному: сначала LengthOfInput, под ним TeaInput, а дельше цепочка из Одного в Другое. То ли байты в текст, то ли строка из текста или наоборот. Кто на ком стоял? Теперь подумайте о том, что копирование данных происходит постоянно и во многих местах. Неужели придется держать порядок в голове?

Как я уже писал, появляется потребность в особом знании о том, как организовать такие классы. Напрашивается идея о “схлопывании” такого дерева в отдельный объект-копировальщик, какой-нибудь DataCopier, что, конечно, противоречит тезисам Егора. Как тут быть, я не знаю.

В третьей части я коснусь темы структур данных и функционального подхода, которым Егор тоже уделил внимание в книге.
Ты же понимаешь

Jan 18, 2018 life, idiots

Немного найдется речевых оборотов, которые меня раздражают. Я совершенно спокойно отношусь к мату, словам-паразитам, булшит-сленгу – заафектить, консерн, форварднуть, пропоузал.

Даже “я тебя услышал” кажется мне что-то забавным. Но если и есть паттерн, от которого хочется прекратить беседу, так это “ты же понимаешь, что…”. Это ни разу не ок, так говорить.

Подставляя это словосочетание в начало фразы, собеседник пытается навязать мысль, причем весьма грубым способом. Ты же понимаешь, и все, без вариантов. Неважно, что дальнейшее высказывание идет вразрез со всякой логикой, главное сделать упор на первом утверждении.

Этот дешевый трюк применяется исключительно перед публикой. В одиночку он не работает, потому что обоим собеседникам видна вся его ложная предпосылка. Но аудитория редко удерживает в голове всю цепочку, поэтому достаточно огласить взаимное согласие, а затем топить за свое мнение без какой-либо аргументации.

Сюда же относятся “мы все согласны, что…”, “очевидно же, что..” и сто других усилителей:

– Ты же понимаешь, что функциональное программирование применяется только в академической среде.

– Ты же понимаешь, что большой проект невозможен на языке без статической типизации.

– Ты же понимаешь, что серьезный бизнес выбирает .Net.

– Очевидно же, GoLang это технология будущего.

– Очевидно же, что Java умирает.

– Все согласятся с тем, что Кложа – хайп.

– Конечно же, только на Руби веб-разработка максимально эффективна.

Подобные фразочки – верный индикатор того, что разговор пора сворачивать. Или по крайней мере что беседа перешла совсем не в то русло.

Во-первых, некрасиво утверждать что-то за собеседника. Хочешь знать его мнение – спроси. Во-вторых, если вы оба придерживаетесь одних идей по теме, то и спорить не о чем.

Я никогда не стесняюсь ответить, что нет, я не понимаю и мне не очевидно. И обязательно кину ответочку – несколько открытых вопросов. Кому это очевидно? Что дало повод так думать? Откуда эти сведения?

В попытке объяснить оппонент, как правило, сам же запутается в противоречиях. Вызвался – теперь крутись на сковородке. Я уже закрыл чат, а он будет писать еще час.

Лучше вообще не разговаривать с теми, кто злоупотребляет словами-усилителями. Мне приходилось общаться с разработчиком, который, если наверняка знал, что прав, добавлял пафосное “Коне-е-ечно!” к каждой фразе. Это было ужасно: малейший диалог с ним звучал как разговор короля с подданным:

– Можно пофиксить первым способом, а можно вторым. Предлагаю вторым. Что скажешь?

– Вторым коне-е-ечно!

Типа, я уже все продумал, а ты говно.

Вы же понимаете, что так делать не нужно. Верно?
Weekly links #31

Jan 14, 2018 read, life
- Birdcage liners
  
  Joel hasn’t been blogging for years, but thank him, a new post has been published.
- GitHub’s technology predictions for 2018
  
  I’m not a fan of making and reading predictions, but this one deserves our attention.
- Five ways to paginate in Postgres
  
  Really, five ways to do that, from the standard one to the most exotic I’ve ever seen. Quite interesting article!
- Capturing ClojureScript Errors on the Server
  
  Good technical stuff from Dmitry on Clojure.
Don't use Leiningen to run shell-scripts

Jan 9, 2018 clojure, lein, make
Working with various Clojure projects, I noticed one thing that really worries me. I’m talking about developers who add more and more entries into :prep-tasks vector in project.clj file. Please stop it. Every time you want to put there a new task to compile CSS or build a Docker image, take a minute or two to think on that. Let’s discuss the problem.

Lein is a great tool of course, really a piece of art. But its abilities are not unlimited. Remember, its main purpose is to manage a Clojure-driven project. I think, everybody agree with that statement.

The Clojure project you are working on is only a part of a top-level project in business terms. Besides both server and UI sides, your application probably sends emails, pushes notifications, interacts with Blockchain network and does further more things.

According to GitHub statistics, you may have even 99% percent of code written with Clojure. But still, there is definitely something that is beyond it. Thus, please do not use Lein for those tasks that do no have any relation to Clojure code.

Recently, I faced a situation when running REPL caused building Ethereum smart contracts first. That step assumes you have installed software of proper versions and configured paths, text configs, etc. Compiling them was a really resource- and time-consuming duty.

The next step was to compile CSS sources. Again, it required installing Ruby, less and wait for some time.

Remember, I did’n want all of this to happen. All I wanted to do is to connect to REPL from Emacs and debug one tiny function. Needless to say, I just commented those tasks in project file.

Again: your Clojure project should know nothing about compiling CSS, building email templates, fetching anything from the network, querying Ethereum, building Docker image or whatever else. Especially when we talking about running REPL. It should run without any troubles at any time.

That’s why I’m strictly against using lein-shell plugin or something similar that lets you run shell commands from Lein.

Of course, building a project requires passing through a list of particular steps that were partially mentioned above. What should we use for that? Shell-scripts? Any modern Javascript task runner? No, just Make utility that has been here for ages.

“Put that gun down and let me explain.” (c)

I know Make is an ancient tool that came from rough C/C++ times. Those days, developers knew quite few about a pipeline, CI or methodologies in general. Almost every single programming language nowadays offers a task runner that takes modern requirements into account. But still, for a set of tasks that might be run upon your project, there is nothing better then a Makefile at the top of file structure. And here is why.

Make utility is a binary tool that does not force you to install a new version of Node.js, Python or Ruby. Probably, it’s already installed on your computer since most of Linux distributions have it out from the box. It works perfectly of various systems. I have never faced any troubles with it switching between Linux and Mac.

Such modern shells as zsh support auto-completing make targets when pressing <TAB> character after “make”. That really saves time especially when you use prefixes. Say, in my pet project, besides Clojure-related targets, I’ve got a bunch of commands to operate on Docker images. These are docker-run, docker-build, docker-compose-up/down and more. Each of them takes 60 to 100 characters so it’s impossible to remember them. So in terminal, I type make doc<TAB> and see a short subset of Docker-related stuff.

I consider any Makefile as not just a list of commands but rather a knowledge base of your project. The more the project develops, the more operations you need to perform over it. Where to store all the those commands? In your wiki? Nobody reads it. A better solution would be to keep them as close to the code as it possible.

Make utility runs extremely fast whereas lein needs about five seconds to boot up. That’s pretty long time, really. Imagine each command line tool hangs for a couple of seconds before it runs. That would be a hell on your computer. A situation that makes me angry is when I mistype in a long lein command like lein migratus craete user-updated, wait for five seconds and see an error message saying there is no craete subcommand in migratus. With make utility, there is no an option for such things.

One of my favorite features is to ask a user for prompt when typing names, passwords or any other sensitive data. Here is an example of how usually I create a new SQL migration:
```
create-migration:
    @read -p "Enter migration name: " migration \
    && lein migratus create $$migration
```
When I type make crea<TAB><RET> (remember, auto-complete magic works here), the system asks for a new migration name. I enter a string that I need and a new migration named properly appears.

Makefiles may include other ones so probably you can maintain separate files for both production/developer modes or for developers/ops teams. Since those files support comments, you are welcome to put doc hints there.

The utility allows to chain targets. When I start working on a new task, at least I need to perform three steps: 1) migrate the database; 2) run tests to ensure everything works before I change something; 3) launch REPL. In my make file, I’ve got a separate target for each step. But I can call them in chain as well:
```
make mig<TAB> te<TAB> re<TAB>
```
that expands into:
```
make migrate test repl
```
and finally becomes:
```
lein migratus migrate
lein test
lein repl
```
Inside a makefile, you can call for another makefile what may become a powerful feature of your build process. Here is how it works.

Say, in our project, on the top level of it there is a “email” folder that brings Node.js project for building email templates. Our Clojure application use those compiled templates for further processing with Selmer to send final emails to our clients. It’s obvious, I need those templates only when I work with our email subsystem and never else. So it would be madness to force all our developers to install Node.js with tons of packages and compile the templates each time they launch REPL.

Inside “email” folder, there is a separate Makefile that knows how to deal with that sub-project. It installs all the requirements and has some useful targets, say, to run compiler in debug mode or open a browser window for preview.

A small fragment of that make file:
```
all: install build dist

install:
	yarn install

build:
	node_modules/.bin/gulp build --production

dist:
    cp ...
```
The default target performs all the targets that are required to get final templates. Now, in the main make file that is on the root of the project, I put:
```
EMAILDIR := $(CURDIR)/email

.PHONY: email
email:
    make -C $(EMAILDIR)

uberjar-build: email
    lein uberjar
```
So this configuration gives me freedom of choice. When I launch REPL, I don’t need all that stuff to deal with compiling emails. Probably, I may work in a company for years without touching them. But those guys who do, they run make email and get the full and ready email installation. Finally, no one be able to build an Uberjar without compiling fresh emails.

Now take into account that those emails were just a small part of a project. Remember, for successful production build you might need fetching huge JSON declarations from 3rd-party services; compiling smart contracts; building Docker images; building CSS and much more. Now answer, whey lein utility that even doesn’t have any default capabilities for that, should do it instead of special tools designed for exactly those things?

I think it’s obvious now that lein only should be used to manage your Clojure code. Never configure it to run non-Clojure-related stuff.
Как ivi.ru крадет деньги

Jan 7, 2018 ivi, idiots
Месяц назад решили с женой посмотреть один кинчик. Я уже не в том возрасте, чтобы шариться по торрент-помойкам, поэтому покупаю на Ютубе. Но именно этого фильма там не было. Гугл вывел меня на ivi.ru, где фильм был, и вот что из этого вышло.

Купил, посмотрели. Через месяц приходит письмо, что с карты списаны 399 рублей за продление ежемесячной подписки. Полез на сайт и выяснил, что:
- эти черти сохранили мою карту, хотя нигде подобной галочки не было;
- они же оформили мне платную подписку, хотя, опять же, нигде этих галочек не было. Вот так, купив фильм у ivi, попадаешь на бабки.
А дальше еще интересней. Звоню в поддержку. Заранее продумал разговор. Сотрудник, не спросив ни моего имени, ни емейла, словом, никак не подтвердив мою личность, отвечает – назовите номер карты, сделаю возврат. Я назвал, он на кнопку клац – отвечает, готово, ждите денег. И действительно, на следующий день они пришли.

Напрашиваются несколько выводов. Первый – ivi.ru действует незаконно, сохраняя карты и подключая платные услуги без ведома владельца. Что-то вроде мобильного опсоса, потерявшего берега.

Второе – в команде ivi об этом прекрасно знают, и уже отработан стандартный сценарий возврата денег. Моментальная реакция говорит о том, что на этот случай заведена отдельная кнопка. Никаких личных данных и подтверждений личности не просят, чтобы не раздувать скандал. Вы когда-нибудь делали возврат в обычном магазине? Там и заявление, и паспорт потребуют. А тут анонимно и по номеру карты.

Третье – действия ivi.ru это обычная кража. Конечно, они прислали письмо. Но что если я не читаю почту? Упор сделан на то, что я не замечу списания. Типичный русский наебизнес. Почему-то именно русская компания смошенничала с моей картой. Совпадение? Не думаю (с).

Короче, ivi.ru, обманщики вы и воры. Позорище.
Почему я против объектов. Часть первая, философская

Jan 5, 2018 oop, programming
UPD: вторая часть.

LT;DR: это очень личный взгляд на ООП, который я обдумывал довольно долго, но окончательно сформировал после прочтения книги Егора “Elegant Objects”. Если коротко, я высказываюсь против идеи представления кода в объектной модели. Некоторые аргументы почерпнуты из сторонних публикаций и адаптированы для краткости. В таких случаях я даю ссылку на оригинал.

Изначально я планировал написать два в одном: и про ментальную, и про техническую составляющие ООП, но так как текст получается объемный, опубликую пока что первую часть о том, как ООП ложится на (мой) мозг.

Объекты, как утверждают Википедия и учебники, помогают отобразить картину физического мира в коде. Думаю, всем это объяснял преподаватель в школе или университете на примере класса кота или собаки. Потом примеры с наследованием, переопределением класса “голос” и так далее.

За последние годы мое увлечение ООП плавно сошло на нет. В одном из постов я прямо признавался, что не понимаю его принципов. Главное, что меня смущает: во время работы, если это был не строго объектный язык, а Питон, JS или PHP, то все задачи я решал простыми функциями. Каждый раз мне говорили, что просто проект легкий, что однажды наступит БОЛЬШОЙ ПРОЕКТ, где с функциями ты хлебнешь. Но время шло, БОЛЬШОЙ ПРОЕКТ так и не наступил, и, кажется, в эпоху микро-сервисов его уже не дождешься. А я все пишу на функциях и неизменяемых коллекциях. В чем же дело?

И любой объектный код я переписывал на функциях с сокращением числа строк до двух раз. Как так?

Причина мне видится в том, что ООП очень абстрактно. Одно и то же событие реального мира можно интерпретировать в объектной модели совершенно по-разному. Отсюда и трудности изучения, и лишний код.

Представим, что Вася отправляет письмо Пете. На языке объектов это записывается так (опустим определения классов):
```
User vasya = new User("Vasya");
User petya = new User("Petya");
Message msg = new Message("Hello!");
vasya.send(msg, petya);
```
Тут, возможно, я нарушил один из бесчисленных паттернов ООП: отвечать за отправку должен не пользователь, а само сообщение (что весьма спорно). Поэтому следующий после меня разработчик поправит код вот так:
```
msg.send(from=vasya, to=petya)
```
Это уже не синтаксис Джавы, в ней нет именованных аргументов, а скорее Питона. Написал так, чтоб было понятно: метод .send() принимает отправителя и получателя и сам отправляет письмо.

Уже на этом этапе видна вся неоднозначность и зыбкость объектного мышления. Согласно паттернам, отправку письма логичней вынести в класс сообщения. С другой стороны, в реальном мире именно пользователь инициирует отправку. Письмо это неодушевленная сущность, набор байт или листок бумаги. Как он может что-то отправлять?

Теперь представим, что на каждый чих мы проектируем класс и создаем объект. Как можно утверждать, что отношения между ними логически верны? Как это доказать?

Зыбкость этого принципа порождает все новые и новые книги и статьи в блогах, где авторы доказывают, что именно их подход обеспечивает прозрачность и поддерживаемость программы, написанной в объектном стиле. Но на более приземленном уровне это выражается, простите, в срачи – бурные обсуждения в чатах, когда эмоции и мнения намного опережают опыт.

Проблему отношений между объектами я называю “кто на ком стоял”. В самом деле, ручка пишет по бумаге pen.writeOn(paper) или бумага с помощью ручки paper.write(pen)? Каждый, кто поспешит ответом в духе “ну конечно первый (второй) вариант”, не учитывает, что это совершенно субъективно.

Предполагаю, что именно поэтому в ООП-среде так популярен рефакторинг. Ключевая фича каждой промышленной IDE – облегчение рефакторинга: переименование и перенос методов, автоматическая адаптация кода.

В окружающем нас реальном мире физические объекты играют далеко не решающую роль. Иными словами, не все можно выразить через объекты. Рассмотрим, например, акт рукопожатия. Следуя принципам Егора, отразить в коде это можно так:
```
class User {
  private String name

  User(String name) {
    this.name = name;
  }
}

class Handshake {
  User user1;
  User user2;

  Handshare(User user1, User user2) {
    this.user1 = user1;
    this.user2 = user2;
  }

  void shake() {
    // ... лог в консоль или что угодно
  }
}

User user1 = new User("Ivan");
User user2 = new User("Petr");
Handshake hs = new Handshake(user1, user2);
hs.shake();
```
Но ведь физически рукопожатия не существует. Нет в нашем мире такого объекта, его нельзя купить, смастерить, поставить на полку. Это событие, акт или, выражаясь точнее, действие! А что в программировании выражает действие? Функция.

Предположим теперь, что друзья пожали руки несколько раз с интервалом в 10 минут. Будет ли правильным вызывать у того же объекта метод .shake()? Или на каждый раз создавать новый объект?

Если первое, не противоречит ли это принципам ООП? Ведь все это разные рукопожатия, совершенно независящие друг от друга. Что если они жали руки с перерывом в 10 лет?

Если второе, то чем это отличается от вызова функции? Мы создаем объект, вызываем единственный метод и тут же забываем его? Зачем тогда класс и объект? Если один-два метода это все, что нам нужно от класса, не проще ли завести функцию?

На эту тему уже неписана отличная статья “перестаньте писать классы”, изучите обязательно. Видео со слайдами, перевод на Хабре.

Далее можно рассуждать о более сложных вещах. Рукопожатие все же имеет косвенное отношение к физическим объектам. Но такие абстрактные понятия как ненависть, симпатия, эгоизм, честность, религия выразить объектно невозможно. Я имею в виду, что не составит труда написать класс с нужным именем, который инкапсулирует другие классы. Но спрашивается, в чем здесь смысл?

Добавьте процессы: горение, магнитные волны, свет. Все, что перечислено выше имеет значение только в действии. Важен не сам объект, а как он изменяет другие сущности. Опять же, про написана хорошая статья, где рассматривается река с точки зрения ООП- и ФП-программиста.

В книге “Elegant Objects” Егор справедливо замечает, что сегодняшнее ООП это просто структура данных с прикрепленными к ней функциями. Однако, не делается акцент на том, сколь масштабно это явление. С выходом языков Go и Rust на них перешли тысячи бывших Java и С++ разработчиков, и, похоже, сочли новые языки вполне себе объектными. А ведь и в Go и в Rust объекты – это банальные сишные структуры. И если функция принимает первым аргументом такую структуру, то вместо some_action(data, 1, "test") можно написать data.some_action(1, "test"). Вот и вся разница.

Очевидно, сегодня для большинства вызов функции через точку кажется главным показателем объектности языка. Я не хочу никого этим обидеть. Человеку свойственно упрощать рутину: выражать код всей программы с помощью настоящих, “элегантных” объектов, как советует Егор, мне кажется неподъемным делом. А со структурам и функциями проще, и даже похоже на ООП.

Я утверждаю, что современный ООП-подход, согласно которому мы выражаем все сущности как объекты, так же похож на окружающий мир, как шахматы на реальную войну. То есть в кукольной манере и гротескным упрощением. Тысячи лет назад войска действительно выстраивались напротив противника, впереди пешие войска, по бокам боевые слоны, сзади командование. Сегодня это не так.

Кратко резюмируя. В ООП до сих пор нет четкого понимания, как выстраивать отношения между объектами. Огромное число паттернов сбивает с толку. Объекты в коде не могут точно описать нематериальные понятия: природные процессы, отношения между людьми. Гораздо большее значение имеет не объект, а действие над ним.

В следующий раз поговорим о технической стороне ООП.
Надо короче

Jan 4, 2018 life, shorter

Удивительно, что в детских организациях, например, образовательных и спортивных школах совершенно не знают, как проводить мероприятия. Я имею в виду провести так, чтобы дети не устали от бессмысленного ожидания.

Типичную линейку в школе ставят следующим образом. Выходит директор. Выходит завуч. Выходит сука-единорос-депутат (иногда – его представитель). Выходит ветеран. Выходит сраный министр культуры и еще кто-то в этом же роде.

Каждый из них несет полную пургу: хочет что-то пожелать, пытается пошутить. Бедные дети стоят и слушают эту ахинею. Сорок минут, час. Потом еще сценка. Неужели нельзя уложиться в 30 минут? Выпиздить метлой этих балаболов и просто запустить детей в класс?

Всем учителям известно, как трудно удержать внимание ребенка хотя бы из-за физиологических причин. Урок подготовишки длится 25 минут, первоклассника – 30 минут, и так далее с шагом в 5 минут. Только к третьему классу урок начинает длиться стандартный академический час. Так почему же вы, учителя-завучи-директор, из года в год закатываете линейку на час с лишним?

Соревнования в спортивных школах ничуть не лучше. Опять же парадокс – каждый тренер должен уметь организовать детей. Заставить слушаться группу из 15 человек это особый навык. Но правильно организовать соревнования никто не умеет.

Зашли в зал и ждут. Участники на месте, судьи на месте, родители расселись. Нет, сука, чего-то ждут. Слово директору школы. Слово организатору. Гимн России. И только потом, с постоянными задержками, поломками микрофона, потерей нужных бумажек, начинаются выступления детей.

Родители уже не ждут результатов, потому что измучены больше детей. Мест на всех нет, гардероба хватило на половину пришедших. Только выступил ребенок, в машину и домой.

А детские концерты! Выступающим по 6-8 лет, концерт длится 1 час 20 минут! Те, кто в конце, к моменту выступления становятся как мочалки. Организаторы издеваются над родителями: каждый же пришел только ради своего ребенка. Почему я должен сначала высидеть 15 номеров? Почему нельзя провести два концерта?

Та же история с мультфильмами и представлениями. Почему нельзя поставить пьесу на 45 минут вместо полутора часов? Ну или час максимум. Это же долго! Все сцены очевидно затянуты. Ребенок теряет суть повествования. Главные идеи в детских произведениях просты, их невозможно растянуть на час без очевидных искажений.

Откуда эта манера впихнуть в детей как можно больше? Наоборот, даже с точки зрения бизнеса короткие постановки выгодней: ребенок (и родитель) меньше устанет, значит, останется больше потенциала для потребления других услуг.

Тем, у кого есть дети, предлагаю эксперимент. Попросите пересказать вашего ребенка полуторачасовой мультфильм, который он только что посмотрел. Как зовут персонажей, в чем их конфликт, куда они пошли\полетели, что сделали, чем закончилось. Редкий ребенок ответит на все вопросы. Даже вы не сможете пересказать целый фильм, он остался в голове в виде отдельных образов и сцен.

Лично мне с возрастом все больше и больше книг и фильмов кажутся затянутыми. Короче надо, короче! Техническую литературу невозможно читать: одну и ту же мысль обсасывают на 10 страницах. Предложения порой столь похожи, что напоминают копипасту. Актеры в фильмах начинают конфликт из-за ничего, проблемы надуманны, сцены длятся дольше, чем нужно. Вертится мысль – а не пора бы вам свалить уже из кадра или занять зрителя чем-то поинтересней?

Хронометраж, группа выступающих, число слайдов в презентации, пункты в повестке дня – все это лучше укоротить. Всегда.
Итоги 2017 года

Dec 31, 2017 2017, results

Упомнить все невозможно, поэтому пробежался по блогу и выделил следующее.

Стал больше писать в блог. Написал 99 постов не считая этого. Значит, всего 100. Красиво.

Повысил долю английского в блоге. Где-то каждый пятый пост на английском. Писать на нем медленней; порой трудно передать мысль в нужном ключе.

В этом году блогу стукнуло 5 лет – юбилей!

Изнемогая в Турции, опубликовал подробное руководство по переходу с PostgreSQL на Datomic. Статья выстрелила: ее разместили на кложурных ресурсах и Hacker News. В News. В течение недели в блог заходили тысячи человек из англоязычной аудитории.

Публиковался в IndieHackers с рассказом про Queryfeed.

Завел Телеграм-канал в параллель блогу.

Весь год проводил митапы в нашем клубе Рефакторинга. Видосы – на нашем канале и сайте.

Стал читать про криптовалюты. Книга Mastering Bitcoin – хороша, но больно занудна.

Путешествовал! Ездил в Берлин на Евро-кложу и в Балтимор на юбилейную конфу. В первый раз в жизни побывал в США. По ссылкам – отчеты о городах.

Стримил Кложу, в т.ч. и на английском. К сожалению, так и не сделал это занятие регулярным.

Участвовал в Хайлоад-Капе! Ничего не занял, но был дикий драйв. Выгородил Кложу с ее Датомиком. Отчитался на английском.

Написал и поддерживаю свою первую библиотеку на Кложе, которой действительно пользуются.

Вместо с Никитой и Рахимом стал писать в блог Grumpy – это где жалуются на плохой дизайн. Изливаю там душу.

В этом году организм сказал твердое нет долгой работе за компом: заболели шея и руки. Как выкрутился расскажу в следующем году.

Уволился из проекта. Осталась неделя в январе, но это мелочи.

Поставил самую большую в жизни елку.

С праздничком!

← Страница 38 из 75 →