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

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

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

Вот, задался таким вопросом… С помощью гугл транслейта и такой-то матери, родилась такая блок-схемка:



картинка кликабельна

Кому нужен сорец (в .docx): тут

Компания EDISON Software профессионально занимается разработкой Android-приложений. Вот некоторые крупные проекты:

• Мобильные приложения виртуального сотового оператора
• Бронирование билетов на мероприятия
• Сервис доставки банковских уведомлений на смартфоны
• Приложение Vivaldi для работы с электронной библиотекой

Полезные статьи на Хабре по Android:

• Разработка быстрых мобильных приложений на Android. Часть первая
• Разработка быстрых мобильных приложений на Android. Часть вторая
• Шишки и грабли Android-разработчика за 2 года

(Пост из серии «просмотреть и добавить в избранное»)

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

Вот список 25 Android-библиотек, релиз которых состоялся в январе-феврале 2017 года. Все они достойны внимания, место в списке не определяется значимостью. Приступим!

В этой статье мы поговорим о «магической» константе 0x5f3759df, лежащей в основе элегантного алгоритмического трюка для быстрого вычисления обратного квадратного корня.

Вот полная реализация этого алгоритма:

float FastInvSqrt(float x) {
  float xhalf = 0.5f * x;
  int i = *(int*)&x;  // представим биты float в виде целого числа
  i = 0x5f3759df - (i >> 1);  // какого черта здесь происходит ?
  x = *(float*)&i;
  x = x*(1.5f-(xhalf*x*x));
  return x;
}

Этот код вычисляет некоторое (достаточно неплохое) приближение для формулы



Сегодня данная реализация уже хорошо известна, и стала она такой после появления в коде игры Quake III Arena в 2005 году. Её создание когда-то приписывали Джону Кармаку, но выяснилось, что корни уходят намного дальше – к Ardent Computer, где в середине 80-ых её написал Грег Уолш. Конкретно та версия кода, которая показана выше (с забавными комментариями), действительно из кода Quake.
В этой статье мы попробуем разобраться с данным хаком, математически вывести эту самую константу и попробовать обобщить данный метод для вычисления произвольных степеней от -1 до 1.

Да, понадобится немного математики, но школьного курса будет более, чем достаточно.

Часть 1
Часть 2
Часть 3
Часть 4

От переводчика: Предлагаю вашему вниманию перевод отчёта по одноплатным компьютерам, который был опубликован на сайте LinuxGizmos.com. В отчёт включены краткие описания 98 плат стоимостью до 200 долларов. В отчёте такие платы называют «хакерскими», чтобы подчеркнуть их пригодность для различного творчества.
Так как объем информации весьма велик, я разбил перевод на несколько частей.

Также хочу предупредить, что под катом очень много картинок!

Итак, часть 1.


КДПВ

В течение последнего года, LinuxGizmos сообщал о дюжинах новых одноплатных компьютерах с открытыми спецификациями, дружественных к разработчикам и «хакерам», на которых можно запустить Linux и Android. Мы добавили их в наш каталог вместе со старыми платами. Платы, попавшие в наш обзор, стоят меньше 200 долларов без учёта пересылки, доступны для доставки в июле этого года, и удовлетворяют нашим (весьма гибким) критериям открытости.

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

Приступим.

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

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

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

Сразу хочу сказать, что все книги на английском. Часть из них можно найти на русском, но без английского на уровне чтения и прослушивания подкастов будет тяжко – на русский клевые вещи об управлении продуктами переводят медленно и нехотя. Второй момент – чтение книг из этого списка не сделает из вас менеджера продукта. Как и книжка С++ за 21 день не сделает из вас С++ разработчика. Просто уровень вхождения в окологуманитарные профессии пониже, и это иногда создает напрасные иллюзии.

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

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

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



Есть только два фактора, которые определяют любое текущее состояние игры: механика (правила) и игроки своими действиями.

Уровень ядра

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

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

К сожалению, универсальных правил прохождения и проведения собеседования нет и быть не может, потому что сотрудников подбирают не только по их техническим навыкам и личностным качествам, но и по совпадению с некоторым (зачастую неявным и очень субъективным) «профилем», который, по мнению интервьюеров, вписывается в их команду или компанию. Что же касается руководств из серии «как правильно проходить собеседования», то они обычно вызывают не меньше боли в комментариях, потому что очень субъективны и обязательно задевают чьи-нибудь болевые точки.

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

А что на собеседованиях раздражает или напрягает вас? Поделитесь в комментариях.

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

Прочтите внимательно эту статью, если вы применяете упрощенную систему налогообложения с объектом налогообложения «доход» по ставке 6 процентов и продаете игры или приложения в Google Play, Apple App Store, а также прочий цифровой контент — например, 3D-модели — в Steam, Unity Asset Store или на других площадках, в условиях договоров с которыми фигурируют комиссии, агентские вознаграждения и прочие формы разделения выручки между сторонами.

Из материала вы узнаете:

• Почему разработчику желательно обладать хотя бы базовой юридической грамотностью
• Чем с точки зрения Гражданского кодекса являются игры и приложения и какие права на них есть у разработчиков помимо авторского права
• Что такое агентский договор и почему все это важно при работе по договору с Apple или Google
• Кто такой налоговый суслик и почему он может превратиться в пушного зверя
• Какой «подвох» существует для применяющих «упрощенку» в части определения налоговой базы
• Почему налог на добавленную стоимость (НДС) продолжает преследовать нас, даже когда мы не являемся его плательщиками
• Как, с точки зрения Федеральной налоговой службы, облагаются НДС внутриигровые покупки (InApp Purchases)

Существуют десятки способов повышения конверсии. Некоторые из них считаются чуть ли не «священными»:

— Избавляйтесь от слайдеров — они отвлекают;
— Делайте посадочную страницу как можно более короткой — пользователи не любят «портянки»;
— Просто увеличьте размер кнопки CTA, и будет вам счастье.

И еще много-много «правил», «законов», «стратегий».

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

В этой статье мы сделали перевод подборки от экспертов ConversionXL — это разрыв шаблона, 7 невероятных примеров, когда результаты a/b тестов опровергают самые «железные» приемы увеличения конверсии.

Сегодня кажется удивительным как маркетологи работали без интернета. Страшно подумать, что Дэвид Огилви и другие мэтры творили на бумаге, а целевая аудитория получала рекламу по почте. Не электронной) Каких-то 20-25 лет, а какой скачок в способах коммуникации с клиентами.

Некоторые принципы из XX века работают до сих пор. Например, формула AIDA «живее всех живых». Но многое сильно изменилось.

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

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

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



Кому интересно, добро пожаловать под кат.

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

Создание интерфейсов в проектировании больших сайтов – это самый объемный и один из самых важных этапов. Поэтому я отдельно решил выделить принципы и законы проектирования интерфейсов.

• Принцип KISS. От англ. «keep it short and simple». Интерфейс должен быть простой и понятный, задачи должны решаться минимальным числом действий, все должно быть понятно и очевидно.
• Не заставляйте думать. Нужно избегать сложных действий, которые заставляют пользователей думать.
• Убираем очевидное. Не стоит показывать очевидные элементы интерфейса, нужно сосредоточиться только на действительно необходимых вещах.
• Соотношение сигнал / шум. В каждом интерфейсе есть важные элементы (сигналы) и маловажные или даже бессмысленные для определенной части системы (шум), естественно, нужно концентрироваться на сигналах и избегать шума.
• Проверенное лучше модного. Не стоит цепляться за моду и делать что-то только потому, что так делают другие, лучше отдать предпочтение проверенным элементам интерфейса.

Для написания этой заметки  было затрачено:

• 68338 километров на поездки.
• 72 человеко-часа на почтовую переписку.
• 423 человеко-часа на эксперименты с коллективом в 30 человек.
• 88 часов на подготовку докладов и выступления на конференциях.
• 17 чашек кофе на беседу с мудрыми людьми на афтепати.
• Порядка 25 часов на набор этого текста и правку багов в нем :).
• До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.

Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.

Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять KPI (ключевые показатели эффективности). Работает так: вы, как владелец бизнеса, назначаете конкретные цели для сотрудников. Они достигают или не достигают поставленных целей в процессе работы. Тем, кто достиг — выдается плюшка (денежная премия).

Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!

Ну, логично же, что:

• Продажникам  нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
• Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.

А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.

Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:



Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.

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

Рассмотрим это на гипотетическом примере, близком к мобильному маркетингу. Допустим, что есть группа пользователей, из которых 5000 — пользователи iOS, а 10000 — Android. Средняя конверсия составляет 5%: 4% для iOS и 5,5% для Android. Согласитесь, что менеджер по продукту на основе этих данных может принять вполне конкретные решения …и совершить ошибку. Рассмотрим данные подробнее — с разбивкой по устройствам. Из пяти тысяч пользователей Apple в группе оказывается 1500 iPad (конверсия 6,67%) и 3500 iPhone (2,86%), а в группе платформы Google 8000 планшетов (6,25%) и 2000 смартфонов (2,5%). То есть выясняется, что конверсия в обеих группах устройств Apple оказывается выше, если рассматривать их в отдельности.



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

Чтобы избежать таких ошибок, не объединяйте разнородные группы. Ниже список критериев, которые нужно использовать в мобильном маркетинге для разделения данных на группы:
— регионы или страны;
— типы и платформы устройств;
— источники получения информации;
— поведенческие сигналы;
— дата установки (в случае изучения сезонности спроса).