Сохранение еды в путешествии – важный фактор комфорта. А охлаждение напитков в жаркий летний день – по-настоящему, бесценно. Раньше это было проблемой. Чего только не придумывали: охлаждали еду и воду, опустив в садке в реку, обматывали мокрыми тряпками, и даже выкапывали погреб в каждом месте стоянки. Всё это, конечно, лучше, чем хранение еды на жаре. Но очень неудобно и неэффективно.

Казалось бы, решение в виде термоэлектрического автомобильного холодильника было найдено еще 50 лет назад. Однако, на практике, такими холодильниками можно худо-бедно пользоваться только «на ходу», потому что они жутко прожорливы и неэффективны. Я сталкиваюсь с выбором авто-холодильника уже не первый раз. И каждый раз это превращается в какое-то хождение по мукам...

Очевидный факт: язык C — это основа большого количества современных экосистем программирования. Он обеспечивает фундамент многих операционных систем, базовых библиотек и системных инструментов. При этом все еще не существует единого ресурса, который последовательно и связно отвечает на важные вопросы, возникающие при изучении C: окружающая экосистема разработки языка, выбор инструментов, переносимость кода, управление зависимостями и глубокие аспекты работы.

Своим постом автор Jenny Jam* пытается заполнить этот пробел. Он рассуждает, когда C — идеальный выбор, а когда лучше обратиться к другим языкам. Описывает, как настроить среду разработки и выбрать инструменты, разобраться в версиях, особенностях сборки и тонкостях работы с библиотеками.

Цель статьи — упорядочить представление о языке C и его экосистеме, и, конечно, дать практические советы, которые пригодятся в реальных проектах.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

Разбираемся в тонкостях разработки пакетов. Изучаем паттерны, которые применяются при создании пакетов и репозиториев в Nix.

Хочу поделиться с вами простыми шагами по настройке Winodows после ее установки с помощью PowerShell. Все шаги я выполнял неоднократно на Windows 11, думаю, что ошибок с Windows 10 не должно возникнуть.

Всем привет! Это Виктор Сергеев из МТС Диджитал. Сегодня поговорим о компьютере-клавиатуре.

Raspberry Pi 500 — компактный компьютер, встроенный в корпус клавиатуры. У новинки неплохие возможности, несмотря на скромный размер. А еще разработчики обеспечили эффективное охлаждение и оснастили устройство удобными портами и разъемами. Подходит новая модель от Raspberry Pi Foundation как для разработчиков, так и для пользователей, которые ищут недорогое и вместе с тем мощное решение для работы с офисными приложениями.

После шумихи с Notion все ринулись кто-куда, но так сложилось, что по большей части все стали смотреть в сторону Obsidian. И Хабр заполонили статьи про Obsidian и плагины для Obsidian.

Правда, к моему сожалению на техническом ресурсе Хабр я почему-то не нашел ни одной статьи о том, как написать свой собственный плагин, а не как использовать кем-то созданные решения. Я считаю это либо досадным недоразумением либо своим неумением использовать поиск Хабра. Накидайте мне в комментарии, если я не прав, я приму к сведению.

А сейчас же я хотел бы заполнить сложившийся вакуум собственным гайдом.

Продолжаем писать собственные плагины для Obsidian. Первую часть статьи можете найти здесь. В ней мы:

Выяснили, что можно писать плагины даже проще, чем это предлагает делать официальная документация

Написали три маленьких плагина, которые уже вовсю используются на продакшене лично мной

Грозились написать четвертый финальный босс-плагин

Вот и приступим.

В аналитических отчётах для клиентов DevOps-инженеры «Экспресс 42» нередко ссылаются на Модель зрелости инфраструктуры как кода, описанную Гэри Стаффордом ещё в далёком 2016 году. Она помогает определить, на каком уровне сейчас находятся инфраструктурные практики компании, и организовать их систематическое развитие. 

Несмотря на то, что статья не нова, она по-прежнему полезна и применима, ведь ключевые концепции инфраструктуры как кода за это время не изменились. Мы перевели материал для внутренних целей, но подумали, что он может быть интересен сообществу.

Эта статья посвящена каналам. Поднимается вопрос необходимости закрытия каналов. Приводится множество примеров, на escape-анализе и трассировке которых объясняются особенности сохранения каналов в памяти, взаимодействие с GC, горутинами. Также поднимается вопрос уместности закрытия каналов. Подсвечивается практическая польза использования однонаправленных каналов.

Современные компании постоянно сталкиваются с необходимостью управлять множеством разных процессов и инициатив. Чтобы не запутаться в этом сложном мире и максимально эффективно использовать ресурсы, важно разделять проекты и задачи на три основные категории: run, change и disrupt. Это не просто модель для описания потоков работ — это практический подход к управлению деятельностью в организации, помогающий расставить приоритеты и распределить ресурсы с умом.

Конечно, async/await были придуманы не для сна. Нашей целью с самого начала был ввод‑вывод (I/O), а в особенности сетевой ввод‑вывод. Вооружившись futures и задачами, теперь мы можем перейти к реальным примерам.

Привет, Хабр! Меня зовут Влада и я обожаю работать с людьми. Попав волею судеб IT сферу, я поняла, что хоть в IT очень много зависит от командного взаимодействия, большая часть тусовки нацеливается на хард, а не софт. Поэтому статьи тут я хочу посвящать софтам.

Конкретно эта тема вдохновлена и моим опытом, и тем, что из‑за большой нагрузки и событий последних лет, мне часто приходилось искать методы вытаскивания сотрудников (за любые места и в любых позах) из депрессивных состояний.

В ход обычно шло всё, от снижения количества тасков на конкретного сотрудника или изменения уровня сложности до тимбилдингов и особого режима работы. Что‑то помогало лучше, что‑то хуже, скорее, конкретный инструмент нужно было искать индивидуально.

Этот метод — свежая находка последних 6 месяцев, и, как мне кажется, он — квинтэссенция смысла — почему вообще происходит выгорание. Опять же, наверное, общий подход знают всё, я просто его преподнесу в более структурной форме.

То, что напишу ниже, ненаучно (хотя и достаточно сильно перекликается с теорией Павлова, да‑да, тем самым, который про собак и условные рефлексы писал), но обкатываю на окружающих людях и себе — очень помогает исправить ситуацию. Теория не моя, но автор дал добро на то, чтобы пустить её в мир. Для тех, кто любит кратко — переходите к блоку «Итог», а всех остальных приглашаю погрузиться в мою историю и подробное объяснение мат.части.

Сегодня я хочу начать разговор о редко обсуждаемой в сети, но крайне интересно технологической особенности ОС Windows – о политике продукта (далее буду назвать её оригинальным названием Product Policy). Каким образом Microsoft решает, сколько RDP сессий возможно одновременно открыть на ОС (почему в IOT их 2)? Где сказано, что у издания Windows Enterprise G может быть лишь английский или китайский языковой пакет? Где определено максимальное количество процессоров и памяти, максимальное количество подключений к расшаренной сетевой папке, как решается поддерживает ли ОС RDMA, требует ли SMB Signing, отключаются ли SMB1, Defender и Cortana. Да практически все компоненты и отличия разных изданий Windows контролируются именно через Product Policy, и пора бы нам разобраться, что это такое, где хранится, как изменять, и к чему приведут изменения.

Я расскажу об инструменте, позволяющем не только смотреть, но и изменять Product Policy, поговорим о Product Policy Editor, рассмотрим, где хранятся текущие значения Product Policy в Windows, и почему они возвращаются к исходным значениям, ну и, конечно, о том, можно ли как-то поменять это всё раз и навсегда для своей ОС, навсегда отключив нелюбимый Defender, разрешив неограниченное количество RDP сессий.  Ну и, конечно, cделаем ранее невозможное — добьёмся русского интерфейса для интересного издания, описанного мной в наделавшей шума статье Windows 11 Enterprise G – Что за издание для правительства Китая и зачем оно вам? Судя по огромному интересу читателей именно к Windows Enterprise G, я начну с неё, а другие аспекты Product Policy, сравнение параметров между изданиями расскажу в другой статье, там же поясню свою мысль о том, что теперь «все издания нужны, все издания равны», — мы можем включить ранее выключенные и отключить ненужные компоненты в любых изданиях, например, разрешить многое в самом лёгком Starter, или поотключать ненужное в любимом мной IoT Enterprise LTSC.

Сегодняшний разговор пойдет о том, как правильно следует устанавливать 64-битную Windows 11 поверх ранее установленной 64-битной операционной системы Windows 7, 8, 10 или 11. Не пропагандирую переход на Windows 11, — выбор за вами, если это вам не нужно, ради бога, — но давайте поможем тем кто хочет это сделать, но встречается с разными сложностями на пути. Хотя при этом, заметка в целом полезна и тем, кто использует, и планирует далее использовать устаревшие системы, — рассказанный мной способ установки ОС «поверх» или «апгрейд» в целом общий для всех версий Windows, я лишь буду отмечать тонкости ранее мне не встречающиеся. Чего еще не будет в этой статье, так это вопросов совместимости с ПО и железом, — такое коротко и обобщенно не описать, решать нужно конкретно поставленную задачу. Обновлять ОС на совсем уж старом железе, наверное, нецелесообразно, а способов заставить работать древний софт на современных ОС известно много, но они тоже подбираются под нужды.

Собственно, начать об обновлении ОС я хочу с того, что Microsoft всегда имеет «матрицу обновляемости» (upgrade matrix) и четкие правила того, что на что может быть обновлено. Начнем с матрицы (а как иначе, Нео?). В любой версии и издании Windows в папке C:\Windows\servicing\Editions лежит файл UpgradeMatrix.xml, в котором четко прописано, с каких версий и изданий вы можете выполнить обновление на данную систему. Для ОС, которая в ISO образе, или на установочной флешке, этот файл лежит внутри install.wim, его проще всего открыть 7zip архиватором и посмотреть, если есть интерес. Разбирать его детально я сегодня не буду, это скучная задача, поговорим о сложностях, возникающих при обновлении ОС.

Статистические исследования и эксперименты являются краеугольным камнем развития любой компании. Особенно это касается интернет-проектов, где учёт количества пользователей в день, времени нахождения на сайте, нажатий на целевые кнопки, покупок товаров является обычным и необходимым явлением. Любые изменения в пользовательском опыте на сайте компании (внешний вид, структура, контент) приводят к изменениям в работе пользователя и, как результат, изменения наблюдаются в собираемых данных. Важным элементом анализа изменений данных и его фундаментом является использование основных типов распределений случайных величин, от понимания которых напрямую зависит качество оценки значимости наблюдаемого изменения. Рассмотрим их подробнее на наглядных примерах.

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.

DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справиться (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.