Джефф Этвуд убеждает, что всем подряд учиться программировать не надо. Он сравнивает работу программиста с работой сантехника: важная профессия, но именно профессия, а не что-то, что должен освоить каждый.
Очень хочется объяснить это элитизмом и желанием оградить узкий кружок посвящённых от вторжения новичков, но, думаю, Этвуд на самом деле верит в то, что говорит: в отличие от математики и умения связно излагать свои мысли, программирование нужно не всем.
В комментариях защищают программистский образ мысли как полезный самому широкому кругу. Получается такой девиз: программистом можешь ты не быть, но понимать, что такое алгоритм и структура данных, ты обязан.
Хотя я полностью согласен с Этвудом в том, что скрипт-кидди, прочитавшие книгу «Освой самостоятельно за 24 часа», и на основании этого считающие себя программистами, принесли миру вреда больше, чем пользы, у этой медали есть и другая сторона.
Она заключается в том, что опытные, профессиональные люди, прекрасно разбирающиеся в своей области, сидят перед компьютером и выполняют рутинные, однообразные операции. Они не могут помыслить о том, что в «ворде» есть макросы, или просто боятся их.
Тотальное выпиливание из винды средств разработки даже простейших скриптов привело к тому, что люди сплошь и рядом отправляются выполнять работу машины.
Разумеется, решение не в том, чтобы вернуть в винду QBASIC. Но как в конце восьмидесятых — начале девяностых QBASIC (плюс немного пакетных файлов) был приемлем как средство автоматизации, так и сейчас есть подходящие средства, хотя бы вордовские макросы или, ещё лучше, маковский «автоматор».
Тезис «программирование — вторая грамотность», по-моему, остаётся верным и сейчас.
Тэги: программирование, ссылки
Написать комментарий
Месяц назад случился очередной переезд, правда, недалеко: из Новогиреева в Перово. Смешно, но я, кажется, привыкаю: по крайней мере последние два переезда были не такими и болезненными.
Для новой квартиры пришлось собрать некоторое количество икеевской мебели. Так вот, коллеги программисты, икеевские инструкции — всем нам образец.
Вне зависимости от того, что мы делаем: «коробочную» программу, информационную систему для «операторов» или внутренную автоматизацию для своих же, — всегда, абсолютно всегда идеальную программу портят пользователи. Даже если пользователи — это мы же.
И получается так, что совершенство системы (внутреннее или внешнее) никем не оценено и бесполезно, если пользователи не могут ей, эм, пользоваться. Приходится им помогать, отвлекаясь от увлекательных технических деталей и переключаясь на такие скучные, унылые вещи как эргономика (= простота пользования) и инструкции по эксплуатации.
А «Икея» нашла способ сократить свои расходы, предлагая покупателям самим собирать столы и стулья. То есть перевернула всё с ног на голову: сделала процесс сборки простым, в том числе благодаря качественным инструкциям. Плюс каждый человек, вкрутивший три самореза по этой инструкции, теперь может считать себя крутым сборщиком мебели.
Нам, программистам, тоже надо бы так.
Редакция от 23 февраля 2012
Тэги: всё равно что пожар, программирование
Написать комментарий
Концепция производного класса — это адаптация префиксной нотации классов, принятой в Simula, и уже поэтому она схожа с концепцией подкласса в Smalltalk. Названия «производный» и «базовый» были выбраны потому, что я никак не мог запомнить, что есть sub, а что — super, и заметил, что такие сложности возникают не только у меня. Вот ещё одно наблюдение: для многих тот факт, что подкласс обычно содержит больше информации, чем его суперкласс, кажется неестественным.
Бьёрн Страуструп. Дизайн и эволюция C++. М.: ДМК Пресс; Спб.: Питер, 2007.
Зато по суб-/супер- (или под-/над-, если угодно) сразу видно, кто из них шире, а кто ýже в смысле принципа подстановки Лисковой. Говоря в терминах смолтока, трудно забыть, что субкласс должен удовлетворять контракту суперкласса. А вот производный класс явно расширяет базовый, отсюда и квадрат, производный от прямоугольника.
Подложил нам Страуструп хрюшку, короче.
Тэги: программирование, язык
Написать комментарий
На работе мы подняли сайт на моём движке, конечно, не такой, как «Непостижимые поля». Там всё чинно: полезные советы из жизни си#, объявления о новом инфраструктурном коде и прочая программистская рутина.
Интересно другое. Я вновь получил то, чего мне, оказывается, не хватало два последние года: мгновенную отдачу при разработке движка.
Оно понятно, что отдельно должна быть боевая установка с реальными данными, а отдельно — тестовая, где фичи отлаживаются, а баги устраняются. И что даже мелкие изменения, а уж тем более крупные переделки надо устраивать в тихом уголке, где ничего нельзя запортить.
Но где тогда брать те эмоции, которые сопровождают правку кода на горячую, прямо по живому, на боевом сайте? Страх ошибиться пополам с предвкушением: вот сейчас, ещё строчка — и фича заработает!
Нет, крупные изменения, конечно, нельзя вносить не запланировав, не продумав, не оттестировав. Но зато и мелочью, если понимаешь, что эффект от неё появится через месяц-другой, после регулярного обновления, заниматься не хочется совершенно. Зачем? Успеется.
Редакция от 8 октября 2009
Тэги: indiana, программирование, работа
Написать комментарий
Есть три традиционных способа называть языки программирования в русском тексте: кириллицей строчными (питон), кириллицей с прописной (Питон), латиницей с прописной (Python). Старые языки ещё иногда пишут всеми прописными (BASIC, ФОРТРАН).
Но почему мы говорим на логлане, эсперанто, интерлингве, а программируем на C++, ФОРТРАНе и Паскале?
Понятно, что последний способ наиболее однозначный, и так или иначе придётся указывать оригинальное название, если, например, упоминается малоизвестный язык — какая-нибудь Cobra.
К сожалению, русский язык просит падежей, а выражения писать на Python-е, функции Lisp’а выглядят уродливо — и по тексту неизбежно расползаются паразитные конструкции типа в языке Lisp.
А уж если русифицировать названия языков программирования, то лучше записывать их так же, как естественные: со строчной буквы. В конце концов, по-английски принято говорить не только Python и Fortran, но и English и Russian.
Забавный побочный эффект такого способа написания: книга Василеску будет называться просто и со вкусом: «Прикладное программирование на языке ада».
Редакция от 17 августа 2009
Тэги: лучшее, программирование, русский язык
Комментарии (7)
Самый важное в этой книге: она заставляет задуматься об отвратительном устройстве множества простых вещей, от электронных часов до программ. Проблема, которую идентифицирует Купер, состоит в том, что разработчики и пользователи хотят разного, но первые не могут стать на место вторых.
Купер считает, что заниматься проектированием взаимодействия должны специально обученные люди (и ни в коем случае не программисты). Думаю, он заблуждается: просто нужно помнить, на каком стуле сидишь.
В книге есть интересная метафора: заходя в самолёт, пользователи хотят повернуть направо (в салон), а программисты — налево (в кабину пилотов). Первые хотят спокойствия и комфорта, вторые готовы променять уют на контроль. Метафора парадоксальная и верная, но даже самые рьяные авиаэнтузиасты вряд ли согласились бы всякий раз, когда летят, сами пилотировать. Но Купер не принимает это в расчёт: он полагает, что энтузиасту не понять пассажира, а программисту — пользователя.
Разумеется, разделение на проектировщиков взаимодействия и программистов — такая же чушь, как деление людей на технарей и гуманитариев по принципу «тройка по русскому — технарь, тройка по физике — гуманитарий». Если верить Куперу, программист — это человек, неспособный разработать интерфейс. Видимо, проектировщик взаимодействия должен характеризоваться в первую очередь неумением писать код.
Автор совершенно верно указывает на то, что принципы взаимодействия с пользователем отличны от принципов взаимодействия с компьютером. Однако вывод о том, что первым и вторым должны заниматься разные люди, мягко говоря, необоснован.
Вообще конкретные рекомендации Купера относительно метедик проектирования (профессия проектировщика, использование т. н. «персонажей») интересны, однако теряются на фоне основной идеи книги: проектирование человеко-машинного интерфейса — это отдельная и важная задача, а не подэтап написания кода.
Редакция от 28 апреля 2009
Тэги: программирование, свежие отзывы
Комментарии (2)
Кому-то снятся чужие сны, а мне время от времени приходят в голову чужие идеи. Такие, которые уже до тебя придуманы и где-то реализованы, и, если их применишь, окружающие неизбежно решат, что ты их оттуда целиком и утянул. Вот примеры.
Недавно пришло мне в голову, что в багтрекере правильнее было бы классифицировать случаи не просто по важности (blocker, critical, major, minor, trivial), а минимум по двум параметрам: серьёзности и вероятности. Тогда, если бы серьёзность и вероятность задавалась как величина в диапазоне 0..1, то важность можно было бы получить простым перемножением.
К счастью, добрые люди меня просветили: эта модель давно используется в методиках по управлению рисками. Да и задолбаешься всё это в трекер вбивать, на самом-то деле.
Где-то с полгода назад я окончательно определился, как удобнее всего оценивать книги и что делать с полемикой, которая неизбежно появляется везде, где читателям предлагают «оставить рецензию». В первом случае я придумал для себя простую и симметричную шкалу −2..+2, которая достаточно проста для того, чтобы соотнести впечатление с определённой цифрой шкалы. Во втором — решил отделить мух от котлет, разнеся рецензии (отзывы) и обсуждение (флуд) пользователей.
И то, и другое предназначалось для моей многострадальной, уже больше года не могущей добраться до веба библиотеки. Но — вот незадача! — обе эти идеи много раньше пришли в голову разработчикам «Яндекс-маркета».
Даже немножко грустно становится.
Тэги: reflection, webdev, программирование
Комментарии (1)
Внимание программистов, мегафункция:
function Return() { return; }
В нашем продакшн-коде, помню, как-то раз мне встретилось следующее:
public void DoSomething()
{
// много кода
return;
return;
}
Тоже дао.
Тэги: wtf, программирование, работа
Написать комментарий
Ну не из грязных же носков php-кодеров и script kiddies он [искуственный интеллект] зародится.
И что ему, бедному, зародившись, делать в сети, рассчитанной на присутствие миллионов злонамеренных естественных интеллектов, отточенных миллиардами лет биологической и десятками тысяч — социальной эволюции.
Будет, как домашняя кошка, ластиться к хозяину, чтобы кормил вовремя, и мышей таскать.
Редакция от 17 сентября 2008
Тэги: интеллект, программирование, цитаты
Комментарии (1)
Неделю назад я озаботился установкой багтрекера (это событие чудесным образом совпало по времени с моментом моего знакомства с «джирой» на работе). За эту неделю я успел вбить туда 58 «случаев» (case) и закрыть 8 из них.
Багтрекером я пользуюсь пока исключительно для «индианы»: другими проектами я занимаюсь так редко и так мало, что для них трекер не нужен.
Раньше я сначала держал баги в голове, потом записывал их в виде скрытых (и не очень) записей на сайте, пробовал приспособить для этого гостевую. В какой-то момент решил хранить их в OneNote, но замечаний оказалось слишком много, чтобы можно была их эффективно сортировать.
Сейчас же я распределил баги, замечания и идеи по реализации новой функциональности не только по важности, но и по номеру целевого релиза. К примеру, реализация RSS-ленты для конкретного тэга очень важна, но не для ближайшего релиза, а для того, в котором я собираюсь вернуть некогда существовавший многоязычный интерфейс.
А вот важность задачи «убрать ссылку „Регистрация“ со страницы входа в систему» сама по себе менее важна, но разобраться с ней надо до ближайшего релиза.
Такая организация задач позволяет, как это ни плоско прозвучит, выделить самые приоритетные дела и заниматься ими, а не разрываться между кучей «самых страшных» багов.
К сожалению, у меня нет возможности пользоваться функциональностью по оценке сложности работы, на основе которой можно подсчитывать дату ближайшего релиза. Увы: посвящать время разработке движка я вынужден урывками.
Редакция от 11 июля 2009
Тэги: software, warmland, программирование
Написать комментарий