Дорогой блог!
Сегодня я расскажу тебе про одного аналитика, но другого и не онолитега. Я расскажу тебе историю про этого аналитика, и архитектора, и менеджера, и программистов.
Однажды к менеджеру пришел заказчик и сказал, что ему очень нужна хорошая программа, чтобы работала хорошо и сразу в нескольких местах, а данные из нее и из других программ могли бы собираться в центре. Тогда менеджер пошел к архитектору, который в то время был еще только программистом, и сказал, что нужна такая программа. Архитектор тогда уже знал, что хочет быть архитектором и поэтому разработал специальный формат, по которому все данные передавались бы в центр. И еще архитектор сделал так, чтобы другие программы передавали только те данные, которые есть в центре. Архитектор назвал это мэппингом данных и был молодец.
А потом этот формат и мэппинг он отдал менеджеру, а он отдал аналитику, а аналитик передал их разработчикам других программ. И все стали думать, что все хорошо.
А потом менеджер сказал одному программисту, чтобы он сделал так, чтобы программа принимала данные в том формате и дал ему пример файла формата и мэппинг. Программист был хороший и все сделал, но увидел, что данные были не те, которые нужны, и сказал об этом архитектору, менеджеру и аналитику, а аналитик сказал, что все хорошо. А когда до сдачи программы оставалось полдня, аналитик сказал, что это мы должны делать мэппинг, а не другие программисты. А менеджер расстроился и сказал, что аналитик не прав. И архитектор расстроился, потому что его не поняли, и сказал, что аналитик не прав. А программист обрадовался, потому что ему надо было меньше работать, а другим программистам -- больше.
Дорогоуважаемые программисты! Будьте осторожны и помните, что аналитики иногда не очень хорошо и правильно понимают программистов, и архитекторов, и менеджеров. А еще аналитики иногда бывают очень уверены в своем мнении и тянут до последнего дня, а программистам приходится оставаться на работе, чтобы все сделать, чтобы менеджер был доволен.
До скорых встреч!
среда, 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 г.
Дорогой блог!
Сегодня я расскажу тебе об одном человеке, он онолитег. Не подумай пожалуйста, что я ошибся, нет-нет. Он сильно отличается от аналитиков, о которых я тебе уже рассказывал.
Во-первых, он отлично знает русский язык и всегда использует много разных слов: вот, как бы, ну, там, понимаешь и другие интересные слова. Я очень люблю слушать, как он говорит. Он сам не говорит, но мне кажется, что у него красный диплом школы Викторов Степанычей. Он скромный и поэтому хороший.
Во-вторых, наш онолитег хорошо знает все о программах, которые есть в его проектах. Иногда он даже лучше программистов и подсказывает им, что они неправильно делают, но никогда не говорит, как надо делать правильно, чтобы программистам было интересно.
Вот какой он хороший онолитег.
Дорогоуважаемые программисты! Если у вас тоже есть такие онолитеги, пожалуйста общайтесь с ними больше. А если у вас вдруг их нет, обязательно попросите своего менеджера нанять хотя бы одного. Общение с онолитегами -- одно удовольствие.
До скорых встреч!
Сегодня я расскажу тебе об одном человеке, он онолитег. Не подумай пожалуйста, что я ошибся, нет-нет. Он сильно отличается от аналитиков, о которых я тебе уже рассказывал.
Во-первых, он отлично знает русский язык и всегда использует много разных слов: вот, как бы, ну, там, понимаешь и другие интересные слова. Я очень люблю слушать, как он говорит. Он сам не говорит, но мне кажется, что у него красный диплом школы Викторов Степанычей. Он скромный и поэтому хороший.
Во-вторых, наш онолитег хорошо знает все о программах, которые есть в его проектах. Иногда он даже лучше программистов и подсказывает им, что они неправильно делают, но никогда не говорит, как надо делать правильно, чтобы программистам было интересно.
Вот какой он хороший онолитег.
Дорогоуважаемые программисты! Если у вас тоже есть такие онолитеги, пожалуйста общайтесь с ними больше. А если у вас вдруг их нет, обязательно попросите своего менеджера нанять хотя бы одного. Общение с онолитегами -- одно удовольствие.
До скорых встреч!
Подписаться на:
Сообщения (Atom)