Хех. А я случайно в бассейн свалился. Телефон, в котором я сам менял аккумулятор, умер на следующий день. Не откачал. Сушка не спасла. Думаю, если бы аккумулятор не менял, то крышка бы держалась поплотнее и он бы пережил погружение.
а отправленные в тюрьму советские пенсионеры, поставившие лайк под поздравлением с Днем Победы - обыденность
^ не вяжется с:
Згідно з матеріалами справи, пенсіонерка протягом 2022 року публікувала на своїй сторінці в «Однокласниках» дописи, в яких виправдовувала дії російських військ в Україні, заперечувала воєнні злочини РФ, поширювала дезінформацію про хід війни та закликала до підтримки окупантів (локальный источник)
Это, мягко говоря, не одно и тоже. Я не одобряю даже такое, какие к чёрту 5 лет… Дичь. Но изначальный коммент натянул сову на глобус.
По похожим орбитам. Осколки получат разное ускорение в разных направлениях. Будет некий спред. Облетать придётся основательно (особенно ввиду того что никто не сможет эти кусочки засечь и подсчитать).
Пока инцидент единичный - живём. Массовый - тут будет беда.
Не соглашусь. Для цепной реакции нужно чтобы оно масштабно посыпалось. Не единичный случай. Там ведь есть некоторый запас прочности. Тут как я ЯО. Распад происходит то тут то там, но чтобы жахнуло нужна концентрация.
могут получить большую скорость чем была у объектов до столкновения
Правильно ли я понимаю, что если скорость всё ещё будет мала, то они всё равно упадут. Если велика — улетят в космос. И если будет в неком расчётном диапазоне, то это может затянуться надолго. Если да, тогда получается какова вероятность попадание в этот "лимб". Ну и она зависит от того, сколько более быстрых осколков образовалось при столкновении.
Дано: нужно отрисовать иерархию сотрудников в компании в виде интерактивного UI древа. Компании могут быть очень большими. Скажем пара тысяч человек. Данные уже загружены и готовы к отображению.
Человек, который решал задачу, взял готовую библиотеку, которая умеет в виртуализацию. Всё подключил — всё работает. UI в целом не лагает. Отзывчивый. Анимации красивые. Но каждый раз когда человек нажимает "+" на крупном звене мы наблюдаем некоторые тормоза. Плюс при изначальном отображении показан UI с индикатором загрузки.
Загрузки чего? Все данные уже на клиенте же. Копаем…
Визуально на экране помещается, скажем 30 пользователей, из пары тысяч. В профайлере вижу что рендерятся все тысячи. Стали разбираться — оказалось что виртуализатору нужно как-то узнать размеры всех нод. Поэтому он втихую рендерит всё и запоминает размеры. Упс. Т.е. виртуализация у нас как бы и есть и её как бы и нет.
Но размеры у всех нод согласно дизайну статичны. Достаточно их просто захардкодить и UI оживает мгновенно. Никаких более тормозов. Никаких индикаторов загрузки.
Однако осталась проблема с тем, что раз в секунду перерисовывается весь canvas. Почему? Проблема инвалидации ngrx селекторов. Хотя бы у одного пользователя online статус поменялся — всё перерисовываем. Даром что из тысяч визуально одновременно на экране видно пару десятков.
Решаем переносом логики вида "а онлайн ли данный юзер" в компонент отображения юзера. Проблема ушла.
Причём тут алгоритмы? А при том, что у меня как у reviewer-а этого модуля сразу моментально в голове всплыли все эти Big-O проблемы. Ну просто потому, что я сразу увидел что виртуализированное древо должно работать мгновенно, а оно чего-то там грузит. Там ведь нечему тормозить. Раз мы рисуем какие-то анимации загрузки, значит мы где-то сильно продолбались с асимптотикой. Обе вышеописанные проблемы были связаны с тем, что мы обрабатывали все ноды, там где нужно было обрабатывать только видимые.
Человек, который это реализовывал не увидел этих проблем и был уверен, что виртуализация уже работает. И даже был прав. Она работала. Но в полсилы. Он не знал, что можно сильно лучше. Он понимал что код обрабатывает все ноды, но он не знал что можно этого не делать. Логика вида "ну виртуализатор же должен посчитать все размеры" звучит логично. Никаких претензий к нему не имею, просто привёл в качестве живого примера как намётанный глаз мгновенно идентифицирует алгоритмические проблемы там, где их другие не видят и не знают что можно качественно что-то улучшить. Добавим к этому то что все эти loading индикаторы сами себя не заимплементят — получаем не только проблемы с производительностью, а ещё и проблемы с человекочасами.
По двум точкам график не строят. Но в целом у меня такие мысли:
Каждый выбирает себе компании, задачи, приоритеты по вкусу. Тысячу раз видел когда на вопрос руководства "А вот так сделать можно?" оно получало ответ "В теории да, но задача неподъёмная". Хотя с CS ответ был бы "через неделю будет готово" или "дайте мне денёк на поиграться и я отвечу".
Не зная инструмента, как правило, невозможно догадаться что его надо применить. Человек просто решает задачу как умеет. И думает при этом, что решил всё оптимально. Может даже премию получит за то, что всё ускорил в 10 раз (скажем индексы в СУБД добавил). А то что там можно было всё на O(N) заменить человек в принципе представления не имеет. Но пол недели убьёт на красивую loading-анимацию, сервис отражения статуса выполняемой задачи и т.д.
Уже при постановке задачи народ исходит из "это невозможно (или мы не потянем)", а вот это уже готово в библиотеке Х. Подправим задачу так, чтобы библиотека Х прокатила.
Кто-то десятилетиями перекладывает JSON и плачет про выгорание. А кто-то и спустя 15-20 лет тащится от работы и среди коллег прослыл фокусником, которому просто даёшь задачу и он просто её выполняет. Вне зависимости от сложности. Сам проведёт анализ, найдёт решение, отладит, напишет тесты и т.д.. Потом ещё по согласованию с руководством выложит код либы в open source под логотипом компании.
Кто-то в принципе ударяется в познание того, как его рабочие инструменты работают под капотом. А там чего только нет. И побитовая магия, и всякие хипы, LRU кеши, rate limiter-ы разных мастей, в хайлоаде вообще половина Кнута в том или ином виде реализована. И вот когда такой человек начинает отвечать за core часть всех важных homemade инструментов компании, у него может собственная версия хоть даже LinkedList-а завестись.
Ну и т.д.
Вспомнилось ещё. Бинарный поиск применил когда отрисовывал в школьном приложении математические графики. Нужно было для поиска экстремумов заданной функции. Причём бинарный поиск не по массиву, а в рамках бесконечного углубления в дробность чисел. Впрочем это уже нюанс.
Я знаю. Просто lightin2 упомянул что мол структура простая и пишется слёту. Я бы поспорил. Я помнится долго её отлаживал. На собесе я бы сильно удивился, если бы меня заставили её писать. Это изврат.
Heap пригодился когда писал свою версию React-а. Нужно было сортировать древо инвалидированных (= требует rerender-а) компонентов. Обычная сортировка отпадает, т.к. эта коллекция изменяется в процессе (инвалидация context provider-а инвалидирует всех consumer-ов).
Причём потребовалось комбинировать его с HashMap. После знакомства с LRU кешем решение пришло в голову моментально.
LRU cache использую обильно уже во 2-й компании подряд. Гениальная штука.
Всякие обходы графов и деревьев пригождались сотни раз.
Наиболее интересные варианты были когда нужно было избегать circular reference-ов.
Топологическая сортировка пригодилась когда игрался с паттерном Observable
Trie пригодился когда писал подсветку найденного в тексте.
Linked List использовал несколько раз в кастомной реализации rate limiter-ов.
Конечные автоматы во всяких парсерах, интерпретаторах и иже с ними.
Мне попадалось довольно много medium задач, которые были сложнее ряда hard задач. Я часто тупо не понимал в чём была логика того, кто расставлял уровни. К примеру там есть задача Wiggle Sort (не помню точно название). Она medium. Я даже посмотрев решение мало что понял. В то время как были hard задачи уровня напиши небольшой парсер. 15 минут рутины и accepted. Видимо hard тупо за boilerplate.
А как? Я пробовал даже во время слабого - тачскрин сходит с ума. Практически невозможно пользоваться.
Хех. А я случайно в бассейн свалился. Телефон, в котором я сам менял аккумулятор, умер на следующий день. Не откачал. Сушка не спасла. Думаю, если бы аккумулятор не менял, то крышка бы держалась поплотнее и он бы пережил погружение.
Прямо в частных домах? Не в квартирах? Больше половины? О_о
AI говорит что Einfamilienhäuser + Reihenhäuser (таунхаусы) это ~25-30%. Если взять "собственных" то я думаю можно на два делить.
Вы предлагаете писать на хабре Эзоповым языком даже не россиянам?
Ох уж эти формулировки. Под эту фразу попадает любой учебник истории. Включая изданные в СССР.
Спутниковый сигнал? Или местное кабельное TV?
^ не вяжется с:
Это, мягко говоря, не одно и тоже. Я не одобряю даже такое, какие к чёрту 5 лет… Дичь. Но изначальный коммент натянул сову на глобус.
Я зарёкся так делать. Лишился на своей трубке возможности бесконтактной оплаты. А доступ к банковскому приложению так и не появился. One+
Купи ему резиновую уточку.
Раз раз разом success stories про vibe coding пишут люди, которые не смотрят что там написано. Мде…
Brutal. Эпичный разлёт.
По похожим орбитам. Осколки получат разное ускорение в разных направлениях. Будет некий спред. Облетать придётся основательно (особенно ввиду того что никто не сможет эти кусочки засечь и подсчитать).
Пока инцидент единичный - живём. Массовый - тут будет беда.
Не соглашусь. Для цепной реакции нужно чтобы оно масштабно посыпалось. Не единичный случай. Там ведь есть некоторый запас прочности. Тут как я ЯО. Распад происходит то тут то там, но чтобы жахнуло нужна концентрация.
Правильно ли я понимаю, что если скорость всё ещё будет мала, то они всё равно упадут. Если велика — улетят в космос. И если будет в неком расчётном диапазоне, то это может затянуться надолго. Если да, тогда получается какова вероятность попадание в этот "лимб". Ну и она зависит от того, сколько более быстрых осколков образовалось при столкновении.
Нужно чтобы связи не было более двух дней со всеми спутниками одновременно. Планетарный коллапс управления.
Вот ещё нетривиальный пример из практики:
Дано: нужно отрисовать иерархию сотрудников в компании в виде интерактивного UI древа. Компании могут быть очень большими. Скажем пара тысяч человек. Данные уже загружены и готовы к отображению.
Человек, который решал задачу, взял готовую библиотеку, которая умеет в виртуализацию. Всё подключил — всё работает. UI в целом не лагает. Отзывчивый. Анимации красивые. Но каждый раз когда человек нажимает "+" на крупном звене мы наблюдаем некоторые тормоза. Плюс при изначальном отображении показан UI с индикатором загрузки.
Загрузки чего? Все данные уже на клиенте же. Копаем…
Визуально на экране помещается, скажем 30 пользователей, из пары тысяч. В профайлере вижу что рендерятся все тысячи. Стали разбираться — оказалось что виртуализатору нужно как-то узнать размеры всех нод. Поэтому он втихую рендерит всё и запоминает размеры. Упс. Т.е. виртуализация у нас как бы и есть и её как бы и нет.
Но размеры у всех нод согласно дизайну статичны. Достаточно их просто захардкодить и UI оживает мгновенно. Никаких более тормозов. Никаких индикаторов загрузки.
Однако осталась проблема с тем, что раз в секунду перерисовывается весь canvas. Почему? Проблема инвалидации ngrx селекторов. Хотя бы у одного пользователя online статус поменялся — всё перерисовываем. Даром что из тысяч визуально одновременно на экране видно пару десятков.
Решаем переносом логики вида "а онлайн ли данный юзер" в компонент отображения юзера. Проблема ушла.
Причём тут алгоритмы? А при том, что у меня как у reviewer-а этого модуля сразу моментально в голове всплыли все эти Big-O проблемы. Ну просто потому, что я сразу увидел что виртуализированное древо должно работать мгновенно, а оно чего-то там грузит. Там ведь нечему тормозить. Раз мы рисуем какие-то анимации загрузки, значит мы где-то сильно продолбались с асимптотикой. Обе вышеописанные проблемы были связаны с тем, что мы обрабатывали все ноды, там где нужно было обрабатывать только видимые.
Человек, который это реализовывал не увидел этих проблем и был уверен, что виртуализация уже работает. И даже был прав. Она работала. Но в полсилы. Он не знал, что можно сильно лучше. Он понимал что код обрабатывает все ноды, но он не знал что можно этого не делать. Логика вида "ну виртуализатор же должен посчитать все размеры" звучит логично. Никаких претензий к нему не имею, просто привёл в качестве живого примера как намётанный глаз мгновенно идентифицирует алгоритмические проблемы там, где их другие не видят и не знают что можно качественно что-то улучшить. Добавим к этому то что все эти loading индикаторы сами себя не заимплементят — получаем не только проблемы с производительностью, а ещё и проблемы с человекочасами.
По двум точкам график не строят. Но в целом у меня такие мысли:
Каждый выбирает себе компании, задачи, приоритеты по вкусу. Тысячу раз видел когда на вопрос руководства "А вот так сделать можно?" оно получало ответ "В теории да, но задача неподъёмная". Хотя с CS ответ был бы "через неделю будет готово" или "дайте мне денёк на поиграться и я отвечу".
Не зная инструмента, как правило, невозможно догадаться что его надо применить. Человек просто решает задачу как умеет. И думает при этом, что решил всё оптимально. Может даже премию получит за то, что всё ускорил в 10 раз (скажем индексы в СУБД добавил). А то что там можно было всё на O(N) заменить человек в принципе представления не имеет. Но пол недели убьёт на красивую loading-анимацию, сервис отражения статуса выполняемой задачи и т.д.
Уже при постановке задачи народ исходит из "это невозможно (или мы не потянем)", а вот это уже готово в библиотеке Х. Подправим задачу так, чтобы библиотека Х прокатила.
Кто-то десятилетиями перекладывает JSON и плачет про выгорание. А кто-то и спустя 15-20 лет тащится от работы и среди коллег прослыл фокусником, которому просто даёшь задачу и он просто её выполняет. Вне зависимости от сложности. Сам проведёт анализ, найдёт решение, отладит, напишет тесты и т.д.. Потом ещё по согласованию с руководством выложит код либы в open source под логотипом компании.
Кто-то в принципе ударяется в познание того, как его рабочие инструменты работают под капотом. А там чего только нет. И побитовая магия, и всякие хипы, LRU кеши, rate limiter-ы разных мастей, в хайлоаде вообще половина Кнута в том или ином виде реализована. И вот когда такой человек начинает отвечать за core часть всех важных homemade инструментов компании, у него может собственная версия хоть даже LinkedList-а завестись.
Ну и т.д.
Вспомнилось ещё. Бинарный поиск применил когда отрисовывал в школьном приложении математические графики. Нужно было для поиска экстремумов заданной функции. Причём бинарный поиск не по массиву, а в рамках бесконечного углубления в дробность чисел. Впрочем это уже нюанс.
Я знаю. Просто lightin2 упомянул что мол структура простая и пишется слёту. Я бы поспорил. Я помнится долго её отлаживал. На собесе я бы сильно удивился, если бы меня заставили её писать. Это изврат.
У меня больше 100 строк вышло. Довольно дофига для собеса. Но, правда я думаю, он много где есть из коробки.
Heap пригодился когда писал свою версию React-а. Нужно было сортировать древо инвалидированных (= требует rerender-а) компонентов. Обычная сортировка отпадает, т.к. эта коллекция изменяется в процессе (инвалидация context provider-а инвалидирует всех consumer-ов).
Причём потребовалось комбинировать его с HashMap. После знакомства с LRU кешем решение пришло в голову моментально.
LRU cache использую обильно уже во 2-й компании подряд. Гениальная штука.
Всякие обходы графов и деревьев пригождались сотни раз.
Наиболее интересные варианты были когда нужно было избегать circular reference-ов.
Топологическая сортировка пригодилась когда игрался с паттерном Observable
Trie пригодился когда писал подсветку найденного в тексте.
Linked List использовал несколько раз в кастомной реализации rate limiter-ов.
Конечные автоматы во всяких парсерах, интерпретаторах и иже с ними.
То что удалось вспомнить за 5 минут
Мне попадалось довольно много medium задач, которые были сложнее ряда hard задач. Я часто тупо не понимал в чём была логика того, кто расставлял уровни. К примеру там есть задача Wiggle Sort (не помню точно название). Она medium. Я даже посмотрев решение мало что понял. В то время как были hard задачи уровня напиши небольшой парсер. 15 минут рутины и accepted. Видимо hard тупо за boilerplate.