К сожалению, в стандартной библиотеке языка С++ нет никаких средств для работы с протоколом HTTP. Возможно, в будущем появятся, но на данный момент каждый раз при необходимости дёрнуть какой-нибудь REST-сервис, пропарсить веб-страничку, написать простенького бота или краулера приходится задаваться вопросами «А какую же библиотеку взять, так чтобы побыстрее и попроще?». Иногда проект уже использует какой-то фреймворк (а иногда даже несколько) и тогда приходится вспоминать «А как же сделать HTTP-запрос имеющимися средствами?». Чтобы не путаться я решил написать для себя шпаргалку с примерами HTTP-запросов на С++ с применением разных библиотек. А самое удобное место для хранения подобных шпаргалок — Хабр: и сам не потеряешь, и другим может пригодиться.

Будут рассмотрены:

• WinInet
• WinHttp
• Casablanca
• Qt
• POCO
• wxWidgets
• Boost.Asio
• libcurl
• neon
• .NET (С++/CLI)
• IXMLHTTPRequest
• HappyHttp
• cpp-netlib

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

«Государь» Макиавелли — одно из моих самых любимых произведений. Являясь руководством непосредственно правителю, я считаю, эту книгу обязан прочесть каждый начальник/директор. И хотя она уже устарела, думаю было бы весьма полезно держать ее советы у себя в голове.

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

«Было бы неплохо структурировать», — подумал я.

Результатом мысли стал алгоритм принятия решения, представленный в картинке ниже и созданный исключительно по «Государю». Остальные советы, которые не определены ни под одну ситуацию и которые должны выполняться в любом случае, поданы ниже списком. Уверен, каждый сам сможет экстраполировать рекомендации правителю на должность руководителя.

28 октября в Москве мы проводим свою первую конференцию мобильных разработчиков #MBLTDev. Мы уже рассказывали, что на конференции выступят зарубежные и российские представители PayPal, ВКонтакте, Artsy, Parallels, ТКС банка, Typhoon, Soundcloud, Intel, ViaForensics, Одноклассников, Aviasales, Realm и других. Сегодня же подробнее расскажем о трех докладах.




Александр Черный выступит с докладом «Трилатерация с помощью iBeacon» и расскажет:

• Какие биконы есть на рынке и как их купить
• Что доступно через CoreLocation, а что только через CoreBluetooth
• Насколько это точный прибор и какие проблемы есть при его использовании
• Можно ли использовать чужой бикон для своих целей или еще как-то вредить

В конце выступления Александр продемонстрирует трилатерацию со сцены.

Есть такая интересная задача — построение 3D структуры по набору изображений (фотографий) — Structure from Motion. Как её можно решить? После некоторых размышлений приходит на ум такой алгоритм. Найдём на всех изображениях характерные особенности (точки), сопоставим их друг с другом и триангуляцией найдём их трёхмерные координаты. Тут правда есть проблема — неизвестно положение камер при съёмке. Можно ли их найти? Вроде можно. Действительно, пусть у нас N точек на кадре и M кадров. Тогда неизвестных будет 3 * N (трёхмерные координаты точек) + 6 * (M — 1) (координаты камер (вместо 6 может стоять другое число, но сути это не меняет)). Уравнений же у нас 2 * M * N (у каждой точки на каждом изображении есть две координаты). Выходит, что уже для двух изображений и 6 точек задачка разрешима. Под катом описание принципиальной схемы решения задачи SfM (по возможности без формул — но со ссылками для вдумчивого изучения).

Хожу по job interview. Где-то скучно, где-то весело. Где-то интересно. На одном из таких меня попросили написать функцию, которая умеет складывать два числа. Я написал:

  it ('should add two numbers', function () {
    var add = function (a,b) {
      return a + b;
    };

    assert.equal(add(2,3), 5);
  });

А если, говорят, сигнатура функции должна быть типа такой: add(num1)(num2)? Не вопрос, говорю. Думая, что хитрый буржуин хочет проверить, знаю ли я про то, что можно возвращать функции из функций, пишу вот такое:

  it ('should be called like add(num1)(num2)', function () {
    var add = function (a) {
      return function (b) {
        return a + b;
      };
    };

    assert.equal(add(2)(3), 5);
  });

В iOS 6 Apple представили замечательную возможность для вёрстки UI для iOS-приложений — Auto Layout. Но вот что удивительно, до сих пор очень немногие проекты используют эту возможность. А ведь это очень сильный инструмент, если с умом подойти к вёрстке UI, можно сэкономить очень много времени на подстраивании элементов для 3,5” и 4” экранов, портретно-ландшафтном расположении экрана и даже на универсальной вёрстке для iPhone и iPad.

И это всё не считая того, что скоро представят iPhone 6 и никто до сих пор точно не знает, какое там будет разрешение и какой экран. Лучше бы заранее подстраховаться.

В основном, тема Auto Layout довольно простая, и изучить её несложно. Но лично я столкнулся с большой проблемой при расположении элементов в UIScrollView. Я потратил немало времени и нервов на изучение того, как же правильно расположить элементы и указать размер контента для того чтобы ScrollView начал пролистываться.

Хоть и решение довольно простое, но на него не так просто выйти. В данной статье я бы хотел рассказать, как же всё-таки правильно готовить UIScrollView в Auto Layout.

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

Load average может представлять собой непростой для понимания показатель производительности сервера. В этой статье мы попытаемся дать некоторое представление о том, что означают те величины, которые можно найти в выводе команды «top» и в других linux-командах. В статье, также объясняются параметры специфичные для виртуального хостинга, которые обычно не отображается в стандартном выводе команды top.

Проблематика

При разработке мобильных игр многие сталкиваются с необходимостью уменьшения занимаемой оперативной памяти или размера дистрибутива. Чаще всего самые тяжеловесные ассеты в проекте это текстуры. Несжатая текстура размером 1024х1024 занимает в районе 4 Мб. А в сцене обычно таких текстур не мало. И если мы хотим, чтобы сцены нашей игры загружались быстрее и не занимали слишком много оперативной памяти, мы вынуждены подвергать текстуры компрессии. В unity3d для мобильных устройств существует несколько типов сжатия. Думаю, описанный здесь подход для повышения качества результата компрессии текстур будет справедлив для всех алгоритмов, но рассматривать мы будем на примере PVRTC. У него есть один большой плюс, и один большой минус. Размер текстур уменьшается в восемь раз, но при этом появляются ужасные артефакты, особенно на прозрачных текстурах. Данная тема призвана помочь в борьбе с последними.

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

Игру мы писали на Unity, а сама графика — спрайтовая. Но многое из сказанного ниже будет справедливо также и для других кросс-платформенных движков, а так же — для полноценного 3D.

Начну я свой рассказ с заблуждения.

Миф о кросс-платформенности.

Когда мы с командой начинали разработку этого проекта на большом и очень кросс-платформенном движке Unity (который также поддерживает Win, Mac, XBox, PS3, PSP, и т.п.) — то мы надеялись на то, что Unity возьмет всю заботу о кросс-платформенности на себя, а наша задача будет только жать «publish» под разные платформы и пить кофе.

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

Но не все так просто.

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

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

[Статья Armin Ronacher о принципах вычисления коллизий в сетевых шутерах. Носит скорее обзорный и исследовательский, нежели технический характер. Здесь и далее в квадратных скобках примечание переводчика]

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

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

Доброго времени суток!
Вам когда-нибудь хотелось узнать как устроены файлы PNG? Нет? А я все равно расскажу.
Формат PNG(Portable Network Graphics) был изобретен в 1995 году, чтобы стать заменой GIF, а уже в 1996, с выходом версии 1.0, он был рекомендован W3C, в качестве полноправного сетевого формата. На сегодняшний день PNG является одним из основных форматов веб-графики.

Под катом вы найдете общее описание строения PNG-файла, некоторое количество картинок-схем, препарирование в hex-редакторе, и, конечно, ссылку на спецификацию.