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

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

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

Флагманским продуктом в этом направлении стало приложение для создания и управления базами данных для Android устройств.

Все статьи, прочитанные на эту тему (а их было немало), англо- и русскоязычные, в один голос утверждали, что необходимо в первые дни после публикации (1-3 дня) нагнать как можно больше посетителей на вашу страничку в магазине и заставить посетителей установить приложение. Приложение, показавшее быстрый рост в первые дни после публикации, привлекает внимание издателей, и есть шанс, что оно попадет в список Featured Apps в своей категории или даже в целом в магазине, что несомненно принесет еще больше пользователей и, как следствие, прибыли (вы же для этого разрабатывали свое мобильное приложение). Такая стратегия была оправдана, когда приложений в магазине было не так много и новые появлялись не со скоростью света.

Результат такого подхода выглядит примерно так:



Эффект кратковременный, и если за 3 дня вы не попали в желаемый список Featured apps, считайте, что усилия и затраты не оправдались. Количество установок неминуемо снизится в разы.

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

Довелось как-то раз отлаживать вот такой код на C#, который «на ровном месте» падал с NullReferenceException:

	public class Tester {
		public string Property { get; set; }
		public void Foo() {
			this.Property = "Some string"; // NullReferenceException
		}
	}

Да, вот на этой самой строчке с присвоением свойства падал NullReferenceException. Что за дела, думаю — неужели рантайм перестал проверять наличие экземпляра перед вызовом экземплярных методов?

Как оказалось — в некотором роде да, перестал. Правда, и компилятор оказался не тем, за кого себя выдаёт, да и проверки вовсе не гарантированы рантаймом… Подробнее — под катом.

Это статья о том, как мы делали систему защиты браузерной HTML5 игры от взлома и подделки результатов, с какими трудностями мы при этом столкнулись, как их решали и что получили в итоге. Основной и всем знакомой проблемой таких игр является возможность написания бота, который эту игру автоматически пройдет. Разработку подобного бота облегчает тот факт, что код игры находится в публичном доступе. Ситуация осложнялась тем, что были объявлены реальные призы, среди которых iPad, билеты на концерт, USB флеш накопители и т.п.



Статья будет полезна в основном тем, кто делает HTML5 / Flash игры и заботится об их безопасности; тем, кто платит за разработку этих игр; и немного тем, кто призван бороться с ботами. Ну и, конечно, тем, кто написал эту статью. Потому что мы надеемся, что она станет началом продуктивной дискуссии о том, как разработчики браузерных игр могут противостоять кибер-мошенникам.

Что такое фильтры исключений?

Фильтры исключений (Exception Filters) — новая фича C# 6, которая позволяет устанавливать специфические условия для блока catch. Этот блок будет исполнятся только в случае, если указанные условия выполнены. Проиллюстрируем синтаксис небольшим фрагментом кода:

public void Main()
{
  try
  { 
    throw new Exception("E2");
  }
  catch(Exception ex) when(ex.Message == "E1")
  {
    Console.WriteLine("caught E1");
  }
  catch(Exception ex) when(ex.Message == "E2")
  {
    Console.WriteLine("caught E2");
  }
}

Каждый C#-разработчик знает, что C#-компилятор переводит исходный код программы в промежуточный язык под названием Intermediate Language (IL). А за превращение IL в последовательность машинных команд чаще всего отвечает Just-In-Time-компилятор (JIT). Да, на сегодняшний день есть NGen, Mono AOT, .NET Native, но JIT-компиляция всё ещё лидирует в мире .NET-приложений. А вот работает этот самый JIT, знают далеко не все. Если брать в расчёт только реализацию .NET от Microsoft, то стоит различать JIT-x86 и JIT-x64. А ещё за дверями стоит RyuJIT который уже совсем скоро займёт почётное место основного JIT-компилятора. А если вы любите старые версии .NET, то полезно знать, что в разных версиях CLR логика работы JIT отличалась. Исходники у нас теперь открыты, вы можете их посмотреть и осознать, насколько же это большая и сложная тема. Сегодня мы не будем пытаться охватить её, а лишь кратко посмотрим на несколько интересных особенностей отдельных версий JIT-компиляторов. Итак, сегодня в номере:

• Почему короткий метод может не быть заинлайнен и как этого избежать
• JIT-баги: опасные и беспощадные
• Кто и как разматывает циклы
• Чем отличается размотка маленьких и больших циклов

Чем больше я пишу на C# 6, тем больше убеждаюсь в том, насколько оператор ?. (null coalescing operator) помогает писать чистый простой и понятный код. Сегодня я покажу 4 ситуации, в которых он может быть очень полезен.

Большая вложенность

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

var location = default(string);
if (vendor != null)
{
    if (vendor.ContactPerson != null)
    {
        if (vendor.ContactPerson.HomeAddress != null)
        {
            location = vendor.ContactPerson.HomeAddress.LineOne;
        }
    }
}

Но теперь у нас есть C# 6, с ним код можно привести на намного более читаемому виду:

var location = vendor?.ContactPerson?.HomeAddress?.LineOne;

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

Есть такой язык программирования, который называется C#. И есть очень много разработчиков, которым он очень нравится. А ещё есть такой язык программирования, который называется JavaScript. Как-то так сложилось, что он нравится далеко не всем C#-разработчикам. А теперь представьте ситуацию: есть заядлый C#-разработчик. Он очень любит C#, все-все проекты на нём пишет. Но судьба распорядилась так, что ему понадобилось написать клиентское веб-приложение. Знаете, такое, чтобы пользователю не нужно было себе ничего скачивать и устанавливать, чтобы он мог просто открыть любой браузер в любой операционной системе на любом устройстве — а приложение уже там. И вот тут у нашего лирического героя возникла проблема: вроде бы JavaScript идеально подходит для этой задачи, но вот писать на нём отчего-то не очень хочется. К счастью, в современном мире существует много языков, которые транслируются в JavaScript (всякие TypeScript, CoffeScript и тысячи других). Но наш разработчик оказался очень упрямым: он упорно не хочет изменять своему любимому C# с «вражескими» технологиями.

К счастью для него, счастливое будущее уже практически наступило. Есть такой проект, который называется DuoCode. Он умеет транслировать C#-код в JavaScript. Пока он в состоянии beta, но у него уже весьма неплохо получается: поддерживаются нововведения C# 6.0, Generic-типы, Reflection, структуры и LINQ, а отлаживать итоговый JavaScript можно на исходном C#. Давайте посмотрим внимательнее, что же представляет из себя продукт.

В последнее время многие обсуждают недавние открытие CoreCLR и CoreFX от Microsoft. Напомню, что ядро CLR и реализация базовых классов .NET у нас теперь открытые, кроссплатформенные и распространяются под MIT. Таким образом, вы можете собрать свою собственную версию рантайма, которая будет работать под Windows, Linux и Mac. И многих терзал вопрос: а что же теперь будет с Mono? Недавно появились черновики Mono 4.0.0 Release Notes, из которых мы можем узнать о будущих планах компании Xamarin. Итак, сегодня в номере:

• Adoption of Microsoft’s open source code
• Floating point optimizations
• We dropped support for the 2.0, 3.5 and 4.0 assemblies
• Updated IKVM

Обсудим грядущие изменения чуть подробней.

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

Данная статья посвящена оптимизациям компилятора Visual C++. Я собираюсь обсудить наиболее важные техники оптимизаций и решения, которые приходится применить компилятору, чтобы правильно их применить. Моя цель не в том, чтобы рассказать вам как вручную оптимизировать код, а в том, чтобы показать, почему стоит доверять компилятору оптимизировать ваш код самостоятельно.

От переводчика: мы в компании Энтерра очень любим алгоритмы компьютерного зрения. Работаем чаще всего с OpenCv. Время от времени нам пишут разные разработчики с вопросами: «А как лучше начать работать с OpenCv?» или «Какую интересную задачу можно просто решить с помощью OpenCv?» В связи с чем мы решили перевести очень хорошую статью, которая будет полезна всем, кто интересуется компьютерным зрением.



Черная Пятница близко.

Толпы злых покупателей. Рой одинаковых теток среднего возраста, готовых сожрать практически всё, что угодно, в ближайшем супермаркете — главное, что со скидкой 75%. Они выстроятся в очереди перед дверьми магазинов в полночь Дня благодарения. Они будут ломиться внутрь, стучать в запертые двери кулаками и головами, пока не сплющат друг друга и не разобьют руки в кровь, став похожими на зомби из «28 дней спустя». Но вместо человеческой плоти, они жаждут удовлетворить инстинкт покупателя. Их боевые кличи о скидках и распродажах достигают небес. А их громовая поступь способна привести к землетрясению на Великой Равнине.

Естественно, от СМИ помощи не жди — они будут смаковать каждую подробность. От обмороженных семейств, ночевавших в палатке на морозе, до старой леди, растоптанной охотниками за скидкой в момент, когда открылись двери. Что-то похожее случилось с галлимимусом в «Парке Юрского периода». А она просто хотела купить Halo для девятилетнего внука Тимми, чьи родители забыли это сделать в прошлом году. В Wal-Mart. Во время Черной Пятницы.

И я обязан спросить: весь этот хаос и бедлам стоят того?

Чёрт возьми, нет!

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

Просто представьте, как глупо вы будете выглядеть, стоя в очереди в ожидании свободной кассы – только для того, чтобы после сканирования штрихкода последнего сезона «Игры Престолов» выяснить, что в Target его можно купить на 5 долларов дешевле?

Собственно, далее я покажу, как можно обнаружить штрихкод на изображении, используя только Python и OpenCV.

С каждым днём кроссплатформенная разработка под .NET становится всё более реальной. А после недавнего анонса официальной поддержки Linux/MacOS счастливое будущее стало ещё немножечко ближе. Вышеприведённая картинка утратила свою былую актуальность, ведь исходники теперь будут под MIT. Впрочем, писать кроссплатформенные .NET-приложения можно достаточно давно — в этом нам помогает Mono. Но вот отношение к нему в сообществе довольно неоднозначное. Мне зачастую приходится слышать изречения вроде «Mono тупит, под него всё в три раза медленнее работает» или «Под Mono вообще нормально ничего не запускается». Причём очень редко доводится слышать от этих людей конкретные факты. Вопросы «А что конкретно тупит?» или «А что конкретно не работает?» повергают их в ступор. Не всех (некоторые способны на конструктивную дискуссию), но большинство. Чаще всего начинаются возмущённые ответы в духе «Да вообще ничего не работает! А если и работает, то очень медленно!». В конце беседы создаётся впечатление, что каждая конечная машинная команда под Mono работает в несколько раз медленнее, а в половине исходников стоят throw new Exception().

В этом посте мне хотелось бы немножко поделиться опытом. Не так давно мы портировали наш продукт PassportVision (анонс на Хабре) под Linux. Могу заявить, что работает он вполне нормально. Да, чутка медленнее, чем под Windows на классическом .NET от Microsoft (далее — MS.NET). Но работает вполне стабильно, а падение производительности не принципиальное. При этом продукт у нас достаточно большой и вполне попадает под категорию enterprise, а возможности C#/.NET мы используем на полную катушку. Так что завести большое серверное приложение под .NET реально — было бы желание. Также мне довелось беседовать с разными разработчиками, которые пишут что-то под Mono — истории в большинстве своём успешные.

Но почему же тогда встречается столько негатива в сторону Mono? Я считаю, что проблема в том, что люди не особо хотят разбираться в разнице между рантаймами. Запустили разок какое-нибудь .NET-приложение под Linux на Mono 2.4, а оно с ходу не запустилось — всё, Mono целиком плохой, не будем его использовать. А в итоге виноват оказывается один-единственный метод, у которого реализация немного отличается от MS.NET. Новые версии Mono выходят раз в пару месяцев, реализацию уже давно поправили, но люди всё равно продолжают ходить и хаять бедный Mono, не желая разбираться в деталях.

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

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

Один из лучших способов это сделать — семантическое версионирование (semver). В практическом плане, для разработчиков и инструментов разработки, SemVer дает представление о рисках, связанных с переходом на новую версию программного обеспечения. Номера версий представлены в формате MAJOR.MINOR.PATCH, где каждый из трёх компонентов – целое число. Согласно SemVer, если меняется номер MAJOR, это указывает на существенные изменения API, с которыми разработчикам нужно быть очень осторожными.

Эта концепция версионирования обрастает нюансами, если говорить о jQuery, ведь совместимость с браузерами может быть так же важна, как совместимость API. В попытке создать более изящную jQuery, команда выпустила две версии в 2013 году. Первая осталась в линейке 1.* (сегодня это 1.11.1) и обеспечивает совместимость с максимальным количеством браузеров. Вторая версия, начиная с 2.0.0 и до сегодняшней 2.1.1, исключает поддержку ряда браузеров типа IE8 и ниже, чтобы оптимизировать код. Как 1.*, так и 2.* версии jQuery имеют одинаковый публичный API, хотя в их внутренней реализации есть некоторые различия.

Наши будущие релизы будут использовать другую номенклатуру. Как прежде, речь идет о двух разных пакетах. Преемником сегодняшней версии 1.11.1 будет jQuery Compat 3.0. Преемником jQuery 2.1.1 станет jQuery 3.0. Речь идет о двух разных пакетах на npm и Bower, но при этом они будут иметь одинаковую версию, чтобы обозначить тот факт, что их API одинаков.

Мы — небольшой стартап в Чарльстоне, Южная Каролина. Мы принимаем заказы с помощью текстовых сообщений и распечатываем их непосредственно в ресторанах.

Мы запустили eatabit.com в Чарльстоне почти год назад. За это время наш API распечатал более 9300 заказов на еду у наших клиентов — это рестораны, стадионы, курсы гольфа. Работа с мобильной связью не отличается простотой — особенно в зонах с повышенной нагрузкой на сеть, как на стадионах во время матчей, но наши системы отслеживают ситуации вроде плохого качества сигнала или разрывов.

Вне всяких сомнений, Pro Git — это одна из лучших книг про систему контроля версий git. Совсем недавно появилось второе издание этой замечательной книжки. Большие изменения произошли в издательском процессе: исходный код книги теперь хранится в AsciiDoc, а не в Markdown, а различные форматы (PDF, ePub и Mobi) автоматически генерируются с помощью O'Reilly Atlas platform. Разработка книги активно ведётся на гитхабе, актуальная online-версия находится в открытом доступе на официальном сайте, а любители печатной продукции могут заказать себе экземпляр на Amazon. Второе издание получилось почти в два раза больше первого: на сегодняшний день PDF-версия содержит 570 страниц. Помимо улучшения старого материала, книжка также пополнилась новыми главами и разделами:

Сегодня мы поговорим о региональных настройках. Но сперва — небольшая задачка: что выведет нижеприведённый код? (Код приведён на языке C#, но рассматривается достаточно общая проблематика, так что вы можете представить на его месте какой-нибудь другой язык.)

Console.WriteLine((-42).ToString() == "-42");
Console.WriteLine(double.NaN.ToString() == "NaN");
Console.WriteLine(int.Parse("-42") == -42);
Console.WriteLine(1.1.ToString().Contains("?") == false);
Console.WriteLine(new DateTime(2014, 1, 1).ToString().Contains("2014"));
Console.WriteLine("i".ToUpper() == "I" || "I".ToLower() == "i");

Сколько значений true у вас получилось? Если больше 0, то вам не мешает узнать больше про региональные настройки, т. к. правильный ответ: «зависит». К сожалению, многие программисты вообще не задумываются о том, что настройки эти в различных окружениях могут отличаться. А выставлять для всего кода InvariantCulture этим программистом лениво, в результате чего их прекрасные приложения ведут себя очень странно, попадая к пользователям из других стран.Ошибки бывают самые разные, но чаще всего связаны они с форматированием и парсингом строк — достаточно частыми задачами для многих программистов. В статье приведена краткая подборка некоторых важных моментов, на которые влияют региональные настройки.

Проектирование интерфейсов — ремесло очень сложное. Увы, не очень понятно, как этому ремеслу учиться. Разумеется, на сегодняшний день существует огромное количество разных хороших книжек про разные хорошие подходы к этому самому проектированию. Однако практика подсказывает, что даже если вы их все вдумчиво прочитаете, то это не будет означать, что вы будете уметь в любой ситуации создавать идеальный UI. А всё дело в том, что подобная деятельность скорее является своего рода искусством, нежели следованием набору правил. Но как же этим искусством овладевать, если хорошие книжки не дадут необходимых навыков? Нам кажется, что ключевым фактором в этом деле всё-таки является опыт. Но учиться только на своём опыте — занятие долговременное, лучше бы и на других людей поглядывать (и это далеко не только к интерфейсам относится).

Давайте немного поговорим о том, как правильно перенимать чужой опыт. У нас есть много знакомых команд, которые разрабатывают действительно крутые приложения. И при показе нам своих интерфейсов они начинают рассказывать, что и как они сделали. А мы всегда спрашиваем, почему они так сделали, почему они пришли именно к такому решению. И нам кажется, что это самый правильный вопрос. Да, бывают гениальные люди, которым без всякой матчасти во сне привидится идеальный интерфейс без разного рода тяжёлых размышлений о том, как делать хорошо, а как делать плохо. Но таких людей мало, а на подобном опыте многому не научишься. Образное мышление действительно развивается, когда тебе рассказывают о мотивации каждого своего решения (даже самого маленького). Мол, мы сначала сделали так и так, но пользователям было неудобно ввиду вот этого, поэтому мы переделали всё вот так, и теперь все живут счастливо.

В этом посте мы хотели бы рассказать историю одной формочки, которую мы сделали при разработке нашего продукта PassportVision (о котором уже рассказывалось на Хабре). Это одна-единственная небольшая формочка, но мы её делали целый год. Насколько хорошо у нас получилось — судить вам, но пользователи весьма довольны (а разве не это критерий удачного интерфейса?). Мы многократно переделывали разные штуки, горячо спорили о разных мелочах, но в конце концов получилось то, чем удобно пользоваться. Впрочем, нам думается, что через год мы взглянем на этот пост, взглянем на наш к тому времени уже старый UI и скажем: «О Господи! Мы что, действительно отдавали это пользователям? Ох, стыдно, как же стыдно». Но всё правильно — интерфейс постоянно должен развиваться, эволюционировать, становиться лучше. А сегодня мы поговорим о том, что имеется на сегодняшний день и как же мы к этому пришли.

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

Если вы хоть немного разделяете мои ощущения, то нам есть о чём поговорить. Дело в том, что со временем что-то внутри меня начало подсказывать, что рефакторить всё подряд, везде и всё время — не самая лучшая идея. Поймите меня правильно, код должен быть хорошим (а лучше бы ему быть идеальным), но в условиях суровой реальности не всегда разумно постоянно заниматься улучшением кода. Я вывел для себя несколько правил о своевременности рефакторинга. Если у меня начинают чесаться руки что-нибудь улучшить, то я оглядываюсь на эти правила и начинаю думать: «А действительно ли сейчас тот момент, когда нужно нарефакторить?». Давайте порассуждаем о том, в каких же случаях рефакторинг уместен, а в каких — не очень.

Не так давно состоялся релиз Scala 2.11.0. Одним из примечательных нововведений этой версии являются квазицитаты — удобный механизм для описания синтаксических деревьев Scala с помощью разбираемых во время компиляции строк; очевидно, что в первую очередь этот механизм предназначен для использования совместно с макросами.

Удивительно, но на хабре пока тему макросов в Scala рассматривают не слишком-то активно; последний пост
с серьёзным рассмотрением макросов был аж целый год назад.

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

Практика code review или, если перевести на русский язык, инспекций кода появилась давно и уже успешно встроена в процессы разработки во многих компаниях. Команды программистов таких компаний, как Google, Square, Amazon, активно ее используют, и у них нет даже мысли о том, чтобы от нее отказаться. В то же время, в большом количестве компаний эту практику или совсем не применяют, или применяют от случая к случаю.

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

Данный текст создан на основе моего выступления на GRWebDev. Это история проекта, который был отменен и похоронен в GitHub, а также рассказ об уроках, извлеченных в ходе работы над ним.