Если вы талантливый инженер, программист и мечтаете о собственной компании, проекте, независимости — вам понадобится сумасшедшая доза решимости, чтобы начать. Это трудный шаг — бросить теплое место в офисе и стабильный оклад и шагнуть “в никуда”. “С другом” этот шаг сделать легче, одному — всегда страшней. Если единственное, что вас останавливает — это отсутствие “друга”, то вот вам пинок: статья от создателя онлайн-школы Treehouse Райана Карсона.

Будет трудно, но если вам действительно нужен кофаундер в проекте, его всегда можно будет найти (или нанять) позже…

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

Перевод выполнен в Alconost. Итак, статья…

^{Бизнес-ангел часто смотрит на стартаперов с недоумением}

Предположим, вы придумали какое-то железо, и теперь хотите начать его производство. У вас уже есть прототип: вот он, в руке, коряво выглядит, в 4 раза больше нормального размера и из него торчит провод. Но он работает. У вас горят глаза: ведь осталось только «допилить» его и начать производить по всему миру. Из маркетингового плана у вас есть только «запостить про железку на Хабр – и всё закрутится».

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

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

Около полугода назад мне в руки попала книга Чарли Пелерина How NASA builds teams. В книге описывались социальные проблемы крупных технологических проектов, которые стоили миллионов долларов космической промышленности США.

В книге Чарли я подчерпнула ряд идей об измерении социального контекста проекта. И провела некоторые наблюдения с командами гибкой разработки. Думаю, лучше всего систему NASA 4-D лучше применять для тематической командной ретроспективы.

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

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

Станок с ЧПУ (Числовым Программным Управлением) – станок, работа которого подчиняется заранее заданной программе. Благодаря этому для обработки детали не нужен человек. Нарисовал на компьютере детальку, установил в станок заготовку, нажал пуск и пошел пить чай. По возвращении достаешь готовую детальку из станка. Фантастика? Совсем нет, такой станочек можно сделать самостоятельно!

.Net используются при программировании настольных и веб-приложений, а возможно ли использовать фреймворк для управления промышленными объектами?
Разберемся в начале с тем, где возможно применение такого ПО.
Промышленные системы управления состоят из нескольких уровней:

• уровень датчиков
• уровень управления (ПЛК, компьютер)
• уровень визуализации/SCADA

Визуализация – самый неприхотливый уровень АСУ по скорости обработки информации, обычно на операторских панелях отображается информация о состоянии какого-либо агрегата всей системы (некоторые численные значения, биты состояния (вкл-выкл), графики изменения величин). Для этого уровня можно свободно использовать все возможности .NET для вывода графической информации (Win Forms, WPF, SilverLight).
Рассмотрим уровень управления. Здесь нужная скорость обработки информации зависит от объекта управления: если вы хотите просто помигать светодиодом или включить/выключить двигатель без жесткой привязки по времени, то это возможно. Если же необходимо управлять объектами с жестко-определенным временем реакции, то необходимо использовать систему реального времени.
Для систем реального времени необходима ОС реального времени. В таких ОС жёстко определено время переключения контекста задач, т.е. квант времени на обработку каждого потока с одинаковым приоритетом выделяется одинаковый.
А что может получиться при использовании «десктопной» ОС?

Доброго времени суток, хабравчане!

Этой статьей я хочу пролить свет на интернет-эквайринг в целом, рассказать с чем его едят.
Цель статьи: для общего развития.

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

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

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

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
   
   
2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
   
   
3. “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

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

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.

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

Какой хороший программист наш Вася! Всегда опрятно одет, вежлив и предупредителен, хороший семьянин и душа компании. Что? Как он, собственно говоря, программирует? Хм… Постойте… А мы и не знаем. Никто никогда толком результатов его работы и не видел-то. Получается, Вася — не очень хороший программист? Ну ладно.

Вот Петя — точно хороший спец. Его код реально существует, компилируется, что-то делает. Показатель? Показатель. Правда, работает Петя не над тем, что по проекту надо, а над тем, что ему взбредет в голову. Иногда оно совпадает с общими целями, но чаще — нет. Выходит, и Петя наш — не идеал? Выходит так.

Привет, Хабр!

К нам в Alconost часто приходят клиенты и говорят “Мне нужна справочная система для моей программы. Сделайте мне ПэДээФку”. Мы создаем руководство пользователя, оформляем PDF, а потом оказывается, что на самом деле нужна была контекстная справка с индексом и поиском.

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

Оригинал: Starting out on Game Programming

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

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

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

От переводчика: недавно я купил часы с лазерным проектором и прочёл в инструкции привычную фразу: «Запрещено ремонтировать самостоятельно». Раньше в инструкциях писали, что при самостоятельном ремонте производитель отказывается от гарантийных обязательств. Это наглость, но можно понять. Сейчас они прямо запрещают разбирать устройство, даже не объясняя почему. То есть просто выкинь и купи новое. Полный беспредел потребительской культуры.

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

Микроконтроллер фирмы Parallax под названием Propeller, в сравнении с «классикой» жанра типа PIC или AVR занимает несколько странную нишу. Про первые два можно сказать, что это архитектуры общего назначения. Создатели же Пропеллера подошли к вопросу «с фланга».

Прошло уже больше года после завершения конкурса "Интернет-математика: Яндекс.Карты", но нас до сих пор спрашивают об алгоритме, который принёс нам победу в этом конкурсе. Узнав о том, что недавно Яндекс объявил о старте очередной "Интернет-математики", мы решили поделиться опытом нашего прошлогоднего участия и описать наш подход. Разработанный алгоритм смог с точностью 99.44% правильно определить лишние изображения в сериях панорамных снимков, например, как здесь:



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

Исходный код нашего решения доступен на github (C++ с использованием OpenCV).

Если Вы часто сталкиваете в работе со следующими фразами, то это статья для Вас:
• Почему ты, не разобравшись, сделал такую ерунду?
• Хватит задавать вопросы, прочитай вот этот маленький параграф и всё поймешь! — Я прочитал, но ничего не понял, объясни по-человечески.
• А вы знаете, нам всё надо делать по другому, так как в книге Х, в главе Y, есть утверждение Z противоречащее пункту 14.5.3 нашего ТЗ.
• Когда ты уже начнешь работать? – Я проектирую систему, мне надо ещё три недели.
• У меня есть идея, как сделать нашу жизнь лучше! Вася, послушай меня, тебе надо сделать: а, б, в, г …

На днях, после долгого перерыва, надо было поработать на WPF, и возникло желание заменить поднадоевший стандартный вид окон Windows 7 на что-нибудь более вдохновляющее, скажем в стиле Visual Studio 2012:

Данная статья является продолжением цикла статей про язык программирования Эрланг/Erlang и его использование в нашем проекте Рисоваська. В первую очередь я хочу ответить на вопросы заданные в комментариях к первой статье, а вопросов было задано много. Итак продолжим:

Установка Erlang под Windows

Установить Erlang достаточно просто. Сначала скачиваем дистрибутив с официального сайта. Нам нужна последняя на данный момент версия R12B-5, колонка Windows binary (incl. documentation). После инсталляции в меня «Пуск» — «Все программы» появится пункт Erlang OTP R12B и в нем подпункт «Erlang». Если его выбрать, то запуститься безымянная нода вместе с оболочкой (shell) в которой уже можно выполнять эрланговский код, в том числе из моих примеров. Я буду придерживаться названия «нода», так как официального названия в русском языке пока не устоялось, хотя слово «node» и переводиться как «узел».

Вот ссылки про установку Эрланга под Mac OS X и Линукс (на английском).

Большинство приложений провальны. Эта жестокая реальность приводит многих разочарованных разработчиков к заключению, часто подсознательному, что преуспевание в App Store — всё равно, что разбогатеть на «золотой лихорадке»: нужно быть чертовски удачливым.



Идея «удачи» — опасное успокоительное средство, облегчающее боль неудачи. А боль — это хорошая вещь. Она показывает, что что-то идёт не так. Если моё приложение потерпело крах, я хочу знать почему. Вместо того, чтобы обвинять мироздание, почему бы не посмотреть, что ребята из tap tap tap и Tapbots делают для того, чтобы снова и снова достигать успеха.

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

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

“Atmadm” 
Раньше наша работа была кошмаром из нагромождения букв.
“chkntfs”
“dir”



Тогда, в 1984, адаптировав Ксерокс ПАРК ВИМП, Эпл забросила нас вперед на целый галактический прыжок вдаль от этих ужасных командных строк ДОСа, в мир графических пользовательских интерфейсов [ПИ].


Эпл Лиза

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