Wednesday, December 31, 2008

Немножко об уличных фонарях

Несмотря на преимущественную техническую ориентированность блога, хотелось бы завершить год на мажорной ноте, то есть чем-нибудь неайтишном :) Поэтому последней заметкой уходящего 2008 года будет фотозаметка. А посвящена она будет не чему-нибудь, а уличным фонарям.

Дело в том, что я питаю какую-то странную слабость к этим небольшим, скромным, но от этого не менее прекрасным спутникам тихих парков и шумных улиц наших городов. Осознал я это только недавно, поймав себя на этой мысли во время съемки очередного фонаря. Просмотрев свои предыдущие фотографии, я понял, что во многих местах, где я побывал, я тоже их фотографировал, просто без осознания. Объяснить эту любовь сложно. Думаю, здесь в первую очередь играет роль то, что фонарь – это олицетворение источника света в темноте нашей жизни, который всегда на посту, всегда готов помочь людям найти дорогу. Это олицетворение постоянного служения, бескорыстного, безупречного, часто многовекового. Уличные фонари наполнены какой-то грустью. Их рабочий день начинается, когда большинство людей уже сидят в теплых домах и пьют чай, и заканчивается, когда мы просыпаемся и только-только выходим на работу. По большей части они стоят в одиночестве в ночной темноте, и лишь изредка их одиночество скрашивается одним или несколькими прохожими, которые спешат домой или на работу, ничего не замечая вокруг, даже тех, кто освещает им дорогу. Но фонари слишком скромны, чтобы просить благодарности, и слишком великодушны, чтобы обижаться на нас за это. Они просто делают свою работу, день за днем, год за годом, век за веком. Эта заметка – благодарность им за то, что они несут свет в наши жизни.

Полтава

Picture 098  Picture 117

 Picture 115

Киев

Picture 119 Picture 063

Днепропетровск

Picture 016

Коломыя

IMG_2706

Львов

IMG_2584

Санкт-Петербург

IMG_4988 IMG_5416

Москва

Picture 509 Picture 558

Иркутск

Picture 470

И наконец, Харьков

IMG_8279 IMG_2966 IMG_3217 

Picture 077 IMG_3210

IMG_3210_kvadrat_bw

Еще раз поздравляю всех с Новым годом и Рождеством! :)

Tuesday, December 30, 2008

Разминка мозга №1. Числа и Новый год

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

Задачка изначально была совсем не новогодняя, но я решил, что надо ее видоизменить в связи с праздниками, а заодно и запутать вам возможность поиска ответа в великом и ужасном ;)

Итак, представьте себе: Жил да был на свете Дед Мороз (он же – Санта Клаус). Да, это тот самый дедушка, который на Новый год приносят хорошим деткам конфеты и мандарины, а взрослым – iPod’ы и Wii. Что, вам не принесли? Ну, значит плохо себя вели ;)

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

Однако, дедушка стар, и ваша задача – помочь ему найти это число за минимальное количество проходов по хлеву. На беду, у дедушки еще одна проблема – у него не очень хорошая память, он может запомнить лишь несколько чисел (для определенности положим не больше 5), а писать он не умеет. Зато дедушка умеет считать :) Складывать, вычитать, умножать и делить. Думаю, он умеет еще извлекать корни и решать интегральные уравнения третьего порядка, но к нашей задаче это отношения не имеет :)

Вот, собственно, и все. Прошу алгоритмы в комментарии, товарищи программисты и не только. Чур, код не писать, покажите, на что вы способны без компилятора ;)

PS. С наступающими вас! Пусть 2009 год даст новые идеи и мечты, а также энергию и устремление для их реализации! И, конечно, счастья, здоровья и любви вам и вашим близким!

Monday, December 22, 2008

Доклад на харьковской UNETA

Судя по всему, я буду одним из докладчиков на следующей харьковской UNETA, которая ориентировочно будет в начале-середине января. Тема у меня будет не совсем обычная, она будет связана с производительностью ORM. Точно будут L2S и EF, возможно, добавлю что-то еще, если хватит времени. Так как тема не связана с какой-то конкретной технологией, скорее, это разбор и сравнение, то я могу немного варьировать ее содержание. В связи с этим у меня возник вопрос, что бы вам хотелось услышать? В принципе, скелет доклада я уже продумал, но все равно есть место для различных деталей, тестов, которые я могу провести и т.д. Я постараюсь учесть все пожелания и осветить их в докладе по-максимуму.

В докладе я постараюсь рассказать о том, как работают рассматриваемые ORM внутри, что именно влияет на их производительность, проведу некоторые наиболее интересные и показательные тесты для их сравнения между собой и с чистым ADO.NET, и постараюсь рассмотреть генерируемые каждой ORM запросы.

Итак, у меня есть несколько вопросов к вам:

  1. Стоит ли включать в доклад NHibernate? Или достаточно будет L2S и EF?
  2. Какие тесты вы бы хотели увидеть?
  3. Какие сопутствующие темы вам были бы интересны? Что из неописанного выше можно осветить еще?

Ответы прошу оставлять в комментариях. Прошу поучаствовать в опросе не только харьковчан, которые планируют идти на UNETA, но и всех, кому это интересно. После доклада я сделаю отдельный пост, посвященный результатам, в котором выложу и презентацию, и тесты, и их результаты.

Спасибо за помощь :)

Saturday, December 13, 2008

Дао программиста

Думаю, каждый программист в своей работе уже определил для себя, что программирование состоит как минимум из двух компонентов: технологий и подходов (возможно, не самое лучшее слово для описания данного термина, но лучше термин я не нашел).

Технологии определяют “чем” мы работаем, т.е. это набор инструментов: языки программирования, базы данных, среды, тулзы, библиотеки классов, фреймворки, компоненты и т.д. То есть, если взять аналогию с токарем, это те инструменты и материальные приспособления, которые он использует для изготовления деталей.

Подходы же определяют “как” мы используем все эти инструменты и пишем код, т.е. в случае программирования это понимание и правильное использование ООП, SOLID, паттернов проектирования (GoF, Fowler), каких-то других Patterns & Best Practices, архитектурных принципов, рефакторинга, алгоритмов, структур данных и т.д. Сюда же можно отнести и знание и использование таких практик, как TDD, DDD и пр. В том числе это и тот опыт, который мы приобретаем в процессе работы. В случае с токарем это его умение вытачивать те или иные детали, которое он тоже совершенствует.

У каждого программиста эти 2 компонента развиты в разных соотношениях. Есть ребята гармонично развитые, которые, например, не только знают о том, что есть такая штука как ООП, но и правильно его используют. Есть отклонения в ту или иную сторону.

Как правило, у начинающих программистов идет четкий перекос в сторону технологий. Они изучают язык(и) программирования, технологии разработки веб-приложений и доступа к данным в университете или по книжкам (статьям в инете/msdn/блогам, нужное подчеркнуть), и верят в то, что этого знания достаточно не только для того, чтобы написать приложение любой сложности, но и чтобы быть классным программистом в целом. Они также часто верят в то, что на любой их вопрос всегда найдется ответ в гугле, что какие-то там непонятные паттерны проектирования им не нужны и что они знают ООП в совершенстве (дружный смех в зале). Что, узнаете себя в молодости? :)

Прозрение приходит со временем. Вдруг оказывается, что есть еще такие вещи, как сложность приложения, связность, взаимозависимость, что ты пишешь не ООП-код, а процедуры, сгрупированные в классы, что рефакторинг – это не простой звук, а реальность, что unit-тесты – это не прихоть лида или архитекта, а отличное средство подерживать качество продукта (и кода) в здоровом состоянии. Программист начинается развиваться не только в сторону технологий, но и в сторону подходов. Приходит понимание, что технологии уже не так и важны, потому что практически любую из них ты можешь изучить довольно быстро, а вот на переписывание каличного кода можно потратить недели и месяцы. Кроме того, накопленный опыт позволяет даже относительно легко перепрыгнуть на другой язык программирования или даже платформу. Программист выходит из установленных рамок и начинает понимать, когда ту или иную технологию лучше использовать, а когда стоит избегать ее как огня. Сейчас вот мы большой кистью закрасим небо, а потом возьмем маленькую и прорисуем на его фоне ветки дерева и листики. Вы знаете, а здесь вообще акварель не подойдет, давайте это все маслом сделаем! Это уже уровень понимания начинающего архитекта.

Неужели это конец развития? Нет, конечно, это только начало. Во-первых, нет предела совершенству, и знание и понимание тех же технологий можно и нужно увеличивать. А во-вторых, когда программист переходит на уровень архитекта, у него начинаются уже свои головные боли и дальнейшее развитие, но уже не как программиста. Есть application architect, solution architect, enterprise architect, etc. и у каждого свои навыки и знания. Про дао архитекта я пока написать не могу, извините, не дорос еще :) Но оно есть, я в этом уверен.

К чему я все это веду? К тому, чтобы все понимали, что в работе программиста важны и технологии, и подходы, что даже отличное знание технологий еще не делает программиста инженером. На одном крыле далеко не улетишь. Ну и чтобы каждый мог понять хотя бы приблизительно, на каком уровне он сейчас находится и увидел, что именно нужно развивать. Благо, книги есть не только по технологиям, но и по подходам. Изучайте ООП, паттерны, рефакторинг, всякие TDD/DDD/Agile/прочее, это чужой опыт, который может помочь вам стать настоящим профессионалом. Успехов!