[FF D8]

Вам когда-нибудь хотелось узнать как устроен jpg-файл? Сейчас разберемся! Прогревайте ваш любимый компилятор и hex-редактор, будем декодировать это:

Специально взял рисунок поменьше. Это знакомый, но сильно пережатый favicon Гугла:

Последующее описание упрощено, и приведенная информация не полная, но зато потом будет легко понять спецификацию.

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

[FF D8] — маркер начала. Он всегда находится в начале всех jpg-файлов.

Следом идут байты [FF FE]. Это маркер, означающий начало секции с комментарием. Следующие 2 байта [00 04] — длина секции (включая эти 2 байта). Значит в следующих двух [3A 29] — сам комментарий. Это коды символов ":" и ")", т.е. обычного смайлика. Вы можете увидеть его в первой строке правой части hex-редактора.

Вы правильно поняли из названия, что это не совсем обычное описание алгоритма JPEG (формат файла я подробно описывал в статье «Декодирование JPEG для чайников»). В первую очередь, выбранный способ подачи материала предполагает, что мы ничего не знаем не только о JPEG, но и о преобразовании Фурье, и кодировании Хаффмана. И вообще, мало что помним из лекций. Просто взяли картинку и стали думать как же ее можно сжать. Поэтому я попытался доступно выразить только суть, но при которой у читателя будет выработано достаточно глубокое и, главное, интуитивное понимание алгоритма. Формулы и математические выкладки — по самому минимуму, только те, которые важны для понимания происходящего.

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

Если есть желание, то предлагаю пройти те же этапы самостоятельно параллельно со статьей. Проверить, насколько приведенные рассуждения подходят для разных изображений, попытаться внести свои модификации в алгоритм. Это очень интересно. В качестве инструмента могу порекомендовать замечательную связку Python + NumPy + Matplotlib + PIL(Pillow). Почти вся моя работа (в т. ч. графики и анимация), была произведена с помощью них.

Внимание, трафик! Много иллюстраций, графиков и анимаций (~ 10Мб). По иронии судьбы, в статье про JPEG всего 2 изображения с этим форматом из полусотни.

В последнее время на Хабре появилось множество статей о нейронных сетях. Из них очень интересными показались статьи о Перцептроне Розенблатта: Перцептрон Розенблатта — что забыто и придумано историей? и Какова роль первого «случайного» слоя в перцептроне Розенблатта. В них, как и во многих других очень много написано о том, что сети справляются с решением задач, и обобщают до некоторой степени свои знания. Но хотелось бы как-то визуализировать эти обобщения и процесс решения. Увидеть на практике, чему там научился перцептрон, и почувствовать, насколько успешно ему это удалось. Возможно, испытать горькую иронию относительно достижения человечества в области ИИ.
Языком у нас будет С#, только потому что я недавно решил его выучить. Я разобрал два наиболее простых примера: однослойный перцептрон Розенблатта, обучаемый коррекцией ошибки, и многослойный перцептрон Румельхарта, обучаемый методом обратного распространения ошибки. Для тех, кому, как и мне, стало интересно, чему они там на самом деле обучились, и насколько они на самом деле способны обобщать – добро пожаловать под кат.

ОСТОРОЖНО! Много картинок. Куски кода.

Прошлой осенью работа над моими побочными проектами зашла в тупик: я практически не продвигался вперёд и у меня никак не получалось делать больше, не принося в жертву свою основную работу в Khan Academy.

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

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

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


Иллюстрация Стивена Резига

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

К сожалению, статья будет достаточно тяжелая для обычного прикладного программиста, не интересующегося тематикой защиты ПО, но тут уж ничего не поделать.

Для более или менее адекватного восприятия статьи потребуется минимальные знания ассемблера (его будет много) а так-же навыков работы с отладчиком.

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

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

В качестве реципиента, по совету одного достаточно компетентного товарища, я выбрал немножко старый (но не потерявший актуальности, в силу качества исполнения) keygenme от небезызвестного Ms-Rem.

Вот первоначальная ссылка, где он появился: http://exelab.ru/f/index.php?action=vthread&forum=1&topic=4732
А потом он попал вот сюда: http://www.crackmes.de/users/ms_rem/keygenme_by_ms_rem/
Где данному keygenme был выставлена сложность 8 из 10 (*VERY VERY* hard).
Хотя, если честно, это слегка завышенная оценка — я бы поставил в районе 5-6 баллов.

Пожалуй, начнем.

Доброго времени суток.

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

На дворе 2014 год, доля Android JellyBean перевалила за 60%, появились новые тренды в дизайне. В общем, случилось много всего интересного. Но синхронизация данных с сервером осталось неотъемлемой частью большинства приложений. Существует много способов реализации ее в приложении. Android предоставляет нам SyncAdapter Framework, который позволяет автоматизировать и координировать этот процесс и предоставляет множество плюшек в довесок.

Account

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

Краткое резюме преимуществ:

• Поддержка фоновых механизмов вроде SyncAdapter
• Стандартизация способа авторизации
• Поддержка различных токенов (прав доступа)
• Шаринг аккаунта с разграничением привилегий (возможность использовать один аккаунт для различных приложений, как это делает Google)

Шаги для получения плюшек:
1) Создание Authenticator'а
2) Создание Activity для логина
3) Создание сервиса для общения с нашим аккаунтом

Всем привет!
Продолжаю перевод книги John Torjo «Boost.Asio C++ Network Programming». Вторая глава получилась большая, поэтому разобью ее на две части. В этой части мы поговорим именно про основы Boost.Asio, а во второй части речь пойдет про асинхронное программирование.

Содержание:

• Глава 1: Приступая к работе с Boost.Asio
• Глава 2: Основы Boost.Asio
  
  • Часть 1: Основы Boost.Asio
  • Часть 2: Асинхронное программирование
• Глава 3: Echo Сервер/Клиент
• Глава 4: Клиент и Сервер
• Глава 5: Синхронное против асинхронного
• Глава 6: Boost.Asio – другие особенности
• Глава 7: Boost.Asio – дополнительные темы

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

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

Habrahabr::instance()->sup(tr("Good morning, %1").arg(username));

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

Qt — кросплатформенный фреймворк для разработки приложений и пользовательского интерфейса на С++ с использованием технологий QML (декларативного языка на манер JavaScript & CSS). Ранее поддерживался Trolltech, пока его не купили Nokia, которые продали его Digia — замечательной компании, которая открывает кьюту невероятные возможности.

• Полноценная поддержка Android *
• Полноценная поддержка iOS *
• Десктопные Qt Quick Controls доработаны
• Баги виджетов исправлены (+ пара новых няшных элементов)
• Qt Windows/Mac Extras — интеграция с нативным кодом для этих платформ
• Поддержка Bluetooth на Linux
• Увеличена производительность рендера Qt Quick (QML)
• Множество фиксов для OS X Mavericks
• Модуль Accessibility доступен и на Android

* — за исключением пару очень узких функций, которые недоступны из-за лицензий/правил/etc

Полный текст релиза: blog.qt.digia.com/blog/2013/12/12/qt-5-2-released-the-best-qt-yet
Узнать все о вкусняшке и скачать ее, собсно, можно тута: qt-project.org

P.S. В голове не уложилось, когда позавчера собрал свое десктопное qml приложение под Android, затем под iOS-cимулятор и все это добро работало — начинается новая эра...

TLDR: как определять, есть ли в типе метод с данным именем и сигнатурой, а также узнавать другие свойства типов, не сойдя при этом с ума.

Здравствуйте, коллеги.
Хочу рассказать о SFINAE, интересном и очень полезном (к сожалению*) механизме языка C++, который, однако, может представляться неподготовленному человеку весьма мозгоразрывающим. В действительности принцип его использования достаточно прост и ясен, будучи сформулирован в виде нескольких чётких положений. Эта заметка рассчитана на читателей, обладающих базовыми знаниями о шаблонах в C++ и знакомых, хотя бы шапочно, с C++11.
* Почему к сожалению? Хотя использование SFINAE — интересный и красивый приём, переросший в широко используемую идиому языка, гораздо лучше было бы иметь средства, явно описывающие работу с типами.

Этим постом мы хотели бы начать цикл статей, посвященных задаче изменения голоса. В зарубежной литературе данную задачу часто именуют термином voice morphing, в отечественной литературе данная задача ещё не получила достаточного освещения как в научных, так и в инженерных кругах. Тема является достаточно обширной и во многом творческой. В результате работы в данном направлении у нас накопился определенный опыт, который мы планируем систематизировать и изложить, а также передать основную суть некоторых алгоритмов.



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

P.S.
Добавил дополнительные ссылки на первоисточники

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

Похожие системы пишет под себя огромное количество разработчиков, даже прослеживаются некоторые тенденции:

• большинство тяготеют к управлению проектами, т.е. уклон в область совместной работы, постановки задач другим пользователям и прочим видам collaboration
• подходы к определенным вопросам очень сильно похожи на лидеров рынка (Google calendar с его принципами установки повторения задач, к примеру). Мало кто делает нормальное древовидное представление задач, т.к. коли это не особо распространено, то значит и не особо востребовано. Но я почему-то всегда попадаю в ту группу пользователей, которым не хватает возможности что-то подкрутить, порыться в настройках. Отдельная песня – идеология Apple, где в большинстве случаев настройки программы сводятся к паре галочек. Иногда такой подход даже обижает.

Мы долго не могли понять почему каждый норовит сделать свой собственный сервис для управления списками дел и почему мы тоже стали жертвой этого стремления, но работа над нашим GTD-приложением, о котором пойдет речь ниже, помогла нам прийти к гипотезе.
Оглянитесь вокруг, много ли вы знаете туду-сервисов? — Тьма. А пользуетесь каким-нибудь? — Вероятно. Но все ли вас в нем устраивает? Скорей всего — нет.
Наверняка вы знаете уйму недостатков в сервисе, с которым работаете ежедневно, но продолжаете пользоваться им потому, что ничего лучше вы все равно еще не нашли. Если вы — разработчик, настает день когда вы понимаете, что настало время «точить пилу» и вы начинаете делать свой таск-менеджер. Постойте, но почему?

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

Веками для запоминания чего либо использовалась бумага. Она хорошо выполняет свою роль по двум причинам: во-первых, она, как известно, все стерпит, а во вторых, она ничего не навязывает. Иными словами, бумага сочетает в себе функциональность и простоту. Глубоко проникнувшись этой идеей, мы сделали свой продукт.
Что мы понимаем под этим? Эйнштейн говорил «Сделай настолько просто, насколько это возможно, но не проще.» Мы, следуя этому принципу реализовали все фундаментальные инструменты управления делами, но в тоже время мы сделали их максимально обобщенными и ненавязчивыми. Именно поэтому, если вам нужен некоторый инструмент, то вы сможете пользоваться им применительно к любой предметной области, а если он вам не нужен, то вы даже можете не заметить его существования. Т.е. мы не навязываем методологию, мы просто даем набор идеально заточенных инструментов.

Дальше меньше общих слов и больше технологических подробностей. Картинка клибельна.

Табличные элементы управления (обычно в их названии присутствуют слова Table или Grid) широко используются при разработке GUI. Так получилось, что на работе мы используем С++ и MFC для разработки пользовательского интерфейса. В начале мы использовали CGridCtrl — общедоступную и довольно известную реализацию грида. Но с некоторого времени он перестал нас устраивать и появилась на свет собственная разработка. Идеями, лежащими в основе нашей реализации, я хочу с вами здесь поделиться. Есть задумка сделать open source проект (скорее всего под Qt). Поэтому данную заметку можно рассматривать как «Proof Of Concept». Конструктивная критика и замечания приветствуются.

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

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


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

После одного игрового проекта со стримом всего процесса разработки мне часто пишут начинающие разработчики, что-то спрашивают, что-то показывают и на что-то жалуются. Недавно мне пришлось влезть в спор двух ребят, где темой спора было: “Что круче знать 3д-моделирование или программирование, если собираешься разрабатывать игры?”. Влез к ним в спор с предложением сделать первый шаг из схемы, что родилась в процессе участия в игровых проектах и создания своих.

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

Хабралюди, добрый день!
Сегодня хочу начать написание ряда лекций с практическими заданиями по книги Михаеля Привата и Роберта Варнера «Pro Core Data for iOS», которую можете купить по этой ссылке. Каждая глава будет содержать теоретическую и практическую часть.



Содержание:

• Глава №1. Приступаем (Практическая часть)
• Глава №2. Усваиваем Core Data
• Глава №3. Хранение данных: SQLite и другие варианты
• Глава №4. Создание модели данных
• Глава №5. Работаем с объектами данных
• Глава №6. Обработка результатирующих множеств
• Глава №7. Настройка производительности и используемой памяти
• Глава №8. Управление версиями и миграции
• Глава №9. Управление таблицами с использованием NSFetchedResultsController
• Глава №10. Использование Core Data в продвинутых приложениях

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


Быстро разбогатеть и уплыть на собственный остров просто, увы, лишь в мечтах.

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

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

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