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

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

Но я это все к чему. А к тому что даже в надежных проектах (5 лет без видимых поломок!) рано или поздно неизбежно случаются поломки. Что это значит? Что можно не париться ведь все равно все сломается? Нет. Можно и нужно работать над качеством и надежностью проекта, чтобы ломалось раз в 5 лет, а не через день.

Очень полезная штука когда надо быстро сделать некое подобие мока бэкенда

jsonbox — бесплатное удалённое хранилище для JSON: https://jsonbox.io/

Сервис генерирует для вас URL, к которому вы сможете обращаться через API, чтобы сначала добавить, а затем читать и редактировать ваш JSON.

Документация: https://github.com/vasanthv/jsonbox#readme

#инструменты #api #json

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

70% стоимости решения большинства задач — в коммуникациях.

Один из вариантов решения проблемы - утвердить "SLA" на уровне компании (кстати похожим образом сделано у нас в Skyeng). Согласовать со всем руководством, оформить документально (например в confluence), ознакомить всех сотрудников с документом. Затем включить вопрос ознакомления с этим правилом в процесс онбординга новых сотрудников.

Схематичный пример как могут выглядеть правила:

- Сообщение в slack. Не дольше 3 часов.
- Сообщение по электронной почте. Не позднее следующего рабочего дня.
- Личные встречи и звонки согласовываются заранее и заносятся в календарь

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

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

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

В эту субботу в Воронеже буду выступать на https://gdgvrn.ru с докладом об особенностях построения рабочих процессов в распределнной команде.

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

Перевод курса по документированию API теперь есть в форме сайта: https://starkovden.github.io.

Заметил последнее время много шума вокруг асинхронных инструментов в php. В PHP дайджесте на Хабре даже отдельный раздел под это завели. Из того, что я более-менее видел, это https://reactphp.org/) и https://www.php.net/manual/ru/book.swoole.php. Кстати, много интересной информации по этим инструментам можно почерпнуть в блоге моего коллеги Сергея Жука https://sergeyzhuk.me/reactphp-series.

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

Я пару лет назад начал писать на go. Это отдельная история как и почему, сейчас не об этом. Мне кажется нет смысла объяснять отдельно как выглядит асинхронность там. Когда приходится сталкиваться с задачами, где действительно требуется утилизировать ресурсы или где милисекунды решают, то я вряд ли буду смотреть в сторону ReactPHP, а скорее решу эту задачу на go, потому что он создавался как раз для подобных задач, а вот php совсем для других.

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

21 ноября состоится митап про страхи в php http://it.skyeng.ru/php21 Я там буду участвовать в качестве спикера в том числе. Кому интересна какая-то из тем или кто хочет пообщаться регистрируйтесь и приходите!

Мои предсказания о будущем php
https://habr.com/ru/company/skyeng/blog/474724/

В php 8 будут объедиенные типы. https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-union-types-v2.md Подавляющим количеством голосов предложение принято. Выглядит как возвращение к тому, от чего пытались уходить.

Рутинная работа, наверное одно из самых демотивирующих явлений. Как подумаешь что прежде чем сесть за интересную задачу, которую руки чешутся решить, нужно сначала разгрести таск-трекер, так сразу настроение начинает идти вниз.
Думаю пора начать серию постов о своем опыте автоматизации рабочих процессов и не только рабочих. Эта серия зрела давно. В двух словах сказать все что набралось невозможно. Поэтому постараюсь по порядку осветить все то, с чем пришлось столкнуться и что получилось успешно решить с помощью автоматизации.
И начну пожалуй с самой частой проблемы, о которой немного сказал вначале. Проблемы рутины. Давным-давно, когда я еще занимался работой на аутсорсе с небольшой командой, столкнулся с проблемой актуальности статусов и другой информации о задаче в таск-трекере. Приходилось ежедневно вручную контролировать этот вопрос, что утомляло и занимало время. В команде использовался redmine и он поддерживал интеграцию с git из коробки. Если указать в названии коммита номер задачи и статус, то он сменится в задаче автоматически. Но как заставить разработчиков не забывать правильно оформлять сообщения коммитов? Даже если они ответственные люди, все равно не исключен человеческий фактор и нарушения форматов будут, а это значит, что надеяться на этот механизм нельзя и нужно продолжать контролировать вручную. Безнадега.
Изучив тему, решил попробовать воспользоваться pre-receive хуком, который запускается на стороны сервера до того, как изменения будут приняты в репозиторий. Написать этот хук можно на bash/pyton/php и других скриптовых языках. Мне было это проще сделать на php. Скрипт занимался тем, что проверял сообщения коммитов на четко заданный формат, примерно такой "#{task-id}-{status} | {message}". Список возможных значений для status был жестко ограничен, так как соответствовал статуса в redmine. Хук не пропускал коммиты с неправильными статусами или неверными форматами сообщений. Он просто не давал пушить. Первое время это частенько кого-нибудь выбешивало, когда забывал оформить по правилам. Приходилось даже делать rebase когда коммитов в пуше не один и просто ammend не мог помочь. Но скоро уже все привыкли, комиты оформлялись правильно на автоматизме и проблема исчезла. В дальнейшем этот хук стал также проверять и статус задачи, например, не давая пушить в закрытые задачи. Это было несложно доработать с помощью Redmine API и даже нашелся [готовый php-клиент](https://github.com/kbsali/php-redmine-api).
Реализация заняла у меня часа 4-5 в сумме. Если не считать первых попыток на bash, которые не увенчались успехом в виду моих не достаточно глубоких познаний в этом инструменте. В итоге статусы в задачах стали меняться автоматически, в каждой задаче был список коммитов, на которые можно было перейти и посмотреть что именно мы меняли. В истории git была привязка к задачам, в рамках которых делались изменения, я этим кстати часто пользовался, чтобы посмотреть для чего делались те или иные правки, смотрел переписку по задаче. Также часто помогало поиском по истории собрать воедино все правки по проблеме когда коммиты разбросаны. Вообщем время это экономило массу и привнесло порядка. Ну и конечно же я перестал беспокоиться об актуальности статусов и просто начал ими пользоваться. Если стоит статус released значит задача в мастере, если ready for development - значит ни одного коммита еще не сделано и т.д.
Все в команде настолько к этому привыкли, что как-то раз, когда этот хук внезапно отвалился, это вызвало небольшую волну возмущений, "а почему статусы перестали проставляться". Хук конечно же быстро починили.
Но правда одно ограничение все же есть. Pre-receive срабатывает на стороне сервера. И если у вас облачный github/gitlab/bitbucket, то использовать эту возможность не получится. По крайней мере я не нашел способа. Если кто-то его знает, то за подсказку в личку буду благодарен.

Недавно писал пост про переработки в другой канал

Привет, Антон @antgubarevcom Губарев продолжает поднимать вечные и холиварные темы. Сегодня он хочет поговорить с вами

Про переработки ⏳🎡

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

У нас в Skyeng в официальной вики четко прописано, что переработки не приветствуются. Но я:

• всё ещё встречаю рассказы о компаниях, в которых переработки не только распространены, но и поддерживается на уровне руководства 🤦‍♂️

• вижу ситуации, когда сотрудники пытаются перерабатывать по своей воле 🧟‍♂️

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

Хуже, когда в коллективе заводится трудоголик или карьерист. Человек, готовый работать по 60 часов в неделю просто потому, что для него это норма (ну или он так думает)🤖 Казалось бы, вот он, локомотив, который способен затащить задачи, которые другим не под силу. Но вид такого “стахановца”, скорее всего, будет демотивировать неуспевающих. И исправить их неуспеваемость станет сложнее. Да и неспроста выгоревший трудоголик — всё более частое явление.

40 часов на работу в неделю

https://meetups-online.ru/php-may-2020 В эту субботу буду рассказывать как мы в непростых условиях смогли избавиться от очень старого легаси монолита и не упасть в грязь лицом перед бизнесом.

Этот анонс напомнил мне о том что на этом мероприятии будет интересный доклад от слепого разработчика.

На ближайших выходных сразу два крутых PHP-мероприятия. Ребята уже скоординировались и больше таких коллизий не будет. Ну а в этот раз можно насладиться выбором.

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

Кроме того, 30 и 31 мая будет проходить PHP fwdays online. Программа вот тут https://fwdays.com/en/event/php-fwdays-2020#program-event.

Сам жду доклад Макса Рафалко (Infection) о принципах проектирования пакетов. Уж очень понравился его документ о выделении пакета из Infection https://github.com/infection/infection/issues/922.

Организаторы PHP fwdays предоставили пару билетов для розыгрыша — он в следующем сообщении.

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

https://github.com/walkor/Workerman Новый набирающий обороты инструмент для асинхронного программирования на пыхе. Сомнительное использование пыха, но инструмент может быть полезен

https://github.com/golang/pkgsite Теперь опен сорс!