Сайт Романа ПарпалакаБлог

Небо над Москвой — 2

Традиционное фото на 9 мая:

9 мая 2018 года, 10:31     фото     Оставить комментарий
Смотрите также:  Небо над Москвой

Политика на улице

28 марта 2018 года, 22:18     фото · политика     Оставить комментарий
Смотрите также:  Белая лента

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

Промышленное прогаммирование

Хочу поделиться опытом промышленной разработки программного обеспечения. Под словом «промышленная» я понимаю разработку приносящего деньги продукта в коллективе от нескольких десятков человек.

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

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

Аджайл-манифест разработки программного обеспечения

Начнем систематизировать знания о разработке с аджайл-манифеста:

Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.

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

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

Область ответственности разработчика

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

Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тестировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.

Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!

Вторая:

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

Это два противоположных подхода к вопросу об области ответственности разработчика. Давайте выделим особенности каждого подхода:

Оператор ЭВМ Инициативный разработчик
Просит четкое техническое задание Просит объяснить бизнес-ценность задачи
Делает по требованиям, даже если они противоречат сделанному ранее Не любит переделывать
При обнаружении противоречий сообщает постановщику задачи
Не дает результат без менеджера и тестировщиков Работает самостоятельно
Знает, что значит «сделать»
Получает меньше денег Получает больше денег

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

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

25 марта 2018 года, 19:03     промышленное программирование     Оставить комментарий

День выборов

На этих выборах есть три возможных стратегии:

  1. Проголосовать за Путина.
  2. Проголосовать не за Путина.
  3. Не пойти на выборы.

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

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

Понятно, что в ходе голосования будут фальсификации. Понятно, что выборы нечестные. Что выборов нет вообще. Но это слабая причина, или даже отговорка, чтобы не ходить на голосование. Как говорит Белковский, «классический принцип традиционной этики состоит в том, что делай, что должен и будь что будет». Отказываясь от голосования мы точно ни на что не можем повлиять.

Кстати, перечитал свой старый пост об итогах выборов в парламент в декабре 2011 года. Многие вещи выглядят наивно, особенно подсчеты рейтингов. Такая уж была атмосфера медведевской модернизации. Но уже через полгода, после разгона марша миллионов на Болотной, я написал о том, что Путин прошел точку невозврата и сам от власти не откажется. После маленькой победоносной войны на Украине говорить о рейтингах вообще стало бессмысленно.

Тем не менее, за шесть лет основная идея — «надо согласиться с тем, что любой человек (в том числе Зюганов или Жириновский), выигравший выборы у Путина, будет президентом не хуже, чем сам Путин» — всё еще актуальна. Поэтому я воспользуюсь классическим принципом традиционной этики и прогуляюсь в этот солнечный день до избирательного участка.

18 марта 2018 года, 12:11     политика     Оставить комментарий

Собираем долги после обедов с коллегами

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

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

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

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

Достоинства этого волшебного метода трудно переоценить. Официант сам дает чек вместе с картой, и я кладу в кошелек и карту, и чек. Чеки не теряются, они надежно лежат в кошельке вместе с картами и небольшим запасом наличных. Чеки периодически попадают в поле зрения и своим видом напоминают: «Посмотри переводы и выбрось ненужные». Когда я занят, чеки спокойно лежат и ждут день-два. Мне не надо помнить о сборе денег. Я никому не надоедаю фразами «не забудь перевести за обед».

Иногда коллеги забывают вернуть деньги. Я прихожу и говорю:
— Слушай, мы в понедельник были в «желтых дверях», и, похоже, ты не перевел мне деньги. Вот чек. В истории переводов у меня пусто.
— Да? Сейчас посмотрю. А, да, сейчас переведу, извини.

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

22 января 2018 года, 22:25     деньги     Оставить комментарий

Уравнение Максвелла

Центральное место на этой фотографии занимает формула $$\nabla\cdot\vec{B}=0$$ на разрисованной стене.

Это одно из уравнений Максвелла в дифференциальной форме. Вероятно, оно должно вдохновлять играющих на площадке детей.

20 января 2018 года, 19:41     фото     Оставить комментарий

Здесь нет выхода

16 января 2018 года, 22:57     идиотека     Оставить комментарий

Поиграл на рояле

Позавчера летел из Кишинева. Зал вылета был полон. Подошел к бизнес-залу. Он был перекрыт (видно на фото справа). Девушка за стойкой информации сказала, что он на реконструкции.
— А у вас рояль стоит, на нем можно поиграть?
— Да, можно.
— Стоит два евро, — добавил сотрудник аэропорта, стоящий рядом.
— Два евро?
— Да шутка это, — улыбнулся он.

Сыграл несколько композиций с перерывами на голосовые объявления. В конце несколько человек похлопали, одна женщина поблагодарила :)

15 января 2018 года, 22:01     lytdybr · фото     Комментарии (2)

Линуксовая подсистема в Windows

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

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

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

Так или иначе, проблема удобной настройки окружения для веб-разработки на PHP была решена только в Windows 10. В ней появилась линуксовая подсистема, или WSL. Она позволяет запускать скомпилированные для линукса бинарники. При этом ядро линукса отсутствует, а системные вызовы к нему на лету транслируются в Win API. В общем, WSL — это Wine наоборот.

Несколько лет после выхода линуксовая подсистема была в состоянии беты, и пользоваться ей было невозможно. Но, начиная с Creators Update, выпущенного в апреле, ситуация изменилась, и nginx вместе с php-fpm нормально заводится и работает.

С практической точки зрения WSL — это командная строка bash, в которой можно устанавливать любой пакет из репозитория Ubuntu 16.04 через apt install. Диски компьютера примонтированы и доступны в файловой системе через /mnt/c, /mnt/d и т. д.

Ребята из Микрософта нацеливались на «интероперабельность»: из bash можно запустить не только линуксовые elf-бинарники, но и обычные exe-файлы. Процессы могут без проблем работать друг с другом. Например, мне было лень делать дамп и переносить базу данных, и я оставил ее в Windows. К ней успешно подключается php-fpm.

Я перевел ежедневную работу на линуксовую подсистему. Обнаружил две проблемы. Первая: не работают unix-сокеты. Решается использованием TCP-сокетов в конфигурации php-fpm и nginx. Вторая: nginx падает при загрузке файлов, из-за того что вызывает нереализованную функцию. Решается запуском встроенного в PHP веб-сервера при тестировании загрузки файлов. Ситуация у меня возникала редко. Может быть ее уже исправили, а я об этом и не знаю.

Еще есть особенность: не работают средства автозапуска программ. Пришлось добавить команды service start nginx в .bashrc.

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

Положительные моменты: можно выкинуть MinGW, виртуальные машины и прочие попытки завести bash на Windows, и работать в полноценной линуксовой консоли. Софт в среде разработки идентичен софту на боевом сервере и обновляется одной командой apt upgrade.

Спустя три года я всё-таки перешел на Windows 10, линуксовая подсистема стала в этом решающим фактором.

8 января 2018 года, 01:23     веб-разработка · операционные системы · линукс     Комментарии (3)

О схеме URL сервиса генерации картинок с формулами

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

На самом деле код картинки содержится в ее адресе. Как писал Якоб Нильсен 19 лет назад, URL — это интерфейс. И я принял такое интерфейсное решение. Формула на латехе (например, a^2+b^2=c^2) кодируется и добавляется в урл:

//tex.s2cms.ru/svg/a%5E2%2Bb%5E2%3Dc%5E2

По нему открывается сама картинка с формулой: $$a^2+b^2=c^2$$.

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

//tex.s2cms.ru/g/a%5E2%2Bb%5E2%3Dc%5E2

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

Вообще, исходный код может быть достаточно длинным. Вот пример, в котором на комплексной плоскости отмечены первые 10 степеней числа $$1+i\pi/10$$:

\begin{tikzpicture}[scale=1.0545]\small
\tikzset{>=stealth}
\def\k{10}
\def\p{3.1415926/\k}
\def\r{3.1}
\def\l{5.8}
\def\t{0.07}
\draw[->,thin,gray] (-\l,0)--(\l,0);
\draw[->,thin,gray] (0,-0.6)--(0,\l);
\draw[green!40!black](\r,0) -- (\r,\p*\r) node[midway,right] {$i\pi/\k$};
\foreach \l in {1,...,\k}
   \draw[->] (0,0) -- ({(\l-1)*atan(\p)}:{((sqrt(1+\p*\p)^(\l-1)*\r)});
\draw[->,red] (0,0) -- ({\k*atan(\p)}:{((sqrt(1+\p*\p)^\k*\r)}) node[pos=0.91,above] {$-1,\!5934+0,\!1561i$};
\draw[very thin] (\r,\t)--(\r,-\t) node[below]{$1$}
(-\r,\t)--(-\r,-\t) node[below]{$-1$}
(\t,\r)--(-\t,\r) node[left]{$1$}
(0,0) node [anchor=north west,yshift=-0.07cm] {$0$};
\draw [line width=0.21mm,opacity=0] (-\l,-0.6) rectangle (\l,\l);
\end{tikzpicture}

Результат:

$$\begin{tikzpicture}[scale=1.0545]\small \tikzset{>=stealth} \def\k{10} \def\p{3.1415926/\k} \def\r{3.1} \def\l{5.8} \def\t{0.07} \draw[->,thin,gray] (-\l,0)--(\l,0); \draw[->,thin,gray] (0,-0.6)--(0,\l); \draw[green!40!black](\r,0) -- (\r,\p*\r) node[midway,right] {$i\pi/\k$}; \foreach \l in {1,...,\k} \draw[->] (0,0) -- ({(\l-1)*atan(\p)}:{((sqrt(1+\p*\p)^(\l-1)*\r)}); \draw[->,red] (0,0) -- ({\k*atan(\p)}:{((sqrt(1+\p*\p)^\k*\r)}) node[pos=0.91,above] {$-1,\!5934+0,\!1561i$}; \draw[very thin] (\r,\t)--(\r,-\t) node[below]{$1$} (-\r,\t)--(-\r,-\t) node[below]{$-1$} (\t,\r)--(-\t,\r) node[left]{$1$} (0,0) node [anchor=north west,yshift=-0.07cm] {$0$}; \draw [line width=0.21mm,opacity=0] (-\l,-0.6) rectangle (\l,\l); \end{tikzpicture}$$

Этот пример я взял из статьи о формуле Эйлера $$e^{i\pi}=-1$$. Первую версию картинки рисовал вручную. В Maple выполнил возведение в степень и построил график. Открыл его в фотошопе и поверх дорисовал стрелки-векторы, оси координат.

На версию с графиком в tikz ушло столько же времени, или даже больше. Но масштабируемость результата находится на совершенно другом уровне. Чтобы нарисовать первым способом вдвое больше векторов, нужно потратить вдвое больше времени. Второй способ требует изменения одного числа k в исходном коде, и foreach сделает всю работу. Вот 20 векторов:

$$\begin{tikzpicture}[scale=1.0545]\small \tikzset{>=stealth} \def\k{20} \def\p{3.1415926/\k} \def\r{3.1} \def\l{5.8} \def\t{0.07} \draw[->,thin,gray] (-\l,0)--(\l,0); \draw[->,thin,gray] (0,-0.6)--(0,\l); \draw[green!40!black](\r,0) -- (\r,\p*\r) node[midway,right] {$i\pi/\k$}; \foreach \l in {1,...,\k} \draw[->] (0,0) -- ({(\l-1)*atan(\p)}:{((sqrt(1+\p*\p)^(\l-1)*\r)}); \draw[->,red] (0,0) -- ({\k*atan(\p)}:{((sqrt(1+\p*\p)^\k*\r)}); \draw[very thin] (\r,\t)--(\r,-\t) node[below]{$1$} (-\r,\t)--(-\r,-\t) node[below]{$-1$} (\t,\r)--(-\t,\r) node[left]{$1$} (0,0) node [anchor=north west,yshift=-0.07cm] {$0$}; \draw [line width=0.21mm,opacity=0] (-\l,-0.6) rectangle (\l,\l); \end{tikzpicture}$$

Вот 50:

$$\begin{tikzpicture}[scale=1.0545]\small \tikzset{>=stealth} \def\k{50} \def\p{3.1415926/\k} \def\r{3.1} \def\l{5.8} \def\t{0.07} \draw[->,thin,gray] (-\l,0)--(\l,0); \draw[->,thin,gray] (0,-0.6)--(0,\l); \draw[green!40!black](\r,0) -- (\r,\p*\r) node[midway,right] {$i\pi/\k$}; \foreach \l in {1,...,\k} \draw[->] (0,0) -- ({(\l-1)*atan(\p)}:{((sqrt(1+\p*\p)^(\l-1)*\r)}); \draw[->,red] (0,0) -- ({\k*atan(\p)}:{((sqrt(1+\p*\p)^\k*\r)}); \draw[very thin] (\r,\t)--(\r,-\t) node[below]{$1$} (-\r,\t)--(-\r,-\t) node[below]{$-1$} (\t,\r)--(-\t,\r) node[left]{$1$} (0,0) node [anchor=north west,yshift=-0.07cm] {$0$}; \draw [line width=0.21mm,opacity=0] (-\l,-0.6) rectangle (\l,\l); \end{tikzpicture}$$

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

Меня просили изменить алгоритм кодирования, чтобы укоротить адреса. Необходимости в этом я пока не вижу. Но если буду делать доработку, то поступлю аналогично. Адрес /svgb/... с закодированными в base-64 бинарными данными будет вести на картинку, /gb/... на дешифрованный вариант в редакторе формул.

6 января 2018 года, 01:13     upmath     Оставить комментарий

туда →

Поделиться
Записи

Подписка на RSS (?)