Неприятности случаются… Неожиданно плохой фидбек, проблемы с заказчиком или коллегами, не повысили зарплату, странные баги, внезапный овертайм или закрытие проекта — подобные события запускают цепочку реактивных реакций:

• Нет, тут есть ошибка -> сами гады -> а может все не так и плохо -> ппц -> ладно, давай выкручиваться

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

• Как узнать каждое состояние и предугадать следующее?
• Как помочь выйти себе и собеседнику из цепочки?
• Что не делать, чтобы не усугубить ситуацию?

От переводчика: это перевод статьи Кристиана Глобмайера The Ten Rules of a Zen Programmer. Статья мне понравилась, решил сделать перевод, после окончания перевода загуглил название, нашел вариант перевода: 10 принципов дзен программиста. Отличается от моего, поэтому решил свой вариант перевода все-таки запостить.

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

Одним дождливым утром я сидел за своим столом и думал об эффективной работе. До того, как я начал работать фрилансером, у меня бывало, что я работал много, но никогда не был доволен результатом. Я начал практиковать Дзен в 2006 году. То, что мне пришло в голову через довольно большое время — старые мастера Дзен уже знали сотни лет назад, как сегодняшние программисты должны работать. Хотя я не люблю посты «как быть лучшим программистом», я хочу рассказать о некоторых моих мыслях с того времени. Этот пост будет служить мне напоминанием, но если у вас есть идеи, не стесняйтесь оставлять комментарии.

Я технический евангелист компании Unity Technologies, и моя работа — путешествовать. За пару часов до Нового Года я насчитал в своем календаре 23 командировки по разным конференциям и мероприятиям в 2013-ом. В 2012-ом ситуация была похожа, но фокус был больше на Западную Европу. А теперь пришло время делиться опытом.

Предположим, мы пишем игру для Android, которая подразумевает некое сетевое взаимодействие между устройствами. Причем наши устройства находятся в одной сети и мы хотим, чтобы взаимодействие между ними осуществлялось быстро, а значит вариант с обменом данными через интернет нам не подходит. Ах да, еще одна маленькая ложка дегтя — мы хотим охватить максимально возможную аудиторию, для чего нам необходимо поддерживать Android 2.3.
Что же нам делать? Давайте поговорим об этом, а заодно рассмотрим относительно новые возможности Android SDK для соединения двух и более устройств.

Мне было немного странно видеть, что в таком замечательном ресурсе мало обсуждения и самой темы о торговых марках, то есть наименовании IT продуктов и компаний (“торговой марки”, “торгового наименования”, “ТМ”, “trademark”). Очевидно, что любой программист и участник IT рынка (а особенно те, кто пишут свои продукты), рано или поздно столкнется с этим вопросом. Поэтому, чем раньше IT-шники об этом будут задумываться, тем меньше будет проблем в их бизнесе в будущем.

Итак, постараемся восполнить пробел и открыть тему торговых марок. Очевидно, что с точки зрения программирования легко повторить и tetris, и facebook, и любые «фермы». Но попробуйте раскрутить свой продукт (клон он или нет) с похожими на эти продукты названиями — тут же владельцы (вернее их юристы) вас закроют со всех ресурсов. С другой стороны, если ваш продукт становится популярным, то тут же назревает необходимость защитить его от клонов и сделать так, чтобы другие не использовали и не забивали вашу марку в свои ключевые слова. Если коротко — это и есть причина, по которой торговая марка выступает одним из основных параметров оценки и стоимости любого IT проекта при его финансировании, продаже и заключении солидных контрактов.

Для тех, кому одного курса на праздники мало и кто хочет больше, продолжаем нашу серию курсов от Школы анализа данных Яндекса. Сегодня подошла очередь курса «Дискретный анализ и теория вероятностей» – даже более фундаментального, чем предыдущий. Но без него нельзя представить ещё большую часть современной обработки данных.

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



Читает курс Андрей Райгородский. Доктор физико-математических наук. Профессор кафедры математической статистики и случайных процессов механико-математического факультета МГУ им. М. В. Ломоносова. Заведующий кафедрой Дискретной математики ФИВТ МФТИ. Профессор и научный руководитель бакалавриата кафедры «Анализ данных» факультета инноваций и высоких технологий МФТИ. Руководитель отдела теоретических и прикладных исследований компании «Яндекс». (Ещё больше можно узнать в статье о нём на Википедии).

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

Сегодня — о самом важном. Современный анализ данных без него представить невозможно. В рамках курса рассматриваются основные задачи обучения по прецедентам: классификация, кластеризация, регрессия, понижение размерности. Изучаются методы их решения, как классические, так и новые, созданные за последние 10–15 лет. Упор делается на глубокое понимание математических основ, взаимосвязей, достоинств и ограничений рассматриваемых методов. Отдельные теоремы приводятся с доказательствами.



Читает курс лекций Константин Вячеславович Воронцов, старший научный сотрудник Вычислительного центра РАН. Заместитель директора по науке ЗАО «Форексис». Заместитель заведующего кафедрой «Интеллектуальные системы» ФУПМ МФТИ. Доцент кафедры «Математические методы прогнозирования» ВМиК МГУ. Эксперт компании «Яндекс». Доктор физико-математических наук.

Вступление
Думаю многие программисты создали, или пробовали создать свою игру. Обычно процесс доходит до момента, когда основная часть всего написана, и нужно начинать строить уровни, игровые сцены, и т.д. Если использовать готовые решения, «из коробки» — например Unity, тогда проблем не возникает. Но могут появиться проблемы с лицензированием, поддержкой разных платформ — может кто-то хочет попробовать что-то поделать под Linux / Mac, где не всегда можно найти нужное решение. Да и начинающим игроделам интересней использовать что-то своё, лёгкое в разработке и наращивании функционала, адаптированное под себя. Для себя я нашёл решение в виде написания собственного небольшого плагина к Inkscape.

Закончил интеграцию нашей площадки с платежной системой PayPal. В моем случае, была небольшая особенность — мы уже принимаем платежи с Робокассы и нам хотелось бы получить похожий воркфлоу при оплате. Разных вариантов интеграции у PayPal очень много и самой большой «сложностью» был поиск нужного варианта, совпадающего с уже существующим воркфлоу.
Воркфлоу наш очень прост:

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

В итоге у меня все получилось, хотя и не без маленьких косяков (как же без них).

Что нам понадобится

• PayPal REST API SDK. Я писал на .net, но SDK есть для многих платформ, а даже если нет, то это ведь REST и OAuth — можно подключиться и без SDK.
• Инструкция по взаимодействию с API
• Интерактивный гайд с примерами кода. Код я брал прямо оттуда, причесывал, правил баги, заполнял «пустоты» (те самые косяки выше).

После 1,5 лет работы канала ПРОСТАЯ НАУКА мы решились-таки на начало его монетизации. Из всех возможных идей (а их было немало) мы остановились на наиболее простых: книга, наборы и шоу для детей.

Начали с книги. В качестве основы взяли наши видеоролики с опытами. Отобрали опыты для детей (для возраста 5-12 лет). Далее разбили их на разделы. И, взяв для начала первые 4 раздела (про воду, куриное яйцо, опыты с воздушными шариками и на равновесие), сгруппировали в них по 8 опытов. Итого вышло 32. Потом сняли 32 ролика в нужном «детском формате» — с соответствующей музыкой, монтажом, объяснением. Затем написали текст и сверстали книгу.

И когда дело дошло до «книги»

Мы ходим в японские рестораны,
но не едим рыбу. Кто мы?

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

Идея

Ровно год назад в декабре 2012 года мы сидели с женой в одном из ресторанов. Был новогодний ажиотаж, поэтому меню, как водится, не хватило на всех, а обслуживали достаточно долго. Даже чек пришлось ждать минут 20. Неделей ранее я впервые увидел в другом ресторане механическую кнопку вызова официанта. Тогда у меня в первый раз промелькнула идея о том, что неплохо бы каждому ресторану иметь электронное меню и такой же электронный вызов официанта. Сначала появилась мысль о маленьком Atom PC, который будет стоять в ресторане и по wifi принимать запросы от ресторанных планшетов. Подумал, обсудил с женой и забыл на пару недель. Спустя две недели ситуация с меню повторилась и тогда я понял, что все можно обернуть в красивый SaaS сервис. Сейчас, даже странно смотрится то, что эта идея не пришла ко мне сразу. Так появилась идея сервиса, который мы назвали «47 ресторанов».

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

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

^{В первых двух абзацах оригинального текста автор описывает как он пил пиво с друзьями. Я заменил их пятничной картинкой о гимнастике из детства.}

Объектная гимнастика (англ. Object Calisthenics) — это упражнения в программировании, которые состоят из 9 правил, которые Джефф Бей описал в своей книге «The ThoughWorks Anthology». Пытаясь как можно точней следовать этим правилам, вы измените свои привычки написания кода. Это не значит, что вы должны постоянно соблюдать все эти правила. Найдите баланс и используйте только те, которые вам удобны.

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

Ниже я прокомментирую этих 9 правил:

1. Только один уровень отступа в методе
2. Не используйте Else
3. Оберните все примитивные типы и строки
4. Коллекции первого класса
5. Одна точка на строку
6. Не используйте сокращения
7. Сохраняйте сущности короткими
8. Никаких классов с более чем 2 атрибутами
9. Никаких геттеров, сеттеров и свойств

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

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

Интересный факт: Оказывается существует целое движение — OpenCourseWare, которое началось в 1999 году в Германии, когда один из университетов разместил видео своих лекций онлайн. Вскоре и други университеты подхватили инциативу и сейчас OpenCourseWare — это достаточно популярная штука, которая представляет из себя курсы и бесплатные учебные материалы, созданные в университетах и распространяющиеся через интернет.
Как правило ресурсы OCW не требуют регистрации и не предлагают никаких сертификатов о прохождении. Все обучение — в качестве self-improvement.

Под катом список бесплатных онлайн-курсов и уроков от лучших учебных заведений

^{Источник фото}
Тестирование — это очень важный процесс во время разработки приложений. В случае Android, тестирование приложения следует производить на большом количестве устройств, в связи с тем, что многие из них имеют значительные различия по характеристикам (разрешение экрана, версия Android и т.д.). Процесс тестирования приложения вручную на большом количестве устройств может быть трудоемок, утомителен и подвержен ошибкам. Более эффективный и надежный подход состоит в автоматизации тестирования пользовательского интерфейса. С помощью UIAutomator можно разработать тест-скрипт, который будет работать на множестве Android устройств
с одинаковой точностью и воспроизводимостью.

Салют, Хабр!
Недавно я уволился с довольно завидной должности (главного архитектора) в довольно неплохой компании (Acronis) и с непоколебимым решением в мозгу больше не работать по найму переехал из Москвы обратно в Ереван, откуда семь лет назад понаехал в Златоглаво-Нерезиновую. Учитывая необычность произошедшего и часто задаваемый вопрос «но почему?!», я решил разобраться в собственных мыслях и озвучить их вслух для себя самого и тех, кто может почерпнуть в моих размышлениях что-то для себя полезное. Короче говоря, это рассказ о том, почему я оставил высокооплачиваемую перспективную работу в международной компании ради сомнительной перспективы начать собственное дело, и как я собираюсь дальше жить.

Международная ассоциация компаний-партнеров Майкрософт (IAMCP) и Microsoft EMEA проводят второй конкурс разработчиков приложений для Windows8 и Windows Phone. Конкурс проводится по категорям B2B (общая тематика и решения для здравоохранения) и B2C (общая тематика и приложения для контроля личного здоровья). Примите участие и выиграйте Surface 2, XBOX One, приглашения на конференцию WPC 2014, которая пройдет в Вашингтоне, и другие ценные призы!

Для участия в конкурсе необходимо зарегистрировать приложение до 2 февраля 2014 года.

Зарегистрировать приложение и узнать подробнее о конкурсе можно на специальном сайте: www.appcup.eu

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

2 года назад два разработчика из Петербурга начали делать сервиc, который решает тривиальную, но вполне актуальную проблему: мониторинг JavaScript-ошибок в продакшене. Что из этого вышло и легко ли программисту стать стартапером постараемся рассказать в нашей истории. О менталитетах, двух долгих поездках в штаты, стартап-буллшите, интроверсии, победах и медном тазе, много ли денег $200K, почему iPad нужен чаще ноутбука и как получить год бесплатного хостинга.

Давайте знакомиться, нам есть что рассказать.

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


Хочешь вовлечь пользователя? Общайся с ним на его языке!

Хотя вопросы «состыковки» текста с кодом, несомненно, важны, один момент – очень деликатный! – часто остается без внимания, и это – качество перевода. Почему? Для этого есть объективные причины.

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

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

Вторая причина – приоритет кода перед текстом. Логично, что юзабилити, монетизация и графика ставятся во главу угла. В конце концов, пользователь приходит в игру не для того, чтобы читать! Да на буквы эти и внимания никто не обратит! (Возьмите конфетку если вы разработчик, и такие мысли никогда не приходили вам в голову – значит, вы на самом деле исключение из правил).

В эту ловушку попадаются многие – задачи по подготовке локализации и ее тестированию часто откладываются на самый последний момент.

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

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

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

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

Для меня этот проект стал первым, где надо было вплотную использовать SQLite (раньше он был нужен не более, чем для select <что-нибудь> <откуда-то>).

Задача такова: сканировать штрих-коды товаров, распознавать их, сверять со справочниками и выводить результат пользователю.

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