• С какой литературы можно начать изучение системного администрирования?

    athacker
    @athacker
    Нет такой магической "одной" книги :-) Администрирование -- это работа с кучей СИСТЕМ, ПОДСИСТЕМ, СЕРВИСОВ И ПРОТОКОЛОВ. И по каждому из представителей вышеперечисленного написано по десятку и более довольно толстых книг. А чтобы ковырять домашний сервак -- да, можно обойтись несколькими книжками. Но одной -- точно нет.

    Так как... Ну, допустим, начали вы ставить линукс. Сразу начинаются вопросы: "а как разбивать диск?" "GPT или MBR"? Начинается чтение мануалов, а чем GPT отличается от MBR. Следующий же вопрос, тоже по диску: "А какую файловую систему делать? Ext3/ext4/xfs/btrfs/zfs/ufs? Начинается чтение, какие файловые системы поддерживает та ОС, которую вы ставите, чем они отличаются и какая из них предпочтительнее конкретно для вашего сценария.

    Потом настройки сети. Нужен IP-адрес. Что такое IP-адрес, для чего он предназначен, и какой нужно присваивать данной конкретной машине? А как она потом будет выходить в интернет. Если я назначу динамический адрес -- откуда он будет браться? Самозародится ли он у меня в сети, или нужно будет что-то предварительно сделать. О, какая-то новая аббревиатура: DHCP. Это чо такое?! И начинается чтение про DHCP...

    ОК, у меня дома роутер, он умеет DHCP и вроде как всё настроено. Если я на серваке выставлю "получать адрес по DHCP", то не будет проблем? По идее, не должно... " Через несколько дней: "О-па, а почему это сервак не отвечает на том IP, который у него был позавчера?!

    Допустим, систему вы поставили. Надо как-то ею управлять, чтобы каждый раз не бегать к серверу. А чо за слово такое -- SSH? Как его использовать, чем подключаться? Ага, putty... А чего это я при логине ввожу root и пароль, а оно меня не пускает?!

    Ну, и так далее, идею дальше развивать не буду :-) Домашний сервер сделать -- это похвальное желание, но до системного администрирования там ещё очень и очень далеко. К тому же, вы не указали, какую ОС собираетесь на этот сервак ставить.

    P/S/: Да, и "хочу разбираться в железках лучше" -- это слегка ортогональная ко всему вышеперечисленному тема, там свои ветвления наборов знаний со своими граблями :-)
    Ответ написан
    Комментировать
  • О Docker или отличие от виртуальной машины и немного о Vagrant...?

    @bamaz
    Хотелось бы узнать в чем различие между Virtualbox(VMware) и Docker?


    Docker - строгая изоляция ресурсов внутри операционной системы Linux.
    Не более того. То есть бинарный файл запускается в той же ОС, но не имеет доступа за пределы выделенной ему клетки. Программа (одна-единственная вообще говоря в Докер предполагается программа) может иметь свои-собственные зависимости, более того, допускается использование совсем другой версии Linux внутри Докер-контейнера.

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

    Это делается на уровне API ОС, следовательно, довольно не накладно по производительности. Правда, при неграмотном использовании (когда в качестве предков в образе используются разные образы) накладно по расходу дискового пространства.

    В частности Docker умеет запускать только Linux из под Linux, причем не какие угодно версии годятся, в контейнере Докера может быть только специально подготовленная (облегченная). В других OC - Windows, MacOSX - Докер реализован как полноценная виртуальная машина с Линуксом, следовательно, жрет ресурсов много.

    VirtualBox - это настоящая виртуальная машина, то есть внутри может быть действительно совершенно другая ОС. Не только Linux. Полная изоляция вплоть до эмуляции аппаратных портов-ввода вывода. Изоляция более строгая. Но требует намного больше ресурсов.

    Запуск виртуальной машины сопряжен со значительными затратами времени. Лучшие виртуальные машины откусывают не менее 15% производительности....

    Запуск программы в Docker - сопоставим с запуском обычного бинарного файла внутри обычного операционного окружения (если уж быть точным - то чуть больше, но незначительно).

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

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

    Если я правильно понимаю, я могу и там и там поднять любую ОС, к примеру ту же Ubuntu и LAMP.


    Внутри Докера - далеко не любую. Выбор ограничен считаным числом специально подготовленных дистрибутивов Линукса.

    Внутри Virtual Box - действительно любую.

    Только разница в том что к Docker я буду иметь доступ сразу же из bash, а к VB через её окно или ssh,


    То, что вы хотите и через Virtual Box легко реализуется с помощью инструмента Vagrant. Будет иллюзия, что вы в Докере работаете.


    плюс если я выйду то в виртуалке все сохранится, а в Docker без коммита все умрет? Или есть другие важные отличия...?


    То, что вы имеете ввиду - можно сделать и внутри полной виртуалки - отключить персистентное сохранение на диски.
    То, о чем вы пишете - это просто концепция стейтлесс-контейнеров. То есть внутри все настроено раз и навсегда. Все изменения контейнер Докера должен делать только на смапированных внешних девайсах. Это гарантирует постоянство внешней среды для программы внутри Докер-контейнера. Крайне важно для повторяемости в продакшене. Чтобы не пришлось в 3 ночи просыпаться и искать отчего ваш сайт с миллионой посещаемостью перестал работать. Ах это потому что какая то софтина не имеющая отношения к вашей программе обновилась и потянула за собой библиотеку, не соместимую по версией с тем, что вы используйте.

    Пишут что Docker активно применяется при программировании и переносе workstations. Тоесть имеется ввиду, я могу работать с кодом прямо в docker image, после коммитить, пушить, а затем все это запускать на сервере без установки зависимостей?


    Нет.
    Концепция повторяемости такова.
    Вы программируете и дизайнере и верстаете как обычно.
    Результат своей работы вы помещаете в контейнер - отлаживаете в контейнере.
    На сервере используется тот же контейнер.
    Это гарантирует какую-то повторяемость условий при которых велась отладка и при которых будет работать все в продакшне.

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

    Vagrant, насколько я понимаю активно применяется при создании images и конфигурировании их же?


    При разработке - да.
    Так как ты можешь работать в несовместимой с docker средой (например, в Windows) и отладка возможна только через виртуальную машину.

    В продакшене - нет. Так как слишком большие накладные расходы на виртуальную машину.

    И последнее, могу ли я:
    Запустить image в Linux, сделать правки в коде (кстати как это сделать, к примеру в том же *storm, Sublime. ... ) и закоммитить.
    После войти в Windows, запустить image и там продолжить разработку?


    Думаю да,
    но это не то, для чего создавался Докер.

    А написание кода внутри виртуальной машины - возможно. Я сам так делаю.
    Ответ написан
    Комментировать
  • Как научиться алгоритмическому мышлению?

    max-kuznetsov
    @max-kuznetsov
    Главный IT-архитектор
    Бьёрн Страуструп, описывая C++, говорил: "Язык программирования служит двум связанным между собой целям: он является выразительным средством программиста для указания действий, которые надо выполнить, а также набором концепций, которыми пользуется программист при решении проблемы." Но язык программирования точно не является решением проблемы, он только средство выражения и инструмент. Поэтому для начала давайте оставим в стороне программирование.

    С остальным всё просто. Программисту часто не хватает некоторой "прелюдии", позволяющей перебросить мостик между идеей программы и написанием кода. Мостик этот строится так:

    1. Имеем некоторую идею: "а хорошо бы написать программу, которая делала бы...".
    2. Определяете предметную область с теми процессами, которые имеют отношение к разрабатываемой программе.
    3. Формулируете цель проекта: как программа должна повлиять на предметную область (не вдаваясь в реализацию).
    4. Формулируете бизнес-задачи, решение которых позволят достичь поставленной цели.
    5. Указываете ограничения, в рамках которых будет создаваться программа.
    6. Создаёте концепцию - некое видение того, какой будет новая программа, без технических деталей.
    7. Решаете, а нужна ли такая программа?
    8. Если нужна, то прорабатываете одно или несколько технических решений, как можно сделать программу. Делаете оценки реализуемости и оставляете одно решение.
    9. Разрабатываете детальные требования к вашей программе.
    10. Создаёте архитектурное решение, логическое и физическое.
    11. Проводите детальное проектирование каждого компонента вашей архитектуры.
    12. Программируете, тестируете, отлаживаете код.
    13. И - ура! - внедряете программу.


    Это выглядит сложным. Но не очень сложно.

    Как я смотрю на весь этот процесс, можете посмотреть тут: Обзор процесса разработки программного обеспечения. Краткий академический обзор всего процесса можно найти в книге Макконнелла "Остаться в живых. Руководство для менеджеров программных проектов" - книга небольшая, для начала самое то.
    Ответ написан
    1 комментарий
  • Что лучше canvas или svg?

    @Sashjkeee Куратор тега CSS
    f-e
    Плюсы Canvas:
    • Высокая производительность при отрисовке любых 2D объектов.
    • Стабильная производительность — всё есть пиксель. Производительность падает только при увеличении разрешения изображения.
    • Лучше всего подходит для создания растровой графики (например, в играх, фракталов и т.п.), редактирования изображений и операций, требующих манипулирования на уровне пикселей.
    Плюсы SVG:
    • Нет зависимости от разрешения — SVG лучше подходит для кроссплатформенных пользовательских интерфейсов, так как позволяет масштабировать изображение при различных разрешениях экрана.
    • SVG очень хорошо поддерживает анимацию. Элементы могут быть анимированы с использованием описательного синтаксиса или с помощью JavaScript.
    • Можно получить полный контроль над каждым элементом, используя SVG DOM API в JavaScript.
    • SVG хранится в формате XML, что предоставляет больше возможностей браузерам по обеспечению доступности SVG документов по сравнению с элементом canvas. Таким образом, SVG выглядит лучшим решением для пользовательских интерфейсов веб-приложений.
    Минусы Canvas
    • Отрисовка основана на пикселях.
    • Не существует API для анимации. Вам придется прибегать к использованию таймеров и других событий для обновления канвы.
    • Слабые возможности по рендерингу текста.
    • Возможно, не самый лучший выбор, когда доступность имеет решающее значение. Канва предоставляет вам поверхность для рисования в выбранном контексте (2D и 3D). Можно указать альтернативный контент внутри элемента canvas, который будет показан браузером при невозможности отображения графики. Кроме того, вы можете выполнить проверку доступности выбранного Canvas API с помощью JavaScript. На основе этого вы можете обеспечить различную функциональность для пользователей браузеров с разной поддержкой HTML 5 Canvas.
    • HTML 5 Canvas не подходит для создания веб-сайтов или интерфейсов веб-приложений, так как пользовательские интерфейсы обычно должны быть динамическими и интерактивными, а Canvas требует от вас постоянной перерисовки каждого элемента в интерфейсе.
    Минусы svg
    • Низкая скорость рендеринга при увеличении сложности документа (рисунка), так как используется модель DOM
    • Скорее всего, SVG не подходит для таких приложений как игры. Возможно лучшим выбором будет комбинация HTML Canvas + SVG.
    Вывод
    HTML 5 Canvas следует использовать для:
    1. Редактирования изображений: обрезки, изменения размеров, фильтров (удаления эффекта красных глаз, создания эффекта сепии, изменения цветности или яркости)
    2. Создания растровой графики: визуализации данных, создания фракталов и графиков функций.
    3. Анализа изображений: создания гистограмм и т.п.
    4. Создания игровой графики, такой как спрайты и фоны.
    SVG следует использовать для:
    1. Создания пользовательских интерфейсов веб-приложений, независимых от разрешения экрана.
    2. Высокоинтерактивных анимированных пользовательских интерфейсов.
    3. Графиков и диаграмм.
    4. Редактирования векторных изображений.
    честно скопипастил
    Ответ написан
    Комментировать
  • Как разбить большой файл в node.js на несколько поменьше?

    MarcusAurelius
    @MarcusAurelius Куратор тега Node.js
    автор Impress Application Server для Node.js
    Этот вопрос более общий, чем Ваш случай с node.js и даже более общий, чем JavaScript вообще. Хорошо разделить свой код на части, выделить абстракции, дать им названия и объединить их в одно целое - это одна из главных задач программиста на любом языке.

    Я сначала отвечу на частный вопрос по Node.js и JavaScript, а потом объясню эту тему глубже. Для Node.js есть require, при помощи которого можно импортировать из других модулей. Это реализация Dependency Lookup, т.е. мы имеем несколько модулей и каждый из них знает, от каких он зависит и может запросить менеджер зависимостей дать ссылку на то, что экспортирует другой модуль (в данном случае файл). Например, мы можем сделать require('./matrix.js') или require('./lib/matrix.js') и таким образом получим ссылку на то, что экспортирует matrix.js через module.exports = { ... };. Пример кода с импортом: names.js

    В этот самый module.exports мы отдаем ссылку на функцию ил на объект или массив, который содержит все, что мы хотим экспортировать (можно экспортировать и скалярное значение, но это практически не нужно). В подавляющем большинстве случаев экспортируют объект (используя его как справочник экспортируемых идентификаторов), чуть реже одну функцию (иногда фабрику или функцию обертку) или конструктор прототипа (или класса). Пример кода с экспортом: lib/submodule2.js

    Но можно импортировать зависимости целыми массивами, например тут: main.js Если посмотреть чуть шире ноды, на JavaScript, то есть способ импорта/экспорта через ключевые слова import и export. Примеры: import.mjs и export.mjs

    Документацию модно почитать тут:
    1. Модули для Node.js через require/module.exports: https://nodejs.org/api/modules.html
    2. Модули для Node.js через import/export: https://nodejs.org/api/esm.html
    3. Модули для JavaScript через import/export: https://developer.mozilla.org/en-US/docs/Web/JavaS... и https://developer.mozilla.org/en-US/docs/Web/JavaS...

    Но это все техническая реализация, гораздо важнее то, как мы разбиваем наш код на модули или абстракции. Тут нужно ввести понятие связывание и классифицировать методы связывания (частей кода):
    1. Через общие данные (самое жесткое связывание)
    2. Через вызовы (обычно между модулями с экспортом и импортом)
    3. Через события (самое легкое, между слабосвязанными программными компонентами)

    Если из разных функций, прототипов и классов (их методов) Вы обращаетесь к одним и тем же данным, а тем более, меняете их, то это очень плохо. Могут быть общие идентификаторы такие, но это только константы, которые не меняются из разных мест. Могут быть группы функций, которые должны видеть одну переменную и менять ее, но их нужно объединять друг с другом через замыкания и частичное применение. И такие, связанные через данные конструкции (сильно связанные) должны находиться только внутри одного файла. Изменение одних и тех же данных из разных мест, может привести к формированию сложного и непредсказуемого состояния, а в конечном итоге к ситуациям, когда комбинаторный взрыв состояния не может быть адекватно обработан программой, все случаи просто не покрыты условиями и мы даже не можем себе представить и учесть в коде все случаи.

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

    Наименее жесткий способ связывания - через события. Тут один программный компонент (модуль, класс, прототип, функтор) может подписаться на события другого или вызывать события у себя или в другого не ожидая, что там есть подписчики. Конечно тут могут быть проблемы с контрактами событий, т.е. именами и форматами данных, они все указаны не жестко и тут может быть много ошибок. Это очень гибкий способ, но он таит в себе потенциальные проблемы совместимости. Так что, где можно обойтись вызовами, то лучше не использовать события.

    Есть еще один средний способ между вызовами и событиями, это callback (и listener). При помощи него события и сделаны, практически, в метод .on(name, callback) (или его аналоги) передается функция callback в качестве аргумента. На этом способе построено асинхронное программирование, в том числе такие способы связывания, как асинхронная последовательная композиция и асинхронная параллельная композиция функций, чеининг и промисы.
    Ответ написан
    1 комментарий
  • Какой выбрать язык для серверной части highload проекта?

    voidnugget
    @voidnugget
    Программист-прагматик
    Когда люди называют 1Гбит динамического http трафика highload'ом - это вызывает у меня довольно нелепую ухмылку.

    Сравнивать php / python / ruby более-менее целесообразно так как это полностью интерпретируемые языки с кэшированием байткода, иногда с оптимизациями, как в случае с jRuby и Project Graal. Обычно такие вещи помирают на 14-17К запросов в секунду с пустыми ответами... В общем на одном гигабите трафика тут обычно всё и заканчивается. Node.js по производительности более корректно сравнивать с JVM языками типа Groovy или Scala, но никак не с самой Java. На практике через Netty на Disruptor'е под offheap'ом и Terracotta можно пропустить и 40Гбит живого трафика, без статики, - главное правильно профилировать и писать прямо pfRing.

    Почти в каждом случае где есть сборка мусора нужно использовать offheap кэширование, или любые другие методы контроля роста кучи. Во время самой сборки в очень больших (16Гб и более) старых поколениях возникают проблемы с планировщиками и контролем приоритетов - в итоге получаем очень большое, критическое, увеличение текущих задержек на обработку запросов.

    Если вы хотите строить что-то действительно стоящее - стоит смотреть в сторону CQRS-ES'a и реактивных приложений в рамках SOA. Возможно внедрение микросервисных архитектур если нет требований к задержкам на выполнение запросов. Но, учитывая что вы задаёте здесь вопросы о том "что лучше node.js или python" не думаю что у вас хватит опыта для построения подобных вещей.

    Можно пробовать golang - яндекс слез с python'a на golang по причине слоупочности оного, и довольно хорошо так слез. В golang'е сейчас самый лучший RAD, гораздо круче того же node.js. Идеоматичность самого языка решает достаточно много потенциальных проблем ещё на этапе разработки. Да и сообщество сейчас довольно активно пилит его runtime - внедряют многопоточный gc и ещё пару вкусностей. Даже не умея всех этих асинхронностей и прочей лабуды с golang'ом можно получить довольно хороший выхлоп. Правда меня немного смущает отсутствие нормальных datamapper'ов и scaffolding'a под golang.
    Ответ написан
    16 комментариев