Weekly linkdump #156
Макс ИщенкоОпубликовано 19.12.2008 в Ссылки
Интересные ссылки за неделю:
- Михаил Донской о программировании, Жизненный цикл программиста
- Влад Головач опубликовал в открытом доступе второе издание своей книги, Дизайн пользовательского интерфейса II. Искусство мыть слона
- Обзор разных подходов к представлению данных, много food for thoughts, Data Visualization: Modern Approaches
- Еще на тему интерфейсов, 10 Useful Techniques To Improve Your User Interface Designs
- Если вы думаете что 2-х мониторный рабочий стол –это круто, то как насчет 6 мониторов? Office FAQ
- Программа Hello World в Five Strangest Programming Languages. забавно, но бесполезно
Активные темы на форуме:
Загрузка ...Понравилась статья? Подпишись на обновления по RSS/E-mail
На сайті http://mandolux.com/ є трохи wallpapers, в тому числі для 2х і 3х моніторів.
(c)Михаил Донской
Спасибо за ссылку на Донского. Шикарнейшая статья!
Weekly button accordion dump
ЛОЛ, рядом со мной сидят два чувака – у каждого по 5 мониторов, у меня всего лишь три ))
Просто смешно
http://www.disco.ru/russian/
http://www.disco.ru/english/
Одни понты и ничего по сути.
Понты – это с тремя годами опыта делать столь громкие заявления.
Где взять и откуда берутся программисты в России? Михаил Донской на Радио Свобода.
подкаст
http://itblogs.ru/blogs/pod/archive/2007/12/16/24195.aspx
Почему “Михаил Донский о программировании” Донский?
Может надо все-таки исправить на “Донской”.
Исправил
Уважаемый аноним, а при чём здесь три года опыта?
Так назывемые вами “понты” это моё субъективное мнение по поводу приведенной статьи, которое я имею право открыто высказать вне зависимости от “количества” опыта.
Очень уж рассмешили расставленные акценты на русской и английской страничках компании ДИСКо (DISCo). Как
http://www.disco.ru/russian/
http://www.disco.ru/english/
Если ближе к сути, то я не согласен с тем что профессия програмиста от прошла “полный цикл от интеллектуальной и романтической до бытовой и повседневной”. В любой профессии, в том числе и в нашей есть широкий спектр от абсолютной романтики до гнетущей рутины. Так есть сейчас и так было всегда, даже 40 лет назад, когда автор окончил матфак. Взять например ещё более древнии профессии – например торговец. Продавать на рынке – это скорее повседневная рутина, а вот торговать ценными бумагами и быть успешным – искусство.
Denys Nikolayenko
Я бы не делал акцент на сайте, вообще, и, тем более, не проецировал бы его на статью. У меня изначально сложилось мнение о том, что он давно не актуален. Что в общем-то, частая ситуация среди небольших компаний. Я называю это “сапожник без сапог” – у software outsourcing компании не хватает времени на то чтобы сделать (поддерживать в актуальном состоянии) свой сайт. Кроме того, думаю, что круг знакомств и авторитет Донского, наверное бы, позволил бы компании обойтись без сайта вообще. Если говорить об акцентах в разных русской и английской версиях сайтов, то в общем-то вполне себе нормальный текст, как на время его написания. Некоторые наши компании, до сих пор не осилили разделение сайта на языковые версии и мешают в кучу англо- и русскоязычное наполнение, что не менее смешно, чем сегодня читать текст написанный в 2000 году. Поэтому, повторюсь, обсуждая статью, не стоит проводить параллелей с сайтом.
Что касается статьи, то в приведенном тобой аспекте я все таки более согласен с автором. Хотя бы потому что, как по мне, “бытовая и повседневная” != “рутинная”. Но ты зацепил хорошую тему. Да, ты прав, рутина была, есть (и будет). Но, во-первых, соотношение рутинной и не рутинной работы 40, 30, 20 лет тому назад и сейчас плавно трансформировалось из 80 на 20, в 20 на 80. Но это не то, с чего нужно начинать. Начинать, нужно с определения того, что такое рутина. Чем дальше в лес, тем чаще приходится встречаться с мнением, что рутина в работе программиста – это поддержка системы, программного продукта, т.е. работа после transition phase. Далеко ходить не нужно, достаточно обсуждение компаний тут почитать. Масса программистов, которые считают, что их истинное предназначение – это “творчество”, которое в большинстве случаев заключается в том, чтобы “натяпляпать” продукт и “здихатись його”. А поддерживать его, или, о ужас ужас, поддерживать чужой (да, ужас, но не ужас ужас (С)
) продукт – это ниже их достоинства. На самом же деле “Since the days when computers first came into common use, there must have been tens of thousands of accounts receivable programs written. There are probably a dozen or more accounts receivable programs underway as you read these words.” (C) Tom DeMarco, Timothy Lister. Вот где рутина (хотя в Peopleware это используется в другом контексте). В тысячный раз писать одно и тоже. Как по мне, лучше посидеть на саппорте единственного в своем роде продукта, чем “творчески” в тысячный раз изобретать велосипед.
Аналогия, с торговлей ИМХО не совсем верна, так как и на продуктовом и на финансовом рынке есть люди, которые пытаются творчески подойти к процессу, так и те, кто действуют строго по заученной методике. Но это никак не влияет на то, что торговец является бытовой, повседневной, иными, словами, достаточно распространенной профессией.
И последнее, жаль что ты не увидел за деревьями леса. Основная ценность статьи не в ее названии, не в том, что она показывает эволюцию профессии программиста (пусть даже на примере карьеры одного человека). В ней затрагиваются несколько достаточно важных тем, как то: плачевное состояние нашей системы образования, рост финансовой составляющей в мотивации выбора профессии и другие. И к сожалению, это мало кто видит.
==========================================
Я не согласен с автором. Я понятия не имею какием образом работает VS 2008, но это мне не мешает успешно участвовать в разработке гиганской системы ентерпрайз-уровня. Невозможно знать программу досконально, если в ней тысячи и десятки тысяч человеко-месяцев работы. Возможно знания о работе инструментальных средств понадобятся при профилировании (например когда обнаружится чрезмерная нагрузка на процессор, и прийдется ее устранять), но в других случаях – это оверхед. Чем автору не угодили программисты на PHP вообще не понятно, или он считает что программисты, это только те, кто пишет на асме и брейнфаке, а остальные это быдло?
На HTML скорее верстальщики называются чем пограммисты.
To: Анонимно говорит: 22.12.2008 в 16:02
Не нужно утрировать. Не думаю, что речь идет о понимании того как работает подсветка синтаксиса в редакторе (хотя понимать как работает компилятор или отладчик все же полезно).
В моем понимании, под инструментальными средствами в данном случае подразумевается third party tools/libraries, а не среды разработки/отладки/профилирования. И тут я ой как согласен с автором, ибо использовать WinHTTP API или Apache Commons HTTP Сlient, не зная как работает протокол HTTP (не ознакомившись с RFC) – это классический пример непонимания “как эти средства организованы внутри, по каким принципам они работают”. А такое встречается сплошь и рядом: человек на собеседовании рассказывает, что он много работал с HTTP, в ответ я беру клавиатуру, делаю “telnet example.com 80″, прошу сгрузить корневую страницу и вижу круглые глаза. А будь у него в институте разработка простого HTTP сервера, в виде курсового проекта, все было бы куда приятнее. Собственно, это как я понял этот текст.
Хотя, если говорить про инструменты, то и там можно найти примеры. Приходит человек на собеседование. В резюме X лет разработки ActiveX компонент. Пара вопросов и обнаруживается, что он не имеет понятия ни об IDL, ни о CoInitialize, ни о threading models… потому что wizards. Люди часто пользуются всякими инструментами автоматизирующими разработку, без понимания того, что происходит за кулисами. “отсутствие такого понимания может вести к большим проблемам, начиная с неэффективности и кончая полной неработоспособностью” (С)
Я уже не говорю про запросы к БД из обработчика WM_PAINT. Смешно? Но ничего не выдумано, это все случаи из практики.
To: Анонимно говорит: 22.12.2008 в 20:00
Сейчас в приложениях применяют многоуровневые архитектуры, и часто программисту вообще не надо знать, как приложение взаимодействует с базой данных, как обменивается информацией с внешним миром и различными сервисами. Это называется хорошая архитектура приложения, и за нее отвечает архитектор (ну и какое-то количество программистов, которые работают с persistence layer). Если архитектура плохая – тогда каждому программисту приходится лезть в дебри MS SQL, различных сетевых протоколов, изучать как работают “инструментальные средства”. Я считаю это неверно.
Программирование уже перешло на более высокий уровень. Сейчас надо умение думать, чтобы уметь создавать/связывать/манипулировать абстракциями. Знание протокола http и CoInitialize are obsolete. Как работает CoInitialize – можно за час(день, неделю, выбрать нужное…) изучить с помощью мсдн и кучи документации. А научиться думать – это почти нереально(если сейчас не умеешь =)).
Конечно все это ИМХО, я сам далеко не архитектор и не могу тягаться с автором, но я считаю что ему пора на пенсию =)
ЗЫ Забыл свой пароль, коментарий от 22.12.2008 в 16:02 и этот – Антона Мартыненко
2Антон Мартыненко: напишите свой логин на support@developers.org.ua – будем восстанавливать пароль что-ли.
Анонимно говорит: 23.12.2008 в 08:38
Да автор, в общем-то, и не отрицает что он собирается на пенсию
, при этом описывая эволюцию отрасли программирования на протяжении всей своей профессиональной карьеры.
То что ты говоришь, отлично укладывается в рамки метфоры – профессия шофера. Тебя не интересует как автомобиль едет, ты знаешь где педали, руль и главное что он едет. А как сделать чтобы это все ехало – это задача
архитекторапроектировщика автомобиля. Но есть два нюанса:1. Понимание принципов устройства автомобиля в некоторых случаях далеко не лишнее. Наверное, самый наглядный и часто встречающийся пример – это засаженный по самые пороги в болото внедорожник, которых в умелых руках играючи преодолевает такое препятствие.
2. Каким образом, при таком подходе (”моя хата з краю”), должны появляться архитекторы? Если вокруг никто не знает “как приложение взаимодействует с базой данных, как обменивается информацией с внешним миров и различными сервисами”. Ушел архитектор из проекта и все?
Я уже не говорю про то, что такой подход не будет работать при использовании XP (да и гибких методологий, в целом), там хочешь не хочешь, а прийдется узнать принцип работы всех частей системы. Да и “хорошая архитектура” – это что-то недалеко ушедшее от серебрянной пули. “Сложная система, спроектировання “с нуля”, никогда не заработает. Следует начинать с работающей простой системы” (С). А для того чтобы архитектор мог развивать архитектуру, ему нужен квалифицированный feedback от разработчиков, а часто и оппонирование. А “архитектор всегда прав” – это я бы сказал тупиковый путь, так как человек не сталкивающийся с кодом на детализированном уровне, не сможет прочувствовать что лучше применить в той или иной ситуации. Но это мое ИМХО.
Кроме того, пример запроса к БД (persistence layer, business logic) из WM_PAINT, – это как раз пример того, что может получиться при недостаточном знании своих инструментыльных средств, и незнания чего делается у соседа.
Программирование уже перешло на более высокий уровень.
Да никуда оно не вышло. Да появилось больше готовых компонент. Нам уже не нужно писать библиотеки для работы с протоколом HTTP, но если ты уж работаешь с такой библиотекой, то знать как работает протокол необходимо. Если я прошу разработчика сжимать HTTP траффик, с целью оптимизации производительности, то я ожидаю всего лишь установки заголовка Accept-Encoding в gzip, а не выдумывания хитрой “связки абстракций” из ZipInput/OutputStream’ов, и в результате вопроса, а как это сделать если сервер не наш. Для этого нужно знать, что абстракция HTTP пакета, состоит из команды, заголовков и тела. И нужно знать какие стандартные заголовки бывают, и какие возможности заложены уже в сам протокол. А окромя как из RFC эти данные взять особо неоткуда.
To Анонимно
Я склонен считать что эта пропорция не изменилась. И более того, если брать в абсолюте то в нашем направлении сейчас гораздо больше творчества нежели было 40 лет назад. По одной простой причине, прогресс никто не отменял, и количество нестандартных задач, которые требуют творческого подхода и особых знаний неуклонно растёт. Эти задачи возникают не только и не столько внутри компьютерных наук, а больше на стыках с другими. IMHO. Информационные технологии по своей сути – подспорье для для всех сфер человеческой деятельности.
Как сказал Ашманов: “чем больше расширяется круг уже сделанного, тем шире разрывы в периметре, тем БОЛЬШЕ несделанного”.
По стечению обстоятельств я работаю в стенах Института Кибернетики основаного В.М. Глушковым. Состояние там действительно плачевное.
Но я не думаю что если бы в СССР изначально велось проектирование своих систем, то что-то бы существенно изменилось (за исключением Поисков, Парусов и т.д. и т.п.). Когда в стране системный кризис, то тут уже не до культуры проектирования.
Как теперь видно, что и в направлении разработки програмного обеспечения мы не далеко ушли от индусов и китайцев раз тягаемся с ними в плоскости стоимости услуг
2 Denys Nikolayenko
Как раз перманентная необходимость делать из говна пулю создала культуру изящных инженерных решений простыми средствами. И не только, скорее даже не столько, в ИТ. Именно носители этой культуры породили миф о том что пост-совок суть Клондайк гениальных инженеров. На самом деле то поколение в массе отошло от дел, а новое судя по всему, даже не знает слова RFC
To Denys Nikolayenko говорит: 23.12.2008 в 22:49
Соотношение должно было измениться хотя бы по той причине, что жизненный цикл систем стал гораздо дольше, а разработка упростилась/ускорилась. Т.е. времени на поддержку существуюющих решений (читай, рутину или bugfixing в понимании молодого поколения) стало идти больше, чем на разработку систем с нуля. Я именно об этом говорил.
Если говорить в абсолютных цифрах, то неплохо бы сравнить и количество программистов сейчас и 40 лет назад. Думаю, количество творчества в пересчете на одного программиста думаю все таки резко упало. Я не знаю, что там было 40 лет назад, меня тогда еще не было, но я тебе сказать, что даже по сравнению с тем, что было 10-15, ситуация изменилась существенно. Перечитал. Похоже на старческое брозжание. Пора прекращать, мне еще рано
В целом я хотел обратить внимание, не на изменение характера профессии, а на изменение характера профессионализма. Может это и не было основной мыслью статьи, но это именно то, в чем на мой взгляд наибольшая ее ценность.
Макс Ищенко говорит: 23.12.2008 в 23:03
Согласен, но см. выше про количество программистов. Кроме того, есть также выражение “Новое – это хорошо забытое старое”. Один простой пример, казалось бы недавно запущенный Яндекс.Пробки, является концептуальной копией проекта, который был сделан нашей командой в 2002-2003 годах, для одной из европейских компаний. Разница в том, что он в web’е, а у нас был на клиентском ПК (я бы сказал embedded, но после флуда на ветке GL, я уже боюсь это слово применять). Тут впору вспомнить Джоэла, с его Microsoft Goes Bonkers. Реально нового не так уж много. Ну и для полноты раскрытия темы можно еще перечитать The High-tech illusion (из Peopleware).
eugene_n говорит: 24.12.2008 в 00:09
Именно. Системы образования, которая развивала навыки системного мышления уже нет. А замены ей еще нет, и, к сожалению, непонятно будет ли…
2Макс:
Умер Михаил Донской http://www.infox.ru/business/media/2009/01/13/Mikhail_Donskoy_Nekrolog.phtml