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

P.S. Придумалось далеко не для всех известных мне языков — раскрытие темы для недостающих только приветствуется.

Prolog
Женщина-мечта: делает все, что вы хотите. К сожалению, иногда описание того, что же вы хотите, занимает больше времени, чем объяснение, как это делать.

BASIC
Горячая разведенка; специализируется на соблазнении подростков, и очень многие получают с ней свой первый опыт. Мнения взрослых о ней разделяются — одни вспоминают ее с нежностью, другие — осуждают ее дурное влияние на юные умы.

Любая достаточно сложная технология неотличима от магии
Артур Кларк

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

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

Меня всегда завораживала магия программирования — маленькие фокусы, в которых бессмысленный на первый взгляд код делает что-то интересное. Самые известные из них — «подписи», которые выводят на печать короткий текст (обычно имя автора). В прошлый раз я показала несколько таких фокусов, основанных на эзотерических языках программирования, и некоторым читателям они даже пригодились при подготовке новогоднего поздравления :-) Настоящая же магия — это создание таких вещиц на совершенно нормальном языке, который вы используете каждый день, например, на C++ или Java. В этой статье я покажу несколько способов вывести короткий текст с использованием в качестве исходных данных только числовых констант.

Disclaimer: большинство приведенных фокусов основаны на низкоуровневых действиях с памятью, поэтому результаты могут варьироваться в зависимости от архитектуры компьютера и используемого компилятора (я пользуюсь gcc).

C++ спокойно относится к маргинальным манипуляциям с памятью и указателями, поэтому обфускации типа задания строки числом — почти обычное дело :-) Самый простой пример:

Перевод статьи молодого греческого программиста «Why I bill hourly»

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

Я люблю сравнивать разработку программного обеспечения с возведением здания, начиная с пустого земельного участка. Процесс выглядит примерно так:

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

Любой инженер-строитель шарахнется от такого предложения, программисты же в своей жажде заключить сделку прикинут смету, удвоят ее, добавят 30% и будут надеяться на лучшее. Как отвечаю на такой вопрос я?

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

У регулярной сверхурочной работы множество вредных последствий — как для команды, так и для компании. Давайте их рассмотрим.

Истощение

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

Иногда мне приходят письма с предложениями продаться как блоггер, то есть писать заказные вещи за известное вознаграждение. В большинстве своем это недостойные и неподобающие затеи типа вирусного маркетинга, не требующие особого умения писать, на которые уважающий себя и свое дело человек не согласится (если, конечно, он не погибает от голода). Но однажды я получила предложение, от которого не смогла отказаться — хотя бы потому, что мечтала об этом уже несколько лет. Так я стала одним из трех официальных блоггеров TopCoder Open 2010. В этой статье я расскажу о том, как в моей почте на полгода поселился ярлык «Blog», о том, как неожиданно сложно оказалось писать на заданную (пусть даже любимую) тему в рамках фиксированного расписания, и о том, чем все это закончилось.

Пролог

TCO (а раньше и похожий турнир для студентов TCCC) проводится каждый год, и каждый год организаторы прилагают массу усилий для того, чтобы турнир стал максимально интересным для участников и наблюдателей. Кульминация турнира — финалы-онсайт, и очень важно передать дух происходящего там зрителям, наблюдающим только по интернету. С 2007 года TopCoder экспериментирует с форматами блога, позволяющими сделать это лучше всего. Однажды у нас был даже видеоблог, снятый специально приглашенными профессионалами, но обычно блог имеет более привычную форму текста и фотографий, и пишется админами и/или избранными членами сообщества (хм, TC member звучит лучше). До этого года репортаж велся только с финалов, а блоггеры выбирались на конкурсном основании по одной статье, в которой они должны были доказать, почему выбрать нужно именно их. В этих конкурсах я не участвовала ни разу — то я была еще маленькая, то находились другие дела, то просто стеснялась предъявлять свое свиное рыло в калашном ряду предыдущих победителей — звезд масштаба Петра Митричева (который был одним из первых «выборных» блоггеров, неожиданно выбыв в последнем раунде Algorithm).

Главный турнир года на TopCoder (хабраанонс) закончился уже неделю назад, а на Хабре это важнейшее событие до сих пор не освещено! Это странно и удивительно, и я, верный адепт TopCoder, спешу исправить это недоразумение — тем более что в этом году я имела возможность наблюдать финалы вживую.

Algorithm

Самое зрелищное и эмоционально насыщенное соревнование турнира и в этом году не обмануло ожидания зрителей. Многократный чемпион прошлых лет Петр Митричев (Petr) удивил и немножко шокировал своих поклонников, выбыв из соревнования в первом же полуфинале со всего лишь одной решенной задачей. Второй фаворит, TianCheng Lou (более известный как ACRush), уверенно выиграл свой полуфинал и лидировал весь финал до самых системных тестов, которых не выдержала его третья задача, отбросив его на второе место под слитное «аах» зрителей.

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

Я не могу безболезненно сидеть за столом дольше часа подряд, и я не могу работать больше, чем стандартный восьмичасовой день. Проблема в том, что последние 15 лет моя стратегия работы заключалась в том, чтобы поймать «поток» и после этого кодить очень долго без перерывов. Эта стратегия очень популярна у кодеров, любящих запираться на сутки, надевать наушники и отключаться от внешнего мира — и именно поэтому они так болезненно реагируют, когда их отвлекают. Программирование требует концентрации, а концентрация работает по принципу клапанного механизма — на разогрев и запуск требуется время, поэтому уже запущенный механизм лучше не останавливать.

Я не думал, что существуют другие способы программирования, и уже начал было смиряться с тем, что обречен на низкую производительность. Но за последние 6 месяцев я обнаружил, что «медленный разогрев и долгая работа без перерывов» — поведение приобретенное, а не врожденное, и вполне возможно переучиться на другие ритмы активности. Это похоже на многофазный сон — как только вы привыкли делать вещи определенным образом, любые изменения очень трудоемки, но возможны — при наличии достаточной мотивации и времени на привыкание.

Когда плотник осваивает свое ремесло, он учится, наблюдая за работой других — за тем, как они распиливают древесину и забивают гвозди. То же относится и к хирургам, учителям и множеству других профессий — но не к программистам. Нас учат программированию в университетах или мы учимся сами, но при этом мы крайне редко наблюдаем за тем, как работают другие программисты. Если продолжать аналогию с плотниками, нас учат теории обработки древесины и алгоритмам забивания гвоздей, а потом оставляют с материалом наедине на всю нашу профессиональную жизнь, а все остальные плотники работают в отдельных закрытых комнатах.

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

— А ведь и правда день программиста, — спохватилась я за два часа до его наступления (в основном благодаря этому топику). Потом представила себе завтрашние поздравления — «С праздничком», «С днем программиста», «Поздравляю, коллеги»… Скучно. И душа запросила чего-нибудь эдакого, профессионального, с огоньком!

В этой статье я хочу предложить несколько способов представить любое банальное поздравление в необычном виде в полном соответствии с нашей профессией и названием блога. Большинство языков работают только с латиницей, так что будем либо желать «Happy Programmers' Day!», либо (для самых неудобоваримых языков) просто говорить «congrats».

Существует множество алгоритмов, которые собирают кубик Рубика — более или менее эффективно. Те из них, которые может выучить и применять средний смертный, обычно требуют более 40 ходов. Алгоритмом бога называют алгоритм, использующий для сборки любой начальной конфигурации минимальное количество ходов (термин связан с концепцией всеведения и применяется также для ряда других механических и логических задач). Число бога, соответственно, определяют как количество ходов, требующееся этому алгоритму в худшем случае. Так вот, для кубика Рубика это число равно 20.

Немного истории

Сам кубик был придуман в 1974 году. Теоретические исследования кубика сосредотачивались на оценке нижней и верхней границ максимального количества ходов для решения кубика.

или Что нужно вынести в клюве из высшего образования?

Вступление

На Хабре периодически появляются статьи о высшем образовании, вокруг которых вспыхивают споры о том, нужно ли человеку высшее образование как таковое. А что, если рассмотреть ВО не как существующую систему ВУЗов с их стандартами обучения, а как нечто иное?

Закон Украины «О высшем образовании» (думаю, законы остальных стран с ним более-менее согласны) определяет ВО как систему знаний, умений, навыков и личных качеств, необходимых для успешных занятий определенным видом интеллектуальной деятельности (ну, на самом деле, конечно, длиннее и муторнее, но суть примерно такова).

Оставим в стороне личные качества (ну не уроками этики же их развивать?). Ограничимся информационными технологиями как видом интеллектуальной деятельности (во-первых, эту область я знаю на собственном опыте, а не по догадкам и книгам, а во-вторых, для других областей некоторые постулаты могут быть неприменимы). Согласимся с тем, что знания и умения, нужные каждому человеку для работы, лучше всего приобретать собственно в процессе работы — особенно в IT, где актуальные технологии меняются достаточно быстро. Так какие же умения и навыки остаются в сухом остатке — чему должно учить ВО? Нет, не «учить учиться», хотя и этому тоже.

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

1. Читать

Читать-то я умею, но вот прочитанное в голове не задерживается
Л.Бэрфус «Сексуальные неврозы наших родителей»

(Окончание этих двух топиков — переводов эссе «Unmaintainable Code». В оставшихся главах автор часто обращается к уже описанным методам, удваивая и утраивая каждый из них; изложение сильно сокращено за счет исключения таких мест.)

Тестирование

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

Продолжение этого топика — вторая и третья главы эссе «Unmaintainable Code». Несколько перекликается с первой, но описанные методы уже не так очевидны (а некоторые отличаются поистине дьявольской изобретательностью и не меньшей злокозненностью). Ах да, с заявленного в прологе языка Java автор незаметно переключился на C/C++.

Камуфляж

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

Вольный перевод с сокращениями первой части эссе «Unmaintainable Code». Именование переменных — довольно банальная тема (хоть и забавно изложенная), но без этой части эссе было бы неполным.

Пролог

Это самое популярное из моих эссе. Удивительно, сколько людей не понимают, что это насмешка.

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

Не переусердствуйте: ваш код не должен выглядеть неподдерживаемым, а только быть таким, иначе он рискует подвергнуться рефакторингу или просто быть переписанным.

Месяц назад на Хабре был опубликован замечательный топик Нотубук в красках. В наше время ноутбук — не роскошь, а инструмент, мысль отличная, и загорелись ею многие, в том числе и я. Как ни странно, я нашла краски до того, как успела охладеть к этой идее, и отступать стало некуда. Здесь я расскажу о своем опыте раскрашивания ноута и покажу, что из этого получилось.

Статья без начала, в которой автор рассказывает о невыносимых типажах людей, с которыми он работал за последние 30 лет, с эпилогом переводчика

Я закончил колледж 30 лет назад. Моей первой работой была разработка испытательной аппаратуры для Univac. Это были бы замечательные времена, если бы не…

Грег Скрытный

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

Однажды я рассказал в общих чертах о проекте, которым я собирался заняться. Грег внимательно выслушал и сказал то же, что и обычно: ничего. Я провозился с реализацией неделю или две, пока не обнаружил, что мой подход в корне неверен. Я спросил об этом Грега, и он ответил, что для него это было очевидно с первого взгляда. Знаете, он ничего не сказал мне! Будь я его боссом, я бы его уволил.

(UPD. Перенесла в ХабраЮмор. Господа, не воспринимайте все так серьезно :-) )

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

Присылайте требования в файле Excel, а скриншоты ошибок — в Word

Разработчик — счастливый владелец рабочего компьютера образца 2005 года — получит массу удовольствия, пытаясь открыть мегабайтный файл, перекапывая все сто листов требований в поисках двух строк изменений и увеличивая масштаб просматриваемого файла, чтобы рассмотреть скриншот. Желательно также делать скриншоты максимально неинформативными, чтобы ваша приятная переписка подольше не заканчивалась. Еще можно творчески подойти к описанию проблемы, отображенной на скриншоте: лучше всего работает фраза «Посмотрите, пожалуйста!» (не забывайте смертельно обидеться на ответ «Посмотрели!»).

Задача вычисления первых двух десятков чисел Фибоначчи давно потеряла практическую ценность для программистов и используется преимущественно для иллюстрации базовых принципов программирования — рекурсии и итерации. Я же использую ее для демонстрации нескольких языков программирования, в которых она приобретает необычный и местами даже нездоровый вид.

Итак, мой рейтинг десяти наиболее противоестественных способов вычисления чисел Фибоначчи из написанных мной за последние полгода в рамках проекта Progopedia. Для уточнения задачи потребуем, чтобы выводом программы были первые 16 чисел в виде
1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987,…

10. Sanscript

Визуальный язык программирования, в котором все элементы языка представлены в виде элементарных блоков, из которых составляется собственно «код», именуемый диаграммой потоков (flowgram). Место в рейтинге этот язык заслужил размером диаграмм (два, ну три десятка элементов — максимум, который можно использовать на одной диаграмме без скроллинга и окончательного запутывания в связях между блоками) и неудобством использования ключевых структур языка (каждый цикл или условный переход требует для своего описания одной или нескольких отдельных диаграмм, которые мгновенно загромождают логику программы многоуровневой вложенностью и передачей глобальных переменных в виде параметров цикла). Ну, и собственно визуальностью — программа не пишется, а рисуется, и клавиатура как таковая используется только для ввода значений констант и (опционально) переименования элементарных блоков и написания комментариев.


Главная диаграмма потоков

Представьте себе: ваш племянник спрашивает у вас, сколько будет 2*2+1. Вам не до того, и вы переадресовываете вопрос своему интерпретатору, который честно отвечает: 6. Внимание, вопрос: благодаря какому языку программирования ваш племянник завтра получит двойку?