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

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

Меня давно мучает мысль об одной проблеме — тотально злоупотребление массивами в PHP. Возможно корень проблемы в процедурном наследии PHP или в том, что PHP привлекает большое количество неопытных разработчиков, не знаю. Но дело в том, что очень многие используют массивы там, где должны использоваться объекты!

Взглянем на типичный пример ужасающего, на мой взгляд кода, злоупотребляющего массивами. Для примера, предположим, мы извлекаем данные из БД и работаем с ними посредством массива. Вот такие примеры я вижу ежедневно:

Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» развиваем биллинг для операторов связи «Гидра» и уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.

Разрабатывая и тестируя сайт, зачастую замечаешь не все js-ошибки. Это происходит по ряду причин:

• отсутствие консоли в некоторых мобильных и планшетных браузерах;
• открытая консоль мешает при тестировании, перекрывая видимую часть страницы;
• консоль открывают когда страница уже загрузилась и ошибки, возникающие при загрузке, теряются (Firebug в Firefox, Internet Explorer);
• при разработке часто отключают логирование ошибок в системах аналитики, чтобы не было лишнего «шума» при анализе ошибок;
• и прочее.

5-го марта 2016-го года в городе Джэксонвилл закончился очередной съезд комитета ISO C++. Люди собирались предварительно-окончательно решать, что же войдёт, а что не войдёт в стандарт С++17. Конечно, ещё не 2017-ый год и кое-что ещё, возможно, переиграется. Тем не менее, есть мнение, что именно данное мероприятие очертило С++17 в его будущем виде.

Я не буду тут тянуть кота за хвост и искать толерантные выражения: нас ждёт катастрофа. Стандарты С++11/14 были очень значительным скачком вперёд, но на этом всё закончилось. С++17, обещанный когда-то «мажорным» релизом, по факту не несёт в себе ничего существенного. Немного синтаксического сахара, пару мелочей в стандартную библиотеку — и на этом всё. Отголоски данной трагедии уже звучали некоторым эхо на Хабре, но я всё-таки решил обобщить информацию и понять, куда мы катимся.

На Хабре уже упоминали об одной известной уязвимости, связанной с переменной $_SERVER['HTTP_HOST']. Только почему-то говорилось об SQL-инъекциях и о чем угодно, кроме XSS.

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

<script type="text/javascript" src="<?=$_SERVER['HTTP_HOST']  ?>/my.js"></script>

Допустим, адрес вашего сайта "www.user.com". Допустим, адрес моего сайта "www.hacker.com". Все, что мне нужно сделать, — это скинуть вам ссылку на специальную страницу моего сайта, откуда я сделаю самый обычный редирект на ваш же собственный сайт. Только для редиректа использую немного необычные заголовки. В качестве HTTP-target я укажу ваш собственный сайт "www.user.com", а вот в качестве хоста — мой "www.hacker.com". Хотя, в принципе, в абсолютной форме HTTP-target нет ничего необычного.

Заголовки примут вид:

GET http://www.user.com HTTP/1.1
Host:www.hacker.com

И ваш скрипт вместо SERVER['HTTP_HOST'] подставит мой хост. Ваша ссылка src="<?=$_SERVER['HTTP_HOST'] ?>/my.js" примет вид не как вы ожидали "www.user.com/my.js", а "www.hacker.com/my.js". В результате чего с моего сайта ваш браузер с чистой совестью скачает скрипт и выполнит его.

А я получу ваши cookie.

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

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

Как правило, язык C++ используют там, где требуется высокая скорость работы. Но на C++ без особых усилий можно получить код, работающий медленнее какого-нибудь Python/Ruby. Именно подобным кодом оперируют многочисленные сравнения Any-Lang vs C++.

Вообще, оптимизация бывает трех типов:

1. Оптимизация уже готового, проверенного и работающего кода.
2. Изначально написание оптимального кода.
3. Просто использование оптимальных конструкций.

Специально заниматься оптимизацией готового кода следует только после того, как проект закончен и используется. Как правило, оптимизация потребуется только в небольшой части проекта. Поэтому сначала нужно найти места в коде, которые съедают большую часть процессорного времени. Ведь какой смысл ускорять код, пусть даже на 500%, если он отнимает только 1% машинного времени? И следует помнить, что, как правило, гораздо больший выигрыш в скорости дает оптимизация самих алгоритмов, а не кода. Именно про данный ее вид говорят: «преждевременная оптимизация — зло» (с).

Второй тип оптимизации — это изначальное проектирование кода с учетом требований к производительности. Такое проектирование не является ранней оптимизацией.

Третий тип даже не совсем оптимизация. Скорее это избегание неоптимальных языковых конструкций. Язык C++ довольно сложный, при его использовании частенько нужно знать, как реализован используемый код. Он достаточно низкоуровневый, чтобы программисту пришлось учитывать особенности работы процессоров и операционных систем.

Список составили разработчики Java, C++ и JavaScript библиотеки libphonenumber для парсинга, форматирования и проверки телефонных номеров

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

1. Телефонные номера, действительные сейчас, останутся действительными всегда. Телефонные номера определённого типа (например, мобильные), никогда не сменят тип.

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

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

Каждый интересующийся шаблонами в С++ скорее всего слышал об их Тьюринг-полноте и связанных с этим шутках про «we put a language in your language, so you can program while you program». В этом посте я расскажу как с помощью шаблонов и константных выражений построить настоящую машину Тьюринга, вычисляющую результат своей работы во время компиляции, на которой можно будет запускать уже существующие программы. Например усердный бобер с 4 состояниями и 2 символами выглядит как-то так:

ADD_STATE(A);
ADD_STATE(B);
ADD_STATE(C);
ADD_STATE(D);

ADD_RULE(A, Blank, 1, Right, B);
ADD_RULE(A, 1, 1, Left, B);

ADD_RULE(B, Blank, 1, Left, A);
ADD_RULE(B, 1, Blank, Left, C);

ADD_RULE(C, Blank, 1, Right, Stop);
ADD_RULE(C, 1, 1, Left, D);

ADD_RULE(D, Blank, 1, Right, D);
ADD_RULE(D, 1, Blank, Right, A);

using tape = Tape<Blank>;
using machine = Machine<A, 0, tape>;
using result = Run<machine>::type;

int main() {
    print(result());
    return 0;
}

На выходе, как и положено, получаем

1 _ 1 1 1 1 1 1 1 1 1 1 1 1 

Тут можно посмотреть на код: https://ideone.com/MvBU3Z. Желающие узнать как все устроено внутри, добро пожаловать под кат.

Проект не содержит Ардуино


Этот проект изначально должен был выглядеть иначе — монументальное сооружение, состоящее из тумбы с канистрами и насосами, водружённого на неё аквариума и помидорного оазиса поверх него. В райских кущах помидорного оазиса планировался водопад, а в аквариуме — рыбные формы жизни, главное требование к которым — умение поедать незапланированных жителей аквариума и держать в чистоте стёкла; основные кандидаты — сомики и гурами. Как вы уже могли догадаться, мой девиз — «лень — двигатель прогресса» (и чего только не сделаешь, чтобы аквариум не чистить и помидоры не поливать).

Компилятор avrgcc поддерживает C++, однако в его поставку не входит ни стандартная библиотека, ни реализация ABI: служебных функций, вызовы которых вставляет сам компилятор. В результате люди пытаются реализовать те части, которые им нужны, самостоятельно и зачастую делают это не очень хорошо. Например, часто предлагается отстрелить себе ногу определив пустую функцию __cxa_pure_virtual(void) {} или подложить себе грабли, написав заглушки для __cxa_guard_acquire, __cxa_guard_release и __cxa_guard_abort. В данной статье я предлагаю разобраться, чего не хватает для счастья, где это взять или как написать.
Я знаю, что немло людей считает, что C++ на микроконтроллере не нужен. Их я прошу прочитать последний раздел статьи перед тем, как писать комментарии.

От переводчика

В мире победили языки высокого уровня и в мирах руби-питон-js разработчиков остается только разглагольствовать, что в плюсах не стоит использовать то или иное. Например, исключения, потому что они медленные и генерируют много лишнего кода. Стоило спросить "и какой же код он генерирует", как в ответ получил мямленье и мычание. А и правда — как же они работают? Ну что ж, компилируем в g++ с флагом -S, смотрим что получилось. Поверхностно разобраться не сложно, однако то, что остались недопонимания — не давали мне спать. К счастью, готовая статья нашлась.

На хабре есть несколько статей, подробных и не очень (при этом все равно хороших), посвященных тому, как работают exceptions в C++. Однако нет ни одной по-настоящему глубокой, поэтому я решил восполнить этот пробел, благо есть подходящий материал. Кому интересно как работают исключения в C++ на примере gcc — запаситесь pocket-ом или evernote, свободным временем и добро пожаловать под кат.

В нашем блоге на Хабре мы уже рассказывали о различных исследованиях, направленных на создание алгоритмов прогнозирования цен акций, к примеру, с помощью машинного обучения. Еще в 2013 году исследователи из бизнес-школы Уорика (Warwick Business School) опубликовали результаты эксперимента, в ходе которого в качестве инструмента для прогнозирования трендов фондового рынка использовался поисковик Google.

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

Памяти моего папы, Плеханова Станислава Петровича, посвящается.

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

Один из принципов дизайна в Atlassian — лаконичность. В ходе эволюции UX некоторые непопулярные действия, расчитанные на опытных пользователей, были спрятаны в выпадающих списках или за горячими клавишами. Там они ждут предприимчивого пользователя, который случайно наткнётся на них благодаря случайному нажатию клавиш или клику мышки (ну, или заглянет в руководство). Вот шесть моих любимых трюков Bitbucket Cloud, о которых вы, возможно, никогда не слышали:

Омнибар

Омнибар в Bitbucket — это строка быстрого доступа к действиям, похожая на ⇧⇧ в средах разработки JetBrains или ⌘+P в Sublime Text. Запустить омнибар можно на любой странице, нажав клавишу точки.

По умолчанию, он покажет набор действий, соответствующих текущему контексту:

Ключевые моменты:
* Реализация скрипта для проверки PTR посетителей;
* Конфигурирование nginx в IfIsEvil-style с ветвлениями map;
* Имена location в переменных map;
* Управление ветвлением через try_files /nonexist $map_var.

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

Я никогда бы не рискнул написать статью об очередной реализации умного дома с подключением датчиков утечек воды в ванной и системами слежения за проделками кота в квартире. Слава богу, кот под контролем собаки, вода вроде тоже не течёт. Но всё же мы больше находимся на работе, в различных офисах, где не всегда удается создать оптимальную рабочую среду. Статья посвящена системе экологического мониторинга рабочего пространства в офисе и тем мероприятиям, которые мы провели после месяца её (на удивление) стабильной работы. Конечно, все данные отправляем в облака, смотрим на них со своих смартфонов, полезности в этом никакой, зато повод похвалиться перед близкими и знакомыми, да и в офисе стало покомфортней. Реализовано всё на ESP8266, а как — милости просим под кат)

Я заметил, у разработчиков совершенно полярное отношение к библиотеке Boost.Spirit: либо она им жутко не нравится, либо они фанатеют от нее. Конечно, описывать грамматику на C++ – занятие на любителя. Таким любителем оказался и я, когда познакомился со Спиритом. Хочу показать, как с помощью Спирита можно довольно просто решать повседневные задачи разбора текста.

Простая задача – как два пальца

На Спирите очень удобно писать маленькие парсеры «не отходя от кассы» – прямо в C++ коде. Вот например, как вы поступите если нужно распарсить строку вида «число-число», которая задает диапазон страниц для печати? На Спирите – одна строчка:

bool ok = parse(First, Last, (uint_ >> L"-" >> uint_), MinMax) && (First == Last);

Посложнее…

Более того – можно ненамного сложнее создавать и парсеры побольше. В качестве примера рассмотрю парсер мини-языка, который я делал для API Яндекс.Бара. Задача была такова: для облегчения загрузки плагинов в баре используется XML, который довольно избыточный сам по себе. Но зато XML легче грузить из JavaScript-а, чем парсить произвольный формат (на JS пишутся расширения под FireFox, в том числе и Я.Бар).

Итак, что мне было нужно – имея на входе обычную инфиксную нотацию:

Эта подборка коротких заметок относительно контейнеров C++ появилась как результат просьбы подготовить для начинающих коллег программистов сжатый обзор STL. Зачем это было нужно, когда по этому предмету есть оригинальная документация и много целых отдельных книг, из которых как минимум 5-6 превосходного качества существуют в переводах и на русский язык?
Но смысл, однако, есть и он вот в чём:

• Все книги изданы в конце 90-х — начале 2000-х. Более поздние стандарты языка C++ (вплоть до C++11) вводят новые синтаксические конструкции, которые в применении с STL дают кросс-эффект … с очень интересной интерференцией. Это позволяет часто использовать конструкции STL с гораздо большей лёгкостью.
• Книги обычно описывают предмет слишком детализировано (это хорошо для студентов, но избыточно для программистов, пусть даже уровня джуниоров, которым, после других языков, например, нужно только базовое ознакомление). Оригинальная документация, наоборот, напичкана формальными синтаксическими определениями (это замечательно в качестве справочника под рукой, но избыточно для знакомства). Настоящие заметки, полностью избегая формальных определений, строятся вокруг примеров использования, в большей части понятных программисту даже без каких-либо дополнительных пояснений.
• Контингент, для которого первоначально готовились тексты, помимо прочего в значительной степени ориентирован на численные математические методы, обработку данных в потоке, на что не рассчитаны существующие публикации. Мне тоже ближе такой уклон, и такой акцент будет заметен в примерах, на которых построено описание.

Из-за требований обязательной однотипности объектов в контейнерах, их можно было бы с уточнением называть регулярными контейнерами, это много проясняет (не делается такое уточнение только потому, что и так всем ясно о чём речь). Речь, конечно, идёт о контейнерах STL, но и традиционный массив C/C++ — это такой же регулярный контейнер, и они будут фигурировать в тексте и примерах. (Структуры, а ещё более обще, классы с полями данных тоже являются контейнерами, но их никак не назовёшь регулярными.)

Хотелось бы надеяться, что эти заметки окажутся полезными кому-то из осваивающих STL, упростят этот процесс понимания. А предложения и замечания, когда они будут по существу, от тех читателей, кто уже профи в C++, позволят улучшить эти тексты на будущее, когда они смогут пригодиться ещё кому-нибудь.