Дорогой блог!
Сегодня я расскажу тебе об одних письмах, которые называются MSMQ. Это такие специальные письма, их придумала вторая лучшая компания в мире, которые обязательно доходят до адресата или возвращаются обратно.
Я очень люблю писать и посылать разным людям письма: другим программистам, и аналитикам, и архитектору, и менеджеру, и субподрядчикам, и друзьям, и девушкам, и даже незнакомым людям. Субподрядчик, я тебе уже о нем рассказывал, дневник, и архитектор специально придумали так, чтобы наша программа и их программа посылали друг другу письма MSMQ. Я так рад этому решению! Больше всего я люблю спрашивать что-нибудь в письмах, и я научил нашу программу спрашивать другую программу про то, какие картинки у нее есть. А субподрядчик научил свою программу отвечать на мои письма и посылать в ответ картинки. Это так здорово!!! А недавно я узнал, что я могу получить только две или три картинки, а большие письма мне не приходят. Я очень расстроился, и менеджер расстроился, и даже начальник всего нашего отдела расстроился, потому что они тоже любят писать письма и смотреть картинки.
Тогда я и субподрядчик узнали, что письма MSMQ не могут быть очень большими, а только не больше 2 Мб. А еще мы узнали, что если у почтового ящика MSMQ поставить размер 100 Мб, то нельзя получить ни одного письма, потому что MSMQ тоже любит писать письма, но только уже сам себе.
Дорогоуважаемые программисты! Если вы тоже любите писать письма, обязательно пользуйтесь Почтой России, потому что там работает добрый почтальон Печкин, и проверяйте их размер. А если вы так много написали, что все не влезает в конверт, отправляйте бандероли и контейнерные перевозки.
До скорых встреч!
понедельник, 15 декабря 2008 г.
среда, 3 декабря 2008 г.
Дорогой блог!
Сегодня я снова хочу расказать тебе о стиле, а точнее об именовании всего-всего.
Как ты наверно знаешь, все-все вещи в компьютере можно назвать. Можно назвать файлы, документы, папки, пользователей, а еще переменные, классы, интерфейсы, сервисы, базы данных и даже серверы! Раньше я называл их по-разному: файлы, документы и папки мог назвать русскими буквами или английскими, а переменные и другие вещи - только английскими. Обычно у меня получалось называть их, например, так: MessagingService или IRibbonItemsFactory. Но один добрый человек сказал мне, что это неправильно, и научил называть все одинаково и правильно, например, так: SLUGBA_SOOBSHENIY или I_RIBBON_KNOPKA_FACTORY. Теперь я, и другие программисты, и архитектор, и даже аналитики и менеджер все будем называть правильно и хорошо. Какое счастье!
Дорогоуважаемые программисты! Пожалуйста называйте все-все-все только правильно и красиво.
До скорых встреч!
Сегодня я снова хочу расказать тебе о стиле, а точнее об именовании всего-всего.
Как ты наверно знаешь, все-все вещи в компьютере можно назвать. Можно назвать файлы, документы, папки, пользователей, а еще переменные, классы, интерфейсы, сервисы, базы данных и даже серверы! Раньше я называл их по-разному: файлы, документы и папки мог назвать русскими буквами или английскими, а переменные и другие вещи - только английскими. Обычно у меня получалось называть их, например, так: MessagingService или IRibbonItemsFactory. Но один добрый человек сказал мне, что это неправильно, и научил называть все одинаково и правильно, например, так: SLUGBA_SOOBSHENIY или I_RIBBON_KNOPKA_FACTORY. Теперь я, и другие программисты, и архитектор, и даже аналитики и менеджер все будем называть правильно и хорошо. Какое счастье!
Дорогоуважаемые программисты! Пожалуйста называйте все-все-все только правильно и красиво.
До скорых встреч!
пятница, 14 ноября 2008 г.
История про субподрядчика
Дорогой блог!
Сегодня я расскажу тебе об одном субподрядчике. Субподрядчики -- это такие специальные люди, которым можно поручить порученную нам работу и заплатить за это заплаченные нам деньги. Дорогой блог, не перепутай субподрядчиков с аутсосрсерами! Субподрядчик всегда показывает свою программу заказчику сам, а аутсорсер показывает ее нам, а мы потом ее показываем заказчику.
Вот, а сегодня я ездил к заказчику, чтобы с одним субподрядчиком протестировать, как их программа взаимодействует с нашей программой. Дорогой блог, ты уже знаешь, что мы -- хорошие программисты, поэтому наша программа заработала хорошо. А программа субподрядчика не заработала, но у него был с собой исходный код, и поэтому мы стали смотреть в него. Когда мы посмотрели туда, мне стало очень грустно, потому что я увидел, что субподрядчик все сделал не очень правильно и плохо тестировал свой код, поэтому ничего не заметил. Мне кажется, что субподрядчик -- не плохой программист, просто у него нет такого замечательного менеджера, и архитектора, и других программистов и аналитиков, как у меня, поэтому его программа так плохо работала.
Дорогоуважаемые программисты! Всегда проверяйте своих субподрядчиков, потому что хотя они и сами показывают свои программы заказчику, все равно виноваты оказываются все. А если вы вдруг увидите, что у субподрядчика есть хорошие программисты, архитекторы, менеджеры и аналитики, обязательно зовите их к себе, чтобы они и вас научили быть хорошим. А если у субподрядчика плохие программисты, и архитекторы, и менеджеры, и даже аналитики, не зовите их к себе, а поскорее тестируйте их программы и говорите им об ошибках.
До скорых встреч!
Сегодня я расскажу тебе об одном субподрядчике. Субподрядчики -- это такие специальные люди, которым можно поручить порученную нам работу и заплатить за это заплаченные нам деньги. Дорогой блог, не перепутай субподрядчиков с аутсосрсерами! Субподрядчик всегда показывает свою программу заказчику сам, а аутсорсер показывает ее нам, а мы потом ее показываем заказчику.
Вот, а сегодня я ездил к заказчику, чтобы с одним субподрядчиком протестировать, как их программа взаимодействует с нашей программой. Дорогой блог, ты уже знаешь, что мы -- хорошие программисты, поэтому наша программа заработала хорошо. А программа субподрядчика не заработала, но у него был с собой исходный код, и поэтому мы стали смотреть в него. Когда мы посмотрели туда, мне стало очень грустно, потому что я увидел, что субподрядчик все сделал не очень правильно и плохо тестировал свой код, поэтому ничего не заметил. Мне кажется, что субподрядчик -- не плохой программист, просто у него нет такого замечательного менеджера, и архитектора, и других программистов и аналитиков, как у меня, поэтому его программа так плохо работала.
Дорогоуважаемые программисты! Всегда проверяйте своих субподрядчиков, потому что хотя они и сами показывают свои программы заказчику, все равно виноваты оказываются все. А если вы вдруг увидите, что у субподрядчика есть хорошие программисты, архитекторы, менеджеры и аналитики, обязательно зовите их к себе, чтобы они и вас научили быть хорошим. А если у субподрядчика плохие программисты, и архитекторы, и менеджеры, и даже аналитики, не зовите их к себе, а поскорее тестируйте их программы и говорите им об ошибках.
До скорых встреч!
воскресенье, 19 октября 2008 г.
Дорогой блог!
Сегодня я расскажу тебе о том, как я провел выходные. Выходные -- это такое время, когда я, который работает планктоном, и другие программисты, они тоже планктон, и архитектор, и аналитики, которые уже наверно не планктон, и даже менеджер, который совсем не планктон, вот, когда все мы можем не ходить на работу, а сидеть дома и веселиться с друзьями, и смотреть кино, и еще пить пиво и чай.
А в эти выходные я не стал так делать, а пошел на работу, чтобы провести еще один день в лучшей компании мира и сделать много полезного и нужного. И другие программисты тоже пришли на работу, чтобы тоже делать полезные штуки. А еще мы все пришли на работу, потому что не успели сделать много штук в рабочие дни, хотя мы очень старались.
Дорогоуважаемые программисты! Я искренне желаю вам успевать делать все, что вас просят делать менеджеры и аналитики, а еще архитекторы. Я желаю вам все успевать, даже когда вас просят за одну неделю сделать столько, сколько вы делаете обычно за две недели. Будьте хорошими программистами и планктоном!
До скорых встреч!
Сегодня я расскажу тебе о том, как я провел выходные. Выходные -- это такое время, когда я, который работает планктоном, и другие программисты, они тоже планктон, и архитектор, и аналитики, которые уже наверно не планктон, и даже менеджер, который совсем не планктон, вот, когда все мы можем не ходить на работу, а сидеть дома и веселиться с друзьями, и смотреть кино, и еще пить пиво и чай.
А в эти выходные я не стал так делать, а пошел на работу, чтобы провести еще один день в лучшей компании мира и сделать много полезного и нужного. И другие программисты тоже пришли на работу, чтобы тоже делать полезные штуки. А еще мы все пришли на работу, потому что не успели сделать много штук в рабочие дни, хотя мы очень старались.
Дорогоуважаемые программисты! Я искренне желаю вам успевать делать все, что вас просят делать менеджеры и аналитики, а еще архитекторы. Я желаю вам все успевать, даже когда вас просят за одну неделю сделать столько, сколько вы делаете обычно за две недели. Будьте хорошими программистами и планктоном!
До скорых встреч!
среда, 15 октября 2008 г.
История о формате и мэппинге
Дорогой блог!
Сегодня я расскажу тебе про одного аналитика, но другого и не онолитега. Я расскажу тебе историю про этого аналитика, и архитектора, и менеджера, и программистов.
Однажды к менеджеру пришел заказчик и сказал, что ему очень нужна хорошая программа, чтобы работала хорошо и сразу в нескольких местах, а данные из нее и из других программ могли бы собираться в центре. Тогда менеджер пошел к архитектору, который в то время был еще только программистом, и сказал, что нужна такая программа. Архитектор тогда уже знал, что хочет быть архитектором и поэтому разработал специальный формат, по которому все данные передавались бы в центр. И еще архитектор сделал так, чтобы другие программы передавали только те данные, которые есть в центре. Архитектор назвал это мэппингом данных и был молодец.
А потом этот формат и мэппинг он отдал менеджеру, а он отдал аналитику, а аналитик передал их разработчикам других программ. И все стали думать, что все хорошо.
А потом менеджер сказал одному программисту, чтобы он сделал так, чтобы программа принимала данные в том формате и дал ему пример файла формата и мэппинг. Программист был хороший и все сделал, но увидел, что данные были не те, которые нужны, и сказал об этом архитектору, менеджеру и аналитику, а аналитик сказал, что все хорошо. А когда до сдачи программы оставалось полдня, аналитик сказал, что это мы должны делать мэппинг, а не другие программисты. А менеджер расстроился и сказал, что аналитик не прав. И архитектор расстроился, потому что его не поняли, и сказал, что аналитик не прав. А программист обрадовался, потому что ему надо было меньше работать, а другим программистам -- больше.
Дорогоуважаемые программисты! Будьте осторожны и помните, что аналитики иногда не очень хорошо и правильно понимают программистов, и архитекторов, и менеджеров. А еще аналитики иногда бывают очень уверены в своем мнении и тянут до последнего дня, а программистам приходится оставаться на работе, чтобы все сделать, чтобы менеджер был доволен.
До скорых встреч!
Сегодня я расскажу тебе про одного аналитика, но другого и не онолитега. Я расскажу тебе историю про этого аналитика, и архитектора, и менеджера, и программистов.
Однажды к менеджеру пришел заказчик и сказал, что ему очень нужна хорошая программа, чтобы работала хорошо и сразу в нескольких местах, а данные из нее и из других программ могли бы собираться в центре. Тогда менеджер пошел к архитектору, который в то время был еще только программистом, и сказал, что нужна такая программа. Архитектор тогда уже знал, что хочет быть архитектором и поэтому разработал специальный формат, по которому все данные передавались бы в центр. И еще архитектор сделал так, чтобы другие программы передавали только те данные, которые есть в центре. Архитектор назвал это мэппингом данных и был молодец.
А потом этот формат и мэппинг он отдал менеджеру, а он отдал аналитику, а аналитик передал их разработчикам других программ. И все стали думать, что все хорошо.
А потом менеджер сказал одному программисту, чтобы он сделал так, чтобы программа принимала данные в том формате и дал ему пример файла формата и мэппинг. Программист был хороший и все сделал, но увидел, что данные были не те, которые нужны, и сказал об этом архитектору, менеджеру и аналитику, а аналитик сказал, что все хорошо. А когда до сдачи программы оставалось полдня, аналитик сказал, что это мы должны делать мэппинг, а не другие программисты. А менеджер расстроился и сказал, что аналитик не прав. И архитектор расстроился, потому что его не поняли, и сказал, что аналитик не прав. А программист обрадовался, потому что ему надо было меньше работать, а другим программистам -- больше.
Дорогоуважаемые программисты! Будьте осторожны и помните, что аналитики иногда не очень хорошо и правильно понимают программистов, и архитекторов, и менеджеров. А еще аналитики иногда бывают очень уверены в своем мнении и тянут до последнего дня, а программистам приходится оставаться на работе, чтобы все сделать, чтобы менеджер был доволен.
До скорых встреч!
пятница, 3 октября 2008 г.
SQL и XML
Дорогой блог!
Сегодня я расскажу тебе о том, как переводить данные из SQL Server 2005 сразу в XML.
Для этого в сервере придумали оператор SELECT FOR XML. Он умеет делать из табличек сразу XML, и программистам больше не надо писать много кода C# или VB или других языках, делать датасеты и обрабатывать их.
Я расскажу сегодня о режиме EXPLICIT, потому что он самый интересный и позволяет делать вообще любой XML. Только для этого надо писать много-много селектов и первыми двумя параметрами в них всегда должны стоять целые числа: сначала тэг, а потом родительский тэг. А еще родительский тэг может быть нуллом, тогда этот тэг будет без родителя. Например вот так:
SELECT
1 AS Tag
, NULL AS PARENT
, 'xml text' AS [TestRoot!1!value]
FOR XML EXPLICIT
И этот запрос выдает такой XML:
<TestRoot value="xml text" />
А если нужно тэги вкладывать друг в друга, то приходится писать много селектов и делать им всем юнион, а иерархия тэгов выстраивается полями Tag и Parent. Например можно сделать вот так:
SELECT
1 AS Tag
, NULL AS Parent
, 'xml text' AS [TestRoot!1!value]
, NULL AS [TestChild!2!Name]
, NULL AS [TestChild!2!Code]
UNION
SELECT
2 AS Tag
, 1 AS Parent
, NULL
, 'child text'
, 111
FOR XML EXPLICIT
Вот, тогда мы получим такой XML:
<TestRoot value="xml text" >
<TestChild Name="child text" Code="111" />
</TestRoot>
Дорогой блог, ты наверное уже заметил, что я в первом запросе пишу длинные и неудобные имена столбцов. На самом это я просто говорю, какие имена тэгов и атрибутов надо подставлять в XML: [имя тэга!номер тэга!имя атрибута]. А еще в конце имени столбца можно поставить еще один восклицательый знак и написать еще какую-нибудь опцию вроде HIDE (она нужна, чтобы столбец не отображался в XML, а только был в таблице).
Дорогоуважаемые программисты! Мне очень нравится выгружать мои данные сразу в XML, потому что я использую этот механизм для выгрузки больших объемов в смежную систему. А еще мне очень нравится, что имена столбцов получаются такими эмоциональными и радостными -- столько восклицательных знаков! Немного жаль только, что нельзя ставить еще и вопросительные, но это ничего, я уверен, что в SQL Server 2015 будут и они и еще много других приятных штук :)
До скорых встреч!
Сегодня я расскажу тебе о том, как переводить данные из SQL Server 2005 сразу в XML.
Для этого в сервере придумали оператор SELECT FOR XML. Он умеет делать из табличек сразу XML, и программистам больше не надо писать много кода C# или VB или других языках, делать датасеты и обрабатывать их.
Я расскажу сегодня о режиме EXPLICIT, потому что он самый интересный и позволяет делать вообще любой XML. Только для этого надо писать много-много селектов и первыми двумя параметрами в них всегда должны стоять целые числа: сначала тэг, а потом родительский тэг. А еще родительский тэг может быть нуллом, тогда этот тэг будет без родителя. Например вот так:
SELECT
1 AS Tag
, NULL AS PARENT
, 'xml text' AS [TestRoot!1!value]
FOR XML EXPLICIT
И этот запрос выдает такой XML:
<TestRoot value="xml text" />
А если нужно тэги вкладывать друг в друга, то приходится писать много селектов и делать им всем юнион, а иерархия тэгов выстраивается полями Tag и Parent. Например можно сделать вот так:
SELECT
1 AS Tag
, NULL AS Parent
, 'xml text' AS [TestRoot!1!value]
, NULL AS [TestChild!2!Name]
, NULL AS [TestChild!2!Code]
UNION
SELECT
2 AS Tag
, 1 AS Parent
, NULL
, 'child text'
, 111
FOR XML EXPLICIT
Вот, тогда мы получим такой XML:
<TestRoot value="xml text" >
<TestChild Name="child text" Code="111" />
</TestRoot>
Дорогой блог, ты наверное уже заметил, что я в первом запросе пишу длинные и неудобные имена столбцов. На самом это я просто говорю, какие имена тэгов и атрибутов надо подставлять в XML: [имя тэга!номер тэга!имя атрибута]. А еще в конце имени столбца можно поставить еще один восклицательый знак и написать еще какую-нибудь опцию вроде HIDE (она нужна, чтобы столбец не отображался в XML, а только был в таблице).
Дорогоуважаемые программисты! Мне очень нравится выгружать мои данные сразу в XML, потому что я использую этот механизм для выгрузки больших объемов в смежную систему. А еще мне очень нравится, что имена столбцов получаются такими эмоциональными и радостными -- столько восклицательных знаков! Немного жаль только, что нельзя ставить еще и вопросительные, но это ничего, я уверен, что в SQL Server 2015 будут и они и еще много других приятных штук :)
До скорых встреч!
среда, 10 сентября 2008 г.
Ленточки
Дорогой блог!
Сегодня я расскажу тебе о лентах и контекстных вкладках. Лента -- это такая новая панель инструментов, которую придумал Майкрософт и стал использовать в Office 2007. В ней есть категории, вкладки, на вкладках есть группы, в группах есть кнопки и другие штуки и группы кнопок, в которых тоже есть кнопки и другие штуки. Вот, и все это позволяет пользователю легко, и красиво, и свободно делать все, что ему надо. А еще в ленте можно сделать одну большую кнопку с главным меню программы и вставить много-много всяких кнопочек и других шиук в панель быстрого запуска. Лента -- это очень хороший контрол, в который можно поместить все, что надо, только она занимает немножко много места, зато она может быть одна на всю программу.
Вот, а еще в ленту можно прямо во время работы программы вставлять все, что угодно: и вкладки, и группы, и кнопки и все остальное. Например, если пользователь работает со списком входящих сообщений и документов, можно показать вкладку для этого списка, а если он работает с запросами, можно показать ему вкладку для запросов. А сделать это просто :)
1. Надо сначала создать категорию вкладок и наполнить ее вкладками или создать вкладку, но мне больше нравится делать с категориями:
RibbonPageCategory category
= new RibbonPageCategory(categoryName, categoryColor, false);
RibbonPage page = new RibbonPage(pageName);
FillRibbonPage(page);
category.Pages.Add(page);
2. Надо наполнить вкладки группами, кнопками и всем остальным:
public void FillRibbonPage(RibbonPage page)
{
RibbonPageGroup groupBrowse = new RibbonPageGroup("Просмотр");
BarButtonItem btnBrowse = new BarButtonItem();
btnBrowse.Caption = "Просмотр";
btnBrowse.LargeGlyph = Resources.box_view;
btnBrowse.LargeWidth = 85;
btnBrowse.Name = "btnBrowse";
btnBrowse.RibbonStyle = RibbonItemStyles.Large;
btnBrowse.ItemClick += new ItemClickEventHandler(btnBrowse_ItemClick);
groupBrowse.ItemLinks.Add(btnBrowse);
page.Groups.Add(groupBrowse);
}
3. А потом надо управлять видимостью категории или вкладки:
private void OnSmartPartActivated(object sender, WorkspaceEventArgs e)
{
category.Visible = (e.SmartPart is MySmartPart);
}
private void OnSmartPartClosing(object sender, WorkspaceCancelEventArgs e)
{
if (e.SmartPart is MySmartPart)
category.Visible = false;
}
Дорогоуважаемые программисты! Используйте ленты и прочие инструменты на здоровье! У меня ленты от DevExpress.
До скорых встреч!
Сегодня я расскажу тебе о лентах и контекстных вкладках. Лента -- это такая новая панель инструментов, которую придумал Майкрософт и стал использовать в Office 2007. В ней есть категории, вкладки, на вкладках есть группы, в группах есть кнопки и другие штуки и группы кнопок, в которых тоже есть кнопки и другие штуки. Вот, и все это позволяет пользователю легко, и красиво, и свободно делать все, что ему надо. А еще в ленте можно сделать одну большую кнопку с главным меню программы и вставить много-много всяких кнопочек и других шиук в панель быстрого запуска. Лента -- это очень хороший контрол, в который можно поместить все, что надо, только она занимает немножко много места, зато она может быть одна на всю программу.
Вот, а еще в ленту можно прямо во время работы программы вставлять все, что угодно: и вкладки, и группы, и кнопки и все остальное. Например, если пользователь работает со списком входящих сообщений и документов, можно показать вкладку для этого списка, а если он работает с запросами, можно показать ему вкладку для запросов. А сделать это просто :)
1. Надо сначала создать категорию вкладок и наполнить ее вкладками или создать вкладку, но мне больше нравится делать с категориями:
RibbonPageCategory category
= new RibbonPageCategory(categoryName, categoryColor, false);
RibbonPage page = new RibbonPage(pageName);
FillRibbonPage(page);
category.Pages.Add(page);
2. Надо наполнить вкладки группами, кнопками и всем остальным:
public void FillRibbonPage(RibbonPage page)
{
RibbonPageGroup groupBrowse = new RibbonPageGroup("Просмотр");
BarButtonItem btnBrowse = new BarButtonItem();
btnBrowse.Caption = "Просмотр";
btnBrowse.LargeGlyph = Resources.box_view;
btnBrowse.LargeWidth = 85;
btnBrowse.Name = "btnBrowse";
btnBrowse.RibbonStyle = RibbonItemStyles.Large;
btnBrowse.ItemClick += new ItemClickEventHandler(btnBrowse_ItemClick);
groupBrowse.ItemLinks.Add(btnBrowse);
page.Groups.Add(groupBrowse);
}
3. А потом надо управлять видимостью категории или вкладки:
private void OnSmartPartActivated(object sender, WorkspaceEventArgs e)
{
category.Visible = (e.SmartPart is MySmartPart);
}
private void OnSmartPartClosing(object sender, WorkspaceCancelEventArgs e)
{
if (e.SmartPart is MySmartPart)
category.Visible = false;
}
Дорогоуважаемые программисты! Используйте ленты и прочие инструменты на здоровье! У меня ленты от DevExpress.
До скорых встреч!
среда, 3 сентября 2008 г.
Общение
Дорогой блог!
Сегодня я хочу рассказать тебе о коммуникации. Ты уже знаешь, что обычно программы делают сразу несколько программистов, а еще аналитики, архитектор и менеджер, а иногда их тоже много. Когда все эти люди общаются между собой, это называется коммуникацией.
В хороших командах каждый человек знает, что он должен делать и с кем говорить, чтобы узнать что-то, или наоборот, рассказать о своих результатах. А еще в хороших командах все знают, кто чем занимается, и могут друг друга подменить. Вот, а еще коммуникация делает так, что кто-то или даже все обладают видением проекта в целом. А видение -- это очень хорошо, потому что с его помощью можно ставить цели и идти к ним.
Чтобы была коммуникация, есть много вяких вещей, например, методологий, о них я тебе расскажу как-нибудь в другой раз. В гибких методологиях предлагают собираться каждый день всей командой или только несколькоим людям и делиться своими проблемами и задачами. Так делают в ХР, и SCRUM, и других гибких методологиях. И это здорово, потому что опытные програмимсты могут помочь неопытным, а архитектор -- рассказать о каком-то куске системы, а аналитик -- о новых требованиях, а тестировщик -- о новых проблемах или еще о чем-нибудь. А менеджер может всех похвалить за то, что они не бездельничают, а проводят собрания и работают :)
Дорогоуважаемые программисты! Не забывайте о коммуникации и рассказывайте своим товарищам о том, что вы делаете. И все время спрашивайте, что они делают, потому что когда они заболеют или уйдут в отпуск, вам придется делать то, что делают они.
Дорогоуважаемые менеджеры! Не мешайте программистам общаться, потому что это хорошо и полезно. Иногда пятнадцать минут общения каждым утром сберегают недели разработки.
До скорых встреч!
Сегодня я хочу рассказать тебе о коммуникации. Ты уже знаешь, что обычно программы делают сразу несколько программистов, а еще аналитики, архитектор и менеджер, а иногда их тоже много. Когда все эти люди общаются между собой, это называется коммуникацией.
В хороших командах каждый человек знает, что он должен делать и с кем говорить, чтобы узнать что-то, или наоборот, рассказать о своих результатах. А еще в хороших командах все знают, кто чем занимается, и могут друг друга подменить. Вот, а еще коммуникация делает так, что кто-то или даже все обладают видением проекта в целом. А видение -- это очень хорошо, потому что с его помощью можно ставить цели и идти к ним.
Чтобы была коммуникация, есть много вяких вещей, например, методологий, о них я тебе расскажу как-нибудь в другой раз. В гибких методологиях предлагают собираться каждый день всей командой или только несколькоим людям и делиться своими проблемами и задачами. Так делают в ХР, и SCRUM, и других гибких методологиях. И это здорово, потому что опытные програмимсты могут помочь неопытным, а архитектор -- рассказать о каком-то куске системы, а аналитик -- о новых требованиях, а тестировщик -- о новых проблемах или еще о чем-нибудь. А менеджер может всех похвалить за то, что они не бездельничают, а проводят собрания и работают :)
Дорогоуважаемые программисты! Не забывайте о коммуникации и рассказывайте своим товарищам о том, что вы делаете. И все время спрашивайте, что они делают, потому что когда они заболеют или уйдут в отпуск, вам придется делать то, что делают они.
Дорогоуважаемые менеджеры! Не мешайте программистам общаться, потому что это хорошо и полезно. Иногда пятнадцать минут общения каждым утром сберегают недели разработки.
До скорых встреч!
вторник, 2 сентября 2008 г.
Аттестация
Дорогой блог!
Хочу поделиться с тобой радостной новостью: сегодня я наконец-то стал белым человеком, потому что у меня закончился испытательный срок! Это значит, что теперь я буду, как и другие программисты, и архитектор, и менеджер и аналитики проходить ежегодную аттестацию, смогу ездить на обучение за счет компании и даже вносить предложения по улучшению всего.
Дорогоуважаемые программисты! Проходите аттестации почаще, становитесь белыми людьми в компаниях!
До скорых встреч!
Хочу поделиться с тобой радостной новостью: сегодня я наконец-то стал белым человеком, потому что у меня закончился испытательный срок! Это значит, что теперь я буду, как и другие программисты, и архитектор, и менеджер и аналитики проходить ежегодную аттестацию, смогу ездить на обучение за счет компании и даже вносить предложения по улучшению всего.
Дорогоуважаемые программисты! Проходите аттестации почаще, становитесь белыми людьми в компаниях!
До скорых встреч!
вторник, 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 и еще скажет примерно вот так: "Невозможно управлять <...> службой на компьютере '<...>'.".
До скорых встреч!
понедельник, 4 августа 2008 г.
Дорогой блог!
Сегодня я расскажу тебе об одном человеке, он онолитег. Не подумай пожалуйста, что я ошибся, нет-нет. Он сильно отличается от аналитиков, о которых я тебе уже рассказывал.
Во-первых, он отлично знает русский язык и всегда использует много разных слов: вот, как бы, ну, там, понимаешь и другие интересные слова. Я очень люблю слушать, как он говорит. Он сам не говорит, но мне кажется, что у него красный диплом школы Викторов Степанычей. Он скромный и поэтому хороший.
Во-вторых, наш онолитег хорошо знает все о программах, которые есть в его проектах. Иногда он даже лучше программистов и подсказывает им, что они неправильно делают, но никогда не говорит, как надо делать правильно, чтобы программистам было интересно.
Вот какой он хороший онолитег.
Дорогоуважаемые программисты! Если у вас тоже есть такие онолитеги, пожалуйста общайтесь с ними больше. А если у вас вдруг их нет, обязательно попросите своего менеджера нанять хотя бы одного. Общение с онолитегами -- одно удовольствие.
До скорых встреч!
Сегодня я расскажу тебе об одном человеке, он онолитег. Не подумай пожалуйста, что я ошибся, нет-нет. Он сильно отличается от аналитиков, о которых я тебе уже рассказывал.
Во-первых, он отлично знает русский язык и всегда использует много разных слов: вот, как бы, ну, там, понимаешь и другие интересные слова. Я очень люблю слушать, как он говорит. Он сам не говорит, но мне кажется, что у него красный диплом школы Викторов Степанычей. Он скромный и поэтому хороший.
Во-вторых, наш онолитег хорошо знает все о программах, которые есть в его проектах. Иногда он даже лучше программистов и подсказывает им, что они неправильно делают, но никогда не говорит, как надо делать правильно, чтобы программистам было интересно.
Вот какой он хороший онолитег.
Дорогоуважаемые программисты! Если у вас тоже есть такие онолитеги, пожалуйста общайтесь с ними больше. А если у вас вдруг их нет, обязательно попросите своего менеджера нанять хотя бы одного. Общение с онолитегами -- одно удовольствие.
До скорых встреч!
вторник, 29 июля 2008 г.
Темп и поток
Дорогой блог!
Прости, что я давно не писал тебя. Это все потому что вещи вокруг меня происходят очень быстро. Сегодня, дорогой дневник, я расскажу тебе про поток.
Мой менеджер знает, что я и другие программисты работают по сорок часов в неделю. Мы честно приходим к 10.00 и уходим не раньше 19.00, а обедаем не больше часа в день. Мы хорошие программисты и не обманываем менеджера.
Но есть разные люди, они не плохие, дневник, но отвлекают нас и мешают нам работать восемь часов. Эти люди отвлекают нас по-разному: они звонят нам по телефону, говорят с нами или не с нами, но мы все равно слышим, или они говорят нам сделать что-то другое, потому что тоже наши менеджеры, или пишут нам в асю. Вот, они нас отвлекают и я и другие программисты не можем работать сорок часов в неделю с десяти до семи. Мне очень грустно, дорогой блог, потому что я хочу приносить пользу и быть хорошим, а мне не дают этого делать.
А еще я заметил вот какую штуку. Утром я могу делать много разных вещей. Я могу писать программы, писать тесты, исправлять ошибки, учиться новым интересным предметам и быстро отвечать на вопросы. Вот сколько всего я могу, и даже еще больше. А вечером я обычно могу только писать тесты и программы, но и то не всегда.
Умные дяденьки, одного из которых зовут Денис Зарин, когда-то рассказывали мне, что есть такая штука поток, только они называли его флоу, наверно по-английски.
Поток -- это когда программист заниматеся только чем-нибудь одним и ни на что не отвлекается. А если у программиста звонит телефон или с ним начинает говорить другой программист или менеджер или аналитик, он выходит из потока. Наверно это как будто программист ныряет в речку или море и смотрит на красивых рыбок и кораллы. Если программист нырнул глубоко, он может много чего увидеть и работает очень быстро и хорошо, а если не нырнул, то ничего не увидит и будет плохо работать.
Вот, и я теперь знаю, что утром нырять в поток у программистов получается лучше, чем вечером, и что програмиста очень легко выдернуть из потока.
Дорогоуважаемые программисты! Помните про свой поток и будьте всегда в нем. Я желаю вам, чтобы вы одинаково глубоко ныряли утром, днем и вечером и чтобы вас оттуда не выдергивали, когда вам этого не нужно и не хочется.
До скорых встреч!
PS Дорогой дневник, мне еще кажется, что поток бывает не только в программировании, а еще в самой жизни. И еще мне кажется, что я сейчас очень сильно в него нырнул.
Прости, что я давно не писал тебя. Это все потому что вещи вокруг меня происходят очень быстро. Сегодня, дорогой дневник, я расскажу тебе про поток.
Мой менеджер знает, что я и другие программисты работают по сорок часов в неделю. Мы честно приходим к 10.00 и уходим не раньше 19.00, а обедаем не больше часа в день. Мы хорошие программисты и не обманываем менеджера.
Но есть разные люди, они не плохие, дневник, но отвлекают нас и мешают нам работать восемь часов. Эти люди отвлекают нас по-разному: они звонят нам по телефону, говорят с нами или не с нами, но мы все равно слышим, или они говорят нам сделать что-то другое, потому что тоже наши менеджеры, или пишут нам в асю. Вот, они нас отвлекают и я и другие программисты не можем работать сорок часов в неделю с десяти до семи. Мне очень грустно, дорогой блог, потому что я хочу приносить пользу и быть хорошим, а мне не дают этого делать.
А еще я заметил вот какую штуку. Утром я могу делать много разных вещей. Я могу писать программы, писать тесты, исправлять ошибки, учиться новым интересным предметам и быстро отвечать на вопросы. Вот сколько всего я могу, и даже еще больше. А вечером я обычно могу только писать тесты и программы, но и то не всегда.
Умные дяденьки, одного из которых зовут Денис Зарин, когда-то рассказывали мне, что есть такая штука поток, только они называли его флоу, наверно по-английски.
Поток -- это когда программист заниматеся только чем-нибудь одним и ни на что не отвлекается. А если у программиста звонит телефон или с ним начинает говорить другой программист или менеджер или аналитик, он выходит из потока. Наверно это как будто программист ныряет в речку или море и смотрит на красивых рыбок и кораллы. Если программист нырнул глубоко, он может много чего увидеть и работает очень быстро и хорошо, а если не нырнул, то ничего не увидит и будет плохо работать.
Вот, и я теперь знаю, что утром нырять в поток у программистов получается лучше, чем вечером, и что програмиста очень легко выдернуть из потока.
Дорогоуважаемые программисты! Помните про свой поток и будьте всегда в нем. Я желаю вам, чтобы вы одинаково глубоко ныряли утром, днем и вечером и чтобы вас оттуда не выдергивали, когда вам этого не нужно и не хочется.
До скорых встреч!
PS Дорогой дневник, мне еще кажется, что поток бывает не только в программировании, а еще в самой жизни. И еще мне кажется, что я сейчас очень сильно в него нырнул.
вторник, 22 июля 2008 г.
Дорогой блог!
Сегодня я расскажу тебе о проектах. Проект -- это такая штука, которой все занимаются на работе. Работы тоже бывают разные, и на одних работах все занимаются только одним проектом, а на других работах все занимаются разными проектами. А еще проекты можно вести, сдавать и срывать, но это грустно и я не буду писать об этом.
У меня на работе есть один проект, который понимал только один программист, но он давно уволился, а теперь я должен понимать, но не понимаю. Этим проектом никто не хочет заниматься, потому что он неинтересный и у всех есть другие дела.
А еще у меня на работе есть другой проект, который тоже непонятный и сложный. Но зато его делает один интересный человек, и еще там менеджером тоже интересный человек. И поэтому этот проект делать интересно.
А третий проект у меня на работе самый интересный, и его делают тоже интересные люди, и там интересный второй программист и третий программист и архитектор и менеджер. И я каждый день узнаю что-то новое, и мне нравится мой третий проект. А первый проект мне не нравится, потому что я не узнаю ничего нового, а только использую старые инструкции и руководства.
Дорогоуважаемые программисты! Я хочу вам пожелать, чтобы все проекты, которые вы работаете на работе, были интересными. И чтобы люди, которые вместе с вами работают эти проекты тоже были интересными.
Дорогоуважаемые менеджеры! Я от всей души желаю вам, чтобы вы спрашивали программистов, какие проекты им интересны, а какие совсем не интересны. И еще я желаю, чтобы все ваши проекты были интересными для всех программистов и аналитиков и архитекторов и других людей, которые в них работают.
До скорых встреч!
Сегодня я расскажу тебе о проектах. Проект -- это такая штука, которой все занимаются на работе. Работы тоже бывают разные, и на одних работах все занимаются только одним проектом, а на других работах все занимаются разными проектами. А еще проекты можно вести, сдавать и срывать, но это грустно и я не буду писать об этом.
У меня на работе есть один проект, который понимал только один программист, но он давно уволился, а теперь я должен понимать, но не понимаю. Этим проектом никто не хочет заниматься, потому что он неинтересный и у всех есть другие дела.
А еще у меня на работе есть другой проект, который тоже непонятный и сложный. Но зато его делает один интересный человек, и еще там менеджером тоже интересный человек. И поэтому этот проект делать интересно.
А третий проект у меня на работе самый интересный, и его делают тоже интересные люди, и там интересный второй программист и третий программист и архитектор и менеджер. И я каждый день узнаю что-то новое, и мне нравится мой третий проект. А первый проект мне не нравится, потому что я не узнаю ничего нового, а только использую старые инструкции и руководства.
Дорогоуважаемые программисты! Я хочу вам пожелать, чтобы все проекты, которые вы работаете на работе, были интересными. И чтобы люди, которые вместе с вами работают эти проекты тоже были интересными.
Дорогоуважаемые менеджеры! Я от всей души желаю вам, чтобы вы спрашивали программистов, какие проекты им интересны, а какие совсем не интересны. И еще я желаю, чтобы все ваши проекты были интересными для всех программистов и аналитиков и архитекторов и других людей, которые в них работают.
До скорых встреч!
четверг, 17 июля 2008 г.
Аналитики
Дорогой блог!
Сегодня я хочу поделиться с тобой мыслями об аналитиках.
Как однажды сказал Дмитрий Дзюба, аналитик -- это такое странное существо, которое бегает с выпученными глазами и говорит на непонятном языке.
У нас в отделе работает один аналитик. Дневник, не подумай пожалуйста, что он плохой. Он занимается тем, что по туманным и неясным требованиям заказчика составляет предельно ясные и понятные описания программ, которые надо будет написать.
А еще у нас есть архитектор, который тоже разбирается в туманных и неясных требованиях и по ним рисует красивые схемы с серверами, армами и параметрами соединений.
Сегодня аналитик мне сказал, что в одной очень серьезной организации, где будет работать моя программа, нужно сразу две версии программы: одну специальную для этой организации и еще одну для других организаций. Я ему поверил, потому что я послушный программист и хороший, и стал делать вторую программу. А еще я поговорил с архитектором, и он мне сказал, что эти две программы на самом деле одна программа, и я очень расстроился. А потом мне сказали, что я не должен был слушать аналитика. Дорогой дневник, как страшно становится жить! Теперь я больше не могу верить аналитику, а могу верить только архитектору и другим программистам. А вдруг они меня тоже хотят обмануть? Что же мне делать, дневничок?
Дорогоуважаемые программисты! Пожалуйста будьте внимательны и проверяйте слова аналитиков! Аналитики коварны и говорят на языке заказчика. А еще аналитики иногда не очень хорошо разбираются в требованиях и их работу приходится делать программистам и архитекторам. Удачи вам и хороших аналитиков.
До скорых встреч!
Сегодня я хочу поделиться с тобой мыслями об аналитиках.
Как однажды сказал Дмитрий Дзюба, аналитик -- это такое странное существо, которое бегает с выпученными глазами и говорит на непонятном языке.
У нас в отделе работает один аналитик. Дневник, не подумай пожалуйста, что он плохой. Он занимается тем, что по туманным и неясным требованиям заказчика составляет предельно ясные и понятные описания программ, которые надо будет написать.
А еще у нас есть архитектор, который тоже разбирается в туманных и неясных требованиях и по ним рисует красивые схемы с серверами, армами и параметрами соединений.
Сегодня аналитик мне сказал, что в одной очень серьезной организации, где будет работать моя программа, нужно сразу две версии программы: одну специальную для этой организации и еще одну для других организаций. Я ему поверил, потому что я послушный программист и хороший, и стал делать вторую программу. А еще я поговорил с архитектором, и он мне сказал, что эти две программы на самом деле одна программа, и я очень расстроился. А потом мне сказали, что я не должен был слушать аналитика. Дорогой дневник, как страшно становится жить! Теперь я больше не могу верить аналитику, а могу верить только архитектору и другим программистам. А вдруг они меня тоже хотят обмануть? Что же мне делать, дневничок?
Дорогоуважаемые программисты! Пожалуйста будьте внимательны и проверяйте слова аналитиков! Аналитики коварны и говорят на языке заказчика. А еще аналитики иногда не очень хорошо разбираются в требованиях и их работу приходится делать программистам и архитекторам. Удачи вам и хороших аналитиков.
До скорых встреч!
Дорогой блог!
Я очень рад, что завел тебя! Я верю, что ты станешь мне настоящим другом и поможешь мне глубже понять себя, приобрести новых друзей и еще больше сблизиться со старыми.
Я начинаю эту новую страничку в своей интернет-жизни, зная, что у меня уже есть друг -- ты, мой дневник.
А сейчас прости, мне пора дальше превращать свой мозг в активную биомассу на благо компании.
Я скоро вернусь, не скучай, дневник :)
Я начинаю эту новую страничку в своей интернет-жизни, зная, что у меня уже есть друг -- ты, мой дневник.
А сейчас прости, мне пора дальше превращать свой мозг в активную биомассу на благо компании.
Я скоро вернусь, не скучай, дневник :)
Подписаться на:
Сообщения (Atom)