Эксперты считают, что повышение штрафов незначительно скажется на улучшении ситуации на дорогах России. По их мнению, лишь десятая часть участников дорожного движения реагирует на увеличение штрафных санкций.
Президент утвердил увеличенные штрафы за «зебру»

Вчера много ходил по городу, и 3 раза меня поразила необычная “вежливость” водителей на переходах, придумал и удовлетворился объяснением, что в субботу люди прибывают в умиротворенном состоянии. Оказалось что есть друге объяснение – увеличение штрафов за не пропуск пешеходов на зебре. На следующий день уже специально обратил внимание, на поведение водителей, визуально поведение водителей изменилось…

С одной стороны можно согласится с “экспертами” что лишь десятая часть участников дорожного движения реагирует на увеличение штрафов, но вот с выводом о том что это незначительно скажется не могу…

Это гораздо больше, чем факт. Так оно и было на самом деле. (Барон Мюнхгаузен)

Почему,… потому что это заметил, заметил невооруженным глазом. Можно предположить что через некоторое время все вернется в “норму”, а можно предположить что те самые 10 процентов как раз и меняют ситуацию, ведь когда ты выходишь на зебру нужно не чтобы все 10 машин остановились, а хотя бы одна из 10, все кто за ней будут вынуждены остановится.

Что это за “эксперты” и “эксперты” в чем, кто и почему их называет “экспертами”… Время покажет, насколько они были правы.

Интернет это хорошо… Иногда там можно встретить просто шедевры:

Новая сказка про репку

Сейчас мало у кого вызывает сомнения, что идеология Model-driven engineering доминирует по крайней мере при проектировании приложений. Но так же не вызывает сомнений, что в менеджменте доминирует Task management.

Попробую пояснить что имеется в виду: менеджер говорит разработчикам надо реализовать такую-то функциональность - ставит задачу (она может в свою очередь дробиться на более мелкие задачи, сейчас это не важно), разработчик анализирует, что необходимо сделать чтобы реализовать эту задачу. Вот такая идиллия, если не вдаваться в подробности.

В реальной жизни все выглядит несколько грубей, есть требование реализовать некую функциональность к определенному сроку и менеджер способен подкрепить это требование властными полномочиями или от реализации этой задачи в срок может завесить материальное обеспеченье, или самый тяжелый вариант, менеджер немного разбирается в разработке и понимает, что эту задачу с технической точки зрения можно реализовать в указанные сроки. При это очень часто бывает, что следование идеологии Model-Driven более трудозатратно чем “просто” реализовать требуемый функционал. Через некоторое время идеология Task Driven начинает распространятся из области менеджмента в область разработки, и это как правило начала конца. Т.е. приложение может существовать еще долго, но уже в состоянии деградации…

Выше описанный сценарий не теоретические домыслы, а практические наблюдения. Почему так происходит? Если присмотреться никто в этом не виноват или наоборот виноваты все, а точнее сказать виновата система. Разработчики/проектировщики часто не имеют желание, силы, возможности, внутренней мотивации отстаивать свою позицию, менеджер с точностью наоборот. В итоге страдает продукт… и пока что, на практике, не видел “системы” разработки избавленной от этого недостатка, где-то хуже, где-то лучше… Наверное идеальный вариант, когда разработчики пишут для себя или “не ограничены” временными рамками, но это уже не коммерческая разработка.

Что поделать как правило со временем качество приложения ухудшается и судя по всему причина именно в этом… Наверное как и с любой другой проблемой, от которой нельзя избавиться, остается помнить о ней и по возможности пытаться смягчить её проявления.

В последнее время все чаще встречаются новости о борьбе с “нарушителями авторских прав”, к примеру: суд над Pirate Bay, и законопроект об отключение пользователей интернета уличенных в незаконном файлообмене во Франции.

Особенно неубедительно звучит аргумент о воровстве у авторов произведений, что в свою очередь в целом наносит удар по культуре.

Жаль, конечно, что писатели трудятся прежде всего ради хлеба насущного, а уж потом для славы, и что их уровень жизни растет в прямой зависимости от роста их способности зарабатывать на хлеб (поэтому они никогда не добьются славы), вот и процветают однодневки, а великое произведение остается ненаписанным. (Джек Лондон)

Очень сомнительно что это наносит удар по культуре, скорее наоборот текущее состояние в области авторских прав наносит удар по культуре. И те кто действительно хотят заботится о культуре должны задуматься об этом.

А во вторых употребление термина воровство, откровенное подмена понятий. Что такое воровство и почему это плохо, воровство это присвоение чужого имущества себе, при этом важно не то что у кого-то что-то появляется, а то что у кого-то что то исчезает. Если вор украдет часы, то что здесь плохого, не то что у него появились часы, а то что они исчезли у их хозяина. Но в случае с информацией и другими не материальными ценностями, они не исчезают, а копируются/создаются у нового владельца, никто их не лишается.

Неосознанно большинство людей все это чувствует, и не считает такие действия преступлением. Законы являются/должны является закреплением правил, обычаев сложившихся в конкретном обществе, и все что не естественно рано или поздно в здоровом обществе отомрет.

Как метко замечено в одном из комментариев:

Вот они две российские беды в действии!

Подробней: К нам - Гиппопотам? Сам - Гиппопотам?!

Вопрос, который давно, с интересом и без какого-либо заметного результата обсуждается уже не первое десятилетие. Постараюсь избавить вас от повторения всем известной аргументации, и даже не буду пытаться ответить на этот вопрос. Если долгое время люди не могут придти к единому мнение по какому либо вопросу, значит вопрос не корректно поставлен.

Стимулом для написания заметки послужил разговор с другом:
я: … у меня были возможности заниматься работой менеджера, но я сознательно не шел на нее, мне нравиться заниматься разработкой программ
он: … тут что-то не то, … хм а что тебя мотивирует, почему тебе это нравиться
я: … мне нравиться что-то создавать своими руками, когда я занимаюсь разработкой я чувствую себя творцом, который создает какой-то мир…
он: … но ведь есть требования проекта/заказчика, ты ведь делаешь работу для них, а менеджер планирует работу и говорит что тебе делать
я:  … ни менеджер ни аналитик на самом деле не определяют идеологию/концепцию системы, её определяют люди занимающиеся проектированием. А ты сам-то от чего получаешь удовольствие в работе, зачем?
он: … мне нравиться когда то, что я делаю приносит людям пользу

Нормальный разговор, который часто случается между давно знакомыми людьми за кружкой пива, но он послужил мне стимулом, еще раз задуматься о сути разработки и поглубже разобраться в предмете.

То что разработку приложений не корректно сравнивать с производством машин или строительством дома, стало понятно уже лет 10-20 назад, ещё раньше была распространена аналогия “написание книги”, но как только разработка стала коллективным занятием, она тоже стала не слишком адекватной. Сейчас популярна аналогия “инновационная разработка коллективом научных работников”, которая тоже выглядит не очень убедительно. С другой стороны было бы наивно думать, что разработка это какой-то настолько уникальный вид человеческой деятельности, что трудно подобрать достаточно хорошую аналогию.

В моем представлении наиболее уместна будет аналогия для проекта по разработке ПО – проект по съемки фильма. И там и там есть заранее известные этапы, и общие рекомендации/шаблоны. И там и там учувствует больше  количество людей обладающих различными навыками. И там и там достаточно большие бюджеты, единственно доля зарплаты от общей суммы в разработке, возможно, больше чем при съемки фильма. И там и там проводились и продолжают проводится попытки поставить производство продукта, на поток с хорошо прогнозируемым результатом, и там и там это привело к похожим результатам. И там и там стоит вопрос искусство ли это, только в кино, он чаще ставиться относительно какого то конкретного проекта (фильма). И там и там общий рецепт успеха звучит примерно одинаково: выделите достаточно денежных средств и сделайте так чтобы ничего не мешало работе, пригласите отличного сценариста и режиссера, хороших актеров, хороших гримеров, постановщиков трюков, операторов, музыкантов и скорее всего вы получите отличный фильм, про разработку повторят не буду думаю у вас самих получиться.

Первое не соответствие которое сразу может подметить критик: так при разработке решается конкретная проблема заказчика, заказчик ждет решения своей проблемы, а при съемке фильма об это не идет никакой речи. Что тут сказать, в целом согласны, вот только не согласны, что это что-то меняет, все тоже кино, в кино ведь тоже редко режиссеры а уж тем более актеры свободны в своем выборе. Кстати тут тоже просматривается аналогия, хороший режиссер может не согласиться снимать если ему не нравиться сценарий, и хороший актер может отказаться от роли, актер может даже не спросить о роли, ему может быть достаточно знать кто режиссер чтобы согласиться/отказаться, плохие и начинающие актеры/режиссеры как правило согласны на все.

А чтобы почувствовать аналогию сильнее, попробуйте взять не просто разработку, а разработку игр, если вы в общих чертах представляете, что происходит в этой индустрии, вы поразитесь сходством.

Зачем нужны аналогии и чем они хороши? По аналогии можно придти к вопросам и ответам, значительно быстрее если не иметь ее и лучше почувствовать предмет рассмотрения. Что же теперь самое время ответить на вопрос: Is Programming an Art?

Blogger2BlogML is a free on-line service that allows you to save your Blogger posts and comments to a single file for archival or transfer to a different Blog publishing system.

Learn more at: http://www.blogger2blogml.info

Нам не дано предугадать, как слово наше отзовется
Федор Тютчев

В программирование существует такое понятие как “волновой эффект” это когда внесение изменений в одной какой то части приложения, приводит к появлению новых ошибок. Об этом важном понятии все знают, а с проблемой стараются бороться по мере возможности: выделяют интерфейсы, уменьшают взаимозависимости модулей и классов.

Человек хитер, а если он еще добрался до компьютера, то его изобретательность, в плане навреди ближнему, просто не знает границ. Вы говорите проектирование, выделение модулей, тесты … а он только хитро ухмыляется. А если он не один, если они сбились в стаю команду.

Вот свежий пример, есть понятие (класс) у которого есть числовое поле Number, вопрос: как его изменить чтобы причинить максимальный ущерб? Изменить тип, изменить название? Нет все не так… слишком просто, любой компилятор сразу почует. Ответ простой: ничего не надо менять, ровным счетом ничего, достаточно взять и в один день договориться понимать под этим полем нечто другое, изменить его семантику. Причем чем более похоже это звучит к тому что понималось под этим до этого тем лучше. Всё продолжает работать ничего не падает, но со временем начинают появляется ошибки и какие то странные данные, до тех пор пока их количество не достигает критического уровня, и вот начинаю разбираться, выясняется что… ну конечно же большинство всегда право. Упс, всё, конец, операция закончилась успешно, ещё один противник повержен…

Для отслеживания изменений в данных можно использовать утилиту TableDiff.exe, но если эта задача носит регулярный и частый характер, то использование этой утилиты может занимать заметные временные и человеческие ресурсы. К примеру TableDiff.exe не поддерживает тип данных: nvarchar(max).

На рынке существуют различные утилиты реализующие такую функциональность практически все коммерческие. Участие в программе Microsoft BizSpark открыло возможность познакомиться с продуктом VS 2008 Database Edition. Который содержит функциональность Data Compare и много другой относящийся к работе с базами данных, которая доступна именно в этой редакции Visual Studio и поэтому многие разработчики либо не подозревают о её существовании либо не имеют навыков её использования. Если у Вас есть потребности в подобной функциональности, то применение VS2008 Database Edition может быть эффективным.

Классические эволюционные модели рассматривают целый ряд механизмов, обеспечивающих распространение в популяции «генов альтруизма», то есть таких генов, которые склоняют их носителей к поведению, вредному для них самих, но полезному для других особей (см. статьи об этом на «Элементах»). Наиболее известны и лучше всего разработаны три теории: родственного отбора (помогая родственникам, способствуешь распространению своих же генов), реципрокного альтруизма (принцип «ты мне — я тебе») и непрямой реципрокности (альтруистические поступки как средство повышения собственной репутации и социального статуса).

Могут ли быть в природе такие ситуации, когда ни один из трех перечисленных механизмов не работает, и альтруисты ни прямо, ни косвенно не получают никакой выгоды от своего альтруизма, но альтруизм тем не менее развивается и процветает?
(Альтруисты процветают благодаря статистическому парадоксу)

Вот такой простой вопрос, но объяснение ответа вызвало затруднения. Не смотря на простоту объяснения не получалось людям донести его, что послужило поводом к написанию этой статьи, верю что это решит проблему.