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

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

https://stackoverflow.com/questions/33002829/ios-keeping-old-launch-screen-and-app-icon-after-update/33003622#33003622

​​Роль тимлида в бизнесе

Культура тимлидства в России у нас пока низкая: многим кажется, что нужно взять самого скилованного разработчика, дать ему прибавку 15-30% и сказать "ты тимлид, возьми Скрам и построй разработку шобы всё было мне понятно. Кстати, ты всё равно остаёшься разработчиком, поэтому не забывай писать код". Чушь.

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

Кроме правильных процессов (это быстро приходит в порядок, я писал об этом в статье Как начать скрамить), тимлид должен:
Систематизировать знания: звучит цинично, но тимлид не должен прикипать к своей команде, потому что его задача — снизить bus factor. Тимлид должен создавать документацию и базу знаний, чтобы при смене всей команды бизнес не встал.

Обучать и интегрировать людей: вторая по важности задача. Когда есть документация, нужно срезать косты на обучение и интеграцию людей. Да, можно сказать, что этим должен заниматься HR, но хороший тимлид и выполняет роль HR. Мы в JQ Estate делали хэндбук, чтобы людям проще интегрироваться.

Объяснять, что делает команда разработки: разработка не должна быть чёрным ящиком для остальных отделов в компании. Демо-дни из скрама и прочие презентации нужны, чтобы вся компания знала, что сделала команда разработки и что она будет делать дальше.

Следить за настроением команды: спринты спринтами, но бизнес это марафон. Тимлид должен следить за состоянием команды, держать всех в тонусе и не давать перегорать из-за больших нагрузок. Ну и, конечно, давать фидбэк и получать его — если человек приходит увольняться из-за маленькой зарплаты, то что-то пошло не так. Рекомендую вопрос мотивации держать открытым, чтобы все знали как они могут получать больше. Бтв, в Т—Ж хорошая статья: Как поднять себе зарплату.

Пиарить команду: посмотрите на Злых марсиан. Чем громче команда, тем больше людей к ней пытается попасть и тем проще нанимать людей по адекватным ценникам, а не x3 от рынка, потому что никто её не знает. Команда должна быть престижной. Тот же хэндбук Джкью пример такого пиара: когда я кинул вакансию с этим хэндбуком в @javascript_jobs, я за первый час получил под 40 откликов. Слава богу, у нас конкуренции и продуктовых команд мало — расскажи что вы делаете и уже будет интерес.

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

Теперь вопрос: и когда писать код?

Есть что добавить? 👉🏻 @evgenyrodionov

Когда спринт завершается, то нужно сделать выводы. В мире Agile эта процедура именуется ретроспективой. И сегодня я расскажу вам о том как ретроспективы проходят у нас. И сразу же маленькая ремарка, я рассказываю один из самых простых форматов ретроспектив, т.к мы проводим его чаще всего, он длится по времени полтора-два часа и требует минимума подготовки. Но если если вам будет интересно погрузиться в тему, то рекомендую почитать «Agile Retrospectives: Making Good Teams Great» (https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/)

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

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

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

На то чтобы написать даётся 10-15 минут. Пишем в тишине. Когда ретро веду я, то за 2-3 минуты я напоминаю, что время подходит к концу, но другие мастера делают по своему. Когда время заканчивается мы начинаем вешать стикеры на доску. Каждый участник ретроспективы выходит к ней, проговаривает написанное и вешает в соответствующую часть. После того как прочитаны все стикеры, ведущий благодарит участника и зовёт следующего. При этом мы не ограничиваемся одним проходом, так как иногда вспоминаешь что-то слушая другого, после первого круга может наступить второй.

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

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

В итоге, должно получиться как-то так.

Остаётся совсем немного. Приоритезируем проблемы для обсуждения, например, голосуем по кругу (и у каждого пара-тройка голосов) за кластеры. Это нужно и для того, чтобы понять какие проблемы стоит вообще обсуждать, и для того чтобы успеть это сделать в оставшееся время.

Ну и, наконец, штурмим на тему решения каждой проблемы.

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

Завтра подробнее про мозговые штурмы.

Самописная аутентификация пользователей - это очень больно

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

- АПИ авторизации через соцсети со временем протухают. Через соцсеть надо не забывать вытаскивать емейл.

- Емейлы везде нужно ловеркейсить.

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

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

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

- Для пароля нужно использовать models.PasswordField, чтобы пароль сам за вас хешировался и солился в базе. При этом пароль всё равно будет утекать в открытую в логи, пока вы не поставите везде где надо декоратор sensitive_post_parameters.

В общем, я созрел для вендор-лока на Auth0, Firebase Authentication или Amazon Cognito User Pool.

Подборка про то, что если получить work authorization в Нью-Йорке, то без работы не останешься.

https://www.builtinnyc.com/2017/11/07/nyc-top-100-tech-companies-2017

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

Сегодня официант сам завязал со мной разговор:

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

Яжпрограммист.

Что делать в Лиссабоне

Что делать в Амстердаме

Что делать в Праге

#design #figma

Помните я ранее писал, что смотрю в сторону Figma, но пока не готов переехать. Так вот, это случилось, после месяца тестирования дизайн-команда Модульбанка переехала на нее и я хотел поделиться с вами, почему мы так сделали.

Началось все с того, что мы в очередной раз обсуждали с нашим лид-дизайнером Динаром инструментарий для оптимальной работы. И конечно, о чем я ранее тоже писал, мы использовали популярную связку Sketch + Abstract + Lingo (тогда еще не было общих компонентов в скетче). Проблема возникла тогда, когда мы поняли, что у нас есть еще аналитики, которые делают прототипы для отображения бизнес-логики (не забывайте, мы делаем банк и без полных технических заданий с проверкой всех кейсов нам никак) и мы хотели дать им удобный инструмент для создания этих самых прототипов. А с учетом того, что альфа версия наших компонентов была готова, то вообще дать им готовую библиотеку с кнопками и т.д., что позволило бы сразу делать прототип по нашим гайдам. И тут мы решили потестировать Figma и когда я говорю потестировать, то реально замерить разницу, а не только субъективные чувства.

Динар замерил скорость выполнения маленькой задачи (30 минут работы) в существующей связке и в Figma и оказалось, что помимо овертулзинга, мы еще сверху тратим от 5 до 7 минут на то, что бы синхронизировать все и проверить. А если надо показать результат бизнес-заказчику, то это еще 1-2 минуты, чтобы залить в Zeplin (для кого-то InvisionApp, но суть та же).

Сразу скажу, что Figma с момента моего последнего поста про нее сильно подросла и самое главное, они выпускают апдейты практически через каждые несколько дней. Посмотрите на их change-log http://releases.figma.com/ – даты и то, что они сделали, говорит сам за себя.

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

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


P.S. Сразу после того, как показался Invision Studio я задал вопрос ребятам из Figma, будет ли у них такой же инструмент для анимаций, так как это единственное, в чем они отстают, на что получил, практически, утвердительный ответ от их CEO Dylan Field 🚀

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

"Just to set expectations, I am not aware of anyone looking into this issue. Having been in similar situations in the past, two things that have worked well to get unblocked are forking+fixing the issue locally and contracting an expert.
👍 3 👎 3 😕 1"

https://github.com/facebook/react-native/issues/16522