[comp] А Unix уже 40!

Помню, с какой калейдоскопической быстротой все менялось в начале 90-х, когда я только начинал заниматься программированием. В течении 5-ти лет (с 90-го по 95-й) довелось осваивать Бейсик на БК-1001, Turbo Pascal 3.0 на Pobotron 1715, Turbo Pascal 5.0 на IBM PC, Assembler x86, Assember IBM 360, Turbo C 2.0, Turbo C++ 1.0, Borland C++ 2.0, Windows 3.0, Borland C++ 3.1, OS/2 3.0, FoxBase и FoxPro (версий уже не помню), Prolog, Borland C++ 4.0, Windows 3.11, Win32s, Windows 95, WinNT 3.5, Win32, первые статьи об STL и Java… А вокруг! Канул в лету СССР, появилась независимая Республика Беларусь, сменили деньги, сумма стипендий выросла до миллионных показателей… Казалось, что даже вокруг программирования не может быть ничего длительного. А уж в программировании и подавно – технологии менялись раз в три года, а то и быстрее.

Но в 95-м я занялся программированием всерьез. Что заставило снять и выкинуть розовые очки. Хорошо помню какой-то свой спор с фанатичным Pascal-истом в 99-м году. Он как пытался меня убедить в скорости изменений в области ИТ. Моим же аргументом были возраст различных языков и платформ. SQL-ю на тот момент было где-то лет 13 (если отталкиваться от SQL-86), языку C – 27, языкам C++ и ObjectPascal – лет по 15. Даже платформе Windows (начиная с 16-ти битовых версий) – больше десяти лет. А уж Unix-у… Unix-у тогда был тридцатник.

И вот сейчас Unix-у 40 лет! Страшно подумать. Да и остальные герои (SQL, C, C++, Windows) тоже здесь. И тоже постарели лет на десять. И даже совсем юная в те годы Java, уже стоит на пороге своего 15-тилетия, и даже C# собирается разменять второй десяток. Все те же, все там же.

Интересная все-таки штука – ИТ. Вроде как все постоянно меняется, все время что-то всплываетвозникает, все время что-то заявляет о себе, все время нагнетаетсячувствуется ожидание какого-то прорыва. Вот сейчас, вот уже совсем скоро, вот-вот не долго уже осталось… А Unix-у уже 40! А потом будет и 50. И, очень возможно, и 60. Что хорошо.

С днем рождения Unix! Long Live Rock-n-Roll!

PS. Приношу свои извинения за то, что не упомянул дедушек Fortran и Lisp. Поскольку для меня они не представляют даже академического интереса :) Но я с почтением отношусь к их возрасту.

[comp.bugs] Интересный ресурс: The Risks Digest

Вот: Forum On Risks To The Public In Computers And Related Systems.

Например, выпуск этого дайжеста от 15 августа 2009. Цитата:

UK national ID card cloned in 12 minutes
The prospective national ID card was broken and cloned in 12 minutes.  The
*Daily Mail* hired computer expert Adam Laurie to test the security that
protects the information embedded in the chip on the card.  Using a Nokia
mobile phone and a laptop computer, Laurie was able to copy the data on a
card that is being issued to foreign nationals in minutes.  He then created
a cloned card, and with help from another technology expert, changed all the
data on the new card. This included the physical details of the bearer,
name, fingerprints and other information.  He then rewrote data on the card,
reversing the bearer's status from "not entitled to benefits" to "entitled
to benefits".  He then added fresh content that would be visible to any
police officer or security official who scanned the card, saying, "I am a
terrorist - shoot on sight."

[comp; life] Как узкому специалисту удачно продать себя?

Представьте себе, что вы “узкий” специалист – сильно увлеченный какой-то специфической областью классный программист. Например, вы занимаетесь компиляторами, графическими движками для CAD систем, распределенными БД для исторических данных, lock-free алгоритмами и т.д. И вы хотите удачно продать себя. Т.е. обеспечить себе (очень) хороший заработок и получить возможность дальше заниматься любимым делом. И задаетесь вопросом: “Как это сделать?”

К сожалению, ответа у меня нет. Я не смог найти его лет десять назад для самого себя, хотя и хотелось, чтобы мои наработки в области самописной объектной СУБД не пропали даром. Поэтому ниже следуют рассуждения на тему, в которой я не разбираюсь.

Под “продать” понимается несколько вариантов. Например, можно устроиться на хорошую оплачиваемую работу и работать над созданием чужих продуктов (т.е. продать себя, по сути). Можно продавать услуги (консультант продает свое время решая проблемы заказчика или обучая заказчика). Можно создать собственный продукт и продавать его.

Итак, мне кажется, что продать можно либо продукт, либо бренд.

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

В чем здесь закавыка? Поскольку мы считаем себя классными специалистами, техническая часть разработки продукта не должна составлять для нас проблем. Хотя бы в теории, поскольку на практике проблемы обязательно будут. Поэтому наибольшие проблемы для нас представляют: идея продукта и его продвижение на рынок. И если по поводу продажи продукта еще можно что-то почитать, куда-то посмотреть и у кого-то спросить, то вот с идеей дело швах… Она либо есть, либо ее нет.

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

Теперь поговорим о брендах. Брендом должны стать мы сами. Т.е. мы должны продавать самих себя за счет своей репутации, а наше имя должно быть сильно на слуху (хотя бы в узких кругах). За счет чего это можно сделать? Либо за счет продукта-бомбы, либо за счет публикаций. Продукт-бомба (что-то новое, что меняет отношение людей к чему-то, вроде WinAmp-а или BitTorrent-а) – это очень похоже, на то, что уже обсуждалось выше. Нужна идея. И не просто идея. А супер-пупер идея.

Блин, тут какое-то логическое противоречие. Если у нас есть супер-пупер идея, и есть основанный на ней продукт, то зачем нам превращать свое имя в бренд? Лучше сосредоточиться на развитии продукта. Получается, чтобы наше имя стало брендом, нам нужна супер-пупер идея и продукт, которые принесут нам знаменитость, но не принесут достаточного количества денег. Лично я бы супер-пупер продукту без прибыли предпочел бы безыдейный продукт с прибылью…

Но не все так плохо. Можно получить себе имя на продукте, который формально будет принадлежать не нам. Томпсон не был владельцем Unix-а, Керниган и Ричи не были владельцами C, Страуструп – владельцем C++, Хейлсберг – владельцем Delphi и C#, Гослинг – владельцем Java. Но нужно заметить, что из вышеперечисленных только Хейлсберг был взят на работу как узкий специалист по разработке языков программирования (опять же за счет собственного продукта). Остальные стали “случайными” изобретателями и до создания своих знаменитых детищ, они были узкими специалистами в других областях (если мне не изменяет мой склероз).

Значит, нужно рассматривать вариант с супер-пупер публикациями. Тут дело, вроде бы, выглядит получше. Как кто-то хорошо сказал (кажется это был Стив Эгг) – самые знаменитые программисты знамениты не своим программами, а своими книгами. Вот, например, что написал Андрей Александреску? Книгу “Modern C++ Design” и кучу статей, ну и еще библиотеку Loki для C++ и часть стандартной библиотеки для D 2.0. А что еще? Вот в том-то и дело.

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

---

Пора подводить итог.

Какое слово я употреблял выше чаще всего? Думаю, что слово “идея”.  Это и есть ключевой момент. Нужно придумать, что будет продаваться. Что-то нужное потребителю. Не наши знания, не наши способности. Поскольку покупатели не знают, что с этим делать. Поэтому следует дать им то, что им знакомо.

Книгу о том, как можно делать что-то более быстро, качественно и дешево, чем раньше.

Консультации, которые позволят решать проблемы клиентов быстрее, качественнее и дешевле, чем раньше.

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

Как же все просто на словах. Аж жуть берет.

---

PS. Данная заметка возникла в результате чтения обсуждения вопроса Дмитрия Вьюкова на RSDN: “Есть ли спрос на multithreading/concurrency/synchronization?”
И у меня есть просьба к читателям моего блога. Пожалуйста, уделите этому вопросу несколько минут вашего времени. Может вы нуждаетесь или не нуждаетесь в специалисте по multithreading/concurrency? Может вы сталкивались с проблемами в старых многопоточных программах, которые требовалось быстро найти и устранить, а это не получалось? Может вы пытаетесь использовать какую-то стороннюю библиотеку для многопоточности (Intel TBB, Cilk++ и пр.), но это плохо получается из-за отсутствия специалистов, к которым можно обратиться за помощью? Может вы устали искать какой-то специфический инструмент для задействования мощностей multicore процессоров в ваших задачах? Может вы не встречали толковых книг по современной многопоточности, многоядерности и средствам синхронизации? Может вы хотели бы посетить курсы по этой теме? Скажите Диме об этом.

[comp.prog.concurrency] Презентация “Diving Down the Concurrency Rabbit Hole”

Большая (212 слайдов) презентация Diving Down the Concurrency Rabbit Hole от Mike Acton.

Большая часть интересная. Хотя оформление самой презентации корявое – нужно было либо все делать фотографиями, либо же все писать нормально. А так чередование нормального текста и фотографий “липких листочков” с рукописными фразами (часто вне фокуса) воспринимается как издевательство.

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

[comp.prog] Должны ли соискатели писать код на интервью?

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

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

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

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

• для соискателя собеседование – это стресс. Написание кода в таких условиях – это олимпиадный подход. По собственному опыту могу сказать, что далеко не все люди способны делать что-нибудь разумное в таких условиях. Так что, если вам нужен экстремал, который за 5 минут в три часа ночи через dial-up способен найти и устранить баг в 24x7 системе на другом конце света, то это может быть оправдано. Но тогда есть шанс упустить менее расторопного претендента, в программах которого такие сбои не будут возникать вообще;
• несоответствие масштабов. Вряд ли вы ищете разработчика, которому предстоит писать программки объемом 50-100 строк (и все они будут разными вариантами QuickSort). Скорее вы ищете человека которому предстоит выдавать по 50, ну максимум, по 150 отлаженных строк в день. Лично я не уверен в том, что способность быстро написать маленькую программку является доказательством способности спокойно и тщательно разрабатывать большую программу. Скорее, я уже уверен в обратном. Гораздо больше доверия у меня сейчас вызывает человек, который 20 минут будет обдумывать задачу, чем который за эти же 20 минут набросает ее решение;
• слишком много допущений. Когда вы даете соискателю задание за 20 минут написать небольшую программку, ожидаете ли вы, что он сделает это идеально? Думаю, что вряд ли. Поэтому в оценке наспех написанного кода будет неизбежно присутствовать некая дельта качества. И я думаю, что эта дельта может привести к ошибочным выводам относительно соискателя.

Для меня вышеперечисленные причины являются достаточными для того, чтобы отказаться от программирования на интервью. Но ведь способность соискателя к написанию кода как-то проверять нужно? Обязательно нужно. Но делать это следуют по другому. Сейчас наиболее адекватным способом мне кажется выдача соискателю небольшой задачи накануне интервью (небольшая – это с решением в 200-500 строк). С тем, чтобы решение он прислал перед интервью (это нужно для того, чтобы у вас было время проверить и оценить полученное решение). Почему такой способ лучше?

• человек решает задачу в комфортных для себя условиях. Поэтому, если он написал откровенную фигню, то оправдания “стрессовые условия”, “не было привычной мне IDE”, “не было времени подумать” и пр., идут лесом вместе с самим соискателем;
• вы видите более-менее реальное качество кода, которое способен выдавать человек. Поэтому, если в присланном решении вы найдете корявый стиль, отсутствие комментариев или другие проблемы, можете твердо быть уверены в том, что в лучшую сторону ничего уже не изменится;
• если человек задает вам наводящие вопросы относительно полученной задачи (а задача должна быть такой, чтобы вопросы задавались), вы получаете информацию об “адекватности” и “вменяемости” соискателя. Ведь с очень большой долей вероятности аналогичными вопросами он будет засыпать вас и после приема на работу. Поэтому, если вам встретиться человек, который будет консультироваться с вами по каждой строчке кода, то у вас будет возможность отправить его лесом еще до собеседования;
• вместе с кодом решения человек должен прислать и наборы тестовых данных, на которых он проверял свое решение. Эти наборы очень много расскажут вам о том, насколько качество программы важно для соискателя и как много он готов платить за это качество;
• не менее важную информацию об обязательности и ответственности соискателя вы получите от самого времени получения решения. Поскольку вы можете договориться об отсылке решения до 12:00, а соискатель пришлет вам его в 15:00, за пятнадцать минут до собеседования. И даже не объяснит, почему он не смог сделать этого до 12:00.

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

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

А самый главный недостаток такого подхода в том, что он требует гораздо больше усилий от вас. Ведь задачу нужно придумать. Ее нужно самому решить. Нужно составить ее хорошее описание (с тем, чтобы минимизировать количество “глупых” вопросов, которые неизбежно будут задаваться). Затем, нужно за короткое время проанализировать и полученное решение, и тестовые данные. В общем, вкладывать придется гораздо больше собственных сил, чем в случае с маленьким заданием на собеседовании.

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

[comp.prog] Приобщаюсь к классикам: throwing away 1000 lines of code :)

One of my most productive days was throwing away 1000 lines of code.
Ken Tompson

Сегодня выбросил из проекта почти 18K строк (физических строк, включая пустые и комментарии).

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

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

Но сам факт выбрасывания 18K строк примечателен. Не каждый день (да и не каждый год) такое происходит :)

[life] Смена часов

К наручным часам лично я сильно привязываюсь. Ношу наручные часы лет с 10 и чувствую себя очень неуютно, когда их нет. Свои последние часы, Casio W-741:

я купил в 1996-м. С тех пор они пережили вместе со мной пару небольших туристических походов, множество командировок, и даже штук пять переездов и почти двухлетний ремонт квартиры.

Часы были отличные. Практически не убиваемые. Батарею менял, наверное, раз в 5-6 лет (если бы я не использовал ежечасный звуковой сигнал, срок жизни батарей мог бы быть еще больше).

Решил сменить их, в основном, из-за ремешка. “Родной”, пластиковый ремешок приказал долго жить довольно быстро – года через три после покупки. Несколько лет я носил их с металлическим браслетом, но когда пришел и его срок, то перешел на кожаные ремешки. С которыми просто беда. Дешевые изнашиваются за 4-6 месяцев, более дорогие – где-то за год. Потом нужно искать новый, что не просто, т.к. ремешки нужной ширины редко встречаются в часовых лавочках.

В общем, после того, как медным тазом накрылся очередной ремешок, я решил, что пора купить себе новые часы. Тем более, что в старых перестал работать звуковой сигнал. И вот тут меня постигло серьезное разочарование. Выбирать-то особенно и не из чего. В стороне можно оставить проблему выбора чего-либо в Гомеле (это вообще особая песТня). Но я прошелся по сайту www.clockshop.ru и не смог найти ничего достойного на замену даже там.

Что я искал? Электронные часы (принципиально без стрелок) “классического” дизайна. В металлическом корпусе, с металлическим браслетом, с устойчивым к царапинам стеклом, с 100m water resist (плавать с аквалангом мне не нужно, но хотелось бы, чтобы часы без проблем выдерживали купание). Каких-то “навороченных” возможностей типа записной книжки, калькулятора, поддержки нескольких часовых поясов или виброзвонка мне не нужно. Более важна неубиваемость. Но ничего подходящего не нашлось (лучший вариант, наверное, вот этот, хоть и в пластиковом корпусе). Всяких G-Shock-ов полно, но не хочется таскать на руке здоровенную бандуру, тем более, что я веду вовсе не активный образ жизни. А вот что-то консервативное, без изысков и закоса под спортивность…

Так вот интересно, а есть ли в природе вообще такое?

В итоге, пока приобрел себе вот такие (Casio W-96H):

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

[comp.prog.testing] Некоторые принципы тестирования программ от Бертранда Мейера

Озвучены в этой статье. И, в кратце, процитированны здесь:

Principle 1: Definition
To test a program is to try to make it fail.

Principle 2: Tests versus specs
Tests are no substitute for specifications.

Principle 3: Regression testing
Any failed execution must yield a test case, to remain a permanent part of the project's test suite.

Principle 4: Applying oracles
Determining success or failure of tests must be an automatic process.

Principle 5: Manual and automatic test cases
An effective testing process must include both manually and automatically produced test cases.

Principle 6: Empirical assessment of testing strategies
Evaluate any testing strategy, however attractive in principle, through objective assessment using explicit criteria in a reproducible testing process.

Principle 7: Assessment criteria
A testing strategy's most important property is the number of faults it uncovers as a function of time.

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

I did not address psychology. Does effective testing imply confrontation? I am writing this while on a plane; whether the flight software's tester hurt the programmer's feelings worries me less, right now, than whether he exercised best efforts to uncover deficiencies. (Actually, the informational display has been stuck for the past hour at 958 km from our starting point-I hope critical systems were tested more confrontationally.)

[life] Жизнь за окном: вранье на ровном месте

Помню в детстве у меня состоялся серьезный разговор с отцом о том, почему нельзя врать. Хочется верить, что своей дочери я смогу объяснить это не хуже, чем получилось у моего отца. Не то, чтобы я сам никогда не врал – случается, но это всегда происходит “через силу”. А уж если я ловлю кого-то на неправде, то доверия к этому человеку у меня уже никогда не будет. Равно как и уважения.

Еще можно понять причины, которые стоят за “большой ложью”. Как во время учебы: “Ну как продвигается твой курсовой? Через неделю защита, не забыл?” -- “Да он уже почти написан, осталось только отчет оформить!” ;) Хотя сама работа над курсовым только завтра или послезавтра начнется.

Ну тут понятно, тут ставки кажутся высокими. А вот сегодня в маршрутке я наблюдал за враньем, смысл которого я не могу понять вообще. На конечной остановке вместе со мной в маршрутку садится парень, который по телефону начинает кому-то объяснять, что он вот-вот уже подъедет на встречу. “Я уже на ЗИП-е, через пять минут буду у тебя!” – говорит. Хотя до ЗИП-а (остановка такая) еще, как минимум, десять минут езды, при отсутствии пробок на мосту, что чуть ли не каждый день происходит.

Я уже после этих слов стал думать – ну и зачем ему было так говорить? Но то, что произошло потом, было еще круче. Как и следовало ожидать, минут через 15-ть мы проезжаем ЗИП, и этот парень опять звонит своему знакомому и говорит: “Я тебя на остановке не наблюдаю! Ты где? Прошу, подойди на остановку, я тебя жду!”.

Вот это классно! Сам едет в маршрутке, до ближайшей остановки еще пару минут езды, а он утверждает, что никого там не видит. Высший пилотаж, имхо. На следующей после ЗИП-а остановке вышел я. Он поехал дальше. Так я и не узнал, до какой остановки он ехал…