среда, 31 октября 2012 г.

Самые востребованные языки программирования

Очень интересная статистика от компании “HeadHunter”: http://habrahabr.ru/company/hh/blog/156803/ Анализируя её, могу вот еще что отметить.

Если посчитать соотношение запросов (по Москве) соискателей к запросам работодателей, то получается примерно такое:

Язык программирования

Соотношение запросов

php

2,2

java

3

c++

6

c#/.net

6,4

delphi

8,7

Просто феерический успех у php. Но и “классика жанра“- Java- очень хорошо смотрится. Посмотрите мою статью “Специализация” пятилетней давности- там я выделял Java, как наиболее подходящий для карьеры, зарабатывания денег язык. И, судя по статистике, это остается верным и на сегодняшний день.

Заметьте также, что остальные языки оказываются в 2 раза менее востребованными, чем лидеры: Java- коэф.= 3, а уже следующий C++ – коэф.= 6. Более того, если вы посмотрите вакансии по другим странам, то увидите, что и там Java наиболее востребован.

В общем, учите Java, и живите счастливо! Улыбка

пятница, 12 октября 2012 г.

Полный P&P

Пятого октября прошла конференция Microsoft Patterns and Practices Summit Russia 2012 для архитекторов программных систем и руководителей. Докладчики были из Редмонда, из группы “Patterns and Practices”, и из российского офиса компании.

Я сначала распланировал посещение секций так, чтобы по Windows 8 больше информации получить, но потом понял, что наши “евангелисты” от MS больше, чем я уже знаю, не скажут. Быстро переориентировался- и, вуаля- выудил кое-что полезное из выступлений.

Первое. Запомнилось (даже записал и хочу поиграться с этим) организация вложенных вызовов в линейную цепочку: start(a).then(b).then(c).done;. Вместо

if (a(b(c))) { done; },

где a, b, c- могут быть анонимные функции.

Это часто встречается в цепочках вычислений, где от успешности выполнения одной функции зависит выполнение последующих. Такая запись устраняет многоуровневую вложенность вызовов функций. А представьте, если это анонимные функции- это же кошмарный код получается! А предложенная запись улучшает читаемость кода.

Второе. В Window 8 в ресурсы приложения одну и ту же картинку можно будет записать с разным разрешением и размером. ОС сама будет вытаскивать и отображать ту из картинок, которая наиболее подходит для данного монитора (с учетом его размеров и разрешения).

Третье. Какую они удобную локализацию сделали- закачаешься! Может это и раньше было, я про это на конференции узнал. Просто создаете папочки вида “en-en”, “ru-ru” и т.д. и кладете туда файлы с ресурсами в которых пишите что-то вроде:

button1.name = …

button.width = …

button.font.style = …

Еще к этому верификацию прикрутить, чтобы проверять к каким текстам, заголовкам сделаны переводы, а к каким- нет, то вообще “бомба”.

Четвертое. Мысль вроде простая, но я нигде (Word, Visio, AutoCAD и т.д.) пока не видел реализации. Зачем на мелком масштабе пытаться отрисовывать маленькие элементы? Там же ничего уже не разглядеть. Куда эффективней заменять изображение более крупными информационными блоками с большими подписями. Ткнул в блок мышкой- масштаб увеличился, блок “раскрылся”.

И еще. Явно об этом нигде не говорится- народ только по форумам судачит. Но я лично на конференции почувствовал, что предпочтение отдается JavaScript. C# вроде как не задвигают, то существенно меньше о нем говорят. Неужто опять будет эпопея с очередной сменой мейнстримового языка? Так что я предупредил- а вы держите “ушки востро”. Подмигивающая рожица

Потом, конечно, Вы сами сможете посмотреть выступления на www.techdays.ru, но я вам скажу, что через экран монитора вы упустите “ауру” тусовки- на уровне эмоций, жестов очень многое передается. А это редко в кадр попадает, а если и попадает, то как-то “не ловится” мозгом. Ну, и приятно иногда взять докладчика “за пуговичку” и из “первых уст” получить информацию.

По организации конференции:

  1. Очень понравилось. Хорошо все продумано, четко сработано- ну, просто мастера.
  2. Для уровня архитекторов программных систем откровенно слабовато. Хотя, судя по уровню вопросов из зала, может это я слишком многого хочу.

пятница, 3 августа 2012 г.

Развернутый комментарий к статье “Где мы?”

Статья: http://trv-science.ru/2012/07/17/gde-my/

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

В мою бытность преподавателем в ВУЗе, где я работал, уже такой эксперимент был проведен. Ввели рейтинг, где публикациям отдали повышенный коэффициент. Думаете, публикаций стало больше? Да. Их стало больше. В цифрах на бумаге, а не реальных статьей. Все очень просто. Преподаватели стали договариваться друг с другом о соавторстве: я включу тебя в соавторы моей статьи, а ты меня включи в соавторы твоей статьи. В результате, нам обоим в зачет пойдёт по две публикации. Все в выигрыше. Норматив выполнен “на ровном месте”.

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

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

Поэтому, “выдыхай, бобер”, и спокойно “зри в корень”: надо отказаться от любых количественных показателей научной деятельности и уделить внимание качеству подготовки ученых, обеспечению им комфортной жизни и работы. Уверен, количественные показатели при этом сами окажутся где надо без каких-либо подгонок и усилий.

Да и с первоочередными мерами совершенно фантазировать не надо. Практически все статьи по данной проблеме говорят об одном и том же: достойная, высокая зарплата. Буквально, очень высокая. Ну, допустим, 50-70 тысяч долларов в год чистыми на руки всему преподавательскому составу для любого провинциального ВУЗа. Это первый шаг. Про остальные шаги и говорить не хочу, т.к. и этот первый шаг десятилетиями не делается.

На словах высокие чиновники говорят об увеличении финансирования, а на самом деле ВУЗы ходят сокращать. Без всякой конкурентной борьбы между ВУЗами, административными мерами объединить и/или закрыть. Чтобы уменьшить расходы на содержание. И все. Вот такая вам наука.

Полет мысли в золотой клетке компании

По мотивам статьи “Today is Goof Off at Work Day” у меня родилось несколько комментариев.

Сама статья об известной “фишке” ряда компаний, когда сотрудникам официально выделяется рабочее время для занятий чем угодно. В Google, например, это 20% рабочего времени (соответствует одному рабочему дню в неделю). В Facebook- это “Hack Day”. Из таких “занятий чему угодно” родились известные нам GMail, Google News, Google Talk, AdSense.

Идея выглядит симпатично:

  1. Компании такие “day off” могут записать себе в бенефиты, привлекательные для сотрудников.
  2. Для компаний это не прямые расходы, вполне себе могут позволить.
  3. Если идея хорошая, то у компании есть полные права на ее реализацию и раскрутку. Даже если идея не по профилю компании- тоже сгодится: бизнес диверсифицировать или красиво упаковать и продать реализацию идеи.
  4. Работнику хорошо, что мозги можно переключить с одной деятельности на другую. Эдакий активный отдых.
  5. Если идея сработает, то работник, наверняка, получит какие-либо бонусы (деньги, должность, репутация).
  6. Такие дни “вольного творчества” сродни стартапу. Только в стартапе риски выше. А тут вы ничем не рискуете- за ту же зарплату “стартапите”. Можно возразить, что компания заберет у вас идею, а вам премию в качестве подачки выпишут и все. Но это уже вопрос “синицы или журавля”.

Интересно, если эту идею сделать повсеместной, внедрить на большинстве предприятий, что получится: “вселенский” бардак или мир станет разнообразнее и интереснее?

пятница, 27 июля 2012 г.

Что почитать

Решил поделиться мнением о  том, что прочел в последнее время.

  1. “Совершенный код”, С. Макконелл. Книга хороша для программистов с опытом работы 1-2 года. Совсем уж начинающим программистам голову этим забивать не стоит- им надо научиться базовым вещам, а уж потом Макконелл. Опытным программистам книга по большей части будет бесполезна- перечисленные в ней приёмы программирования тривиальны и быстро осваиваются в первые годы программирования. Так что, если вы 1-2 года уже программируете- берите, читайте- много нового и интересного узнаете.
  2. “Психбольница в руках пациентов”, Алан Купер. Плохая книга. Может, проектировщикам она понятна и нравится, но программистам эта книга точно не нужна. Раздражительно много “воды”, набор тривиальных мыслей и ни одной методики решения перечисленных в книге проблем.
  3. Журнал MSDN Magazine. Да, в нем большинство статей о технологиях Microsoft. Но, кроме того, в каждом номере есть статьи, посвященные алгоритмам, тенденциям. Материал подается очень четко, без “воды”, профессионально, с хорошим переводом. Например, оцените такие статьи:
    1. Использование Windows Azure Service Bus для… вещей! Вместо Azure используйте любое другое облако. Оцените саму идею- подключение приборов в “облако”.
    2. Bacterial Foraging Optimization. Забавнейшая штука. И для кругозора полезно.
    3. Ant Colony Optimization. Муравьиный алгоритм.

среда, 30 мая 2012 г.

Про китайский backdoor, JTAG и военные секреты

Исходная новость, наделавшая немало шума: “Latest news on my Hardware Security Research.”

Её перевод на xakep.ru: “В военной микросхеме США китайского производства обнаружен бэкдор.”

Заметки эксперта в области безопасности об этой новости: “Bogus story: no Chinese backdoor in military chip.”

Перевод заметок эксперта на xakep.ru: “Подробности о китайском бэкдоре в чипе FPGA.”

Если перевод исходной новости сделан корректно, то перевод заметок изрядно запутан. Не буду пересказывать тут все “перлы” перевода, а просто перескажу своими словами, что имел ввиду эксперт. А вы уже сами сравните мои пояснения с “хакерским” переводом. Думаю, это заставит вас улыбнуться. Улыбка

Лет 7 назад я активно программировал однокристальные ЭВМ. Общий стаж в области схемотехники у меня примерно 10 лет. Последние годы я переключился исключительно на программирование, и стал уже забывать про все эти JTAG’и. Интересная исходная новость вызвала интерес у меня к теме. Я решил “тряхнуть стариной”. Итак.

  1. Микросхемы (м/с) могут делаться на заводе с тестировочными блоками. Однако, никого это волнует. После тестирования м/с эти контактные площадки никуда наружу не выводятся- 99,99% разработчиков, использующих эти м/с в своих разработках, об этом ничего и не знают. Чтобы добраться до них надо разрушить м/с.
  2. После тестирования, заключения м/с в корпус, ее продают разработчикам всяких телевизоров, плейеров, телефонов.
  3. Разработчик программирует м/с. Знаете, страшно неудобно, когда приходится постоянно доставать м/с с печатной платы, перепрошивать, потом снова вставлять, включать, убеждаться, что не работает, искать ошибку в программе, и по-новой перепрошивать. Так жили до JTAG’a. Интерфейс JTAG- это выводы на м/с, через которые можно подключиться напрямую к м/с и, не вытаскивая ее из печатной платы, перепрошивать. Более того, отлаживать код в м/с по шагам, смотреть значение ячеек памяти, регистров. Обалденная штука.
  4. После того, как программа для м/с написана, устройство (плейер, телевизор) доработано, его запускают в производство.
  5. Если код в м/с не представляет особой ценности, то контактные площадки, выведенные под интерфейс JTAG, можно так и оставить разведенным на печатной плате. Достаточно самого разъема для подключения не припаивать на плате к этим контактным площадкам.
  6. Т.е. хакерам достаточно припаять разъем и подключиться к м/с через JTAG- и вот перед нами все коды м/с! Можем отлаживать, перепрошивать- делать что хотим. Про этот способ взлома устройств и писал эксперт, когда говорил: “About 20% of home routers have a backdoor in them, and 50% of industrial control computers have a backdoor.”
  7. Но от этого можно защититься. После прошивки м/с по JTAG’у можно выставить биты защиты (залочить м/с). Биты защиты задают разные уровни доступа к м/с: полный доступ, только чтение, запрет на чтение, запрет на перепрошивку и т.д. Разработчики устройств часто пренебрегают установкой этих битов, что и дает шансы хакерам.
  8. Приведенная в качестве примера м/с ProASIC3- это флэш-память с функцией шифрования данных. Через JTAG вы можете в нее прошить AES-ключ, и она вам будет выдавать данные, зашифрованные этим ключём. Это используется для защиты данных при передаче их по каналам связи.
  9. Эксперт говорит, что проникая через “незакрытую дверцу” JTAG’a (когда не выставлены биты защиты), хакеры могут прочитать AES-ключ. Ну, и далее использовать сворованный AES-ключ для шифрования своих данных, и выдачи их, как за подлинные.
  10. А теперь улыбнитесь переводу с “хакера”: “С точки зрения производителя один из способов защититься от такого, не меняя дизайн микросхемы — это добавить криптографический ключ (обычно AES 128 бит), который отключает самые опасные из команд JTAG.”
    Никакой AES-ключ JTAG-команды не отключает!
  11. Далее, эксперт говорит про недокументированные функции JTAG, с помощью которых можно получить доступ к содержимому м/с, в том числе и при выставленных битах защиты. Признаюсь, что эта область для меня малознакома. Я могу только несколько замечаний сделать по этой теме.
    • Чтобы такие функции были, надо, чтобы производитель м/с умышленно разработал м/с с таким функционалом. Это время, деньги- просто так никакому производителю и даром не надо этой возни. JTAG- для программистов м/с, не для производителя. Какой смысл делать функционал, чтобы потом не сказать о нем программистам, а самим, втихаря, что-то делать через JTAG?
    • Занимаясь схемотехникой, я на форумах много раз читал обсуждения попыток взлома м/с с выставленными битами защиты. Обсуждений, ложных заявлений о взломе я начитался столь много, что теперь мало верю подобным слухам.
    • Даже если у JTAG есть недокументированный доступ, то, чтобы его получить, надо подключиться непосредственно к м/с. Т.е. удаленно ничего не взломать, не вывести устройство из строя, что и пишет эксперт: "The Chinese might subvert FPGAs so that they could later steal intellectual-property written to the chips, but the idea they went through all this to attack the US military is pretty fanciful.”

И главное, вот что сам Скоробогатов сказал о своей работе:  “There was a lot of rumour on the Internet and in various blogs claiming that we found that 'Chinese manufacturers putting backdoors in American chips'. This is not true as anyone can see drafts of our papers which we had to release yesterday to clear the issue with being accused of making false claims. It is the US manufacturer Actel who inserted the backdoor at the gates level of JTAG controller in ProASIC3, Igloo, Fusion and SmartFusion devices. Moreover, the traces of the backdoor can be found in the development software Libero through simple Windows XP Search for particular bits in standard STAPL file. With the backdoor key you can extract the IP (FROM, ARRAY/bitstream, NVM/NFMB) or even reprogram the factory backdoor key and make your own key.
We never said the Chinese have put a backdoor inside Actel's chips and it does not say so in our papers. It is as though people have put 2+2 together and made 4 or 5 or 6 depending on what their agenda is. We believe that other chips will have backdoors and since a US chip has them and you can do lots of things that give you a vast amount of control over the devices then is there any reason to suggest other manufacturers have not done the same. The US military have been looking at the issues of hardware assurance and part authenticity for a good number of years.
Also that fact that since it is possible now to scan for backdoors in a way that was not possible before, people will start to take a look at this area whether to use it to remove IP or to use it for other purposes.”

В общем:

  1. Целью ученого была разработка метода- никого он ни в чём не обвинял.
  2. Эксперт сказал, что и без хитроумных закладок и “бэкдоров” большая часть техники взламывается “на раз”, т.к. программисты микроконтроллеров не выставляют, как минимум, биты защиты.
  3. А “хакер” в своем переводе все здорово перемешал, и я бы не сказал, что наврал- скорее всего в теме не разобрался или пал жертвой “желтой” прессы.

воскресенье, 27 мая 2012 г.

Будь в тренде!

Очень интересный документ от IBM недавно я нашел и изучил: “Global Technology Outlook 2011”. Известный факт: IBMовские прогнозы не раз сбывались. Этот прогноз меня заинтересовал тем, что он во многом пересекается с моими ощущениями по отрасли.

Социальные сети + Бизнес (Enterprise)

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

В этом свете очень интересна экспериментальная социальная сеть от Microsoft. Ее принцип действия: делается поиск нужной информации, и тут же можно найденное опубликовать у себя в ленте и дать к ссылке комментарий. Похоже, MS изучает возможность влияния соц. сети на результаты поиска.

До этого Google пыталась запустить новый поисковый алгоритм, рассчитывающий релевантность ссылки по ее популярности в соц.сетях.

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

Увеличение объемов обрабатываемой информации

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

В этой связи ожидается большой спрос на DaaS (Data-as-a-Service), AaaS (Analytics-as-a-Service). Подозреваю, что на этом рынке могут “играть” только крупные игроки. Тем не менее, у небольших стартапов есть шанс разработать/оптимизировать процесс обработки данных и продать разработку “крупняку”.

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

Логика приводится “железная”. Но я в этой области не “спец”, чтобы комментировать. Почитайте и подумайте сами.

Интернет вещей

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

Возможностей, конечно, тут открывается немало. Но тема настолько вялая, что, я не верю, что в ближайшее десятилетие она “выстрелит”. Хотя, конечно, всей душой за более быстрое развитие этой темы.

Обучающиеся системы

Ну, кто бы сомневался! Это очевидный, сильный тренд, довольно таки “старый” уже. Если тему “обучающиеся системы” скрестить с темой “Социальные сети + Бизнес (Enterprise)” (работа с неупорядоченными данными), то получим взрывное (для мозга) направление работы.

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

Итоги

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

В IBMовском прогнозе отражается, в первую очередь, взгляд IBM на ИТ. Если обобщить, то это суперкомпьютеры, огромные объемы данных- в общем, что-то мощное и большое- чисто по-IBM’овски.

Если вы не IBM’еры, то можно порекомендовать заниматься:

  1. Отдельными элементами систем, предназначенных для обработки разнородной информации (структурированной, не структурированной, видео, аудио, фото).
  2. Узкоспециализированными алгоритмами для обучающихся систем.

Это могут быть алгоритмы сортировки, распараллеливания вычислений, извлечения ключевых слов, понимание контекста, распознавание образов и т.п. Очень хорошие, интересные, перспективные темы. Дерзайте!

среда, 16 мая 2012 г.

Предчувствие

«Ростелеком», Microsoft и «1С» представили первую услугу, доступную на национальной облачной платформе, – «O7.Бизнес»

За формальным заголовком скрывается важная тенденция. В область автоматизации бизнес-процессов все больше "крупняка" втягивается. Появились и устойчиво развиваются последние 5 лет новые компании в этой области. Предлагаются все более мощные решения. Есть ощущение, что тут будут "далеко идущие" последствия. Как будто бы в этой области подошли к некоей критической точке, после которой будет прорыв в этом направлении.

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

В ближайшие несколько лет что-то тут будет прорывное- это моё предчувствие. Обратите внимание! Активное шевеление- это факт. А выводы вы можете сделать свои.

пятница, 4 мая 2012 г.

Длинный нос инноваций

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

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

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

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

4. Если проследить за тем, как технология развивалась, то можно увидеть влияние на нее других проектов и идей.

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

Длинный нос

1. Проходит около 20 лет прежде, чем новая технология сможет принести миллиард долларов. Большую часть времени эта технология не находится в центре внимания большинства людей.

2. В любом случае, чтобы снять с рынка миллиард долларов в течение 5 лет необходимо около 15 лет «холить и лелеять» технологию. Это означает, что мы можем предсказать, когда технология начнет широко использоваться.

3. В технологию никто не будет верить, до тех пор, пока она «вдруг» получит широкое признание.

4. Первые мультитач-экраны появились в 1984 году, но получили распространение только в 2007. Все это время они развивались вне поля зрения массового потребителя.

5. Например, первую мышку с колесиком Xerox запатентовала в 1973 году. Но до этого ее уже изобрел и продавал 1968 году Райнер Малебрайн. Он не запатентовал ее, т.к. считал это изобретение тривиальным, чем-то, что мог придумать любой.

6. Другой пример. Первые iPod’ы (с колесиком) во многом позаимствовали форму/дизайн от радиоприемника T3, выпущенного Рамсом в 1958 году. В то же время, Рамс был вдохновлен идеями, заложенными в радиоприемник TR-1, который изобрели трое изобретателей в 1954 году.

7. Еще один пример. Серийный карманный фотоаппарат Кодак продавал в 1926 году. Предлагалось несколько цветовых вариантов корпуса. Apple повторила тот же трюк со своим белым iPod’ом.

Больше, чем просто идея

1. Патенты в области идей работают плохо.

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

3. Творчество - это процесс придания очевидности неочевидным вещам.

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

5. Лучшие изобретатели занимаются тем, что вытаскивают на «свет божий» старые идеи и «причесывают» их в соответствии с современными тенденциями. Своему успеху они обязаны своим предшественникам.

6. Обычно мы думаем об изобретательстве, как о некоей алхимии «делания золота из ничего». Однако, это больше похоже на разведку месторождения золота. Многие предпочитают исследовать местность в поисках золота. Кроме этого, вам потребуются навыки его выкапывания и переплавки. Просто найти месторождение золота недостаточно.

7. На сегодняшний день недостаточно сделать что-то, что просто работает, как это было раньше.

8. Мы должны как-то «подать» эту вещь потребителю. Продолжая аналогию с золотом, золото приобретает дополнительную ценность, если сделать из него ювелирное украшение.

9. Изобретение – это выбор. Нужно решить, так или иначе, выбрать то, или другое. Эскизы используют именно для этого.

10. Ремесло требует практики.

11. Процесс синтеза - это часть эскизного наброска. Другая составляющая – это отбор. Эти процессы параллельны.

12. Чем лучше вы знаете историю, тем больше вы готовы к завтрашнему дню.

13. Много лет назад Casio продал наручные часы за 90 доллара. Они были с тачскрином, и ими можно было пользоваться как калькулятором. Насколько хороша была эта технология в 1984 году? Насколько продвинулся прогресс?

14. Если вы меняете часть любого продукта, то, не забудьте, пересмотреть и адаптировать остальные его части. Например, ПДУ ТВ заставил ТВ станции синхронизировать рекламу.

пятница, 16 марта 2012 г.

Советы программистам-новичкам. Настройка на работу

Как я уже ранее говорил, в работе программиста есть творческая часть. Это приводит к некоторой проблеме. Например, слесарь может точить детали хоть трезвый, хоть “с бодуна”- руки-то “помнят” и “на автомате” будут строгать детали. С творчеством так не бывает- муза капризна и когда “накроет” не угадаешь. А работать-то надо. Одна из черт профи- стабильная работоспособность.

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

четверг, 15 марта 2012 г.

Советы программистам-новичкам. Не твое- не трогай!

Есть такой старый армейский принцип: “Не твое- не трогай.” Этот принцип верен и в отношении программирования в команде. Делай свой кусок работы, и не меняй что-либо в чужом коде. В чем смысл данного правила?

Например, вы поменяли, буквально, чуточку в чужом коде, т.к. заметили в нём ошибку (на ваш взгляд ошибку). Проверили тут же- работает. Выложили код. И тут оказывается, что старик Мерфи прав. Ту части кода, которую вы “осознали” и подумали, что это ошибка, вы-то исправили. А вот оказывается, что ваше исправление поломало функционал в куче других мест, о которых вы и не подозревали.

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

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

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

“Не твое- не трогай!”

среда, 14 марта 2012 г.

Советы программистам-новичкам. Не умничай

Это распространено не только в среде программистов- от любого мастера (парикмахера, сантехника, строителя) можно услышать фразу: “Да кто же так делает! Это все неправильно…” В отношении программистов эта фраза дополняется восклицанием: “Это все надо переписать! Я сейчас это сделаю.”

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

Если на ваш ПЕРВЫЙ взгляд вам кажется, что можно было сделать проще/лучше, то помните:

  1. Код был написан, скорее всего, несколько лет назад. Для программирования- это не малый срок:
    • Может быть, в те времена было так принято писать.
    • Не было такого API, которым можно было бы сделать все проще.
    • Не было такого синтаксиса, позволяющего выразить мысль компактнее.
  2. Вы не знаете обстоятельств, которые сопутствовали его написанию:
    • Просили сделать очень быстро- лишь бы работало.
    • Хотели посмотреть “на попробовать” как будет и нужен был набросок. А потом возникли другие обстоятельства и про код забыли.
    • Изначально было сделано хорошо, а потом код многократно изменялся разными программистами, проповедующими различные подходы к написанию кода, которые еще своего там намешали.
  3. Личные обстоятельства:
    • Программист увольнялся- ему было “пофигу”.
    • Не дали премию, мало заплатили.

Ну и, конечно, остаются варианты, относящиеся напрямую к исходной фразе: “Да кто же так делает!”:

  1. Мало предлагали денег по вакансии и на работу наняли слабого программиста.
  2. Наняли по блату.
  3. Наняли умного парня, но большого любителя поэкспериментировать.

Поэтому, не умничайте, а лучше вдумайтесь, почему сделано именно так, а не иначе. Скорее всего, потом Вы заметите, что все не так уж плохо, и код лучше не трогать.

вторник, 13 марта 2012 г.

Советы программистам-новичкам. Инструменты

Очень простой совет: используйте лучшие инструменты. Хорошего мастера всегда можно определить по его инструментам. Как у классного плотника будет хорошая фирменная пила, у опытного монтажника- перфоратор “мохита”, так и у хорошего программиста должен быть отличный инструментарий.

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

Распространите этот принцип на все ваше рабочее место:

  1. Хороший компьютер, монитор (а лучше два), удобная мышь и клавиатура.
  2. Настройте автоматическое резервирование (потерять время на переустановку системы из-за полетевшего диска- это дорогое удовольствие, дешевле стоит внешний диск для резервирования).
  3. Удобный трекер, быстрый репозиторий, хорошую “мержалку” бранчей.
  4. При программировании используйте хорошие библиотеки, системы сборки.

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

Не берите тот инструмент, который проще всего достать, который под рукой- ищите лучший. Простой пример: MS XML есть в каждой ОС, и, поэтому, его очень просто начать использовать. А если померять скорость работы этой библиотеки, то обнаружите, что она примерно в два раза медленней работает большинства других библиотек. Может для простых “конфигов” это и не важно, но если надо читать файлы в несколько мегабайт, то здорово с MS XML намучаетесь.

понедельник, 12 марта 2012 г.

Советы программистам-новичкам. Творчество и рутина

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

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

  1. Вписать ваш прототип в существующую архитектуру приложения (рефакторинг в несколько итераций).
  2. “Дожать” все проявляющиеся баги.
  3. Сделать удобный UI.
  4. Расставить комментарии (допустимо и просто хорошо продумать названия функций, переменных).
  5. Отдать это пользователям- они еще “наваляют” 20-30 багов и пожеланий по интерфейсу.
  6. Исправить баги (“заплаток” не делать!).
  7. Повторить п.5,6 еще пару раз.

Справится с заданием в его творческой части и остановится на этом (тут еще пренебрежительно говорят: “А, далее уже мелочи!”) означает НЕ выполнить задание. Это означает, что каким бы творческим программистом вы ни были, в первую очередь вы- ХРЕНОВЫЙ программист. И это главное.

Присмотритесь- “творцов” среди программистов “пруд пруди”. А вот профессионалов мало. Воспитывайте в себе профи. Заставляйте себя тщательно копаться в багах, аккуратно размещать элементы UI на форме, комментировать код. Да- это рутина, да- это не интересно. Но без этого вы- ХРЕНОВЫЙ программист.

воскресенье, 11 марта 2012 г.

Советы программистам-новичкам. Цена “заплатки”

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

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

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

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

Еще раз подумайте: цена заплатки- ваша репутация.