День Программиста - неофициальный праздник программистов, отмечаемый на 256-й день года. Число 256 (два в восьмой степени) выбрано потому, что это количество чисел, которые можно выразить с помощью одного байта. Таким образом, с помощью 1 байта можно закодировать 256 символов. То есть все буквы английского языка, русского, цифры, знаки...

В високосные годы этот праздник попадает на 12 сентября, в невисокосные - на 13 сентября. Сообществу программистов эта идея пришлась по душе! Ведь действительно, сотни тысяч человек работают, и от их труда в наш информационный век зависит очень многое. При этом официального Дня у них до сих пор нет… И пока кто-то пробивает эту идею в правительственных верхах, кто-то просто радуется празднику.

Тем не менее, в разных кругах День Программиста празднуют в разные дни. Варианты могут быть такими:

• Настоящие кодеры отмечают День Программиста 2 дня. 255-ый и 256-ой :-)
• Первая массовая рассылка компьютерного вируса — даты расходятся.
• 19 июля — день создания первой программы. Ее написала Августа Ада Лавлейс, первый программист и дочь Джорджа Байрона. Программа была предназначена для для вычисления чисел Бернулли на аналитической машине английского математика Чарльза Бэббиджа.
• 10 декабря — день рождения самой Ады Лавлейс (1815 г.), в честь которой назвали первый универсальный алгоритмический язык программирования Ada, который был утвержден как раз 10 декабря 1980 г.
• 4 апреля — 4.04, по аналогии с ошибкой 404 («данная страница не найдена»). Считается днем веб-программистов.
• 26 июля — в честь предъявления первого в истории обвинения создателю компьютерного вируса. В 1989 году в этот день уголовному преследованию был подвергнут студент Роберт Моррис, создавший и запустивший компьютерного червя, названного его именем.
• На Украине со времен FidoNet принято отмечать день программиста в «пятницу, 13-го».

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

В 2007 году День Программиста отмечается 13 сентября.

Поздравляем всех программистов с профессиональным праздником и желаем, чтобы Ваш код был коротким, а года длинными!

Тосты на праздник День Программиста:

Каждый грамм - за создателей программ!

Раньше человек 10 должны были работать неделю, чтобы сделать столько же ошибок, сколько делает компьютер секунд за 10. За постоянное увеличение скорости компьютеров!

Самый короткий тост: Enter!!!

"Вся наша жизнь - игра", пусть и без возможности записаться. Так выпьем же за хакеров, которые могут обессмертить любые игры!

За связь без бpака!

За чтобы выпить, дай бог памяти? О! За нее и выпьем, ведь еще гигабайт никогда не будет лишним!

Корпорация Microsoft намерена представить новый функциональный язык программирования F#, который будет встроен уже в ближайшую версию среды для разработчиков Visual Studio. На сегодня F# создается силами подразделения Microsoft Developer Division.

Официальная дата языка F# (произносится как Ф-Шарп) пока не объявлена, однако в блоге ведущего специалиста Microsoft Developer Division говорится, что данный язык не является разработкой на один релиз, а будет развиваться в дальнейшем силами корпорации и сообщества сторонних разработчиков.

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

F# сочетает безопасность, производительность и скриптовые преимущества таких языков, как Python, говорят в Microsoft. F# будет иметь свои собственные библиотеки в среде .NET, сможет он работать как автономно, так и с операционной системой, промежуточным ПО и системами управления базами данных.

Язык будет работать в среде Microsoft CLR и взаимодействовать со всеми системами .NET Framework. В корпорации надеются, что F# найдет свое применение в академической среде.

Еще раз перечитав эту статью, а именно пару абзацев про грамотное поведение окон, возникла идея применить это на практике. Как раз есть форма, до отказа набитая всякими элементами управления (далее - контролами), в числе которых имеются и такие, из которых могут выпадать вспомогательные окошки. А именно: ComboBox (в режиме DropDownList) и DateTimePicker. Из первого выпадает список возможных вариантов, из второго - более-менее симпатичный календарик.

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

Сразу скажу, что с ComboBox'ом особых проблем не возникло. Правда вызвало некоторое удивление то, что сворачивание/разворачивание списка осуществляется не методом, а свойством, что несколько противоречит здравому смыслу. Все таки сворачивание/разворачивание - это действие, а не характеристика.

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

Ладно, нашел я комбо-боксовое свойство DroppedDown и быстренько соорудил метод:

private void Combo_Enter(object sender, EventArgs e)
{
	ComboBox cb = (ComboBox)sender;
	cb.DroppedDown = true;
}

и подцепил на него события OnEnter от всех комбо-боксов.

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

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

• Метод DrawToBitmap, позволяющий (наверное) нарисовать наш элемент управления в заранее созданный битмап. Интересно, нарисует только строчку с датой или еще и развернутый календарь??? Кому и зачем это может понадобиться - для меня загадка.

• GetAutoSizeMode возвращает одно из значений перечисления AutoSizeMode, которое содержит всего два таких значения: GrowAndShrink и GrowOnly.

  Нафига это надо, если у контрола есть свойство AutoSize. Поменяйте его тип с bool на int и к списку свойств GrowAndShrink и GrowOnly добавьте еще и None, и можно "облегчить" класс на целый метод.

  Чуть ниже нашел то, о чем уже писал в предыдущих постах: This property supports the .NET Framework infrastructure and is not intended to be used directly from your code. О как! Оказывается свойство есть, но пользоваться им низзя! Спрашивается, зачем оно тогда есть? Аа-а-а, да! Это будет наверное реализовано в будущих версиях... Или уже было реализовано в прошлых... Все равно маразм! :(

• Свойства CompanyName, ProductName и ProductVersion существуют вообще везде, где только можно. Понятно, нужно знать кто и когда соорудил тот или иной класс, особенно если это коммерческая разработка. Но вот только не ясно, какое именно отношение эти свойства имеют к календарю, ровно как и к любому другому контролу.

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

• Продолжение предыдущего пункта - метод GetNextControl, выдающий следующий из списка дочерних контролов. Ну коль уж так хочется напихать в календарь еще и прогресс-баров с радио-кнопками и полями ввода RTF-текста, то почему их нельзя перебрать просто как массив? Ах можно? Тогда нафига сделали этот метод? И почему в таком случае не сделали метод GetPrevControl, чтоб можно было перейти не только к следующему, но и к предыдущему????

• Идем дальше. Свойство HasChildren возвращает логическое значение, точно определяющее, есть ли у нас дочерние контролы али нет таких. Видимо, по мнению майкрософта, пользователи их библиотек настолько тупы, что для них нужно было создать отдельное свойство, а просто сравнить с нулем количество элементов в массиве Controls они не догадаются. Жуть. :(

• DropDownAlign - тоже очень полезная вещь. Вот только реальной практической пользы в нем я тоже не нахожу.

• Отдельно стоит рассмотреть целую коллекцию свойств, которой обладают абсолютно все контролы. Это Height, Width и Size, а также их сородичи: Left, Top и Location. Причиной их появления стала все та же предусмотрительность дядек из Microsoft, которые (для нашего "удобства") тупо продублировали одни и те же свойства, обозвав их разными именами.

  Сюда же стоит отнести и свойства Right и Bottom. Наверное рядовой программер не в состоянии запрограммировать операцию сложения двух целых чисел и ему для определения координат окна нужно ввести дополнительные свойства.

• Region - а вдруг кому-нить захочется сделать календарик круглым или с дыркой. Нельзя отнимать у программиста-разработчика такую бесценную возможность!

• MaximumSize и MinimumSize. Эти два свойства предназначены видимо для тех мега-программеров, которые осилили учебник языка C# только до раздела "События", а дальше - забили. Т.к. если разработчик знает, что такое события и как отследить изменение размеров окна, то для него потребность в этих свойствах никогда не возникнет.

• Text и Value. Тоже братья-близнецы. Созданы специально для ленивых, которым влом написать a = dtp.Value.ToString(). Теперь у них есть более короткий (и естественно более понятный) вариант: a = dtp.Text.

• FindForm и Parent. Еще один способ облегчить тяжелую жизнь программистам: циклы типа while(m.parent != null) m = m.parent; нынче не в моде. Нам надо отдельное свойство для решения таких сверх-сложных задач.

• Ну и под конец два гениальных события: ContextMenuChanged и CursorChanged. Первое наступает, когда у контрола изменилось контекстное меню (гениально, правда???), второе - (держитесь за стул, ибо упадете) наступает, когда поменялся курсор.

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

Вот такой вот цирк.

Но суть этой статьи сводится не к тому, что в библиотеке .NET Framework масса лишнего мусора, а к тому, что ни свойства, ни метода для программного разворачивания календаря я так и не обнаружил. Наверное про него гении из майкрософта просто забыли. Еще бы! Ведь надо было запрограммировать весь вышеописанный бред, а сроки сдачи коммерческого проекта .NET Framework 2.0 ведь не резиновые, вот и не успели...