Перевод оригинальной статьи за авторством Des Traynor

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



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

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

Короткому и понятному английскому слову «dialer» еще только предстоит обзавестись гармоничным, не режущим слух русским эквивалентом. Если вы заглянете в словарь, то в качестве перевода вам будет предложен зубодробительный «номеронабиратель». Однако в живом языке больше прижились слова «звонилка», «дозвонщик» и «дайлер». В рамках своей внутренней кухни мы привыкли использовать именно последний вариант, его мы и будем придерживаться в этом посте.

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

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

Но обо всем по порядку.

Всем доброго дня!

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

Изменять код
В процессе разработки программного обеспечения нет такого понятия, как «стагнация». Все, что вы разрабатываете сейчас — просто очередная версия компонента, который вероятно будет меняться в будущем. Изменение является самым распространенным явлением в мире разработки программного обеспечения и вам лучше принять это как факт. Рассчитывайте на возможные изменения всего, что вы разрабатываете и поэтому проектируйте ваш код более модульным. Это упрощает изменения и в тоже время увеличивает качество кода. Старайтесь придерживаться концепций DRY и YAGNI. Вы часто будете в ситуации, когда вы смотрите на ваш код и представляете, что вы могли бы сделать это лучше. Так пусть эта мысль не мешает вам спать. Садитесь сразу за дело и рефакторинг! Если не сделаете это сейчас, вы возможно никогда этого не сделаете. Чем дольше ждете, тем сложнее и дороже это будет. И это может вырасти в лишнюю головную боль, с которой не захочется связываться.
«Хороший код — это код, который легко изменять. Код стремится измениться до момента, когда его уже не легко изменять. Весь код становится плохим кодом». Неизвестный автор.

Вступление

Добрый всем, хочу рассказать про тёплую и ламповую стратегию детства — Противостояние. Игра была выпущена в 1996-98 гг нашей Российской фирмой Дока.
Игра — стратегия в реальном времени про вторую мировую войну. Спустя много лет я решил сперва пройти её и записать прохождение, а затем постараться по максимуму продлить удовольствие от игры, распаковывая ресурсы и пытаясь понять игровую логику.

Под катом я опишу процесс извлечения музыки, графики и немножко не дотяну до редактора карт.
Так же в описании будут отсылки на 8-битную палитру цветов, псевдоархивы, RLE-сжатие и чуток HEX-редактора. В самом коде я подсмотрел только алгоритм декодирования изображений, сжатых RLE.

Некоторые знают, что у нас есть API, программный интерфейс, позволяющий «общаться» с платформой hh.ru мобильным и десктопным приложениям, другим сайтам и просто виджетам, включая тот, что расположен справа от этой статьи на странице нашего блога.

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

Вольный перевод статьи Якуба Линовски — «A Good User Interface».

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

Уважаемые жители Хабра, спасибо, что зашли в наш блог за подробностями специальной акции. Мы разработали ее для вас, потому что хотим представить вам нашу карту QIWI Plastic (с июля она распространяется в новом черном дизайне). Вы можете оформить карту совершенно бесплатно. Для этого зайдите на страницу акции (ссылка выше) и получите там промо-код.

А теперь мы хотим на простых жизненных примерах рассказать вам, где и как вам может пригодиться QIWI Plastic.

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

• Плавная прокрутка
• Подгрузка областей карты

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

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

Буквально за несколько недель, с момента показа новой iOS 7, произошел легкий сдвиг в сознании не только у дизайнеров, но и у пользователей, имя ему — плоский дизайн. Этот прием, да, назовем его так, получил шквал критики и восхищения, у него появились сторонники и лютые ненавистники, но сегодня, я постараюсь рассмотреть новый, современный, набирающий огромную популярность подход при проектировании — long shadows (длинные тени).

(P.S. — Все картинки кликабельны).

Что такое длинные тени в дизайне, и как это понимать?

Цель урока. Научиться создавать тесты для кода. NUnit. Принцип применения TDD. Mock. Юнит-тесты. Интегрированное тестирование. Генерация данных.

Тестирование, принцип TDD, юнит-тестирование и прочее.

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

1. Мы делаем сайт, показываем заказчику, он высылает список неточностей и дополнительных пожеланий, мы их бодро правим и сайт отдаем заказчику, т.е. выкладываем на его сервер. На его сервер никто не ходит, заказчик понимает, что чуда не произошло и перестает платить за хостинг/домен. Сайт умирает. Нужны ли там тесты?
2. Мы делаем сайт, показываем заказчику, он высылает список правок, мы их бодро правим, запускаем сайт. Через полгода на сайте 300 уников в день и эта цифра растет изо дня в день. Заказчик постоянно просит новые фичи, старый код начинает разрастаться, и со временем его всё сложнее поддерживать.

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

Устоявшиеся мнения о преимуществах кросс-платформенной разработки с использованием HTML5 или Native SDK:

HTML5

• Лёгкое вхождение для веб-разработчиков
• Дешево в разработке
• Большое покрытие (браузер сейчас есть везде)
• Единая база кода

При помощи таких средств как, например, Cordova, на HTML5 можно создавать гибридные приложения (которые размещены не в интернете, а в нативном контейнере). Такие приложения совмещают перечисленные выше плюсы и посредством плагинов позволяют выйти за пределы браузера, осуществляя тесную интеграцию с возможностями устройств. Гибридные приложения можно публиковать и распространять через AppStore, Google Play и другие магазины приложений.

Native

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

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

Петер Сунде — один из основателей трекера The Pirate Bay, вместе со своими коллегами по Flattr.com Линусом Оллсоном и Лейфом Хёгбергом намерены создать мобильное приложение для обмена мгновенными сообщениями, которые не смогут читать спецслужбы и корпорации. Приложение называется Hemlis («секрет» по-шведски). Оно будет основано на проверенных технологиях, таких как XMPP и PGP, и совершенно бесплатно в базовом варианте. Продвинутые возможности, например, обмен фотографиями или, в перспективе, голосовой и видео-чат, будут доступны за деньги. В приложении не будет рекламы, а продажа персональных данных и прослушка будут невозможны технически — утверждает Петер Сунде. Единственный способ прочитать частную переписку — получить контроль над телефоном одного из собеседников.

На открытии DevCon 2013 (видеозапись открытия на русском и на английском) мы рассказали о том, что не только мы проводим конкурсы мобильных приложений, наши партнёры тоже это делают. И я рад рассказать чуть подробнее о конкурсе, который объявил Банк Тинькофф Кредитные Системы.

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

Итак, мы хотим написать нечто достаточно музыкальное.

CatBoard — это самодельная эргономичная компактная клавиатура с открытым исходным кодом, имеет множество нестандартных решений, таких как: нестандартная аппаратная раскладка со стандартными клавиатурными сочетаниями; быстрый автоповтор нажатой клавиши; Fn слой с клавишами управления курсором, цифровым блоком, функциональными клавишами; отдельные клавиши переключения раскладок; более удобное расположение Ctrl и Shift; отдельную кнопку AltTab; режим совместимости с Macintosh, позволяющий работать на нём точно так же, как и на PC; возможность прошивки без дополнительного оборудования; возможность устанавливать поверх ноутбучной клавиатуры. Благодаря открытому коду, с клавиатурой можно делать что угодно, новая прошивка заливается в считанные секунды, поэтому экспериментировать можно прямо на ходу.

Введение

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

Привет, жители Хабра. Несколько дней назад я выкладывал обзор GoPro Hero 3 Black Edition и историю компании Woodman Lans. Как оказалось, многим эта статья и этот ролик пришлись по душе, поэтому я решил не останавливаться. Мы взяли на тест квадрокоптер для GoPro под названием DJI Phantom, обзор которого в русскоязычном рунете я, пожалуй, еще не встречал.

Сегодня, 2 июля 2013 года, в 10:20 по Москве, Олег Куваев, «Папа Масяни» предложил народу скинуться на выпуск очередной серии досрочно: в последние несколько серий её спонсировал МедиаМаркт, а тут — аж до сентября отложили новый выпуск!
Сумма была заявлена в 100 тысяч рублей.

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

Такая же проблема встала и передо мной при проектировании высоконагруженного сервера системы мониторинга транспорта на .NET. В итоге, было принято решение, что кэшам – быть. Кэши словарей стали храниться в обёртках над ConcurrentDictionary. Этот вариант был взят без особых исследований, поскольку является стандартным средством .NET для потокобезопасных словарей. Теперь настало время проверить производительность данного решения. Об этом, собственно, статья. Также в конце статьи будет небольшое исследование того, как устроен внутри ConcurrentDictionary.