Дорого дня, уважаемые хабражители!

Сегодня я расскажу вам о том, как можно установить неподписанное (или плохо подписанное) приложение на устройство с iOS 9. Да, без Jailbreak. Да, бесплатно. Нужен лишь компьютер с OS X и Apple ID. Как такое возможно? Читаем под катом.



Осторожно! Много картинок!

Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.

Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.

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

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

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

На вопрос будущего Flash в рамках браузера Google Chrome отвечает Chris Campbell — продукт менеджер Adobe Flash Runtime Project.

Я не слышал, чтоб кто-то предложил полное блокирование Flash для использования.
Решение Google заключается в простой модели «Нажми для запуска» на уровне домена.
Если Вы один раз разрешили запустить Flash контент на конкретном сайте, то весь этот сайт (включая его iframe-ы) будет
запускать Flash содержимое без каких-либо дополнительных действий со стороны пользователя и при последующих визитах.
Google так же продолжит поставлять Flash Player в своих установках и обновлениях.

Под катом небольшая картинка на тему «Как работают журналисты».

Знаете ли вы что такое рейтрейсер? Это программа которая рисует трёхмерную сцену на экране так, как её бы увидели вы. Конечно, не совсем так, но некоторые рейтрейсеры умеют рисовать очень правдоподобные картинки, например как в "Аватаре".

Идея рейтрейсера очень простая и в этой статье я раcскажу как устроен этот алгоритм и даже напишу его на JavaScript. Картинки и пример прилагаются.

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

Знакомится будем на примере фреймворка akka используя язык java (сам akka написан на scala).

Как я уже писал в своей первой статье, не так давно я перешел c С++ на Scala. И вместе с этим я начал изучать модель акторов в исполнении Akka. Наиболее яркое впечатление на меня произвела лекгость реализации и тестирования конечных автоматов (finite-state machines, FSM), которую предоставляет эта библиотека. Уж не знаю, почему именно так получилось, учитывая изобилие остальных прекрасных и полезных вещей в Akka. Но теперь в моем первом проекте на Scala я использую конечные автоматы при каждой выпадающей возможности, подкрепленной целесообразностью (как я искренне надеюсь). И вот я решил, что готов поделиться с сообществом теми знаниями об Akka.FSM, а также некоторыми хитростями и личными наработками, которые я успел накопить. Подобной темы на хабре я не нашел (да и вообще со статьями про Scala и Akka здесь как-то не густо), и решил, не затягивая, исправить положение и выговориться, пока кто-то не сказал всего раньше меня. А чтобы было не скучно — предлагаю вместе реализовать поведение самого настоящего электронного кота. Хотелось бы верить, что какая-то одинокая романтическая душа, вдохновившись моей статьей, доработает предлагаемый в ней функционал до полноценного «Тамакотчи», в качестве домашнего задания. Главное, чтобы такая душа не забыла после поделиться своими результатами с сообществом в комментариях. В идеальном варианте можно было бы создать проект на гитхабе с общим доступом, чтобы каждый желающий смог привнести свой личный вклад в развитие идей трансгуманизма. А теперь — в сторону шутки и фантазии, закатываем рукава. Начинать мы будем с самого нуля, а я для пущего 7D и эффекта присутствия я буду проделывать каждый шаг вместе с вами. TDD прилагается: с неоттестированным робокотом уж точно будет не до шуток.

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

Перед тем как начать писать этот доклад я прочел больше 115 постмортемов и историй инди разработчиков. Что я понял? Во-первых, что мой английский отстой. Во-вторых что инди очень разные. Очень. И чтобы каталогизировать их понадобилась куча времени.

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

Раз за разом я вижу отблески самого себя в «молодых» программистах. Они сражаются с теми же концепциями, что и я когда-то, попадают в те же ментальные ловушки и, в общем-то, делают те же ошибки. Написав пост 4 wrong ways, я задумался, насколько распространены эти ошибки, и можем ли мы их категоризировать. Я попадался в каждую из этих ловушек хотя бы раз, в некоторые по нескольку и видел те же ошибки у других.

Приветствую, друзья!

О чем статья

В этой статье будет дано поверхностное описание системы тестирования мобильных приложений HockeyApp. Я расскажу как пройти путь от написания кода в ActionScript, до получения логов в системе HockeyApp. И познакомлю с ANE библиотекой FPHockeyApp. Если вы знакомы с системами тестирования приложений, можете сразу перейти к примерам использования библиотеки FPHockeyApp.

Суть проблемы

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

Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Построение перспективного искажения

Четвёртая статья будет разбита на две, первая часть говорит про построение перспективного искажения, вторая про то, как двигать камеру и что из этого следует. Задача на сегодня — научиться генерировать вот такие картинки:

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

Всем привет!

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

Недавно случайно наткнулся на ютубе на фильм с Брайаном Грином «Тайны мироздания» и удивился, что у видео так мало просмотров.

Не сказать, чтобы такая подача материала мне очень нравилась, но все равно, местами довольно интересно :) Может быть, будет интересно не только мне.

Сами видео под катом.

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

Два года назад познакомился с замечательнейшим фреймворком для разработки игр на Actionscript Ash (почти сразу после знакомства с ним, пришло понимание, что фреймворк подойдет под любой язык. А еще чуть-чуть позже появились порты фреймворка под другие языки — на момент написания перевода имеется 7 штук). Некоторое время распирало желание поделиться находкой с русскоязычным сообществом, пока меня не опередили переводом на Хабре. Теперь вдогонку хочу выложить перевод касательно реализации почти незаменимого паттерна Finite-State Machine для Ash Entity System фреймворка.

На Хабре уже есть очень много интересных статей про создание игры с нуля, но мало статей, описывающих что делать, чтобы своя любимая поделка не превратилась во Франкенштейна и дошла до вменяемого состояния. Автор оригинальной статьи рассказывает, как эволюционировал код игрового движка от кучи хлама в основном цикле к продуманной, расширяемой архитектуре, использующей Entity Component System. В статье много кода, который почти весь часто повторяется — но я не стал его выбрасывать, поскольку с ним будет понятнее, какие изменения вносит автор и как это отражается на всей структуре. Статья рассчитана на новичков, вроде меня, которые уже настрочили несколько «гениальных» прототипов, но теперь не знают, как разобраться в их коде.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

Добрый день!

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

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

Иногда возникают такие ситуации, когда нужно прочитать QR код, а смартфона под рукой нет. Что же делать? В голову приходит лишь попробовать прочитать вручную. Если кто-нибудь сталкивался с такими ситуациями или кому просто интересно как же читается QR код машинами, то данная статья поможет вам разобраться в этой проблеме.

В статье рассмотрены базовые особенности QR кодов и методика дешифрирования информации без использования вычислительных машин.

Иллюстраций: 14, символов: 8 510.

14 сентября прошла третья онлайн-конференция RuHaxe — регулярное мероприятие, посвященное языку Haxe и основанным на нём технологиям и инструментам.

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

Также в спойлер после второго доклада, добавлено продолжение про работу с Maven и haxemojos, опубликованное автором через несколько дней после конференции, как продолжение темы и ответ на дополнительные вопросы.