Но пока до моего второго в жизни хакатона остается еще 3 недели, вот увлекательная штука.
Вчера по личной необходимости залез на русский форум Рассвет - это местный форум для русских и приехавших из СНГ, проживающих в Нидерландах.
Так вот пока я листал форум, наткнулся на тему под названием "burnout и депрессия".
Для тех кто не в курсе - бернаут, это по нашему выгорание на работе. Что такое выгорание объяснять, думаю, не нужно.
В ветке объясняли, как с этим бернаутом бороться, что надо идти ко врачу и получать направление к психотерапевту с антидепрессантами.
На самом деле это очень смешно. Представьте, вы в России приходите к шефу и говорите, что вы выгорели на работе, и у вас теперь депрессия. А тут так можно и даже нужно!
Очень интересно, что в Нидерландах знать не знают про такие болячки, как гастрит или остеохондроз, зато бьют тревогу при депрессии.
Проблемы первого мира, чтоб его...
Вчера по личной необходимости залез на русский форум Рассвет - это местный форум для русских и приехавших из СНГ, проживающих в Нидерландах.
Так вот пока я листал форум, наткнулся на тему под названием "burnout и депрессия".
Для тех кто не в курсе - бернаут, это по нашему выгорание на работе. Что такое выгорание объяснять, думаю, не нужно.
В ветке объясняли, как с этим бернаутом бороться, что надо идти ко врачу и получать направление к психотерапевту с антидепрессантами.
На самом деле это очень смешно. Представьте, вы в России приходите к шефу и говорите, что вы выгорели на работе, и у вас теперь депрессия. А тут так можно и даже нужно!
Очень интересно, что в Нидерландах знать не знают про такие болячки, как гастрит или остеохондроз, зато бьют тревогу при депрессии.
Проблемы первого мира, чтоб его...
👍1
Что ж я отсутствовал слишком долго, так позвольте рассказать почему.
Дело не в том, что по возвращению из отпуска я, как и многие другие, долго вхожу в рабочий ритм, и даже не в том, что за последний месяц я не столкнулся ни с чем интересным, о чем хотел бы рассказать на канале.
Канал не только о работе с машинами, но и работе с людьми, и именно о людях я сегодня и расскажу.
Жизнь в Нидерландах для экспата всегда начинается с арендованного жилья, и здесь, к счастью, процесс построен довольно гладко. Есть арендодатель, арендатор и между ними риэлторская фирма, занимающаяся всеми техническими и организационными вопросами.
В Нидерах вы можете снять квартиру на любой вкус и бюджет, временную или постоянную, с мебелью или пустую, а также в включенными в аренду коммунальными расходами или без.
Гоняясь за дешевой стоимостью аренды, мы сняли квартиру с мебелью, но без коммуналки, а значит расходы на газ, воду и электричество были на нас.
В апреле этого года мы обнаружили проблему с отоплением, когда батареи нагревались вне зависимости от температуры на термостате. Об этой проблеме мы сообщили риэлтору, и началась долгая вакханалия, в которой было все: игнорирование наших жалоб риэлтором, мастеры без необходимых инструментов, миллионы писем и звонков.
Так продолжалось пока мы не уехали в отпуск, перед чем я отправил данные счетчиков в газовую компанию для расчета потребления.
Вот тут-то и начался адок.
Согласно данным газовой компании наше потребление газа составило чуть меньше 3000 кубометров газа. Чтобы вы понимали - среднее потребление на семейную пару без детей с газовым отоплением обычно не превышает 1400 кубометров в год. В итоге вместо 89 евро нам было предложено платить 184 евро в месяц. Про корректирующий счет размером в 1095 евро даже говорить не хочу.
Сказать, что я тогда о**ел, значит ничего не сказать. Когда я начал выяснять это с хозяином и риэлтором, начался тот же игнор, что и обычно, и я пошел на форум русских эмигрантов.
На форуме мне сказали, что я сам себе злобный буратино, но если я уверен на 10000000%, что дело в бойлере, то дело можно будет решить только через суд, да и вообще я должен был сам следить за этим. Писать письма не имеет смысла, нужно доставать всех звонками чуть ли не каждый день, зазывать хозяина в квартиру и наглядно демонстрировать проблему, а также угрожать неуплатой аренды.
Баталия с риэлтором и хозяином продолжалась неделю, я с пеной у рта показывал фотографии, присланные ранее, требовал отчеты о данных счетчика (которых внезапно не было), утверждал что свидетельства инженеров о нормально функционирующем бойлере полная ложь.
Риэлтор вчера написал, что у нас все нормально с бойлером, мы просто сами потратили и вообще "у вас жена дома сидела год, вот и нажгла".
После такого пассажа я решил получить юр консультицацию, и с сожалением узнал, что если я не смогу доказать что бойлер действительно сломан (а он как назло работает прекрасно сейчас), то дело я проиграю с вероятностью в 99.999999%, поскольку нет убедительных доказательств, что бойлер действительтно не фукнционировал нормально последние 5 месяцев.
К чему я все это рассказываю? За год я изучил очень много о жизни в Нидерландах, и как здесь принято работать, в том числе и с людьми, но вот основные уроки:
- риэлторы - всегда пидорасты
- хозяин - всегда пидораст
- снимайте квартиру с включенной коммуналкой
- читайте отзывы о риэлторах, прежде чем общаться с ними
- письма, пусть и являются письменным подтверждением жалобы, никогда не работают
- отправляйте данные счетчиков каждый месяц
- в Нидерландах каждая скотина попытается забрать ваши деньги при любой возможности, но сделает что угодно, лишь бы их не возместить
- идея для стартапа - камера айфона с тепловизором (чтобы можно на камеру зафиксировать горячий радиатор)
Дело не в том, что по возвращению из отпуска я, как и многие другие, долго вхожу в рабочий ритм, и даже не в том, что за последний месяц я не столкнулся ни с чем интересным, о чем хотел бы рассказать на канале.
Канал не только о работе с машинами, но и работе с людьми, и именно о людях я сегодня и расскажу.
Жизнь в Нидерландах для экспата всегда начинается с арендованного жилья, и здесь, к счастью, процесс построен довольно гладко. Есть арендодатель, арендатор и между ними риэлторская фирма, занимающаяся всеми техническими и организационными вопросами.
В Нидерах вы можете снять квартиру на любой вкус и бюджет, временную или постоянную, с мебелью или пустую, а также в включенными в аренду коммунальными расходами или без.
Гоняясь за дешевой стоимостью аренды, мы сняли квартиру с мебелью, но без коммуналки, а значит расходы на газ, воду и электричество были на нас.
В апреле этого года мы обнаружили проблему с отоплением, когда батареи нагревались вне зависимости от температуры на термостате. Об этой проблеме мы сообщили риэлтору, и началась долгая вакханалия, в которой было все: игнорирование наших жалоб риэлтором, мастеры без необходимых инструментов, миллионы писем и звонков.
Так продолжалось пока мы не уехали в отпуск, перед чем я отправил данные счетчиков в газовую компанию для расчета потребления.
Вот тут-то и начался адок.
Согласно данным газовой компании наше потребление газа составило чуть меньше 3000 кубометров газа. Чтобы вы понимали - среднее потребление на семейную пару без детей с газовым отоплением обычно не превышает 1400 кубометров в год. В итоге вместо 89 евро нам было предложено платить 184 евро в месяц. Про корректирующий счет размером в 1095 евро даже говорить не хочу.
Сказать, что я тогда о**ел, значит ничего не сказать. Когда я начал выяснять это с хозяином и риэлтором, начался тот же игнор, что и обычно, и я пошел на форум русских эмигрантов.
На форуме мне сказали, что я сам себе злобный буратино, но если я уверен на 10000000%, что дело в бойлере, то дело можно будет решить только через суд, да и вообще я должен был сам следить за этим. Писать письма не имеет смысла, нужно доставать всех звонками чуть ли не каждый день, зазывать хозяина в квартиру и наглядно демонстрировать проблему, а также угрожать неуплатой аренды.
Баталия с риэлтором и хозяином продолжалась неделю, я с пеной у рта показывал фотографии, присланные ранее, требовал отчеты о данных счетчика (которых внезапно не было), утверждал что свидетельства инженеров о нормально функционирующем бойлере полная ложь.
Риэлтор вчера написал, что у нас все нормально с бойлером, мы просто сами потратили и вообще "у вас жена дома сидела год, вот и нажгла".
После такого пассажа я решил получить юр консультицацию, и с сожалением узнал, что если я не смогу доказать что бойлер действительно сломан (а он как назло работает прекрасно сейчас), то дело я проиграю с вероятностью в 99.999999%, поскольку нет убедительных доказательств, что бойлер действительтно не фукнционировал нормально последние 5 месяцев.
К чему я все это рассказываю? За год я изучил очень много о жизни в Нидерландах, и как здесь принято работать, в том числе и с людьми, но вот основные уроки:
- риэлторы - всегда пидорасты
- хозяин - всегда пидораст
- снимайте квартиру с включенной коммуналкой
- читайте отзывы о риэлторах, прежде чем общаться с ними
- письма, пусть и являются письменным подтверждением жалобы, никогда не работают
- отправляйте данные счетчиков каждый месяц
- в Нидерландах каждая скотина попытается забрать ваши деньги при любой возможности, но сделает что угодно, лишь бы их не возместить
- идея для стартапа - камера айфона с тепловизором (чтобы можно на камеру зафиксировать горячий радиатор)
Вот бывает такое, когда ты чувствуешь себя абсолютно некомпетентым существом. Глядишь на профили Линкдина коллег, проекты, над которыми они работают, да даже технологии, которые все вокруг знают, а ты ни сном, ни духом.
В такие моменты случается то, что я называю профессиональной депрессией. И на работу ехать не хочется, над сторонним проектом тоже трудиться не хочется (хотя очень и очень надо), да и вообще - лежать бы целыми днями на кровати, да смотреть 7-ой сезон Американской истории ужасов.
А потом ты, сидя над задачей об которую вторую неделю зубы ломаешь, видишь вокруг беготню и шум.
DHCP лежит, половина серверов недоступна, кругом паника, сетевики на пару с инфраструктурщиками мучают железки.
А потом ты присоединяешься к SRE'шникам (Инженерам доступности сервисов), находишь косяк в инфраструктурном коде за 5 минут, чинишь, и все счастливы.
Вот это называется "маленькая победоносная война".
В такие моменты случается то, что я называю профессиональной депрессией. И на работу ехать не хочется, над сторонним проектом тоже трудиться не хочется (хотя очень и очень надо), да и вообще - лежать бы целыми днями на кровати, да смотреть 7-ой сезон Американской истории ужасов.
А потом ты, сидя над задачей об которую вторую неделю зубы ломаешь, видишь вокруг беготню и шум.
DHCP лежит, половина серверов недоступна, кругом паника, сетевики на пару с инфраструктурщиками мучают железки.
А потом ты присоединяешься к SRE'шникам (Инженерам доступности сервисов), находишь косяк в инфраструктурном коде за 5 минут, чинишь, и все счастливы.
Вот это называется "маленькая победоносная война".
👍1
Твое лицо, когда ты нашел и решил проблему, над которой бились 4 человек с опытом 15+ лет.
А почитайте лютую историю о том, как из-за программной ошибки в штатах 6 часов не работала телефонная служба 911, и какой урок мы должны из этого извлечь: https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/
The Atlantic
The Coming Software Apocalypse
A small group of programmers wants to change how we code—before catastrophe strikes.
Ну, теперь о хакатонах.
Мероприятие это крайне занимательное и веселое. Обычно собирается несколько десятков комманд, выезжает со своим оборудованием в специально выделенное место (будь то офис, загородный отель или даже стрипклуб (https://habrahabr.ru/post/317128/)) и работает над индивидуальными проектами от 24 до 48 часов.
Я не зря сказал, что именно часов, а не дней. Идея хакатона - создать с нуля проект различной сложности (от идеи на бумажке до минимально работающего продукта) за 2 суток максимум. Это означает, что группе разрабов и инженеров нужно запастись энергетиками (или другими стимуляторами), потому что сна или перерыва на обед не предусмотрено.
В основном хакатоны это своего рода тимбилдинги, где люди разных профессий, экспертиз и взглядов на жизнь дружно работают над чем-то одним. Для чего же это нужно? Зачем человек идет заниматься работой в свободное от работы время?
Тут на руку играет задротские (прошу прощения за моветон) привычки большинства инженеров и разработчиков. Видите ли, львиная доля программистов получает удовольствие от процесса написания программ. Более того, из-за плохих коммуникативных навыков далеко не каждый инженер может вывести свою "идею" на рассмотрение продукт оунером или проджект менеджером. Так что хакатон для них своего рода отдушина. Пришел и неотрывно пишешь то, что хочешь ты и твои единомышленники. Это крайне позитивно влияет на лояльность организации и профессии.
Что касается меня, в этом году я буду разрабатывать веб приложение "Оно сломалось!" на моем любимом Питоне.
Мероприятие это крайне занимательное и веселое. Обычно собирается несколько десятков комманд, выезжает со своим оборудованием в специально выделенное место (будь то офис, загородный отель или даже стрипклуб (https://habrahabr.ru/post/317128/)) и работает над индивидуальными проектами от 24 до 48 часов.
Я не зря сказал, что именно часов, а не дней. Идея хакатона - создать с нуля проект различной сложности (от идеи на бумажке до минимально работающего продукта) за 2 суток максимум. Это означает, что группе разрабов и инженеров нужно запастись энергетиками (или другими стимуляторами), потому что сна или перерыва на обед не предусмотрено.
В основном хакатоны это своего рода тимбилдинги, где люди разных профессий, экспертиз и взглядов на жизнь дружно работают над чем-то одним. Для чего же это нужно? Зачем человек идет заниматься работой в свободное от работы время?
Тут на руку играет задротские (прошу прощения за моветон) привычки большинства инженеров и разработчиков. Видите ли, львиная доля программистов получает удовольствие от процесса написания программ. Более того, из-за плохих коммуникативных навыков далеко не каждый инженер может вывести свою "идею" на рассмотрение продукт оунером или проджект менеджером. Так что хакатон для них своего рода отдушина. Пришел и неотрывно пишешь то, что хочешь ты и твои единомышленники. Это крайне позитивно влияет на лояльность организации и профессии.
Что касается меня, в этом году я буду разрабатывать веб приложение "Оно сломалось!" на моем любимом Питоне.
Хабр
Зачем проводить хакатон в стриптиз-клубе?
Предупреждаю на берегу: мопед хакатон не мой. Но я его буду вести и организовывать логистику! Как и для многих десятков хакатонов до этого. В посте я хочу расск...
Расскажу о такой прикольной штуке, как SLA - Service Level Agreement.
Раньше SLA это был такой документ, в котором указывалась ответственность поддерживающей стороны. Взять к примеру SLA по базам данных, который я и готовил. Внутри документа были перечислены критерии "нормального" состояния приложения, возможные проблемы и два временных отрезка: reaction time и resolution time. Время на реакцию означало максимальное количество времени, пока инженер, сломя голову не побежит к компьютеру и не примется за ремонт; resolution же обозначал максимальное время на решение проблемы.
Были типовые проблемы, например, отказ БД. Поскольку у нас имелась резервная площадка и робот контроллер, проверяющий состояние всех систем, время на реакцию было 5 минут, а также 10 минут на «решение» - робот сам переключал приложение на работу с резервной базой.
Были и нетиповые проблемы, такие как проседание производительности. Вот обычный кейс - банк проводит закрытие операционного дня. Максимально допустимое время на это - полчаса. Если по каким-то причинам времени требовалось больше, нужно было садиться вместе с разработчиками и дружно ковыряться в коде приложения и структуре таблиц. На такого рода проблемы я выставлял от недели до трех.
Сейчас понятие SLA упростили донельзя (хотя в классическом ITIL используют тот же принцип, что и ранее) и его теперь обозначают в процентах.
Проще говоря, SLA это какой процент времени в году (с точностью до секунд) приложение или сервис работают бесперебойно.
То есть SLA в 99.9% означает, что приложение будет лежать не больше, чем 9 часов в году.
Звучит не так уж много, но представьте себе, какие издержки понесет Valve, если Steam - крупнейшая в мире система цифровой дистрибьюции - будет лежать 9 часов. Даже раз в году.
Про всякие Twitch, Google или Яндекс.ру я вообще молчу.
Раньше SLA это был такой документ, в котором указывалась ответственность поддерживающей стороны. Взять к примеру SLA по базам данных, который я и готовил. Внутри документа были перечислены критерии "нормального" состояния приложения, возможные проблемы и два временных отрезка: reaction time и resolution time. Время на реакцию означало максимальное количество времени, пока инженер, сломя голову не побежит к компьютеру и не примется за ремонт; resolution же обозначал максимальное время на решение проблемы.
Были типовые проблемы, например, отказ БД. Поскольку у нас имелась резервная площадка и робот контроллер, проверяющий состояние всех систем, время на реакцию было 5 минут, а также 10 минут на «решение» - робот сам переключал приложение на работу с резервной базой.
Были и нетиповые проблемы, такие как проседание производительности. Вот обычный кейс - банк проводит закрытие операционного дня. Максимально допустимое время на это - полчаса. Если по каким-то причинам времени требовалось больше, нужно было садиться вместе с разработчиками и дружно ковыряться в коде приложения и структуре таблиц. На такого рода проблемы я выставлял от недели до трех.
Сейчас понятие SLA упростили донельзя (хотя в классическом ITIL используют тот же принцип, что и ранее) и его теперь обозначают в процентах.
Проще говоря, SLA это какой процент времени в году (с точностью до секунд) приложение или сервис работают бесперебойно.
То есть SLA в 99.9% означает, что приложение будет лежать не больше, чем 9 часов в году.
Звучит не так уж много, но представьте себе, какие издержки понесет Valve, если Steam - крупнейшая в мире система цифровой дистрибьюции - будет лежать 9 часов. Даже раз в году.
Про всякие Twitch, Google или Яндекс.ру я вообще молчу.
Поэтому любая компания стремиться увеличить SLA хотя бы до 99.99% (не больше часу в год) - хотя это все еще плохо.
Крупные и мощные поставщики услуг, например Amazon Web Services, торжественно заявляют, что их сеть доставки контента (если интересно что это - пишите на ящик, расскажу) имеет SLA 99.999% (5 минут в год). Слабо верится, если честно.
А вот Google иллюзий не питает и на свою почту гарантирует SLA в выше упомянутые 99.99%.
Кстати, если увидите где-либо 100% SLA - гоните таких маркетологов в шею, это недостижимая величина (об этом я тоже расскажу).
Позже расскажу про uptime и partial uptime, и как их считать.
Крупные и мощные поставщики услуг, например Amazon Web Services, торжественно заявляют, что их сеть доставки контента (если интересно что это - пишите на ящик, расскажу) имеет SLA 99.999% (5 минут в год). Слабо верится, если честно.
А вот Google иллюзий не питает и на свою почту гарантирует SLA в выше упомянутые 99.99%.
Кстати, если увидите где-либо 100% SLA - гоните таких маркетологов в шею, это недостижимая величина (об этом я тоже расскажу).
Позже расскажу про uptime и partial uptime, и как их считать.
По поводу uptime есть следующие моменты.
Во-первых, собственно, сам uptime. Когда считается, что сайт, продукт или сервис сломан?
Некоторые считают, что сайт лежит, если на него нельзя попасть. Подход это неправильный и вот почему.
Допустим у вас есть интернет-магазин плюшевых котят. Сам сайт у вас работает, пользователь может зайти на него, но вот незадача - он не может оформить заказ. Или ему не приходит электронное письмо с подтверждением заказа. Или, что еще хуже, заказ оформлен, деньги уплочены, а вот заказ в CRM не появился, и доставка не будет произведена.
Дабы избежать таких разборок, толковые ребята в эксплуатации указывают в SLA что является сбоем и разделают общий uptime (сайт работает) и частичный uptime (все компоненты работают).
С таким подходом реализуется мониторинг всех движущих частей, и каждая команда инженеров отвечает конкретно за свой кусок.
SLA считается соответственно для общего и частичного uptime.
Вообще наука эта очень интересная, люди до сих пор спорят между собой по теме «что понимается под «все работает».
Что же до нас, то мы дошли до такого с внедрением микросервисной архитектуры, где программа состоит из множества маленьких блоков, каждый из которых мониторится и управляется разными группами.
Во-первых, собственно, сам uptime. Когда считается, что сайт, продукт или сервис сломан?
Некоторые считают, что сайт лежит, если на него нельзя попасть. Подход это неправильный и вот почему.
Допустим у вас есть интернет-магазин плюшевых котят. Сам сайт у вас работает, пользователь может зайти на него, но вот незадача - он не может оформить заказ. Или ему не приходит электронное письмо с подтверждением заказа. Или, что еще хуже, заказ оформлен, деньги уплочены, а вот заказ в CRM не появился, и доставка не будет произведена.
Дабы избежать таких разборок, толковые ребята в эксплуатации указывают в SLA что является сбоем и разделают общий uptime (сайт работает) и частичный uptime (все компоненты работают).
С таким подходом реализуется мониторинг всех движущих частей, и каждая команда инженеров отвечает конкретно за свой кусок.
SLA считается соответственно для общего и частичного uptime.
Вообще наука эта очень интересная, люди до сих пор спорят между собой по теме «что понимается под «все работает».
Что же до нас, то мы дошли до такого с внедрением микросервисной архитектуры, где программа состоит из множества маленьких блоков, каждый из которых мониторится и управляется разными группами.
Мы приехали на место проведение хакатона. Место, скажу сразу, может оскорбить религиозные чувства. Голландцы особо не чураются вести бизнес где возможно, и в загородном отеле, где мы расположились, раньше были кельи монахов. Картина маслом: религиозная символика, книги, теологическая литература, Библии, Иисус, будто с осуждением смотрящий на курящих во дворе, куча людей с ноутбуками.
Мы взяли на себя довольно простой проект, 3 микросервиса. Задача: заходишь на сайт, нажимаешь на картинку того, что на твой взгляд сломано, при достижении определенного количества кликов (100 человек не может ошибаться), ответственные команды получают сообщение в Slack. Я предлагал сделать что-то посерьезнее, например создавать тикеты в хелпдеск ситеме или в баг-трекере, на что Меттью, капитан нашего пятиместного кораблика, сказал: "Мы здесь, чтобы развлекаться и пить пиво."
И в этом есть смысл. Около часу ночи я отправился на боковую, в основном зале люди продолжали программировать, обсуждать архитектуру и собирать инфраструктуру их наколеночных проектов.
Мы же, проявив инженерную сознательность на старте, уже через пару часов смеялись, играли в Exploding Kittens и Cards Agains Humanity (уморительно чернушная игра, я вам скажу) и пили пиво.
Уже к 19 часам наш проект был готов на 70%. Сегодня нам разве что остается написать бота, который будет писать в Slack.
Мораль проста: не парься, и все получится.
Мы взяли на себя довольно простой проект, 3 микросервиса. Задача: заходишь на сайт, нажимаешь на картинку того, что на твой взгляд сломано, при достижении определенного количества кликов (100 человек не может ошибаться), ответственные команды получают сообщение в Slack. Я предлагал сделать что-то посерьезнее, например создавать тикеты в хелпдеск ситеме или в баг-трекере, на что Меттью, капитан нашего пятиместного кораблика, сказал: "Мы здесь, чтобы развлекаться и пить пиво."
И в этом есть смысл. Около часу ночи я отправился на боковую, в основном зале люди продолжали программировать, обсуждать архитектуру и собирать инфраструктуру их наколеночных проектов.
Мы же, проявив инженерную сознательность на старте, уже через пару часов смеялись, играли в Exploding Kittens и Cards Agains Humanity (уморительно чернушная игра, я вам скажу) и пили пиво.
Уже к 19 часам наш проект был готов на 70%. Сегодня нам разве что остается написать бота, который будет писать в Slack.
Мораль проста: не парься, и все получится.
Самое приятное в хакатонах это, конечно, свобода действий. Нас было 5 человек, 2 инженера и 3 разраба. Разрабы написали вебсервис, собирающий метрики, быстро, буквально за полчаса. Я и Меттью же занимались веб разработкой: html, css и javascript.
Это крайне увлекательно, перейти на "ту" сторону баррикад и побыть в шкуре разработчика. Когда мы закончили с веб интерфейсом, дело было за малым - научить бота в Slack обновлять состояние систем по сообщению: 15 минут, чистый Python, и работа была сделана.
Отличительной чертой хакатона также является непредвзятость коллег по отношению друг к другу. Неважно какие проблемы мы испытываем по отношению друг к другу в ежедневной работе - сейчас мы все друзья и работаем над одной задачей.
В результате разработчики .net ковырялись с нами в HTML верстке, а мы помогали им вычленять нужные IP адреса внутри Docker контейнеров, чтобы сервисы могли коммуницировать между собой.
Когда мы паковали свои вещи, один из разработчиков положил руку мне на плечо и сказал: "Это было честью работать с тобой на этом проекте, надеюсь мы вновь встретимся в следующем году."
В ноябре я буду 7 лет в ИТ индустрии и наслушался всякого (и комплиментов, и критики), но это самые приятные слова, которые мне говорили за все время.
Это крайне увлекательно, перейти на "ту" сторону баррикад и побыть в шкуре разработчика. Когда мы закончили с веб интерфейсом, дело было за малым - научить бота в Slack обновлять состояние систем по сообщению: 15 минут, чистый Python, и работа была сделана.
Отличительной чертой хакатона также является непредвзятость коллег по отношению друг к другу. Неважно какие проблемы мы испытываем по отношению друг к другу в ежедневной работе - сейчас мы все друзья и работаем над одной задачей.
В результате разработчики .net ковырялись с нами в HTML верстке, а мы помогали им вычленять нужные IP адреса внутри Docker контейнеров, чтобы сервисы могли коммуницировать между собой.
Когда мы паковали свои вещи, один из разработчиков положил руку мне на плечо и сказал: "Это было честью работать с тобой на этом проекте, надеюсь мы вновь встретимся в следующем году."
В ноябре я буду 7 лет в ИТ индустрии и наслушался всякого (и комплиментов, и критики), но это самые приятные слова, которые мне говорили за все время.
👍1
Кстати, ребятки, небольшая новость. Авторов у канала теперь целых не один, а два, поэтому ждите новый контент.
И напоследок про хакатоны. Финальный этап - демо.
Те, кто из вас присутствовал на ИТ конференциях, не раз видели стенды от разработчиков и вендоров, посвященные их продуктам. Демо после хакатона это нечто похожее: из подручных средств необходимо соорудить стенд (обычно в качестве подручных средств выступают рабочие ноутбуки, мониторы и распечатки презентаций), а затем 2 часа без устали рассказывать о том, как конкретно ваш продукт полезен в решении поставленной цели, и до чего же он крут, сами потрогайте!
На этот раз у нас было порядка 10-12 стендов, и посетители делали большой круг, обходя каждый из них. Когда доходили до нашего, кто-то из команды выпрыгивал с радостным "Do you want to hear about our product?" и начинал рассказывать. Каждому посетителю, снова и снова.
Мы сменяли друг друга, кому-то было душно, кому-то надо было поработать, кто-то сбегал на перекур, но я помню, как я оттарабанил один и тот же рассказ не менее чем 50 раз.
Я отнюдь не завидую маркетологам и сейлзам, которые ездят на конференции в качестве представителей фирм. За два часа я ужасно устал говорить, а что уж думать про ребят, которые занимаются этим весь день...
Самое интересное, конечно, было после демо, когда я с парнями потягивал пиво, вытирая пот со лба, и один из наших спросил: "Ну и что теперь? Мы запустим это в продакшон?".
Ха ха ха.
Печально в хакатонах то, что ни один продукт, не смотря на свою полезность, в итоге не выкатывается в промышленное использование. Лучшее что можно сделать с проектом - выложить его на Github, чтобы было чем похвастаться.
Но все равно это было круто и весело.
Те, кто из вас присутствовал на ИТ конференциях, не раз видели стенды от разработчиков и вендоров, посвященные их продуктам. Демо после хакатона это нечто похожее: из подручных средств необходимо соорудить стенд (обычно в качестве подручных средств выступают рабочие ноутбуки, мониторы и распечатки презентаций), а затем 2 часа без устали рассказывать о том, как конкретно ваш продукт полезен в решении поставленной цели, и до чего же он крут, сами потрогайте!
На этот раз у нас было порядка 10-12 стендов, и посетители делали большой круг, обходя каждый из них. Когда доходили до нашего, кто-то из команды выпрыгивал с радостным "Do you want to hear about our product?" и начинал рассказывать. Каждому посетителю, снова и снова.
Мы сменяли друг друга, кому-то было душно, кому-то надо было поработать, кто-то сбегал на перекур, но я помню, как я оттарабанил один и тот же рассказ не менее чем 50 раз.
Я отнюдь не завидую маркетологам и сейлзам, которые ездят на конференции в качестве представителей фирм. За два часа я ужасно устал говорить, а что уж думать про ребят, которые занимаются этим весь день...
Самое интересное, конечно, было после демо, когда я с парнями потягивал пиво, вытирая пот со лба, и один из наших спросил: "Ну и что теперь? Мы запустим это в продакшон?".
Ха ха ха.
Печально в хакатонах то, что ни один продукт, не смотря на свою полезность, в итоге не выкатывается в промышленное использование. Лучшее что можно сделать с проектом - выложить его на Github, чтобы было чем похвастаться.
Но все равно это было круто и весело.
Не раз уже напоминал об этом, но если у кого-то из вас есть интересные идеи, вопросы или пожелания, смело пишите.
Даже не на почту (согласен, это дико неудобно), а прямо в Телеграм - @ThomasStorm
Даже не на почту (согласен, это дико неудобно), а прямо в Телеграм - @ThomasStorm
Разработка программного обеспечения - занятие крайне медитативное. Вы надеваете закрытые наушники, включаете любимую музыку и принимаетесь за работу.
В то же время разработка процесс непрерывный. Вы написали приложение, которое делает что-то конкретно одно, потому что вы любите минимализм и весь из себя такой unix way. Вскоре вы переписываете свое приложение, и далек не потому, что оно вам внезапно не нравится. Потому что требования новые.
Несколько недель назад я работал с парнем-из-гугла, чтобы автоматизировать бизнес-процесс под названием "Подпись договора о ноутбуке".
Ранее, когда сотрудник получал ноутбук, он подписывал бумажку на которой значились данные по ноутбуку, его цена и ответственность сотрудника. Бумага сканировалась ИТшниками, отправлялась кадровикам. Кадровики вручную загружали скан договора с HR систему. Бумага отправлялась в шредер.
Крайне неэффективно, не правда ли?
Так вот я и парень-из-гугла написали 3-компонентую систему:
- Скрипт на Groovy, которые отправляет кастомное письмо с ссылкой на форму цифровой подписи
- Google Script приложение, которое собирает данные и генерирует контракт с цифровой подписью
- Python скрипт, которые забирает контракт, загружает его в HR систему и меняет статус тикета в Сервисдеске.
Затем началось веселье:
- А давайте брать данные по оборудованию из CMDB, а не забивать их вручную!
- А еще подпилим приложение, чтобы оно не валилось от ASCII несовместимых символов!
- А можно копию контракта по почте отправлять?
- А что делать с людьми, если они поженились и сменили фамилию? Может будем искать не по имени, а по идентификатору сотрудника?
Честно говоря, я порой думаю, что нужно было отказаться от этого и продолжить использовать бумагу.
Мало того, люди так сильно хотят ноутбук, что им его выдают до того, как отработает цифровая подпись.
Как сказал классик: "Компьютеризация бардака превращает его в компьютеризированный бардак."
В то же время разработка процесс непрерывный. Вы написали приложение, которое делает что-то конкретно одно, потому что вы любите минимализм и весь из себя такой unix way. Вскоре вы переписываете свое приложение, и далек не потому, что оно вам внезапно не нравится. Потому что требования новые.
Несколько недель назад я работал с парнем-из-гугла, чтобы автоматизировать бизнес-процесс под названием "Подпись договора о ноутбуке".
Ранее, когда сотрудник получал ноутбук, он подписывал бумажку на которой значились данные по ноутбуку, его цена и ответственность сотрудника. Бумага сканировалась ИТшниками, отправлялась кадровикам. Кадровики вручную загружали скан договора с HR систему. Бумага отправлялась в шредер.
Крайне неэффективно, не правда ли?
Так вот я и парень-из-гугла написали 3-компонентую систему:
- Скрипт на Groovy, которые отправляет кастомное письмо с ссылкой на форму цифровой подписи
- Google Script приложение, которое собирает данные и генерирует контракт с цифровой подписью
- Python скрипт, которые забирает контракт, загружает его в HR систему и меняет статус тикета в Сервисдеске.
Затем началось веселье:
- А давайте брать данные по оборудованию из CMDB, а не забивать их вручную!
- А еще подпилим приложение, чтобы оно не валилось от ASCII несовместимых символов!
- А можно копию контракта по почте отправлять?
- А что делать с людьми, если они поженились и сменили фамилию? Может будем искать не по имени, а по идентификатору сотрудника?
Честно говоря, я порой думаю, что нужно было отказаться от этого и продолжить использовать бумагу.
Мало того, люди так сильно хотят ноутбук, что им его выдают до того, как отработает цифровая подпись.
Как сказал классик: "Компьютеризация бардака превращает его в компьютеризированный бардак."
Сегодня утром написала сестра. Пока она ехала в электричке, какой-то мужик продавал книгу собственного авторства о том, как пользоваться даркнетом.
В те времена, когда я ездил в подмосковных электричках, мне предлагали только книжки, как пользоваться интернетом, чтобы качать музыки и сериальчики.
Эх, смена поколений... 🙁
В те времена, когда я ездил в подмосковных электричках, мне предлагали только книжки, как пользоваться интернетом, чтобы качать музыки и сериальчики.
Эх, смена поколений... 🙁
Ребзя, канал не умер! Просто я был очень и очень занят.
У меня есть 2 новости.
Первая: наш мамкин стартап в лице робота-криптотрейдера из зачаточного состояние вырос в такую себе машину по зарабатыванию денег. Предстоит еще много чего сделать, но фундамент заложен.
Кому интересны цифры - https://stats.gsmg.io
Кому интересно пообщаться с нами и нашей маленькой коммьюнити - https://join.slack.com/t/gsmg-platform/shared_invite/enQtMjcxNzQyOTYzNjIxLWMzMGEwNDQ2ZDZiMTRmMjY5OGUxZTkzMjlkYzY4MzhjNzlmZjA5MDA1MGRlOTA5MmVhNmY5NWEyOTliNDgyZTE
Если заходите по ссылке из канала, так и говорите, я вас узнаю. 😉
А по второй новости особо рассказать ничего не могу, но если вкратце - скоро будет больше интересного контента, технологий, баек и практик, поскольку я совершил небольшой личностный апгрейд и буду работать над более серьезными вещами.
У меня есть 2 новости.
Первая: наш мамкин стартап в лице робота-криптотрейдера из зачаточного состояние вырос в такую себе машину по зарабатыванию денег. Предстоит еще много чего сделать, но фундамент заложен.
Кому интересны цифры - https://stats.gsmg.io
Кому интересно пообщаться с нами и нашей маленькой коммьюнити - https://join.slack.com/t/gsmg-platform/shared_invite/enQtMjcxNzQyOTYzNjIxLWMzMGEwNDQ2ZDZiMTRmMjY5OGUxZTkzMjlkYzY4MzhjNzlmZjA5MDA1MGRlOTA5MmVhNmY5NWEyOTliNDgyZTE
Если заходите по ссылке из канала, так и говорите, я вас узнаю. 😉
А по второй новости особо рассказать ничего не могу, но если вкратце - скоро будет больше интересного контента, технологий, баек и практик, поскольку я совершил небольшой личностный апгрейд и буду работать над более серьезными вещами.
🔥1
Иногда, когда я решаю какую-то сложную задачу, я люблю крикнуть: "Я есть Тьма!" (не вслух разумеется, а только в чатах.)
Поскольку я работаю преимущественно с нидерландцами, то иногда я пишу: "Ik ben Duisternis!"
Fun факт - Dusternis переводится как тьма или темнота. Но стоит опечататься и перепутать расположение букв t и s, то получается Duitsernis, что дословно означает "надгробье для немцев".
Даже не знаю, что круче. 🤔
Поскольку я работаю преимущественно с нидерландцами, то иногда я пишу: "Ik ben Duisternis!"
Fun факт - Dusternis переводится как тьма или темнота. Но стоит опечататься и перепутать расположение букв t и s, то получается Duitsernis, что дословно означает "надгробье для немцев".
Даже не знаю, что круче. 🤔
Касательно недавних новостей, тут все прозаично - с нового года я выхожу на новую работу и буду не абы кем, а Cloud Architect.
Причины, по которым я искал и нашел новую работу, оставим за скобками.
Сегодня я бы хотел вам рассказать о том, почему нидерландские (именно нидерландские) инженеры - плохие. Но об этом чуть позже сегодня.
А пока я расскажу про штуку, которая меня дико раздражает.
Среди ИТ сообщества любят часто шутить на тему Линукса, как чего-то непонятного, что ты обязан собирать сам.
Как инженер с уже 7-летним опытом хочу развеять эти идиотские сомнения.
Видите ли, в мире серверных операционных систем доминируют лишь две группы: ОС семейства Микрософт (Windows Server со всеми вытекающими и новыми версиями) и так называемые *nix-подобные системы.
Если в плане Микрософта у вас есть только Windows, то никс-подобных систем великое множество - от различных дистрибутивов Линукса, до монстров типа FreeBSD и HP-UX.
Я не буду вдаваться в подробности архитектурных особенностей двух главных конкурентов, но вот главное отличие: Windows готов к работе из коробки и позволяет вам развернуть на нем различное ПО (от веб-серверов и серверов БД до системы удаленных рабочих столов и прочих прелестей).
Линукс же приходит к вам в виде конструктора. Сам Линукс это лишь ядро, kernel, из которого различные вендоры, от HP и IBM до Яндекса и RedHat, разрабатывают свои вариации Линукса.
Это абсолютно не значит, что вам нужно отращивать бороду, надевать столетний свитер и искать шаманский бубен.
Чтобы установить Линукс на компьютер, сервер или виртуальную машину, нужно всего-лишь обладать базовым пониманием работы компьютеров и операционных систем.
С другой стороны Линукс предоставляет огромный набор возможностей по кастомизации операционной системы. Вы можете отключать ненужные модули ядра (например модуль звука или 3D графики - зачем они вам на сервере?), ставить свои ограничения по количество одновременно запущенных процессов или выставлять им приоритезацию ресурсов - это лишь верхушка айсберга из того, что мне приходилось с Линуксом делать.
Про то, что все модные системы виртуализации (кроме Микрософтовского Hyper-V) разрабатывались по философии и логике Линукса, я вообще молчу.
Поэтому, если кто-то из инженеров или программистов реагирует на Линукс идиотским смехом и предлагает пропатчить KDE2 или собирать программу "из сырцов" - я перестаю воспринимать этого человека всерьез.
Причины, по которым я искал и нашел новую работу, оставим за скобками.
Сегодня я бы хотел вам рассказать о том, почему нидерландские (именно нидерландские) инженеры - плохие. Но об этом чуть позже сегодня.
А пока я расскажу про штуку, которая меня дико раздражает.
Среди ИТ сообщества любят часто шутить на тему Линукса, как чего-то непонятного, что ты обязан собирать сам.
Как инженер с уже 7-летним опытом хочу развеять эти идиотские сомнения.
Видите ли, в мире серверных операционных систем доминируют лишь две группы: ОС семейства Микрософт (Windows Server со всеми вытекающими и новыми версиями) и так называемые *nix-подобные системы.
Если в плане Микрософта у вас есть только Windows, то никс-подобных систем великое множество - от различных дистрибутивов Линукса, до монстров типа FreeBSD и HP-UX.
Я не буду вдаваться в подробности архитектурных особенностей двух главных конкурентов, но вот главное отличие: Windows готов к работе из коробки и позволяет вам развернуть на нем различное ПО (от веб-серверов и серверов БД до системы удаленных рабочих столов и прочих прелестей).
Линукс же приходит к вам в виде конструктора. Сам Линукс это лишь ядро, kernel, из которого различные вендоры, от HP и IBM до Яндекса и RedHat, разрабатывают свои вариации Линукса.
Это абсолютно не значит, что вам нужно отращивать бороду, надевать столетний свитер и искать шаманский бубен.
Чтобы установить Линукс на компьютер, сервер или виртуальную машину, нужно всего-лишь обладать базовым пониманием работы компьютеров и операционных систем.
С другой стороны Линукс предоставляет огромный набор возможностей по кастомизации операционной системы. Вы можете отключать ненужные модули ядра (например модуль звука или 3D графики - зачем они вам на сервере?), ставить свои ограничения по количество одновременно запущенных процессов или выставлять им приоритезацию ресурсов - это лишь верхушка айсберга из того, что мне приходилось с Линуксом делать.
Про то, что все модные системы виртуализации (кроме Микрософтовского Hyper-V) разрабатывались по философии и логике Линукса, я вообще молчу.
Поэтому, если кто-то из инженеров или программистов реагирует на Линукс идиотским смехом и предлагает пропатчить KDE2 или собирать программу "из сырцов" - я перестаю воспринимать этого человека всерьез.