Ivan Grishaev

Ivan Grishaev's blog

Writing on programming, education, books and negotiations.

Home About Bookshelf RSS
Clojure Emacs Python Programming Interview Video
Книга «Clojure на производстве»
Книга «Clojure на производстве», второй том

  • Помогать или нет

    ,

    В Телеграм-канале Design & Productivity опубликован вопрос, затрагивающий работу и отношения с коллегами. Привожу его полностью:

    Предположим, вы дизайнер в продуктовой компании. К вам подходит коллега, с которым вы по работе почти не пересекаетесь, и говорит: «Мне очень нужно до завтра сделать презентацию для начальства. Сможешь помочь с дизайном?». У вас уже предостаточно своих срочных задач, так что единственная возможность помочь — задержаться на пару-тройку часов после работы.

    Что будете делать?

    А. Задержусь после работы и помогу.

    Б. Задержусь и помогу, но договорюсь о какой-то помощи взамен. Всё-таки жертвую своим личным временем.

    В. Вежливо откажусь. Чтобы сделать хорошо, надо разобраться в задаче, а на это точно нет времени. Может там и презентация-то не нужна.

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

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

    Е. Ваш вариант, которого тут не хватает — пишите мне личным сообщением @gorskiy

    Отличный вопрос. Тут все: работа, отношения, переговоры. Очень жизненная ситуация. Обратите внимание, что речь идет про дизайн, а меня читают в основном программисты. На мой взгляд, вопрос прекрасно ложится и на айтишную отрасль тоже. Только “дизайн” нужно заменить на “программу” или “таску в Джире”, и все станет на свои места.

    Прежде чем читать дальше, советую хорошенько подумать, заварить чаю и только потом продолжать.

    На текущий момент результат голосований выглядит так:

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

    Обращусь к руководителю

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

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

    Вы же, когда одновременно с коллегой подошли к кабинке туалета, не зовете менеджера? Как-то справляетесь?

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

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

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

    Задержусь и помогу

    Вариант, когда вы банально соглашаетесь задержаться и помочь, на мой взгляд, такой же отстой, как и предыдущий. Вы просто сдаетесь, проигрываете переговоры. А если каждую неделю начнут просить, что тогда? Говорить, что я уже другим помог?

    Зачем вообще делать чужую работу? Это же не правильно. Вы вычеркиваете из жизни несколько часов. Скорее всего, они предназначались родным и близким, а может, любимому занятию: спорту, чтению, прогулке. Никто об этом не узнает. Тот, кому вы помогаете, конечно, будет благодарен, но вряд ли оценит. Он подумает: я же остался после работы, почему бы и ему не остаться; чувак понимает в дизайне, ему будет легко.

    Может, думаете, что вы такой супермен и защитник слабых, главный пожарный в проекте? Всем все равно.

    Договорюсь и помогу, но за что-нибудь взамен

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

    Ладно, как все-таки следует поступить?

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

    Лучше всего будет провести с коллегой получасовой разговор и помочь разобраться в задаче. Выяснить, какие входные данные, что нужно сделать, в чем вообще задача, и как ее решить максимально просто. В нашем случае, зачем вообще дизайн в презентации? Вдруг ее покажут инвестору, готорый в гробу видал весь дизайн? Вдруг презентация огонь, а менеджер не владеет темой? Может, хватит логотипа в углу и нормального шрифта? Если речь о программировании, может, достаточно повесить скрипт на крон? Взять готовую тулзу?

    Все это нужно вовсе не вам, а коллеге, чтобы у него возникло понимание задачи. Это автоматически подскажет путь к решению. И что самое важное, коллега в итоге сделает все сам и вырастет профессионально, а вам будет благодарен еще больше, чем если бы вы все за него сделали.

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

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

    Ваша цель помочь понять задачу и направить на верное решение. Материалы в тему:

  • Что читать детям

    , ,

    Если в чем-то я и разбираюсь, то в детских книгах точно. Будучи ребенком я много читал, мама водила нас с сестрой в библиотеку. Многие из книг навсегда врезались в память. В старшем возрасте я и родители многое раздали. Откуда мне было знать, как трудно будет потом догнать эти книги?

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

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

    Хорошая детская книга должна отвечать нехитрым критериям.

    Она должна быть в мире ребенка. Персонажи и быт должны укладываться в привычную картину мира. Мифы Древней Греции, где все режут друг друга и насилуют дочерей – это не детская книга. Проклятый Зощенко с рассказами о том, как наказывают детей – тоже не детская книга. Дичь вроде Чука и Гека, где отец полярник не бывает дома годами, а замученная мать говорит “вы меня в могилу сведете” – это тоже не детская книга.

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

    Книга должна быть оформлена достойно: с твердой обложкой, плотной бумагой и крупными картинками. Не берите поделки на офисной бумаге.

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

    Это не религиозная книга. Никаких библий для детей и всего в том же духе.

    Так вышло, что вчера приходили гости, смотрели книги. Попутно я решил отфотать на телефон и написать несколько строк о каждой. Это не вся коллекция, конечно: другая часть лежит по шкафам. Книги, которые сегодня не купить в обычном магазине, я называю старыми. Их можно прекрасно купить на букинистических сайтах Alib и Libex.

    Оба сайта сохранили интерфейс нулевых, что не должно вас останавливать. Почти любая детская книги ищется там на ура. Если нет, используйте расширенный поиск, гуглите ISBN и ищите по нему. На сервере не учитываются окончания и морфология; это не Гугл, а дубовый SQL с оператором LIKE.

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

    Старайтесь не покупать у украинских продавцов: это будет международная посылка, то есть дольше, дороже, с трудностями в переводе денег.

    Горячо рекомендую к прочтению И ребенку, И родителю вот эти книги.

    Удивительные приключения кролика Эдварда

    Трогательная история о скитаниях фарфорового кролика. Когда-то он жил в шоколаде в богатом доме, но волею судеб его выбросило в океан. Кролик не может двигаться или говорить, только думать. Он не может ни на что повлиять, только воспринимать и анализировать, неважно что он видит: свалку или смерть ребенка. Огромной силы произведение. Ходили с сыном на спектакль.

    Картинки в книге всего лишь черно-белые копии оригинала, вдобавок с белыми полями по краям. Оформление желает лучшего.

    Ветер в ивах

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

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

    Пятеро в звездолете. Семь дней чудес

    Советская фантастика для подростков, две повести: полет в космос в далеком будущем и необычный прибор, способный влиять на поведение людей. Довольно интересно. Иллюстрации черно-белые и довольно редкие. Сыну понравилось, я в детстве тоже любил этот сборник.

    А я был в компьютерном городе. Энциклопедия профессора Фортрана

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

    Древние чудовища России

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

    Тайны анатомии

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

    Говорящий сверток

    Хорошая история про путешествие детей в страну вымышленных животных. Добрый волшебник, хитрый план и освобождение замка от злобных василисков. Много милых созданий, финальная битва напоминает Властелин колец.

    Муфта, Полботинка и Моховая Борода (4 части)

    Приключения троих накситраллей – небольших человечков-гномов в современном мире людей. Тоже ценный экземпляр. Невероятные события в лесу и городе, подвиг, поиск похищенного друга, ссора и воссоединение. Очень жизнеутверждающая книга. Состоит из четырех частей, но сегодня купить их в одном издании, похоже, нельзя. Брал у букинистов, правильное издание насчитывает 400 страниц (это вам для ориентира). Крупные милые иллюстрации.

    Маша и Дракоша

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

    Спасибо Уин-Дикси

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

    Пес по имени Мани

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

    Зоки и Бада

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

    Как это построено

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

    Ляпики и Злохвосты

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

    Витя Малеев в школе и дома

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

    Читайте детям!

  • Thoughts on keyboards

    , ,

    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 WindowsTM LogoTM. 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 WindowsTM LogoTM 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 WindowsTM LogoTM. 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.

  • Зарядка

    ,

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

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

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

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

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

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

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

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

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

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

  • Почему я против объектов. Часть вторая, техническая

    ,

    Это продолжение предыдущего поста на тему ООП. Напомню, что пишу его под воздействием книги Егора “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, что, конечно, противоречит тезисам Егора. Как тут быть, я не знаю.

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

  • Ты же понимаешь

    ,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Weekly links #31

    ,

  • Don't use Leiningen to run shell-scripts

    , ,

    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 крадет деньги

    ,

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

    Купил, посмотрели. Через месяц приходит письмо, что с карты списаны 399 рублей за продление ежемесячной подписки. Полез на сайт и выяснил, что:

    • эти черти сохранили мою карту, хотя нигде подобной галочки не было;

    • они же оформили мне платную подписку, хотя, опять же, нигде этих галочек не было. Вот так, купив фильм у ivi, попадаешь на бабки.

    А дальше еще интересней. Звоню в поддержку. Заранее продумал разговор. Сотрудник, не спросив ни моего имени, ни емейла, словом, никак не подтвердив мою личность, отвечает – назовите номер карты, сделаю возврат. Я назвал, он на кнопку клац – отвечает, готово, ждите денег. И действительно, на следующий день они пришли.

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

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

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

    Короче, ivi.ru, обманщики вы и воры. Позорище.

  • Почему я против объектов. Часть первая, философская

    ,

    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"). Вот и вся разница.

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

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

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

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

Страница 37 из 74