ни чем — это элемент автоматизации. :) при выходе из режима вставки (insert mode) плагин автоматически дергает за системный переключатель и переключает раскладку на английскую. при входе — восстанавливает в прежнее состояние.
А чем лучше? Мы не будем говорить про вычисления на калькуляторе, где «программа» живет лишь до получения первого результата. Давайте рассмотрим более привычную для разработчиков ситуацию ситуацию, когда программа должна использоваться и поддерживаться в течении продолжительного времени. Как это часто бывает, проходит полгода, и цены на яблоки вырастают на на 1 рубль. Этот факт нужно отразить в чудо-программе. Разумеется, предыдущего гения-программиста уже месяц, как схантил йандекс, и задачу предстоит решать другому. Что он видит? Он видит в коде две волшебные константы: что из них цена, которую нужно менять «1» или «3»? В исходнике нет ответа, поэтому он идет выяснять состояние прайса на яблоки в предыдущем периоде, проклиная всех долбаных гениев, решивших (уж не знаю чем вам этот код приглянулся) — допустим, сэкономить 10 секунд на написание 2 строчек проясняющего суть текста. :)
мне показалось, что упоминание Оккама/П.Д.О. было бы уместнее в предыдущей статье — про модульность. здесь же он ясности не добавил). в программировании нередко приходится добавлять обозначения для того, чтобы повысить ясность. сравните:
Исключения должны проектироваться не от кода, а от ситуаций,
которые вы хотите по-особенному обработать.
Исключения являются частью внешнего интерфейса. Т.е. это то, с чем будет
взаимодействовать _клиенсткий_ код (чужой — а не ваш). Вы не можете заранее предугадать, какие ситуации клиентский код «захочет»
обрабатывать «по-особенному». Соответственно — проектировать исключения исходя
из какой-то особенной обработки нет ни какого резона. Вы можете лишь обозначать
исключительные ситуации в той мере, в которой сочтете нужным
это требуется для обеспечения полноты модели предметной области.
из-за ошибки, эта версия не сохраняет изменения. правится в файле firefile@strebitzer.at/content/firefile.js, в строчке 718. - if(qpos !== false) { + if(qpos !== -1) {
2 пирата -> Главарь оставляет себе всё.
3 пирата -> 99, 0, 1 монет пиратам по старшинству. последний пират доволен, ведь иначе, если убрать главаря, то второй заберёт себе все
Когда 2 пирата все очевидно.
В случае с 3 пиратами решение слишком парадоксально. Мне кажется, что тут ошибка в рассуждении.
Задача пирата состоит не только в том, чтобы получить золото — он ещё должен остаться в живых. Поэтому, модель решения нужно строить не на бинарном отношении «получит/не получит», а на высказывании: «если останется жив, то получит». Здесь все интереснее.
От ответа другого пирата зависит не только дележ золота, но и жизнь главаря. Если главарь ценит свою жизнь дороже 100 монет, то другой пират, за свою лояльность, получает не 1 жалкую монету, а все 100 (в противном случае главаря уберут). Кто этот «другой» уже не важно (в реальной жизни задействуется принцип субординации).
Поэтому ситуации с тремя пиратами решение будет таким: главарь получает жизнь, всё золото получает следующий по старшинству, а последний пират остаётся ни с чем. :)
Следовательно, доказательство на случаи 4 и 5 пиратов тоже не верно.
задумывался об этом, читая rfc. но пришел к выводу, что фактически это бесполезная хрень. все клиенты понимают 302 и автоматически редиректят, поэтому инсинуации в rfc про 303 ни кого не волнуют. :)
«проблему» стоило бы порешать лишь в одном случае — если бы браузеры действительно запрашивали потдветждение юзера при 302 редиректе. но этого нет и никогда не будет, потому, что так устроен современный интернет. :)
в последнее время, многие производители ноубков размещают свето-индикаторы (caps-lock, num-lock и т.п.) в том месте, где в процессе печати на клавиатуре они закрыты запястьем руки. имхо, дурацкое дизайнерское решение. :(
Префикс WWW придумали не столько для указания типа сервиса, столько по соображениям безопасности.
Куки, установленные для домена site.ru, будут видны и на всех под-доменах *.site.ru.
Куки, установленные для домена www.site.ru, будут видны только на этом сайте, т.к. *.www.site.ru не бывает. :)
Поэтому, если не нужно, чтобы сайты на под-доменах были связаны с сайтом на основном домене, то ему присваивается всем известный префикс www.
Вы можете сложить 0.5 и 0.5, получив 1, но из двух огрызков вы не получите целого яблока. Объекты из ООП имеют примерно такое же отношение к объектам реального мира, как натуральные числа к огрызкам от яблок — и то и другое это абстракции. Развитие «объектного мышления» это развитие абстрактного мышления, с использованием концепций ООП.
Одна из них — интерфейс — абстракция поведения (взаимодействия сущности в внешним миром). На диаграммах используется наследование классов там, где нужно было использовать реализацию интерфейсов. В самом деле, описав интересующее поведение «продавца» и «игрока» интерфейсами, можно было бы абстрагироваться от конкретной сущности «человек», и в последствии, без проблем, перенести это поведение на автоматы-обменники. Мне кажется, эта ошибка, стала следствием того, что автор слишком много уделяет внимания объектам реального мира. :)
«Прошла конференция, посвященная ООП. Одни докладчики говорили про моделирование объектов реального мира и их иерархий. Другие — по делу…» =)
Объясните, почему продавец жетонов — которые на диаграмме суть деньги — до сих пор на свободе, ведь он, осуществляя обмен, и не являясь представителем кредитной организации, злостно нарушает закон «О валютном регулировании и валютном контроле»? Как продавцу жетонов самому поиграть на игровом автомате? Как разместить на диаграмме класс для механического продавца — автомат-обменник, меняющий купюры на жетоны, — так чтобы при этом он не оказался киборгом (наследником человека)?
Верстальщики прекрасно знают что такое парадигма наследования, хотя бы из css. И не пользоваться этой мощью в шаблонах — путь в говнокод.
Проблема в том, что за словом «наследование» скрывается куча разных по смыслу понятий. В программировании, наследованием называют логическое отношение обобщения (is-A) для типов данных. В css же, под наследованием понимается механизм каскадной композиции свойств.
класс определяет лексическое пространство имен. т.е. класс фактически является неймспейсом. поэтому синтаксис App::Lib2::MyClass::WhoAmI() был бы логичен (равно как и вложенные классы).
— Ты зачем притащил десять булок хлеба!?
— Потому, что яйца были.
— !??
— Сама же просила: «сходи в магазин, купи хлеба, если будут яйца, возьми десяток».
Ваша модель позволяет сократить время разработки, за счет того, что сама может достраивать пути запроса. Однако, у меня создалось впечатление, что в процессе эксплуатации это может приводить к появлению не очевидных багов, поскольку добавление новых связей может изменять пути уже существующих запросов (а следовательно, и семантику их результатов).
Связный граф без колец (циклов) называется деревом. Эта модель подходит лишь для каких-то вырожденных случаев. Понятийные связи в реальных моделях образуют сети.
В общем, для меня многое осталось не ясным. Буду ждать релиза в опенсорц, для того чтобы посмотреть как это работает на практике.
print 1 * 3и
price_of_apples = 1
number_of_apples = 3
print price_of_apples * number_of_apples
первый пример несомненно короче. но где больше ясность?
Кроме того:
wiki: Принцип достаточного основания) иными словами, бритва Оккама не нужна))
Исключения являются частью внешнего интерфейса. Т.е. это то, с чем будет
взаимодействовать _клиенсткий_ код (чужой — а не ваш). Вы не можете заранее предугадать, какие ситуации клиентский код «захочет»
обрабатывать «по-особенному». Соответственно — проектировать исключения исходя
из какой-то особенной обработки нет ни какого резона. Вы можете лишь обозначать
исключительные ситуации в той мере, в которой
сочтете нужнымэто требуется для обеспечения полноты модели предметной области.
git config --global alias.oops \ '!am() { curl -s http://whatthecommit.com/ | grep '"'<p>'"' | cut -c4-; }; git commit -em "# $(am)" "$@"'использование:
firefile@strebitzer.at/content/firefile.js, в строчке 718.- if(qpos !== false) {+ if(qpos !== -1) {Когда 2 пирата все очевидно.
В случае с 3 пиратами решение слишком парадоксально. Мне кажется, что тут ошибка в рассуждении.
Задача пирата состоит не только в том, чтобы получить золото — он ещё должен остаться в живых. Поэтому, модель решения нужно строить не на бинарном отношении «получит/не получит», а на высказывании: «если останется жив, то получит». Здесь все интереснее.
От ответа другого пирата зависит не только дележ золота, но и жизнь главаря. Если главарь ценит свою жизнь дороже 100 монет, то другой пират, за свою лояльность, получает не 1 жалкую монету, а все 100 (в противном случае главаря уберут). Кто этот «другой» уже не важно (в реальной жизни задействуется принцип субординации).
Поэтому ситуации с тремя пиратами решение будет таким: главарь получает жизнь, всё золото получает следующий по старшинству, а последний пират остаётся ни с чем. :)
Следовательно, доказательство на случаи 4 и 5 пиратов тоже не верно.
«проблему» стоило бы порешать лишь в одном случае — если бы браузеры действительно запрашивали потдветждение юзера при 302 редиректе. но этого нет и никогда не будет, потому, что так устроен современный интернет. :)
Куки, установленные для домена site.ru, будут видны и на всех под-доменах *.site.ru.
Куки, установленные для домена www.site.ru, будут видны только на этом сайте, т.к. *.www.site.ru не бывает. :)
Поэтому, если не нужно, чтобы сайты на под-доменах были связаны с сайтом на основном домене, то ему присваивается всем известный префикс www.
Одна из них — интерфейс — абстракция поведения (взаимодействия сущности в внешним миром). На диаграммах используется наследование классов там, где нужно было использовать реализацию интерфейсов. В самом деле, описав интересующее поведение «продавца» и «игрока» интерфейсами, можно было бы абстрагироваться от конкретной сущности «человек», и в последствии, без проблем, перенести это поведение на автоматы-обменники. Мне кажется, эта ошибка, стала следствием того, что автор слишком много уделяет внимания объектам реального мира. :)
Объясните, почему продавец жетонов — которые на диаграмме суть деньги — до сих пор на свободе, ведь он, осуществляя обмен, и не являясь представителем кредитной организации, злостно нарушает закон «О валютном регулировании и валютном контроле»? Как продавцу жетонов самому поиграть на игровом автомате? Как разместить на диаграмме класс для механического продавца — автомат-обменник, меняющий купюры на жетоны, — так чтобы при этом он не оказался киборгом (наследником человека)?
Проблема в том, что за словом «наследование» скрывается куча разных по смыслу понятий. В программировании, наследованием называют логическое отношение обобщения (is-A) для типов данных. В css же, под наследованием понимается механизм каскадной композиции свойств.
<?phpnamespace foo
class A {}
?>
B.php:
<?php
class B {}
?>
<?php
include "A.php";
include "B.php"; # В каком нейспейсе class B: 'foo' или 'global' ?
?>
Ваша модель позволяет сократить время разработки, за счет того, что сама может достраивать пути запроса. Однако, у меня создалось впечатление, что в процессе эксплуатации это может приводить к появлению не очевидных багов, поскольку добавление новых связей может изменять пути уже существующих запросов (а следовательно, и семантику их результатов).
Связный граф без колец (циклов) называется деревом. Эта модель подходит лишь для каких-то вырожденных случаев. Понятийные связи в реальных моделях образуют сети.
В общем, для меня многое осталось не ясным. Буду ждать релиза в опенсорц, для того чтобы посмотреть как это работает на практике.
например так:
@should.throw(Exception).when(1,0)
@should.give(7).when(5,2)
но думаю, есть лучшие варианты.