По первому вопросу я вам не помогу, у меня опыта с зашифрованными разделами нет. Скорее, всего, вам смогут помочь в Tg-чате NixOS RU.
По второму: сам я ставился с английским языком, потом в GUI зашёл в Settings/Keyboard и добавил там русский язык и раскладку. По умолчанию языки переключаются через Win+Space, но клавиши можно поменять.
Я менял через командную строку, потому что "моя" комбинация не ставится через GUI. Делал вот по этому ответу на Ask Ubuntu.
Да, обычно создают файл shell.nix, где получают пути к деривациям (пакетам) по именам.
Далее можно их добавить в существующие переменные окружения, либо описать новые. Я не силён в gcc, кажется, он использует переменные C_INCLUDE_PATH и CPLUS_INCLUDE_PATH.
Затем в каталоге запускаете nix-shell, выполняется shell.nix и у вас воссоздаётся нужная среда для разработки.
По первому вопросу — пакеты можно делать самостоятельно, так поступает большинство разработчиков. Для этого надо освоить язык программирования Nix и разобраться в деталях.
Есть неофициальная документация по этому вопросу, Nix Pills. Сейчас я её перевожу и публикую здесь на Habr. Можете прочитать быстро в оригинале, если владеете английским, или подождите, где-то в течение пары месяцев я закончу.
По второму вопросу — но машине одно хранилище пакетов Nix, в каталоге /nix/store, так что пакеты дублироваться не будут. Правда, есть тонкость. На обычных дистрибутивах, чтобы использовать Nix, надо зайти под пользователем nix. На NixOS это может быть действительно многопользовательская система.
С другой стороны, вам может быть, и не надо именно так детально управлять конфигурацией пользователей. В каждый проект можно сложить по файлу shell.nix. Перед работой запускать nix-shell, а по окончании выходить из него. В shell.nix описать, какие именно пакеты нужны для работы. Это окружение смогут разделить все участники проекта.
Обычно пакеты адаптируют к подходу Nix. Вы можете зайти сюда: https://search.nixos.org/packages и поискать там нужный пакет. Если он есть, то он адаптирован для работы в Nix. Конечно, конфиги не складывают в /etc/pkgname. Можно для конкретного проекта написать скрипт на языке Nix, который создаст конфиг, и этот конфиг будет доступен через переменную окружения. В других проектах будут свои скрипты, которые будут создавать своё окружение.
У меня просто есть история про разное понимание паттерна Unit of Work. Один участник дискуссии думал, что UoW это то же самое, что и транзакция и может быть вложенной. А другой опирался на описание паттерна в книге Фаулера. Там про вложенность ничего нет.
Вместо того, чтобы сократить время разговора, паттерн стал причиной спора. Поэтому не соглашусь с вами. Паттерны нужны для передачи информации о проектных решениях в коде. Если программисты будут понимать их по разному, неизбежны проблемы.
Да, тоже очень хорошая книга. Время от времени перечитываю любимые места. К сожалению, кажется, она всё-таки устарела даже как учебный курс. Но я бы рекомендовал её читать для расширения кругозора. Кнут очень эрудированный автор, кстати, владеет русским языком. И эта эрудиция очень заметна.
Не соглашусь. Паттерны придумывают люди для каких-то целей. И паттерны это всегда результат осмысления существующего кода, результат поиска закономерностей.
Описание паттерна очень важно для передачи смысла. Если вы дадите классу название OrderRepository, читатель вас поймёт. А вот если назовёте его OrderManager — то, скорее всего, нет. Manager может быть чем угодно.
Может быть, вы и правы. Но я Гради Буча очень давно не перечитывал, поэтому в фундаментальные книги и не записал. Мне кажется, его подход оказался слишком громоздким — предтечей современного кровавого энтерпрайза.
Вы правы, что хороших книг гораздо больше, чем здесь написано. Но объять необъятное нельзя, Козьма Прутков это точно установил.
Я сначала в заголовке написал, что речь про ООП и даже про .NET, но потом решил, что длинный заголовок зло, и перенёс ООП и .NET в хабы. Мне казалось, они бросаются в глаза и задают какой-то контекст.
Что касается SICP, то у меня несколько материалов, навеянных этой книгой. В частности, предыдущая статья на хабре.
По первому вопросу я вам не помогу, у меня опыта с зашифрованными разделами нет. Скорее, всего, вам смогут помочь в Tg-чате NixOS RU.
По второму: сам я ставился с английским языком, потом в GUI зашёл в Settings/Keyboard и добавил там русский язык и раскладку. По умолчанию языки переключаются через Win+Space, но клавиши можно поменять.
Я менял через командную строку, потому что "моя" комбинация не ставится через GUI. Делал вот по этому ответу на Ask Ubuntu.
Да, обычно создают файл shell.nix, где получают пути к деривациям (пакетам) по именам.
Далее можно их добавить в существующие переменные окружения, либо описать новые. Я не силён в gcc, кажется, он использует переменные
C_INCLUDE_PATHиCPLUS_INCLUDE_PATH.Затем в каталоге запускаете nix-shell, выполняется shell.nix и у вас воссоздаётся нужная среда для разработки.
Да, вопросы можно задать в группе Tg, посвящённой Nix и NixOS: https://t.me/ru_nixos
Я не на все могу ответить, потому что я программист и у меня конфиги очень простые, буквально на несколько строк.
По первому вопросу — пакеты можно делать самостоятельно, так поступает большинство разработчиков. Для этого надо освоить язык программирования Nix и разобраться в деталях.
Есть неофициальная документация по этому вопросу, Nix Pills. Сейчас я её перевожу и публикую здесь на Habr. Можете прочитать быстро в оригинале, если владеете английским, или подождите, где-то в течение пары месяцев я закончу.
По второму вопросу — но машине одно хранилище пакетов Nix, в каталоге /nix/store, так что пакеты дублироваться не будут. Правда, есть тонкость. На обычных дистрибутивах, чтобы использовать Nix, надо зайти под пользователем nix. На NixOS это может быть действительно многопользовательская система.
С другой стороны, вам может быть, и не надо именно так детально управлять конфигурацией пользователей. В каждый проект можно сложить по файлу shell.nix. Перед работой запускать nix-shell, а по окончании выходить из него. В shell.nix описать, какие именно пакеты нужны для работы. Это окружение смогут разделить все участники проекта.
Давайте так. Этот цикл переведу, за ним можно и flakes.
Обычно пакеты адаптируют к подходу Nix. Вы можете зайти сюда: https://search.nixos.org/packages и поискать там нужный пакет. Если он есть, то он адаптирован для работы в Nix. Конечно, конфиги не складывают в /etc/pkgname. Можно для конкретного проекта написать скрипт на языке Nix, который создаст конфиг, и этот конфиг будет доступен через переменную окружения. В других проектах будут свои скрипты, которые будут создавать своё окружение.
Преувеличиваю, конечно. Но мне сказали, что писать надо провокационно, иначе читать никто не будет. ?
Спасибо за спасибо! Очень приятно читать такие отзывы.
Не думали о карьере деврела? ?
Вы очень здорово расписали складскую задачу. Я бы тоже упор делал на алгоритмы, на численные методы и вот это вот всё.
А вот как раз вышла: https://habr.com/ru/company/itbrand/blog/721016/
Материал проработанный. Спасибо, теперь попробую этот Schema Registry куда-нибудь прикрутить и пощупать.
Здорово, что нашли. :) Осенние конференции сейчас и правда активно приглашают докладчиков.
В статье рекомендуется другая книга — Clean Archicteture.
У меня просто есть история про разное понимание паттерна Unit of Work. Один участник дискуссии думал, что UoW это то же самое, что и транзакция и может быть вложенной. А другой опирался на описание паттерна в книге Фаулера. Там про вложенность ничего нет.
Вместо того, чтобы сократить время разговора, паттерн стал причиной спора. Поэтому не соглашусь с вами. Паттерны нужны для передачи информации о проектных решениях в коде. Если программисты будут понимать их по разному, неизбежны проблемы.
С таким утверждением сложно спорить. :)
Ты думал, он только занудствует на тему тестов и чистоты кода? :)
Да, тоже очень хорошая книга. Время от времени перечитываю любимые места. К сожалению, кажется, она всё-таки устарела даже как учебный курс. Но я бы рекомендовал её читать для расширения кругозора. Кнут очень эрудированный автор, кстати, владеет русским языком. И эта эрудиция очень заметна.
Не соглашусь. Паттерны придумывают люди для каких-то целей. И паттерны это всегда результат осмысления существующего кода, результат поиска закономерностей.
Описание паттерна очень важно для передачи смысла. Если вы дадите классу название
OrderRepository, читатель вас поймёт. А вот если назовёте егоOrderManager— то, скорее всего, нет.Managerможет быть чем угодно.Может быть, вы и правы. Но я Гради Буча очень давно не перечитывал, поэтому в фундаментальные книги и не записал. Мне кажется, его подход оказался слишком громоздким — предтечей современного кровавого энтерпрайза.
Вы правы, что хороших книг гораздо больше, чем здесь написано. Но объять необъятное нельзя, Козьма Прутков это точно установил.
Я сначала в заголовке написал, что речь про ООП и даже про .NET, но потом решил, что длинный заголовок зло, и перенёс ООП и .NET в хабы. Мне казалось, они бросаются в глаза и задают какой-то контекст.
Что касается SICP, то у меня несколько материалов, навеянных этой книгой. В частности, предыдущая статья на хабре.