October 31, 2006

Имя мне - Лень!

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

Как бы то ни было, а возникло у меня размышление ровно на эту тему. Не знаю у кого как, а у меня такие "критические дни" (когда работать, да и вообще думать, вроде бы и надо, а совсем не хочется) случаются. Не скажу что уж совсем часто, но грешу. Среди моих коллег это тоже не редкость.

Лично я пытаюсь в такой ситуации не идти против природы, и стараюсь занять себя чем-нибудь умеренно полезным но незатейливым, чтобы поменьше задействовать мозг. Сегодня я долго размышлял на тему вчерашнего поста Михаила Пеньковского, восхищался новым творением Defmacro и прошёл корпоративный онлайн тренинг. Но на что-то бОльшее (более творческое, чем просто размышления) меня не хватило.

Посему, очень сильно интересует мнение масс. Благо, аудитория на ресурсе достаточно разноплановая. Случаются ли у Вас периоды паталогического бездействия и как Вы с ними боретесь или не боретесь? :-)


October 30, 2006

Ученье - свет

Наткнулся тут на интересные посты по поводу обучения computer science.(Смотри ссылки раз, два и три). Вкратце, там идёт обсуждение на тему "какой язык программирования больше всего подходит для начального обучения". Кроме того, там же есть рассуждение о том, что неплохо было бы, если бы состоявшиеся специалисты, то есть люди, имеющие определённый опыт в сфере создания программного обеспечения, приходили в классы и делились опытом, потому как теория это, конечно, хорошо, но пока она не подкреплена практикой, никому не интересна.

Не знаю как там у них, но у нас, на мой взгляд, всё гораздо серьёзнее, и одним выбором языка программирования не обойтись. Я, как человек, в чьей памяти ещё свежи студенческие годы, хочу немного поразмышлять на тему "как бы я хотел, чтобы меня учили". Ну и, конечно же, был бы рад услышать(увидеть/прочитать) комментарии, а ещё лучше ответные посты :-)

Итак, начнём. Для начала обрисую как для меня происходил процесс обучения. Даже не процесс... нет. Пожалуй просто перечислю майлстоуны. Паскаль, ассемблер, C/C++, чуточку Жавы, ООП, немного ЛИСПа, немного Пролога, чуток БД, а потом всё это перемешиваем и добавляем по вкусу теории разработки программного обеспечения. Отмечу, что под термином "теория разработки ПО" скрывалось описание RUP, совсем даже поверхностное, наверное из-за ограниченной длительности курса. Чего я не слышал в институте и не услышал бы никогда, кабы не врождённая любознательность: COM/DCOM/COM+, .Net, Python, Ruby, Perl, CGI вообще, SQL, паттерны и ещё много чего.

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

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

Я бы хотел услышать, что есть замечательный мир веб-программирования, который активно развивается, что есть не только MS VisualStudio и Borland C++ Builder, но и ещё IDEAEclipse. С превеликим удовольствием я бы послушал рассуждения состоявшегося программиста на тему что лучше: строгая типизация или duck typing, Open Source или Proprietary Software, Scheme или Haskell, Java или .Net в конце концов! Ах да! Забыл про Линукс. Я бы хотел, хотя бы для общего развития, пообщаться с Линуксом, пока у меня на всё это было время. Теперь времени гораздо меньше, теперь есть работа, серьёзно снижающая количество времени, которое можно потратить с интересом.

Наверное, я бы хотел стать преподавателем, ведь есть столько всего интересного, о чём можно рассказать. А пока буду излагать свои мысли на бумаге в блоге.


October 27, 2006

Без бумажки ты букашка

Не далее как вчера имел с коллегами небольшую беседу. Рассуждали мы на тему профессиональной сертификации. В частности - сертификации программистов. Вопрос, как оказалось, совсем не простой и многосторонний. И вот, что я думаю по этому поводу.

Компании сертификация программистов нужна только тогда, когда ей необходимо получить зарубежного клиента, который гораздо охотнее будет сотрудничать, если ему приедоставят бумагу, в которой сказано, например, "у нас в команде ХХ% разработчиков имеют сертификаты Microsoft/Sun/Oracle/Whatever". Я допускаю возможность, что наличие сертифицированных разработчиков влияет как-то и на отношения с Российскими заказчиками, но точно ничего сказать не могу. Ради своего бизнеса (и это, несомненно, правильно) компания готова пойти на затраты, чтобы оплатить программисту не только сдачу экзамена, но и всяческие курсы по подготовке к нему. Это позитив. С другой стороны, компания врядли сделает то же самое только если это надо самому разработчику (ну, например, для поднятия самооценки). Какие могут быть аргументы? Например: "наша компания работает на внутренний рынок и ничего от сертификации сотрудников не выигрывает" или "зачем мы будем тратить деньги на то, что потом поможет сотруднику при приёме на работу в другую компанию". В принципе, позиция ясна. Я с ней даже согласен, но! Не является ли этот самый программист, а вместе с ним и его "моральный дух", основой компании? Ну если не компании целиком, то её подразделения. Тогда любые вложения в развитие программиста, если ему это интересно и важно, повышают лояльность человека к компании и в конечном итоге его производительность и ценность. Разве не так?

Можно рассмотреть вопрос под другим углом. С точки зрения самого подопытного программиста. А нужна ли сертификация ему? Я не очень часто смотрю объявления о приёме на работу, но последнее время почти не встречал в требованиях к кандидатам наличия каких-либо сертификатов. Скорее всего это связано с тем, что рынок (и это не я придумал) испытывает нехватку разработчиков. Они всем нужны, но их нет. Точнее нет того качества, что требуется. (Эта тема постоянно всплывает там и сям, поэтому о ней говорить не будем.) Компании и рады бы брать на работу сертифицированных специалистов, но внуждены снижать требования. Рынок, однако. Вернёмся к программисту. По большому счёту, в такой ситуации на рынке рабочей силы, эта самая сертификация нужна ему как корове седло. Она, конечно, может стать плюсом, но не решающим. Тут уж всё начинает зависеть от человека, если он заинтересован в своей работе, то он будет стремиться к освоению чего-то нового, интересного, может быть к той же сертификации, будь она неладна. А тем, кто по какой-то причине не хочет или не может развиваться, остаётся только одно - постоянно жаловаться на маленькую зарплату, плохие условия труда и ужасно завышенные требования к кандидатам :-)

Я как-то задумывался над тем, чтобы сдать сертификационные экзамены Microsoft, а потом передумал. Почему? Да просто посчитал, что это мне ничего не даст в плане развития, а острой необходимости в наличии сертификата нет. Хотя, подобные мысли всё ещё посещают меня время от времени.

Что уважаемый читатель думает по поводу нужности профессиональной сертификации как с точки зрения компании, так и с точки зрения работника? Может быть у кого-то есть сертификат и он поделится с нами, какие выгоды даёт его наличие? Является ли самообразование достойной альтернативой прохождению курсов по подготовке к сертификационным экзаменам? Вобщем, все мнения по данному поводу приветствуются!


С глаз долой, из сердца вон

Получился у меня с Not A Kernel Guy своебразный диалог, в рамках которого он, в течение одного комментария, дважды посоветовал изменить дизайн. Неважно по какому поводу и неважно дизайн чего. К данному разговору это не имеет никакого отношения. Но вот, что показалось мне достойным отдельного разговора, так это вопрос, как определить ту грань, когда старый код поддерживать становится гораздо труднее чем написать всё from scratch.

Рискну ошибиться, но ведь наверняка, это общая проблема для многих долгосрочных и не очень проектов.

Хорошо, когда можно обойтись малой кровью, то есть лёгким рефакторингом, или переписыванием пары классов, которые составляют суть проблемы. Но ведь это совсем не всегда возможно. Даже в моей скромной практике был случай, когда код работал нормально на однопроцессорной системе, а будучи запущенным даже на HyperThreading процессоре начинал приподносить сюрпризы, я уж не говорю про многопроцессорные системы, где его пытались запускать. Сразу отмажусь, код писал не я :-) Да, и собственно тот, кто его писал тоже не виноват, потому как дело было давно, когда и мысли не было, что однажды будет доступно нечто бОльшее, чем разделение времени одного единственного процессора. Было совершенно ясно, что проблема в синхронизации потоков, но как это обычно бывает: 

The fellow who designed it
is working far away;
The spec's not been updated
For many a livelong day.
The guy who implemented it is
Promoted up the line;
And some of the enhancements
Didn't match to the design
They haven't kept the flowcharts,
The manual's a mess,
And most of what you need to know,
You'll simply have to guess.
(с) чей-то
 
А меж тем система была серьёзная, установленная много где и рабочая. Какие-то вещи удалось исправить, но ничего кардинального изменять не стали. Вместо этого задумали новую систему :-)
 
У данной проблемы есть ещё одна сторона. Очень интересная. Суть её сводится к фразе "сделано не здесь". (Об этом аспекте хорошо написано в статье на RSDN начиная со слов "История программных революций от Microsoft"). То есть как бы хороша ни была система и принятые в ней решения, каждыая новая группа, которая берётся за её разработку (доработку/переделку и пр.) предпочитает сделать всё заново, нежели что-то изменить.
 
Короче говоря, эволюционный и революционный подходы. Их плюсы и минусы, а так же причины, по которым следует предпочитать один подход другому. И всё это вовсем не обязательно с точки зрения программного обеспечения.
Хотелось бы услышать глас народа по данному поводу.

October 26, 2006

Внутрипроектная коммуникация

По мотивам поста Константина Старовойтова.

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

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

Хочу здесь описать ещё два варианта развития процесса взаимодействия программиста и менеджера.

Вариант 1: программист сделает так, как хочет начальник, но только из вредности, а не потому что верит в его (начальника) непогрешимость. Отмечу сразу, что до такого состояния "да гори оно всё синим пламенем" программиста ещё надо довести. Как это сделать? Игнорировать все его попытки высказать свою точку зрения будет достаточно.

Вариант 2: делать так, как говорит начальник (чтобы он отстал), но параллельно реализовать свою версию решения. А потом всё это выдать на гора и сравнить. Выход самый оптимальный, но малоприменимый на практике, потому как требует вдвое больше работы. Зато есть плюс: когда варианты будут исследованы и предложенный программистом будет признан лучшим, можно сказать "ну я же вам говорил!". Self esteem повышается в разы.

Имхо: к программисту лучше подходить не с ответом, а с вопросом, в смысле, что лучше дать ему помучаться над задачей, чем дать полуготовое решение на реализацию. Мне, например, гораздо интереснее было бы найти решение самому, а потом обсудить его и, возможно, улучшить. Кроме того, психологически трудно придумать что-то новое и, возможно, лучшее, когда на руках есть готовое решение. В спорной ситуации самым главным оказывается даже не профессионализм каждого участника, а способность их всех достичь желаемого результата вместе через диалог диалогу.

В качестве наиболее кардинального решения могу прелдожить: гнать такого менеджера подальше от программистов, или ещё лучше - вручить ему клавиатуру и пускай тоже трудится, раз такой умный :-)


October 25, 2006

Browsing 2.0

Сейчас модно называть всё 2.0. Вот и я решил не отставать от мейнстрима :-)

Всем, конечно, известно, что и Microsoft и Mozilla разродились на днях новыми версиями своих браузеров. IE 7 и Firefox 2 соответственно.

Как-то сравнивать их до официального релиза не было смысла, ибо бета не всегда полностью соответствует готовому продукту. А вот после -- можно. Только вот дело это неблагодарное и тем более, таких обзоров уже навалом.

По этому поводу хочу отметить лишь, что Microsoft всё меньше видится мне в качестве всемирного зла. Они даже не стали начинять ядом торт, предназначенный разработчикам FireFox.

Но разговор совсем не об этом. Разговор совсем даже о том, что: сейчас веб браузер выступает как платформа для серьёзных приложений. И примером тому могут служить Google Docs&Spreadsheets или Kiko. Сегодня высказывания о том, что для полноценной работы на компьютере надо иметь только Операционную систему и Браузер в придачу, уже не выглядят чем-то из области фантастики. Сегодня это вполне реально, хотя, специфика решаемых задач будет сильно ограничена. На текущий момент это офисные приложения. Но никто не мешает сделать, например, некое подобие Online IDE. (Об онлайн компиляторах я слышал, TryRuby видел, IDE пока не встречал. Поправьте меня если я не прав. А если прав, то тоже скажите, буду патентовать. upd: Google сказал, что online IDE существуют. Патент накрылся :-)).

Более того. (Меня этот факт поразил, хотя, если начать думать в правильную сторону, я мог его заметить и сам.) Сегодня я наткнулся на мысль, что серьёзные веб приложения могут смело работать какое-то время offline. Эдакие смарт клиенты, только с другой стороны :-)

Такая виртуальная централизация (виртуальная потому что тут всё-таки речь идёт не об одном сервере, даже в случае с одим ресурсом) напоминает мне далёкое прошлое, о котором я только слышал, когда в одном большом кабинете стоял огромный такой ЭВМ, не побоюсь этого слова, а в другом кабинете сидели за относительно компактными терминалами программисты и с этим ЭВМ работали.

Всё это звучит красиво, но есть гигансткое НО. Раньше, во временя больших ЭВМ всё работало относительно локально. Проецируюя же такой централизованный подход на глобальную сеть, мы сталкиваемся с проблемой доступности каналов передачи данных и их надёжности, и до тех пор, пока приемлимый уровень доступности/надёжности не будет достигнут в глобальном масштабе, всё совсем не так радужно.

Итак, чтобы получить "всеобщее счастье over IP" надо ещё совсем немного подождать, а пока будем наслаждаться новыми технологиями и продуктами, которые каждый день радуют нас своим появлением.

Под впечатлением от:

 

Technorati tags: ,

О сокрытии

Вместо эпиграфа:

information hiding

(1) In programming, the process of hiding details of an object or function. Information hiding is a powerful programming technique because it reduces complexity. One of the chief mechanisms for hiding information is encapsulation -- combining elements to create a larger entity. The programmer can then focus on the new object without worrying about the hidden details.

Information hiding is also used to prevent programmers from changing --- intentionally or unintentionally -- parts of a program.

(Взято отсюда: http://www.webopedia.com/TERM/I/information_hiding.html)

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

Итак:

Совершенно ясно, что такое это самое сокрытие и для чего оно применяется. Для того, чтобы спрятать детали реализации от посторонних глаз. В случае с .Net Framework (как, впрочем и с любой другой библиотекой классов) это делается для (в том числе) упрощения работы пользователя, то есть программиста, то есть меня. Чтобы я не задумывался над всеми теми подводными камнями, на которые натыкались разработчики Microsoft в процессе реализации какой-нибудь фишечки, типа того же класса Thread.

Однако! Сами разработчики периодически вынуждены (под влиянием общественного мнения или по собственной инициативе) описывать внутреннее поведение и внутренние взаимосвязи своих разработок широкой публике. В качестве примера, вчерашний разговор о том, почему Sleep хуже чем Join или вот ещё один пост с подробностями реализации анонимных методов в .net 2.0. И это только то, что мне попалось за 2 последних дня.

Согласен! Всегда интересно выяснить как же оно всё-таки работает. Но (выдержка из поста про анонимные методы): "It's actually important that you understand how these works (and not just treat it as "magic"), because lack of said understanding can lead to subtle programming errors". Это, блин, портит всю красоту чёрного ящика под названием Whatever Framework. Получается, что мало понять ЧТО он делает, надо ещё отдавать себе отчёт в том, КАК он это делает. А как же сокрытие?! Более того, если я знаю как это работает, то зачем я буду вообще это использовать, когда могу сделать точно так же.

ИМХО: фреймворк, если уж он так гордо себя именует должен быть совершенно чёрным ящиком и не приводить к subtle programming errors только потому, что я не знаю как он устроен.

 

Technorati tags: ,

October 24, 2006

Мой мир перевернулся

Самый активно используемый приём в мультитрединговом программировании объявлен вне закона. Источники близкие к Microsoft утверждают, что System.Threading.Thread.Sleep() это совершенно, то есть абсолютно, в корне неверное решение.

Я ещё нормально отнёсся к тому, что в .net 2.0 по сути запретили Suspend и Resume, я ими и не пользовался, но вот Sleep(). Это всё равно что запретить... воздух что ли. Нет, конечно, предлагаются альтернативные методы, которые несомненно будут работать, но как много связано с самим словом Sleep. Мне будет тебя не хватать, друг.

Навеяло рифму: "R.I.P. Sleep".

Technorati tags: , ,

October 19, 2006

Web 1.0 vs. Web 2.0

Как-то приводил здесь пример описания языков программирования посредством задач, которые они помогают решить. Сегодня наткнулся на почти аналогичный метод описания/сравнения Web 1.0 и Web 2.0. На мой взгляд очень занимательно. Коллективный разум, однако.

Мне очень понравились высказывания типа:

или


This page is powered by Blogger. Isn't yours?