Литиевые батарейки (те, что на матплатах стоят) и аккумуляторы дают около трёх вольт. Теоретически на реакции литий-фтор можно получить 5,9 вольт, но я сомневаюсь, что такие элементы вобще можно сделать.
В книге, по крайней мере в моём издании, он предлагает выбирать только из двух вариантов («египетский» и с отступом перед скобкой), ещё один называет приемлимым только в некоторых случаях, и ещё два не рекомендует использовать.
Вобще то, я тоже открывал книгу, прежде чем писать комментарий. Второе издание (Питер 2005) 729 страница:
Избегайте отсутствия отступов в парах begin-end В стиле форматирования, проиллюстрированном в листинге 31-24, пара begin-end выровнена по границе управляющей структуры, а в выражениях, охватываемых операторами begin и end, сделаны отступы относительно begin.
Листинг 31-24. Пример пары begin-end, не выделенной отступами (Java)
//Ключевое слово begin выровнено по границе for.
for(int i = 0; i < MAX_LINES; i++ )
{
//В выражениях сделан отступ относительно begin.
Readl_ine( i );
Processl_ine( i );
//Слово end также выровнено по границе структуры for.
}
Хотя такой подход выглядит хорошо, он нарушает Основную теорему форматирования, так как не показывает логическую структуру кода. При таком расположении begin и end не являются частью управляющей структуры, но в то же время, они не являются и частью блока выражений, расположенного далее.
Пока писал на c++ и c# — пользовался таким стилем. Сейчас перешёл на java и «египетский» мне кажется гораздо нагляднее. Опять же, Макконел в «Совершенном коде» так ругается:
Хотя такой подход выглядит хорошо, он нарушает Основную теорему форматирования, так как не показывает логическую структуру кода. При таком расположении begin и end не являются частью управляющей структуры, но в то же время, они не являются и частью блока выражений, расположенного далее.
где в итоге не пришли бы к прямому выполнению SQL-запросов
Вот, мне чем не нравится hibernate, так это тем, что он скрывает синтаксис sql. В паре мелких проектовал использовал iBatis — очень понравилось. Там всё основано именно на sql — есть средства для динамической генерации, разных комбинациях запросов, ОРМ не лезет дальше отображения строк в объекты. Конечно, там тоже проблем хватает, и 3-beta, которую я в последний раз использовал была весьма глючной, но надеюсь, что её доведут до ума. Сам пока что эксперементирую с no-sql базами.
Да нет, я всего лишь к тому, что кривой код можно написать на чем угодно
А, тогда ладно, а то я уж было подумал, что вы наш код заочно кривым обозвали =)
их трудно хранить в текстовых файлах
Чем?
Пример: заказчик захотел добавить новое поле к учётке пользователя. Нужно добавить поле в таблицу, новый параметр в пару процедур и слегка переделать триггер. Составить скрипт миграции — проще некуда (alter table, alter proc ...). Однако, добавив этот скрипт в систему контроля версий, мы не получим ясной истории изменений (старые файлы не изменились, лишь добавился один новый). Определение объектов базы будет «размазано» по нескольким файлам. Фактически, после нескольких доработок, весь код базы данных оказывается случайным образом распределён по нескольким скриптам. Если пойти другим путём и всегда хранить определение объекта в одном файле, то придётся как-то определять порядок выполнения скриптов.
Просто потому, что маппинг множеств и отношений между множествами в объекты влечет кучу проблем.
Да, это так. Но если в вашем приложении используется ООП, то без орм не обойтись по определению. Я не буду спорить насчёт обоснованности применения ООП как такового — очень холиварная тема.
Ну, конечно, ОРМ обеспечивает все буковки аббревиатуры гораздо лучше, чем сама СУБД.
Атомарность, изоляция и долговечность обеспечиваются субд в пределах одной транзакции. Все ОРМ умеют нормально работать с транзакциями. Согласованность можно обеспечить централизованным кэшем, или вобще отключить кэширование вне транзакций. Я в чём-то не прав?
По-моему спор становится немного бессмысленным. У вас есть положительный опыт, у меня отрицательный. Сейчас мне гораздо приятнее работать с обычными трехзвенными системами (особенно когда заказчик слабо представляет, чего хочет).
Не, я не могу, это был сарказм. Просто у вас второй и третий пункты тоже очень категоричны.
Про массивы — ладно, в реляционной модели данных всегда можно без них обойтись.
Про остальное отвечу выше.
И переменные там тоже нафиг не нужны! Даёшь истинно функциональный sql с лямбдами и монадами!
Нормально спроектированная система не нуждается не только в миграции, но и в отладке, тестировании и внедрении. Она решает все проблемы юзера ещё в виде диаграмм.
Да при чём тут orm? Это всего лишь симтом. Вся идея ООП — полный отстой.
Взаимодействие кучи кривонаписанного кода приводило к трудноотлавливаемым багам
А, да, я и забыл, что тру-программисты сразу пишут идеальный код, правят чужие баги по скриншоту и уже забыли, что такое дебаггер) Ничего, я тоже когда-нибудь выучусь!
Отсутствие возможности поООПить — ужасно
ООП? А что это? Я чего-то читал про разные автомобили и всяких млекопитающих, но так и не понял. Мне просто не нравится sql в императивном стиле, глаза об него ломаются, боюсь инвалидом стать)
По существу:
Текстовые файлы очень неудобно хранить в системе контроля версий
Да, затупил. Процедуры не трудно хранить в скв, их трудно хранить в текстовых файлах. Это одна из проблем, которую с переменным успехом решают системы миграций.
Мне пофиг на производительность, ACID и прочую фигню. Да и с SQL у меня плохо
Вы, наверно, не знаете, что кроме hibernate есть много других orm, не столь тормозных и без костылей в виде hql. Да, если не секрет, каким боком orm может нарушить acid принципы в субд?
Я так понимаю, у вас есть положительный пример использования бизнес-логики в базе данных. Поделитесь, если не трудно, а то у меня пока что только отрицательные.
Писал аналогичную платёжную систему. Тоже использовал минимум кода на веб-сервере и всю логику реализовывал в базе данных. Поначалу всё было очень логично и аккуратно. Со временем вылезли следующие проблемы:
— код всех этих хранимых процедур очень неудобно хранить в системе контроля версий (есть костыли вроде autobase, но они здорово усложняют разработку)
— взаимодействие кучи хранимых процедур приводило к трудноотлавливаемым багам и дедлокам (на mssql2005)
— код бизнес-логики на tsql ужасен. Ну не предназначен sql для императивного программирования — костыли на каждом шагу
— всё это усугублялось парой неудачных решений в структуре таблиц, которые невозможно было исправить из-за множества зависимостей в процедурах. Всё было бы гораздо проще при использовании orm-прослойки.
Больше никогда так не буду делать!)
Если хочется безопасности — лучше использовать отдельные сервера для сайта и для системных api.
> обрабатывать необходимые исключения в порядке важности, а все остальные — с помощью общего Exception.
Это некрасивый костыль, Pokemon Exception Handling
Посчитал. Ёмкость металлического шарика диаметром 20 сантиметров (для пластины считать лениво) — порядка 10^-11 фарад. Ёмкость плоского конденсатора для пластины 0,1 кв.м. на расстоянии 0,5м от земли — порядка 1,5 * 10^-12 фарад. Так что эффект сферического конденсатора заметно больше, причём он не изменится при любом удалении от земли.
Правда, при таких параметрах, на частоте 15кГц сопротивление линии составит порядка 10^6 ом. Для питания слабо пригодно. Сопротивление обратно пропорционально диаметру сферического противовеса, так что заметно снизить его не получится.
Насчёт «однополярного» конденсатора я немного нафантазировал, правильно он называется сферический, и да, зачастую «в вакууме»). По такому запросу ссылок в поисковиках будет вполне достаточно. Правда я несколько переоценил его ёмкость, сейчас посчитаю, как оно на самом деле работает.
Вы неправы. В приведённой вами ссылке есть формула рассчёта реактивного сопротивления. Если вы не поленитесь хотя-бы примерно определить ёмкость такого «конденсатора», то получите _очень_ большое реактивное сопротивление на звуковых частотах.
Пластина и земля в данном случае являются раздельными _однополярными_ конденсаторами (в школе мимо этого классе в девятом проходят). Их можно разнести на сотню километров и эффект не ослабнет (если, конечно, забыть про индуктивность провода).
Вы немного неправы. Самым ядовитым веществом в атмосфере пандоры является синильная кислота (hydrogen cyanide, в вики написано). Симптомы отравления совпадают, правда синильная кислота также воздействует на кожу. Я не особо интересовался концентрациями, возможно земляне нашли какой-то способ защитить открытые части тела.
if (a && b && c && d && e && f) { blah-blah-blah }тоже не очень красиво, но привыкается быстро.
Хотя такой подход выглядит хорошо, он нарушает Основную теорему форматирования, так как не показывает логическую структуру кода. При таком расположении begin и end не являются частью управляющей структуры, но в то же время, они не являются и частью блока выражений, расположенного далее.
void foo() { bar(); }Пример: заказчик захотел добавить новое поле к учётке пользователя. Нужно добавить поле в таблицу, новый параметр в пару процедур и слегка переделать триггер. Составить скрипт миграции — проще некуда (alter table, alter proc ...). Однако, добавив этот скрипт в систему контроля версий, мы не получим ясной истории изменений (старые файлы не изменились, лишь добавился один новый). Определение объектов базы будет «размазано» по нескольким файлам. Фактически, после нескольких доработок, весь код базы данных оказывается случайным образом распределён по нескольким скриптам. Если пойти другим путём и всегда хранить определение объекта в одном файле, то придётся как-то определять порядок выполнения скриптов.
Да, это так. Но если в вашем приложении используется ООП, то без орм не обойтись по определению. Я не буду спорить насчёт обоснованности применения ООП как такового — очень холиварная тема.
Атомарность, изоляция и долговечность обеспечиваются субд в пределах одной транзакции. Все ОРМ умеют нормально работать с транзакциями. Согласованность можно обеспечить централизованным кэшем, или вобще отключить кэширование вне транзакций. Я в чём-то не прав?
По-моему спор становится немного бессмысленным. У вас есть положительный опыт, у меня отрицательный. Сейчас мне гораздо приятнее работать с обычными трехзвенными системами (особенно когда заказчик слабо представляет, чего хочет).
Про массивы — ладно, в реляционной модели данных всегда можно без них обойтись.
Про остальное отвечу выше.
Нормально спроектированная система не нуждается не только в миграции, но и в отладке, тестировании и внедрении. Она решает все проблемы юзера ещё в виде диаграмм.
Да при чём тут orm? Это всего лишь симтом. Вся идея ООП — полный отстой.
ООП? А что это? Я чего-то читал про разные автомобили и всяких млекопитающих, но так и не понял. Мне просто не нравится sql в императивном стиле, глаза об него ломаются, боюсь инвалидом стать)
По существу:
Да, затупил. Процедуры не трудно хранить в скв, их трудно хранить в текстовых файлах. Это одна из проблем, которую с переменным успехом решают системы миграций.
Вы, наверно, не знаете, что кроме hibernate есть много других orm, не столь тормозных и без костылей в виде hql. Да, если не секрет, каким боком orm может нарушить acid принципы в субд?
Я так понимаю, у вас есть положительный пример использования бизнес-логики в базе данных. Поделитесь, если не трудно, а то у меня пока что только отрицательные.
— код всех этих хранимых процедур очень неудобно хранить в системе контроля версий (есть костыли вроде autobase, но они здорово усложняют разработку)
— взаимодействие кучи хранимых процедур приводило к трудноотлавливаемым багам и дедлокам (на mssql2005)
— код бизнес-логики на tsql ужасен. Ну не предназначен sql для императивного программирования — костыли на каждом шагу
— всё это усугублялось парой неудачных решений в структуре таблиц, которые невозможно было исправить из-за множества зависимостей в процедурах. Всё было бы гораздо проще при использовании orm-прослойки.
Больше никогда так не буду делать!)
Если хочется безопасности — лучше использовать отдельные сервера для сайта и для системных api.
Это некрасивый костыль, Pokemon Exception Handling
Правда, при таких параметрах, на частоте 15кГц сопротивление линии составит порядка 10^6 ом. Для питания слабо пригодно. Сопротивление обратно пропорционально диаметру сферического противовеса, так что заметно снизить его не получится.
Пластина и земля в данном случае являются раздельными _однополярными_ конденсаторами (в школе мимо этого классе в девятом проходят). Их можно разнести на сотню километров и эффект не ослабнет (если, конечно, забыть про индуктивность провода).