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

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

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

Следы от пуль

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

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

Логично заключить, что нужно добавить брони в тех местах, где больше всего следов. Но это неверно.

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

Так вот, советы как завалить проект:

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

2) Концепт не нужен, зачем тратить время? Главное, начать как можно быстрей писать код, а идеи и концепт обязательно придут в пути. Кто быстрей начнёт программировать, сможет забронировать самые интересные задания.

3) Очень важно менять существенные вещи примерно в середине проекта, а лучше несколько раз. Ведь нужно было срочно программировать, и выбрали не ту технологию, не тот способ, 3D графику вместо 2D.

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

Прочитал интересную и полезную статью (1) — и захотел поделиться собственным опытом. В нашей фирме за 12 лет работы с одной (своей, Oracle-ориентированной) программой у сотен клиентов накоплен богатейший материал на тему апгрейда структуры БД.

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

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

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

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

Когда мы только запускали облако, первой проблемой было «как нам получить консоль». Штатный механизм XCP поразумевает, что консоль рисуется с помощью VNCTerm, а желающий её увидеть должен сначала пойти в XenAPI, получить там session-id консоли, пойти на порт консоли, передать session-id, получить RFB, завёрнутый в HTTP, развернуть HTTP, вынуть RFB (он же VNC), отдать её локальному рендереру VNC (VNC-клиенту или java-апплету с тем же функционалом). При этом консоль закрывалась (сессия рвалась) при каждой перезагрузке виртуальной машины. Она рвалась даже при миграции виртуальной машины. Другими словами, это была технология, которая подразумевала «глянул одним глазком, починил ssh/iptables и забыл». Неудобно, медленно, сложно. Выкатывать такое в продакт совсем не хотелось.

И я залез в дебри serial-howto, console-howto и ещё несколько ужасных документов, рассказывающих о том, как правильно нужно конфигуриовать прерывания на ISA плате у мультикарт, а так же специфику настройки linux-2.2 для работы с оными. Параллельно изучалось устройство консоли в зене (внимательный читатель мог даже заметить, когда именно я более-менее разобрался в этом вопросе — я писал на хабре краткий обзор того, что происходит с консолью).

После этого пришла мысль: нужно писать своё, потому что готового чужого хорошего нет.

Сначала мы хотели взять хотя бы готовые компоненты и сделать из них своё. Я помню до сих пор ту замечательную схему, в которой мы планировали сохранять в БД вывод anyterm'а, делать двойное туннелирование последовательного порта с использованием UDP… Выглядело это, мягко скажем, неприглядно.

Потом пришла в голову мысль выпилить anyterm. Для этого нужно было посмотреть, как работают терминалки. Это было очень забавно и поучительно (желающие могут изучить исходный текст PuTTY). Главной проблемой в этом изучении было то, что они много рисуют на экран. Прямо в процессе обработки ввода. Отделить специфику DC от, собственно, того, что является консолью, было сложно.

Через некоторое время мы пришли к идее «нам нужен свой эмулятор терминала».
Задача казалась относительно простой, пока мы не прикоснулись к бездне, именуемой «escape-коды и типы терминалов...».

Пишущие машинки

Итак, в начале была пишущая машинка. В какой-то момент возникло желание совместить телеграф с пишущей машинкой. Так возник телетайп
Разумеется, инженерам, создававшим телетайп, не было никакого резона делать все с нуля. Они просто приделали коды к каждой клавише пишущей машинки. После некоторых боёв в стиле MS VS Netscape, был создан стандарт html5 на коды для оных машинок, то бишь телетайпов. Если мне память не изменяет, то это ASCII, где предусмотрены все комбинации клавиш, характерные для американской пишущей машинки. Включая код BELL, который, кстати, должен вовсе не делать BEEP, а делать «дзыньк», ибо у пишущих машинок был именно колокольчик, а не спикер.

Давайте подумаем, кому нужны гуманные методологии разработки? Команда, ответственность, храбрость, доверие…

Инвестор

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

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

Менеджер проекта

Ему нужно, чтобы проект:

а) Был довольно точно описан, согласован с Заказчиком и требования не менялись. Тогда его несложно оценить, распланировать этапы работ и водопадно выполнить.

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

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

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

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

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

Американский стандарт интеллектуальных транспортных систем U.S. Dot ITS описывает весь комплекс автоматизированных систем управления транспортом. Стандарт настолько масштабен, что втиснуть его описание в один или даже два поста нереально. Так как большинство описанных в нем систем для нас недостижимое светлое будущее, то и делать этого не стоит. А вот что стоит сделать — это рассмотреть то, как он устроен изнутри, какие находки сделали неизвестные американские (ой ли?) ИТ-специалисты, проделавшие весьма значительный объем работы за счет налогоплательщиков.

Чтобы было проще, предлагаю рассмотреть более подробно одну из систем стандарта, а именно АСУДД (автоматизированную систему управления дорожным движением). Тем более, что это сейчас крайне модная тема в нашей стране, где еще сильны иллюзии того, что компьютеры смогут заменить нормальный асфальт, а, может быть, вообще позволят обойтись без дорог.

Привет, Хабр! Я продолжаю цикл статей по теме маркетинга и продаж в веб-студиях / интерактивных агентствах. В этом материале я хочу поговорить о собственных сайтах студий и типовых ошибках, которые очень часто совершают их владельцы.

Этот дайджест основан на моем приличном опыте мониторинга и анализа сайтов на рынке веб-разработок (исследования конкурентов в ADV, мониторинг и анализ участников «Тэглайн», проведение заказных аудитов для студий и пр.).

Я попытался систематизировать основные «ляпы» и упущения по нескольким основным категориям, на которых и остановлюсь подробнее:

• Ошибки позиционирования;
• Ошибки расстановки приоритетов;
• Неправильная презентация компании и услуг;
• Неправильная презентация портфолио и кейсов;
• Ошибки в коммуникации с заказчиком;

Идея Java vs .Net vs Mono

Сама идея создания подобного теста появилась из-за, постоянно не дававшего мне покоя, противопоставления .Net и Java, и я решил максимально объективно оценить реальную производительность данных платформ, затем в поле зрения попала интересная opensource разработка Mono (свободная реализация .Net), и было решено включить и её, а заодно прогнать тесты под Linux. Соответственно были разработаны две аналогичных программы тестирования на языках C# и Java. Далее будут приведены фрагменты исходников на C#, полный исходный код можно получить из репозитария Google Code:
http://code.google.com/p/dotnet-java-benchmark/source/checkout
Целью данного теста является сравнение производительности различных виртуальных машин, выполняющих по сути один и тот же код на одном и том же компьютере. В соревновании принимали участие следующие платформы:

• Microsoft .Net 4.0 (Windows 7)
• Oracle Java SE Version 6 Update 24 (Windows 7)
• Oracle Java SE Version 6 Update 24 (Linux 2.6.35.27 Ubuntu 10.10)
• Novell Mono 2.11 (Linux 2.6.35.27 Ubuntu 10.10)

Начало и оглавление см. в первой части.

А что вообще такое — «биржа»?

Представьте себе магазин, в котором продаётся картошка.

Сегодня очень модно делать стартапы. В чем-то это похоже на золотую лихорадку.

Огромное количество людей, прочитав готовые алгоритмы, хотят открыть свой стартап.

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



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

Итак, я настоятельно рекомендую всем, кто делает свой стартап или только собирается, пересмотреть отношение к ряду вопросов.

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

Презентация магистерской программы «Master of Technology Entrepreneurship» начнется в 18.00 в четверг 9 июня на Биржевой линии В.О., д. 14 в бизнес-инкубаторе QD.

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

День открытых дверей традиционно проходит в формате «Call to Action».

Всем привет.
Сегодня я расскажу вам как с помощью AndEngine написать небольшую игру. Стаья получилась довольно большая и, чтобы не утомлять читателя, пока мы остановимся на первой ее части. Все что нужно от читателя — это знание java, ООП и умение обращаться с Eclipse и Android SDK. Забегая вперед, у нас получится что то похожее на Mirrors Maze либо Laser Logic.
Вторая часть статьи.
Третья часть статьи.

NuGet привнес в мир .NET-разработки поддержку установки компонентов разработки с помощью пакетов. С момента запуска NuGet в начале года в его репозитории создано уже свыше 4000 пакетов, а количество загрузок пакетов приближается к миллиону.

Возможности NuGet не ограничиваются официальным хранилищем пакетов. Любая компания или индивидуальный разработчик могу создать свой собственную ленту пакетов, с ограниченным в рамках организации доступом. Благодаря тому, что средства интеграции NuGet со средой разработки Visual Studio поддерживает частные ленты пакетов, любой желающий может использовать свои ленты точно так же как и официальную. Таким образом, пользу и удобство NuGet можно использовать и тогда, когда вы не можете или не хотите распространять компоненты публично.

Вместе с возможность самостоятельного создания ленты пакетов на собственной инфраструктуре существует еще одна возможность. Недавно был запущен сервис MyGet, который предлагает быстрое создание частных лент пакетов NuGet как сервис. Как шутят на сайте MyGet – это NuGet as a Service (NaaS).



В этой статье дается описание сервиса и рассматривается порядок его использования.

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

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



[Эта статья рассматривает технические особенности, соотношения и размеры Flash версии игры Canabalt. Читатель, будь осторожен, статья содержит спойлеры и большое количество цифр!]

Друзья часто спрашивают меня: думал ли я о том, чтобы выложить исходный код моей Flash игры Canabalt в интернет на растерзание и изучение. Они думают, что для людей будет полезно увидеть, как в игре организована физика и другие вещи. Но я отношусь с опасением к этой идее, на это у меня есть несколько причин, например: исходный код игры написанный за 5 дней, представляет из себя кошмарный и отвратительный спагетти-код, который вряд ли поможет кому-нибудь. Поэтому, из чувства гордости по поводу первого дня рождения Cannabalt, я подумал: «почему бы не написать статью, в которой бы рассказывалось о том, как внутри всё устроено?»

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

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