Многие из нас любят походы. Мы привозим тонны фотографий, потом долгими вечерами ковыряемся, пытаясь выбрать лучшие, чтобы было что показать друзьям и знакомым. Но некоторым этого мало. Хочется порой, знаете ли, погрузиться в воспоминания ещё немного полнее. Вот бы записать маршрут и потом посмотреть его на карте или в Гуглобусе!

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

В последнем нашем конном походе у товарища был навигатор Gramin Oregon 450, на который мы трек и писали. Анализировать трек оказалось очень увлекательным занятием! Можно посмотреть скорость движения, а потом вспомнить где рысили, где галопчик делали, а где и шагом плелись, где поили лошадок и где стоянки делали. А если учесть, что к этим данным можно «привязать» фотографии и даже сделать красивый .kmz-файл с отметками и фотографиями!.. Вобщем, простор для фантазии.

Впредь решено было «писать» все походы и я приступил к поиску устройства.

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

Разработчики программного обеспечения не любят составлять план работ. Обычно пытаются вовсе от него отказаться. «Закончу, когда закончу!», — говорят они, ожидая, что этот смелый и веселый поступок вызовет одобрение у босса, а о планировании будет успешно забыто.

Большая часть расписаний, с которыми вы встретитесь, будет представлять из себя бездушные отписки. Совершенно забытые, они хранятся в каком-нибудь общем каталоге. После выпуска продукта с опозданием на пару лет странный парень, в чьем офисе, говорят, видели картотеку, принесет на обсуждение причин провала старую распечатку, которую все засмеют. «Только гляньте! Мы запланировали две недели, на переписывание системы с нуля на Ruby!»

Модель пропасти

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

Сейчас, куда не посмотри, все стали учёные: литературой запаслись, интернеты читают. Кого не спроси, и о кривой принятия технологии знают, и вообще всё им понятно: «… да-да, знаем! Есть Новаторы, Ранние последователи, есть рынок ранний, а есть поздний, отщепенцы и увальни — ну куда без них? Да-да, между рынками, ранним и основным, есть пропасть, которую нужно перепрыгнуть!» Знают. Прыгают. Только, бывает, пикируют. А всё почему? Потому что аннотацию прочли, а содержимое не осилили. Поэтому я написал эту заметку. Речь пойдёт о том, что важные вещи, которые нужно знать о модели Пропасти, не всегда лежат на поверхности.


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

Тема анонимности в Интернете является сейчас достаточно модной и интересной, и особенно теперь, когда новостные порталы пугают наc всякими там PRISM, правительственными инициативами и прочим. Большинство людей озабочены тем, как сохранить тайну своей личности в сети и поэтому все темы так или иначе посвящены ЗАЩИТЕ. Но иногда, раскрытие анонимности это не такое уж и плохое дело. Да-да, эта заметка — мой опыт борьбы с анонимностью своими силами, без помощи спец-служб…

Программировать — не в бирюльки играть.
И. В. Сталин

Я хочу напомнить о древней русской игре Бирюльки, об игрушке для iPhone и об Adwhirl, закрывающемся сервисе Google, с которым надо что-то срочно делать.

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

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

Изучив «арт чемпионов» в AppStore, Google Play и Amazon российского, американского, европейского и азиатского рынков, хотим поделиться выявленными закономерностями. Просим воспринимать данные размышления просто как некий дайджест нашего дня, на серьезное исследование мы не претендуем, так как это требует куда большего времени и более кропотливого подхода. Материал готовился для одной из майских конференций, изучался топ-гроссинг за март-апрель. С этого времени топ, конечно, поменялся, тем не менее, в целом все примеры до сих пор актуальны и, на наш взгляд, отражают общую тенденцию.


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

Что посеешь, то и пожнешь
Из желудя вырастет дуб,
Из семени репейника — только репейник
Профессиональное образование —
это семена, которые мы сеем...

Поиск высококлассных специалистов — один из самых сложных вопросов в бизнесе, связанном с разработкой ПО. Несмотря на все сложности мировой и отечественной экономики, квалифицированных кадров не хватает катастрофически. Количество проектов, требующих высокой квалификации, растет значительно быстрее, чем “зреют” специалисты (разработчик — 2-3 года, ведущий разработчик — плюс 2 года, архитектор решения — плюс 3–5 лет ...).

В результате на рынке труда сложно найти разработчиков, и почти невозможно найти квалифицированных архитекторов. Проблема усугубляется тем, что обучение хорошего разработчика не простая задача, в лучшем случае только половина студентов IT-специальностей, обучающихся по стандартной программе и не имеющих опыта работы, действительно в состоянии выполнять реальные задачи после окончания вуза. При этом, эти студенты, как правило, начинают работать по специальности со 2-3 курса, и сложно понять: они знают и умеют «благодаря» или «вопреки». Возможность обучить архитектора в вузе в принципе вызывает сомнения, если не истерический смех.

Недавно я получил от своего знакомого вопрос примерно следующего содержания:

Добрый день Михаил! Сейчас занимаюсь одной исследовательской работой. Учитывая ваш профессиональный опыт, хотел бы вас попросить ответить на вопрос:

Вы выпустили продукт, который делали целый год, потратив на разработку все инвестиции. Из 1 000 первых пользователей 995 удалили его или перестали им пользоваться на следующий же день. Опишите ваши действия.
Заранее благодарю!!!

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

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

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

Вас ждет много анализа и немного частных производных. Код прилагается.
Прошу под кат!

Давно хотел написать на эту тему. Первым толчком послужила статья Miško Hevery "Static Methods are Death to Testability". Я написал ответную статью, но так и не опубликовал ее. А вот недавно увидел нечто, что можно назвать «Классо-Ориентированное Программирование». Это освежило мой интерес к теме и вот результат.

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

• это не дает никаких преимуществ по сравнению с процедурным программированием
• не стоит отказываться от объектов
• наличие статических членов класса != смерть тестам

Хотя эта статья про PHP, концепции применимы и к другим языкам.

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

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

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

Осторожно, butthurt.

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

Отобраны лучшие 10% из примерно 200 прочитанных книг о маркетинге, продажах и всем связанном — самые «пробивные» вещи, которые помогут вам не тратить время на всякий шлак, а сразу начать с главного.

В конце — суммация книг, которые хабровчане рекомендуют в комментариях помимо основного списка.

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



Тогда понадобился год, чтобы прочитать в десять раз больше бумаги и сделать выборку, которая оказалась неожиданно полезной многим. Вот результаты ещё одного года — ещё N+2 книги для бизнеса, которые реально помогают.

Привет!
Прошлые два обзора полезных книг за 2010 и 2011 год собрали просто адовое количество закладок, поэтому я продолжу. Прошел ещё год, ещё около 250 прочитанных книг – и вот самые интересные под катом.

Кто сказал, что слоны не умеют танцевать? Возрождение корпорации IBM: взгляд изнутри (Герстнер Луис)

Отличная книга про то, как удалось восстановить IBM. То, что со стороны выглядело как бессистемное перемещение активов и последовательность приказов без особого смысла, через несколько лет начало складываться в единую систему.

Догнать зайца (Стивен Спир)

Отличная книга про дебаг производственных процессов. Одна из основных вещей – то, что все серьёзные проблемы возникают из-за сочетания некритичных багов. Есть примеры из американской ядерной программы, NASA и т.п. Я предлагаю прямо сейчас пойти и прочитать описание железнодорожного крушения на Каменской: один не отчитался, второй не проверил тормоза, третий зажал тангенту, четвёртый сорвал стоп-кран. Результат — катастрофа.

В данном посте я хочу обратиться к теме, о которой многие начинающие iPhone-разработчики часто имеют смутное представление: Objective-C Runtime. Многие знают, что он существует, но каковы его возможности и как его использовать на практике?
Попробуем разобраться в базовых функциях этой библиотеки. Материал основан на лекциях, которые мы в Coalla используем для обучения сотрудников.

Мы, программисты, — оптимисты. Это проявляется во всем цикле разработки ПО от оценки сроков до написания кода и внедрения. Как показывает моя практика, в разработке ПО законы Мерфи работают в 100% случаев. Несмотря на это, я раз за разом сталкиваюсь с «программистами-оптимистами».

Топ «оптимистичных» допущений: