Байка
Знаете какой самый потрясающий пример байк-шеддинга я видел?
Это случилось ещё до популяризации термина "байк-шеддинг". Однажды 6 человек - 4 программиста и 2 менеджера собрались на уютном созвоне и 2 часа кряду обсуждали вопрос вселенской важности:
"На каком языке писать комментарии в коде?"
Двое программистов сразу сказали что им пофиг, и они будут делать так, как им скажут - у них нет предпочтений, а поэтому они посидят да послушают. Остальные четверо ожесточённо спорили всё оставшееся время, кидаясь друг в друга аргументами, метриками, ожиданиями, представлением о прекрасном и логикой.
Чем же мне так запомнился этот случай? Да тем, что по итогу было принято решение писать комментарии-таки на английском языке. В коде русского продукта. Разрабатываемого для российского рынка. Российской компанией с российскими разработчиками.
Вообще говоря, никто из участников встречи толком английского не знал и говорить на нём не умел. Потому что это было не нужно.
Но решение принято. А значит надо. Только помимо работы ещё пришлось исправлять в комментариях тупейшие грамматические ошибки в духе "I can haz cheezburger". Просто чтобы избавиться от испанского стыда.
Такие дела
Знаете какой самый потрясающий пример байк-шеддинга я видел?
Это случилось ещё до популяризации термина "байк-шеддинг". Однажды 6 человек - 4 программиста и 2 менеджера собрались на уютном созвоне и 2 часа кряду обсуждали вопрос вселенской важности:
"На каком языке писать комментарии в коде?"
Двое программистов сразу сказали что им пофиг, и они будут делать так, как им скажут - у них нет предпочтений, а поэтому они посидят да послушают. Остальные четверо ожесточённо спорили всё оставшееся время, кидаясь друг в друга аргументами, метриками, ожиданиями, представлением о прекрасном и логикой.
Чем же мне так запомнился этот случай? Да тем, что по итогу было принято решение писать комментарии-таки на английском языке. В коде русского продукта. Разрабатываемого для российского рынка. Российской компанией с российскими разработчиками.
Вообще говоря, никто из участников встречи толком английского не знал и говорить на нём не умел. Потому что это было не нужно.
Но решение принято. А значит надо. Только помимо работы ещё пришлось исправлять в комментариях тупейшие грамматические ошибки в духе "I can haz cheezburger". Просто чтобы избавиться от испанского стыда.
Такие дела
Планета в порядке!
На мой извращённый вкус, одно из самых интересных занятий современности - наблюдать как технологии изменили коммуникационные паттерны людей.
Наши привычки в общении, само понимание другого человека, та самая "новая искренность" когда мы все на виду и надо вести себя по-другому. Как же всё-таки нас повлияли технологии!
...
Да, блджд, никак не повлияли. Люди всегда были в массе своей недалёкими, нелюбопытными и ленивыми, как оперативно нам сообщает Пушкин Александр Сергеич. Так же у людей всегда были амбиции, обида, жажда власти, букеты комплексов, нереалистичные ожидания, подвластность стадному эффекту, желание внимания к себе, подростковый максимализм.
Что действительно сделали технологии - поставили нас перед зеркалом. Смотри, мол, человечество - у тебя в руках огроменные вычислительные мощности, а ты их используешь чтобы мемы с котиками смотреть? "Ну ты троглодит!" (с) Магазинчик Бо
В общем, обломались по ходу прекраснодушные фантасты, писавшие нечто в духе "потомки будут гораздо умнее нас, на другом уровне будут мыслить, перестанут воевать, просветлятся". Обломался и я, придя в индустрию потому что "вот тут люди зарабатывают большие деньги своими мозгами - стало быть много умных людей". По менеджменту IT-компаний заметно, что ум (энциклопедические знания) прекрасно совмещаются с детскими иллюзиями о прекрасной окружающей реальности.
Потому чтознают думают что баблишка много и оно всегда будет тут крутиться (в горизонте человеческой жизни).
Кстати поэтому и не работает коммунизм, пародией на который наша индустрия и является (но это предмет отдельной заметки). Люди, собаки такие! Всё никак не хотят становиться мирными-спокойными-договороспособными-высокоморальными и работать по велению сердца. А норовят то полениться, то поумничать, то к власти по головам идут.
Что ж, глупо обвинять человека в следовании своим инстинктам. И уж тем более глупо переубеждать nouveau communiste что это всё плохо заканчивается. Поэтому лично я с этим ничего делать не буду.
И ждёт нас всех не технокоммунизм, а самый настоящий киберпанк: хай тек, лоу лайф - все дела. Ну и гори оно синим пламенем: кажется, нам всем нужен урок.
Такие дела.
На мой извращённый вкус, одно из самых интересных занятий современности - наблюдать как технологии изменили коммуникационные паттерны людей.
Наши привычки в общении, само понимание другого человека, та самая "новая искренность" когда мы все на виду и надо вести себя по-другому. Как же всё-таки нас повлияли технологии!
...
Да, блджд, никак не повлияли. Люди всегда были в массе своей недалёкими, нелюбопытными и ленивыми, как оперативно нам сообщает Пушкин Александр Сергеич. Так же у людей всегда были амбиции, обида, жажда власти, букеты комплексов, нереалистичные ожидания, подвластность стадному эффекту, желание внимания к себе, подростковый максимализм.
Что действительно сделали технологии - поставили нас перед зеркалом. Смотри, мол, человечество - у тебя в руках огроменные вычислительные мощности, а ты их используешь чтобы мемы с котиками смотреть? "Ну ты троглодит!" (с) Магазинчик Бо
В общем, обломались по ходу прекраснодушные фантасты, писавшие нечто в духе "потомки будут гораздо умнее нас, на другом уровне будут мыслить, перестанут воевать, просветлятся". Обломался и я, придя в индустрию потому что "вот тут люди зарабатывают большие деньги своими мозгами - стало быть много умных людей". По менеджменту IT-компаний заметно, что ум (энциклопедические знания) прекрасно совмещаются с детскими иллюзиями о прекрасной окружающей реальности.
Потому что
Кстати поэтому и не работает коммунизм, пародией на который наша индустрия и является (но это предмет отдельной заметки). Люди, собаки такие! Всё никак не хотят становиться мирными-спокойными-договороспособными-высокоморальными и работать по велению сердца. А норовят то полениться, то поумничать, то к власти по головам идут.
Что ж, глупо обвинять человека в следовании своим инстинктам. И уж тем более глупо переубеждать nouveau communiste что это всё плохо заканчивается. Поэтому лично я с этим ничего делать не буду.
И ждёт нас всех не технокоммунизм, а самый настоящий киберпанк: хай тек, лоу лайф - все дела. Ну и гори оно синим пламенем: кажется, нам всем нужен урок.
Такие дела.
YouTube
Магазинчик Бо. Эпизод 24. Крем материализации
Есть в этой серии смысл и есть забавные стёбы, но вот вцелом довольно странная концепция. Есть некоторые серии, типа этой, которые я сам не совсем осмыслил прежде чем сочинить. Пишешь на интуиции- в результате получается интересно и самому. Кстати, очень…
IT-панк
В концепции IT-панка, высказанной недавно Никитой Колмогоровым, знаете, есть рациональное зерно.
Оглянитесь вокруг: IT-индустрия это адок. Компании наобум пробуют всякие новомодные-хайповые штуки вроде ажайла, кубернетиса или же REST-а. Какой-то существенной отдачи от них не чувствуется, а бюрократию они повышают. Если бы это было не так, то Фила Ранжина как социального явления бы не появилось. Бюрократия, будь она трижды во имя стабилизации успеха, порождает мириады бестолковых ритуалов. Некоторые из них мы оправдываем через "это коммьюнити-прувен", про некоторые говорим - "о, это же сами авторы ажайл-методологии придумали", иные через "ой вот так в умной книжке написано". Чуете? Чуете уже какую-то религиозность в этом всём, да?
А чего только стоят ритуалы, навязанные SJW, позитивным мышлением и эффективными продажами, ммм: "тренируй софт-скиллы", "нельзя быть токсичным", "надо уважать пол и национальность людей, не взирая на их квалификацию". И ладно бы это была проблема-в-себе.
Мы дожили до точки, когда карго-культ этой чуши превратил индустрию в унылое говно в целом. Ритуалы заставляют корчиться в овертаймах (потому что встречи!) и выдавать в результате совершенно неюзабельное говно. Оно устаревает спустя пару месяцев и живёт только на ИВЛ из покупного трафика, да легаси-пользователей, которые поставили софт себе и теперьиспользуют его страдают по привычке. Прямо как в старом-добром СССР!
А вот бюрократия как раз может существовать сама по себе. Никакой внешний потребитель ей совершенно не нужен. Например, чтобы проводить многочасовые встречи ни о чём (но отчитаться "мы провели встречу") не нужны пользователи. Не нужны они и для самозабвенного покрытия кода юнит-тестами во славу KPI. И для бесконечного рефакторинга, написания и авто-генерации документации. Так же не нужны пользователи переезде с AWS в Azure, с Azure на свой датацентр, со своего датацентра снова в AWS. И для перевода инфраструктуры на куберодокеры с развешиванием прометеуса по всем углам пользователи тоже совершенно не нужны.
Ало, ну мы ж инженеры! Мы знаем как софт работает и на что действительно способны современные машины. Кому как ни нам провести пользователя в мир прекрасного? Кому как ни нам дать пользователю инструменты, раз и навсегда избавляющие его от боли и рутины? От бюрократии и человеческого фактора. От долгих ожиданий и окон, зависающих в самый неподходящий момент.
Только мы не можем. Мы сами погрязли по самые уши в самой отвратной бюрократии на пустом месте, человеческом факторе, тоннах согласований и тулингах, которые всё медленнее с каждым релизом.
Только в нашей индустрии есть закон Брукса: "Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше".
Да даже панком-то на таком фоне быть не надо. Достаточно просто профилактики буллшита и бюрократии, посылать в пизду best practices, делать то, что стабильно работает и выходить к пользователю напрямую с конкретным решением конкретной проблемы (а не носиться-искать инвестиции под очередной трешак). Звучит как конкурентное преимущество! Даже никакая теория от Колмогорова не понадобится.
Но такие развлечения, видимо, просто не для всех. Кое-какие хорошие практики и правила в индустрии всё же есть и если ты нарушаешь их просто чтобы нарушить - то это называется "нало маме отморожу уши". Путь к тру-панку лежит через понимание всего ужаса ситуации, в которой мы оказались. А для этого придётся научиться видеть суть. Не модные баззворды и пену технологических хайпов, а суть. Суть того, как работают технологии, суть пользовательских проблем. Суть решений, которые предлагают конкуренты. Суть всего. И только вникнув в неё, наконец, можно возвыситься над хаосом и увидеть пути решений.
Печально только одно, на мой взгляд. Я, как человек определённо ухвативший суть - могу свести её к простой и ужасной по своей сути максиме: "с технологиями всё в порядке. Просто люди - мудаки". Но буду рад, если кто-нибудь меня разубедит.
Такие дела.
В концепции IT-панка, высказанной недавно Никитой Колмогоровым, знаете, есть рациональное зерно.
Оглянитесь вокруг: IT-индустрия это адок. Компании наобум пробуют всякие новомодные-хайповые штуки вроде ажайла, кубернетиса или же REST-а. Какой-то существенной отдачи от них не чувствуется, а бюрократию они повышают. Если бы это было не так, то Фила Ранжина как социального явления бы не появилось. Бюрократия, будь она трижды во имя стабилизации успеха, порождает мириады бестолковых ритуалов. Некоторые из них мы оправдываем через "это коммьюнити-прувен", про некоторые говорим - "о, это же сами авторы ажайл-методологии придумали", иные через "ой вот так в умной книжке написано". Чуете? Чуете уже какую-то религиозность в этом всём, да?
А чего только стоят ритуалы, навязанные SJW, позитивным мышлением и эффективными продажами, ммм: "тренируй софт-скиллы", "нельзя быть токсичным", "надо уважать пол и национальность людей, не взирая на их квалификацию". И ладно бы это была проблема-в-себе.
Мы дожили до точки, когда карго-культ этой чуши превратил индустрию в унылое говно в целом. Ритуалы заставляют корчиться в овертаймах (потому что встречи!) и выдавать в результате совершенно неюзабельное говно. Оно устаревает спустя пару месяцев и живёт только на ИВЛ из покупного трафика, да легаси-пользователей, которые поставили софт себе и теперь
А вот бюрократия как раз может существовать сама по себе. Никакой внешний потребитель ей совершенно не нужен. Например, чтобы проводить многочасовые встречи ни о чём (но отчитаться "мы провели встречу") не нужны пользователи. Не нужны они и для самозабвенного покрытия кода юнит-тестами во славу KPI. И для бесконечного рефакторинга, написания и авто-генерации документации. Так же не нужны пользователи переезде с AWS в Azure, с Azure на свой датацентр, со своего датацентра снова в AWS. И для перевода инфраструктуры на куберодокеры с развешиванием прометеуса по всем углам пользователи тоже совершенно не нужны.
Ало, ну мы ж инженеры! Мы знаем как софт работает и на что действительно способны современные машины. Кому как ни нам провести пользователя в мир прекрасного? Кому как ни нам дать пользователю инструменты, раз и навсегда избавляющие его от боли и рутины? От бюрократии и человеческого фактора. От долгих ожиданий и окон, зависающих в самый неподходящий момент.
Только мы не можем. Мы сами погрязли по самые уши в самой отвратной бюрократии на пустом месте, человеческом факторе, тоннах согласований и тулингах, которые всё медленнее с каждым релизом.
Только в нашей индустрии есть закон Брукса: "Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше".
Да даже панком-то на таком фоне быть не надо. Достаточно просто профилактики буллшита и бюрократии, посылать в пизду best practices, делать то, что стабильно работает и выходить к пользователю напрямую с конкретным решением конкретной проблемы (а не носиться-искать инвестиции под очередной трешак). Звучит как конкурентное преимущество! Даже никакая теория от Колмогорова не понадобится.
Но такие развлечения, видимо, просто не для всех. Кое-какие хорошие практики и правила в индустрии всё же есть и если ты нарушаешь их просто чтобы нарушить - то это называется "нало маме отморожу уши". Путь к тру-панку лежит через понимание всего ужаса ситуации, в которой мы оказались. А для этого придётся научиться видеть суть. Не модные баззворды и пену технологических хайпов, а суть. Суть того, как работают технологии, суть пользовательских проблем. Суть решений, которые предлагают конкуренты. Суть всего. И только вникнув в неё, наконец, можно возвыситься над хаосом и увидеть пути решений.
Печально только одно, на мой взгляд. Я, как человек определённо ухвативший суть - могу свести её к простой и ужасной по своей сути максиме: "с технологиями всё в порядке. Просто люди - мудаки". Но буду рад, если кто-нибудь меня разубедит.
Такие дела.
Нищета
Оправдать существование всего IT может один примечательный факт: очень многих людей индустрия буквально вытащила из нищеты.
Сидит Петя в Усть-Урюпинске. За плечами у него Усть-Урюпинский политех. И светит Пете в лучшем случае токарный станок советских времён на полуразваленном заводе, да чекушка водки после работы. Но тут Пете подворачиваются курсы погроммирования на питухоне/жабаскрипте. Петя тратит на них копеечку, сэкономленную на пиве, покупает б/у ноут, въезжает в материал и спустя какое-то время находит себе новую работу, которая поднимает его из сабпрайма прямиком в средний класс. Петя достиг успеха, имеет шестизначную зарплату, ипотека закрыта, шуба жене куплена, автокредит платится. Красота, жизнь состоялась, все пьют.
У меня к этому двоякое отношение.
С одной стороны у меня профессиональный бугурт по отношению к таким людям. Университетов они не кончали, над стрёмными задачками на многопоточность по ночам перед сессией не сидели, кэширующий proxy на сях не писали, CPU-рейтресинга на крестах не нюхали... Господи, мальчики, да вы кто такие? Идите-ка вы поучитесь годик-другой! Вам же не объяснишь тривиальное архитектурное решение! Вы ж ничего не умеете кроме как пакеты из npm качать!
Да-да, звучит это как сраная дедовская обидка а-ля "я страдал и вы страдайте!". Однако же, необходимый теорминимум Computer Science никто не отменял. Работать с людьми, не имеющими представления о базовых алгоритмах и структурах данных - сложно. Будь моя воля - я бы их на пушечный выстрел не подпустил к принятию решений. Пусть вон, тикеты разгребают. Ребят, извините, но правда. Я очень вас уважаю, но мы не сработаемся потому что у нас с вами разное представление об "очевидном".
А дальше происходит вот какая штука. Джуны с онлайн-курсов попадают на рабочие места, растут, набираются опыта и через какое-то время их повышают. И иногда - повышают до позиций, предусматривающих найм персонала. То есть вчерашние выходцы с курсов, не писавшие merge sort-а руками начинают собесить людей исходя из своих представлений о прекрасном. Привет двухчасовые собесы с галочками по списку, привет круглые люки, привет очередной веб-чатик в неоплачиваемом тестовом.
Короче, веду я к тому что люди без чёткого знания основ выстраивают процесс собеседования под найм себе же подобных.
При том профессионалов с крепким теоретическим фундаментом и опытом они отсеивают. Сортировки, хэшмапы и обход деревьев - видится им - ни хрена не имеют отношения к их повседневной работе. Мысль, что даже один человек с крепкой головой, поставленный на соответствующую должность может принести/сэкономить им кучу бабла - не посещает их светлые головы.
Теперь возвысимся над хаосом и увидим полную картину: через эти ворота невежества любую организацию рано или поздно заполняют недоучки, вытесняя своей массой всех плюс-минус адекватных сотрудников. Диды неожиданно узнают что они - диды, становятся "токсичными" и "не умеющими работать в команде". Как итог - FAANG получает вкрай заебавшегося профессионала и укрепляет свою доминацию на рынке, а джунпарк - отсутствие токсичности и командную работу. Софт, правда, при этом получается говёный и пользователи не рады, но кому какое до них дело, правда?
Забавно, что примерно то же самое произошло в своё время с КПСС.
С другой стороны, подъём из нищеты - это прекрасно. Это - лучшее, что случалось с людьми из пост-СНГ. IT-индустрия для многих - спасательная шлюпка от бесперспективности, бедности и русской хтони. Впервые за сотню лет рынок предоставил жителю России возможность жить как нормальный человек, а не как подзаборная псина. И ничто не может убедить меня в обратном.
Как мне кажется, подружить эти два мира можно через взаимопонимание. Поэтому я предлагаю пришедшим с курсов относиться с чуть большим уважением к профильным профессионалам, а профильным профессионалам вкладывать больше понимания к работу с выпускниками курсов. И вместе мы сможем обрести счастье и вытащить индустрию из говна.
Такие дела.
Оправдать существование всего IT может один примечательный факт: очень многих людей индустрия буквально вытащила из нищеты.
Сидит Петя в Усть-Урюпинске. За плечами у него Усть-Урюпинский политех. И светит Пете в лучшем случае токарный станок советских времён на полуразваленном заводе, да чекушка водки после работы. Но тут Пете подворачиваются курсы погроммирования на питухоне/жабаскрипте. Петя тратит на них копеечку, сэкономленную на пиве, покупает б/у ноут, въезжает в материал и спустя какое-то время находит себе новую работу, которая поднимает его из сабпрайма прямиком в средний класс. Петя достиг успеха, имеет шестизначную зарплату, ипотека закрыта, шуба жене куплена, автокредит платится. Красота, жизнь состоялась, все пьют.
У меня к этому двоякое отношение.
С одной стороны у меня профессиональный бугурт по отношению к таким людям. Университетов они не кончали, над стрёмными задачками на многопоточность по ночам перед сессией не сидели, кэширующий proxy на сях не писали, CPU-рейтресинга на крестах не нюхали... Господи, мальчики, да вы кто такие? Идите-ка вы поучитесь годик-другой! Вам же не объяснишь тривиальное архитектурное решение! Вы ж ничего не умеете кроме как пакеты из npm качать!
Да-да, звучит это как сраная дедовская обидка а-ля "я страдал и вы страдайте!". Однако же, необходимый теорминимум Computer Science никто не отменял. Работать с людьми, не имеющими представления о базовых алгоритмах и структурах данных - сложно. Будь моя воля - я бы их на пушечный выстрел не подпустил к принятию решений. Пусть вон, тикеты разгребают. Ребят, извините, но правда. Я очень вас уважаю, но мы не сработаемся потому что у нас с вами разное представление об "очевидном".
А дальше происходит вот какая штука. Джуны с онлайн-курсов попадают на рабочие места, растут, набираются опыта и через какое-то время их повышают. И иногда - повышают до позиций, предусматривающих найм персонала. То есть вчерашние выходцы с курсов, не писавшие merge sort-а руками начинают собесить людей исходя из своих представлений о прекрасном. Привет двухчасовые собесы с галочками по списку, привет круглые люки, привет очередной веб-чатик в неоплачиваемом тестовом.
Короче, веду я к тому что люди без чёткого знания основ выстраивают процесс собеседования под найм себе же подобных.
При том профессионалов с крепким теоретическим фундаментом и опытом они отсеивают. Сортировки, хэшмапы и обход деревьев - видится им - ни хрена не имеют отношения к их повседневной работе. Мысль, что даже один человек с крепкой головой, поставленный на соответствующую должность может принести/сэкономить им кучу бабла - не посещает их светлые головы.
Теперь возвысимся над хаосом и увидим полную картину: через эти ворота невежества любую организацию рано или поздно заполняют недоучки, вытесняя своей массой всех плюс-минус адекватных сотрудников. Диды неожиданно узнают что они - диды, становятся "токсичными" и "не умеющими работать в команде". Как итог - FAANG получает вкрай заебавшегося профессионала и укрепляет свою доминацию на рынке, а джунпарк - отсутствие токсичности и командную работу. Софт, правда, при этом получается говёный и пользователи не рады, но кому какое до них дело, правда?
Забавно, что примерно то же самое произошло в своё время с КПСС.
С другой стороны, подъём из нищеты - это прекрасно. Это - лучшее, что случалось с людьми из пост-СНГ. IT-индустрия для многих - спасательная шлюпка от бесперспективности, бедности и русской хтони. Впервые за сотню лет рынок предоставил жителю России возможность жить как нормальный человек, а не как подзаборная псина. И ничто не может убедить меня в обратном.
Как мне кажется, подружить эти два мира можно через взаимопонимание. Поэтому я предлагаю пришедшим с курсов относиться с чуть большим уважением к профильным профессионалам, а профильным профессионалам вкладывать больше понимания к работу с выпускниками курсов. И вместе мы сможем обрести счастье и вытащить индустрию из говна.
Такие дела.
Почему нельзя обсуждать зарплаты
Ну очевидно же. Начнётся же вот эта вся херня, когда сениор Слава мнит себя б-гом на основании того, что он получает ажно на два десятка тысяч больше чем мидл Женя. У нас разработчики итак ходят важные, как гуси потому что получают кратно больше, нежели врачи и учителя. А если ещё и обсуждение зарплат поощрять - то совсем начнётся ярмарка понтов. Все забьют на работу и будут соревноваться в количестве бэх.
Будь моя воля - я бы всей стране запретил обсуждать с айтишниками их зарплаты.
Я серьёзно.
Ну очевидно же. Начнётся же вот эта вся херня, когда сениор Слава мнит себя б-гом на основании того, что он получает ажно на два десятка тысяч больше чем мидл Женя. У нас разработчики итак ходят важные, как гуси потому что получают кратно больше, нежели врачи и учителя. А если ещё и обсуждение зарплат поощрять - то совсем начнётся ярмарка понтов. Все забьют на работу и будут соревноваться в количестве бэх.
Будь моя воля - я бы всей стране запретил обсуждать с айтишниками их зарплаты.
Я серьёзно.
Опыт
Что должен знать хороший разраб? Ну так, навскидку... Алгоритмы и структуры данных, сетевые протоколы, многопоточность. Иметь опыт работы с несколькими разноплановыми базами данных, потыкать палочкой хайлоад, всласть надрочиться с UI-ем, потаскаться по встречам и познать хтонь и ужас промышленного управления проектами. Совсем хорошо - пописать какую-нибудь гадость для девайсин. Ну датчики там, USB - вот это всё. Ардуринку в конце концов заиметь.
Увидеть геймдев и выгореть.
Называйте это "сеньор-помидор", если угодно.
Если проходить на Ultra-Violence с бустом в виде профильного высшего образования, да клювом не щёлкать - всей этой развлекухи хватает лет на 10.
На 15, если особо не напрягаться.
На 20, если ты совсем тумбочка.
А дальше упираешься в потолок. Это ты уже видел, вон в том ковырялся на какой-то из работ, этот вопрос на собесе тебе уже задавали, с похожим багом ты уже сталкивался, а про этот протокол что-то читал на хабре. Можно набить себе статов на всяких хакерранках и литкодах, но делать это просто не интересно. Можно подготовиться к интервью и устроиться в FAANG, но лень заморачиваться. Работаешь за 300 кк/сек на пиндосов по удалёнке в родном городе-герое Усть-Хтоньске и думаешь куда дальше. Cнисходительно улыбаешься при виде пункта "интересные задачи" в вакансиях, а одухотворённые неофиты, познающие мир разработки ПО кажутся тебе назойливыми белками-истеричками. Холивары перестают радовать, предпочтения по технологиям исчезают: "методичку захватил? ну щас докурю и пойдём делать таску".
Я хочу сказать, что не смотря на напускную сложность, разработка ПО вовсе не так разнообразна и удивительна. Прокачивание технических скиллов вполне себе ограничено сверху. С какого-то момента качаться дальше просто бессмысленно - ничего нового не узнаешь. Стоило иметь это в виду с самого начала.
Такие дела.
Что должен знать хороший разраб? Ну так, навскидку... Алгоритмы и структуры данных, сетевые протоколы, многопоточность. Иметь опыт работы с несколькими разноплановыми базами данных, потыкать палочкой хайлоад, всласть надрочиться с UI-ем, потаскаться по встречам и познать хтонь и ужас промышленного управления проектами. Совсем хорошо - пописать какую-нибудь гадость для девайсин. Ну датчики там, USB - вот это всё. Ардуринку в конце концов заиметь.
Увидеть геймдев и выгореть.
Называйте это "сеньор-помидор", если угодно.
Если проходить на Ultra-Violence с бустом в виде профильного высшего образования, да клювом не щёлкать - всей этой развлекухи хватает лет на 10.
На 15, если особо не напрягаться.
На 20, если ты совсем тумбочка.
А дальше упираешься в потолок. Это ты уже видел, вон в том ковырялся на какой-то из работ, этот вопрос на собесе тебе уже задавали, с похожим багом ты уже сталкивался, а про этот протокол что-то читал на хабре. Можно набить себе статов на всяких хакерранках и литкодах, но делать это просто не интересно. Можно подготовиться к интервью и устроиться в FAANG, но лень заморачиваться. Работаешь за 300 кк/сек на пиндосов по удалёнке в родном городе-герое Усть-Хтоньске и думаешь куда дальше. Cнисходительно улыбаешься при виде пункта "интересные задачи" в вакансиях, а одухотворённые неофиты, познающие мир разработки ПО кажутся тебе назойливыми белками-истеричками. Холивары перестают радовать, предпочтения по технологиям исчезают: "методичку захватил? ну щас докурю и пойдём делать таску".
Я хочу сказать, что не смотря на напускную сложность, разработка ПО вовсе не так разнообразна и удивительна. Прокачивание технических скиллов вполне себе ограничено сверху. С какого-то момента качаться дальше просто бессмысленно - ничего нового не узнаешь. Стоило иметь это в виду с самого начала.
Такие дела.
Сколько нужно программистов чтобы вкрутить лампочку?
Приходит коллега, говорит: "слушай, у нас там в одном месте ошибка, а ты там ковырялся недавно - оно не работает немного". Короче бажно код смерджился в стейджинг-бранч - надо поправить.
Коллега показывает на файл, а код там примерно такой, чтобы вы понимали:
Чекаут монорепы, бренч от стейджинга в TortoiseGit, 3 минуты на запуск Rider-а (я уже просто отдыхать собирался - в последний момент прилетело). Переставляю, проверяю что собирается (всегда проверяю перед коммитом). Коммит.
Теперь надо сделать Pull Request. Паблишу бренч, иду в трекер. Завожу тикет, в заголовке описываю проблему в двух словах. Проставляю служебные поля в духе "к какой части системы относится", "кем найдено", "в какой версии". CI не собирает если не привязать под-таску. Делаю под-таску с умными словами: "восстановить порядок выполнения кода в файле таком-то".
Создаю Pull Request, привязываю тикет и под-таску, ставлю auto-merge, кидаю ссылку коллеге чтобы зааппрувил. А тут у нас автоматизация - CI сразу же пошёл собирать версию. Удобно. Пока CI всё собирает - проставляю везде правильные статусы тасок. Через 5 минут в почту приходит уведомление "пайплайн упал, билд не собирается".
Иду на страницу CI, смотрю логи. Оказывается упала проверка на соответствие бренча (стейджинг) полю "будет починено в версии", которое проставляется в слинкованном с пулл-реквестом тикете.
Спрашиваю коллегу - а какая у нас нынче версия бренчу стейджинга соответствует? "3.6.8" отвечает коллега. Я смотрю в списке трекера - ха, нет такой версии в списке. Сообщаю коллеге.
Он говорит - "ну, делать нечего - докладывай менеджеру". Пишу менеджеру - "слушай, целевой версии для стейджинга в трекере нету. надо завести, а то у меня прав нет". Менеджер говорит "доступы есть у администратора - пиши ему". Пишу администратору: "дорогой мой человек, будь так добр добавить версию 3.6.8 в список в трекере, а то у меня CI не собирает".
Жду ответа 15 минут - ответа нет. Очевидно, человек на сегодня уже закончил. Докладываю менеджеру - мол - "убёг уже, видимо". Менеджер говорит - "пингану его, не беда".
Возвращаюсь к коллеге, сообщаю что скорее всего будет починено уже завтра.
———
Для вкручивания лампочки программисты сделают фреймворк с пошаговым контролем поворота из JSON-конфига, который автоматически будет запускать гидравлику, приставленную к каждому патрону, получив web-запрос от датчика, контролирующего разность потенциалов на спирали. Гидравлика будет вкручивать лампочку в течение часа с оптимальной скоростью.
Хорошо, что программисты не вкручивают лампочки.
Такие дела.
Приходит коллега, говорит: "слушай, у нас там в одном месте ошибка, а ты там ковырялся недавно - оно не работает немного". Короче бажно код смерджился в стейджинг-бранч - надо поправить.
Коллега показывает на файл, а код там примерно такой, чтобы вы понимали:
если (а) то {
делать(а);
}
если (б) то {
делать(б);
если (в) то {
делать(в); // очевидно что криво смерджилось
}
}
если (г) то {
делать(г);
}
Надо зайти, две строчки переставить. Приключение на 20 минут - зашли и вышли.Чекаут монорепы, бренч от стейджинга в TortoiseGit, 3 минуты на запуск Rider-а (я уже просто отдыхать собирался - в последний момент прилетело). Переставляю, проверяю что собирается (всегда проверяю перед коммитом). Коммит.
Теперь надо сделать Pull Request. Паблишу бренч, иду в трекер. Завожу тикет, в заголовке описываю проблему в двух словах. Проставляю служебные поля в духе "к какой части системы относится", "кем найдено", "в какой версии". CI не собирает если не привязать под-таску. Делаю под-таску с умными словами: "восстановить порядок выполнения кода в файле таком-то".
Создаю Pull Request, привязываю тикет и под-таску, ставлю auto-merge, кидаю ссылку коллеге чтобы зааппрувил. А тут у нас автоматизация - CI сразу же пошёл собирать версию. Удобно. Пока CI всё собирает - проставляю везде правильные статусы тасок. Через 5 минут в почту приходит уведомление "пайплайн упал, билд не собирается".
Иду на страницу CI, смотрю логи. Оказывается упала проверка на соответствие бренча (стейджинг) полю "будет починено в версии", которое проставляется в слинкованном с пулл-реквестом тикете.
Спрашиваю коллегу - а какая у нас нынче версия бренчу стейджинга соответствует? "3.6.8" отвечает коллега. Я смотрю в списке трекера - ха, нет такой версии в списке. Сообщаю коллеге.
Он говорит - "ну, делать нечего - докладывай менеджеру". Пишу менеджеру - "слушай, целевой версии для стейджинга в трекере нету. надо завести, а то у меня прав нет". Менеджер говорит "доступы есть у администратора - пиши ему". Пишу администратору: "дорогой мой человек, будь так добр добавить версию 3.6.8 в список в трекере, а то у меня CI не собирает".
Жду ответа 15 минут - ответа нет. Очевидно, человек на сегодня уже закончил. Докладываю менеджеру - мол - "убёг уже, видимо". Менеджер говорит - "пингану его, не беда".
Возвращаюсь к коллеге, сообщаю что скорее всего будет починено уже завтра.
———
Для вкручивания лампочки программисты сделают фреймворк с пошаговым контролем поворота из JSON-конфига, который автоматически будет запускать гидравлику, приставленную к каждому патрону, получив web-запрос от датчика, контролирующего разность потенциалов на спирали. Гидравлика будет вкручивать лампочку в течение часа с оптимальной скоростью.
Хорошо, что программисты не вкручивают лампочки.
Такие дела.
Внеочередной пост
Я всей душой не люблю Хованского. Юмор у него плоский, пошлый и невыносимо тупой. Так же считаю что жить в таком свинарнике лично мне было бы стыдно перед самим собой.
Но задержание человека "по подозрению в оправдании терроризма" — это совершенно дикая, тупая и скотская хуета, которой не должно существовать никогда, ни в одной стране. Вне зависимости от того, к кому это применяется.
Такие дела
Я всей душой не люблю Хованского. Юмор у него плоский, пошлый и невыносимо тупой. Так же считаю что жить в таком свинарнике лично мне было бы стыдно перед самим собой.
Но задержание человека "по подозрению в оправдании терроризма" — это совершенно дикая, тупая и скотская хуета, которой не должно существовать никогда, ни в одной стране. Вне зависимости от того, к кому это применяется.
Такие дела
Коллеги мне прислали бутылку водки
А история тут вот какая.
Эти засранцы прекрасно знают что я очень трепетно отношусь к своей работе. Поэтому первого апреля сего года подговорили нач. отдела написать на общий e-mail RnD письмо примерно следующего содержания: "Господа хорошие! Со следующей недели все доступы к корпоративным ресурсам — только через [очень медленный] VPN, требования к покрытию кода unit-тестами повышаются до 100%, а так же мы нанимаем 8 разработчиков из Индии. Обтекайте".
Я прочёл и меня прям передёрнуло: "Господи — думаю — мой работодатель сошёл с ума. Ну чего началось-то, нормально же общались!". Слово за слово я взял бутыль вискаря и напился вхлам.
Спустя полчаса мне в чат пишут коллеги: "Ты емейл видел?". "Видел" — говорю. "И как тебе?" — "Ну... — а у самого глаз дёргается — нормально наверное, с этим можно работать.". "С первым апреля, лол, мы тебя разыграли!".
Тут я не удержался и вылил в чат нашей команды голосовухами стройный поток залихвастского русского мата. А коллеги, из языков знающие только иврит и английский — довольны по самые помидоры, угорают надо мной и веселятся. Потом я ещё и в групповой емейл-аккаунт отписал что меня чуть удар не хватил от таких шуточек.
Вот они мне после того случая в удобный момент передали корпоративный презент. Бутыль неплохой водки (ну я ж русский, из Сибири, езжу на медведях и пью водку) с подписью: "сохранить до первого апреля следующего года".
Рабочая атмосфера супер. 10/10, всем рекомендую.
Такие дела.
А история тут вот какая.
Эти засранцы прекрасно знают что я очень трепетно отношусь к своей работе. Поэтому первого апреля сего года подговорили нач. отдела написать на общий e-mail RnD письмо примерно следующего содержания: "Господа хорошие! Со следующей недели все доступы к корпоративным ресурсам — только через [очень медленный] VPN, требования к покрытию кода unit-тестами повышаются до 100%, а так же мы нанимаем 8 разработчиков из Индии. Обтекайте".
Я прочёл и меня прям передёрнуло: "Господи — думаю — мой работодатель сошёл с ума. Ну чего началось-то, нормально же общались!". Слово за слово я взял бутыль вискаря и напился вхлам.
Спустя полчаса мне в чат пишут коллеги: "Ты емейл видел?". "Видел" — говорю. "И как тебе?" — "Ну... — а у самого глаз дёргается — нормально наверное, с этим можно работать.". "С первым апреля, лол, мы тебя разыграли!".
Тут я не удержался и вылил в чат нашей команды голосовухами стройный поток залихвастского русского мата. А коллеги, из языков знающие только иврит и английский — довольны по самые помидоры, угорают надо мной и веселятся. Потом я ещё и в групповой емейл-аккаунт отписал что меня чуть удар не хватил от таких шуточек.
Вот они мне после того случая в удобный момент передали корпоративный презент. Бутыль неплохой водки (ну я ж русский, из Сибири, езжу на медведях и пью водку) с подписью: "сохранить до первого апреля следующего года".
Рабочая атмосфера супер. 10/10, всем рекомендую.
Такие дела.
REST — говно
Ну к'мон, ребят, а то ж вы сами не видите что это натягивание совы на глобус.
Так, давайте ещё раз. Идея RESTful-а в чём? В том, чтобы иметь на каждую сущность набор HTTP-методов для работы с ним. Они не имеют состояния (в смысле что не держат сессию пользователя - так-то HTTP - это стейтлесс протокол), работают по возможности быстро и, как результат, хорошо линейно скейлятся. Прекрасное начинание, но чуваки, придумавшие REST явно хотели больше чем лавров Капитана Очевидность.
И дальше началась специальная олимпиада: REST определяет конвеншоны касательно вида URI и использования HTTP verb-ов. Не следовать им нельзя, потому что тогда "у вас не REST". Только эти конвеншоны неудобные, противоречивые и негибкие. Щас на примерах покажу.
Вот есть у нас товар (любимый пример в онлайн-туториалах). Делаю эндпоинт
А потом у товара появляется свойство "компания-производитель". И как дальше? Для компании-производителя мне заводить отдельный REST-эндпоинт, а в товаре возвращать Id компании? То есть мне чтобы достать товар с информацией о производителе - надо 2 запроса подряд делать? И что дальше - на каждую связь один-ко-многим - по одному запросу на сервер? На каждую сущность? Мне вам посчитать, или сами на калькуляторе перемножите? Я не хочу, чтобы клиент 2 часа подтягивал данные и DDoS-ил сервер!
Поехали дальше: А если у меня сложный и многокомпонентный запрос на поиск товаров? Типа "хочу всех квадратных плюшевых мишек дешевле пяти, но дороже двух тысяч, из букв названия которых можно сложить слово ЖОПА, с кожаной животом и динамиком, поющим Диму Билана при нажатии с возможность доставки по Усть-Хтоньску в ночное время но не позднее двух часов". 2048 символов квери-строки хватит всем, да? А иначе придётся складывать в JSON параметры поиска и посылать POST-ом, что в REST делать нельзя, потому что у нас же семаааантика.
А вот на сайте мы, скажем, отображаем список пользователей с именем, возрастом, аватаркой, краткой биографией, датой рождения и емейлом. А в мобильном приложении - просто аватаркой и именем. И что - и мобильное приложение и сайт должны при каждом запросе стягивать список пользователей со всеми доступными полями, да? А если там 150 полей, плюс вложенные? Канал-то сетевой не резиновый. Чтобы решить эту проблему по-умному - нужна система работы с проекциями. А тут или опять посылай запросы POST-ом с указанием нужной проекции (что уже не REST), или лепи 100500 эндпоинтов, возвращающих одни и те же данные в разных проекциях на разные случаи жизни.
Ну и всё равно останутся ещё и RPC-онли эндпоинты, которым ты будешь говорить что-то в духе "удали все товары старше 30 дней у вот этих компаний", а они тебе будут отвечать
И это не какие-то хитрые примеры с потолка. Вполне штатные ведь юскейсы.
А внимательный читатель уже давно заметил, что ни на состояние, ни на скалабилити эти конвеншоны никак не влияют. Это просто названия. Короче, опять решаем в какой цвет покрасить велосипедный сарай.
Остаётся дежурно напомнить, что даже такие мастодонты как CORBA, SOAP с WSDL, gRPC, WCF в .NET никого не спасли и всё ещё весьма проблематичны (или мертвы). А тут у нас налицо непродуманная, слабая, чудовищно медленная, но пышущая радикальным юношеским максимализмом концепция. Сделает ли она чью-либо жизнь лучше? Не думаю.
Такие дела.
P.S: Ах, да. Есть же GraphQL. Язык/протокол, натягивающийся на другие языки и протоколы, чтобы выставить базу данных во внешний мир и писать запросы на JSON вместо специализированного языка для запросов. Кринж на уровне идеи, извините.
Ну к'мон, ребят, а то ж вы сами не видите что это натягивание совы на глобус.
Так, давайте ещё раз. Идея RESTful-а в чём? В том, чтобы иметь на каждую сущность набор HTTP-методов для работы с ним. Они не имеют состояния (в смысле что не держат сессию пользователя - так-то HTTP - это стейтлесс протокол), работают по возможности быстро и, как результат, хорошо линейно скейлятся. Прекрасное начинание, но чуваки, придумавшие REST явно хотели больше чем лавров Капитана Очевидность.
И дальше началась специальная олимпиада: REST определяет конвеншоны касательно вида URI и использования HTTP verb-ов. Не следовать им нельзя, потому что тогда "у вас не REST". Только эти конвеншоны неудобные, противоречивые и негибкие. Щас на примерах покажу.
Вот есть у нас товар (любимый пример в онлайн-туториалах). Делаю эндпоинт
/api/good/XXX, вешаю на него verb-ы. Всё хорошо, даже коды HTTP правильные возвращаю. А потом у товара появляется свойство "компания-производитель". И как дальше? Для компании-производителя мне заводить отдельный REST-эндпоинт, а в товаре возвращать Id компании? То есть мне чтобы достать товар с информацией о производителе - надо 2 запроса подряд делать? И что дальше - на каждую связь один-ко-многим - по одному запросу на сервер? На каждую сущность? Мне вам посчитать, или сами на калькуляторе перемножите? Я не хочу, чтобы клиент 2 часа подтягивал данные и DDoS-ил сервер!
Поехали дальше: А если у меня сложный и многокомпонентный запрос на поиск товаров? Типа "хочу всех квадратных плюшевых мишек дешевле пяти, но дороже двух тысяч, из букв названия которых можно сложить слово ЖОПА, с кожаной животом и динамиком, поющим Диму Билана при нажатии с возможность доставки по Усть-Хтоньску в ночное время но не позднее двух часов". 2048 символов квери-строки хватит всем, да? А иначе придётся складывать в JSON параметры поиска и посылать POST-ом, что в REST делать нельзя, потому что у нас же семаааантика.
А вот на сайте мы, скажем, отображаем список пользователей с именем, возрастом, аватаркой, краткой биографией, датой рождения и емейлом. А в мобильном приложении - просто аватаркой и именем. И что - и мобильное приложение и сайт должны при каждом запросе стягивать список пользователей со всеми доступными полями, да? А если там 150 полей, плюс вложенные? Канал-то сетевой не резиновый. Чтобы решить эту проблему по-умному - нужна система работы с проекциями. А тут или опять посылай запросы POST-ом с указанием нужной проекции (что уже не REST), или лепи 100500 эндпоинтов, возвращающих одни и те же данные в разных проекциях на разные случаи жизни.
Ну и всё равно останутся ещё и RPC-онли эндпоинты, которым ты будешь говорить что-то в духе "удали все товары старше 30 дней у вот этих компаний", а они тебе будут отвечать
200 OK и количество удалённых товаров в JSON-е возвращать. REST-овики вообще говорят что это называется "RPC over HTTP" и типа этого вообще не должно быть. Прямо как в том анекдоте: "Доктор, слова нет а жопа есть", ага. Нет, а как иначе? Сначала запрашивать все товары старше 30 дней, получать список из 100500 штук и для каждого делать DELETE /api/good/XXX? Ну если так, то догадываюсь зачем нам столько скалабилити.И это не какие-то хитрые примеры с потолка. Вполне штатные ведь юскейсы.
А внимательный читатель уже давно заметил, что ни на состояние, ни на скалабилити эти конвеншоны никак не влияют. Это просто названия. Короче, опять решаем в какой цвет покрасить велосипедный сарай.
Остаётся дежурно напомнить, что даже такие мастодонты как CORBA, SOAP с WSDL, gRPC, WCF в .NET никого не спасли и всё ещё весьма проблематичны (или мертвы). А тут у нас налицо непродуманная, слабая, чудовищно медленная, но пышущая радикальным юношеским максимализмом концепция. Сделает ли она чью-либо жизнь лучше? Не думаю.
Такие дела.
P.S: Ах, да. Есть же GraphQL. Язык/протокол, натягивающийся на другие языки и протоколы, чтобы выставить базу данных во внешний мир и писать запросы на JSON вместо специализированного языка для запросов. Кринж на уровне идеи, извините.
Проповедь
Большинство наших приложений состоят из трёх основных частей: инфра, логика и UI. И разработчики из этих трёх разных областей сейчас ведут между собой холивары. Те, кто инфрой занимается — это DevOps, гошники, строители дата-пайплайнов, опытные пользователи БД и писатели интеграции CI с hashicorp vault. Те, кто занимается логикой — сейчас всё больше проповедует функциональное программирование, строгую типизацию, ран-тайм проверки и code coverage. Адепты UI-разработки преимущественно с горящими глазами рассказывают какой офигенный фронтенд, как на нём просто и быстро можно нафигачить и какой у ноды крутой тулинг — вон на нём даже сервера можно фигачить.
Остановитесь! Перестаньте воевать друг с другом. Неужели непонятно, что сделать хороший продукт на технологиях для какой-то одной части - невозможно?
Вы не соберёте хороший продукт на go, готовых контейнерах со всякой гадостью и кубернетисе. Начнёте писать логику на go — помрёте и перемешаете её с инфрой и закончите контейнерным монолитом. UI скорее всего будет набросан на коленке. А если у вас совсем тёмное прошлое за плечами — то будет у вас база данных и логика на stored-процедурах. Просто потому что вы их знаете и любите. Прямо как в той спорной истории с Lingualeo.
Не соберёте вы хороший продукт и на голом Haskell, потому что это скорее некая эзотерика будет, а не эффективно работающее бизнес-решение. Если такой продукт выстрелит, не дай б-же — будете потом носиться по всей стране и искать разработчиков себе в команду. Или, скажем, потонете в борьбе с производительностью Python-а на больших нагрузках. Tornado конечно держит 10к соединений, но nginx держит больше. А шаблонизатор django не даст вам спокойно сделать SPA, используя всю широту инструментов фронтенда.
Что касается .NET и Java — их, конечно, можно взять для полного стека. Однако же, из своего опыта скажу - их прям надо УМЕТЬ готовить чтобы было хорошо. Для Java — уметь настраивать виртуальную машину под потребление памяти, подбирать правильные фреймворки и немного программировать на XML. Для .NET — вовремя убежать от MS-овских облаков, отказаться от IIS и перейти на Core (который сравнительно свеж, а поэтому его может потряхивать при работе).
Ну и с однопоточным сервером на ноде, будем честны, вы тоже долго не протянете. CPU-bound операции вроде генерации excel-ничков и pdf-ничков заставят вас дебажить при высокой нагрузке, лепить эпические костыли и в итоге настраивать левой пяткой кубернетис. А если вы ещё и любитель динамической типизации, то бизнес-логикой себе все ноги отстрелите. Зато фронтенд будет весело свистеть и раскатисто пердеть.
Братья, давайте закончим бессмысленные войны, обнимемся и признаем что друг без друга мы мало что сделаем в реалиях современного IT. Мы решаем идеологически разные задачи и нет никакого смысла "логистам" троллить фронтендеров извечным "аааа когда банки переедут на джаваскрипт мы все умрём". Нет смысла гошникам троллить джавистов а-ля "а чё у вас аппликуха так медленно работает?". Нет смысла... (и тут я понял что не могу вспомнить как фронтендеры троллят инфраструктурщиков).
На самом деле я уже довольно давно считаю что всё в нашей профессии — инструмент. Он не может быть плохим или хорошим. Он может подходить под задачу, а может не подходить.
Давайте просто выбирать инструменты вдумчиво и правильно.
Такие дела.
Большинство наших приложений состоят из трёх основных частей: инфра, логика и UI. И разработчики из этих трёх разных областей сейчас ведут между собой холивары. Те, кто инфрой занимается — это DevOps, гошники, строители дата-пайплайнов, опытные пользователи БД и писатели интеграции CI с hashicorp vault. Те, кто занимается логикой — сейчас всё больше проповедует функциональное программирование, строгую типизацию, ран-тайм проверки и code coverage. Адепты UI-разработки преимущественно с горящими глазами рассказывают какой офигенный фронтенд, как на нём просто и быстро можно нафигачить и какой у ноды крутой тулинг — вон на нём даже сервера можно фигачить.
Остановитесь! Перестаньте воевать друг с другом. Неужели непонятно, что сделать хороший продукт на технологиях для какой-то одной части - невозможно?
Вы не соберёте хороший продукт на go, готовых контейнерах со всякой гадостью и кубернетисе. Начнёте писать логику на go — помрёте и перемешаете её с инфрой и закончите контейнерным монолитом. UI скорее всего будет набросан на коленке. А если у вас совсем тёмное прошлое за плечами — то будет у вас база данных и логика на stored-процедурах. Просто потому что вы их знаете и любите. Прямо как в той спорной истории с Lingualeo.
Не соберёте вы хороший продукт и на голом Haskell, потому что это скорее некая эзотерика будет, а не эффективно работающее бизнес-решение. Если такой продукт выстрелит, не дай б-же — будете потом носиться по всей стране и искать разработчиков себе в команду. Или, скажем, потонете в борьбе с производительностью Python-а на больших нагрузках. Tornado конечно держит 10к соединений, но nginx держит больше. А шаблонизатор django не даст вам спокойно сделать SPA, используя всю широту инструментов фронтенда.
Что касается .NET и Java — их, конечно, можно взять для полного стека. Однако же, из своего опыта скажу - их прям надо УМЕТЬ готовить чтобы было хорошо. Для Java — уметь настраивать виртуальную машину под потребление памяти, подбирать правильные фреймворки и немного программировать на XML. Для .NET — вовремя убежать от MS-овских облаков, отказаться от IIS и перейти на Core (который сравнительно свеж, а поэтому его может потряхивать при работе).
Ну и с однопоточным сервером на ноде, будем честны, вы тоже долго не протянете. CPU-bound операции вроде генерации excel-ничков и pdf-ничков заставят вас дебажить при высокой нагрузке, лепить эпические костыли и в итоге настраивать левой пяткой кубернетис. А если вы ещё и любитель динамической типизации, то бизнес-логикой себе все ноги отстрелите. Зато фронтенд будет весело свистеть и раскатисто пердеть.
Братья, давайте закончим бессмысленные войны, обнимемся и признаем что друг без друга мы мало что сделаем в реалиях современного IT. Мы решаем идеологически разные задачи и нет никакого смысла "логистам" троллить фронтендеров извечным "аааа когда банки переедут на джаваскрипт мы все умрём". Нет смысла гошникам троллить джавистов а-ля "а чё у вас аппликуха так медленно работает?". Нет смысла... (и тут я понял что не могу вспомнить как фронтендеры троллят инфраструктурщиков).
На самом деле я уже довольно давно считаю что всё в нашей профессии — инструмент. Он не может быть плохим или хорошим. Он может подходить под задачу, а может не подходить.
Давайте просто выбирать инструменты вдумчиво и правильно.
Такие дела.
Electron
Электрон не пинал только ленивый. И приложения на нём получаются тормозные, и огромный рантайм браузера он с собой тянет, и памяти жрёт - дай б-же. Да и крешится под собственной тяжестью время от времени. Это и без моей помощи обсуждают на каждом углу. А по сему, в этом посте я не стану раскачивать холивар, а просто поразмышляю вслух в спокойной обстановке.
И первое, чем хочу поделиться: самая идея делать десктопные приложения на HTML и Javascript не нова. Тут стоит немного поностальгировать.
Впервые я столкнулся с таких подходом к UI в 2010м году или около того. Тогда ещё, помнится, AOL начал войну против "неофициальных" клиентов ICQ. А я пользовался qip-ом 2005, потому что он быстрее всех обновлялся, оперативно накатывая фиксы чтобы подстроиться под меняющийся протокол AOL-а. Аська тогда порой вылетала чуть ли не каждые 10 минут и именно qip держал коннект стабильнее всего.
А потом вышел QIP Infium, и начал сильно-больно нагло тянуть пользователей на свой jabber-сервер, форсировать регистрацию на qip.ru и норовить сохранить пароли от мессенджеров в своё облако. Одно время я с удивлением обнаружил, что все статусы, которые я ставил в QIP собираются в публично-доступный микроблог на qip.ru, навроде твиттера. Меня о таком никто не предупредил, поэтому ощущения были неприятные. Я стал искать альтернативу.
Ещё до qip я недолго пользовался коретой (Kopete ICQ - да да, у меня когда-то стоял дебиан на основной машине с кедами). Ни рыба ни мясо. Зато неплох был консольный CenterICQ. Но это всё пришлось удолить когда встала необходимость снести линух и вернуться на винду.
После кипа у меня какое-то время стояла Miranda, которая меня в конец доканала бездной настроек при сомнительной стабильности и весьма убобрищным внешним видом. И в конце концов я всерьёз залип в... Trillian.
У него был необычный для тех времён внешний вид, приятный, не перегруженный (после миранды) интерфейс и мне стало интересно как он сделан. Я пошёл в директорию установки и с удивлением обнаружил что сам .exe-шник по сути создаёт окно и делает внутри себя браузер. Да не абы какой, а вполне себе IE. И далее через плюсовые биндинги общается с его JS-движком (WSH там внутри).
Сам же фронтенд лежал рядом кучкой HTML/CSS/JS. Я тогда ещё изрядно удивился - блин, как изворотливо. Неужели совсем у ребят с UI-погроммированием всё плохо? Но в целом инженерную задумку я оценил. Да и по UX там всё было без нареканий. Словом, впечатления остались тёплые. Эх, не знал я тогда что авторы Trillian на 10 лет опередели своё время.
Разумеется, Electron устроен иначе, у него внутри вроде как Blink и для JS используется V8. Как ни крути, а V8 по всем фронтам уделывает WSH. Хотя бы потому что это не JScript (было дело когда MS пытался зохавать поляну JavaScript, ехидно сообщая что это просто скриптинг для администрирования - PowerShell тогда ещё не планировался). Но сам подход изобрели уже давно.
И в таком подходе есть свои преимущества и недостатки. Если быть до конца честным, то я скорее против electron-way. Однако же, чисто как пользователю мне безумно вкатывают две вещи:
— Почти любой текст можно выделить и скопировать
— Почти все electron-приложения могут скейлить шрифт по Ctrl-колесо мыши.
Первое хорошо чтобы копировать всякие сообщения об ошибке или данные прямо из окна работающего приложения. А вот второе - это прям топ. У меня огромный 31-дюймовый монитор, сижу я от него далеко и дальнозоркостью не отличаюсь. Увеличение шрифта - фича, которой я пользуюсь, наверное, чаще всего.
Забавно, что даже в самой всратой технологии можно обнаружить свои плюсы, если постараться.
Такие дела.
Электрон не пинал только ленивый. И приложения на нём получаются тормозные, и огромный рантайм браузера он с собой тянет, и памяти жрёт - дай б-же. Да и крешится под собственной тяжестью время от времени. Это и без моей помощи обсуждают на каждом углу. А по сему, в этом посте я не стану раскачивать холивар, а просто поразмышляю вслух в спокойной обстановке.
И первое, чем хочу поделиться: самая идея делать десктопные приложения на HTML и Javascript не нова. Тут стоит немного поностальгировать.
Впервые я столкнулся с таких подходом к UI в 2010м году или около того. Тогда ещё, помнится, AOL начал войну против "неофициальных" клиентов ICQ. А я пользовался qip-ом 2005, потому что он быстрее всех обновлялся, оперативно накатывая фиксы чтобы подстроиться под меняющийся протокол AOL-а. Аська тогда порой вылетала чуть ли не каждые 10 минут и именно qip держал коннект стабильнее всего.
А потом вышел QIP Infium, и начал сильно-больно нагло тянуть пользователей на свой jabber-сервер, форсировать регистрацию на qip.ru и норовить сохранить пароли от мессенджеров в своё облако. Одно время я с удивлением обнаружил, что все статусы, которые я ставил в QIP собираются в публично-доступный микроблог на qip.ru, навроде твиттера. Меня о таком никто не предупредил, поэтому ощущения были неприятные. Я стал искать альтернативу.
Ещё до qip я недолго пользовался коретой (Kopete ICQ - да да, у меня когда-то стоял дебиан на основной машине с кедами). Ни рыба ни мясо. Зато неплох был консольный CenterICQ. Но это всё пришлось удолить когда встала необходимость снести линух и вернуться на винду.
После кипа у меня какое-то время стояла Miranda, которая меня в конец доканала бездной настроек при сомнительной стабильности и весьма убобрищным внешним видом. И в конце концов я всерьёз залип в... Trillian.
У него был необычный для тех времён внешний вид, приятный, не перегруженный (после миранды) интерфейс и мне стало интересно как он сделан. Я пошёл в директорию установки и с удивлением обнаружил что сам .exe-шник по сути создаёт окно и делает внутри себя браузер. Да не абы какой, а вполне себе IE. И далее через плюсовые биндинги общается с его JS-движком (WSH там внутри).
Сам же фронтенд лежал рядом кучкой HTML/CSS/JS. Я тогда ещё изрядно удивился - блин, как изворотливо. Неужели совсем у ребят с UI-погроммированием всё плохо? Но в целом инженерную задумку я оценил. Да и по UX там всё было без нареканий. Словом, впечатления остались тёплые. Эх, не знал я тогда что авторы Trillian на 10 лет опередели своё время.
Разумеется, Electron устроен иначе, у него внутри вроде как Blink и для JS используется V8. Как ни крути, а V8 по всем фронтам уделывает WSH. Хотя бы потому что это не JScript (было дело когда MS пытался зохавать поляну JavaScript, ехидно сообщая что это просто скриптинг для администрирования - PowerShell тогда ещё не планировался). Но сам подход изобрели уже давно.
И в таком подходе есть свои преимущества и недостатки. Если быть до конца честным, то я скорее против electron-way. Однако же, чисто как пользователю мне безумно вкатывают две вещи:
— Почти любой текст можно выделить и скопировать
— Почти все electron-приложения могут скейлить шрифт по Ctrl-колесо мыши.
Первое хорошо чтобы копировать всякие сообщения об ошибке или данные прямо из окна работающего приложения. А вот второе - это прям топ. У меня огромный 31-дюймовый монитор, сижу я от него далеко и дальнозоркостью не отличаюсь. Увеличение шрифта - фича, которой я пользуюсь, наверное, чаще всего.
Забавно, что даже в самой всратой технологии можно обнаружить свои плюсы, если постараться.
Такие дела.
Сантехник .NET стека
Этот пост ни о чём. Если вам не нравятся посты ни о чём - не читайте :)
Мне нравится называть себя "сантехником .NET стека", и вот почему.
Потому что в какой-то момент из моей работы пропало всякое творчество. Это вот опенсорс, я пишу красиво, хорошо, документировано. С элементами функциональщины, fluent-конфигурации. Нестандартный ход того же RT с интеграцией в MSBuild. Lattice у меня вот до сих пор в разработке. Я что-то всё тяну да тяну. Но клянусь б-гом, там внутри отдельный клиентский жс-движок покрытый тестами и документацией, собирающийся раздельно с клиент-фронтендом!
А в повседневной моей работе давно уже нет никакого творчества. В основном это некоторое количество менеджерской бюрократии (поучаствовать в одном-втором-третьем митинге, почитать доку в конфлюенсе, создать-перетащить тикет-другой, код поревьюить) и некоторое количетво кода. Решить несложную задачку, баг поправить застарелый, зарефакторить, тесты написать. Плюс помочь коллегам, которые временами спрашивают всякое.
В этой рутине нет никакого пространства для самовыражения. Я просто довольно смышлёный, помню много инструментов, знаю как работают всякие штуки. И получается что я просто как сантехник с огромным ящиком инструментов таскаюсь вместе со всей командой и - you know... Doin' my best.
А с другой стороны, оно и к лучшему. В больших полномочиях большая ответственность. Продукт слишком большой, если я даже и могу убедить кого-либо перейти на мою библиотеку - то я ж за это буду отвечать головой потом. И нет нет, подсадить компанию на свои фреймворки - это не идеальное жоп секурити, как показал мой опыт.
Поверьте, я знаю о чём говорю: мой Lattice до сих пор вращается в недрах Replace Group. Хотя я сам в недрах Replace Group не вращаюсь уже года 2. И исходники только у меня. Да и сама Replace Group уже давным давно куплена норвержцами. Дважды.
Для моих разработок, кстати, будет полезно поучаствовать в новых боевых условиях. Пользователи на гитхабе-то пользуют и молчат! А тут можно самому пощупать на сеьёзном проекте, а не на всякой детской дичи. В общем, я долго думал и пришёл к выводу что с точки зрения качества и фичеватости - подключать свою либу к новому проекту - это всегда хорошо. Можно посмотреть на неё в работе, потрогать ручками. Записать себе на листочке что получилось хорошо, что плохо, где мож что убрать, где добавить. Баги могут вылезти какие-нибудь.
Но я не стану этого делать. Во-первых потому что у меня есть профессиональная этика, а у меня тут налицо конфликт интересов. Во-вторых, не хочу случись что быть крайним. Да, я понимаю что Tecture в нашем продукте выстрелит просто пушкой. Но крайним в случае чего быть всё же не хочется.
Поэтому работа отдельно, а пет-прожекты отдельно. На работе я предпочитаю быть сантехником и гайки крутить.
Такие дела
Этот пост ни о чём. Если вам не нравятся посты ни о чём - не читайте :)
Мне нравится называть себя "сантехником .NET стека", и вот почему.
Потому что в какой-то момент из моей работы пропало всякое творчество. Это вот опенсорс, я пишу красиво, хорошо, документировано. С элементами функциональщины, fluent-конфигурации. Нестандартный ход того же RT с интеграцией в MSBuild. Lattice у меня вот до сих пор в разработке. Я что-то всё тяну да тяну. Но клянусь б-гом, там внутри отдельный клиентский жс-движок покрытый тестами и документацией, собирающийся раздельно с клиент-фронтендом!
А в повседневной моей работе давно уже нет никакого творчества. В основном это некоторое количество менеджерской бюрократии (поучаствовать в одном-втором-третьем митинге, почитать доку в конфлюенсе, создать-перетащить тикет-другой, код поревьюить) и некоторое количетво кода. Решить несложную задачку, баг поправить застарелый, зарефакторить, тесты написать. Плюс помочь коллегам, которые временами спрашивают всякое.
В этой рутине нет никакого пространства для самовыражения. Я просто довольно смышлёный, помню много инструментов, знаю как работают всякие штуки. И получается что я просто как сантехник с огромным ящиком инструментов таскаюсь вместе со всей командой и - you know... Doin' my best.
А с другой стороны, оно и к лучшему. В больших полномочиях большая ответственность. Продукт слишком большой, если я даже и могу убедить кого-либо перейти на мою библиотеку - то я ж за это буду отвечать головой потом. И нет нет, подсадить компанию на свои фреймворки - это не идеальное жоп секурити, как показал мой опыт.
Поверьте, я знаю о чём говорю: мой Lattice до сих пор вращается в недрах Replace Group. Хотя я сам в недрах Replace Group не вращаюсь уже года 2. И исходники только у меня. Да и сама Replace Group уже давным давно куплена норвержцами. Дважды.
Для моих разработок, кстати, будет полезно поучаствовать в новых боевых условиях. Пользователи на гитхабе-то пользуют и молчат! А тут можно самому пощупать на сеьёзном проекте, а не на всякой детской дичи. В общем, я долго думал и пришёл к выводу что с точки зрения качества и фичеватости - подключать свою либу к новому проекту - это всегда хорошо. Можно посмотреть на неё в работе, потрогать ручками. Записать себе на листочке что получилось хорошо, что плохо, где мож что убрать, где добавить. Баги могут вылезти какие-нибудь.
Но я не стану этого делать. Во-первых потому что у меня есть профессиональная этика, а у меня тут налицо конфликт интересов. Во-вторых, не хочу случись что быть крайним. Да, я понимаю что Tecture в нашем продукте выстрелит просто пушкой. Но крайним в случае чего быть всё же не хочется.
Поэтому работа отдельно, а пет-прожекты отдельно. На работе я предпочитаю быть сантехником и гайки крутить.
Такие дела
Велосипеды
Ну что, кому жопку подпалить? :)
Короче. Вы как хотите, но я считаю что велосипеды надо нормализовать. Особенно если они очень маленькие и помещаются в 2-3 класса. Душнилы заорут, мол, "ааааа!!! только не велосипед! переиспользуй готовое! нееет это не каммунити-прувен!".
"Пионэры," — говорю я душнилам — "идите в жопу!".
Типичный душнила склонен тыкать пальцем в 200 строк кода и орать "о господи велосипеееееед!!!". Называть себя разработчиком после такого — это как вообще? Слушай, чел, там код. На языке, который ты знаешь. Это даже не зоопарк технологий — если велосипед делаю я, то всё написано ровно на том же языке, что и основная система. Берёшь, открываешь и читаешь. Или у нас глазонек нет?
А взять какое-нибудь говно из npm. Ты ж даже не знаешь кто это написал. А даже если бы и знал - кто тебе сказал что квалификация автора либы выше твоей/моей/чьей-либо? Вдруг там внутри как в секторе Газа? А автор "велосипеда", в который ты тыкаешь пальцем всё ещё сидит с тобой рядом, умеет говорить ртом, писать текст и комментарии к коду руками, а так же разбирается во всём написанном мозгом.
А вот, скажем, поддержка. Ребят, ну я был "по ту сторону опенсорса". Я сам мейнтейню библиотеку. Любой мейнтейнер может культурно отправить вас нахуй со всеми вопросами и багрепортами. Никто никому ничего не должен, читай лицензию. И потом, мейнтейнер — тоже человек. У него могут быть тысячи причин не заниматься проектом. Не говоря уже о том, что мейнтейнера может тупо сбить автобус. У меня был реальный случай, когда пришлось перетаскивать копипастом в проект JS-библиотеки, которые не заапдейтились под новую версию реакта. Мейнтейнеры просто забили на них хуй. Не знаю что у них там произошло — женились может, или работу сменили. Надеюсь что всё-таки автобус.
Что же теперь? Пользоваться библиотеками, за которыми стоят крупные корпорации и над которыми люди работают за зарплату? Да, имеет смысл. Но есть нюанс: большие корпорации делают огромные и сложные библиотеки на все случаи жизни. Не факт что они нужны вам целиком. Я об этом позже развёрнуто напишу. А пока скажу только что видел, как люди ставят себе целый мультитул-фреймворк ради одной-единственной функции. Никита Прокопов негодуэ!
А ещё установка готового пакета не бесплатна: лишние строчки в файлах проектов, лишние конфиги, лишнее время на скачивание, лишние байты в релизной сборке. Умножайте на 100-200 билдов CI в день для норм такого проекта. Курочка-то по зёрнышку клюёт. Пришло на проект 50 Василиев и каждый добавил по маааленькому пакетику. Вроде ничего криминального, а вся система начинает собираться как дирижабль.
Короче, от установки пакета тоже есть свой оверхед. Только он не моментально даёт вам в рожу, а так... Системно и с оттяжечкой. Проблемой это становится ВНЕЗАПНО.
В общем, то, что можно написать самому в рамках рабочего дня - я пишу сам. Сходить в исходники требуемой либы и просто скопипастить нужный код - так же норм.
Делаю ли я велосипеды? Несомненно. Только вот мои велосипеды всегда прекрасно и быстро работали, были всем понятны и не требовали сношений с настройкой (что регулярно встречается у 3rd-party либ). Будь я Филом — я бы сказал что я просто охуенен, но всё проще: при разработке я думаю головой, а не жопой. Всем бы так — и не будет печали.
Такие дела
P.S: На днях прочитал отличное: "а чтобы делать свои велосипеды тебе нужна лицензия от министерства магии".
Ну что, кому жопку подпалить? :)
Короче. Вы как хотите, но я считаю что велосипеды надо нормализовать. Особенно если они очень маленькие и помещаются в 2-3 класса. Душнилы заорут, мол, "ааааа!!! только не велосипед! переиспользуй готовое! нееет это не каммунити-прувен!".
"Пионэры," — говорю я душнилам — "идите в жопу!".
Типичный душнила склонен тыкать пальцем в 200 строк кода и орать "о господи велосипеееееед!!!". Называть себя разработчиком после такого — это как вообще? Слушай, чел, там код. На языке, который ты знаешь. Это даже не зоопарк технологий — если велосипед делаю я, то всё написано ровно на том же языке, что и основная система. Берёшь, открываешь и читаешь. Или у нас глазонек нет?
А взять какое-нибудь говно из npm. Ты ж даже не знаешь кто это написал. А даже если бы и знал - кто тебе сказал что квалификация автора либы выше твоей/моей/чьей-либо? Вдруг там внутри как в секторе Газа? А автор "велосипеда", в который ты тыкаешь пальцем всё ещё сидит с тобой рядом, умеет говорить ртом, писать текст и комментарии к коду руками, а так же разбирается во всём написанном мозгом.
А вот, скажем, поддержка. Ребят, ну я был "по ту сторону опенсорса". Я сам мейнтейню библиотеку. Любой мейнтейнер может культурно отправить вас нахуй со всеми вопросами и багрепортами. Никто никому ничего не должен, читай лицензию. И потом, мейнтейнер — тоже человек. У него могут быть тысячи причин не заниматься проектом. Не говоря уже о том, что мейнтейнера может тупо сбить автобус. У меня был реальный случай, когда пришлось перетаскивать копипастом в проект JS-библиотеки, которые не заапдейтились под новую версию реакта. Мейнтейнеры просто забили на них хуй. Не знаю что у них там произошло — женились может, или работу сменили. Надеюсь что всё-таки автобус.
Что же теперь? Пользоваться библиотеками, за которыми стоят крупные корпорации и над которыми люди работают за зарплату? Да, имеет смысл. Но есть нюанс: большие корпорации делают огромные и сложные библиотеки на все случаи жизни. Не факт что они нужны вам целиком. Я об этом позже развёрнуто напишу. А пока скажу только что видел, как люди ставят себе целый мультитул-фреймворк ради одной-единственной функции. Никита Прокопов негодуэ!
А ещё установка готового пакета не бесплатна: лишние строчки в файлах проектов, лишние конфиги, лишнее время на скачивание, лишние байты в релизной сборке. Умножайте на 100-200 билдов CI в день для норм такого проекта. Курочка-то по зёрнышку клюёт. Пришло на проект 50 Василиев и каждый добавил по маааленькому пакетику. Вроде ничего криминального, а вся система начинает собираться как дирижабль.
Короче, от установки пакета тоже есть свой оверхед. Только он не моментально даёт вам в рожу, а так... Системно и с оттяжечкой. Проблемой это становится ВНЕЗАПНО.
В общем, то, что можно написать самому в рамках рабочего дня - я пишу сам. Сходить в исходники требуемой либы и просто скопипастить нужный код - так же норм.
Делаю ли я велосипеды? Несомненно. Только вот мои велосипеды всегда прекрасно и быстро работали, были всем понятны и не требовали сношений с настройкой (что регулярно встречается у 3rd-party либ). Будь я Филом — я бы сказал что я просто охуенен, но всё проще: при разработке я думаю головой, а не жопой. Всем бы так — и не будет печали.
Такие дела
P.S: На днях прочитал отличное: "а чтобы делать свои велосипеды тебе нужна лицензия от министерства магии".
Про перфоманс приложений
Короче тема такая. Я отказываюсь верить в концепцию ботлнека. Если с производительностью жопа - то, скорее всего, нет какого-то ОДНОГО места, в которое всё утыкается и тупит. Если у вас так - то вам повезло.
Согласен, проблемы с производительностью бывают из-за тупых ошибок. Возьмём типичный кейс: там где можно сделать один запрос в базу данных - делается полсотни. Это тупо, это один из простейших ботлнеков и относительно легко лечится.
А вот как насчёт мест, где вместо одного SQL-запроса делается всего два? Фигня-фигнёй, согласитесь. Разница - пара сотен миллисекунд. Но проблемы начинаются когда таких мест в коде тысячи.
И тут за деревьями появляется лес.
Большинство медленных систем, которые я видел не содержали в себе ботлнеков как таковых. Они равномерными тонкими слоями нагружали, скажем, базу данных простыми операциями. Такой... логический DDoS. И что с этим делать кроме "пошло всё нахрен - взять и переписать" - не особо ясно.
И так со всем - лишние сетевые вызовы, лишнее чтение из файловой системы, чтение файлов целиком в строку, листы вместо хэшсетов, промежуточные абстракции.
А самое главное - начинаешь разбираться и вроде по отдельности всё получается такое, собака, нужное. Например, чтение настроек какой-нибудь фигни: ну разве ж сервис X не может одним запросом выбрать все параметры конфигурации? Ан нет, смотришь в логику и там начинается: "ой, мы выберем сначала один, потом второй, потом мы сравним их по модулю 42 и если они разные - вытянем третий". А по одному достаётся чтобы, понимаешь, логическую целостность системы не нарушать. Никому в голову не приходит что выбрать всё один раз выйдет дешевле.
И главное-то сука, код действительно приемлемо и логично выглядит. И читается неплохо. И за интерфейсами всё спрятано. Но мы всё равно делаем 3 запроса в базу, когда можно сделать один! Это же тупость.
Самое печальное, что построить простенький фреймворк с рефлекшоном вокруг настроек, который будет как-нибудь красиво, через шарповую лямбду преобразовывать всё, что хочется запросить в отдельный запрос - религия не позволяет! Сразу начнут вопить вокруг: "велосипеееед! велосипеееед!", "найди готовую либу!", "в этом коде никто не разберётся!".
Херня! Гетерогенные ботлнеки, распределённо и планомерно замедляющие систему - вот в чём никто не сможет разобраться. Ваши ёбаные пирамиды абстракций и сервисов - вот что действительно сложно. 20 строчек нестандартного кода по сравнению с этим - херня собачья.
Но нам, настоящим мужикам, не с руки читать 20 строк кода. Потому что, как мы знаем, "настоящие мужики терпят"(с).
Такие дела
Короче тема такая. Я отказываюсь верить в концепцию ботлнека. Если с производительностью жопа - то, скорее всего, нет какого-то ОДНОГО места, в которое всё утыкается и тупит. Если у вас так - то вам повезло.
Согласен, проблемы с производительностью бывают из-за тупых ошибок. Возьмём типичный кейс: там где можно сделать один запрос в базу данных - делается полсотни. Это тупо, это один из простейших ботлнеков и относительно легко лечится.
А вот как насчёт мест, где вместо одного SQL-запроса делается всего два? Фигня-фигнёй, согласитесь. Разница - пара сотен миллисекунд. Но проблемы начинаются когда таких мест в коде тысячи.
И тут за деревьями появляется лес.
Большинство медленных систем, которые я видел не содержали в себе ботлнеков как таковых. Они равномерными тонкими слоями нагружали, скажем, базу данных простыми операциями. Такой... логический DDoS. И что с этим делать кроме "пошло всё нахрен - взять и переписать" - не особо ясно.
И так со всем - лишние сетевые вызовы, лишнее чтение из файловой системы, чтение файлов целиком в строку, листы вместо хэшсетов, промежуточные абстракции.
А самое главное - начинаешь разбираться и вроде по отдельности всё получается такое, собака, нужное. Например, чтение настроек какой-нибудь фигни: ну разве ж сервис X не может одним запросом выбрать все параметры конфигурации? Ан нет, смотришь в логику и там начинается: "ой, мы выберем сначала один, потом второй, потом мы сравним их по модулю 42 и если они разные - вытянем третий". А по одному достаётся чтобы, понимаешь, логическую целостность системы не нарушать. Никому в голову не приходит что выбрать всё один раз выйдет дешевле.
И главное-то сука, код действительно приемлемо и логично выглядит. И читается неплохо. И за интерфейсами всё спрятано. Но мы всё равно делаем 3 запроса в базу, когда можно сделать один! Это же тупость.
Самое печальное, что построить простенький фреймворк с рефлекшоном вокруг настроек, который будет как-нибудь красиво, через шарповую лямбду преобразовывать всё, что хочется запросить в отдельный запрос - религия не позволяет! Сразу начнут вопить вокруг: "велосипеееед! велосипеееед!", "найди готовую либу!", "в этом коде никто не разберётся!".
Херня! Гетерогенные ботлнеки, распределённо и планомерно замедляющие систему - вот в чём никто не сможет разобраться. Ваши ёбаные пирамиды абстракций и сервисов - вот что действительно сложно. 20 строчек нестандартного кода по сравнению с этим - херня собачья.
Но нам, настоящим мужикам, не с руки читать 20 строк кода. Потому что, как мы знаем, "настоящие мужики терпят"(с).
Такие дела
Организационный момент
1. В пятницу поста не будет. Вместо него я выкачу техническую статью на хабр. Она короткая, в основном для дотнетчиков, но думаю и всем остальным будет интересно.
2. Мне предложили выступить на конференции TeamLeadCamp. Если всё срастётся, то дам знать где и когда меня можно будет послушать.
3. По просьбе ребят из Microsoft, я обновил Reinforced.Typings до версии 1.6.1 - теперь там есть поддержка .NET 6. Без бомбления не обошлось, позже напишу об этом.
Новиков, кончай писать в телеграм-канал, садись писать тезисы, ленивая жопа.
Такие дела
1. В пятницу поста не будет. Вместо него я выкачу техническую статью на хабр. Она короткая, в основном для дотнетчиков, но думаю и всем остальным будет интересно.
2. Мне предложили выступить на конференции TeamLeadCamp. Если всё срастётся, то дам знать где и когда меня можно будет послушать.
3. По просьбе ребят из Microsoft, я обновил Reinforced.Typings до версии 1.6.1 - теперь там есть поддержка .NET 6. Без бомбления не обошлось, позже напишу об этом.
Новиков, кончай писать в телеграм-канал, садись писать тезисы, ленивая жопа.
Такие дела
Статья
Итак, наконец-то я опубликовал свою долгожданную статью о Roslyn и как с его помощью рефакторить.
Заходите, ставьте плюсы, поджигайте комменты: https://habr.com/ru/post/564992/
Следующие два поста в канале будут о том, что происходит behind the scenes крупного рефакторинга.
Такие дела
Итак, наконец-то я опубликовал свою долгожданную статью о Roslyn и как с его помощью рефакторить.
Заходите, ставьте плюсы, поджигайте комменты: https://habr.com/ru/post/564992/
Следующие два поста в канале будут о том, что происходит behind the scenes крупного рефакторинга.
Такие дела
Сегодня я рефакторил код (ч.1)
Если ваша вечеринка не похожа на это - даже не зовите меня. :)
У на время рефакторинга IDE и окружение превращается в огромную лабораторию по этому самому рефакторингу. На подхвате у меня тестовые проекты в студии, куда можно вставить любой шарповый код и попробовать выполнить и подебажить. В ходе рефакторинга я часто скачу по разным местам проекта туда-сюда. Открыто дополнительно 10 вкладок в Notepad++ со всякой промежуточной чушью, которую я туда копипащу чтобы не потерять. И нет, всякие мульти-клипборд тулы тут не помогут потому что они совсем всё подхватывают, даже те буквы, которые ты скопипастил из RegExr-а в строку поиска в IDE. Вычищать заколебёшься. К тому же Notepad++ просто быстрее чем VS Code. Саблайм мне не нравится.
Рядом лежит обычный бумажный блокнот для записи TODO и рисования схемок. Записывать TODO в коде мне не помогает — я всё равно забуду прочитать перед коммитом.
Навигация по проекту трещит от нагрузки. Очень удобно, кстати, именно для таких случаев иметь мощную настольную игровую машину, а не ноут. Чтобы IDE могла свободно всосать в оперативную память весь код проекта, плюс индексы-кэши для поиска. Кстати, в Rider-е поиск даже по всем файлам работает очень быстро! Респект парням, которые такое сделали. Обожаю софт, который реально ускоряется в разы если ему даёшь больше системных ресурсов, открывая совершенно иные experience-ы. Надысь мне вот надо было один падлючий extension-метод развернуть в static invocation везде в проекте (а мест там куча) — у Rider-а это заняло порядка трёх минут. Круто-круто.
Становятся реально важны тулы, которые не подведут в работе. В ходе рефакторинга иногда я пользуюсь консольным git-ом. Им хорошо, скажем заамендить пачку коммитов потому что гит мне не тот емейл проставил, а у нас политика не позволяет так пушить. Операции по-проще веду через TortoiseGit. Иногда пользуюсь IDE-шным git-клиентом.
Параллельно чисто для навигации открыто ещё две копии IDE с проектом из разных бренчей. У меня репозиторий для этого склонирован 3 раза. Чтобы я мог одновременно смотреть, скажем, на master, release и тот бренч, который я сделал на досуге для проверки некоторых гипотез (например: а что будет если я просто разнесу вон тот огромный контроллер хотя бы на partial-ы?). А ещё MSBuild иногда после себя оставляет мусорные артефакты (кэши пакетов, папки
CPU скрипит и греется — он как будто генту собирает. То есть вполне реально 12 часов кряду собирать код и ранить тесты с перерывами минут на 10 пока я думаю. Сейчас я пробую настроить локальный докер, чтобы поднимать инфру с тестовыми данными, потому что ходить до базы данных через VPN на мою виртуальную машину — это долго.
А регулярные выражения? Ох как я их обожаю. У меня открыто по 3-4 вкладки RegExr-а. Туда я могу, например, скопипастить код класса, а RegExr вытащит мне из него список всех используемых классов с определёнными именами, а потом по этому списку пройтись. Или быстро преобразовать, скажем,
Unit-тесты. Используются наполную примерно с той же целью что и IDE-шки с тестовыми проектами. Только в IDE я запускаю какой-либо алгоритмический код, или проверяю как себя ведут некоторые, скажем, системные классы в определённых условиях. В последнее время я там тестирую как ведёт себя наш IoC-контейнер в разных условиях, а в unit-тестах проверяю как ведут себя какие-то штуки в контексте проекта. Кстати иногда смотрю на результаты, окружаю assert-ами, да так и коммичу. Нехай покрытие растёт. А тут хоть регрессионный тест на, скажем, какой-нибудь корнер-кейс будет.
Продолжение следует...
Если ваша вечеринка не похожа на это - даже не зовите меня. :)
У на время рефакторинга IDE и окружение превращается в огромную лабораторию по этому самому рефакторингу. На подхвате у меня тестовые проекты в студии, куда можно вставить любой шарповый код и попробовать выполнить и подебажить. В ходе рефакторинга я часто скачу по разным местам проекта туда-сюда. Открыто дополнительно 10 вкладок в Notepad++ со всякой промежуточной чушью, которую я туда копипащу чтобы не потерять. И нет, всякие мульти-клипборд тулы тут не помогут потому что они совсем всё подхватывают, даже те буквы, которые ты скопипастил из RegExr-а в строку поиска в IDE. Вычищать заколебёшься. К тому же Notepad++ просто быстрее чем VS Code. Саблайм мне не нравится.
Рядом лежит обычный бумажный блокнот для записи TODO и рисования схемок. Записывать TODO в коде мне не помогает — я всё равно забуду прочитать перед коммитом.
Навигация по проекту трещит от нагрузки. Очень удобно, кстати, именно для таких случаев иметь мощную настольную игровую машину, а не ноут. Чтобы IDE могла свободно всосать в оперативную память весь код проекта, плюс индексы-кэши для поиска. Кстати, в Rider-е поиск даже по всем файлам работает очень быстро! Респект парням, которые такое сделали. Обожаю софт, который реально ускоряется в разы если ему даёшь больше системных ресурсов, открывая совершенно иные experience-ы. Надысь мне вот надо было один падлючий extension-метод развернуть в static invocation везде в проекте (а мест там куча) — у Rider-а это заняло порядка трёх минут. Круто-круто.
Становятся реально важны тулы, которые не подведут в работе. В ходе рефакторинга иногда я пользуюсь консольным git-ом. Им хорошо, скажем заамендить пачку коммитов потому что гит мне не тот емейл проставил, а у нас политика не позволяет так пушить. Операции по-проще веду через TortoiseGit. Иногда пользуюсь IDE-шным git-клиентом.
Параллельно чисто для навигации открыто ещё две копии IDE с проектом из разных бренчей. У меня репозиторий для этого склонирован 3 раза. Чтобы я мог одновременно смотреть, скажем, на master, release и тот бренч, который я сделал на досуге для проверки некоторых гипотез (например: а что будет если я просто разнесу вон тот огромный контроллер хотя бы на partial-ы?). А ещё MSBuild иногда после себя оставляет мусорные артефакты (кэши пакетов, папки
/bin и /obj), от которых можно иногда ловить некорректное поведение билда. Типа я вот эту библиотеку снёс, переключился на другой бренч, там поработал, потом вернулся обратно — MSBuild бедненький видит что файл уже лежит и пересобирать его не надо - прям так и подсасывает. А потом очень удивляется почему ж дебаг криво работает.CPU скрипит и греется — он как будто генту собирает. То есть вполне реально 12 часов кряду собирать код и ранить тесты с перерывами минут на 10 пока я думаю. Сейчас я пробую настроить локальный докер, чтобы поднимать инфру с тестовыми данными, потому что ходить до базы данных через VPN на мою виртуальную машину — это долго.
А регулярные выражения? Ох как я их обожаю. У меня открыто по 3-4 вкладки RegExr-а. Туда я могу, например, скопипастить код класса, а RegExr вытащит мне из него список всех используемых классов с определёнными именами, а потом по этому списку пройтись. Или быстро преобразовать, скажем,
piper.saveMeToDb() в _piperManager.savePiperToDb(piper) в рамках класса. То есть для такой... серьёзной замены мне мощностей Rider-а не хватает. RegExr справляется лучше. Unit-тесты. Используются наполную примерно с той же целью что и IDE-шки с тестовыми проектами. Только в IDE я запускаю какой-либо алгоритмический код, или проверяю как себя ведут некоторые, скажем, системные классы в определённых условиях. В последнее время я там тестирую как ведёт себя наш IoC-контейнер в разных условиях, а в unit-тестах проверяю как ведут себя какие-то штуки в контексте проекта. Кстати иногда смотрю на результаты, окружаю assert-ами, да так и коммичу. Нехай покрытие растёт. А тут хоть регрессионный тест на, скажем, какой-нибудь корнер-кейс будет.
Продолжение следует...