• Интерфейс Dropbox

  Jul 6, 2020 life, ui, dropbox

  У Никиты в статье Computers as I used to love them показана установка Dropbox. Легко заметить, что некогда удобный софт стал жирным монстром, где вместо одного клика нужно пять. Жаль, что Dropbox повторил судьбу Evernote и пал жертвой маркетологов и иже с ими.

  Недавно понадобилось кое-что с Дропбокса, и я поставил последний клиент. Прошел ад с миллионом экранов – это, конечно, жесть. И добавлю один важный факт.

  Дело в том, что Dropbox долгое время считали эталоном программы без интерфейса. В этом был его козырь, с которым он влетел с двух ног. Разве до Dropbox не было средств синхронизации? Были. Вот только Dropbox упростил процесс до минимума. Видишь папку? Кидай туда файлы, и они появятся в другом месте. Все на уровне операционной системы, копировать-вставить, перетащить мышкой. Не надо ни к чему привыкать. Да, было окошко с настройками, но обычный юзер туда не лазил — незачем.

  Вы будете смеяться, но в каком-то лохматом году я делал обмен репликами в 1C на базе Дропбокса. Один комп выгружал обновления в папку, второй подхватывал, как только они там появились. Затем наоборот. Работало!

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

  

  Хорошо это или плохо, судить не нам. Прежняя модель была удобной, но, возможно, в ней бизнес вышел на плато-фазу, а деньги на шеф-повара нужны. Синхронизация файлов, в общем-то, вещь простая, и рано или поздно наступает насыщение. Все довольны, все работает, а поскольку Dropbox — не банк и не мобильный оператор, предложить ему больше нечего. Даже блокчейн не подключишь и машын лерниг. Кажется, они делали почтовый клиент, но закрыли его.

  Морали нет, просто наблюдение. Больше Dropbox не подходит на роль программы без интерфейса. Ушла эпоха.

• Анонс книги на Хабре

  Jul 1, 2020 book

  Разместил на Хабре анонс книги. Помогите вывести новость на главную.

• Она такая твёрдая

  Jun 26, 2020 life

  Такая же будет у вас, если закажете. Ещё не поздно.

  

• О принятии решений

  Jun 24, 2020 life

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

  Я тоже долго страдал от этого, пока не открыл важные вещи. Пишу их даже не для вас, а чтобы самому потом перечитывать.

  Первое – моменты, когда вы не можете принять решение, нужно ценить. Это означает, вы вышли из зоны комфорта, продвинулись на территорию, где не были прежде. На самом деле не так часто бывает выбор, когда некому помочь, потому что сюда не попадают материальные блага. Так что самое лучше – не кусать ногти, а порадоваться: еще год назад такого выбора не было!

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

  Третье – свершение выбора важнее его исходов, потому что свершение – это движение вперед. Даже если вы продвинулись не в том направлении, можно скорректировать курс. Это лучше, чем бесконечно сидеть на одном месте.

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

• Страница книги

  Jun 23, 2020 book

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

• Предзаказ книги

  Jun 18, 2020 book

  UPD (2021 Mar 20): Принимаю заказы и сейчас, осталась небольшая коробка книжек. А если кончатся, напечатаю.

  UPD (2020 Dec 03): Финальная версия книги и вся информация о ней.

  TL;DR: анонсирую предзаказ книги. Чтобы получить ее на лучших условиях, сделайте следующее:

  • нажмите на кнопку оплаты Яндекс.Денег (ныне ЮMoney);
  • укажите ФИО, емейл, телефон и адрес доставки (ниже я объясню, зачем эти данные);
  • оплатите картой или из кошелька;
  • ждите доставки на указанный вами адрес.

  Сумма предзаказа 800 рублей. Сюда входит печать книги в твердой обложке (примерно 500 рублей) и доставка (300 рублей в среднем по России). Ожидаемая дата рассылки книг – через три недели.

  В поле “адрес” впишите индекс, службы доставки без него страдают.

  Подробности под катом.

  Read more →

• Что там с книгой? — 5

  Jun 16, 2020 book

  Уже совсем скоро:

  

  Read more →

• Ищу помощника

  Jun 15, 2020 помощник

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

  Требования к вам:

  • Знание git: ветки, пулл-реквесты, мердж. Учетка на GitHub;
  • Азы bash, make и прочих GNU-утилит;
  • Владение текстовым редактором, чтобы выполнять монотонные штуки;
  • Базовые знания Сlojure и Python;
  • Желательно, чтобы у вас был Мак или Линукс (первое предпочтительней). Возможно, получится и с Виндой, но тогда придется настраивать Докеры/виртуалки и разбираться, почему что-то не работает;
  • Будет супер, если вдруг вы знакомы с LaTeX.

  Задачи, которые готов предложить (по убыванию важности):

  • Адаптировать книгу о Сlojure под устройства с небольшим экраном (Kindle и телефон). Нужно изменить форматирование кода на Сlojure;
  • Оформить питонячьи скрипты в пакеты;
  • Взяться за issue проекта Etaoin. Я не прикасался к библиотеке почти год, а пользователи что-то пишут;
  • Поработать над закрытым проектом на Сlojure.

  Работа не для состоявшихся профессионалов, а для человека уровня junior или middle. Одновременно ее можно рассматривать как менторство: если что-то не получается, я готов объяснить, в том числе голосом.

  Как будем работать:

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

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

  Если вам это подходит, напишите мне письмо на адрес ivan@grishaev.me с темой “Помощник” (или “Помощница”). Расскажите коротко о себе: чем занимаетесь и что умеете из списка требований. Напишите свою часовую зону и желаемую сумму в месяц: мне проще отталкиваться от ваших пожеланий.

  Спасибо.

• Что думаю о Swagger

  Jun 9, 2020 programming, swagger

  Одна из самых бесполезных вещей в айти — это Swagger. Так называется система, которая отображает REST-апихи в JSON-файле. Идея хорошая, но на практике вымораживает мозг. Давно порывался написать о ее минусах, и вот на днях опять подгорело.

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

  Swagger это порождение мира node.js, столь мне отвратного. Это папка node_modules с миллионом микро-файлов, хрупкие сборки и прочие фу. К счастью, появились докер-образы, но и они не без греха. Так, образ swagger-ui нельзя запустить в read-only файловой системе. Если у вас Кубернетис, придется выкручиваться.

  Усилия, направленные в русло Swagger, напоминают строительство пирамид. Масштабно, неэффективно и никому не нужно. Верный признак ущербности в том, что со всех сторон плодят еще более не нужные утилиты: убогий онлайн-редактор, CLI и, конечно, ОБЛАЧНУЮ учетную запись. Для утилиты, которая по JSON рисует HTML.

  Те, кто топят за Swagger, не понимают, как устроена документация в фирмах. Дело в том, что JSON не может нормально передать текст, он для этого не предназначен. Использовать для документации язык, в котором нет мульти-строк, средств акцента, ссылок и прочего — это прохладная идея.

  Нормальная документация — это семейство markdown- или asciidoc-файлов, объединенных в проект. Человек садится за редактор и пишет текст ручками. Расставляет акценты, ссылки, сноски. Это трудная работа, но только так получается достойная документация.

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

  Верный признак того, что Swagger это ущербная технология — им не пользуются самостоятельные компании. За всю карьеру я ни разу не видел, чтобы условный Гугл, Яндекс, Амазон и прочие показывали документацию через Swagger. В фирмах разный подход, но как правило это HTML с написанным человеком текстом. Вот несколько примеров:

  • Убер
  • Яндекс.Касса
  • Гугл.Фотки
  • Фейсбук
  • Твиттер

  Кто там еще? Вконтакт, Dropbox, банки (Тинек, Сбер)… ни одна значимая фирма не пользуется Сваггером. По моим меркам это был бы позор уровня студента.

  Стандартный шаблон Сваггера ужасен. Взгляните на официальное демо:

  

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

  Кроме убогого шаблона, Swagger предлагает утилиту для генерации кода приложения. Давайте честно: кто захочет строить проект на базе кодогенерации, написанной неизвестно кем? Этот код однозначно уйдет в урну. Конечно, генерация пригодится студентам для курсовой работы по предмету “введение в веб-разработку”, но и только.

  В общем, прекратите страдать фигней. Хотите нормальную документацию — поднимайте проект на Asciidoc, Wiki, GitBook, что угодно. Это трудно и требует навыков выражать свои мысли понятно. Может, пока апиха в разработке и меняется каждые два дня, нет смысла писать документацию. Но не вываливайте на клиентов интерфейс Сваггера. В нем отчетливо слышна машинная природа, и по всем признакам ясно, что эта страница не для людей.

• Dictionary-like Specs in Clojure

  May 29, 2020 programming, clojure

  TLDR: this post is a copy of readme file from the GitHub repo.

  Maps are quite common in Clojure, and thus s/keys specs too. Here is a common example:

  (s/def :profile/url    string?)
  (s/def :profile/rating int?)
  (s/def ::profile
    (s/keys :req-un [:profile/url
                     :profile/rating]))
  
  (s/def :user/name    string?)
  (s/def :user/age     int?)
  (s/def :user/profile ::profile)
  (s/def ::user
    (s/keys :req-un [:user/name
                     :user/age
                     :user/profile]))
  

  What’s wrong with it? Namely:

  • each key requires its own spec, which is verbose;
  • keys without a namespace still need it to declare a spec;
  • for the top level map you use the current namespace, but for children you have to specify it manually, which leads to spec overriding (not only you have declared :user/name);
  • keys are only keywords which is fine in 99%, but still;
  • there is no a strict version of s/keys which fails when extra keys were passed. Doing it manually looks messy.

  Now imagine if it would have been like this:

  (s/def ::user
    {:name string?
     :age int?
     :profile {:url? string?
               :rating int?}})
  

  or this (full keys):

  (s/def ::user
    #:user{:name string?
           :age int?
           :profile #:profile{:url? string?
                              :rating int?}})
  

  This library is it to fix everything said above. Add it:

  ;; deps
  [spec-dict "0.1.0"]
  
  (require '[spec-dict :refer [dict dict*]])
  

  Read more →

← Страница 6 из 53 →