Docker, как я понимаю, оперирует содержимым контейнеров LXC или OpenVZ? Возможно, стоит попробовать. Либо написать свои скрипты для деплоя в контейнеры.
Но беспокоит вопрос использования дискового пространства. Серверные диски желательно экономить.
Насчёт монструозности − там по ссылке автор приводит зачем-то конфигурацию железа, но вообще ничего не пишет про конфигурацию Apache и nginx. Скорее всего, он действительно сравнивает nginx с mpm-prefork, на что ему и попеняли в комментариях.
Вот, на мой взгляд, несколько более корректное сравнение. В нём, по крайней мере, говорится о том, какой модуль использовался. Стабильный mpm-event и nginx идут ноздря в ноздрю.
Ну, я его особо и не рассматриваю в роли фронтенда. Хотя, с другой стороны, чем не фронтенд? Монструозность Apache сильно преувеличена, зато в его конфигурацию намного проще въехать, чем в конфиг того же nginx.
А если к этому добавить ещё и сборку в пакеты всех библиотек, которые есть в PyPy/Registry, но нет в репо целевой ОС (целевых ОС), управление частным репо, управление ключами… Оно действительно вам надо?
Во всех этих ухищрениях с термосами и нагревательными элементами нет ни малейшего смысла. Свежесваренный кофе быстро окисляется, поэтому если забыл про свой напиток на 10-15-20-25-30 минут, в итоге будешь пить гадость − неважно, горячую или чуть тёплую. А растворимый можно и в микроволновке подогреть.
Я пробовал несколько билдов Ardour3, начиная от RC и включая релизы. Со сборкой проблем ни разу не возникало, но вот стабильность работы крайне огорчала. В итоге продолжаю юзать 2.8, и до 4 нескоро дойдут руки, наверное.
Пользуясь случаем, как говорится. Недавно вполне штатным образом деинсталлировал на десктопе сына ваш браузер («неизвестно как там оказавшийся», разумеется, но спишем это на возраст сына), и вследствие этого в рядом стоявшем Mozilla Firefox сломалась пустая вкладка (browser.newtab.url). Пожалуйста, сделайте так, чтобы деинсталлятор ваших продуктов возвращал все настройки в юзабельное состояние. А лучше вообще не трогайте настройки других браузеров, раз у вас есть свой.
А студенты-медики уже на первом курсе препарируют мышей. (А кое-где это делают и в школах.) И это, как ни странно, не «привязывает» их к мышам. Наоборот, помогает позже заняться более крупными существами, и даже человеком.
Начинать обучение программированию надо на простом, замкнутом и самодостаточном программно-аппаратном комплексе, например, «Электроника МК-52» или «Sinclair ZX-81». Когда ученик освоил программирование в машинных кодах с ассемблированием при помощи бумаги и ручки, можно переходить к Ассемблеру. Почему, кстати, этого языка нет в опросе? Начали бы с машинных кодов − не возникало бы дурацких вопросов типа «Как сделать окно с кнопкой». Ученики бы уже знали, что библиотеки и фреймворки не на деревьях растут.
Этот текст опубликован в блоге компании, которая материально заинтересована в том, чтобы люди физически передвигались. Общение «лицом к лицу» − хороший предлог для передвижения.
Ок. Чем точнее весы, тем меньше предельный вес. Полкило не взвесишь до стотысячной грамма. К тому же в химлабораториях обычно двое весов: одни для прикидки, другие для точного взвешивания того, что прикинули. На фото, видимо, засняли первые весы.
Имхо слишком провокационный заголовок. На первый взгляд создаётся впечатление, что вы призываете программистов не учить SQL, хотя без SQL в профессии вообще делать нечего.
ORM имеют множество достоинств, проявляющихся в длительной перспективе. Это прежде всего безопасность запросов (ORM обычно берёт на себя экранирование); потом представление параметров типами данных основного языка, без утомительной конверсии; автоматизация бэкапа и деплоя в условиях навороченных constraints; прозрачные кэширование данных и отложенные запросы; переносимость (если ORM работает с несколькими СУБД)… Что точно не является достоинством ORM − так это абстрагирование от SQL. Это даже скорее недостаток. В гипотетическом случае, когда достоинства ORM не востребованы, вызов SQL будет проще писаться, лучше читаться (SQL использует концепцию литературного программирования, если что) и работать производительней.
Кстати, в вашем случае я бы создал одну таблицу для мужчин, женщин и прочих гендеров-шмендеров, а соотношения many-to-many между ними так же реализовал бы в виде отдельной промежуточной таблицы. Нет никаких проблем в том, чтобы связи между строками одной таблицы задать в другой таблице, но об этом часто забывают. Считайте это пропагандой нетрадиционных отношений. :)
Но беспокоит вопрос использования дискового пространства. Серверные диски желательно экономить.
Уже нет. Как сейчас помню:
Хотя я ещё не настолько параноик, чтобы удалять gcc с сервера. Я вообще не помню ни одной массово эксплуатируемой уязвимости с участием gcc.
Вы правы, наверное. Дело привычки.
Насчёт монструозности − там по ссылке автор приводит зачем-то конфигурацию железа, но вообще ничего не пишет про конфигурацию Apache и nginx. Скорее всего, он действительно сравнивает nginx с mpm-prefork, на что ему и попеняли в комментариях.
Вот, на мой взгляд, несколько более корректное сравнение. В нём, по крайней мере, говорится о том, какой модуль использовался. Стабильный mpm-event и nginx идут ноздря в ноздрю.
Фреймворк − чаще всего Django.
божественнее, чем, скажем
А если к этому добавить ещё и сборку в пакеты всех библиотек, которые есть в PyPy/Registry, но нет в репо целевой ОС (целевых ОС), управление частным репо, управление ключами… Оно действительно вам надо?
как-то первый раз слышу. И вообще, часто встречаю virtualenv в продакшне, и мне он там вполне нравится.
Не могли бы вы обосновать этот пункт поподробнее или ссылочкой кинуть?
ORM имеют множество достоинств, проявляющихся в длительной перспективе. Это прежде всего безопасность запросов (ORM обычно берёт на себя экранирование); потом представление параметров типами данных основного языка, без утомительной конверсии; автоматизация бэкапа и деплоя в условиях навороченных constraints; прозрачные кэширование данных и отложенные запросы; переносимость (если ORM работает с несколькими СУБД)… Что точно не является достоинством ORM − так это абстрагирование от SQL. Это даже скорее недостаток. В гипотетическом случае, когда достоинства ORM не востребованы, вызов SQL будет проще писаться, лучше читаться (SQL использует концепцию литературного программирования, если что) и работать производительней.
Кстати, в вашем случае я бы создал одну таблицу для мужчин, женщин и прочих гендеров-шмендеров, а соотношения many-to-many между ними так же реализовал бы в виде отдельной промежуточной таблицы. Нет никаких проблем в том, чтобы связи между строками одной таблицы задать в другой таблице, но об этом часто забывают. Считайте это пропагандой нетрадиционных отношений. :)