Дорогой блог!
Как ты конечно помнишь, недавно я рассказывал тебе о композиции и наследовании внутри людей. А пару дней назад я обнаружил, что люди умеют делать еще одну штуку, которую обычно умеют делать хорошие программы. Это модульность.
Ты же знаешь, что модульность - это когда можно брать не всю программу целиком, а только ее часть, и все будет работать хорошо, если взять правильную часть. А еще это значит, что прямо во время работы от программы можно отключить другую часть, и она все равно будет работать. Мы вот пишем разные программы., но самая главная среди них - модульная, потому что мы пишем ее хорошо, хоть и не всегда.
А на днях я разговаривал с одной тетенькой, она наш эксперт. Вот, и мы с ней замечательно говорили про предметную область и задачки. А потом она сказала, что в нашей программе есть ошибка, а я ее спросил, какая ошибка, а она сказал, что не знает и там написано непонятно, а я сказал, что написано по-русски и пусть хотя бы прочитает или пришлет скриншот. А она мне тогда сказала, что не понимает, что ей надо сделать, хотя до этого присылала мне много скриншотов.
Я тогда очень расстроился, потому что мы не можем исправить свою ошибку. А потом я стал думать, почему тетенька-эксперт себя так повела, и придумал, что она тоже модульная. Ведь она же просто отключила модуль мозга и стала дальше работать, как ни в чем не бывало. По-моему это просто прекрасно, когда люди становятся модульными, как хорошие программы. Только я так и не узнал, какая ошибка у нас в программе.
Дорогоуважаемые программисты! Помните, что модульность - это очень хорошо, особенно когда вы пишете сложные программы. А еще есть модульность в людях, и это тоже хорошо и можно так натренироваться, что самому стать модульным. Тогда вы сможете отключать мозг, и никто не сможет его съесть или еще что-нибудь.
До скорых встреч!
Показаны сообщения с ярлыком программирование. Показать все сообщения
Показаны сообщения с ярлыком программирование. Показать все сообщения
четверг, 13 октября 2011 г.
среда, 31 августа 2011 г.
Про наследование и композицию в людях
Дорогой блог!
Сегодня я хочу поговорить с тобой про композицию и множественное наследование. Но не как обычно с классами и интерфейсами, а с настоящими людьми. Я тебе сейчас расскажу, что это такое. Композиция - это когда ты становишься начальником (представляешь!) и набираешь себе подчиненных и даешь им всякие указания, а сам следишь, чтобы они их выполняли. Тогда ты очень важный человек, и еще настоящий композитор людей. А множественное наследование - это когда ты один планктон и сам все делаешь: и за начальника, и за программистов, и за тестировщиков, и за всех других планктонов.
Мы с тобой знаем, что множественное наследование классов - это не очень хорошо, потому что можно очень сильно запутаться и написать плохую программу. А множественное наследование людей - это ничего, потому что есть такие специальные люди фрилансеры, и они так живут. А композиция - это вообще отлично, потому что так работает много-много начальников и еще больше планктонов.
А мой начальник - он не такой, как все. Он умеет делать сразу и композицию, и множественное наследование: он вроде как начальник и дает нам указания, а еще сам программирует, встраивает и тестирует. Вот какой он молодец. А еще я сегодня узнал, что в моем начальнике есть баг, потому что он программирует только в своей песочнице, а говорит, что в общем коде. И от этого бага у нашего продукта до сих пор нет очень важного компонента, хотя у нас уже был релиз. Получается, что мой начлаьник не только человек, но еще и класс.
Дорогоуважаемые программисты! Помните, что в коде хорошо совмещать наследование и композицию, но множественное наследование - это плохо. А в жизни все наоборот - множественное наследование может быть хорошим, но его нельзя совмещать с композицией. А еще нельзя быть сразу человеком и классом, потому что это разные вещи. Вы уж пожалуйста определитесь, кем вы хотите быть и какие отношения делать. Тогда у вас все будет хорошо и здорово.
До скорых встреч!
Сегодня я хочу поговорить с тобой про композицию и множественное наследование. Но не как обычно с классами и интерфейсами, а с настоящими людьми. Я тебе сейчас расскажу, что это такое. Композиция - это когда ты становишься начальником (представляешь!) и набираешь себе подчиненных и даешь им всякие указания, а сам следишь, чтобы они их выполняли. Тогда ты очень важный человек, и еще настоящий композитор людей. А множественное наследование - это когда ты один планктон и сам все делаешь: и за начальника, и за программистов, и за тестировщиков, и за всех других планктонов.
Мы с тобой знаем, что множественное наследование классов - это не очень хорошо, потому что можно очень сильно запутаться и написать плохую программу. А множественное наследование людей - это ничего, потому что есть такие специальные люди фрилансеры, и они так живут. А композиция - это вообще отлично, потому что так работает много-много начальников и еще больше планктонов.
А мой начальник - он не такой, как все. Он умеет делать сразу и композицию, и множественное наследование: он вроде как начальник и дает нам указания, а еще сам программирует, встраивает и тестирует. Вот какой он молодец. А еще я сегодня узнал, что в моем начальнике есть баг, потому что он программирует только в своей песочнице, а говорит, что в общем коде. И от этого бага у нашего продукта до сих пор нет очень важного компонента, хотя у нас уже был релиз. Получается, что мой начлаьник не только человек, но еще и класс.
Дорогоуважаемые программисты! Помните, что в коде хорошо совмещать наследование и композицию, но множественное наследование - это плохо. А в жизни все наоборот - множественное наследование может быть хорошим, но его нельзя совмещать с композицией. А еще нельзя быть сразу человеком и классом, потому что это разные вещи. Вы уж пожалуйста определитесь, кем вы хотите быть и какие отношения делать. Тогда у вас все будет хорошо и здорово.
До скорых встреч!
вторник, 7 апреля 2009 г.
Про рисунки
Дорогой блог!
Сегодня я хочу поговорить с тобой о базах данных. Ты конечно знаешь, что базы данных - это такая штука, в которой можно хранить всякие штуки. А еще в них можно связывать одни штуки с другими, для этого умные дяденьки рисуют красивые рисунки с квадратиками и стрелочками и называют их схемами баз данных.
А не такие умные дяденьки, вот как мы с тобой, например, смотрят на эти схемы и удивляются. А еще иногда умные дяденьки говорят не очень умным дяденькам дорисовать их рисунки, потому что у них нет времени. Между нами говоря, я думаю, что им лень рисовать или они просто тоже не очень умные дяденьки, а ты как думаешь? Вот, мне недавно умный дяденька сказал дорисовать за него немножко схемы.
А оказалось, что он уже почти все нарисовал сам, а мне надо просто сделать такую штуку, чтобы к одни его квадратики могли использовать другие его квадратики. Но для этого надо дорисовать свои квадратики и стрелочки, а его квадратики совсем-совсем нельзя трогать. А потом я понял, что мне нужен на самом деле один квадратик и две стрелочки: от него и к нему.
Но я не мог так сделать, потому что для этого мне пришлось бы перерисовать квадратик умного дяденьки. И тогда я придумал нарисовать два своих квадратика, а чужие квадратики не трогать:
Дорогоуважаемые программисты! Рисовать квадратики и стрелочки - это очень хорошо и весело. А еще умные дяденьки называют это красивыми словами абстракция и проектирование.
До скорых встреч!
Сегодня я хочу поговорить с тобой о базах данных. Ты конечно знаешь, что базы данных - это такая штука, в которой можно хранить всякие штуки. А еще в них можно связывать одни штуки с другими, для этого умные дяденьки рисуют красивые рисунки с квадратиками и стрелочками и называют их схемами баз данных.
А не такие умные дяденьки, вот как мы с тобой, например, смотрят на эти схемы и удивляются. А еще иногда умные дяденьки говорят не очень умным дяденькам дорисовать их рисунки, потому что у них нет времени. Между нами говоря, я думаю, что им лень рисовать или они просто тоже не очень умные дяденьки, а ты как думаешь? Вот, мне недавно умный дяденька сказал дорисовать за него немножко схемы.
А оказалось, что он уже почти все нарисовал сам, а мне надо просто сделать такую штуку, чтобы к одни его квадратики могли использовать другие его квадратики. Но для этого надо дорисовать свои квадратики и стрелочки, а его квадратики совсем-совсем нельзя трогать. А потом я понял, что мне нужен на самом деле один квадратик и две стрелочки: от него и к нему.
Но я не мог так сделать, потому что для этого мне пришлось бы перерисовать квадратик умного дяденьки. И тогда я придумал нарисовать два своих квадратика, а чужие квадратики не трогать:
Дорогоуважаемые программисты! Рисовать квадратики и стрелочки - это очень хорошо и весело. А еще умные дяденьки называют это красивыми словами абстракция и проектирование.
До скорых встреч!
пятница, 20 марта 2009 г.
Повышение уровня!
Дорогой блог!
Сегодня я расскажу тебе об опыте пользователя. Опыт пользователя - это такая штука, которая остается у пользователя после того, как он чем-то попользовался. Например, когда я пользуюсь чаем из чашки, у меня остается опыт выпивания горячего чая, а еще опыт держания чашки, а еще опыт питья из чашки. Вот сколько всякого опыта у меня остается.
Дорогой дневник, как ты думаешь, почему я до сих пор не получил следущий уровень и новые навыки? Меня это очень беспокоит.
А когда я работаю планктоном, я пользуюсь разными программами: операционной системой, почтой, браузером, и даже средой разработки визуал студио, и другими программами. Вот, а еще я пользуюсь программой, которую пишу я и другие программисты, и архитектор. И от этого всего я тоже получаю опыт, и это очень хорошо и весело.
А вчера я программировал и увидел большую Проблему. Но я не испугался, потому что я хороший программист и умею находить решения Проблем. Я стал искать их в нашей программе, и нашел сразу много: целых три! Так здорово, когда у тебя есть целых три чего-нибудь! А потом я стал их изучать и увидел, что они все очень разные, но решают одну Проблему. И я очень расстроился, потому что не знал, какое использовать, а потом увидел, что можно все три сразу. А еще я расстроился от того, что одно решение было очень-очень-очень плохим, а другое решение было тоже не очень хорошим, а третье было непонятным. А потом я поговорил с начальником и архитектором, и они мне сказали, что знают только об одном решении, которое не очень хорошее, и сказали, что я могу использовать любое, которое мне понравится. Я стал разбираться во всех трех решениях и получил очень много опыта пользователя кода нашей программы. А потом я снова расстроился, потому что понял, что программисты, которые запрограммировали эти три решения не подумали, какой опыт пользователя я получу, и какое решение сделал архитектор.
Дорогоуважаемые программисты, аналитики, архитекторы, дизайнеры, начальники и менеджеры! Я очень люблю получать опыт пользователя, потому что это очень хорошо и полезно, хоть и не всегда приятно. Желаю вам всегда-всегда получать такой опыт, а еще я желаю вам вспоминать о своем опыте пользователя и представлять себя пользователем своих программ и других предметов.
До скорых встреч!
Сегодня я расскажу тебе об опыте пользователя. Опыт пользователя - это такая штука, которая остается у пользователя после того, как он чем-то попользовался. Например, когда я пользуюсь чаем из чашки, у меня остается опыт выпивания горячего чая, а еще опыт держания чашки, а еще опыт питья из чашки. Вот сколько всякого опыта у меня остается.
Дорогой дневник, как ты думаешь, почему я до сих пор не получил следущий уровень и новые навыки? Меня это очень беспокоит.
А когда я работаю планктоном, я пользуюсь разными программами: операционной системой, почтой, браузером, и даже средой разработки визуал студио, и другими программами. Вот, а еще я пользуюсь программой, которую пишу я и другие программисты, и архитектор. И от этого всего я тоже получаю опыт, и это очень хорошо и весело.
А вчера я программировал и увидел большую Проблему. Но я не испугался, потому что я хороший программист и умею находить решения Проблем. Я стал искать их в нашей программе, и нашел сразу много: целых три! Так здорово, когда у тебя есть целых три чего-нибудь! А потом я стал их изучать и увидел, что они все очень разные, но решают одну Проблему. И я очень расстроился, потому что не знал, какое использовать, а потом увидел, что можно все три сразу. А еще я расстроился от того, что одно решение было очень-очень-очень плохим, а другое решение было тоже не очень хорошим, а третье было непонятным. А потом я поговорил с начальником и архитектором, и они мне сказали, что знают только об одном решении, которое не очень хорошее, и сказали, что я могу использовать любое, которое мне понравится. Я стал разбираться во всех трех решениях и получил очень много опыта пользователя кода нашей программы. А потом я снова расстроился, потому что понял, что программисты, которые запрограммировали эти три решения не подумали, какой опыт пользователя я получу, и какое решение сделал архитектор.
Дорогоуважаемые программисты, аналитики, архитекторы, дизайнеры, начальники и менеджеры! Я очень люблю получать опыт пользователя, потому что это очень хорошо и полезно, хоть и не всегда приятно. Желаю вам всегда-всегда получать такой опыт, а еще я желаю вам вспоминать о своем опыте пользователя и представлять себя пользователем своих программ и других предметов.
До скорых встреч!
четверг, 29 января 2009 г.
Памятные даты
Дорогой блог!
Я хочу сегодня рассказать тебе о датах. Ты конечно знаешь, что есть разные даты: дни рождения, Новый Год и 23 февраля. А еще у всех-всех дат есть год. А некоторые базы данных говорят, что в них нельзя записать даты меньше 1 января 1753 года. Мне от этого становится очень грустно и печально, потому что я уже никогда не смогу записать в них все даты из моего любимого учебника истории.
Сегодня другой программист научил меня правильно и быстро проверять год дат. Он сказал, что для этого нужно только проверить длину строки, а если она вдруг окажется меньше 10 (2 буквы на день, 2 буквы на месяц, 4 буквы на год и еще 2 точки), то год неправильный. Вот как хорошо и здорово можно проверять год!
Дорогоуважаемые программисты! Пожалуйста всегда-всегда проверяйте свои даты только так, и тогад у вас не будут появляться глупые ошибки, а будут появляться только умные и сложные.
До скорых встреч!
Я хочу сегодня рассказать тебе о датах. Ты конечно знаешь, что есть разные даты: дни рождения, Новый Год и 23 февраля. А еще у всех-всех дат есть год. А некоторые базы данных говорят, что в них нельзя записать даты меньше 1 января 1753 года. Мне от этого становится очень грустно и печально, потому что я уже никогда не смогу записать в них все даты из моего любимого учебника истории.
Сегодня другой программист научил меня правильно и быстро проверять год дат. Он сказал, что для этого нужно только проверить длину строки, а если она вдруг окажется меньше 10 (2 буквы на день, 2 буквы на месяц, 4 буквы на год и еще 2 точки), то год неправильный. Вот как хорошо и здорово можно проверять год!
Дорогоуважаемые программисты! Пожалуйста всегда-всегда проверяйте свои даты только так, и тогад у вас не будут появляться глупые ошибки, а будут появляться только умные и сложные.
До скорых встреч!
среда, 21 января 2009 г.
Сабвершен
Дорогой блог!
Сегодня я расскажу тебе о сабвершене. Это такаяспециальная прогармма для хранения файлов и папок, которая умеет хранить их разные версии.
Несколько дней назад я очень расстроился, потому что моя программа перестала компилироваться, а компилятор мне говорил только непонятные штуки. А потом я сделал так, чтобы программа компилировалась, но когда я ее запустил, она не заработала, а стала говорить, что в моих классах не хватает методов и свойств и есть много ошибок.
Я совсем расстроился, потому что я теперь не могу писать эту программу, а она очень нужна менеджеру, и архитектру, и аналитикам, и заказчику.
А потом я и другой программист три дня пытались сделать так, чтобы программа снова работала и не говорила, что внутри есть ошибки, потому что их там нет, но у нас ничего не получалось. А потом другой программист предложил еще раз скачать из сабвершена всю программу и перекомпилировать ее, а я согласился. Тогда программа перестала даже компилироваться, а другой ограммист ушел на свой компьютер и сказал, что у него все компилируется, и я очень испугался и снова расстроился. А другйо программист сказал, что надо заново взять весь транк из сабвершена попробовать еще раз, потому чо он тоже не знает, в чем дело.
И это помогло нас скомпилировать и заставить работать программу!
Дорогоуважаемые программисты! Будьте осторожны с сабвершеном, потому что он хитрый и ингда делает то, что хочет, а не то, что ему говорят. А еще он иногда теряет файлы и ломает программы.
До скорых встреч!
Сегодня я расскажу тебе о сабвершене. Это такаяспециальная прогармма для хранения файлов и папок, которая умеет хранить их разные версии.
Несколько дней назад я очень расстроился, потому что моя программа перестала компилироваться, а компилятор мне говорил только непонятные штуки. А потом я сделал так, чтобы программа компилировалась, но когда я ее запустил, она не заработала, а стала говорить, что в моих классах не хватает методов и свойств и есть много ошибок.
Я совсем расстроился, потому что я теперь не могу писать эту программу, а она очень нужна менеджеру, и архитектру, и аналитикам, и заказчику.
А потом я и другой программист три дня пытались сделать так, чтобы программа снова работала и не говорила, что внутри есть ошибки, потому что их там нет, но у нас ничего не получалось. А потом другой программист предложил еще раз скачать из сабвершена всю программу и перекомпилировать ее, а я согласился. Тогда программа перестала даже компилироваться, а другой ограммист ушел на свой компьютер и сказал, что у него все компилируется, и я очень испугался и снова расстроился. А другйо программист сказал, что надо заново взять весь транк из сабвершена попробовать еще раз, потому чо он тоже не знает, в чем дело.
И это помогло нас скомпилировать и заставить работать программу!
Дорогоуважаемые программисты! Будьте осторожны с сабвершеном, потому что он хитрый и ингда делает то, что хочет, а не то, что ему говорят. А еще он иногда теряет файлы и ломает программы.
До скорых встреч!
понедельник, 15 декабря 2008 г.
Письма счастья
Дорогой блог!
Сегодня я расскажу тебе об одних письмах, которые называются MSMQ. Это такие специальные письма, их придумала вторая лучшая компания в мире, которые обязательно доходят до адресата или возвращаются обратно.
Я очень люблю писать и посылать разным людям письма: другим программистам, и аналитикам, и архитектору, и менеджеру, и субподрядчикам, и друзьям, и девушкам, и даже незнакомым людям. Субподрядчик, я тебе уже о нем рассказывал, дневник, и архитектор специально придумали так, чтобы наша программа и их программа посылали друг другу письма MSMQ. Я так рад этому решению! Больше всего я люблю спрашивать что-нибудь в письмах, и я научил нашу программу спрашивать другую программу про то, какие картинки у нее есть. А субподрядчик научил свою программу отвечать на мои письма и посылать в ответ картинки. Это так здорово!!! А недавно я узнал, что я могу получить только две или три картинки, а большие письма мне не приходят. Я очень расстроился, и менеджер расстроился, и даже начальник всего нашего отдела расстроился, потому что они тоже любят писать письма и смотреть картинки.
Тогда я и субподрядчик узнали, что письма MSMQ не могут быть очень большими, а только не больше 2 Мб. А еще мы узнали, что если у почтового ящика MSMQ поставить размер 100 Мб, то нельзя получить ни одного письма, потому что MSMQ тоже любит писать письма, но только уже сам себе.
Дорогоуважаемые программисты! Если вы тоже любите писать письма, обязательно пользуйтесь Почтой России, потому что там работает добрый почтальон Печкин, и проверяйте их размер. А если вы так много написали, что все не влезает в конверт, отправляйте бандероли и контейнерные перевозки.
До скорых встреч!
Сегодня я расскажу тебе об одних письмах, которые называются MSMQ. Это такие специальные письма, их придумала вторая лучшая компания в мире, которые обязательно доходят до адресата или возвращаются обратно.
Я очень люблю писать и посылать разным людям письма: другим программистам, и аналитикам, и архитектору, и менеджеру, и субподрядчикам, и друзьям, и девушкам, и даже незнакомым людям. Субподрядчик, я тебе уже о нем рассказывал, дневник, и архитектор специально придумали так, чтобы наша программа и их программа посылали друг другу письма MSMQ. Я так рад этому решению! Больше всего я люблю спрашивать что-нибудь в письмах, и я научил нашу программу спрашивать другую программу про то, какие картинки у нее есть. А субподрядчик научил свою программу отвечать на мои письма и посылать в ответ картинки. Это так здорово!!! А недавно я узнал, что я могу получить только две или три картинки, а большие письма мне не приходят. Я очень расстроился, и менеджер расстроился, и даже начальник всего нашего отдела расстроился, потому что они тоже любят писать письма и смотреть картинки.
Тогда я и субподрядчик узнали, что письма MSMQ не могут быть очень большими, а только не больше 2 Мб. А еще мы узнали, что если у почтового ящика MSMQ поставить размер 100 Мб, то нельзя получить ни одного письма, потому что MSMQ тоже любит писать письма, но только уже сам себе.
Дорогоуважаемые программисты! Если вы тоже любите писать письма, обязательно пользуйтесь Почтой России, потому что там работает добрый почтальон Печкин, и проверяйте их размер. А если вы так много написали, что все не влезает в конверт, отправляйте бандероли и контейнерные перевозки.
До скорых встреч!
пятница, 14 ноября 2008 г.
История про субподрядчика
Дорогой блог!
Сегодня я расскажу тебе об одном субподрядчике. Субподрядчики -- это такие специальные люди, которым можно поручить порученную нам работу и заплатить за это заплаченные нам деньги. Дорогой блог, не перепутай субподрядчиков с аутсосрсерами! Субподрядчик всегда показывает свою программу заказчику сам, а аутсорсер показывает ее нам, а мы потом ее показываем заказчику.
Вот, а сегодня я ездил к заказчику, чтобы с одним субподрядчиком протестировать, как их программа взаимодействует с нашей программой. Дорогой блог, ты уже знаешь, что мы -- хорошие программисты, поэтому наша программа заработала хорошо. А программа субподрядчика не заработала, но у него был с собой исходный код, и поэтому мы стали смотреть в него. Когда мы посмотрели туда, мне стало очень грустно, потому что я увидел, что субподрядчик все сделал не очень правильно и плохо тестировал свой код, поэтому ничего не заметил. Мне кажется, что субподрядчик -- не плохой программист, просто у него нет такого замечательного менеджера, и архитектора, и других программистов и аналитиков, как у меня, поэтому его программа так плохо работала.
Дорогоуважаемые программисты! Всегда проверяйте своих субподрядчиков, потому что хотя они и сами показывают свои программы заказчику, все равно виноваты оказываются все. А если вы вдруг увидите, что у субподрядчика есть хорошие программисты, архитекторы, менеджеры и аналитики, обязательно зовите их к себе, чтобы они и вас научили быть хорошим. А если у субподрядчика плохие программисты, и архитекторы, и менеджеры, и даже аналитики, не зовите их к себе, а поскорее тестируйте их программы и говорите им об ошибках.
До скорых встреч!
Сегодня я расскажу тебе об одном субподрядчике. Субподрядчики -- это такие специальные люди, которым можно поручить порученную нам работу и заплатить за это заплаченные нам деньги. Дорогой блог, не перепутай субподрядчиков с аутсосрсерами! Субподрядчик всегда показывает свою программу заказчику сам, а аутсорсер показывает ее нам, а мы потом ее показываем заказчику.
Вот, а сегодня я ездил к заказчику, чтобы с одним субподрядчиком протестировать, как их программа взаимодействует с нашей программой. Дорогой блог, ты уже знаешь, что мы -- хорошие программисты, поэтому наша программа заработала хорошо. А программа субподрядчика не заработала, но у него был с собой исходный код, и поэтому мы стали смотреть в него. Когда мы посмотрели туда, мне стало очень грустно, потому что я увидел, что субподрядчик все сделал не очень правильно и плохо тестировал свой код, поэтому ничего не заметил. Мне кажется, что субподрядчик -- не плохой программист, просто у него нет такого замечательного менеджера, и архитектора, и других программистов и аналитиков, как у меня, поэтому его программа так плохо работала.
Дорогоуважаемые программисты! Всегда проверяйте своих субподрядчиков, потому что хотя они и сами показывают свои программы заказчику, все равно виноваты оказываются все. А если вы вдруг увидите, что у субподрядчика есть хорошие программисты, архитекторы, менеджеры и аналитики, обязательно зовите их к себе, чтобы они и вас научили быть хорошим. А если у субподрядчика плохие программисты, и архитекторы, и менеджеры, и даже аналитики, не зовите их к себе, а поскорее тестируйте их программы и говорите им об ошибках.
До скорых встреч!
среда, 3 сентября 2008 г.
Общение
Дорогой блог!
Сегодня я хочу рассказать тебе о коммуникации. Ты уже знаешь, что обычно программы делают сразу несколько программистов, а еще аналитики, архитектор и менеджер, а иногда их тоже много. Когда все эти люди общаются между собой, это называется коммуникацией.
В хороших командах каждый человек знает, что он должен делать и с кем говорить, чтобы узнать что-то, или наоборот, рассказать о своих результатах. А еще в хороших командах все знают, кто чем занимается, и могут друг друга подменить. Вот, а еще коммуникация делает так, что кто-то или даже все обладают видением проекта в целом. А видение -- это очень хорошо, потому что с его помощью можно ставить цели и идти к ним.
Чтобы была коммуникация, есть много вяких вещей, например, методологий, о них я тебе расскажу как-нибудь в другой раз. В гибких методологиях предлагают собираться каждый день всей командой или только несколькоим людям и делиться своими проблемами и задачами. Так делают в ХР, и SCRUM, и других гибких методологиях. И это здорово, потому что опытные програмимсты могут помочь неопытным, а архитектор -- рассказать о каком-то куске системы, а аналитик -- о новых требованиях, а тестировщик -- о новых проблемах или еще о чем-нибудь. А менеджер может всех похвалить за то, что они не бездельничают, а проводят собрания и работают :)
Дорогоуважаемые программисты! Не забывайте о коммуникации и рассказывайте своим товарищам о том, что вы делаете. И все время спрашивайте, что они делают, потому что когда они заболеют или уйдут в отпуск, вам придется делать то, что делают они.
Дорогоуважаемые менеджеры! Не мешайте программистам общаться, потому что это хорошо и полезно. Иногда пятнадцать минут общения каждым утром сберегают недели разработки.
До скорых встреч!
Сегодня я хочу рассказать тебе о коммуникации. Ты уже знаешь, что обычно программы делают сразу несколько программистов, а еще аналитики, архитектор и менеджер, а иногда их тоже много. Когда все эти люди общаются между собой, это называется коммуникацией.
В хороших командах каждый человек знает, что он должен делать и с кем говорить, чтобы узнать что-то, или наоборот, рассказать о своих результатах. А еще в хороших командах все знают, кто чем занимается, и могут друг друга подменить. Вот, а еще коммуникация делает так, что кто-то или даже все обладают видением проекта в целом. А видение -- это очень хорошо, потому что с его помощью можно ставить цели и идти к ним.
Чтобы была коммуникация, есть много вяких вещей, например, методологий, о них я тебе расскажу как-нибудь в другой раз. В гибких методологиях предлагают собираться каждый день всей командой или только несколькоим людям и делиться своими проблемами и задачами. Так делают в ХР, и SCRUM, и других гибких методологиях. И это здорово, потому что опытные програмимсты могут помочь неопытным, а архитектор -- рассказать о каком-то куске системы, а аналитик -- о новых требованиях, а тестировщик -- о новых проблемах или еще о чем-нибудь. А менеджер может всех похвалить за то, что они не бездельничают, а проводят собрания и работают :)
Дорогоуважаемые программисты! Не забывайте о коммуникации и рассказывайте своим товарищам о том, что вы делаете. И все время спрашивайте, что они делают, потому что когда они заболеют или уйдут в отпуск, вам придется делать то, что делают они.
Дорогоуважаемые менеджеры! Не мешайте программистам общаться, потому что это хорошо и полезно. Иногда пятнадцать минут общения каждым утром сберегают недели разработки.
До скорых встреч!
вторник, 19 августа 2008 г.
Стиль
Дорогой блог!
Сегодня я немного расскажу тебе о стиле программирования.
Он должен быть единым для всей команды программистов. Тех, кто отказывается подчиняться этому требованию, необходимо убиватьубиватьубивать на месте. Потому что когда один программист что-то пишет не так, как остальные, а потом другой программист на это смотрит, у другого программиста начинает болеть и разрушаться мозг.
Дорогоуважаемые программисты! Пишите все в одном стиле, а то очень сложно поддерживать код.
До скорых встреч!
Сегодня я немного расскажу тебе о стиле программирования.
Он должен быть единым для всей команды программистов. Тех, кто отказывается подчиняться этому требованию, необходимо убиватьубиватьубивать на месте. Потому что когда один программист что-то пишет не так, как остальные, а потом другой программист на это смотрит, у другого программиста начинает болеть и разрушаться мозг.
Дорогоуважаемые программисты! Пишите все в одном стиле, а то очень сложно поддерживать код.
До скорых встреч!
понедельник, 18 августа 2008 г.
Родословные юз кейсов
Дорогой блог!
Сегодня я расскажу тебе о юз кейсах. Это такие штуки, которые говорят, как можно и нужно использовать что-нибудь. Их можно рисовать и читать, а еще не так давно я узнал, что их можно делать объектами и использовать как объекты.
А если их можно делать объектами, то можно их делать родовыми объектами! И тогда обычный сценарий использования можно настраивать и изменять прямо когда пользователь его использует. Программист может менять поведение своей программы, практически не меняя код, а пользователь каждый раз будет работать по-разному. Как страшно жить!
Дорогой дневник, я вот задумался, я будут ли такие юз кейсы юз кейсами или они уже что-то большее?
Дорогоуважаемые программисты! Пожалуйста бережно обращайтесь со своими юз кейсами!
До скорых встреч!
Сегодня я расскажу тебе о юз кейсах. Это такие штуки, которые говорят, как можно и нужно использовать что-нибудь. Их можно рисовать и читать, а еще не так давно я узнал, что их можно делать объектами и использовать как объекты.
А если их можно делать объектами, то можно их делать родовыми объектами! И тогда обычный сценарий использования можно настраивать и изменять прямо когда пользователь его использует. Программист может менять поведение своей программы, практически не меняя код, а пользователь каждый раз будет работать по-разному. Как страшно жить!
Дорогой дневник, я вот задумался, я будут ли такие юз кейсы юз кейсами или они уже что-то большее?
Дорогоуважаемые программисты! Пожалуйста бережно обращайтесь со своими юз кейсами!
До скорых встреч!
среда, 13 августа 2008 г.
Перечислимые типы и поля
Дорогой блог!
Сегодня я расскажу тебе о том, как получить сразу все поля перечислимого типа. Чтобы не путать тебя, дневник, я сразу расскажу, какой перечислимый тип у нас будет:
public enum MyEnum
{
Field,
AnotherField,
OneMore
}
Когда я был совсем маленьким и неумным я делал так:
public MyEnum[] GetMyEnumValues()
{
return new MyEnum[] {
MyEnum.Field,
MyEnum.AnotherField,
MyEnum.OneMore
};
}
Но если я или другой программист когда-нибудь добавит поле в перечислимый тип, или наоборот уберет его, или просто изменит его название, все сломается. Поэтому так делать плохо и так делают только плохие программисты. А хорошие программисты всегда делают так:
public IList<MyEnum> MyEnumFields
{
get
{
IList<MyEnum> result = new IList<MyEnum>();
MyEnum values = MyEnum.Field;
foreach(FieldInfo field in typeof(MyEnum).GetFields())
if (field.FieldType.Equals(typeof(MyEnum)))
result.Add((MyEnum)field.GetValue(value));
return result;
}
}
Дорогоуважаемые программисты! Пожалуйста будьте только хорошими и не расстраивайте своих коллег, и аналитиков, и менеджеров. Обращайтесь с типами правильно и изучайте типы.
До скорых встреч!
Сегодня я расскажу тебе о том, как получить сразу все поля перечислимого типа. Чтобы не путать тебя, дневник, я сразу расскажу, какой перечислимый тип у нас будет:
public enum MyEnum
{
Field,
AnotherField,
OneMore
}
Когда я был совсем маленьким и неумным я делал так:
public MyEnum[] GetMyEnumValues()
{
return new MyEnum[] {
MyEnum.Field,
MyEnum.AnotherField,
MyEnum.OneMore
};
}
Но если я или другой программист когда-нибудь добавит поле в перечислимый тип, или наоборот уберет его, или просто изменит его название, все сломается. Поэтому так делать плохо и так делают только плохие программисты. А хорошие программисты всегда делают так:
public IList<MyEnum> MyEnumFields
{
get
{
IList<MyEnum> result = new IList<MyEnum>();
MyEnum values = MyEnum.Field;
foreach(FieldInfo field in typeof(MyEnum).GetFields())
if (field.FieldType.Equals(typeof(MyEnum)))
result.Add((MyEnum)field.GetValue(value));
return result;
}
}
Дорогоуважаемые программисты! Пожалуйста будьте только хорошими и не расстраивайте своих коллег, и аналитиков, и менеджеров. Обращайтесь с типами правильно и изучайте типы.
До скорых встреч!
понедельник, 11 августа 2008 г.
Сервисы
Дорогой блог!
Сегодня я расскажу тебе о службах. Служба -- это такая специальная программа, у которой нет окошка и она работает сама по себе. Еще службы называются Windows Services.
В C#, на котором я пишу программы и сервисы, можно управлять сервисами из других программ. Микрософт говорит, что для этого есть хороший класс ServiceController. Он позволяет запускать службы и останавливать их, а еще отправлять им всякие команды. Для этого есть метод ExecuteCommand, в который можно передать код команды. И сервис должен уметь обрабатывать такие команды, для этого надо написать в нем метод OnCustomCommand. Вот, и все это вместе хорошо и красиво работает.
Дорогоуважаемые программисты! Когда вы будете писать свои сервисы, не забудьте, про все эти замечательные методы и про то, что они требуют разных разрешений. А еще не забудьте, что параметрами метода ExecuteCommand могут быть только целые числа от 128 до 256. А если вы вдруг об этом забудете, то добрый .Net напомнит вам об этом с помощью InvalidOperationException и еще скажет примерно вот так: "Невозможно управлять <...> службой на компьютере '<...>'.".
До скорых встреч!
Сегодня я расскажу тебе о службах. Служба -- это такая специальная программа, у которой нет окошка и она работает сама по себе. Еще службы называются Windows Services.
В C#, на котором я пишу программы и сервисы, можно управлять сервисами из других программ. Микрософт говорит, что для этого есть хороший класс ServiceController. Он позволяет запускать службы и останавливать их, а еще отправлять им всякие команды. Для этого есть метод ExecuteCommand, в который можно передать код команды. И сервис должен уметь обрабатывать такие команды, для этого надо написать в нем метод OnCustomCommand. Вот, и все это вместе хорошо и красиво работает.
Дорогоуважаемые программисты! Когда вы будете писать свои сервисы, не забудьте, про все эти замечательные методы и про то, что они требуют разных разрешений. А еще не забудьте, что параметрами метода ExecuteCommand могут быть только целые числа от 128 до 256. А если вы вдруг об этом забудете, то добрый .Net напомнит вам об этом с помощью InvalidOperationException и еще скажет примерно вот так: "Невозможно управлять <...> службой на компьютере '<...>'.".
До скорых встреч!
вторник, 29 июля 2008 г.
Темп и поток
Дорогой блог!
Прости, что я давно не писал тебя. Это все потому что вещи вокруг меня происходят очень быстро. Сегодня, дорогой дневник, я расскажу тебе про поток.
Мой менеджер знает, что я и другие программисты работают по сорок часов в неделю. Мы честно приходим к 10.00 и уходим не раньше 19.00, а обедаем не больше часа в день. Мы хорошие программисты и не обманываем менеджера.
Но есть разные люди, они не плохие, дневник, но отвлекают нас и мешают нам работать восемь часов. Эти люди отвлекают нас по-разному: они звонят нам по телефону, говорят с нами или не с нами, но мы все равно слышим, или они говорят нам сделать что-то другое, потому что тоже наши менеджеры, или пишут нам в асю. Вот, они нас отвлекают и я и другие программисты не можем работать сорок часов в неделю с десяти до семи. Мне очень грустно, дорогой блог, потому что я хочу приносить пользу и быть хорошим, а мне не дают этого делать.
А еще я заметил вот какую штуку. Утром я могу делать много разных вещей. Я могу писать программы, писать тесты, исправлять ошибки, учиться новым интересным предметам и быстро отвечать на вопросы. Вот сколько всего я могу, и даже еще больше. А вечером я обычно могу только писать тесты и программы, но и то не всегда.
Умные дяденьки, одного из которых зовут Денис Зарин, когда-то рассказывали мне, что есть такая штука поток, только они называли его флоу, наверно по-английски.
Поток -- это когда программист заниматеся только чем-нибудь одним и ни на что не отвлекается. А если у программиста звонит телефон или с ним начинает говорить другой программист или менеджер или аналитик, он выходит из потока. Наверно это как будто программист ныряет в речку или море и смотрит на красивых рыбок и кораллы. Если программист нырнул глубоко, он может много чего увидеть и работает очень быстро и хорошо, а если не нырнул, то ничего не увидит и будет плохо работать.
Вот, и я теперь знаю, что утром нырять в поток у программистов получается лучше, чем вечером, и что програмиста очень легко выдернуть из потока.
Дорогоуважаемые программисты! Помните про свой поток и будьте всегда в нем. Я желаю вам, чтобы вы одинаково глубоко ныряли утром, днем и вечером и чтобы вас оттуда не выдергивали, когда вам этого не нужно и не хочется.
До скорых встреч!
PS Дорогой дневник, мне еще кажется, что поток бывает не только в программировании, а еще в самой жизни. И еще мне кажется, что я сейчас очень сильно в него нырнул.
Прости, что я давно не писал тебя. Это все потому что вещи вокруг меня происходят очень быстро. Сегодня, дорогой дневник, я расскажу тебе про поток.
Мой менеджер знает, что я и другие программисты работают по сорок часов в неделю. Мы честно приходим к 10.00 и уходим не раньше 19.00, а обедаем не больше часа в день. Мы хорошие программисты и не обманываем менеджера.
Но есть разные люди, они не плохие, дневник, но отвлекают нас и мешают нам работать восемь часов. Эти люди отвлекают нас по-разному: они звонят нам по телефону, говорят с нами или не с нами, но мы все равно слышим, или они говорят нам сделать что-то другое, потому что тоже наши менеджеры, или пишут нам в асю. Вот, они нас отвлекают и я и другие программисты не можем работать сорок часов в неделю с десяти до семи. Мне очень грустно, дорогой блог, потому что я хочу приносить пользу и быть хорошим, а мне не дают этого делать.
А еще я заметил вот какую штуку. Утром я могу делать много разных вещей. Я могу писать программы, писать тесты, исправлять ошибки, учиться новым интересным предметам и быстро отвечать на вопросы. Вот сколько всего я могу, и даже еще больше. А вечером я обычно могу только писать тесты и программы, но и то не всегда.
Умные дяденьки, одного из которых зовут Денис Зарин, когда-то рассказывали мне, что есть такая штука поток, только они называли его флоу, наверно по-английски.
Поток -- это когда программист заниматеся только чем-нибудь одним и ни на что не отвлекается. А если у программиста звонит телефон или с ним начинает говорить другой программист или менеджер или аналитик, он выходит из потока. Наверно это как будто программист ныряет в речку или море и смотрит на красивых рыбок и кораллы. Если программист нырнул глубоко, он может много чего увидеть и работает очень быстро и хорошо, а если не нырнул, то ничего не увидит и будет плохо работать.
Вот, и я теперь знаю, что утром нырять в поток у программистов получается лучше, чем вечером, и что програмиста очень легко выдернуть из потока.
Дорогоуважаемые программисты! Помните про свой поток и будьте всегда в нем. Я желаю вам, чтобы вы одинаково глубоко ныряли утром, днем и вечером и чтобы вас оттуда не выдергивали, когда вам этого не нужно и не хочется.
До скорых встреч!
PS Дорогой дневник, мне еще кажется, что поток бывает не только в программировании, а еще в самой жизни. И еще мне кажется, что я сейчас очень сильно в него нырнул.
Подписаться на:
Сообщения (Atom)