В Минкомсвязи считают, что операторы, выигравшие конкурс, не реализовали проект в полной мере. Поэтому министерство предлагает создать компанию со 100%-ным госучастием. Согласно пояснительной записке к проекту, на которую ссылается газета, новому оператору предлагается передать изъятые у победителей прошлогоднего конкурса частоты в диапазонах 720-750 мегагерц и 761-862 мегагерца, а также «все доступные и в дальнейшем высвобождаемые частоты в диапазонах 390-470 МГц и 694-876 МГц, сохранив при этом текущее распределение частот операторам связи в диапазоне 2500-2700 МГц».

via Риа Новости

Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.

Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.

Компания Intel представляет бесплатный комплект программного обеспечения для проектирования, разработки, отладки и оптимизации приложений под Android — Beacon Mountain. В состав комплекта входит как ПО Intel, так и сторонние утилиты. Общий список программ выглядит следующим образом:

• Intel Hardware Accelerated Execution Manager (Intel HAXM)
• Intel Graphics Performance Analyzers (Intel GPA) System Analyzer
• Intel Integrated Performance Primitives (Intel IPP) Preview
• Intel Threading Building Blocks (Intel TBB)
• Intel Software Manager
• Google Android SDK (ADT Bundle)
• Android NDK
• Eclipse Integrated Development Environment
• Android Design
• Cygwin (для Microsoft Windows)

Теперь весь этот софт можно установить за несколько кликов из одного дистрибутива. В состав Beacon Mountain входит средство обновления его компонентов — вам не придется отслеживать выход новых версий.
Beacon Mountain предназначен для разработки приложений как под процессоры ARM, так и под Intel Atom; поддерживаются версии Android от 4.2 и выше. Сам комплект работает на Windows 7 или 8; позднее планируется выпустить версию для Apple OS X.
Скачать Beacon Mountain с сайта Intel
Под хабракатом — небольшой видеоролик о новом продукте.

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

В наличии:
— Один усилитель с колонками
— Один стационарный компьютер
— Один ноутбук
— Желание слушать интернет радио независимо от двух предыдущих пунктов и перетыканию проводов

В результате родился план собрать «audio card over ethernet». Исследовав вопрос совместимости оборудования, я выбрал роутер TP-link MR3020 и USB аудио-карточку Creative SB Play.

Что из этого получилось:


О том, как это получить, добро пожаловать под кат.

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

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

Введение

Данная статья является продолжением цикла статей: Использование паттерна синглтон [1], Синглтон и время жизни объекта [2], Обращение зависимостей и порождающие шаблоны проектирования [3], Реализация синглтона в многопоточном приложении [4]. Сейчас я хотел бы поговорить о многопоточности. Эта тема настолько объемна и многогранна, что охватить ее всю не представляется возможным. Здесь я заострю внимание на некоторых практичных вещах, которые позволят вообще не думать о многопоточности, ну или думать о ней в крайне минимальном объеме. Если говорить точнее, то думать о ней только на этапе проектирования, но не реализации. Т.е. будут рассмотрены вопросы о том, как сделать так, чтобы автоматически вызывались правильные конструкции без головной боли. Такой подход, в свою очередь, позволяет значительно уменьшить проблемы, вызванные состояниями гонок (race condition, см. Состояние гонки [5]) и взаимными блокировками (deadlock, см. Взаимная блокировка [6]). Этот факт уже сам по себе представляет немалую ценность. Также будет рассмотрен подход, который позволяет иметь доступ к объекту из нескольких потоков одновременно без использования каких-либо блокировок и атомарных операций!

Вообще здесь должен был быть традиционный первый «корпоративный» пост о том, что мы уже ровно 7 лет занимаемся хостингом, что нашим профилем являются серверы, прежде всего, в Европе и США, что работая для русскоязычных клиентов и будучи международной компанией, мы сознательно отказываемся от серверов в России, и так далее. Однако новость прошлой пятницы заставляет поговорить о другом.

Сегодня я расскажу про то, как устроено взаимодействие с модемом в ОС Android. В данной статье описывается структура компонентов операционной системы Android, ответственных за сетевое взаимодействие по протоколам пакетной передачи данных – GPRS, EDGE, 3G и т.д.
Эта статья содержит большое количество теории, практика же будет во второй статье.

Описание слоя радиоинтерфейса

Рассмотрим, так называемый, слой радиоинтерфейса, от английского – Radio Interface Layer. В ОС Android представляет он представляет собой абстрактный слой между сервисом телефонии (android.telephony) и модемом.


Рисунок 1. Слой радиоинтерфейса.

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

Звонков было много, за следующую неделю я посетил 17 собеседований, по 3-4 в день, в четверг я уже перестал соглашаться на собеседования, а звонки все шли и шли.

Это не статья из серии, «смотрите как меня все хотят, я офигенен», я просто хочу сказать, что сейчас в России существует дефицит IT специалистов, и когда подходящий человек приходит к вам в компанию, важно не только то, насколько он понравится вам, но и то, насколько вы понравитесь ему, ибо мне кажется, что сейчас конкуренция существует скорее на вашей стороне, на стороне работодателей, чем на стороне программистов. Оговорюсь сразу, речь не пойдет о всяких Яндексах, ВКонтактах и Мэилру, там все ясно, речь идет о компаниях второго эшелона, предыдущей ступени.

Священный спор

Принято считать, что есть «вечные» вопросы, на которые нет правильного ответа. Например, что лучше: Windows или Linux, Java или C#; Чужой против Хищника или Чак Норрис против Ван Дамма.

Одним из таких холиваров считается выбор лучшей IDE для Java:


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

Так вот, я утверждаю, что это не просто дело вкуса. Есть объективные причины, почему

Intellij IDEA однозначно лучше, чем Eclipse.

Подчёркиваю, мы сейчас рассматриваем обе среды именно как Java IDE.

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

С чего начать?

Пишем своё первое приложение на Android
Пишем первое приложение для Android
Создаем файловый менеджер
Основы программирования под Android на примере игры Судоку
Создание приложения в стиле Android
Спокойной ночи!

В продолжении статьи о кроссплатформенной и кросс-аппаратной оптимизации, на примере задачи поиска полным проходом по таблице из 5 полей и 10 000 000 строк, и неизбежности этой задачи даже при индексном поиске, я покажу как ускорить такой поиск в 3.5-5.3 раза с использованием C++ независимо от аппаратной платформы.
В предыдущей статье нам удалось ускорить поиск в 1.3 раза: GitHub.com
Мы не будем банально описывать конструкции языка, а покажем преимущества C++ при решении одного из этапов реальной задачи.
Мы по-прежнему пишем кроссплатформенно под MSVC11(MSVS2012) и GCC 4.7.2, и используем в них C и частично реализованный стандарт C++11.
Для упрощения понимания мы все ещё пишем без индексного поиска, но это решение в дальнейшем будет использоваться при индексном поиске.

С удивлением обнаружил, что про явление алиасинга (aliasing) здесь постов нет. Ситуацию нужно исправить, тк. алиасинг в любой сколько-то сложной C++ программе обязательно хоть где-нибудь, да есть. Это может быть хорошо, давая возможность ловких оптимизаций, а может быть плохо, внося повышенной паршивости баги. Под катом вкратце про оба случая (ну и неизменное «компилятор бьет спина», конечно; для разнообразия сегодня это gcc).

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

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

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

По мотивам одного вчерашнего поста про оптимизацию условных переходов при расчете x=sign(a,b)*min(abs(a), abs(b)) якобы в 10 раз. Краткая сводка:

• оптимизация налицо, но размер мнимый: не в 10 раз, а 2.5 раза;
• бенчмарки надо делать правильно: не надо мерить CPU stalls, RAM bandwidth итп вместо исследуемой функции;
• бенчмарки надо делать правильно: иначе могут дико дрожать;
• выставлять только приоритет прикольно, но на коротких бенчмарках зря: +0.5% скорости, -15% дрожания;
• нужно мерить исследуемую функцию и только ее, только так получаешь корректные данные;
• нужно греть проц, нужно считать минимум из N прогонов/секунд, только так побеждаешь дрожание;
• нужно пользовать SSE, с ним получилось 8.6 раз, причем код… читается.

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

Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

При оптимизации времени выполнения алгоритма, использующего LDPC декодер, профайлер привел к функции, вычисляющей следующее значение:

где a и b — целые числа. Количество вызовов шло на миллионы, а реализация ее была достаточно

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

Итак, сегодня я хочу поговорить о книге профессора Гэвина Кеннеди «Договориться можно обо всём» и о том, как навык ведения переговоров помогает в профессиональной деятельности и повседневных активностях. Саму книгу я прочитал довольно давно, но только сейчас накопилось достаточное количество ярких примеров того, что указанные в ней практические советы эффективны и действуют почти безотказно.

Литий-ионные аккумуляторы не столь «привередливы», как их никель-металл-гидридные собратья, но все равно требуют определенного ухода. Придерживаясь пяти простых правил, можно не только продлить жизненный цикл литий-ионных аккумуляторных батарей, но и повысить время работы мобильных устройств без подзарядки.

Не допускайте полного разряда. У литий-ионных аккумуляторов отсутствует так называемый эффект памяти, поэтому их можно и, более того, нужно заряжать, не дожидаясь разрядки до нуля. Многие производители рассчитывают срок жизни литий-ионного аккумулятора количеством циклов полного разряда (до 0%). Для качественных аккумуляторов это 400-600 циклов. Чтобы увеличить срок службы вашего литий-ионного аккумулятора, чаще заряжаете свой телефон. Оптимально, как только показатель заряда батареи опустится ниже отметки 10-20 процентов, можете ставить телефон на зарядку. Это увеличит количество циклов разряда до 1000-1100.
Данный процесс специалисты описывают таким показателем как Глубина Разряда (Depth Of Discharge). Если ваш телефон разряжен до 20%, то Глубина Разряда составляет 80%. В нижеприведенной таблице показана зависимость количества циклов разряда литий-ионного аккумулятора от Глубины Разряда:


Разряжайте раз в 3 месяца. Полный заряд на протяжении длительного времени также же вреден для литий-ионных аккумуляторов, как и постоянная разрядка до нуля.

Эта поучительная история повествует о том, как важно развивать навыки гугления, и о том, как я боролся с ежечасным полным Garbage collection.

Краткое описание проблемы

После того, как мы мигрировали в продакшене один из компонентов системы (единственный, работающий на Tomcat) на новую версию томката, неожиданно саппорт запаниковал, увидев в логах полуторасекундные запуски GC.