2008/12/17
SCRUM
Весьма полезная статья по scrum - одной из гибких методик разработки. Там же ссылка на скрам-блог http://www.scrumguides.com/
2008/12/12
Касательно разного рода асек. Имеется совсем неплохой клиент QutIM.org - межплатформенный, OpenSource, Freeware. Ждём версии 0.0.2 с поддержкой жаббера и поддерживаем автора.
Авторское право и интернет
Авторское право в интернете - равно как и анонимность в сети - миф.
Читаем лицензионное соглашение Google. В нём очень много интересного: и про то, что гугл никак не ответственна за ваще здоровье при пользовании сервисами, и про то, что гугл имеет право использовать любой контент, прошедщий через их сервисы, по собственному усмотрению, в том числе и для передачи третьим лицам. Но, разумеется, авторское право - право авторства - остаётся за автором.
В лицензии народнолюбимой аськи всё ещё круче: владелец аська-сервиса фактически становится соавтором всего, что проходит через сервис и имеет право использовать по собственному усмотрению без разрешения, собственно, автора.
Интересно, догадались ли сотовики до подобных лицензий? Тогда спецаппаратура прослушки и не нужна будет вовсе.
Автор в интернетах - и не автор вовсе, а произодитель контента.
Читатель, конечно же, живой трафик.
Человечество представляет собой числовую последовательность.
Петь ли осанну новому геному?
Читаем лицензионное соглашение Google. В нём очень много интересного: и про то, что гугл никак не ответственна за ваще здоровье при пользовании сервисами, и про то, что гугл имеет право использовать любой контент, прошедщий через их сервисы, по собственному усмотрению, в том числе и для передачи третьим лицам. Но, разумеется, авторское право - право авторства - остаётся за автором.
В лицензии народнолюбимой аськи всё ещё круче: владелец аська-сервиса фактически становится соавтором всего, что проходит через сервис и имеет право использовать по собственному усмотрению без разрешения, собственно, автора.
Интересно, догадались ли сотовики до подобных лицензий? Тогда спецаппаратура прослушки и не нужна будет вовсе.
Автор в интернетах - и не автор вовсе, а произодитель контента.
Читатель, конечно же, живой трафик.
Человечество представляет собой числовую последовательность.
Петь ли осанну новому геному?
2008/11/22
Вышел Komodo Edit 5
и к нему addon SourceTree http://community.activestate.com/addons?page=3
Особенно расписывать Комодо не буду, скажу лишь, что он на движке мозилы, и поддерживает подсветку и "умную дополнение" многих языков программирования
и к нему addon SourceTree http://community.activestate.com/addons?page=3
Особенно расписывать Комодо не буду, скажу лишь, что он на движке мозилы, и поддерживает подсветку и "умную дополнение" многих языков программирования
2008/11/06
Пишем CMS. Часть 2: ловим ошибки
Как я уже писал, сейчас мы будем заниматься ошибками. Нам нужно:
Теперь пхп настроен как нам надо. Займемся перехватом ошибок. Обратим внимание на замечательную функцию set_error_handler() - она указывает пхп, кто\что будет заниматься обработкой ошибок вместо стандартного обработчика. На сайте приведён достаточно хороший пример, рассказано и показано, какого вида должна быть функция обратного вызова (callback fucntion). Так что я не буду заниматься здесь пережёвыванием мануала.
Но мы ведь собирались просто логировать ошибки? Для этого можно воспользоваться функцией log() из предыдущего примера, либо по аналогии написать функцию error(), либо (внимание!) провести небольшой рефакторинг функции log() так, чтобы она принимала местоназначение лога.
На сегодня у меня всё.
Успехов.
а) чтобы пользователь ошибок не виделДля этого мы (надеюсь, все внимательно ознакомились с мануалом http://php.net/manual/ru/book.errorfunc.php про перехват ошибок?) сначала настроим пхп в соответствии с требованиями. Воспользуемся функцией ini_set() и страничкой с описанием конфигурации. Примерно так:
б) чтобы владелец ресурса об ошибках был в курсе
error_reporting E_ALL | E_STRICTАх, да! внимательно прочитав описание error_reporting мы видим, что во время выполнения скрипта нас просят пользоваться функцией error_reporting(); воспользуемся.
display_errors "Off"
html_errors "Off"
Теперь пхп настроен как нам надо. Займемся перехватом ошибок. Обратим внимание на замечательную функцию set_error_handler() - она указывает пхп, кто\что будет заниматься обработкой ошибок вместо стандартного обработчика. На сайте приведён достаточно хороший пример, рассказано и показано, какого вида должна быть функция обратного вызова (callback fucntion). Так что я не буду заниматься здесь пережёвыванием мануала.
Но мы ведь собирались просто логировать ошибки? Для этого можно воспользоваться функцией log() из предыдущего примера, либо по аналогии написать функцию error(), либо (внимание!) провести небольшой рефакторинг функции log() так, чтобы она принимала местоназначение лога.
На сегодня у меня всё.
Успехов.
Свободный дизайн
Нашёл замечательный сайт http://www.oswd.org/ Open Source Web Design - Открытые макеты сайтов. Это вам не какие-нибудь "besttemplates" или "100 лучших бесплатных шаблонов".
Это торжество идеи ОпенСорс! Троекратное "Ура!" Столлману! ;)
Это торжество идеи ОпенСорс! Троекратное "Ура!" Столлману! ;)
2008/11/05
Пишем CMS: система логирования
Как я уже писал, каждая система должна начинаться с кнопки "Выход". Так как веб-приложение, в принципе, не нуждается в реализации такой кнопки, напишем что-нибудь полезное, например, систему логирования. А затем, быстренько, на её основе - систему логирования ошибок.
В мануале мы находим главу Error Handling and Logging и там - очень полезную функцию error_log . Пишем обёртку (wrapper)
function log( $log_message )
{
всё.
Теперь в скрипте достаточно вызвать функцию log('сообщение для лога'); и без всяких чудес лог заполняется.
Успехов.
В мануале мы находим главу Error Handling and Logging и там - очень полезную функцию error_log . Пишем обёртку (wrapper)
function log( $log_message )
{
error_log(
}date('Y-m-d H:i:s ') . $log_message . "\r\n", /* оформляем сообщение */
3 /* писать будем в файл */,
'logs/common.log' /* внимательно выбирайте имя файла и chmod */
);
всё.
Теперь в скрипте достаточно вызвать функцию log('сообщение для лога'); и без всяких чудес лог заполняется.
Успехов.
2008/11/01
Как рассчитать свою зарплату
Деньги. Вообще, я склонен думать, что работа не может приносить материального удовлетворения. Потому что денежные знаки конвертируются в удовлетворение моральное и просто поддержание здоровья. Посчитаем их:
аренда жилья около <подставить нужное> с квартплатой и комм.услугами
проезд к месту работы 17х2х22 = 748руб.
обед (учитывая расположение офиса в центральной части города) 250х22 = 5500руб.
просто питание дома 150х30 = 4500руб.
техническая литература ~250руб.\том
периодические технические издания ~120руб.\шт
культурные удовольствия, типа посещения клубов\театров\выставок ~250руб.\1билет
Первые 4строки уже дают сумму более Nтыс.руб. <необходимый минимум для выживания> и это при условиях, что сюда не включены медобслуживание, периодическое обновление гардероба, повышение квалификации, рост цен, рост доллара, падение цен на нефть, поддержание материального положения матери-пенсионера, жена, дети и другие дорогостоящие удовольствия типа приобретения мотоцикла.
аренда жилья около <подставить нужное> с квартплатой и комм.услугами
проезд к месту работы 17х2х22 = 748руб.
обед (учитывая расположение офиса в центральной части города) 250х22 = 5500руб.
просто питание дома 150х30 = 4500руб.
техническая литература ~250руб.\том
периодические технические издания ~120руб.\шт
культурные удовольствия, типа посещения клубов\театров\выставок ~250руб.\1билет
Первые 4строки уже дают сумму более Nтыс.руб. <необходимый минимум для выживания> и это при условиях, что сюда не включены медобслуживание, периодическое обновление гардероба, повышение квалификации, рост цен, рост доллара, падение цен на нефть, поддержание материального положения матери-пенсионера, жена, дети и другие дорогостоящие удовольствия типа приобретения мотоцикла.
2008/10/22
К вопросам этики и эстетики в программировании. Часть 1. Disclaimer.
Disclaimer: 1) a renunciaction of any claim to or connection with; 2) disavowal; 3) a statement made to save one's own ass.
Вот тут некоторые интересуются, о чём собственно это я пишу? Как программирование связано с эстетикой и при чём здесь этика?
То бишь русская, в частности техническая, интеллигенция никуда не делась - что не может не радовать - и продолжает задавать свои любимые вопросы (; цитат не будет).
За интернетом далеко ходить не надо. Вот ЭТИКА, а вот ЭСТЕТИКА.
Ссылки на подробные объяснения и работы по теме "профессиональная этика" не буду приводить.
А пишу я это всё о тех, кто часто слышит в ответ "ртфм", "stfw", "не тупи" и про "ошибку в днк", и для тех, кто уже начал задаваться вопросами "как правильно писать операторную скобку?", "какое количество отступов лучше использовать?", "обязательно ли указывать return в явном виде в каждой процедуре?", "почему массивы начинаются с ноля?", "зачем учить двоичную арифметику?" и т.д.
Если у вторых вертятся похожие вопросы - задайте их, подумаем вместе.
Первым сразу рекомендую обратиться к статье "Как правильно задавать вопросы" и научиться пользоваться поисковыми машинами.
Успехов.
// 12.2006
2008/10/16
Техническое задание, и как его писать
Техническое задание - самая важная (но не единственная) часть документации любого проекта. Для чего и кого оно необходимо вполне можно почитать в интернетах, попадаются неплохие статьи.
Ниже приведён список литературы, рекомендуемой к прочтению всеми, кто чувствует себя в силах писать техзадания:
* ГОСТ 2.004-88 Общие требования к выполнению конструкторских и технологических документов на печетающих и графических устройствах ЭВМ;
* ГОСТ 2.105-95 Общие требования к текстовым документам;
* ГОСТ 2.106-96 Текстовые документы;
* ГОСТ 2.109-73 Технический проект;
* ГОСТ Р 15.101-98 Порядок выполнения научно-исследовательских работ;
* ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем (Взамен ГОСТ 24.101-80, ГОСТ 24.102-80);
* ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. (Взамен ГОСТ 24.601-86, ГОСТ 24.602-86);
* ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы.Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85);
* ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем (Взамен ГОСТ 24.104-85 в части разд. 3.);
* РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.
И это неполный перечень; ознакомиться с документами можно, например, здесь http://www.nist.ru/hr/doc/gost/
Главными для ТЗ-писателя можно считать
ГОСТ 2.105-95 Общие требования к текстовым документам;
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы;
второй описывает содержание технического задания, а первый - как оно должно быть оформлено.
Успехов. Будут вопросы - задавайте
Ниже приведён список литературы, рекомендуемой к прочтению всеми, кто чувствует себя в силах писать техзадания:
* ГОСТ 2.004-88 Общие требования к выполнению конструкторских и технологических документов на печетающих и графических устройствах ЭВМ;
* ГОСТ 2.105-95 Общие требования к текстовым документам;
* ГОСТ 2.106-96 Текстовые документы;
* ГОСТ 2.109-73 Технический проект;
* ГОСТ Р 15.101-98 Порядок выполнения научно-исследовательских работ;
* ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем (Взамен ГОСТ 24.101-80, ГОСТ 24.102-80);
* ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. (Взамен ГОСТ 24.601-86, ГОСТ 24.602-86);
* ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы.Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85);
* ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем (Взамен ГОСТ 24.104-85 в части разд. 3.);
* РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.
И это неполный перечень; ознакомиться с документами можно, например, здесь http://www.nist.ru/hr/doc/gost/
Главными для ТЗ-писателя можно считать
ГОСТ 2.105-95 Общие требования к текстовым документам;
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы;
второй описывает содержание технического задания, а первый - как оно должно быть оформлено.
Успехов. Будут вопросы - задавайте
2008/10/15
К вопросам этики и эстетики в программировании. Часть 0 "Комментарий о комментариях".
Комментарии - одна из самых сложных тем в программировании. В каждом языке программирования существуют конструкции, не влияющие на ход программы и игнорируемые интерпретатором; почти каждое описание языка начинается с их указаний по их использованию (сразу после объявления синтаксиса, эти главы обычно пролистываются); и почти всякий программист хоть раз в жизни горько сожалел об отсутствии "этих бесполезных комментариев".
Комментарии - архинужная и архиважная вещь. Помимо прославления отдельного взятого author и установления его copyright на данный плод трудов, из правильно составленных комментариев обычно можно узнать о лицензии, месте данного кода в пакете, версии файла и пакета, дате, изменениях, содержании файла, используемых алгоритмах, процедурах, функциях, объектах, структуре файла и другие интересные вещи. Примеры см. в пакете pear.php.net.
Хотелось бы подчеркнуть, что комментарии никоим образом не заменяют и не подменяют необходимость документирования программного комплекса, общего хода работ и т.п.. Комментарии не являются заменой технической документации! При составлении техдокументации нельзя уповать на системы механического документирования (типа DoxyDoc), которые собирают подобие документации из комментариев в коде. Документирование - отдельный вид работ, который не рассматривается здесь, но, весьма вероятно, далее я напишу и об этом, и о ГОСТах на составление ТД, которые никто не отменял.
Вернёмся к сложности комментариев. Казалось бы, пока ничего сложного, написал что-нибудь эдакое:
// myfile.php, v.0.2, 2006, (c)me
и комментарий готов. Ан нет; комментарию, помимо свойства краткости, должно быть присуще свойство полноты, либо достаточности. Комментария должно быть достаточно для понимания другим равноквалифицированным специалистом исходящих данных об описываемом объекте. Например:
// myfile.php, v.0.2, main file of MyProject - part 0 - examples' Remark for comments, 2006, (c)me
Ещё одно свойство комментариев - отсутствие избыточности и тавтологии. Например, нет необходимости писать такой комментарий в подобной ситуации:
// Create Objects
function createObj( $objName )
Но, если б эта функция, например, была бы методом некоего класса, комментарий мог бы выглядеть так:
/**
Factory method, фабричный метод
@param $objName имя класса объекта, string
@return $ret ссылка на новый объект требуемого класса
*/
function & createObj( $objName )
{
$ret = & new $objName;
return $ret;
}
Пояснения: а) фабричный метод - один из паттернов проектирования (design pattern), здесь не рассматривается. См. соответсвующую литературу. б) Использован синтаксис PHP. в) Стиль комментариев: DoxyDoc, опции Java, C.
Из данного комментария мы можем почерпнуть информацию о целевом назначении метода, о принимаемых параметрах и возвращаемых значениях. И таким образом, не вдаваясь в детали реализации, положившись на профессональную честность автора в области обезбаживания собственного кода, можем использовать программный интерфейс для собственных нужд. (Если на то есть соответствующее разрешение, лицензия.)
Кстати, совсем не дурно было бы составлять комментарии не только на Вашем родном языке, но и на одном из "языков межнационального общения" принятых ООН, в соответствии с предполагаемым ареалом распространения Вашего кода. И очень хорошо, когда комментарий написан грамотно! Повторяю: грамотно.
Можно ли обойтись без комментариев, не писать их? Угадали, конечно можно! Некоторые авторы именно так и поступают. Я сам знаю лично несколько человек.
По поводу отсутствия комментариев существует несколько мнений. Если не принимать во внимание оскорбительные мнения типа "автор кода - лентяй", можно выделить три точки зрения:
1) либо автор - гений, и он способен держать в собственной памяти все назначения переменных, функций, именования объектов и его голова от этого не пухнет;
2) либо автор считает, что написанный им код настолько ясен и доступен для понимания, что нет необходимости его документировать и комментировать;
3) либо автор предполагает, что код не будет использоваться ещё где- и когда-либо, и просто решил сэкономаить время на писании комментариев.
Первый случай обычно можно узнать по конструкциям типа if(!isset($var) && $var===true), третий - по сваленному в кучу неформатированному коду, второй - когда Вы просматриваете файл и видите исходящий от кода свет, на Вас снисходит благодать и Вы чувствуете переход в godmode, и в каждой руке по бфг9000, и фулплейт, и уже нет небходимости жать IDDQAIDKFA...
Wake up!
Write comments!
// праснис! пешы каменты!
#####################
# (c)me, 2005-2006, 24-26.11.2006
# К вопросам этики и эстетики в программировании, часть 0
#
Комментарии - архинужная и архиважная вещь. Помимо прославления отдельного взятого author и установления его copyright на данный плод трудов, из правильно составленных комментариев обычно можно узнать о лицензии, месте данного кода в пакете, версии файла и пакета, дате, изменениях, содержании файла, используемых алгоритмах, процедурах, функциях, объектах, структуре файла и другие интересные вещи. Примеры см. в пакете pear.php.net.
Хотелось бы подчеркнуть, что комментарии никоим образом не заменяют и не подменяют необходимость документирования программного комплекса, общего хода работ и т.п.. Комментарии не являются заменой технической документации! При составлении техдокументации нельзя уповать на системы механического документирования (типа DoxyDoc), которые собирают подобие документации из комментариев в коде. Документирование - отдельный вид работ, который не рассматривается здесь, но, весьма вероятно, далее я напишу и об этом, и о ГОСТах на составление ТД, которые никто не отменял.
Вернёмся к сложности комментариев. Казалось бы, пока ничего сложного, написал что-нибудь эдакое:
// myfile.php, v.0.2, 2006, (c)me
и комментарий готов. Ан нет; комментарию, помимо свойства краткости, должно быть присуще свойство полноты, либо достаточности. Комментария должно быть достаточно для понимания другим равноквалифицированным специалистом исходящих данных об описываемом объекте. Например:
// myfile.php, v.0.2, main file of MyProject - part 0 - examples' Remark for comments, 2006, (c)me
Ещё одно свойство комментариев - отсутствие избыточности и тавтологии. Например, нет необходимости писать такой комментарий в подобной ситуации:
// Create Objects
function createObj( $objName )
Но, если б эта функция, например, была бы методом некоего класса, комментарий мог бы выглядеть так:
/**
Factory method, фабричный метод
@param $objName имя класса объекта, string
@return $ret ссылка на новый объект требуемого класса
*/
function & createObj( $objName )
{
$ret = & new $objName;
return $ret;
}
Пояснения: а) фабричный метод - один из паттернов проектирования (design pattern), здесь не рассматривается. См. соответсвующую литературу. б) Использован синтаксис PHP. в) Стиль комментариев: DoxyDoc, опции Java, C.
Из данного комментария мы можем почерпнуть информацию о целевом назначении метода, о принимаемых параметрах и возвращаемых значениях. И таким образом, не вдаваясь в детали реализации, положившись на профессональную честность автора в области обезбаживания собственного кода, можем использовать программный интерфейс для собственных нужд. (Если на то есть соответствующее разрешение, лицензия.)
Кстати, совсем не дурно было бы составлять комментарии не только на Вашем родном языке, но и на одном из "языков межнационального общения" принятых ООН, в соответствии с предполагаемым ареалом распространения Вашего кода. И очень хорошо, когда комментарий написан грамотно! Повторяю: грамотно.
Можно ли обойтись без комментариев, не писать их? Угадали, конечно можно! Некоторые авторы именно так и поступают. Я сам знаю лично несколько человек.
По поводу отсутствия комментариев существует несколько мнений. Если не принимать во внимание оскорбительные мнения типа "автор кода - лентяй", можно выделить три точки зрения:
1) либо автор - гений, и он способен держать в собственной памяти все назначения переменных, функций, именования объектов и его голова от этого не пухнет;
2) либо автор считает, что написанный им код настолько ясен и доступен для понимания, что нет необходимости его документировать и комментировать;
3) либо автор предполагает, что код не будет использоваться ещё где- и когда-либо, и просто решил сэкономаить время на писании комментариев.
Первый случай обычно можно узнать по конструкциям типа if(!isset($var) && $var===true), третий - по сваленному в кучу неформатированному коду, второй - когда Вы просматриваете файл и видите исходящий от кода свет, на Вас снисходит благодать и Вы чувствуете переход в godmode, и в каждой руке по бфг9000, и фулплейт, и уже нет небходимости жать IDDQAIDKFA...
Wake up!
Write comments!
// праснис! пешы каменты!
#####################
# (c)me, 2005-2006, 24-26.11.2006
# К вопросам этики и эстетики в программировании, часть 0
#
2008/10/14
2008/10/02
польза
http://www.skillz.ru/
именно блог здесь http://www.skillz.ru/dev/
мне понравилось. склад технической информации. с человекопонятными объяснениями. автор знает, о чем пишет. рекомендую.
да, популярные темы, но не копипаста
зы: нет, мне не платили за рекламу цсм
именно блог здесь http://www.skillz.ru/dev/
мне понравилось. склад технической информации. с человекопонятными объяснениями. автор знает, о чем пишет. рекомендую.
да, популярные темы, но не копипаста
зы: нет, мне не платили за рекламу цсм
2008/09/30
Каждый блоггер обязан
Каждый блоггер обязан чтить и неукоснительно исполнять "правила хорошего бложика" :)
Правило первое: всем рассказывать о своём бложике
Правило второе: всегда всем рассказывать о своём бложике
а если серьёзно, то
Правило третье: в блог надо писать, надо кормить читателя контентом
Правило четвёртое: грамотного читателя надо кормить качественным контентом; надо хоть немного разбираться в том, о чём пишешь.
Грамотного читателя всегда приятнее видеть в бложике, чем неграмотного.
Правило первое: всем рассказывать о своём бложике
Правило второе: всегда всем рассказывать о своём бложике
а если серьёзно, то
Правило третье: в блог надо писать, надо кормить читателя контентом
Правило четвёртое: грамотного читателя надо кормить качественным контентом; надо хоть немного разбираться в том, о чём пишешь.
Грамотного читателя всегда приятнее видеть в бложике, чем неграмотного.
2008/09/26
важное дополнение к предыдущему посту
мало кто помнит, да чего уже там! мало кто вообще знает, что изначально в MVC было две буквы M - MMVC:
одна M для "бизнес-логики", а другая M - для приложения.
так как человекам свойственно всё упрощать, вот и доупрощались: сначала букву потеряли, а затем и смысл. свалили всё в кучу, пересказали школьникам, которые, разумеется, всё и понять-то не могли.
в результате что имеем в отрасли? в начальниках и "тимлидах" - тупые двадцатилетние студенты, выгнанные из бауманки, гении на всю голову, коллайдера на них нет, под чьим "руководством" криативятся миллионные проекты и десятки тысяч строк кода, там где при нормальном дизайне можно было бы обойтись лишь сотнями. ну и далее - проблемы с тестированием и поддержкой, и поток килорублей, текущий мимо. мимо всего.
одна M для "бизнес-логики", а другая M - для приложения.
так как человекам свойственно всё упрощать, вот и доупрощались: сначала букву потеряли, а затем и смысл. свалили всё в кучу, пересказали школьникам, которые, разумеется, всё и понять-то не могли.
в результате что имеем в отрасли? в начальниках и "тимлидах" - тупые двадцатилетние студенты, выгнанные из бауманки, гении на всю голову, коллайдера на них нет, под чьим "руководством" криативятся миллионные проекты и десятки тысяч строк кода, там где при нормальном дизайне можно было бы обойтись лишь сотнями. ну и далее - проблемы с тестированием и поддержкой, и поток килорублей, текущий мимо. мимо всего.
2008/09/25
МВЦ не существует!
Утверждение в заголовке звучит весьма резко и вызывающе, и многие сразу начинают с ним спорить.
На самом деле, это краткая форма более полного утверждения: «В настощее время на текущем этапе развития научно-технического прогресса, теории и практики алгоритмизации и программирования, реализация теоретического обоснования идеи MVC (Model-View-Controller Данные-Представление-Управление) в полной мере невозможна». Ещё раз: речь идёт о невозможности реализации, соответствующей теоретическему обоснованию идеи.
Возможны лишь некоторые приближения. После некоторых допущений.
А теперь по порядку:
а) МВЦ так и не имеет канонического описания. И каждый вправе думать про него что хочет.
б) МВЦ не имеет канонического описания по факту своего появления. Его придумали и начали использовать программисты Small Talk в программировании (исключительно!) пользовательских интерфейсов.
в) Причём, если мы будем фанатично следовать триразделённости МВЦ в проектировании приложений, забывая о пункте б), что часто бывает, может возникнуть примерно следующая ситуация:
Это нереализуемая патовая ситуация.
Любой другой вариант является отклонением от исходного разделения и удаляет нас от МВЦ.
г) В свете вышесказанного особенно опасно говорить о МВЦ в приложениях, которые фактически не имеют тесной связи с клиентской частью. На мой взгляд, это все веб-приложения, за исключением, может быть, ява-апплетов.
д) Все виденные мною «реализации МВЦ» для пхп (все берут корни из phptemplates.org когда он был ещё жив; не ходите туда сейчас – там чей-то пустой блог) не являются МВЦ, это плохие эмуляции. Хотя бы потому, что классический МВЦ утверждает независимость трёх компонентов. Которая отсутствует в этих эмуляциях.
е) Даже полная «объектизация» языка программирования не помогает в реализации МВЦ.
Нет ничего плохого, если вы используете какой-либо из ранее найденных на просторах интернета шаблонов якобы МВЦ, или даже придумали свою реализацию %) Присмотритесь к ней внимательней, и вам захочется рефакторить её и рефакторить, и рефакторить, и рефакторить...
Не надо называть МВЦ то, что МВЦ не является.
На мой взгляд, о МВЦ нельзя думать как о шаблоне (pattern) реализации или разработки, и даже говоря о МВЦ как о шаблоне проектирования, не надо закладывать в схему (в проект) эти три буквы %) Лучше уж «проект пишем, МВЦ в уме».
На самом деле, это краткая форма более полного утверждения: «В настощее время на текущем этапе развития научно-технического прогресса, теории и практики алгоритмизации и программирования, реализация теоретического обоснования идеи MVC (Model-View-Controller Данные-Представление-Управление) в полной мере невозможна». Ещё раз: речь идёт о невозможности реализации, соответствующей теоретическему обоснованию идеи.
Возможны лишь некоторые приближения. После некоторых допущений.
А теперь по порядку:
а) МВЦ так и не имеет канонического описания. И каждый вправе думать про него что хочет.
б) МВЦ не имеет канонического описания по факту своего появления. Его придумали и начали использовать программисты Small Talk в программировании (исключительно!) пользовательских интерфейсов.
в) Причём, если мы будем фанатично следовать триразделённости МВЦ в проектировании приложений, забывая о пункте б), что часто бывает, может возникнуть примерно следующая ситуация:
предположим, контроллер получает сигнал о необходимости изменений представления данных, обращается в модель за данными, модель (как достаточно высокоуровневая система) обращается к подсистеме хранения данных. И, следуя идее МВЦ, обращается она к контроллеру подсистемы, который запрашивает собственную модель, и т.д. вглубь...
Это нереализуемая патовая ситуация.
Любой другой вариант является отклонением от исходного разделения и удаляет нас от МВЦ.
г) В свете вышесказанного особенно опасно говорить о МВЦ в приложениях, которые фактически не имеют тесной связи с клиентской частью. На мой взгляд, это все веб-приложения, за исключением, может быть, ява-апплетов.
д) Все виденные мною «реализации МВЦ» для пхп (все берут корни из phptemplates.org когда он был ещё жив; не ходите туда сейчас – там чей-то пустой блог) не являются МВЦ, это плохие эмуляции. Хотя бы потому, что классический МВЦ утверждает независимость трёх компонентов. Которая отсутствует в этих эмуляциях.
е) Даже полная «объектизация» языка программирования не помогает в реализации МВЦ.
Нет ничего плохого, если вы используете какой-либо из ранее найденных на просторах интернета шаблонов якобы МВЦ, или даже придумали свою реализацию %) Присмотритесь к ней внимательней, и вам захочется рефакторить её и рефакторить, и рефакторить, и рефакторить...
Не надо называть МВЦ то, что МВЦ не является.
На мой взгляд, о МВЦ нельзя думать как о шаблоне (pattern) реализации или разработки, и даже говоря о МВЦ как о шаблоне проектирования, не надо закладывать в схему (в проект) эти три буквы %) Лучше уж «проект пишем, МВЦ в уме».
Вот, кажется, и всё. Это из личного опыта и опыта виртуальных коллег.
Надеюсь, прочитанное вам поможет. Хотя, см. п. а)
зы: тоже польза http://phpclub.ru/talk/showthread.php?threadid=71560&highlight=mvc
зы2: статья основана на переписке с потенциальным работодателем. и полугодичных мытарствах с mvcговнопаттернами
лето 2007г
Надеюсь, прочитанное вам поможет. Хотя, см. п. а)
зы: тоже польза http://phpclub.ru/talk/showthread.php?threadid=71560&highlight=mvc
зы2: статья основана на переписке с потенциальным работодателем. и полугодичных мытарствах с mvcговнопаттернами
лето 2007г
ps: http://angry-web.blogspot.com/2008/09/blog-post_26.html
люди и деньги
деньги, как известно, пятое состояние вещества и пятое измерение. они совершенно свободно конвертируются во что угодно. во время, например. или пространство. или яблоки.
но я не стал писать в предыдущем посте о том, что хочу денег. это пошло и банально. заезжено, запилено и растерзано по разного рода бложикам без меня.
не я стал я писать и о том, что не хочу денег. люди, которые говорят, что не хотят денег - лгут. прежде всего себе
но я не стал писать в предыдущем посте о том, что хочу денег. это пошло и банально. заезжено, запилено и растерзано по разного рода бложикам без меня.
не я стал я писать и о том, что не хочу денег. люди, которые говорят, что не хотят денег - лгут. прежде всего себе
это будет первое сообщение
первому сообщению, как и всяким другим первым штукам, люди склонны придавать мистические смыслы и практические подоплёки.
так вот, всё это ерунда. просто расскажу, для чего я завёл ещё и этот уютненький бложик:
а) стало тесно в уютненькой жежешечке
б) надо ж куда-то откладывать умные мысли
в) надеюсь, не только мне будет интересно следить за захватом мира
г) а после события из п. в) этот блог может служить пособием "как не надо делать"
зы: также, я постараюсь изложить много из того, что знаю на тему "как делать надо"
так вот, всё это ерунда. просто расскажу, для чего я завёл ещё и этот уютненький бложик:
а) стало тесно в уютненькой жежешечке
б) надо ж куда-то откладывать умные мысли
в) надеюсь, не только мне будет интересно следить за захватом мира
г) а после события из п. в) этот блог может служить пособием "как не надо делать"
зы: также, я постараюсь изложить много из того, что знаю на тему "как делать надо"
Подписаться на:
Сообщения (Atom)
Сообщения
