«Аудитория Хабра в массе своей как раз программисты и статья о том «как приготовить из программиста пирог» не может вызвать положительной реакции никак. „
Я думаю тут зависит от информационной культуры человека — готов ли он рассматривать сообщения, противоречащие своей картине мира. В данном случае повествуется о довольно интересном опыте и хотелось бы, чтобы человек дальше о нем рассказывал (например, что будет через год, не проявится ли проблема “поиска локальных максимумов» о которой писал Джоел).
Массовый же читатель строит для себя информационный кокон (я не помню источник термина — кажется книжка Information Diet) — стараясь подписаться на приятные ему блоги и заткнуть неприятные минусом в карму, подобно тому как в древности правители убивали гонцов, принесших плохую весть…
«предугадывать, на каком языке фактически пишет программист, основываясь на типах данных, которыми он манипулирует. Например, если Wyver определит, что программист работает с БД, то вероятней всего он делает это на SQL.»
Что за «вероятней всего» и «предугадывать»? Суть там простая — по типу данных запускается кастомный парсер литерала для этого типа.
Типа:
let webpage : HTML = <html><body><h1>Results for {keyword}</h1>
<ul id="results">{to_list_items(query(db,
SELECT title, snippet FROM products WHERE {keyword} in title))}
</ul></body></html>
Часть после "=" разбирается специальным кодом для html и определяется какой разбор запускать по типу (:HTML)
Нечто похожее есть в F# — type providers — только там обычно используется строковый литерал для встраивания кастомного языка
// reference the type provider dll
#r "RegexProvider.dll"
open FSharp.RegexProvider
// Let the type provider do it's work
type PhoneRegex = Regex< @"(?<AreaCode>^\d{3})-(?<PhoneNumber>\d{3}-\d{4}$)">
// now you have typed access to the regex groups and you can browse it via Intellisense
PhoneRegex().Match("425-123-2345").AreaCode.Value
Я читал про Design by contract миллиард лет назад и уже не помню какого автора, так что могу только порекомендовать поискать самостоятельно про Design by contract и язык Эйфель (кстати, DBC — это зарегистрированная торговая марка, поэтому MS, например, называет у себя тоже самое Code contracts)
«Другая серьезная проблема метода экономической мотивации заключается в тенденции людей находить локальный максимум. Они обнаружат какой-нибудь способ оптимизировать тот показатель, за который вы платите, не достигая в действительности того, чего вы на самом деле хотите.
Так, например, сотрудник службы техподдержки, желая получить премию за сохранение клиента, так выведет его из себя, что „Нью-Йорк Таймс“ опубликует на первой полосе длинную историю о том, как отвратительна ваша техническая „поддержка“. Хотя поведение сотрудника в данной ситуации достигает того результата, за который вы платите (сохранение клиента), оно не достигает того, что действительно важно для вас (прибыль). А когда вы пытаетесь наградить сотрудника за прибыль компании, скажем, дав ему 13 акций, вы понимаете, что это не та вещь, на которую отдельный сотрудник может повлиять, так что идея с акциями — просто потеря времени. „
«Может лучше продолжать тестировать наш код в прямом эфире, во время того как пользователи взаимодействуют с нашим программным продуктом?»
Я думаю, лучше перевести эту фразу так:
«Я никогда не читал про Бертрана Мейера и Design-by-contract поэтому решил сделать свою реализацию смешивающую документацию, контракты и тест в одном понятии „утка“»
А при чем тут киллер фичи? Предположим у вас есть возможность поставить 7 и 8, но вам удобно работатать при помощи виртуальной смарткарты, которая поддерживается в 8…
Per-monitor DPI: Windows 8.1 sets different scale factors for different displays, and can scale content appropriately. Windows® 8 only sets a single scale factor that is applied to all displays. This feature ensures that users with High DPI devices (that is, 150% and 200% scaling laptops) who project or dock their devices with conventional 100% scaling projectors and desktop monitors display properly sized content on those screens.
Есть ли у вас опыт подготовки электронных изданий (а если нет, то не могли бы вы оценить примерно) какие из статей расходов будут больше или меньше в электронном виде? Например, понятно, что производство копий переходит к мгазину. А вот индизайн станет больше или меньше — с одной стороны спецов должно быть меньше, и поэтому они дорогие. С другой стороны возможно технологии и софт более новые или менее требовательные. Как вы считаете?
>>>Причем то, что код нерабочий — будет заметно далеко не сразу, а после того, как порядок вызовов поменялся при каких-то неизвестных условиях.
Еще мне кажется что вы рассматриваете TDD как святой Грааль достижения безглючного кода — то есть что он может помочь в ситуации когда вы даже не знаете условий при которых возможны ошибки. Его, на сколько я знаю, никто так не рассматривает. Просто вместо ручного тестирования во-первых, вы пишете код. Во-вторых, путем юнит тестинга добиваетесь более расширяемого дизайна (если код можно протестировать UT — это значит что он уже работает в двух окружениях — продуктивном и тестовом)
Я не очень понял как посчитать стоимость производства — это эти 1500 на Editors++? Если у продавца меньше издержки на продажу одной копии экземпляра электронной книжки, не будет ли он брать меньше денег? не могли бы вы привести подобную табличку, только чтобы строчками были статьи затрат а столбцами бумажный вариант/электронный вариант по вашей оценке.
Там вроде один ответ с калькуляцией, с непонятными строками, по которым получается что большая часть идет за распечатку (http://dl.dropbox.com/u/1174604/CloudShot/2014/shot_02-may-12_212708.png ) — 5 / 8 — printing costs
+ процент margin for sales может быть другой из-за большей масштабируемости софтвера по сравнению с продавцами
1) Тестировать команды отдельно что они работают со всеми правильными состояниями (из правильных состояний возникают правильные состояния, на неправильные состояния ругаются)
Небольшой интеграционный тест на то, что части работают вместе.
2) В тесте подсунуть фейк объекта файловой системы выбрасывающий тот же эксепшн, что и при выдергивании флешки
3) Я не вижу никаких сложностей в разработке вебсайта в стиле TDD
Интересно, как совместимость Presto связана с закладками. Почему закладки зависят от определенного движка?
www.joelonsoftware.com/articles/fog0000000069.html
Я думаю тут зависит от информационной культуры человека — готов ли он рассматривать сообщения, противоречащие своей картине мира. В данном случае повествуется о довольно интересном опыте и хотелось бы, чтобы человек дальше о нем рассказывал (например, что будет через год, не проявится ли проблема “поиска локальных максимумов» о которой писал Джоел).
Массовый же читатель строит для себя информационный кокон (я не помню источник термина — кажется книжка Information Diet) — стараясь подписаться на приятные ему блоги и заткнуть неприятные минусом в карму, подобно тому как в древности правители убивали гонцов, принесших плохую весть…
Что за «вероятней всего» и «предугадывать»? Суть там простая — по типу данных запускается кастомный парсер литерала для этого типа.
Типа:
Часть после "=" разбирается специальным кодом для html и определяется какой разбор запускать по типу (:HTML)
Нечто похожее есть в F# — type providers — только там обычно используется строковый литерал для встраивания кастомного языка
local.joelonsoftware.com/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B9_%D0%BC%D0%BE%D1%82%D0%B8%D0%B2%D0%B0%D1%86%D0%B8%D0%B8
«Другая серьезная проблема метода экономической мотивации заключается в тенденции людей находить локальный максимум. Они обнаружат какой-нибудь способ оптимизировать тот показатель, за который вы платите, не достигая в действительности того, чего вы на самом деле хотите.
Так, например, сотрудник службы техподдержки, желая получить премию за сохранение клиента, так выведет его из себя, что „Нью-Йорк Таймс“ опубликует на первой полосе длинную историю о том, как отвратительна ваша техническая „поддержка“. Хотя поведение сотрудника в данной ситуации достигает того результата, за который вы платите (сохранение клиента), оно не достигает того, что действительно важно для вас (прибыль). А когда вы пытаетесь наградить сотрудника за прибыль компании, скажем, дав ему 13 акций, вы понимаете, что это не та вещь, на которую отдельный сотрудник может повлиять, так что идея с акциями — просто потеря времени. „
Я думаю, лучше перевести эту фразу так:
«Я никогда не читал про Бертрана Мейера и Design-by-contract поэтому решил сделать свою реализацию смешивающую документацию, контракты и тест в одном понятии „утка“»
Там есть группы и semantic zoom
en.wikipedia.org/wiki/Features_new_to_Windows_8#Infrastructure
technet.microsoft.com/en-us/windows/dn140266
Per-monitor DPI: Windows 8.1 sets different scale factors for different displays, and can scale content appropriately. Windows® 8 only sets a single scale factor that is applied to all displays. This feature ensures that users with High DPI devices (that is, 150% and 200% scaling laptops) who project or dock their devices with conventional 100% scaling projectors and desktop monitors display properly sized content on those screens.
Думаю при возникновении реальной претензии будет какой-нибудь наезд, чтобы остальные боялись — типа пособничество экстремизму.
Еще мне кажется что вы рассматриваете TDD как святой Грааль достижения безглючного кода — то есть что он может помочь в ситуации когда вы даже не знаете условий при которых возможны ошибки. Его, на сколько я знаю, никто так не рассматривает. Просто вместо ручного тестирования во-первых, вы пишете код. Во-вторых, путем юнит тестинга добиваетесь более расширяемого дизайна (если код можно протестировать UT — это значит что он уже работает в двух окружениях — продуктивном и тестовом)
+ процент margin for sales может быть другой из-за большей масштабируемости софтвера по сравнению с продавцами
Небольшой интеграционный тест на то, что части работают вместе.
2) В тесте подсунуть фейк объекта файловой системы выбрасывающий тот же эксепшн, что и при выдергивании флешки
3) Я не вижу никаких сложностей в разработке вебсайта в стиле TDD