Во всех этих ухищрениях с термосами и нагревательными элементами нет ни малейшего смысла. Свежесваренный кофе быстро окисляется, поэтому если забыл про свой напиток на 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 между ними так же реализовал бы в виде отдельной промежуточной таблицы. Нет никаких проблем в том, чтобы связи между строками одной таблицы задать в другой таблице, но об этом часто забывают. Считайте это пропагандой нетрадиционных отношений. :)
получить в итоге удалось не больше половины устройств
Как я понимаю, 50% — это отличная эффективность для венчурного финансирования. Говорят, у больших дядь не более 10% проектов взлетают. Грех жаловаться на кикстартеры.
Мне кажется, вы немножко лукавите, говоря о таких преимуществах ORM, как:
— Возможность вообще не знать SQL, т.к. прямого использования SQL нет.
— Не надо писать километровые запросы самому
Понять ORM без знания SQL невозможно. И SQL-код во всех примерах, кроме, пожалуй, самого простого JOIN, будет более компактным и удобочитаемым, чем обращения к ORM. SQL вообще очень литературен.
Хотя основного смысла применения ORM — писать на одном языке, а не на двух — я не отрицаю. И всё же ORM для более-менее сложной работы с данными — гиря на ногах.
ORM имеют множество достоинств, проявляющихся в длительной перспективе. Это прежде всего безопасность запросов (ORM обычно берёт на себя экранирование); потом представление параметров типами данных основного языка, без утомительной конверсии; автоматизация бэкапа и деплоя в условиях навороченных constraints; прозрачные кэширование данных и отложенные запросы; переносимость (если ORM работает с несколькими СУБД)… Что точно не является достоинством ORM − так это абстрагирование от SQL. Это даже скорее недостаток. В гипотетическом случае, когда достоинства ORM не востребованы, вызов SQL будет проще писаться, лучше читаться (SQL использует концепцию литературного программирования, если что) и работать производительней.
Кстати, в вашем случае я бы создал одну таблицу для мужчин, женщин и прочих гендеров-шмендеров, а соотношения many-to-many между ними так же реализовал бы в виде отдельной промежуточной таблицы. Нет никаких проблем в том, чтобы связи между строками одной таблицы задать в другой таблице, но об этом часто забывают. Считайте это пропагандой нетрадиционных отношений. :)
Как я понимаю, 50% — это отличная эффективность для венчурного финансирования. Говорят, у больших дядь не более 10% проектов взлетают. Грех жаловаться на кикстартеры.
— Возможность вообще не знать SQL, т.к. прямого использования SQL нет.
— Не надо писать километровые запросы самому
Понять ORM без знания SQL невозможно. И SQL-код во всех примерах, кроме, пожалуй, самого простого JOIN, будет более компактным и удобочитаемым, чем обращения к ORM. SQL вообще очень литературен.
Хотя основного смысла применения ORM — писать на одном языке, а не на двух — я не отрицаю. И всё же ORM для более-менее сложной работы с данными — гиря на ногах.