Началось все с того что Adsense в очередной раз понизил оценку эффективности страниц:

А все мы знаем, что скорость сайта – один из факторов ранжирования в выдаче Гугла.

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

Изначально имеется сайтик со статьями, коих в интернете миллионы: CMS Wordpress 4.2, два десятка плагинов, тема, сверстанная фрилансером и shared хостинг.

Перевод поста Джона Маклуна (Jon McLoone) "Doing Spy Stuff with Mathematica".
Код, приведенный в статье, можно скачать здесь.
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе.

---

Я читал о IT проблемах недавно арестованных, как заявлялось, русских шпионов. Говорилось, что они пользовались не самыми надёжными инструментами цифровой стеганографии (вики). И мне стало интересно — насколько быстро я смогу реализовать стеганографию через цифровые изображения в Mathematica, используя метод, известный как "вставка младшего бита" (least significant bit insertion).

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

Чем привлекателен запуск Мастерноды Dash в качестве источника пассивного дохода для держателей криптовалюты Dash?

Во-первых, Мастерноду можно запустить даже на простейшем микрокомпьютере Raspberry Pi, очень маленьком и дешёвом (альтернативное решение — её можно запускать на выделенном сервере или VPS).
А во-вторых, владелец Мастерноды получает вознаграждение за поддержание работы сети Dash, которое на текущий момент приносит 17% годовых (в DASH).

Имея некоторый опыт в тестировании, обнаружила, что аналитики и программисты часто не уделяют внимание некорректным переходам между состояниями сущностей. Что это значит на практике? Например, вы можете удалить то, что уже было удалено, отредактировать уже отправленное и т.д. Такого рода действия могут привести к необработанным исключениям, в том числе ошибкам на уровне БД. Почему надо обрабатывать такие ошибки? Как минимум, плохо показывать пользователю информацию о логической структуре БД. Такие ошибки чаще всего свойственны многопользовательским системам, где несколько пользователей могут редактировать один и тот же объект. В этой статье я расскажу, как проектировать тесты для проверки переходов между состояниями объекта и как быстро оценивать затраты на такое тестирование.

Данный протокол уже много где описан. Я хочу показать и подробно описать свою реализацию на конкретном микроконтроллере. Мне было необходимо принимать сигнал с пульта RGB — такого, как на картинке. Его система команд приведена внизу статьи.

Краткий экскурс

Каждый пакет протокола NEC состоит из стартовой последовательности – импульса длиной 9 мс и паузы длиной 4,5 мс. Дабы не грузить вас теоретическими рисунками, покажу реальные скриншоты с логического анализатора.

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

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

Предыстория

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

• Открытый исходный код
• Реал тайм рендеринг мира в игровом движке
• Поддержка основных платформ (mobile, web, desktop)
• Желательно C# как основной язык разработки

Все началось с того, что в квартире наконец поставили счетчики воды (4 импульсных счетчика, так как 2 стояка) и встал вопрос как проще всего снимать показания. А если учесть что одна пара счетчиков оказалась внутри шкафа кухни, то было принято решения попробовать это автоматизировать.

На просторах интернета можно найти устройство с 1-wire шиной на пару счетчиков по не очень гуманной цене порядка 2500 рублей. Так же это решение требовало вести провода к устройству обработки, что тоже не радовало.

Изыскания на тему, как сделать самом данное устройство, привели сначала к arduino + esp8266 в качестве wifi передатчика, а после погружения в тему оказалось, что сам esp8266 может прекрасно справиться с данной задачей.

Доступ к устройствам, подключенным к Интернет через сеть мобильного оператора возможен в настоящее время только с использованием технологии обратного VPN. Поэтому, для организации удаленного видеонаблюдения через сети 3G/4G нам необходимы два компонента:

• Маршрутизатор с поддержкой протокола туннелирования. В нашем варианте это VPN — OpenVPN.
• Сервер, который будет принимать подключения от удаленных 3/4G и предоставлять к ним доступ для клиентов из сети Интернет.

В данной статье мы рассмотрим настройки маршрутизатора на стороне веб-камеры (DVR).

    Относительно не так давно появилась замечательная библиотека Espresso для тестирования UI Android приложений. Её преимущества над аналогами обозревались не один раз. Если вкратце, то они заключаются в том, что это разработка Google для собственной ОС (ранее они сами использовали Robotium), а так же в лаконичности синтаксиса и скорости работы. Итак, мы решили идти в ногу со временем и использовать Espresso. Но нам мало тех плюсов, что уже есть, мы хотим BDD (http://en.wikipedia.org/wiki/Behavior-driven_development), мы хотим скриншотов и отчетов в json и html, мы хотим запускать это все на CI, в конце концов! Но обо всем по порядку. Я расскажу как подружить Cucumber (http://habrahabr.ru/post/62958/) и Espresso (http://habrahabr.ru/post/212425/) на небольшом примере. Всех, кто устал от Appium, кто хочет уйти от Robotium и тех, кому небезразлично тестирование Android, прошу под кат.

Я уже несколько лет занимаюсь разработкой небольших мобильных проектов на движке Unity3D и иногда заглядываю в Asset Store для покупки полезных ассетов. Недавно я решил попробовать создать какой-нибудь ассет для продажи в этом магазине и посмотреть что из этого выйдет.

После изучения категорий ассетов в Asset Store, я остановился на Complete Projects. В этой категории продаются завершенные проекты и шаблоны игр для самых ленивых разработчиков. Я решил сделать один из таких шаблонов, предназначенный для создания простенькой танковой аркады. Вот что из этого вышло:

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

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

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

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

На Хабре уже было немало материалов о том, как проводить качество вёрстки веб-проектов (вот отличная статья на эту тему) — как правило, речь в таких топиках идёт о коммерческих сайтах. В ходе развития образовательного проекта HTML Academy мы также столкнулись с необходимостью выработки критериев для оценки работ учеников.

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

Приветствую, Хабр!

В этой статье я постараюсь разжевать, что делать с дампами в Java, как понять причину или приблизиться к причине возникновения OOM, посмотреть на инструменты для анализа дампов, инструмент (один, да) для мониторинга хипа, и вообще вникнуть в это дело для общего развития. Исследуются такие инструменты, как JVisualVM (рассмотрю некоторые плагины к нему и OQL Console), Eclipse Memory Analyzing Tool.
Очень много понаписал, но надеюсь, что всё только по делу :)

Резюме

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

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

Продолжаем делать полезные и не очень смарт/умные/bluetooth девайсы на ардуино. В предыдущих статьях я рассказывал как сделать bluetooth машинку, bluetooth вольтметр и bluetooth пульт для телевизора, а сегодня речь пойдет о создании более модного, но менее полезного девайса. Этот давайс позволяет постить в instagram показания термометра с указанием точного времени и места производимых замеров температуры. Сначала покажу как это выглядит и работает на видео, а подробное описание будет уже под катом.

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

Здесь мы создадим новую систему Arch Linux, способную загружаться по сети и автоматически запускать браузер Firefox, а между делом разберёмся с необходимой функциональностью загрузочного сервера. Потом настроим сам сервер и попробуем с него загрузиться. Всё произойдёт в точности, как на картинке, которую нашёл гугл по запросу «PXE»: