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

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

Компьютер сейчас это всемирная база знаний и универсальный симулятор любого устройства.

Но проводите ли вы дни и ночи в библиотеке? Хотите ли превращаться из придатка к одному устройству в придаток к другому?

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

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

Ищу хорошего фронтенд-разработчика, или целую небольшую команду (react/angular). Необходимо оперативно подхватить проект у тех, кто с ним не справился (в целом, около 15 тыс строк js, css и других ресурсов), критически переосмыслить и сделать как надо делать. Прежде всего — работоспособным. Проект — инструменты для сбора лидов и заявок, и работы с заявками на финансовые услуги.

Объем работы (сейчас около 500 условных чч, далее порядка нескольких тысяч, если наш интерес будет взаимным).

Есть CI, авторазвертывание на стенды, git, спецификации человеческим языком в wiki, макеты, API на бэкенде, который готовы подправить под необходимые запросы.
Pixel-perfect не требуется. В приоритетах — скорость завершения работы и работоспособность.

Я хорошо отдаю себе отчет, что срочность и овертаймы требуют много денег. Мы к этому готовы.

В инфо этого канала есть контакты, куда обращаться.

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

Итак, есть понедельник, и есть задача, она _как-то_ описана. Срок — одна календарная неделя, т.е. к следующему понедельнику надо принести результат выполнения задачи. Срок согласован с исполнителем, более того — именно он автор этого срока. Исполнителю даже выдан стандартный запас в 15-25% по сроку.

Всю неделю бодро идет работа, по плану, предоставленному исполнителем.

Реперные промежуточные точки, тем не менее, срываются — промежуточный результат сдается не вовремя, или в  худшем качестве (из-за недостатка времени) — я бы сказал, в непредсказуемо худшем, потому что исполнитель на свое усмотрение решает не делать некоторые подзадачи, чтобы показать хоть что-то. Несделанное копится на конец срока. В пятницу вечером становится понятно, что результата всё равно нет.

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

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

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

А теперь понял, что все это лажа, а такой исполнитель — натурально мудак.

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

Итак, есть поликлиники и их филиалы (около 500), в них есть кабинеты (по 10-100) в каждой, каждому кабинету задаётся достаточно сложное расписание работы (время начала, окончания, перерыва, врач на обеде, врач замещает, специальность врача, прием только оффлайн и т.п. - представьте сотни разных правил, которые могут друг с другом совмещаться, или не могут).

Требуется - уметь по всем кабинетам для заданной специальносьи вернуть 10-минутные слоты записи, можно ли записаться или нет, на интервал до будущих двух недель.

Запросов таких будет до сотни в секунду. Расписание врачи могут править в любой момент.

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

Иногда даже на Хабре выходят хорошие статьи (в переводе). Вот статья о микросервисах. К таким же выводам я пришел, проблуждав сначала в одну сторону, а потом вернувшись  обратно - хочется верить, уже на новом витке https://m.habr.com/post/427215/

У меня между делом спросили, почему это канал так называется.

Ответ очень простой - как понять, что архитектор занят работой? У него губы шевелятся.

Рот закрыл - рабочее место убрал.

По моему опыту, и code review зачастую является блажью

Открыл для себя тему java agents в jvm и изучаю возможности для построения “песочниц”.
Пока что выглядит очень интересно: можно лимитировать количество исполняемого байткода (в штуках), объем выделяемой памяти (до байт), а при помощи небольшого проспективного анализа предупреждать исполнение кода, который может негативно сказаться на управляемости хоста. И это все с уже готовым достаточно удобным instrumentation api.

Абсолютно не жалею, что когда-то отказался от .net

Service mesh is the new ESB. Только теперь вам нужен еще и “девопс”

"Всё, что _на самом деле_ стóит делать, имеет ненулевой шанс неудачи и слишком много неизвестных параметров для разумной оценки сроков"

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

Буду на FinCore2018. Если оставят без присмотра микрофон — еще и выступлю.

У кого-то есть вопросы и желание пообщаться? Можно увидеться

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

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

С таким вебом, как сейчас есть, ренессанс мобильных приложений вещь вполне реальная

В коллекцию вопросов для собеседования. Вопрос хороший, можно час потрещать.

Итак, есть клиент-серверное приложение. В нем есть необходимость валидации. По классике код валидации приходится дублировать и на клиенте, и на сервере.

Необходимо предложить варианты, как с этим можно побороться

Agile и современный "devops" это что-то из обсессивно-компульсивных расстройств деплоймента — всеобщая одержимость быстрыми релизами (быстрее! чаще! еще быстрее и чаще!).

При этом — зрите в корень — про необходимость и безусловную пользу "частых" релизов пишут в книжках те, кто в in-house разработке релизит раз в месяц или около.

Алло, ребят, разберитесь в предмете! Их _часто_ — это раз в неделю (потому что привычно и обычно это было как билды MS Office, раз в год), а вы что себе вообразили?

Известная картинка, где типа босс погоняет работяг, а типа лидер тянет лямку вместе с ними - подлая манипуляция, ибо предлагает делать "правильно".

Правда состоит в том, что не надо быть ни боссом, ни лидером — правильно это нанять всех этих парней, чтобы они работали на тебя.