Мы устали от разработки коммерческих проектов — корпоративных сайтов, порталов и каталогов. Захотелось чего-то яркого, интересного, легкого. А еще нужного и полезного людям. И мы подумали: «А ведь классный онлайновый клавиатурный тренажер — это то, что нужно!»

Так родилась идея сделать Ratatype — лучший в мире онлайновый клавиатурный тренажер.

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

Год назад мы, украинская студия Room 8, начали делать свою первую игру под названием Cyto. Ни у кого в команде практически не было опыта гейм-девелопмента и разработки приложений под iOS, зато у всех были амбиции сделать что-то реально офигенное. Учиться всему пришлось буквально на ходу и иногда мы чувствовали себя слонами в посудной лавке:)

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



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

В статье будут рассмотрены особенности работы низкоуровневого API для работы со звуком в iOS, с которыми пришлось столкнуться при разработке Viber. Речь пойдет о выборе размера аппаратного буфера и поведении AudioUnit при изменений частоты дискретизации.

Для программной работы со звуком в iOS Apple предоставляет 4 группы API, каждая из которых предназначена для решения определенного класса задач:

• AVFoundation позволяет проигрывать и записывать файлы и буферы в памяти с возможностью использовать предоставляемые платформой аппаратные или программные реализации некоторых аудио-кодеков. Рекомендуется использовать, когда нет жестких требований к низкой задержке проигрывания и воспроизведения.
• OpenAL API предназначено для рендеринга и воспроизведения трехмерного звука а так же использования звуковых эффектов. Применяется, в основном, в играх. Обеспечивает низкую задержку воспроизведения, но не предоставляет возможности записывать звук.
• AudioQueue базовое API для записи и воспроизведения аудиопотоков с возможностью использования кодеков, предоставляемых платформой. Используя это API, не получится получить минимальную задержку, но пользоваться им крайне просто.
• И наконец AudioUnit, мощное и богатое API, для работы со звуковыми потоками. По сравнению с Mac OS X на iOS программисту доступно не полностью, но для записи и воспроизведения звука как можно ближе к «железу» подходит лучше всего.

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

Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.

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

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

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

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

Многие читатели Хабра знакомы с внутренней кухней разработки ПО, а ведь железо — это совсем другая история. Готовы? Тогда поехали.

Прошлой осенью, вернувшись из отпуска, я обнаружил, что Дехана, наш Product Manager в UserVoice, заменила мой любимый «Roadmap» в Google Docs на доску Trello.

Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».

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

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

Продолжение перевода серии статей «5 уроков просмотра стартапов»,
прошлая статья Настоящие нечестные конкурентные преимущества

На сотнях стартап питчей в Capital Factory, не нашелся и десяток людей, которые были бы готовы сказать «если вы создадите этот продукт, я дам вам X долларов».



Задумайся над этим: сотни людей готовы уволиться с постоянной работы, потратить свои сбережения, рискнуть личной репутацией, трудиться 70 часов в неделю, пережить такой же стресс, как и рождение ребенка (поверьте мне, я испытал рождение и ребенка, и стартапов)… и все это при том, что нет жалкого десятка людей, действительно готовых заплатить за то, что предлагают стартаперы.

Недальновидно, не правда ли?

Раньше я как-то не стремился глубоко изучать jQuery, поскольку работаю в основном с back-end. Однако самоучитель TRYjQuery, ссылка на который пришла в недавнем письме от CodeSchool, вызвал интерес с первых кадров.

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

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

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

Пройдемся по дизайну, серверным решениям, тестированию и аналитике.

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

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

И так приступим...

Эта глава будет посвящена известному гему Omniauth. Omniauth это новая система идентификации поверх Rack для мультипровайдерной внешней идентификации. Он будет использован для связи CommunityGuides (прим: в настоящий момент ресурс не доступен и похоже уже не вернется) с Facebook, Google, Twitter и Github. Данная глава покажет как интегрировать все это с существующей идентификацией через Devise.

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

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

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

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

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

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

Самые крутые инструменты — универсальны, с их помощью можно решать самые разнообразные задачи. Примеры таких инструментов — документы и таблицы Google, ментальные карты Mindmeister, доски Realtimeboard. Вы можете их приспособить для чего угодно, особенно таблицы. Придумать и сделать такой инструмент сложнее всего. Я расскажу о еще одном универсальном инструменте, который мы активно используем — Tom's Planner.

В этой короткой заметке я хотел бы систематизировать (а именно, расположить в иерархию) многие популярные принципы проектирования программных приложений (test-driven development, ООП, SOLID и т. д.), а также рассмотреть следствия из этой иерархии.

В частности, такая иерархия (я надеюсь) позволит лучше расставлять приоритеты в разработке и профессиональном росте, лучше понимать старые технологии и быстрее изучать новые. При появлении новой парадигмы разработки (a la test-driven development) вы сможете быстро включить ее в эту иерархию и, следовательно, быстрее понять, из каких принципов исходили создатели парадигмы и как правильно ее использовать. Новичкам в программировании статья может быть полезна как обзор существующих принципов.

И в качестве самого базового я полагаю разумным считать принцип «управления сложностью/минимизации технической сложности» МакКоннела. А самыми важными срествами минимизации сложности являются модульность и абстракция.

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.