• Рассказ о Емаксе

  Jun 11, 2016 emacs

  В прошлый четверг я рассказывал аудитории Хекслета про Емакс. Представляю читателям блога скомпилированную версию выступления. Рассказ пересекается с прошлой заметкой о Емаксе.

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

  

  Кадр из фильма Трон: наследие. Хакер взламывает кого-то при помощи Емакса. Ему помогают запущенный тетрис и игра-головоломка о перестановке пирамиды.

  Содержание

  • Историческая часть
  • Отличие от Вима
  • Философия Емакса
  • Недостатки. Когда не следует использовать Емакс
  • Достоинства
  • Как я переходил на Емакс. Трудности, мотивация
  • Установка
  • Основные положения
  • Конфигурирование
  • Коротко о пакетах
  • Сборки, форки
  • Для чего я использую Емакс
  • Ресурсы

  Историческая часть

  Емакс – это старенький текстовый редактор. Ричард Столлман начал работать над ним примерно 40 лет назад. Задумайтесь, как это много – больше, чем средний возраст популярных ресурсов. Емакс – одна из самых старых программ в айти-индустрии и все еще остается в строю.

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

  В Емаксе используется собственный диалект Лиспа, называемый Elisp (не путать с EMACS Lisp – это совсем другой диалект). Столлман отверг Common Lisp как излишне усложненный диалект, а Scheme – как недостаточно мощный. Так появилась своя реализация.

  Технически Elisp имеет серьезные ограничения – никакой многопоточности, нет хвостовой рекурсии, трудности с замыканиями. Производительность его очень невысока, примерно как Питон или Руби старых версий. Однако, даже при всех недостатках языка в нем можно творить потрясные вещи – редактировать код, управлять процессами, читать новости, RSS, играть в игры и так далее.

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

  Емакс обязан успехом исключительно Лиспу. Многие пакеты были написаны 10-20 лет назад, но по-прежнему разрабатываются, проходят рефакторинг.

  Подобно Лиспу, у Емакса есть форки и ответвления. Так, в девяностых годах обанкротилась компания Lucid, программисты которой использовали Емакс. Они взрастили внутри компании независимую версию редактора. Случилось так, что разработчики не договорились о правах и лицензиях. Так появился XEmacs – своего рода улучшенный Емакс. О форках я расскажу ниже.

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

  Отличие от Вима

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

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

  В Емаксе нет режимов из коробки, поэтому комбинации нуждаются в дополнительных клавишах (Комманд и Мета), чтобы различать ввод текста и команды. Это делает комбинации не такими быстрыми в наборе.

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

  Субъективно, Емакс пребывает в более вменяемом состоянии, чем Вим. В сообществе последнего сильны настроения в духе “взять все и переписать”. В Емаксе такого нет. Существуют Емакс-пакеты, которые очень точно воспроизводят принципы работы Вима – режимы, комбинации, исполнение Вим-скриптов.

  Философия Емакса

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

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

  Недостатки. Когда не следует использовать Емакс

  Емакс не идеален. Вот в каких случаях я не рекомендую его использовать.

  • Вам нужен редактор для разовых нужд, в основном копи-пасты. В этом случае прекрасно подойдет Саблайм.

  • Вы пишете на языке-платформе, неотделимой от ИДЕ. Например, C# или Java. Пытаться доработать любой другой редактор бессмысленно.

  • Порог входа выше, чем у стандартных редакторов.

  • Для комфортной работы редактор нужно настроить. Настройка может длиться годами. Главное – не увлекаться.

  Достоинства

  • Работает в разной степени со всеми известными языками и технологиями.

  • Очень гибкая система обработки текста

  • Мощная поддержка процессов. Простота интеграции с любым системным процессом или утилитой, например, git, docker, psql, grep, ls и т.д.

  • Конфигурирование всего и вся

  • Встроенный терминал, ssh-клиент, почтовик, браузер и масса других утилит

  • Золотые хиты детства – змейка, тетрис! M-x snake и M-x tetris

  • Единообразие. Каждый буфер, неважно, файл это или список процессов, подчиняется основным правилам навигации и поиска. Например, вы выполнили поиск в файле, открылся новый буфер с результатами. Теперь вы можете искать в буфере результатов, словно в файле! В любом буфере, неважно, файл это или что-то другое, можно настроить правила подсветки строк. Везде одинаковая навигация, копирование и вставка. Это дико удобно. Напротив, в стандартных ИДЕ каждое окно живет по своим особым правилам.

  Как я переходил на Емакс. Трудности, мотивация

  Я работаю в Емаксе третий год. Расскажу, как как пришел в него и с какими трудностями столкнулся.

  

  Мой Емакс сегодня. По клику большая версия. Слева – дерево файлов, посередине – эта статья в процессе подготовки, справа – код на Схеме.

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

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

  В случае с Саблаймом выяснилось, что для комфортной работы достаточно 5-6 модулей для нескольких языков, интеграции с SVN и Git. Саблайм я до сих пор считаю программой высочайшего уровня и рекомендую как легкую замену ИДЕ.

  Но вот что беспокоило – все авторитетные для меня инженеры работали либо в Виме, либо в Емаксе. Причем вообще без вариантов (чаще – в Емаксе, но не суть). Это легко выяснить из интервью, статей, или просто посмотреть dotfiles на Гитхабе. Так, Емаксом пользуются Гвидо ван Россум (создатель Питона), Джо Армстронг (Эрланга) , Линус Торвальдс (линукса и Гита), Тед Дзюба (предприниматель из Долины). Армин Ронахер, чей вклад в Питон неоценим, используем Вим.

  Полагаю, у названных людей есть деньги чтобы купить лицензии на нужные ИДЕ, но они этого не делают. Линус как-то сказал, что готов купить любую ИДЕ, но его пальцы уже нельзя переучить после 20 лет Емакса. Гвидо положительно отзывался о Пайчарме, но добавил, что опять пришел к связке Емакс + pdb (самый базовый отладчик).

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

  Во-вторых, ИДЕ – это прежде всего бизнес. Адепты Джет-Брейнс расскажут, что без ИДЕ код пишется плохо, нарушаются бизнес-процессы и страдает бизнес. Их позиция ясна.

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

  Наконец, бывают особо критичные случаи, когда без ИДЕ человек оказывается совершенно проф-непригоден. Один коллега в проекте впал в амнезию, когда Пайчарм не смог открыть по клику исходники одного хитрого модуля. Другие не мыслят себя без подсветки и автодополнения. Это полезные вещи, но плохо, когда они становятся зависимостью.

  Я решил переходить на Вим или Емакс, чтобы повысить уровень.

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

  Напротив, с Емаксом пошло проще. Возможно, благодаря cua-mode. Это такой режим для новичков, когда основные команды вроде копирования и вставки работают как в классический редакторах. Долгое время я, за годы привыкший к Ctrl-X/C/V, использовал эти же комбинации. Потом перешел на общепринятые в Емаксе.

  Установка

  • Для Мака. Либо скачать графическую версию, либо поставить консольную версию из brew, предварительно обновив формулы.

  • Для линукса. Из пакетов: apt-get, yum.

  • Для Винды. Скачать бинарники. На винде осложнения в том, что Емакс нуждается в стандартных Юникс-утилитах ps, grep, find. Понадобится какой-нибудь Cygwin или аналог.

  Пакет для интеграции с Гитом под названием magit требует Емакс не ниже 24.4. Это не очень хорошо, так как в старых Убунтах в пакетах указан 24.3. Приходится заморачиваться со сторонними репозиториями. Для начинающих это неважно.

  Основные положения

  Главная смысловая единица в Емаксе – буфер. Это место, где какой-то текст. Буфер может быть связан с файлом. Буфер произошел от принципа работы с данными на лентах. Писать каждое изменения на ленту – страшно медленно. Поэтому считывали данные в память, обрабатывали и записывали поверх.

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

  В момент старта Емакса появляются три стандартных буфера. Это приветствие со ссылками на документацию. Потом буфер сообщений, своего рода лог. И буфер scratch для копипасты.

  Этот последний буфер особый – в нем можно выполнить любой код на Лиспе и сразу проверить, какой эффект имеет этот код.

  В Емаксе используют особые сокращения для клавиш. C (командная клавиша) означает Контрол, M (мета-клавиша) означает Альт. Дефис означает одновременное нажатие. Важно помнить, что 40 лет назад клавиатуры были другие, и клавиша Command располагалась рядом с пробелом, как сегодня на Маке. Так что Столлман не виноват!

  

  Клавиатура тех дней. Обратите внимание на расположение служебных клавиш.

  Примеры:

  • C-x b – нажать вместе Контрол и x, потом b – сменить буфер.
  • C-x C-f – нажать одновременно Контрол и x, потом одновременно Контрол и f – открыть файл.
  • M-g g – нажать вместе Альт и g, потом еще раз g – переход на нужную строку текущего буфера (система спросит номер).

  Нажатие C-g прерывает ввод текущей команды.

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

  Не нужно стараться запомнить все сразу, это придет постепенно.

  Чтобы эффективно работать в Емаксе, желательно освоить две вещи, о которых упоминал Кирилл в вебинаре по Виму. Первое – перенести клавишу Контрол на Капс. Это необходимо и вообще не обсуждается. Если нажимать ее в стандартном положении, рука отвалится из-за сильного напряжения в кисти.

  Как сделать это в Маке, я уже писал раньше.

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

  

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

  В Емаксе нет табов для открытых файлов. Это шокирует тех, кто только начал с ним работать. Дело в том, что табы не нужны. Когда вы долго работаете, сами по себе накапливаются открытые буферы (как мы уже знаем, в Емаксе это не только файлы). Я никогда не выключаю ноут, а только погружаю в сон. К концу второго месяца в Емаксе примерно 400 буферов. Представьте, что для каждого был бы таб. Я бы просто ничего не видел из-за них.

  Кстати, любителям ИДЕ посвящается – откройте 400 файлов и проверьте, как поведет себя система. У моего коллеги ноут грелся так, что обжигало руку. А Емакс потребляет 100 Мб памяти и 10% процессора.

  Удивительно, но основные комбинации для перемещения по тексту работают много где за пределами Емакса – например, в Хроме, почтовом агенте Мака. В Баше по умолчанию включена раскладка Емакса.

  Конфигурирование

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

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

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

  При старте Емакс ищет файл ~/.emacs . Затем – ~/.emacs.d/init.el. .el – расширение файлов на Elisp. Обратите внимание, что первый файл не содержит расширения в имени.

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

  Вот как ставится моя конфигурация:

  # Скачать репозиторий куда-то себе
  git clone https://github.com/igrishaev/dotfiles.git ~/somewhere
  
  # скопировать папку .emacs.d в домашнюю директорию
  cp -r ~/somewhere/.emacs.d ~/
  
  # перейти внутрь
  cd ~/.emacs.d
  
  # поставить утилиту Cask
  make install-cask
  
  # установить пакеты, перечисленные в cask-файле.
  # переменную EMACS нужно задать, если у вас в системе несколько емаксов
  EMACS=/path/to/bin/emacs make install-packages
  

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

  Коротко о пакетах

  Для емакса написаны тысячи пакетов, некоторые из которых тянут на полноценные приложения, исполняемые внутри Лисп-машины.

  Пакеты хостятся в репозиториях, у которых следующие имена – GNU, Melpa, Marmelade. Как правило, в конфиге указывают их все. Стандартный менеджер пакетов из поставки Емакса может устанавливать из репозиториев, но не умеет разруливать зависимости. Поэтому используют либо пакет el-get, либо утилиту Cask, как в моем случае. Это утилита на Питоне для сопровождения проектов на ELisp. В ней много всего, в том числе установка зависимостей. Она переопределяет стандартный менеджер пакетов. Вы пользуетесь как будто стандартным.

  Основные пакеты для Емакса без привязки к конкретным языкам:

  • magit – Интеграция с Гитом
  • nav – Панель файловой навигации
  • auto-complete – Автодополнение из разных источников
  • flycheck – проверка синтаксиса для разных языков. Обычно нужен сабмодуль для конкретного языка
  • markdown-mode – Маркдаун
  • nyan-mode – Нян-кот в твоем Емаксе!
  • simpleclip – Облегчает работу с системным буфером обмена
  • json-mode – Подсветка и валидация джейсона

  Сборки, форки

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

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

  Проект Эрго-Емакс ставит цель создать оптимальную клавиатурную раскладку, где наиболее востребованные функции размещены в нужных местах. Авторы полагают, раскладка повысит производительность и снизит усталость рук. На этом же сайте тусит сообщество, есть сборник рецептов, снипетов и все такое.

  Наконец, существует Spacemacs – попытка взять лучшее из двух миров. Соединить механику Вима с мощью платформы Емакса. Простыми словами, это громадный конфиг с пакетами для имитации Вима.

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

  Судя по репозиторию проекта, работа проделана внушительная, но я не проникся. Да и вообще, идея смешения мне не нравится. Она наивна по своей природе. Вот есть Руби и Питон, у них достоинства и недостатки. Давайте возьмем от каждого только достоинства и получим идеальный язык! Или давайте Мерседес с Ауди смешаем. Или Виндуз с Маком. Это не работает.

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

  Для чего я использую Емакс

  В емаксе можно делать почти все, что угодно, главное – знать меру и не стать упоротым фанатом.

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

  

  В Емаксе на все найдется команда.

  Я использую Емакс для следующего:

  • Программирую в Емаксе на Питоне, Кложе, Джаваскрипте, Ракете, Коммон-Лиспе. В нем же ковыряю Хаскелл и Гоу. Под каждый язык – пакет или два для поддержки. Питон, надо сказать, поддерживается очень хорошо. Трудность скорее в том, какие пакеты для него выбрать из множества. Для Лиспов емакс – родная среда.

  • Редактирую структурированные файлы: Маркдаун, Json, Yaml, ini, html, css. Где не хватает коробочных средств, тоже ставлю пакеты.

  • Работаю с системами контроля версий, почти не вылезая в терминал. Смотрю диффы, блейм, логи. Делаю и мерджу ветки в Емаксе.

  • Изредка читаю онлайн-документацию во встроенном браузере EWW. Это полезно, когда не хочешь постоянно переключаться из браузера в редактор. Делишь экран пополам, в слева страничка с доками,справа код – удобно. Емакс умеет проматывать соседний буфер, не переключаясь из основного.

  • Планирую делать резолв конфликтов при мердже веток встроенным пакетом emerge. Пока что использую kdiff3.

  • Некоторое время, когда в команде пользовались джаббером, сидел из Емакса. Тоже удобно, особенно когда обсуждаешь код.

  • Пытался пользоваться почтой с помощью встроенного пакета Gnus – не пошло в силу однопоточности Лисп-машины. На проверку почты уходит до 10 секунд (у меня куча папок), за это время ничего нельзя сделать.

  • Запускаю и контролирую процессы с помощью пакета prodigy. Был проект на микросервисной архитектуре. Чтобы завести его, нужны были штук 6 фейковых рест-сервисов. Эти заглушки было удобно поднимать и гасить прямо в Емаксе.

  • Порой пользуюсь встроенным терминалом, когда лень открывать основной.

  • Иногда делаю презентации в емаксе: пишу структурированный файл в разметке ORG, который экспортируется в HTML + reveal.js. Например, вот слайды для доклада о юнит-тестах: исходник, результат.

  • Рисую ascii-таблицы в org-mode. Параметры таблицы задаются командой. Таблица ведет себя как лист в Экселе – можно перемещаться по ячейкам, добавлять и удалять строки и столбцы, сортировать, вставлять формулы. Таблица автоматом растягивается под данные в ячейках. И при этом копируется как текст. Очень удобно для документации. Руками вы ее будете рисовать час.

  Пример по шагам:

  • M-x org-table-create – система спрашивает размер таблицы, ввожу число строк и колонок, получаю

  |   |   |   |   |   |
  |---+---+---+---+---|
  |   |   |   |   |   |
  

  • Ввожу данные:

  |Python   |Ruby   |Perl   |Java   |Common Lisp   |
  |---+---+---+---+---|
  |1   |2   |  3 | 4  |5   |
  

  • Нужен еще ряд? Набираю M-x org-table-insert-row:

  |Python   |Ruby   |Perl   |Java   |Common Lisp   |
  |---+---+---+---+---|
  |1   |2   |  3 | 4  |5   |
  |  Some long test  | 42   | foo   | bar     |    Another long text|
  

  • Все съехало, некрасиво. Набираю M-x org-table-align:

  | Python         | Ruby | Perl | Java | Common Lisp       |
  |----------------+------+------+------+-------------------|
  | 1              |    2 | 3    | 4    | 5                 |
  | Some long test |   42 | foo  | bar  | Another long text |
  

  Тадам. И это даже не верхушка айсберга, а самая мелочь из того, что можно делать в org-mode.

  • Возвращаюсь к нашему списку. Веду GDT – учет личных и рабочих дел. Давно хочу написать на эту тему в блог, но пока что отдельным абзацем.

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

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

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

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

  Не могу расшарить свой файл, поскольку в нем немало приватных данных, но примерно это выглядит так:

  ** DONE Sign Contract
  CLOSED: [2016-03-30 Wed 12:36] SCHEDULED: <2016-03-30 Wed>
  - CLOSING NOTE [2016-03-30 Wed 12:36] \\
    signed
  ** TODO Get Reports
  DEADLINE: <2016-06-20 Mon +3m>
  - CLOSING NOTE [2016-03-28 Mon 10:52] \\
    got and paid
  :PROPERTIES:
  :LAST_REPEAT: [2016-03-28 Mon 10:52]
  :END:
  ** DONE IP USN
  CLOSED: [2016-04-25 Mon 10:00] DEADLINE: <2016-04-18 Mon>
  - CLOSING NOTE [2016-04-25 Mon 10:00] \\
    done
  ** TODO Visit some secret place
  DEADLINE: <2016-03-31 Thu>
  ** DONE Sber get new card
  CLOSED: [2016-04-06 Wed 15:42] SCHEDULED: <2016-04-04 Mon>
  - CLOSING NOTE [2016-04-06 Wed 15:42] \\
    got it!
  ** DONE Add bank account to Paypal
  CLOSED: [2016-03-25 Fri 15:39] SCHEDULED: <2016-03-24 Thu>
  - CLOSING NOTE [2016-03-25 Fri 15:39] \\
    added
  ** TODO Sber Deposit
  SCHEDULED: <2017-02-06 Mon>
  ** DONE Phone to Office
  SCHEDULED: <2016-03-01 Tue>
  - CLOSING NOTE [2016-03-01 Tue 15:02] \\
    phoned
  - CLOSING NOTE [2016-02-24 Wed 22:52] \\
    phoned
  

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

  На временной линии задачи выглядят так:

  Friday     10 June 2016
  Saturday   11 June 2016
    Scheduled:  TODO Practice Typing                                    :learning:
    Scheduled:  TODO Listen english                                     :learning:
    Scheduled:  TODO Do some secret stuff
    Scheduled:  TODO Pay for one thing
  Sunday     12 June 2016
  Monday     13 June 2016 W24
  Tuesday    14 June 2016
    Scheduled:  TODO Another important task
    Scheduled:  TODO Listen english                                     :learning:
    Deadline:   TODO Publish announce
  

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

  Ресурсы

  • Официальный туториал
  • Подробнейшая вики
  • Блог китаянки, у которой конфиг Емакса длиной с Китайскую Стену
  • Довольно свежая книжка
  • Серия статей Алекса Отта
  • Раздел на Хабрахабре

• Сегодня рассказываю про Емакс

  Jun 9, 2016 hexlet, slack, emacs

  Сегодня, в четверг 9 июня, в 17:00 по Москве я расскажу про Емакс в Слак-канале образовательного проекта Хекслет.

  Затрону следующие темы:

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

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

  Заходите, будет интересно.

• Доклады с шестой встречи глубокого рефакторинга

  Jun 5, 2016 programming, meetup, deep-refactoring

  Провели шестую встречу!

  

  Юра Хрусталев рассказал, как мы в проекте внедряли Ансибл:

  Слайды

  Миша Вьюков дал советы как продвигать продукты и сообщества в социальных сетях.

  Слайды

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

• Размышления о Питоне

  May 28, 2016 programming, python

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

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

  Итак, преимущества:

  Питон – коммерчески успешный язык

  Приятно осознавать, что Питон используют не только в академических и любительских кругах, но и в бизнесе. Компании доверяют ему деньги. Много фирм используют Питон – Гугл, Пейпал, Инстаграм, НАСА.

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

  Питон – очень легкий язык

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

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

  Питон сильно приблизил програмирование к людям

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

  Появились специальные проекты и книги, например, Python For Engineers, A Primer on Scientific Programming with Python и другие. На работе я видел скрипты на Питоне, написанные людьми, у которых все знание программирования сводилось к школьной программе. Но скрипты работали, автоматизировали труд, а значит, экономили время и деньги.

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

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

  Питон – легкий способ попасть в промышленную разработку

  Напоминает тезис о том, как попасть в шоу-бизнес через постель. Если вы занимаетесь чем-то около-айтишным, например, администрированием, сетями, поддержкой, 1С или старыми языками вроде Дельфи, то Питон – счастливый билет. Из пунктов выше мы выяснили, это что легкий язык промышленного уровня. Возможно, он станет той подножкой уходящего поезда, на которую успеете вскочить, прежде чем расхочется что-то менять и превозмогать.

  Абзацем выше я фактически рассказал свою историю. До знакомства с Питоном я занимался сайтами на CMS, Дельфями и 1С. Конечно, и с этим можно найти работу. Однако, именно за счет Питона я продвинулся на старой работе, потом переехал в другой город за 6000 км и попал в Датаарт. Позже нашел удаленку в Европе.

  Питон поддерживает все парадигмы программирования

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

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

  Для полноценного ФП не хватает полноценных лямбд и неизменяемых коллекций. В тройке функцию reduce запрятали в недра стандартной библиотеки.

  Ленивые вычисления, декораторы и перегрузка операторов открывают пространство для интересных маневров. Питон мимикрирует под самые разные языки, например:

  • Fake Lisp – псевдо-Лисп, забавная попытка писать питонячий код S-выражениями.

  • Hask – закос под синтаксис Хаскела. Питонщикам очень полезно посмотреть, на какие ухищрения пошел автор, чтобы добиться столь точного сходства.

  • fn.py – функциональные ништяки из Скалы. Аналогично, очень интересно взглянуть, что под капотом.

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

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

  Закончим с преимуществами. Питон не идеален. Вижу следующие недостатки:

  Мелкие огрехи с синтаксисом

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

  Формирование кортежа. Может, кто-то не знает, что круглые скобки вокруг кортежа носят символический характер. На самом деле он определяется запятой. Возникает проблема кортежа с одним элементом:

  foo = 1, 2  # it's tuple
  bar = 1,    # it's tuple
  baz = 1     # it's int!
  

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

  Следующий пример. Две строки подряд без запятой сливаются в одну. Это значит, кортеж

  statuses = (
      'success',
      'error'
      'timeout',
      'denied',
  )
  

  вырождается в

  ('success', 'errortimeout', 'denied')
  

  потому что нет запятой после 'error'. Проверка 'error' in statuses вернет False, что есть прямое нарушение бизнес-логики.

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

  Главенство ООП

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

  Вы когда-нибудь дебажили Джанго? Я да. Это был кастомный бекенд авторизации. Дебаг длился больше часа и напоминал БСДМ-сессию.

  Объекты Request, Response, User, Session устраивают свальный грех. Устанавливают ссылки друга несколько раз. Лезут в кэш непонятно зачем.

  Очень странные требования к бекенду авторизации. Метод .get_user() отдает объект пользователя. Потом этот пользователь где-то теряется, на него не остается ссылки. Система запрашивает метод .get_user_by_id(). Я ведь уже отдал пользователя, дубина! Значит, нужно или снова лезть в базу или сеть, либо хранить в классе словарик, что не тред-сейф.

  Почему-то в Кложе с ее неизменяемыми коллекциями мне ни разу не приходилось лазить в сессию, реквест или респонс задним числом и что-то там править. Изменения в коллекции прокидываются только вперед.

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

  Это наносит урон функциональному программированию. Распространяется заблуждение, что ФП – это мапы и лямбды.

  В Питон было бы неплохо добавить что-то, что поощряло отказ от состояния. Например, неизменяемый словарь, больше функций для работы с коллекциями.

  Впрочем, это был бы уже совсем другой язык.

  Низкая скорость

  Еще год назад говорил, что это не недостаток вовсе. Память дешевая, хостинг недорогой и прочие отмазки. Сегодня считаю такой ответ уделом дилетанта.

  Скорость исполнения важна. Представьте, весь ваш софт на компе написан на Питоне. Он бы работал раз в 20-30 медленней, об играх и фотошопах пришлось забыть. Это не просто шаг назад, а откат на несколько поколений.

  Недавно мне нужно было парсить лог Nginx, Гугл выдал утилиту ngxtop. Я не посмотрел, на чем она написана, поставил из пакетов. Лог в несколько гигабайт она обрабатывала час. Оказался Питон. Утилита на Си распарсила за 5 минут. Неверный выбор стоил потери времени.

  Питон долго брал скоростью разработки. Да, работает медленней, зато выкатим раньше, чем конкурент на Джаве. И вот появляются языки, которые совмещают скорость кода и скорость разработки. Если писать на X и Y по времени примерно одинаково, а Y исполняется быстрей в 5 раз, зачем брать X?

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

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

  ГИЛ

  На упрек в адрес ГИЛа отвечают в духе “он вам не нужен”, “используй процессы”. Так говорил и я до тех пор, пока не познал, как работает многопоточность в функциональных языках.

  Мы запускаем веб-приложение на Питоне под uWSGI так. Стартует мастер-процесс. Он управляет воркерами – процессами, в каждом из которых веб-приложение. Единовременно запущены 16 Джанг, каждая из которых отвечает, когда другая занята.

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

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

  Распараллеливание на процессах лишает общего доступа к памяти, вынуждая использовать суррогаты вроде Memcache или Redis, в то время как самый эффективный кеш – общая память.

  Мастер-процессы вроде uWSGI и Green Unicorn – дополнительная прокладка в цепи, по которой проходит запрос. Лишний I/O, точка логирования и падения.

  Наконец, с ГИЛом нельзя ничего распараллелить, разве что запросы в сеть. Функциональные языки лишены этих недостатоков. Неизменяемость коллекций в Кложе, система каналов в Гоу позволяют рулить многопоточностью без страха отстрелить ногу. Это выкашивает целый пласт инфраструктуры: костыли в виде очередей, воркеров и крон-скриптов. И дополнительные системы, чтобы все это поддерживать.

  Трудности распространения

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

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

  Чтобы написал скрипт, запустил сборку и получил архив с исполняемым файлом. Почему функциональные языки это умеют, а Питон – нет?

  Кложа выдает uberjar. Собираю его на Маке, загружаю на хостинг, где кроме Джавы ничего нет – работает без проблем. Хаскель компилируется в бинарь. Ракет, Раст – тоже. Коммон Лисп, которому тридцать лет, Карл, делает дамп Лисп-машины в бинарный файл!

  Фактически, чтобы запустить веб-приложение на Питоне, нужно иметь примерно 10.000 *.py-файлов. Если не будет одного, система не заведется. Изолировать это многообразие можно Докером, но здесь мы кривим душой.

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

  Заключение

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

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

• Комментарии к статье о Лиспе

  May 24, 2016 programming, pfp, lisp

  Прочитал статью Лисп – философия разработки от 2010 года. Решил законспектировать заключительынй раздел с выводами – очень уж понравились.

  Если рассмотреть каждый отдельный язык, то, как правило, можно найти его объединяющую идею. […] Для Common Lisp объединяющей идеей на данный момент является как раз расширяемость.

  Не могу с точностью судить о CL, но расширяемость в Кложе(скрипте) сделана на высоте. Пожалуй, это единственная экосистема, где любой разработчик может внести свой контриб в чужой тип или протокол без обезьяних патчей, как в Руби и Питоне. Напоминает перегрузку операторов, но в масштабах всей Лисп-машины. Это надо просто попробовать.

  В то же время у нее [Джавы] есть и сильная сторона, а именно пронизывающая весь язык модель семантической расширяемости через интерфейсы. Так что в общем-то не удивительно, что язык Clojure появился именно на Java-платформе…

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

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

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

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

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

  В этом смысле показателен пример Python, известного своим девизом «Батарейки в комплекте», который подразумевает наличие в стандартной библиотеке (почти) всего, что нужно для разработки. […] Обратная сторона медали тут отмечена в другой цитате: «Пакет, который попадает в стандартную библиотеку, стоит одной ногой в могиле»

  Меткое замечание. Не случайно автор библиотеки requests, ставшей де-факто для HTTP-запросов, заключил с Гвидо неформальное соглашение. Согласно ему, requests НЕ включается в стандартную библиотеку (чего так хотелось Гвидо), но рекомендуется к использованию на страницах официальной документации. Хитрый мужик! Знал, чем чревато.

  В Common Lisp для этого [построения расширяемых систем] используются следующие технологии: макросы для создания мини-языков для декларативного описания систем, дистрибутивов (в отличие от использования для этих целей внешних языков, таких как XML)…

  Да, достоинство Лиспов – всегда можно написать доменный язык под любую задачу благодаря системе макросов. В Лиспе построение XML, HTML, SQL вырождается в декларативное дерево с одноименными узлами (cdata, div, select).

  Кому интересно, загляните и в другие статьи Практики функционального программирования. Актуальность они не потеряли и еще долго ее сохранят.

• Полезные практики

  May 16, 2016 programming, tips

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

  Первое. Указываю тип переменной в имени

  Задаю переменным имена по правилу <entity>_<type>. Открыв код месячной давности, сразу вижу, где и какие типы. Даже самая коммерческая ИДЕ порой не может понять, с чем имеет дело. А с моим правилом именования работать одно удовольствие.

  Применяю его не слепо, а выборочно. Скалярным типам, например, строкам и числам, не указываю тип, если он ясен из контекста. Выражения name_str = 'test' или age_int = 42 избыточны, поскольку имя и возраст вряд ли могут быть чем-то отличным от строки и целого.

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

  permisson = response['data']['item']['permisson']
  # wtf is permisson?
  

  А ведь достаточно назвать переменную perm_int, и все станет ясно – это же числовой код!

  Указывать тип стоит везде, где кроется неожиданность. Айдишка объекта может быть передана строкой, поэтому назову переменную user_id_str, а дальше преобразую в инт. Поле может называться item, а внутри – гуид сущности, а не словарь. И так далее.

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

  Примеры? Хотели список, чтобы изменять элементы, а пришел кортеж. Итерация по множеству проходит в разном порядке. Хеш от списка вызывает исключение. Пройтись по итератору можно только один раз. И так далее.

  Если работаю со словарем с данными о пользователе, называю user_dict. Список пользователей – user_list, множество – ..._set и так далее, принцип, думаю, понятен. Для кортежей и итераторов окончания tupl, iter.

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

  Смотрит коллега в монитор и не понимает, отчего Pytest падает и выводит следующее:

  assert [1L, 2L, 3L] == [1, 2, 3]
  >>> long trace...
  

  Потому что справа список, а слева – квери-сет. Он выводится как список, но не равен ему.

  Отдельным абзацем замечу, что не приемлю лексемы data в именах переменных. user_data, response_data – ужасные имена. Любая переменная, даже ноль, уже несет данные. Понятней не стало. Это словарь, список или что?

  Добавлять на конце s тоже нет смысла. Коллекция подразумевает больше одного элемента. Если не указан тип, я опять в беде: users – это сет, словарь или кортеж? Можно ли брать слайс? Подставить в ключ словаря?

  Падение на None (он же nil, null, undefined, etc) – особая история. В программировании до сих пор нет понимания, что делать с пустыми типами. Чтобы обезопасить код, полезно явно задать имя вроде user_or_none или, для краткости, user_none. Это вынудит программиста выполнить проверку перед тем, как что-то делать с данными.

  Второе. Избегаю циклов

  О вреде циклов я уже писал, и не раз. Если коротко, то:

  • ручное накопление списка или словаря чревато багами
  • со временем цикл разрастается, обрастает вложенными for, if
  • из-за отступов плохо видно бизнес-логику
  • цикл поощрает плохую практику – впендюрить continue вместо того, чтобы отфильтровать данные до входа в цикл
  • цикл плохо поддается рефакторингу, поскольку затягивает контекст – коллекцию-результат, локальные переменные, вложенные циклы.

  Решение – использовать функции высшего порядка map, filter. Я отрицательно отношусь к трехэтажным лямбдам. Использую обычные функции, объявленные через def/func/defn.

  def get_item_list(user_id):
  
      def get_item(product):
          ...
  
  item_qs = models.Item.objects.filter(user_id=user_id)
  return map(get_item, item_qs)
  

  Я просто объявляю функцию в том месте, где она нужна, и не парюсь за производительность или дзен. Код становится на рельсы: коллекция –> фильтрация –> действие –> другая коллекция –> свертка. Появляется ощущение структуры программы, приходит упорядоченность.

  Добавить новое бизнес-правило в такой код очень легко. Это будет или еще один фильтр, или изменится действие над элементом. В любом случае не съедет весь код, как в примере ниже:

  items = users.get_items()
  res = []
  for item in items:
      if items.color = 'red':
          continue
      res.append(item.id)
  

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

  
  res = []
  users = get_all_users()
  for users in users:
      items = users.get_items()
      for item in items:
          if items.color = 'red':
              continue
          res.append(item.id)
  

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

  Простое правило “дейтвие, коллекция, мап, свертка” работает без нареканий и легко адаптируется под новые требования.

  Третье. Отлавливаю ошибки как можно раньше

  Почти любая операция небезопасна и может кинуть исключение. Проблема в том, что одновременно писать бизнес-логику и следить за ошибками трудно. Каждая ошибка – это блок try-catch и запись в лог, за которыми не видно главную мысль.

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

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

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

  Заворачивать весь код в try-catch – не выход. Поможет возврат пары, как в Golang. С небольшим отличием – не (ok, result_or_error), как принято в последнем, а (err_or_null, result_or_null), как в Node.js. Второй вариант логическии правильней.

  Заворачиваю функцию в простой декоратор:

  def err_result(f):
      def wrapper(*args, **kwargs):
          try:
              return None, f(*args, **kwargs)
          except Exception as e:
              return e, None
      return wrapper
  

  Или вызываю just-in-place:

  def some_func(foo):
      ...
  
  err, result = err_result(some_func)(42)
  

  Вариант с мапом. Функция-обработчик раскладывает пару на составные части с помощью деструктивного синтаксиса:

  
  item_queryset = models.Item.filter(...)
  
  def process_item(item):
      ...
  
  pair_list = map(err_result(process_item), item_queryset)
  
  def process_pair((err, result)):
      if result:
          # positive brunch
      if err:
          # negative brunch
  
  map(process_pair, pair_list)
  

  Или отделяю котлеты от мух: разбиваю список пар на плоские списки ошибок и результатов. Отдельно логирую ошибки. Передаю результаты на дальнейшую обработку. Так в коде появляется порядок.

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

  Заключение

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

  Повторюсь, описанные принципы не идеальны, но с ними возникает чувство порядка. Словно код становится на рельсы, а вместе с ним и процесс. Возникает линейность, предсказуемость действий.

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

  Допускаю, что прочту этот пост через 2 года и подумаю, каким чудаком я был, но пока что так.

• Полезный сервис Requestb.in

  May 8, 2016 http, webdev

  Наткнулся на полезный сервис Request Bin.

  Частенько бывает, какой-нибудь Твиттер, Фейсбук или Пейпал пингуют ваше приложение. Шлют нотификации о платежах, событиях. Проблема, что приложение еще не на сервере, а интегрироваться как-то нужно.

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

  Поможет Request Bin. Идея сервиса гениальна. Вам дают уникальный урл, например, http://requestb.in/1j2bq6r1. На все обращения сервис отвечает 200 ОК, а сам записывает входящий запрос в память. По адресу http://requestb.in/1j2bq6r1?inspect сервис покажет последние 20 запросов: дату, метод, заголовки, параметры.

  Полученный урл указываем в настройках стороннего сервиса. Выполняем операции, смотрим, какие запросы пошли.

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

  Request Bin поддерживает соединение по протоколу HTTPS, правда, с самоподписанным сертификатом. Это помогло при интеграции с Пейпалом. Последний требует, чтобы урл начинался с https://, но не проверяет сертификат.

  Сервису есть, что улучшить. Если в теле запроса был json, парсить и показывать красиво. Сейчас выводит как пришло – в одну строчку. Добавить экспорт запросов в любой формат. Показывать сырой запрос (т.н. raw HTTP).

• Доклады с пятой встречи любителей рефакторить

  May 2, 2016 programming, meetup, deep-refactoring

  Провели пятую встречу!

  Я рассказал про тесты с фикстурами:

  Слайды

  Михаил Хорпяков объяснил, какие вопросы задать работодателю на собеседовании:

  Слайды

  Напомню, сообщество тусит в группе Фейсбука. Скоро анонс шестой встречи. Принимаем заявки на доклады.

• Читаю интернет в Киндле

  May 1, 2016 kindle, book, reading, inet

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

  Раньше, найдя в сети большую интересную статью, терялся от незнания, что с ней делать. Читать сейчас – времени нет. Держать открытой вкладку? Уже 20 открыто, куда больше. Остается жать “Добавить в избранное” и забывать о статье навсегда.

  Статья в избранном – это закрытая вкладка. Энтропия и шум настолько сильны, что по факту к статье вы не вернетесь.

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

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

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

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

  Прекрасное расширение для Хрома и Лисы закачивает любую веб-страничку в Киндл. Удаляет весь мусор, красиво компонует текст. На экране читалки смотрится изумительно.

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

  С новым подходом я прочитал замечательную статью “Being A Developer After 40”. На очереди несколько постов из блога Гвидо Ван Россума.

• Про удаленную работу

  Apr 22, 2016 remote, work, ivan, sam

  

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

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

  Содержание

  • Введение
  • Общий порядок работы
  • Контракт, отпуск, увольнение
  • О слежке
  • Виды удаленки
  • О поиске удаленной работы
  • Общение
  • Английский
  • Деньги
  • Налоги
  • Как жить с удаленной работой
  • О прокрастинации
  • Другое

  Введение

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

  Собеседование стандартное. Кто такой, какие проекты, что умеешь. Просили спроектировать игру “Монополия”. Задавали вопросы на тему сети, пингов.

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

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

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

  При фриланс-биржи вроде ODesk и Upwork я не особо в теме, поэтому не буду о них говорить. В моем видении удаленная работа носит более высокий приоритет, чем фриланс.

  Общий порядок работы

  Я работаю 5 дней по 8 часов, 40 часов в неделю, 2 выходных, как в РФ. Переработок еще не было. Труд оплачивается по часам. Есть понятие рейта — N долларов в час. Проходит месяц, вы умножаете рейт на 8 и на число дней. Выставляете счет на полученную сумму.

  Обычно заказчик и работник находятся в разных часовых зонах. Оговаривают, каким будет временное пересечение. Например, 5 часов в течение суток. Если требуется постоянная связь на случай факапав, это оговаривается отдельно.

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

  Контракт, отпуск, увольнение

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

  Отпуск не оплачивается. Вы уходите на две недели – получаете зарплату в два раза меньше. Отдыхали месяц – зарплаты нет. Впрочем, отдых длиною в месяц в ай-ти – штука мифическая.

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

  Это краеугольный камень в удаленной работе – ты ничем не защищен. У заказчика не болит голова, если нужно избавиться от человека, в котором ошибся.

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

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

  О слежке

  В чате было много вопросов о том, следит ли за мной заказчик. И как контроллируется процесс. Конкретно в моем случае мне НЕ нужно устанавливать особое ПО, которое следит за десктопом и шлет скриншоты начальству. У нас Джира, в задачах выставлен примерный эстимейт, который предварительно обсуждаем всей командой. Взявшись за задачу, ты должен в него уложиться, либо объяснить, на что уйдет дополнительное время.

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

  Отработать 8 часов полностью нереально. Есть определенный КПД. По моим подсчетам, в плодотворный день удается поработать 6 часов. Чтобы сделать 8 полных часов, надо сидеть за компом 11 часов. Ноу лайф, словом. Максимум на день-два.

  Чем больше закачик доверяет личному общению взамен программы-шпиона, тем лучше. Я лично считаю, достаточно 5-минутного разговора, чтобы понять, работает человек или валяет дурака. А то, что он потратил час на блог или личный проект, роли не играет.

  Виды удаленки

  Я разделяю два вида удаленки – внутреннюю (в рамках текущей страны, для меня – России) и внешнюю – Европу, США, Сингапур и тд. Кратко опишу первый пункт, чтобы затем на него не отвлекаться.

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

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

  Гораздо интересней говорить на тему внешней удаленки. Здесь сразу куча всего.

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

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

  Ответственность. Удаленка мне кажется более высокой формой сотрудничества, потому что повышается ответственность. Дело в том, что много вещей приходится разруливать самостоятельно. Минус, эту ответственность нужно быть готовым принять. То есть теперь вы не только пишете код, но и занимаетесь предпринимательством, платите налоги, обо всем договариваетесь с заказчиком и много всего другого.

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

  Свобода в выборе. Удаленной работы сейчас много, и хороший сотрудник может выбирать, с кем работать. Например, вы отработали 5 лет на PHP, понимаете, что не растете, пора двигаться дальше, в но в городе вакансии только на Пых и 1с. Остается только переезд. Но если у вас семья, дети? Вы же не потащите из через всю страну только потому, что захотелось писать на Хаскеле?

  О поиске удаленной работы

  Где искать удаленку? Есть хороший сайт Remote OK – агрегатор удаленных вакансий.

  Они же попадаются на Stack Overflow с тегом remote.

  Вакансии неплохо ищутся на сайтах конкретных языков или технологий, например, для Питона это раздел Jobs на официальном сайте.

  На всех указанных выше ресурсах есть RSS-ленты, что облегчает трекинг.

  Есть рекрутинговые агенства, специализирующиеся на особых технологиях, например, Functional Works – подбор программистов на функциональных языках. Чтобы увидеть расширенную информацию на борде, надо зарегистрироваться. Сейчас там висят 3-4 удаленки. Из прямого общения с рекрутером можно вытянуть больше.

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

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

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

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

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

  Общение

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

  Как правило, удаленщик находится в другой часовй зоне, поэтому оговаривают, в какие часы сотрудник должен быть на связи. Наиболее благоприятный случай – когда зоны различаются на 2-3 часа, как Москва и Лондон, например. Люди, которые работают с США, испытывают трудности из-за слишком большой разницы во времени. У вас 18-00, а у них только утренний кофе. Постепенно ваш распорядок съезжает на ночное время, что плохо для здоровья и социальной составляющей.

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

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

  Английский

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

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

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

  Первое – улучшить чтение. Приходится много читать. Документация, переписка, скайп, чаты в слаке. Бывает, сообщения сыпятся, а ты уже минуту одупляешь одну и ту же фразу. Помогла электронная читалка Kindle. Я читаю тех. литературу на английском на темы, которые хорошо знаю – Емакс, Лисп. Когда знаешь контекст, вопринимать легче. К тому же, в Киндле есть встроенные словари – увидел незнакомое слово, нажал, сразу вышло его транскрипция и толкование. Причем это не голимый гугл-транслейт, а оксфордский словарь с примерами.

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

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

  Каждое видео длится три минуты. Смотреть нужно по следующей схеме:

  • смотрим и читаем бегущую стоку. Важно, чтобы все слова были понятны.
  • Слушаем снова, но не читаем.
  • Слушаем на скорости 1.25. Если что-то не понятно, повторяем или идем на предыдущий шаг.
  • Аналогично, только на скорости 1.5.
  • Аналогично, только на скорости 2. Это максимальная скорость. На ней лучше прослушать несколько раз.

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

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

  Деньги

  Закончим про английский, вернемся к удаленке. Поговорим подробней о деньгах.

  Зарплата из-за рубежа выше. Грубо говоря, зарплата мидла в Европе равна зарплате синьора в России. Или даже больше. Эта разница вызвана следующими факторами:

  • Жизнь в Европе дороже, там очень высокие налоги. Треть или даже 40% дохода европейца уходит на налоги.

  • Удаленный сотрудник не защищен профсоюзами. Это покажется странным, но на западе человека не могут уволить месяцами, потому что трудовой договор сильно защищает работника. Еще есть профсоюзы. Удаленщика никто не защищает. По контракту фирма предупреждает за неделю и давай до свидания.

  • Денежные переводы, которые фирма отправляет сотруднику, не облагаются налогами. Для фирмы это как купить мешок картошки. Из пункта о величине налогов следует экономия бюджета в 40%.

  Из-за разницы в ценах между странами заказчик покупает синьора по стоимости мидла-джуна. Это устраивает обе стороны.

  Кто-то может сказать, что ты не стоишь этих денег, потому что просто играешь на разнице цен. Но подобно тому, как вода движется от высокого давления к низкому, экономика работает на разнице цен. На моем ноуте написано “Designed in California, assembled in Malaysia”. Одну работу выгодней делать в одной части земного шара, другую – в другой.

  Работа на Европу или США – это законный долларовый доход. Сегодня в России абсолютно все зависит от цены доллара – от продуктов до техники.

  До введения санкций я покупал Макбук за 65тр, теперь он стоит 120тр. Шоколадный батончик стоил 20 рублей, стал 41. Наша семья побтребляет много молока – раньше брал за 35 рублей, однако с введением продуктового эмбаго качество молока, сыра, масла резко ухудшилось. Приходится покупать молоко за 65 рублей. Словом, в современной России рублевый доход – очень шаткая штука.

  Для получения валюты нужен статус ИП с валютным счетом. Сейчас есть МФЦ, где все делается быстро, буквально неделя. Подготовить бумаги помогу сервисы вроде “Мое дело” и “Контур Эльба”. Они же составят график выплат взносов, налогов и многое другое.

  Я работаю в Эльбе. Первый год бесплатен, потом 4 тр в год.

  Есть разные системы налогооблажения, самая простая УСН – 6 % с доходов. Каждый квартал платите 6 процентов с того, что заработали. Своевременно вносите в Эльбу заработанные суммы, система сама расчитает налог. Суммы в долларах автоматом переводятся в рубли по тому курсу ЦБ, который действовал на момент ее получения. Ставить неверную дату, чтобы снизить курс с целью уменьшить налог нельзя – это противозаконно.

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

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

  Есть такое понятие как паспорт сделки, когда показываете документы один раз. Их фиксируют в некую юридическую сущность, а вы ссылаетесь на нее многократно.

  Существует система Payoneer, которая создает вам счет в американском банке и присылает карточку для снятия денег. Я ни разу с ней не работал, но вижу минусы в следующем:

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

  • На каждую операцию – поступление на счет, конвертация, снятие – комиссии про пронципу (N + %) USD. У ИП, если операции протекают внутри банка, комиссии гораздо ниже.

  Я пользуюсь услугами известного банка. Хотя и был с ними досадный инцидент, услугами я доволен. Любая операция доступна в личном кабинете. Сайт работает только в Файерфоксе, интерфейс очень кривой, нужна Джава, но это мелочи.

  Налоги

  Вам придется платить налоги уже после получения денег, иногда это могут быть крупные суммы. Расставаться с ними уже псле получения трудно. Не удивительно, что человек, который платит налоги сам, становится более требовательным к себе и окружающим. Я заметил это по некоторым блоггерам, которые работают как ИП. Стали ИП – начали писать про политику, налоги, социальные вопросы.

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

  Еще есть патент. Вы оформляете патент на вид деятельности, и сумма налога станвится фиксированной. Эльба умеет работать с патентом. Получать его просто — качаете заявление, заполняете и несете в налоговую по месту прописки.

  Стоимость патента зависит от региона, уточняйте на сайте Налоговой службы.

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

  Как жить с удаленной работой

  Главное в удаленке – не остаться в изоляции. Есть риск деградировать. Нельзя замыкаться, ищите единомышленников.

  

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

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

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

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

  О прокрастинации

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

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

  Сократить число отвлекающих факторов. Отключить нотификации в месенджерах, всяких скайпах-слаках. Оставить только самые важные, например, от конкретных людей. Чаты со смешными картинками поставить на мьют.

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

  Не пользоваться соцсетями, читать только RSS в Feedly или другом клиенте. Не шариться просто так по сайтам. Использовать текстовые редакторы вместо ИДЕ, плоский текст вместо бинарных файлов или конфигов. Вместо облачных хранилищ подойдет приватный репозиторий на Гитхабе.

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

  Другое

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

  Туманные рассуждения о преимуществах Лиспа и Гоу – там же.

  После моего прощания в чате высказались другие удаленщики. Их тоже интересно почитать.

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