Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

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

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

«Сюрпризы» поджидают на каждом углу. И они приходят не одни. Вместе с ними шагают страхи и сомнения. Именно тому, как выстоять, оставаясь в здравом уме, и будет посвящена эта статья.

На днях Даниэль Штенберг, один из участников группы HTTPbis IETF, которая ведёт разработку протокола http2, опубликовал в своём блоге крайне интересный документ «http2 explained». Небольшой PDF-документ на 26 страницах весьма доступным языком рассказывает о предпосылках и деталях реализации протокола http2.

Как мне кажется, на сегодняшний день это одно из самых лучших разъяснений о том, что такое протокол http2, зачем он нужен, как он повлияет на веб-разработку и какое будущее ждёт Интернет в связи с его появлением. Думаю, что всем людям, причастным к веб-разработке и веб-строению, информация будет полезна, ведь ожидается, что стандарт http2 будет принят уже в июне этого года после завершающей встречи группы HTTPbis в Нью Йорке.

Я расскажу как мы в компании работаем с приемочными тестами. В статье вас ждет ссылка на репозиторий с кодом и видео с примером работы.

Австралийский дизайнер Уилл Дэйбл предлагает интересную метафору, помогающую разрабатывать простые и удобные интерфейсы. Разработчику, который знает свою систему вдоль и поперек, и отдаёт работе над ней значительную часть своей жизни, очень трудно представить, как будет работать с ней обычный пользователь, чья голова забита другими вещами. Особенно, если он пробует его продукт первый раз в жизни и ещё не уверен в его полезности. Чтобы представить, что творится в голове у пользователя, Уилл Дэйбл предлагает вообразить, что пользователь пьян. Его внимание рассеянно, он легко выходит из себя, он не слишком отчётливо видит и не очень уверенно двигается — если постоянно помнить об этом, интерфейс получится чище и проще. Суть метода Дэйбл рассказывает в этом пятиминутном ролике:

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

Так получилось, что тесть и теща у меня доктора педагогических наук. Что приводит к тому, что волей-неволей начинаешь постигать различные полезные методики :)

Однажды, после какого-то ученого совета за виски чаем на кухне тесть говорит: Саш, а вот как ты считаешь, почему люди чего-то не делают?

Честно сказать, вопрос поставил меня в тупик. Я начал фантазировать: ну, обстоятельства мешают, черты характера, недостаток опыта…

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

• Почему менеджеров проектов надо пересаживать в отдельное здание
• Что делать, когда ваш заказчик не пользуется вашей системой отчетов
• Как раскачать low-performer’а

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

Моё хобби

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



Сделать первый шаг за стол переговоров было трудно. Это стресс. А когда были зрители, поединки приобретали особый накал. Но я справился и уже через полгода стал участвовать в турнирах, а вскоре и побеждать. Например, в 2011 и 2013 году становился победителем Московского открытого турнира по быстрой управленческой борьбе, в 2012 и 2013 завоевывал Осенний кубок Москвы в классической управленческой борьбе.

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

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



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

Сейчас же я ожидаю гораздо более сильный по эмоциям шквал комментариев и сравнений меня с различными персонажами, вплоть до Геббельса. Надеюсь, все таки до этого не дойдет. Итак, «Фирменные стандарты» ИТ компании.

В марте прошлого года мы неожиданно получили письмо от команды Google по борьбе со спамом.

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



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

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

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

Как-то один из персонажей популярного сериала заявил «Все врут!». И это отчасти правда. И что уж 100% правда, что все лажают. Каждый может вспомнить, когда наши сотрудники не выполнили взятые на себя обязательства, сорвали сроки, что-то сделали — но совсем не то, а иногда лучше бы вообще не проявляли инициативу. К сожалению, лажают не только сотрудники, но и руководители. Самое печальное в этом то, что работают далеко не дураки, но бывают такие глупые epic fail, что и говорить не хочется.



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

Привет Хабр!

Изначально хотел назвать статью «HTML по ГОСТ`у», но потом выяснилось что у большинства программистов не было предмета «Метрология и стандартизация» и о «стандартизации», «сертификации», «унификации» не все слышали.

В i-Free я много занимаюсь разработкой веб-приложений. А поскольку их много, они разные и работают в разных условиях, то само собой приходится задумываться о стандартизации. Есть такой проект «Пуленепробиваемый HTML5» (http://html5boilerplate.com/), в котором разработчики решили создать идеальный шаблон странички. Он мне очень нравился, и все свои проекты я начинал именно с него. Но, исправляя баг за багом, делая все новые и новые приложения, я пришел к выводу, что многого в нем не хватает. В этой статье я хотел бы рассказать о том, что обычно пропускают при написание страничек и веб-приложений и показать, чем и зачем я прокачал свой шаблон пустой странички.

Бес нас попутал.
Мы создали MadRobots, чтобы привозить в Россию лучшие инновационные гаджеты со всего мира. А опустились до того, что стали торговать банальными айфонами. За это и поплатились — как платят в итоге все, кто идет за толпой и предает свои идеалы.
В прошлый раз я рассказывал, как начал инвестировать на «Кикстартере», увлекся «интернетом вещей» и в итоге обрел свое счастье, бросив работу в Panasonic и открыв свое дело.


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

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

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

Как проект может отстать на год?
… по дню «за раз»
…Фред Брукс

Идея написать пост появилась в связи с тем, что в последнее время приходится сталкиваться со следующий кейсом: Руководители проектов стараются поддерживать процессы, соблюдать предписания методологий, собирать метрики, поддерживать высокую мотивацию на проекте. Но приходит время очередной проверки результатов работы (milestones, deliverables) и оказывается, что степень завершенности проекта отстает от плановой, что неминуемо приведет к срыву сроков. И руководитель проекта, стараясь устранить угрозу как можно раньше, озвучивает ее команде, а далее просто пытается ускорить процесс напутствующим словом и частным мониторингом, что без определения причин редко работает.

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

Вы хотите быть эффективным на работе и в жизни, но есть пара дурных привычек, от которых вы не можете избавиться? Расслабьтесь, избавиться от привычки невозможно.

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

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

Сегодняшний пост написан под влиянием полезной книги Чарльза Дахигга "Сила привычки".

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

Эти требования разумны. Часть из них трудно реализуема. Часть — очевидна. Часть — зависит от контекста. Но в целом они довольно универсальны. Если будут какие-то вопросы по конкретным пунктам — велкам в комментарии.

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

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

Сразу хочу сказать, что все книги на английском. Часть из них можно найти на русском, но без английского на уровне чтения и прослушивания подкастов будет тяжко – на русский клевые вещи об управлении продуктами переводят медленно и нехотя. Второй момент – чтение книг из этого списка не сделает из вас менеджера продукта. Как и книжка С++ за 21 день не сделает из вас С++ разработчика. Просто уровень вхождения в окологуманитарные профессии пониже, и это иногда создает напрасные иллюзии.

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

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

Добрый день!

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

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

От переводчика: Sam Altman, успешный предприниматель из Калифорнии, делится своими наблюдениями по поводу того, что общего у самых успешных компаний. Сам Sam Altman, основавший компанию Loopt, которой удалось привлечь $30 миллионов венчурного капитала, входит в число партнеров Y Combinator. BusinessWeek назвал его одним из «Лучших технологических предпринимателей».

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

* Они одержимы качеством продукта/опыта. Почти слишком одержимы, они тратят много времени на детали, которые на первый взгляд не очень важны. Учредители этих компаний реагируют так, будто они чувствуют физическую боль, когда что-то идет не так с продуктом или пользователю оказывают плохую поддержку. Хотя они верят в ранний запуск и циклы, эти люди не собираются размениваться на плохой продукт. (Это не повод откладывать запуск. Вы, наверное, и так с ним медлите).

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