Опишу простой кейс, где знание алгоритмов must have: LiveJournal. Написан на Perl, его движок работает с точки зрения производительности чуть лучше, чем отвратительно. Единственный вариант сделать его чуть быстрее и адекватнее - найти самые медленные части и переписать алгоритмически эффективно. Желательно ещё и с применением XS (компилируемого в бинарь кода на Си, подключаемого как обычная перловая библиотека). И это, к сожалению, очень типичный кейс, особенно, как мне кажется, в российском мире разработки, где основным заказчиком через пятые руки, но всё равно является государство (и это точно не про эффективность). В чём кейс? В том, что компании хотят что-то изменить, ничего принципиально не меняя. Улучшить давно сдохший в муках движок, но не переписывать его на другом языке с нуля, оптимизировать какие-то куски библиотек для взаимодействия с ЦБ, но не менять сами библиотеки, потому что ошибка может стоить слишком дорого, а "бизнес" устраивает статус-кво (работает - не трожь), заменить кусок последовательного кода без намёка на треды и асинк, алгоритмически оптимизировав в нём 10% (хотя можно было получить +300% прироста производительности, всё-таки переписав движок). Бизнес очень консервативен сам по себе, даже в сфере IT. Бизнес, взаимодействующий с богатым, но чреватым безумными штрафами и даже уголовными делами государством, - часто и вовсе костенеет, становится пугливым и неповоротливым до (бес)предела. И всё, что он может себе позволить - это гальванизация трупов кода из юрского периода ботоксными подтяжками правильных алгоритмов. То есть бизнес конечно начинает в какой-то момент осознавать проблему и хочет что-то изменить, но... только ничего не меняя. И чем крупнее бизнес - тем безнадёжнее и абсурднее ситуация в этом плане. И Yandex здесь - совершенно не исключение, хотя там есть, куда применять навыки написания алгоритмов, особенно в таких штуках как проекты, завязанные на картографию и AI.
Глотком кислорода, отсрочившим смерть PHP, стал выход 7-й версии, которая банально работала в разы быстрее, обогнав и perl, и python. Интерпретатор PHP 7 был фактически написан заново, в этом и был «успех», отсрочивший агонию языка.
Perl 7 же по сути не предлагает ничего нового, это просто смена одних циферок другими. На уровне техническом последним революционным изменением был перевод строк на CoW, когда реальное копирование строки происходило при попытке её изменения, а не при собственно присваивании.
Дальше чуть улучшили скорость вычислений, чуть ещё ускорили работу со строками… Но в основном все изменения последних лет в Perl'е — это запреты делать то и это.
Вместо того, чтобы подумать, с какой перепуга у них open, for, if и множество других операторов не возвращают ничего вразумительного — какие-то постоянные выпиливания того, что было, но «не зашло». Местами правильные типа запрета делать бред вида my $v = $value if condition, местами странноватые типа each, keys и values, не работающих на hashref'ах (кому в данном случае hashref'ы помешали?).
ООП в Perl5 итак куда мощнее многих современных реализаций, включает множественное наследование, да ещё и 2 разных методологии диспетчеризации методов.
Асинхронщина есть, и по-моему ни один проект на Perl без неё не обходится без неё уже лет 10 как.
Типизацию никто даже не думает прикручивать (кроме слегка чокнутого Бразвелла), хотя вообще говоря она бы очень пригодилась.
Но вот то сам интерпретатор как был в 5-ке весьма задумчивым. И нет ни малейшей надежды на то, что интерпретатор когда-то перепишут, выкинув из алгоритмов тонны говна: как минимум потому что уже и сами его разработчики забыли давно, как они наваяли такое. Называется «он так исторически сложился».
В чём отличие 7 от 5? В первой цифре. Всё. Это реально провал.
Вообще пример с ldap:// в статье - сильно неудачный. Никаких file'ов в LDAP нет, да и даже если речь идёт о запросе каких-то атрибутов, содержащих блобы - выхлоп не будет бинарным же, это будет LDIF
dn: uid=foo,out=bar,dc=example,dc=com
jpeg: [base64 encoded string]
Ну т.е. можно было придумать более адекватный пример.
Ну или безусловно интерпретация логируемого библиотекой логирования - тот ещё бич. Если log4j действительно так делает, то это... очень плохо.
Я сам инвалид с ампутацией на уровне верхней трети голени. Полностью поддерживаю точку зрения авторов относительно карбоновых стоп: они безумно дорогие (сами стопы в районе "от 80-ти"), при этом мало тог, что довольно быстро ломаются, так ещё и определить сам факт расслоения стопы и превращения её в фактор прямой опасности для жизни и здоровья - бывает не так-то просто. Я активно езжу на велосипеде, и поломка карбостопы в самые неожиданные моменты уже приводила к падениям (правда, без существенных травм). Со стопой в обзоре, мне кажется, тоже могут быть актуальны проблемы надёжности при интенсивной эксплуатации вне помещений. Плюс не очень понятно, насколько легко она запихивается в обувь, а это критичный момент на самом деле: одним из главным недостатков стандартных косметических нашлёпок ("калош") для протезных стоп является именно то, что их размеры дискретны, при этом шаг размеров обуви меньше и точнее. У меня это приводит к тому, что приходится затягивать калошу вместе со стопой протеза внутрь ботинка, прилагая недюжинные усилия и пользуясь максималтно жёсткой лопаткой для обуви.
Огромное спасибо за то, что сделали такой интересный прототип! Был бы рад участвовать в его тестировании и доработках, особенно в адаптации под езду на велосипеде (там довольно много особенностей). Если, что пишите на drvtiny в домене gmail.com, буду рад оказаться полезен делом и советом.
Представьте, что в MIT родители отправляют своих отпрысков учиться "самостоятельно добывать знания", и работают там не PhD, а этакие коучи, натаскивающие на то, чтобы человек сам "стремился получить знание". Хороша картинка? Реалистичная? В наших ВУЗах, особенно региональных, преподаватели получают копейки, и за эти копейки там остаются только те, кто не может себя найти в обычной жизни, в коммерческих конторах, приносящих прибыль и расплачивающихся чем-то посложнее батона колбасы в месяц со своими сотрудниками. Проще говоря, нужно признать, что да, большинство преподавателей во второстепенных ВУЗах - это просто неудачники, которые сами себя так и не смогли "выпустить" из ВУЗа. И учат они соответственно: им просто наплевать на всё и на всех, они не любят напрягаться и делают свою работу тяп-ляп просто потому что уволить их и нанять других невозможно.
Android - такая штука, для которой очень хочется получить адекватную альтернативу. Усложняющиеся пляски с бубном для того, чтобы получить админ-доступ к собственному телефону, как и постоянная неравная борьба со стремительно заканчивающимся местом из-за того, что большая часть приложений либо не переезжает на внешнюю память, либо не хотят перевозить свои данные - это просто бич, который в некоторых ситуациях откровенно раздражает.
Так что я бы с удовольствием попробовал ОС с возможностью запуска Android-приложений. Неразрешимая по сути проблема только одна: ограниченный выбор железа. Например, сейчас я пользуюсь смартфонами Киоцеры из-за того, что они весьма прочные и долговечные. Если мне взбредёт в голову использовать там SailfishOS - понятное дело, что либо мне самому придётся руками писать драйверы под железо в моём смартфоне, либо... либо никак, да. Думаю, что приложения для Android под Sailfish со временем будут работать все, хотя бы и не самые свежие версии, а вот крайне скудный выбор железа останется проблемой навсегда. Но в качестве ОС для второго смартфона на поиграться - хороший вариант. Глядишь, настолько понравится, что просто куплю бронированный чехол и буду носить Jolla-смарт в нём.
Может, дело в том, что уже полночь, но мне текст показался каким-то произведением ГКСХБ (здесь и далее - Канцелярии). Тяжёлый казённый стиль (ещё и не везде выдержанный) не красит РСХБ, всё-таки это даже не научная статья, это пусть и техническая, но публицистика.
Гигантские таблицы на мобильных устройствах смотрятся ужасно, например. Ну и саму аббревиатуру TMS неплохо было расшифровать, она не кажется легко узнаваемой.
Но... бывает и хуже, безусловно, хорошо, что даже государственные банки пытаются выйти из состояния криогенного сна, пусть это и получается пока очень неуклюже.
Постарался аккуратно отредактировать заметку, чтобы исправить ошибки и опечатки. Большое спасибо всем за то, что не стали бросаться камнями, обещаю в следующий раз отнестись к самопроверке более ответственно.
К сожалению, во всех IT-процессах присутствует этот фактор , который один мой друг грубовато, но метко охарактеризовал крылатой фразой "некогда объяснять, суй в ж** огурец". Это, безусловно, проблема, но все зрелые компании приходят к разумному балансу между тем, чтобы давать возможность техническим специалистам возможность сокращать технический долг и потребностями бизнес-подразделений. Все понимают, что с гнилью в потрохах jar-архивов, с кодом, залатанным-перезалатанным ради совместимости с диким легаси, которое кто-то притащил ещё на заре проекта (ведь тогда-то оно было ещё вполне актуально) - компания не сможет быстро реагировать на необходимость изменений, адаптации под те же требования к производительности. Здесь больше вопрос в том, насколько руководство той или иной компании способно осознать, что именно её тормозит, почему изменения становятся болезненной процедурой и почему вдруг для проекта, начинавшегося как стартап "людей со взором горящим" вдруг здоровый консерватизм стал ключевой ценностью. Не все могут отличить консерватизм от ни чем объективно не подкреплённой аксиоматики, построенной на банальном страхе что-либо менять. Отсюда эта набившая оскомину "Мы пишем под JDK 1.6, потому что так нам завещал Господь". Если встречается что-то подобное - это верный признак того, что технический долг внутри проекта стремительно растёт и грозит утопить проект в постоянных подпиливаниях меняющегося реального мира под требования локальной экосистемы, в которой застывшие навечно в нелепых положениях костыли и палки стали частью действующего механизма получения прибыли. Никто не думает о том, что есть конкуренты, что прибыль могла быть выше, что можно было бы не платить разработчикам за безумные танцы с бубном и не возводить в ранг святых тех, кто "стоял у истоков и понимает, как вся эта мура работает". Всех заботит сохранение статус-кво и в лучшем случае экстенсивный рост. Отсюда и отсутствие стремление к совершенствованию IT-процессов. Но в общем-то у многих это со временем проходит. Ну либо компания деградирует со всеми вытекающими.
Управление зависимостями - касается информационной безопасности и того, что принято называть manageability, способности компании управлять своими активами. В крупных компаниях, у которых есть на это деньги, не только IT-специалисты сами по себе не склонны тащить в проект специфические зависимости исключительно потому что, они очень удобны и помогают сделать всё "вчера", как того хочет бизнес. Есть ещё и IT-аудит, который диктует нобходимость контролировать зависимости не на уровне самих разработчиков, а на уровне devops-инженеров и системных администраторов. То есть по сути то, что используют крупные игроки - это не свалка docker-контейнеров с неконтролируемым содержимым внутри, это docker-экосистема, в которой только самый верхний уровень ("слой") отдан на откуп разработчикам. Поэтому ответ: сисадмин. Но вместе с разработчиками. Потому что devops, it-security и системные администраторы - это не business prevention подразделения, их задача - помогать разработчикам превращать порождаемый ими творческий хаос в стабильно работающие, безопасные, управляемые бизнес-активы компании.
Есть неплохой YouTube-клиент без рекламы, который не только собрать самому из сырцов полезно, но даже читать эти сырцы приятно, чай не на сях: github.com/iv-org/invidious
Vanced для Android что-то бинарное предлагает качать., а Invidious — для ББ, то есть для компа.
Мысль автора, как мне кажется, была в том, что руководитель должен не только передавать, а это тоже необходимо, но и собственно руководить. А это значит, что, например, именно менеджер должен заниматься стратегией и развитием, на что в российских компаниях чуть реже, чем всегда, кладут болт. Конечно, можно сказать: ну пусть разработчики или админы само занимаются стратегией и развитием, но во-первых — им это чаще всего не особо упёрлись, а главное — том тогда нужно взаимодействовать друг с другом аки единому организму в полном согласии. Такого не бывает, и для того, чтобы внедрялись новые методологии разработки, применялись более эффективные технологии и хотя бы просто разгребался бардак и технические дороги в том, что уже есть — и нужен менеджер. На деле же менеджеры в IT просто стелятся под бизнес и какие-либо идеи и технологии внедряют только тогда, когда мало что в этом понимающий юбилеем начинает давить сверху. Например, потому что доработки ПО становятся слишком дорогими и долгоиграющими, штат разработчиков пухнет, а качество результата в лучшем случае остаётся прежним, а у админов — время простоя сервисов полосе аварий составляет от получаса и выше, при этом качество предоставляемого ими сервиса — оказывается посредственным. Руководитель — это не только передаст, но всё-таки прежде всего человек, которые отвечает за развитие и стратегическое планирование. Причем иногда — в прямой ущерб текущим сиюминутным интересам бизнеса, но для пользы дела в договорной перспективе. Хороший менеджер умеет сказать твёрдое НЕТ хотелкам бизнеса и объяснить, почему реализация этих хотелок приведёт к тяп-ляп--и-так-сойдёт, и как это может сказать на результатах компании и её репутации в долговременной перспективе. За дорогие годы работы в разных российских компаниях мне посчастливилось встретить таких руководителей, которыми можно реально гордиться. Один из них стал моим другом, с другими общаемся до сих пор. Я раз, что знаком с такими людьми и могу уверенно сказать: да, бывает по другому, не все такие бесхребетные приспособленцы, какими привыкли видеть менеджеров в российских компаниях. Не все, но далее из моего опыта — к сожалению, из большинство. И когда менеджерская вертикаль выстраивается до самого верха — мы видим результаты, которых добилась наша страна за последние 20-25 лет. "Мы стали более лучше одеваться".
Очень навороченное решение. Правильно ли я понимаю, что его сложность связана с тем, что это всё-таки прикладной мониторинг в основном, и задача в данном случае — собирать все возможные метрики и хранить их как можно дольше?
При написании кода на компилируемых языках имеет смысл компилировать код с учётом «максимально допустимого уровня отладки». Т.е. оставлять пользователю возможность менять уровень логирования, но -лишь в определённых пределах. Именно уровень trace следует убирать условной компиляцией в первую очередь: это не только не должно быть нужно заказчику, если, конечно, он не является вашей «лабораторной мышью» для экспериментов, но и запросто может скомпрометировать ваш код или даже послужить источником весьма впечатляющих дыр в безопасности приложения (элементарный пример дампа в лог с неверно настроенными правами доступа структуры, содержащей заботливо расшифрованный пароль из конфига, я думаю, приводить не надо). К сожалению, есть и некий гипотетический негативный эффект от компиляции с «вырезанием» всего ненужного конечному покупателю кода: в многопоточных и асинхронных приложениях это может приводить к неприятному эффекту смещения таймингов исполнения, проявляющемуся в том, что при «правильно заклинивших в одном положении закрылках», т.е. в режиме отладки со включенными log.trace'ами всё будет работать отлично и всегда, а вот в режиме, когда отдельные участки многопоточного кода перестанут вдруг синхронизироваться на записи в один и тот же файл — 1 раз на 100 приложение вдруг начнёт вываливаться «в корку».
В целом давно ждал подобную статью, сам довольно много размышлял над подходами к отладке — и выбрал для себя именно отладку логированием.
У нас не разрешено выполнение на агентах произвольных команд со стороны сервера: учитывая тот факт, что даже с использованием tls-шифрования проверка агентом «аутентичности» сервера сводится всё равно к проверке IP-адреса — нам такие вещи не видятся безопасными. Ту же самую схему можно реализовать со стороны агента — и это будет куда более правильно ИМХО. У нас пока тоже реализован автоматический контроль только на уровне systemd (прописываешь в макросе на хосте список «полезных» systemd сервисов — и мониторишь), так что Ваша статья подтолкнула меня подумать над реализацией «автообнаружения с автонавешиванием».
Опишу простой кейс, где знание алгоритмов must have: LiveJournal. Написан на Perl, его движок работает с точки зрения производительности чуть лучше, чем отвратительно. Единственный вариант сделать его чуть быстрее и адекватнее - найти самые медленные части и переписать алгоритмически эффективно. Желательно ещё и с применением XS (компилируемого в бинарь кода на Си, подключаемого как обычная перловая библиотека).
И это, к сожалению, очень типичный кейс, особенно, как мне кажется, в российском мире разработки, где основным заказчиком через пятые руки, но всё равно является государство (и это точно не про эффективность). В чём кейс? В том, что компании хотят что-то изменить, ничего принципиально не меняя. Улучшить давно сдохший в муках движок, но не переписывать его на другом языке с нуля, оптимизировать какие-то куски библиотек для взаимодействия с ЦБ, но не менять сами библиотеки, потому что ошибка может стоить слишком дорого, а "бизнес" устраивает статус-кво (работает - не трожь), заменить кусок последовательного кода без намёка на треды и асинк, алгоритмически оптимизировав в нём 10% (хотя можно было получить +300% прироста производительности, всё-таки переписав движок).
Бизнес очень консервативен сам по себе, даже в сфере IT. Бизнес, взаимодействующий с богатым, но чреватым безумными штрафами и даже уголовными делами государством, - часто и вовсе костенеет, становится пугливым и неповоротливым до (бес)предела. И всё, что он может себе позволить - это гальванизация трупов кода из юрского периода ботоксными подтяжками правильных алгоритмов. То есть бизнес конечно начинает в какой-то момент осознавать проблему и хочет что-то изменить, но... только ничего не меняя. И чем крупнее бизнес - тем безнадёжнее и абсурднее ситуация в этом плане. И Yandex здесь - совершенно не исключение, хотя там есть, куда применять навыки написания алгоритмов, особенно в таких штуках как проекты, завязанные на картографию и AI.
Perl 7 же по сути не предлагает ничего нового, это просто смена одних циферок другими. На уровне техническом последним революционным изменением был перевод строк на CoW, когда реальное копирование строки происходило при попытке её изменения, а не при собственно присваивании.
Дальше чуть улучшили скорость вычислений, чуть ещё ускорили работу со строками… Но в основном все изменения последних лет в Perl'е — это запреты делать то и это.
Вместо того, чтобы подумать, с какой перепуга у них open, for, if и множество других операторов не возвращают ничего вразумительного — какие-то постоянные выпиливания того, что было, но «не зашло». Местами правильные типа запрета делать бред вида my $v = $value if condition, местами странноватые типа each, keys и values, не работающих на hashref'ах (кому в данном случае hashref'ы помешали?).
ООП в Perl5 итак куда мощнее многих современных реализаций, включает множественное наследование, да ещё и 2 разных методологии диспетчеризации методов.
Асинхронщина есть, и по-моему ни один проект на Perl без неё не обходится без неё уже лет 10 как.
Типизацию никто даже не думает прикручивать (кроме слегка чокнутого Бразвелла), хотя вообще говоря она бы очень пригодилась.
Но вот то сам интерпретатор как был в 5-ке весьма задумчивым. И нет ни малейшей надежды на то, что интерпретатор когда-то перепишут, выкинув из алгоритмов тонны говна: как минимум потому что уже и сами его разработчики забыли давно, как они наваяли такое. Называется «он так исторически сложился».
В чём отличие 7 от 5? В первой цифре. Всё. Это реально провал.
Вообще пример с ldap:// в статье - сильно неудачный. Никаких file'ов в LDAP нет, да и даже если речь идёт о запросе каких-то атрибутов, содержащих блобы - выхлоп не будет бинарным же, это будет LDIF
dn: uid=foo,out=bar,dc=example,dc=com
jpeg: [base64 encoded string]
Ну т.е. можно было придумать более адекватный пример.
Ну или безусловно интерпретация логируемого библиотекой логирования - тот ещё бич. Если log4j действительно так делает, то это... очень плохо.
Я сам инвалид с ампутацией на уровне верхней трети голени. Полностью поддерживаю точку зрения авторов относительно карбоновых стоп: они безумно дорогие (сами стопы в районе "от 80-ти"), при этом мало тог, что довольно быстро ломаются, так ещё и определить сам факт расслоения стопы и превращения её в фактор прямой опасности для жизни и здоровья - бывает не так-то просто. Я активно езжу на велосипеде, и поломка карбостопы в самые неожиданные моменты уже приводила к падениям (правда, без существенных травм).
Со стопой в обзоре, мне кажется, тоже могут быть актуальны проблемы надёжности при интенсивной эксплуатации вне помещений. Плюс не очень понятно, насколько легко она запихивается в обувь, а это критичный момент на самом деле: одним из главным недостатков стандартных косметических нашлёпок ("калош") для протезных стоп является именно то, что их размеры дискретны, при этом шаг размеров обуви меньше и точнее. У меня это приводит к тому, что приходится затягивать калошу вместе со стопой протеза внутрь ботинка, прилагая недюжинные усилия и пользуясь максималтно жёсткой лопаткой для обуви.
Огромное спасибо за то, что сделали такой интересный прототип! Был бы рад участвовать в его тестировании и доработках, особенно в адаптации под езду на велосипеде (там довольно много особенностей). Если, что пишите на drvtiny в домене gmail.com, буду рад оказаться полезен делом и советом.
Представьте, что в MIT родители отправляют своих отпрысков учиться "самостоятельно добывать знания", и работают там не PhD, а этакие коучи, натаскивающие на то, чтобы человек сам "стремился получить знание". Хороша картинка? Реалистичная?
В наших ВУЗах, особенно региональных, преподаватели получают копейки, и за эти копейки там остаются только те, кто не может себя найти в обычной жизни, в коммерческих конторах, приносящих прибыль и расплачивающихся чем-то посложнее батона колбасы в месяц со своими сотрудниками. Проще говоря, нужно признать, что да, большинство преподавателей во второстепенных ВУЗах - это просто неудачники, которые сами себя так и не смогли "выпустить" из ВУЗа. И учат они соответственно: им просто наплевать на всё и на всех, они не любят напрягаться и делают свою работу тяп-ляп просто потому что уволить их и нанять других невозможно.
Не хотелось бы показаться навязчивым, но "так же" пишется раздельно в данном случае. Впрочем, этому учат в школе.
>Как гласит английская поговорка, «"знание" — это понимать, что помидор является фруктом
Мне жаль, но английская поговорка говорит неправду. Даже в Англии помидор является овощем.
Android - такая штука, для которой очень хочется получить адекватную альтернативу. Усложняющиеся пляски с бубном для того, чтобы получить админ-доступ к собственному телефону, как и постоянная неравная борьба со стремительно заканчивающимся местом из-за того, что большая часть приложений либо не переезжает на внешнюю память, либо не хотят перевозить свои данные - это просто бич, который в некоторых ситуациях откровенно раздражает.
Так что я бы с удовольствием попробовал ОС с возможностью запуска Android-приложений. Неразрешимая по сути проблема только одна: ограниченный выбор железа. Например, сейчас я пользуюсь смартфонами Киоцеры из-за того, что они весьма прочные и долговечные. Если мне взбредёт в голову использовать там SailfishOS - понятное дело, что либо мне самому придётся руками писать драйверы под железо в моём смартфоне, либо... либо никак, да.
Думаю, что приложения для Android под Sailfish со временем будут работать все, хотя бы и не самые свежие версии, а вот крайне скудный выбор железа останется проблемой навсегда. Но в качестве ОС для второго смартфона на поиграться - хороший вариант. Глядишь, настолько понравится, что просто куплю бронированный чехол и буду носить Jolla-смарт в нём.
Может, дело в том, что уже полночь, но мне текст показался каким-то произведением ГКСХБ (здесь и далее - Канцелярии). Тяжёлый казённый стиль (ещё и не везде выдержанный) не красит РСХБ, всё-таки это даже не научная статья, это пусть и техническая, но публицистика.
Гигантские таблицы на мобильных устройствах смотрятся ужасно, например. Ну и саму аббревиатуру TMS неплохо было расшифровать, она не кажется легко узнаваемой.
Но... бывает и хуже, безусловно, хорошо, что даже государственные банки пытаются выйти из состояния криогенного сна, пусть это и получается пока очень неуклюже.
Постарался аккуратно отредактировать заметку, чтобы исправить ошибки и опечатки. Большое спасибо всем за то, что не стали бросаться камнями, обещаю в следующий раз отнестись к самопроверке более ответственно.
Круто, прямо жирный плюс такой компании!
К сожалению, во всех IT-процессах присутствует этот фактор , который один мой друг грубовато, но метко охарактеризовал крылатой фразой "некогда объяснять, суй в ж** огурец".
Это, безусловно, проблема, но все зрелые компании приходят к разумному балансу между тем, чтобы давать возможность техническим специалистам возможность сокращать технический долг и потребностями бизнес-подразделений. Все понимают, что с гнилью в потрохах jar-архивов, с кодом, залатанным-перезалатанным ради совместимости с диким легаси, которое кто-то притащил ещё на заре проекта (ведь тогда-то оно было ещё вполне актуально) - компания не сможет быстро реагировать на необходимость изменений, адаптации под те же требования к производительности.
Здесь больше вопрос в том, насколько руководство той или иной компании способно осознать, что именно её тормозит, почему изменения становятся болезненной процедурой и почему вдруг для проекта, начинавшегося как стартап "людей со взором горящим" вдруг здоровый консерватизм стал ключевой ценностью. Не все могут отличить консерватизм от ни чем объективно не подкреплённой аксиоматики, построенной на банальном страхе что-либо менять. Отсюда эта набившая оскомину "Мы пишем под JDK 1.6, потому что так нам завещал Господь". Если встречается что-то подобное - это верный признак того, что технический долг внутри проекта стремительно растёт и грозит утопить проект в постоянных подпиливаниях меняющегося реального мира под требования локальной экосистемы, в которой застывшие навечно в нелепых положениях костыли и палки стали частью действующего механизма получения прибыли. Никто не думает о том, что есть конкуренты, что прибыль могла быть выше, что можно было бы не платить разработчикам за безумные танцы с бубном и не возводить в ранг святых тех, кто "стоял у истоков и понимает, как вся эта мура работает". Всех заботит сохранение статус-кво и в лучшем случае экстенсивный рост. Отсюда и отсутствие стремление к совершенствованию IT-процессов. Но в общем-то у многих это со временем проходит. Ну либо компания деградирует со всеми вытекающими.
Управление зависимостями - касается информационной безопасности и того, что принято называть manageability, способности компании управлять своими активами. В крупных компаниях, у которых есть на это деньги, не только IT-специалисты сами по себе не склонны тащить в проект специфические зависимости исключительно потому что, они очень удобны и помогают сделать всё "вчера", как того хочет бизнес. Есть ещё и IT-аудит, который диктует нобходимость контролировать зависимости не на уровне самих разработчиков, а на уровне devops-инженеров и системных администраторов. То есть по сути то, что используют крупные игроки - это не свалка docker-контейнеров с неконтролируемым содержимым внутри, это docker-экосистема, в которой только самый верхний уровень ("слой") отдан на откуп разработчикам.
Поэтому ответ: сисадмин. Но вместе с разработчиками. Потому что devops, it-security и системные администраторы - это не business prevention подразделения, их задача - помогать разработчикам превращать порождаемый ими творческий хаос в стабильно работающие, безопасные, управляемые бизнес-активы компании.
Vanced для Android что-то бинарное предлагает качать., а Invidious — для ББ, то есть для компа.
Мысль автора, как мне кажется, была в том, что руководитель должен не только передавать, а это тоже необходимо, но и собственно руководить. А это значит, что, например, именно менеджер должен заниматься стратегией и развитием, на что в российских компаниях чуть реже, чем всегда, кладут болт. Конечно, можно сказать: ну пусть разработчики или админы само занимаются стратегией и развитием, но во-первых — им это чаще всего не особо упёрлись, а главное — том тогда нужно взаимодействовать друг с другом аки единому организму в полном согласии. Такого не бывает, и для того, чтобы внедрялись новые методологии разработки, применялись более эффективные технологии и хотя бы просто разгребался бардак и технические дороги в том, что уже есть — и нужен менеджер. На деле же менеджеры в IT просто стелятся под бизнес и какие-либо идеи и технологии внедряют только тогда, когда мало что в этом понимающий юбилеем начинает давить сверху. Например, потому что доработки ПО становятся слишком дорогими и долгоиграющими, штат разработчиков пухнет, а качество результата в лучшем случае остаётся прежним, а у админов — время простоя сервисов полосе аварий составляет от получаса и выше, при этом качество предоставляемого ими сервиса — оказывается посредственным. Руководитель — это не только передаст, но всё-таки прежде всего человек, которые отвечает за развитие и стратегическое планирование. Причем иногда — в прямой ущерб текущим сиюминутным интересам бизнеса, но для пользы дела в договорной перспективе. Хороший менеджер умеет сказать твёрдое НЕТ хотелкам бизнеса и объяснить, почему реализация этих хотелок приведёт к тяп-ляп--и-так-сойдёт, и как это может сказать на результатах компании и её репутации в долговременной перспективе. За дорогие годы работы в разных российских компаниях мне посчастливилось встретить таких руководителей, которыми можно реально гордиться. Один из них стал моим другом, с другими общаемся до сих пор. Я раз, что знаком с такими людьми и могу уверенно сказать: да, бывает по другому, не все такие бесхребетные приспособленцы, какими привыкли видеть менеджеров в российских компаниях. Не все, но далее из моего опыта — к сожалению, из большинство. И когда менеджерская вертикаль выстраивается до самого верха — мы видим результаты, которых добилась наша страна за последние 20-25 лет. "Мы стали более лучше одеваться".
Очень навороченное решение. Правильно ли я понимаю, что его сложность связана с тем, что это всё-таки прикладной мониторинг в основном, и задача в данном случае — собирать все возможные метрики и хранить их как можно дольше?
В целом давно ждал подобную статью, сам довольно много размышлял над подходами к отладке — и выбрал для себя именно отладку логированием.