🇬🇧 Just finished reading the "Pro .NET Memory Management" book. It was huge material - more than 1000 pages in nearly 2 months. It is worth to go back and read some chapters again because there's so much to learn.
The book covers basics of memory internals, gives practical recommendations on using performance counters on different operating systems, and digs into the important details of how memory is managed and garbage collected in the CLR. And damn, how complex is GC in the .NET platform. Chapters 7 - 11 are directly devoted to the process of garbage collection, i.e. almost 250 pages! It's interesting to me now to compare the GC with memory management in other languages, like Rust for example.
🇷🇺 На днях дочитал книгу "Pro .NET Memory Management". Вдумчивое чтение такого объёмного материала (более 1000 страниц) заняло почти 2 месяца. Эту книгу и её отдельные главы определённо стоит перечитывать, т.к. вряд ли можно запомнить такой объём информации с первого раза.
В книге даются основы устройства памяти, практические рекомендации по применению счётчиков производительности в различных ОС и, самое главное, внутреннее устройство CLR в части работы с памятью и сборки мусора. И, чёрт, как же всё-таки сложно устроен сборщик мусора .NET внутри. Непосредственно процессу сборки мусора посвящены главы 7 - 11, т.е. практически 250 страниц! Интересно теперь сравнить устройство GC с тем, как управление памятью реализовано в других языках, например, в таких как Rust.
The book covers basics of memory internals, gives practical recommendations on using performance counters on different operating systems, and digs into the important details of how memory is managed and garbage collected in the CLR. And damn, how complex is GC in the .NET platform. Chapters 7 - 11 are directly devoted to the process of garbage collection, i.e. almost 250 pages! It's interesting to me now to compare the GC with memory management in other languages, like Rust for example.
🇷🇺 На днях дочитал книгу "Pro .NET Memory Management". Вдумчивое чтение такого объёмного материала (более 1000 страниц) заняло почти 2 месяца. Эту книгу и её отдельные главы определённо стоит перечитывать, т.к. вряд ли можно запомнить такой объём информации с первого раза.
В книге даются основы устройства памяти, практические рекомендации по применению счётчиков производительности в различных ОС и, самое главное, внутреннее устройство CLR в части работы с памятью и сборки мусора. И, чёрт, как же всё-таки сложно устроен сборщик мусора .NET внутри. Непосредственно процессу сборки мусора посвящены главы 7 - 11, т.е. практически 250 страниц! Интересно теперь сравнить устройство GC с тем, как управление памятью реализовано в других языках, например, в таких как Rust.
🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Почему важно писать и запускать smoke-тесты. Показываю на примере Atomic Heart.
Игра выпущена 21 февраля 2023 года. С 6 февраля 2024 года в Steam игроки начинают массово жаловаться на проблемы с открытым миром. В некоторых местах главный герой проваливается в out of bounds. На ролике пример того, как я сам наткнулся на этот баг.
Вы спросите, как так вышло, что спустя почти год в игре есть такие критические баги? Всё очень просто. 6 февраля вышло DLC, которое сломало основную игру. Не силен в геймдеве, но мне кажется, что такой базовый функционал должен проверяться smoke-тестами. Иначе продукт превращается в неюзабельное говно.
Иронично, что чуть дальше по сюжету от диалога в ролике можно встретить отсылку на разработчиков игры в виде говорящего трупа с подписью «Мёртвый игродел». Видимо, при создании DLC разработчики сильно кранчили, что и привело к таким печальным последствиям.
Игра выпущена 21 февраля 2023 года. С 6 февраля 2024 года в Steam игроки начинают массово жаловаться на проблемы с открытым миром. В некоторых местах главный герой проваливается в out of bounds. На ролике пример того, как я сам наткнулся на этот баг.
Вы спросите, как так вышло, что спустя почти год в игре есть такие критические баги? Всё очень просто. 6 февраля вышло DLC, которое сломало основную игру. Не силен в геймдеве, но мне кажется, что такой базовый функционал должен проверяться smoke-тестами. Иначе продукт превращается в неюзабельное говно.
Иронично, что чуть дальше по сюжету от диалога в ролике можно встретить отсылку на разработчиков игры в виде говорящего трупа с подписью «Мёртвый игродел». Видимо, при создании DLC разработчики сильно кранчили, что и привело к таким печальным последствиям.
👨💻4👍2
Simplify Integration Testing with Testcontainers
🇷🇺 Интеграционные тесты играют важную роль в разработке программного обеспечения. С их помощью можно проверить, как система интегрируется с внепроцессными зависимостями, например, с такими, как базы данных. Чтобы интеграционный тест, использующий базу данных, заработал, нужно где-то эту базу создать. Можно развернуть базу данных на виртуальной машине или вовсе на локальном хосте. Но лучше воспользоваться фреймворком Testcontainers.
🇬🇧 Integration tests play an important role in software development. They help us see how the system works with volatile dependencies, such as databases. To run the integration test with the database, we need somewhere to create this database. It can be deployed on a virtual machine or even on a local host. However, it's best to use Testcontainers framework,
🇷🇺 Интеграционные тесты играют важную роль в разработке программного обеспечения. С их помощью можно проверить, как система интегрируется с внепроцессными зависимостями, например, с такими, как базы данных. Чтобы интеграционный тест, использующий базу данных, заработал, нужно где-то эту базу создать. Можно развернуть базу данных на виртуальной машине или вовсе на локальном хосте. Но лучше воспользоваться фреймворком Testcontainers.
🇬🇧 Integration tests play an important role in software development. They help us see how the system works with volatile dependencies, such as databases. To run the integration test with the database, we need somewhere to create this database. It can be deployed on a virtual machine or even on a local host. However, it's best to use Testcontainers framework,
👍2
Возвращаемся в офис! Часть 1.
Читая Reddit на выходных наткнулся на интересную историю одного из работников IT компании в США. Его работодатель, как и многие другие в последнее время, решил силой вернуть своих работников в офисы. Что из этого вышло, предлагаю почитать в переводе ниже. Сразу отмечу, что перевод художественный. Я немного изменил порядок предложений для лучшей читаемости и намеренно не перевёл некоторые твиты автора, т.к. посчитал, что они не играют большой роли.
2 месяца назад мой работодатель, на которого я работал удалённо последние 3 года, начал кампанию по возвращению работников в офисы. При трудоустройстве я нанимался на полную удалёнку. Вся моя команда работала удалённо. Ближайший офис от меня был в полутора часах езды. Работа в офисе для меня не имела никакого смысла.
Компания определила работников, которым нужно вернуться в офис, на основе круга, которым они очертили область вокруг каждого из 10 офисов. И теперь я потерял возможность работать удалённо, т.к. недавно мы временно переехали в другую квартиру, до тех пор, пока не купим наш первый дом. И эта квартира была как раз на краю одного из таких кругов. Это означало, что теперь я обязан вернуться в офис. Сбитый с толку, я написал письмо HR:
Вся моя команда расположена в сотнях миль от офиса, а половина из них в Индии. В возвращении в офис нет никакого смысла. На самом деле, теперь мы работать будем меньше, т.к. коммуникация с остальной командой будет только тогда, когда пересекаются наши рабочие часы.
Как думаете, каков был ответ? Если вкратце, то «вали, если не нравится»:
Конечно, ответ был сдобрен типичной корпоративной чушью:
Хочу отметить, что я люблю свою работу. Я работал со своей небольшой командой и мне нравилось её лидить в различных ситуациях, с которыми мы сталкивались. Мы недооплаченные, недофинансированные специалисты, но мы делаем нашу работу и наши клиенты всем довольны.
Это внезапное изменение выглядело, как хотфикс проблем компании. Плохие решения, бестолковое руководство и регулярные траты привели к тому, что мы ежеквартально отчитывались об убытках. В результате, цена акций компании резко упала.
Конечно, всё это вина работников. Они недостаточно усердно работали. Они должны приносить больше прибыли... Вот только как? Видимо, присутствие в офисе - это решение.
Ок. Я не собираюсь ездить полтора часа в одну сторону, стоять в пробках, дополнительно загрязнять окружающую среду и нести больше расходов. Поэтому, как самый умный, я ответил кратким сообщением:
Это не то, что они хотели услышать. В течение часа сообщение по цепочке дошло до самого верха. Руководство было не в восторге. Кстати, HR мне так и не ответила, а об их реакции на мой ответ я узнал только через слухи. Как вскоре стало известно, я был далеко не единственным, кто отказался вернуться в офис.
Важно отметить, что такие требования выдвигались только работникам, проживающим внутри тех самых кругов. Если ты живёшь вне круга, то можешь работать удалённо. Правда ты не можешь переехать без одобрения компании...
Но только, если ты не живёшь в Индии. Сотрудники команд от туда обязаны релоцировать в один из двух крупных городов, где есть офисы компании, иначе будут уволены. Ах да, никаких пересмотров зарплат в связи с переездом не будет. Наслаждайтесь.
Из-за этих новых правил все работники должны будут сидеть за рабочим столом в шумном опен спейсе с 9 до 17. А клиенты будут жаловаться на то, что не слышат нас, т.к. кто-то за соседним столом узнаёт расценки на новые товары. Это конечно же лучше, чем ситуация сейчас, когда мы можем работать из дома.
Продолжение тут.
Читая Reddit на выходных наткнулся на интересную историю одного из работников IT компании в США. Его работодатель, как и многие другие в последнее время, решил силой вернуть своих работников в офисы. Что из этого вышло, предлагаю почитать в переводе ниже. Сразу отмечу, что перевод художественный. Я немного изменил порядок предложений для лучшей читаемости и намеренно не перевёл некоторые твиты автора, т.к. посчитал, что они не играют большой роли.
2 месяца назад мой работодатель, на которого я работал удалённо последние 3 года, начал кампанию по возвращению работников в офисы. При трудоустройстве я нанимался на полную удалёнку. Вся моя команда работала удалённо. Ближайший офис от меня был в полутора часах езды. Работа в офисе для меня не имела никакого смысла.
Компания определила работников, которым нужно вернуться в офис, на основе круга, которым они очертили область вокруг каждого из 10 офисов. И теперь я потерял возможность работать удалённо, т.к. недавно мы временно переехали в другую квартиру, до тех пор, пока не купим наш первый дом. И эта квартира была как раз на краю одного из таких кругов. Это означало, что теперь я обязан вернуться в офис. Сбитый с толку, я написал письмо HR:
Вся моя команда расположена в сотнях миль от офиса, а половина из них в Индии. В возвращении в офис нет никакого смысла. На самом деле, теперь мы работать будем меньше, т.к. коммуникация с остальной командой будет только тогда, когда пересекаются наши рабочие часы.
Как думаете, каков был ответ? Если вкратце, то «вали, если не нравится»:
Это новое правило. Никаких исключений.
Конечно, ответ был сдобрен типичной корпоративной чушью:
В офисе мы можем взаимодействовать и работать продуктивнее.
Хочу отметить, что я люблю свою работу. Я работал со своей небольшой командой и мне нравилось её лидить в различных ситуациях, с которыми мы сталкивались. Мы недооплаченные, недофинансированные специалисты, но мы делаем нашу работу и наши клиенты всем довольны.
Это внезапное изменение выглядело, как хотфикс проблем компании. Плохие решения, бестолковое руководство и регулярные траты привели к тому, что мы ежеквартально отчитывались об убытках. В результате, цена акций компании резко упала.
Конечно, всё это вина работников. Они недостаточно усердно работали. Они должны приносить больше прибыли... Вот только как? Видимо, присутствие в офисе - это решение.
Это новое правило, продиктованное CEO. Отказ от соблюдения приведёт к увольнению.
Ок. Я не собираюсь ездить полтора часа в одну сторону, стоять в пробках, дополнительно загрязнять окружающую среду и нести больше расходов. Поэтому, как самый умный, я ответил кратким сообщением:
Пожалуйста, дайте знать когда будет мой последний рабочий день, чтобы я смог проинформировать мою команду.
Это не то, что они хотели услышать. В течение часа сообщение по цепочке дошло до самого верха. Руководство было не в восторге. Кстати, HR мне так и не ответила, а об их реакции на мой ответ я узнал только через слухи. Как вскоре стало известно, я был далеко не единственным, кто отказался вернуться в офис.
Важно отметить, что такие требования выдвигались только работникам, проживающим внутри тех самых кругов. Если ты живёшь вне круга, то можешь работать удалённо. Правда ты не можешь переехать без одобрения компании...
Но только, если ты не живёшь в Индии. Сотрудники команд от туда обязаны релоцировать в один из двух крупных городов, где есть офисы компании, иначе будут уволены. Ах да, никаких пересмотров зарплат в связи с переездом не будет. Наслаждайтесь.
Из-за этих новых правил все работники должны будут сидеть за рабочим столом в шумном опен спейсе с 9 до 17. А клиенты будут жаловаться на то, что не слышат нас, т.к. кто-то за соседним столом узнаёт расценки на новые товары. Это конечно же лучше, чем ситуация сейчас, когда мы можем работать из дома.
Продолжение тут.
⚡3
Возвращаемся в офис! Часть 2.
Начало тут.
И если бы мне пришлось тратить 3 часа в день на дорогу до работы, то мне пришлось бы бросить все свои хобби. Мне было бы просто некогда. Дорога домой, готовка ужина, тренировка, сон и всё. Никаких больше YouTube, подработок, ничего. Твоя жизнь теперь только для работы на компанию, которая сократит твою должность, как только начнёшь зарабатывать слишком много денег.
Наху й это. У меня только одна жизнь и я не хочу её прожить так.
В моей истории есть счастливая концовка, но не для всех. Миллионы работников были вынуждены вернуться в офисы из-за ряда причин. Но ни одна из этих причин не в интересах работников, несмотря на то, что корпорации пытаются вас убедить в обратном. Твой работодатель скорее всего, заинтересован в этом, т.к. продолжает использовать офисы, на которые были потрачены миллионы $.
Моё «гневное письмо» HR прошло по цепочке вверх. Другие тоже последовали моему примеру независимо от меня. Целые офисы отказались возвращаться к работе. Работники, проживающие в ЕС и работавшие из дома согласно их трудовым договорам, угрожали судом за нарушение условий договора.
Уже 8 недель прошло с тех пор, как было введено обязательное правило о возвращении всех в офис. Никто не был уволен. Компания тихо вернулась к предыдущей политике, касающейся работы в офисе, и продолжила работать как ни в чём не бывало.
В этой истории нет морали. Я просто хотел поделиться свежим опытом и высказать слова поддержки всем удалённым работникам, которые сейчас в похожей ситуации. Не у всех есть финансовая подушка безопасности, которая была у меня, чтобы идти против новых правил компании. Но тем, кто может идти против, я советую делать это. Работодатели всегда пользовались работниками, но удалённая работа - это отличный уравнитель. Удовлетворённость работников растёт, компании тратят меньше, клиенты более счастливы.
И последняя ремарка. Очевидно, удалённая работа не подходит для всех. Не каждая работа может быть удалённой, или хотя бы гибридной. Я понимаю это. Я говорю только о работах, которые действительно могут осуществляться удалённо: техподдержка, QA, аналитики, разработчики, HR, бухгалтерия, финансы и их соответствующие менеджеры.
Кроме того, если мы уберём всех этих людей с дорог, то для тех, кто не может работать удалённо, дороги станут безопаснее и комфортнее. Деньги будут идти в малые города, в которых иначе никто не хочет жить. И много других плюсов.
Начало тут.
И если бы мне пришлось тратить 3 часа в день на дорогу до работы, то мне пришлось бы бросить все свои хобби. Мне было бы просто некогда. Дорога домой, готовка ужина, тренировка, сон и всё. Никаких больше YouTube, подработок, ничего. Твоя жизнь теперь только для работы на компанию, которая сократит твою должность, как только начнёшь зарабатывать слишком много денег.
Н
В моей истории есть счастливая концовка, но не для всех. Миллионы работников были вынуждены вернуться в офисы из-за ряда причин. Но ни одна из этих причин не в интересах работников, несмотря на то, что корпорации пытаются вас убедить в обратном. Твой работодатель скорее всего, заинтересован в этом, т.к. продолжает использовать офисы, на которые были потрачены миллионы $.
Моё «гневное письмо» HR прошло по цепочке вверх. Другие тоже последовали моему примеру независимо от меня. Целые офисы отказались возвращаться к работе. Работники, проживающие в ЕС и работавшие из дома согласно их трудовым договорам, угрожали судом за нарушение условий договора.
Уже 8 недель прошло с тех пор, как было введено обязательное правило о возвращении всех в офис. Никто не был уволен. Компания тихо вернулась к предыдущей политике, касающейся работы в офисе, и продолжила работать как ни в чём не бывало.
В этой истории нет морали. Я просто хотел поделиться свежим опытом и высказать слова поддержки всем удалённым работникам, которые сейчас в похожей ситуации. Не у всех есть финансовая подушка безопасности, которая была у меня, чтобы идти против новых правил компании. Но тем, кто может идти против, я советую делать это. Работодатели всегда пользовались работниками, но удалённая работа - это отличный уравнитель. Удовлетворённость работников растёт, компании тратят меньше, клиенты более счастливы.
И последняя ремарка. Очевидно, удалённая работа не подходит для всех. Не каждая работа может быть удалённой, или хотя бы гибридной. Я понимаю это. Я говорю только о работах, которые действительно могут осуществляться удалённо: техподдержка, QA, аналитики, разработчики, HR, бухгалтерия, финансы и их соответствующие менеджеры.
Кроме того, если мы уберём всех этих людей с дорог, то для тех, кто не может работать удалённо, дороги станут безопаснее и комфортнее. Деньги будут идти в малые города, в которых иначе никто не хочет жить. И много других плюсов.
❤3👍2
Публикации на Хабр
Буду краток. У меня есть статьи, которые, по моему же мнению, достойны публикации на Хабре.
Сегодня опубликовал перевод статьи про оптимальный размер структур.
Приглашаю к чтению: https://habr.com/ru/articles/797777/
Буду краток. У меня есть статьи, которые, по моему же мнению, достойны публикации на Хабре.
Сегодня опубликовал перевод статьи про оптимальный размер структур.
Приглашаю к чтению: https://habr.com/ru/articles/797777/
Хабр
Правило 16 байт: развенчиваем миф о производительности структур в C#
По умолчанию, при передаче в метод или при возврате из метода, экземпляры значимых типов копируются, когда как экземпляры ссылочных типов передаются по ссылке. В 2008 году была выпущена книга...
👍3
Мысли о LeetCode
Уже 2 месяца я решаю задачи на LeetCode. Начал с набора задач LeetCode 75. На данный момент решено 66% проблем из набора. Пару недель назад начал дополнительно решать задачи из SQL 50. Решаю примерно по 1 задаче в день из каждого набора, кроме выходных.
В LeetCode мне нравится большое коммьюнити с большим количеством задач, решениями и пояснениями. Отличный сайт для самообучения. Но не обходится и без ложки дёгтя – бенчмарки сделаны плохо. Результат выполнения одного и того же кода может варьироваться в неком диапазоне. И это нормально, т.к. на результат влияет много шума. Но сейчас имеем ситуацию, когда алгоритм сперва показывает результат на 50% – 60% лучше остальных решений, а чуть позже становится лучше 99% других решений или наоборот. Если провести достаточное количество замеров, то можно высчитать среднее или медиану. Разработчики сервиса этого не делают из-за экономии времени. Если бы замеры кода осуществлялись правильно, т.е. множество раз, то проверка занимала бы минуты, а не несколько секунд, как сейчас.
Зачем я это делаю? Во-первых, из спортивного интереса. Писать алгоритмы, которые решают задачу быстрее других – это весело. Во-вторых, где-то пол года назад у меня появился интерес к теме написания производительного кода, бенчмарков и всего, что с этим связано. Из-за этого я прочитал книгу Pro .NET Memory Management, а сейчас читаю Pro .NET Benchmarking, изучаю алгоритмы, структуры данных и практикуюсь в решении проблем. Все эти знания, я надеюсь, пригодятся в карьере.
Уже 2 месяца я решаю задачи на LeetCode. Начал с набора задач LeetCode 75. На данный момент решено 66% проблем из набора. Пару недель назад начал дополнительно решать задачи из SQL 50. Решаю примерно по 1 задаче в день из каждого набора, кроме выходных.
В LeetCode мне нравится большое коммьюнити с большим количеством задач, решениями и пояснениями. Отличный сайт для самообучения. Но не обходится и без ложки дёгтя – бенчмарки сделаны плохо. Результат выполнения одного и того же кода может варьироваться в неком диапазоне. И это нормально, т.к. на результат влияет много шума. Но сейчас имеем ситуацию, когда алгоритм сперва показывает результат на 50% – 60% лучше остальных решений, а чуть позже становится лучше 99% других решений или наоборот. Если провести достаточное количество замеров, то можно высчитать среднее или медиану. Разработчики сервиса этого не делают из-за экономии времени. Если бы замеры кода осуществлялись правильно, т.е. множество раз, то проверка занимала бы минуты, а не несколько секунд, как сейчас.
Зачем я это делаю? Во-первых, из спортивного интереса. Писать алгоритмы, которые решают задачу быстрее других – это весело. Во-вторых, где-то пол года назад у меня появился интерес к теме написания производительного кода, бенчмарков и всего, что с этим связано. Из-за этого я прочитал книгу Pro .NET Memory Management, а сейчас читаю Pro .NET Benchmarking, изучаю алгоритмы, структуры данных и практикуюсь в решении проблем. Все эти знания, я надеюсь, пригодятся в карьере.
🔥6
Продолжаю публиковать статьи на Хабр
На этот раз доработанная статья про извлечение подстроки.
Приглашаю к чтению: https://habr.com/ru/articles/801187/
На этот раз доработанная статья про извлечение подстроки.
Приглашаю к чтению: https://habr.com/ru/articles/801187/
Хабр
Как в C# быстро извлечь подстроку
Извлечение подстроки. Казалось бы, что тут может быть сложного? В любом современном языке программирования это можно сделать через функцию substring или через slicing. За время работы C# разработчиком...
👍5👀1
Программисты: goto превращает код в спагетти код.
В то же время код платформы .NET, которую разрабатывает Microsoft:
Да, я знаю, что это ради производительности.
На следующей неделе будет статья, про то, как можно ускорить Dictionary в C#. И нет, не при помощи goto. :)
В то же время код платформы .NET, которую разрабатывает Microsoft:
На следующей неделе будет статья, про то, как можно ускорить Dictionary в C#. И нет, не при помощи goto. :)
👍3
Если вы C# разработчик, то наверняка вам знаком класс Dictionary. В качестве значений вы, скорее всего, использовали классы. Но что если я скажу, что в Dictionary можно использовать структуры? Не стоит бояться того, что структуры копируются при передаче в метод или возврате из него. Есть способ этого избежать, и это работает быстро.
Узнать способ можно в статье на Habr.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
С недавних пор в ASP.NET Core появилась встроенная поддержка кэширования. Пропустим шаги по его добавлению в ваше приложение, и перейдём сразу к сути.
Взаимодействовать с кэшем можно следующим образом:
// Добавление в кэш
_cache.Set(key, foo);
// Извлечение
_cache.Get<Foo>(key);
Какой тип данных лучше всего использовать в качестве ключа? Если вы думаете, что можно использовать значения типа
int, long или структуры, то я вас разочарую.Set, Get, GetOrCreate, TryGetValue принимают ключ типа object. То есть даже если ваш ключ имеет тип значения, он всё равно будет упакован. Следовательно, сэкономить на аллокациях в куче не получится.public static TItem Set<TItem>(
this IMemoryCache cache,
object key,
TItem value)
public static TItem? Get<TItem>(
this IMemoryCache cache,
object key)
public static TItem? GetOrCreate<TItem>(
this IMemoryCache cache,
object key,
Func<ICacheEntry, TItem> factory)
public static bool TryGetValue<TItem>(
this IMemoryCache cache,
object key,
out TItem? value)
record struct. Рассмотрим пример:var value = 1;
var key1 = new Key1(value);
var key2 = new Key2(value);
var key3 = new Key3(value);
var key4 = new Key4(value);
// value: 1
Console.WriteLine(
$"value: {value.GetHashCode()}");
// key1: 1
Console.WriteLine(
$"key1: {key1.GetHashCode()}");
// key2: 1
Console.WriteLine(
$"key2: {key2.GetHashCode()}");
// key3: 905109741
Console.WriteLine(
$"key3: {key3.GetHashCode()}");
// key4: -287359892
Console.WriteLine(
$"key4: {key4.GetHashCode()}");
public record struct Key1(int Id);
public record struct Key2(int Id);
public record class Key3(int Id);
public record class Key4(int Id);
Хэш код во всех случаях с типом значения равен 1. Такое поведение вызвано реализацией расчёта хэша для
record struct – возвращается хэш поля int Id, то есть само значение Id.[IsReadOnly]
[CompilerGenerated]
public override readonly int GetHashCode()
{
return EqualityComparer<int>.Default.GetHashCode(this.<Id>k__BackingField);
}
И поскольку под капотом у
IMemoryCache находится самый обычный Dictionary, то при добавлении элементов с такими ключами произойдёт коллизия. Да, кэш всё ещё будет работать, но не так быстро, как это требуется.Можно переопределить
GetHashCode для структур, но зачем, если в конечном счёте значение всё равно будет упаковано.С
record class ситуация иная, поскольку хэш рассчитывается по-другому. Помимо значения Id учитывается ещё и тип.[CompilerGenerated]
public override int GetHashCode() {
return EqualityComparer<Type>
.Default.GetHashCode(
this.EqualityContract) * -1521134295
+ EqualityComparer<int>
.Default.GetHashCode(
this.<Id>k__BackingField);
}
[CompilerGenerated]
protected virtual Type EqualityContract {
[CompilerGenerated]
get {
return typeof (Key4);
}
}
Я не знаю, почему в .NET не реализовали дженерик
IMemoryCache, который бы позволил эффективно использовать структуры. Наверно на это были причины. Но до тех пор, не используйте значимые типы в качестве ключа для IMemoryCache, т.к. производительность такого решения хуже, чем со ссылочными типами.Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Сербия сейчас де-факто один из крупнейших IT хабов в Европе
Вот и App2Top это подтверждает.
В Белграде расположены офисы:
- Microsoft
- JetBrains
- Wargaming
- Yandex
- Ubisoft
И ещё десятки крупных компаний.
В этом нет ничего удивительного. После 22 года в Сербию хлынули десятки тысяч айтишников России, Беларуси и Украины. Компании начали открывать тут офисы.
Несмотря на то, что русские, украинцы и белорусы у себя на Родине считаются высокооплачиваемыми специалистами, западным компаниям они всё равно обходятся дешевле, чем работники из ЕС. А если нет разницы(в скиллах) , зачем платить больше? (c) Знаю это, т.к. сам был нанят в австрийскую компанию по таким же причинам. Международное разделение труда 🤷♂️
Вот и App2Top это подтверждает.
Согласно Сербской игровой ассоциации (SGA), на конец 2023 года в стране зафиксировано 3400 разработчиков игр. Это на 98% больше, чем было годом ранее. Тогда в локальной индустрии числилось 1700 специалистов.
Более того, согласно оценке SGA, к апрелю 2024 года численность игровых профессионалов в Сербии подскочила уже до 4300 человек.
В Белграде расположены офисы:
- Microsoft
- JetBrains
- Wargaming
- Yandex
- Ubisoft
И ещё десятки крупных компаний.
В этом нет ничего удивительного. После 22 года в Сербию хлынули десятки тысяч айтишников России, Беларуси и Украины. Компании начали открывать тут офисы.
Несмотря на то, что русские, украинцы и белорусы у себя на Родине считаются высокооплачиваемыми специалистами, западным компаниям они всё равно обходятся дешевле, чем работники из ЕС. А если нет разницы
👨💻6
К предыдущему посту про разделение труда
В английском языке есть слово bangalored. «Отбангалорить» — значит уволить и перенести позицию в страну с более дешёвой рабочей силой. Этот термин возник в IT сфере США в 2000-х после лопнувшего пузыря доткомов. После кризиса многие компании сокращали расходы и отдавали работу на аутсорс в страны, где работникам можно платитьветку миску риса. Одним из центров притяжения новых рабочих мест стал город Бангалор на юге Индии.
Недавно Google уволила сотрудников из команд Flutter, Dart и Python. По словам бывшего сотрудника, замена была найдена в Мюнхене из-за более дешёвого найма. Кстати, советую почитать его тред. Интересно, как работники на западе реагируют на сокращения.
В 2022 году я грёб в аутсорс компании. Мы работали на проекте Fujitsu. После февральских событий, они решили прекратить сотрудничество с разработчиками из России и нашли нам замену в Бангалоре и Пуне. То есть, нас буквально отбангалорили😂 Как и сотрудники Google, мы проводили обучение тех, кто нас заменит. В том году я весь октябрь провёл в Индии, обучая свою замену. Фото, кстати, от туда.
К чему это всё и какой можно сделать вывод? Неважно, кто ты: работник MAANG-компании или гребец на галерах. Нужно быть готовым к тому, что бизнес решит тебя отбангалорить, поскольку это всегда происходит внезапно.
В английском языке есть слово bangalored. «Отбангалорить» — значит уволить и перенести позицию в страну с более дешёвой рабочей силой. Этот термин возник в IT сфере США в 2000-х после лопнувшего пузыря доткомов. После кризиса многие компании сокращали расходы и отдавали работу на аутсорс в страны, где работникам можно платить
Недавно Google уволила сотрудников из команд Flutter, Dart и Python. По словам бывшего сотрудника, замена была найдена в Мюнхене из-за более дешёвого найма. Кстати, советую почитать его тред. Интересно, как работники на западе реагируют на сокращения.
В 2022 году я грёб в аутсорс компании. Мы работали на проекте Fujitsu. После февральских событий, они решили прекратить сотрудничество с разработчиками из России и нашли нам замену в Бангалоре и Пуне. То есть, нас буквально отбангалорили
К чему это всё и какой можно сделать вывод? Неважно, кто ты: работник MAANG-компании или гребец на галерах. Нужно быть готовым к тому, что бизнес решит тебя отбангалорить, поскольку это всегда происходит внезапно.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
👆Продолжение поста
Сотрудники Google вряд ли будут испытывать проблемы с поиском работы. Но не у всех в резюме такая строчка, поэтому немного о том, как к этому можно подготовиться. Я вижу несколько вариантов (от простого к сложному):
1. Развивать навыки. В случае внезапного увольнения придётся конкурировать за рабочее место. Хорошо, если ты готов. Иначе придётся в очередной вспоминать, где хранятся классы и структуры, пока проедаешь финансовую подушку. Она ведь у тебя есть?
2. Развивать нетворкинг. Общаясь с другими специалистами, можно перенять их опыт, узнать о какой-то новой технологии. В случае проблем на работе можно объединить усилия и попытаться решить проблему максимально выгодным способом. На крайний случай, нетворкинг может помочь найти новую работу, если тебя зарефералят. Причём, не обязательно заводить знакомства только в офисе. Полезной может оказаться даже переписка в Telegram чате.
3. Договориться с работодателем. Например, о выходном пособии при сокращении. И не просто договориться, а закрепить договорённости на бумаге. Такая бумага называется коллективный договор. Конечно, сказать проще, чем сделать. Боюсь, многие даже не знают, что это такое.
Сотрудники Google вряд ли будут испытывать проблемы с поиском работы. Но не у всех в резюме такая строчка, поэтому немного о том, как к этому можно подготовиться. Я вижу несколько вариантов (от простого к сложному):
1. Развивать навыки. В случае внезапного увольнения придётся конкурировать за рабочее место. Хорошо, если ты готов. Иначе придётся в очередной вспоминать, где хранятся классы и структуры, пока проедаешь финансовую подушку. Она ведь у тебя есть?
2. Развивать нетворкинг. Общаясь с другими специалистами, можно перенять их опыт, узнать о какой-то новой технологии. В случае проблем на работе можно объединить усилия и попытаться решить проблему максимально выгодным способом. На крайний случай, нетворкинг может помочь найти новую работу, если тебя зарефералят. Причём, не обязательно заводить знакомства только в офисе. Полезной может оказаться даже переписка в Telegram чате.
3. Договориться с работодателем. Например, о выходном пособии при сокращении. И не просто договориться, а закрепить договорённости на бумаге. Такая бумага называется коллективный договор. Конечно, сказать проще, чем сделать. Боюсь, многие даже не знают, что это такое.
👍6
Уже 100 дней решаю проблемы на leetcode.
Изначально, я решал по 1 проблеме в день из LeetCode 75 и SQL 50. Задачи по SQL мне довольно быстро наскучили. Я на них забил и переключился на daily challenge.
Из ачивок на текущий момент есть:
1. Набор LeetCode 75.
2. Daily Challenges за апрель.
На самостоятельное решение некоторых проблем уровня Hard пока уходит неприлично много времени. В большинстве случаев я их решаю только после гугления. Но скилл нарабатывается и радует, что хоть какие-то сложные задачи могу решать самостоятельно.
Пока что тяжелее всего даётся:
- Greedy
- Dynamic Programming
- Bit Manipulation
Например, то, что нужно применить dynamic programming, я вижу практически мгновенно. Но как именно разбить задачу на подпроблемы, как связать решение подпроблем, как именно применить мемоизацию — пока даётся со скрипом.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2
В прошлое воскресенье на LeetCode в качестве челленджа была задачка Largest Local Values in a Matrix. Несмотря на уровень Easy, она демонстрирует важность последовательного доступа к данным.
Суть задачи
Дана матрица MxM. Нужно найти максимальные значения во всех матрицах 3x3, которые получаются из исходной матрицы. Решение от LeetCode реализовано так (рис. 1):
1. Берётся матрица 3x3.
2. Последовательно обходятся элементы матрицы в поисках максимума.
3. goto п.1.
Что не так с решением?
Например, что столбцы [9, 6, 2] и [8, 2, 6] относятся к матрицам 0 и 1, и будут обработаны несколько раз. Оптимальный алгоритм вернёт правильное решение, обработав каждый столбец и строку лишь 1 раз. Реализовать такой алгоритм можно 2 способами:
1. Обход по столбцам слева направо, сверху вниз (рис. 2).
2. Обход по строкам сверху вниз, слева направо.
Что быстрее? Кажется, что обход по столбцам. Да, но не всегда.
Причём тут последовательный доступ и кэш ЦПУ?
Реализация кэша ЦПУ основана на концепции локальности данных. При обращении к данным высока вероятность, что:
1. Вскоре к данным обратятся снова. Поэтому-то они и сохраняются в кэш.
2. Могут обратиться и к соседним данным. Поэтому кэширование происходит блоками определённого размера (cache line) и в кэш попадают не только запрашиваемые данные, но и соседние байты памяти.
В общем случае, если поведение программы не укладывается в концепцию выше, то производительность снижается. Например, для алгоритма с обходом по строкам, при размере матрицы 2000+ элементов, количество промахов кэша увеличивается многократно (рис. 3), что приводит к ухудшению производительности (рис. 4). Объясняется это непоследовательным доступом. В кэш попадают ненужные даные, ведь используется только 3 элемента из строки.
Но интересно то, что обход по строкам быстрее, если матрица небольшая (рис. 5). В таком случае, в кэш попадает практически вся матрица. А найти max значение 3-х элементов одной строки быстрее, чем 3-х элементов из разных строк.
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡3❤🔥1