Monthly Archives: May 2011

Работа в потоке и спин-блокировки

Когда что-то разрабатываешь, кодишь и вошел в в поток, то могут возникать ситуации, что установка какого-то ПО или работа чего-то занимает 3-5 минут…. Нужно подождать.

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

И вот тут-то и получается самое интересное. Когда начинаешь возвращаться к работе после паузы, то ты уже не в потоке…. и нужно потратить еще минут 15, точное время зависит от человека.

И что-же тогда делать? Получается, что все таки наиболее эффективно…. – это тупо смотреть в монитор…

Очень четко прослеживается аналогия c многопоточным программированием. Если потоку нужно долго ждать, то он засыпает, если не долго – то более эффективно использовать спинблокировки – тупо убивать процессорное время, потому как переключение контекста гораздо дороже, то же самое, что втыкать в монитор.

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

В завершение хочу привести пример, который недавно наблюдал и, в отличии от разработки ПО, в нем можно все измерить.
В супермаркетах на кассах обычно продавцы долго ждут, пока покупатели ищут деньги. Так вот в одном маркете я увидел, как поставили ПО, которое позволяло начинать обслуживать следующего покупателя, пока предыдущий искал деньги.
Меня это очень поразило – как просто на ровном месте можно больше зарабатывать! … но через пару месяцев в том же маркете на кассах продавцы опять спокойно ждали, пока покупатели ищут деньги. Я не знаю точно, почему отказались от параллельной обработки. Возможно, не смотря на отсутствие простоя, сама скорость уменьшилась. Возможно повысилось количество ошибок, обработка которых требует времени. … но в итоге очевидно – раз отказались от “частого переключения потоков”, значит это того стоит, не смотря на появившийся простой.

Анонс. 26 мая (четверг). Как создать образ лидера? Для тех, кто уже руководитель и для тех, кто только планирует руководителем стать.

26 мая (четверг) состоится очередная встреча управляющих ЛЮДЬМИ в IT компаниях.
 
«Как создать образ лидера? Для тех, кто уже руководитель и для тех, кто только планирует руководителем стать.»

 

На встрече будут выступать действующий проджект-менеджер из Харькова Володя Железняк и его компаньон, профессиональный психолог – Дмитрий Снисарь. На встрече будут проигрываться и практиковаться в навыках поведения действительного лидера команды.
Будут рассмотрены практические способы, которыми люди повышают и понижают свой статус в команде. Кто-то умеет это делать неосознанно, и про таких говорят “прирожденный лидер”. Будет возможность изучить как они это делать и научиться делать это осознанно.
 
Полную информацию и условия участия вы найдете тут http://hr-maverick.blogspot.com/2011/05/26.html
 
P.S. И еще в ближайшем будущем буду выступать я. Ждите следующих анонсов 🙂
 

 

А не отберет ли Facebook поиск у Google-а?

После знакомства с понятиями Видения и Молитвы (от Кавасаки) в Getting Real  возник вопрос, а в чем видение Google-а и Facebook-а?
Да, на корпоративном языке это называется «миссией», но оно часто воспринимается, ка общие слова. Я думаю, это связано с тем, что фаундерам не нравится заниматься тем, что они делают, или им все равно, чем заниматься –  just a business.
Рассмотрим сервисы на главной странице Гугла.
С поиском все ясно – без вопросов, но мы к нему вернемся ниже.
Не понятно, что организовывают карты, их уже географы, геологи и прочие специалисты давно организовали. Переводчики – это к филологам, а у Гугла просто еще один сервис, Вопросы и ответы – ничего оригинального, хотя очевидно поиск вероятнее всего более качественный. Gmail – также не вижу отношения к видению. Более того, цепочки делают неудобным работать на уровне писем, поэтому продолжаю пользоваться почтовыми клиентами.
Тот же успешный Андройд вообще никакого отношения не имеет к миссии.
Здесь, видимо, следует внести небольшое уточнение: мне очень нравятся многие из перечисленных и неперечисленных выше продуктов Гугла и я с удовольствием активно ими пользуюсь: Search, Gmail, Analytics, Blogspot, Reader, Translate, Trends, Picasa, Android, Docs, Otvety, Groups, Calendar, Maps, YouTube, Chrome и Blogspot. Но в плане видения не всегда понятно их существование.
Итак, так как же Facebook может противопоставить поиску свое power of share?  Очевидно, что в технологическом плане это практически невозможно сделать.
Рассмотрим примеры.
Заходит человек в Фейсбук и хочет найти место, где бы отдохнуть. Вводит «Отдохнуть», и тут ему рядом со ссылками вываливаются места где отдыхали их друзья, у которых можно расспросить, узнать впечатления, что пока невозможно для гугла.
И еще один пример.
У эмоционального пианиста от топанья ногами поламалась педаль в пианино и он ее хочет заменить. На что Гугл выдает первую ссылку: “Как заменить педали? Сделай сам”.
Да, можно долго говорить, что нужно уточнить запрос, нужно конкретнее и другое “нужно”.
А Фейсбуку это не нужно. Он может увидеть, что в ваших интересах есть «пианино» или же вы состоите в группе музыкантов, а если не вы, то вероятнее всего ваши друзья. И ничего общего с велосипедами, а тем более со сменой их педалей своими руками, как порекомендовал Гугл, вы не имеете и не хотите иметь. И вероятнее всего, кто-то из знакомых пианистов уже может порекомендовать проверенного человека.
Становится очевидно, какое преимущество путем коннекта людей, а не организации информации, можно получить.
Вернувшись к началу стать становится очевидно, что в Гугле нет общего направленного движения всех к выполнению видения и это видимо вносит хаос (например, я до сих пор ума не приложу, зачем мне GMail-е живая лента, хорошо что можно скрыть). Так же я слышал прецедент о том, что из гугла ушел человек, потому что ему надоели стопятсот code-review – это меня искренне удивило. Скорее Гугл скупает лучших, а самых лучших возможно потом перекидывает на поиск и адсенс, которые приносят прибыль – не будь их, не было бы Гугла. Остальных лучше держать у себя, а то еще начнут стартапы выстреливать – так выгоднее. Ведь не секрет что некоторые стартапы пишутся для продажи Гуглу, а некоторые Гугл после покупки просто закрывает как конкурента.
А Goolge в свою очередь….. перетягивает видение у Фейсбука: с одной стороны Гугл скупает социально ориентированные компании (гланое, чтобы это не сыграло злаю шутку, и Гугл не стал из-за этого более громоздким и неповоротливым. Тогда ему точно не угнаться за Фейсбуком), с другой Гугл привязал бонусы к социальной ирентированности сервисов.
Посмотрим, когда у него дойдут руки до поиска и что из этого получится.

Getting Real by 37 signals – YAGNI, YAGNI, YAGNI

Прочитал книгу Getting Real by 37 signals. Несколько прочтенных страниц такой книги действуют как допинг – нужно бросать чтение и за комп. Каким то странным образом эта книга кружила вокруг меня меня достаточно долго, но ни как не попадала мне в руки. Подход, как должен развиваться web-проект, мне наиболее близок по духу. Компактная, профессиональная команда, с очень успешными проектами. Мне это на много ближе, чем разрабатывать проект, чтобы потом продать Google, Yandex или венчурным фондам. Также мне близко то, что лучше небольшая, но эффективная команда, эффективность оценивается количеством пользователей и доходом, а не количеством человекомесяцев.
Книга о том, как в Web-проекте на полную катушку применять KISS & YAGNI.
Cледующая их книга Rework об управлении проектами тоже кружится вокруг меня, но скоро этому прийдет конец J А тут еще и Хабрахабр подлил масла в огонь: «Rework идейно дополняет книгу Тима Ферриса (Tim Ferriss) «The 4-Hour Workweek»», которую я прочитал непосредственно перед Getting Real.
Одно проведение митингов чего стоит 🙂 :

 
Мысли, которые я отдельно отметил, некоторые новые, а некоторое хорошо забытые старые:

Начинать с интерфейса, а не с логики.
Иногда лучший способ узнать, каким должно быть ваше приложение — это узнать, каким оно не должно быть. Пусть это будет врагом вашего приложения, и вы будете видеть свет, на который вы должны идти.
Если не хватает времени или бюджета, не увеличивать их, а резать функциональность и расставлять приоритеты.
Работникам каждый день нужно знать, когда они просыпаются, почему они собираются идти на работу. Этот план должен быть кратким и сладким, и затрагивать все: почему вы существуете? как это мотивирует? Я называю это молитвой — описание в трех-четырех словах причин, по которым вы существуете.
Пренебрегайте деталями в начале. Убедитесь, что это работает. Позже вы можете все усовершенствовать.
Поверьте, это не большая проблема расширяться, когда в этом есть необходимость.
Создайте половину продукта, но законченный продукт.
Если вы сможете сфокусировать работу и взгляд, на том, что имеет значение, вы достигнете производительности, которую никогда не воображали.
Вы должны рассматривать только те функции и особенности, которые были протестированы в течение трех дней и за это время были востребованы максимально.
Тестируйте в диких условиях.
Испытывайте ваше приложение в реальных условиях. Когда кто-нибудь другой наблюдает, люди особенно осторожны в том, чтобы не наделать ошибок.
Не нужно никаких бета-версий.
Перед тем как добавить функцию, задумайтесь, сколько это с виду простое решение может принести головной боли.
Забудьте о запросах функций. Пусть ваши клиенты будут вашей памятью.
Спросите людей, чего они не хотят.
Избегайте настроек. Примите решение о деталях. Настройки — уход от пути принятия жестких решений.
Никаких встреч. Никогда не участвуйте во встрече без ясной повестки дня.
Самое главное в разработке программного обеспечения — мотивация. Долгие, затянутые циклы разработки — убийцы мотивации.
.. мы могли оценить его работу по главному критерию — качеству.
(Либо фичу не делать вообще, либо делать качественно).

Создавайте дизайн интерфейса (хоть на бумаге) до того, как начнете программировать.
Интерфейс и есть продукт.… это было больше чем идея, это была реальность.
Дизайн от эпицентра.
Обрабатывать состояние “чистого листа”.
Уместность лучше последовательности (consistency).
Вы должны говорить тем же языком, что и ваша аудитория.
Не создавайте отдельного интерфейса для настроек, просто встройте его функции в основной.
Меньше кода.
Появилась идея – подождите неделю, прежде чем ее воплощать.
Выбирайте инструменты, которые заинтересовывают и стимулируют вашу команду. Счастливый программист – продуктивный программист. Смотрите на неосязаемые факторы: чувствуется ли в инструменте страсть, гордость и мастерство? Будете ли вы по-настоящему счастливы, работая в этой среде восемь часов в день? Это особенно важно при выборе языка программирования.

И Ruby, и Rails (авторами которых 37signals являются) проповедуют идею оптимизации для людей и их счастья.

Расплачивайтесь по долгам вашего кода и дизайна.
Выпустите данные в мир через RSS, API и т.п.
В функциональной спецификации нет ни грамма функциональности.
Функциональные спецификации ведут к перегруженности функциями. В стадии спецификаций вас ничто не ограничивает.
Напишите рассказ в одну страницу о том, что именно приложение должно делать. Используйте простой язык и сделайте это быстро. Если вам потребуется более одной страницы, значит, вы очень усложняете. Этот процесс не должен занять более одного дня.
Боритесь с создателями препятствий.
Пишите рассказы, а не описывайте детали.
Вставьте настоящий текст вместо Lorem ipsum.
Подумайте о своем продукте как о человеке. Каким человеком вы бы хотели его видеть?
Примите за правило делить хотя бы один продукт или услугу на маленькие кусочки, которые недороги, легки или интересны.

Давая людям власть над их информацией, вы создаете доверие
Избегайте долгосрочных контрактов, платы за подключение и т.д.
Подумайте о том, чтобы освободить существующих пользователей от повышения цены на какое-то время.
1) Анонс (teaser, буквально: дразнилка – прим. перев.), 2)Рекламный показ отрывков, 3) Выпуск.
Анонс – рекламный показ отрывков – выпуск.
Начните окучивать знатоков и экспертов. Это те, кто находится на переднем крае. Они определяют вкусы остальных.
Перед выпуском программы Backpack мы опубликовали наш манифест. Поэтому люди стали думать о нашей программе и обсуждать ее.
Сколько обновлений/поправок вы сделали? Покажите движение вперед и поддерживайте его.
Мощный сайт для продвижения: обзор, экскурсия, скриншоты и видеоролики, манифест, примеры, отзывы, форум, цены и регистрация, блог.
Поделитесь знаниями с миром
The Yellow Fade Technique, метод, который мы придумали, чтобы выделить недавно измененную область страницы.
Преподавание улучшает вашу карму.
Раздел статей и советов в нашем блоге – самое популярное место на нашем сайте.
Группы по интересам очень любят пережевывать “пищу функциональности” и выплевывать ее обратно в сообщество.
Вам полезно знать, кто о вас говорит. Узнайте это, а затем дайте другим почувствовать ваше присутствие.
Дайте вашему приложению легко запоминающееся название.
Выберите имя короткое, яркое, запоминающееся – и вперед.

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

Пользователям нравится прямота.
Крайне важно, чтобы вы, как компания-разработчик, любили свой продукт. А вы не сможете его любить, если он наполнен кучей вещей, с которыми вы не согласны.
Выпустите плохие новости и уберите их с дороги.
Когда появляются плохие новости, выпустите их сразу. Хорошие новости, с другой стороны, выпускайте медленно.  Если вы можете продлить прекрасные чувства, сделайте это.
Быстрое обновление показывает движение. Оно дает вторую волну разговорам. Оно подкрепляет первоначальные положительные эмоции, связанные с вашим продуктом.
Примеры для содержания блога: частые вопросы, как работать с программой, советы и решения, новые функции, обновления, исправление ошибок, разговоры/пресса.
Выложите ссылки на конкурентов и открыто обсуждайте их.
Не используйте “бета” в качестве козла отпущения. Бета сваливает все на пользователя.
Подождите, пока страсти улягутся, перед тем как действовать … если вы переждете этот начальный период, который составляет 24-48 часов, все уляжется.
Отрицательные реакции почти всегда звучат громче, чем положительные.

Подпишитесь на новости и о своих продуктах, и о продуктах конкурентов Используйте сервисы, такие как PubSub, Technorati, Feedster и другие, чтобы быть в курсе.

Будьте серфером. Наблюдайте за океаном. Смотрите, где образуются большие волны, и соответственно корректируйте курс.

P.S. Только что сделал подсветку ссылок в своем блоге так же как у 37signals в проектах. Кстати у них блог есть по Usability & Design.

"У Гугла явно выходные дни"

Из Google Groups:
“У Гугла явно выходные дни – отзыв в группу я отправила в пятницу, сегодня [среда] мне пришло уведомление, что мое письмо является подозрительным и классифицировано как спам  :-)Пришлось подтверждать Гуглу что я не спамлю в свою же группу.”
А в целом мне показалось, что гугл более глючным стал в послденее время – в особенности Google Docs. Видимо свою роль сыграло то, что Facebook начал покушаться на святое – на рекламу, о которой слышал отзывы, что она более качественная, чем у Гугла (хотя слышал и то, что просто мусорный трафик). И Google засуетился и начал давать сбои.
Кстати, из-за глюка в Андройде при переходе между часовыми поясами я чуть не пропустил встречу с ними же 🙂

Ажиотаж вокруг функциональных языков

Сейчас часто можно услышать “функциональный язык”, “Scala”, “Хаскель”.

А что же случилось? Что за ажиотаж? Тот же Лисп появился в 1958 году. Но почему-то о нем особо ничего не слышно. Да, его где-то все таки используют, но почему-то императивные языки, такие как Java, C++ гораздо распространеннее.

Читая обзор по Scala, я увидел много многовведений, которые удобны, но……. большинство из них не являются привилегией функциональных языков, например встроенный XML, более продвинутые шаблоны (хотя в C++ такая продвинутость уже давно есть без функционального программирования) и т.д.

Замыкания более лаконичны, чем в Java – хотя не возмусь судить, действительно ли это стало возможным благодаря тому, что Scala – функциональный язык.

Единственное, что для меня кажется очевидным преймуществом – это отсутствие side effects, что при многопоточном программировании потенциально имеет преимущества.

Я соглашусь, что на Scala можно писать более элегантный код, чем на Java.

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

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

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

Все точки над “I”, конечно, расставит время.