Простые текстовые форматы данных — прекрасная штука. Нет, без шуток. Возьмём, например, банальные txt-файлы. Ну красота же! В любом утюге есть текстовый редактор, можно открыть файл, почитать, записать. Любой уважающий себя язык программирования из коробки даст вам средства работы с текстовыми файлами. Или вот ранние сетевые протоколы — SMTP, POP3, HTTP 1.0. Это вообще такое блаженство, что слёзы на глаза наворачиваются. Можно взять telnet, приконнектиться к серверу, отдавать команды и читать ответы! Писать клиенты, серверы, снифферы, прокси — одно удовольствие.

Но время не стоит на месте и удобство работы программиста, к сожалению (или к счастью!), давно перестало быть главным критерием выбора технологий. В прекрасные текстовые файлы понадобилось вдруг добавлять графики, картинки и ссылки — и вот у нас есть форматы pdf и doc. С сетевыми протоколами вообще беда — людям зачем-то понадобились сжатие трафика, шифрование, мультиплексирование и другие страшные вещи. И вот уже у нас есть HTTP/2, с которым телнетом не очень-то поработаешь. Даже всем красивый REST разные негодяи типа Google нет-нет, да и пытаются заменить на какой-нибудь gRPC. И это я ещё не начал рассуждать о том, что мало что нынче сохраняется текстовые файлы — все почему-то используют какие-то базы данных, совершенно нечитабельные при открытии их текстовым редактором, но какой-то магией позволяющие информацию структурировать, индексировать, эффективно искать и т.д.

И вот здесь мы подходим к теме того, что я хотел бы обсудить. Как видите, все форматы хранения данных, протоколы и прочие штуки прошли длинный путь в поисках своего оптимального вида. Однако мы, программисты, продолжаем писать код наших программ в текстовых файлах, как делали это наши дедушки лет 50 назад (или уже больше?). Какую бы ОС мы ни использовали, какой бы модный язык ни выбрали, как бы ни была крутой наша IDE — результатом написания кода будут буквы в текстовом файле. Что, согласитесь, в теории совершенно не обязательно, ибо наши буквы компьютеру нужны как зайцу стоп-сигнал. Ему нужны машинные команды для выполнения, это просто нам удобнее описывать их какими-то там буквами. А на самом деле ведь «цикл» или «функция» будут тем, чем они являются, как ты их не назови и где ты их не храни. «Роза пахнет розой, хоть розой назови её, хоть нет».

Да, мы привыкли писать код в текстовые файлы. Вы открываете файл — ну и вроде бы видите код своей программы. Какую-то его часть, вернее. Как-то видите. Понимаете. Ну или думаете, что понимаете. Но вот пост на Facebook вы тоже открываете, видите и понимаете — а ведь Facebook точно этот пост не в текстовом файле хранил.

Давайте же посмотрим, какие проблемы нам создаёт хранение кода в виде набора текстовых строк.

Есть два отличных пакета для работы с данными в R — dplyr и data.table. У каждого пакета свои сильные стороны. dplyr элегантнее и похож на естественный язык, в то время как data.table лаконичный, с его помощью многое можно сделать всего в одну строку. Более того, в некоторых случаях data.table быстрее (сравнительный анализ доступен здесь), и это может определить выбор, если есть ограничения по памяти или производительности. Сравнение dplyr и data.table можно также почитать на Stack Overflow и Quora.

Здесь можно найти руководство и краткое описание data.table, а здесь — для dplyr. Также можно почитать обучающие материалы по dplyr на DataScience+.

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

1. Вдумчивое чтение — чтение фундаментальных книг, структурированных и информативных. Это требует длительной концентрации, причём нельзя читать в состоянии усталости, поскольку вы попросту уснёте и ничего не запомните. Если у вас ещё нет электронной читалки — обязательно купите.
2. Лёгкое чтение — чтение менее серьёзной литературы вроде книг о мотивации, продуктивности, Soft Skills. Всё это зря недооценивается некоторыми программистами. Эти книги не требуют большой концентрации внимания. Да, это совершенно не о языке С++, но это о том, как вообще что-то делать и всё-таки сделать. Хорошо читается перед сном.
3. Подкасты — хорошо идут, когда нужно переключиться с чего-то одного на другое, или во время шоппинга. Помогают взглянуть на что-то неожиданное. Тренируют умение слушать и понимать услышанное, что может быть полезным умением (например, для участия в совещаниях). Если английский язык для вас не родной — вы можете услышать как произносятся термины и имена. Я рекомендую послушать CppCast или Software Engineering Radio — я был приятно удивлён широким охватом их тем. Первый эпизод вышел в 2006-ом году, подкаст наполовину состоит из истории программной инженерии и наполовину из теории (паттерны, проблемы, решения и т.д.)
4. Видео и лекции — CppCon, CppNow, Meeting C++, ACCU Conference для начала. Там просто ошеломляющее количество интересных докладов. В отличии от подкастов это требует визуального внимания и концентрации, но и выучить в результате можно больше. Я думаю просмотр 2-5 видео в неделю вполне достижимо.
   Совет: увеличивайте скорость аудио/видео — мозг быстро привыкает к этой скорости и вы сможете услышать больше за меньшее время.
5. Обсуждения, форумы, твиттер — этот канал обмена информацией требует меньше всего концентрации. Вы можете быстренько просмотреть дискуссии, ленту твиттера в поисках чего-то интересного — просто убивая время. Если что-то нашлось — можно добавить это в список для чтения позже. Чем это всё полезно — огромным разнообразием людей, мнений, подходов, задач и решений. Хороший способ разогнать свой мозг весьма случайной информацией.
   
   Вот, например, мой список Core C++ чтобы следить за значимыми в мире С++ разработчиками. А ещё есть несколько страниц и групп в Facebook и неплохие обзоры от Jens Weller.
   
   Для дискуссий о С++ есть раздел на Реддите (прим. переводчика: а ещё есть хаб на Хабрахабре). Ну и, конечно, группы комитета по стандартизации C++
6. Блоги и статьи — обычно занимает 5-10 минут чтобы прочитать среднюю статью. Если встречается более глубокая статья — можно пометить её для чтения «когда я буду сконцентрирован». По моим наблюдениям выходит 5-10 хороших статей в неделю и не так сложно прочесть их все.

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

Один из аспектов понятия «производительность Web» заключается в том, чтобы уменьшить наблюдаемые пользователем задержки; получить готовую к работе страницу как можно быстрее. В отношении протокола HTTP это подразумевает, что идеальный протокол связи выглядит как-то так:



Клиент шлёт минимально необходимое количество данных, чтобы описать свой запрос, а сервер отдаёт ему минимально необходимое количество данных для отображения страницы и всё это происходит за минимально возможное количество раундов связи. Лишние данные, пересылаемые на сервер или получаемые с сервера, означают увеличение времени загрузки и повышение шансов потери пакетов, перегруженность канала связи. Лишние циклы отправки\приёма данных из-за «болтливости» протокола и задержки (особенно в мобильных сетях, где 100ms — лучшее возможное время отклика) тоже ухудшают ситуацию.

Итак, если мы описали идеальный случай — соответствует ли ему протокол HTTP? И можем ли мы ещё как-нибудь улучшить его?

summarise() используется с агрегирующими функциями, которые принимают на вход вектор значений, а возвращают одно. Функция summarise_each() предлагает другой подход к summarise() с такими же результатами.

Цель этой статьи — сравнить поведение summarise() и summarise_each(), учитывая два фактора, которыми мы можем управлять:

1. Сколькими переменными оперировать

• 1А, одна переменная
• 1В, более одной переменной

2. Сколько функций применять к каждой переменной

• 2А, одна функция
• 2В, более одной функции

Получается четыре варианта:

• Вариант 1: применить одну функцию к одной переменной
• Вариант 2: применить много функций к одной переменной
• Вариант 3: применить одну функцию к многим переменным
• Вариант 4: применить много функций к многим переменным

Также проверим эти четыре случая с и без опции group_by().

Современный мир ПО очень черно-бело разделён на два лагеря: либо ты opensource-приложение, либо закрытое проприетарное. Нет, есть, конечно, и разные лицензии в открытых проектах и какие-то подвижки закрытых продуктов выкладывать в опенсорс свои части (привет, Google, Facebook, Microsoft). Но всё это не меняет сути дела в принципе — если ты берёшь открытый продукт, то видишь всё, что у него внутри, можешь это оценить и решить, стоит связываться или нет. Если ты хочешь приобрести закрытое ПО, то всё, что остаётся — верить заливающимся соловьями продажникам фирмы-производителя, как у них там всё внутри классно, надёжно, быстро и современно. Ну, вы наверняка были на какой-нибудь такой конференции или презентации, где выходил человек в костюме и час втирал о том, как же всё стало лучше в версии 18.1.1 их продукта и почему его нужно покупать прямо сейчас. Ещё часто можно недельку погонять ограниченный trial-режим, что даст ответ ровно на 1 вопрос: «как работает ограниченный trial-режим в течение недели?». Покупатель всегда остаётся один-на-один с решением «взять и рискнуть» или «не связываться». Объективных данных для принятия решения мало. При этом их, казалось бы, больше и не станет — производитель закрытого продукта не выложит исходники, поскольку именно они составляют коммерческую ценность.

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

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

Мы не пытаемся заменить уже существующие в R геопространственные библиотеки — скорее, дополнить и создать небольшие инструменты, позволяющие легко воспользоваться только необходимыми вам функциями.

Прим. переводчика: в синтаксисе C++ напрочь отсутствуют несколько ограниченны средства построения предметно-ориентированных языков. В итоге их мало кто на С++ пытается использовать, а попытки всё же это сделать вызывают интерес, тем более, когда в итоге получается нечто стройно выглядящее и практически полезное. Одним из таких открытий для меня стал фреймворк Silicon, пытающаяся средствами современного С++ дать возможность быстро и гибко реализовать WebAPI в своём проекте. Давайте посмотрим, насколько просто это выглядит.

Hello World на Silicon — программа, которая на HTTP-запрос к

http://host/hello/world

ответит кодом 200 с текстом «hello world»:

auto my_api = http_api(GET / _hello / _world  = [] () { return "hello world";});
mhd_json_serve(my_api, 80);

Неплохо, правда? my_api здесь это описание нашего API, а mhd_json_serve — это бекэнд фреймворка Silicon, реализующий данный API с использованием встроенного вебсервера (на выбор microhttpd или LWAN).

Давайте посмотрим, что ещё умеет Silicon.

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

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

Возможность генерировать данные с заданной корреляцией очень важна для моделирования. В R ожидаемо обширный набор инструментов — пакетов и функций для генерации и визуализации данных из многомерных распределений. Базовая функция для генерации многомерных нормально распределенных данных — mvrnorm() из пакета MASS, части R, хотя пакет mvtnorm также предлагает функции для симуляции и многомерного нормального, и t-распределения.

Если вы узнали эти несколько строчек кода ниже, значит потенциально вы в тренде последних лет развития PHP.

$client = new \Joli\ArDrone\Client();
// use API service (see below)
$client->start();

PHP-ar-drone является портом node-ar-drone, который позволяет пользователю управлять Parrot AR Drone на PHP. Пару лет назад, когда Адриен Баптист демонстрировал эту технологию, это могло показаться _парашюткой :), но не сегодня.

Известные личности в мире PHP и не очень известные, многие сейчас в интернете обсуждают три основных темы – это PHP 7 против HHVM, асинхронное программирование с ReactPHP и PSR-7, а также микрофреймворки как middleware.

Во многом, споры о будущем PHP активизировались с появлением “прямого конкурента” движку PHP Zend Engine. Таким конкурентом стал HHVM — виртуальная машина для компиляции PHP кода в машинный, основанная на JIT, которая была разработана Facebook для решения все возрастающих нагрузок на сервера. Добившись повышения производительности удалось увеличить трафик на 500-600 процентов в сравнении с популярными версиями PHP на Zend 2. После чего, HHVM был отдан в свободное пользование в первую очередь сообществу WordPress. Именно это заставило основателей Zend Engine воспринимать HHVM, как прямого конкурента и к декабрю 2015-го выкатить 3-ю версию движка для PHP 7.

Цикл for в R может быть очень медленным, если он применяется в чистом виде, без оптимизации, особенно когда приходится иметь дело с большими наборами данных. Есть ряд способов сделать ваш код быстрее, и вы, вероятно, будете удивлены, узнав насколько.

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

Давайте попробуем ускорить код с циклом for и условным оператором (if-else) для создания колонки, которая добавляется к набору данных (data frame, df). Код ниже создает этот начальный набор данных.

# Создание набора данных
col1 <- runif (12^5, 0, 2)
col2 <- rnorm (12^5, 0, 2)
col3 <- rpois (12^5, 3)
col4 <- rchisq (12^5, 2)
df <- data.frame (col1, col2, col3, col4)

В первой части: векторизация, только истинные условия, ifelse.
В этой части: which, apply, побайтовая компиляция, Rcpp, data.table, результаты.

Как-то так получилось, что я написал на Хабре уже несколько статей о библиотеках для хуков. Первая была об общих принципах и реализации на базе Detours, вторая — о более дешевой (но не менее функциональной) библиотеке madCodeHook. Сегодня я расскажу об ещё одном варианте — библиотеке Deviare от компании Nektra. «Ещё одна точно такая же библиотека для хуков?» — спросите вы. «Такая же, да не такая» — отвечу я. У Deviare есть несколько особенностей, отличающих её и от Detours и от madCodeHook и делающей её в некоторых случаях намного более полезной.

Под конец прошлого года компания Amazon выпустила (наконец-то!) C++ SDK для своей платформы AWS. Непонятно, почему так долго тянули — есть масса приложений, написанных на С++, из которых давно хотелось удобно пользоваться AWS. Не джавой же единой, в самом деле.

Всегда интересно посмотреть на что-то, написанное на С++ в наши дни с нуля, без груза обратной совместимости и странных архитектурных решений, присущих некоторым разработкам прошлого. Я не буду тут пересказывать документацию, но остановлюсь на ключевых моментах, определяющих всё поведение SDK.

Цикл for в R может быть очень медленным, если он применяется в чистом виде, без оптимизации, особенно когда приходится иметь дело с большими наборами данных. Есть ряд способов сделать ваш код быстрее, и вы, вероятно, будете удивлены, узнав насколько.

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

Давайте попробуем ускорить код с циклом for и условным оператором (if-else) для создания колонки, которая добавляется к набору данных (data frame, df). Код ниже создает этот начальный набор данных.

# Создание набора данных
col1 <- runif (12^5, 0, 2)
col2 <- rnorm (12^5, 0, 2)
col3 <- rpois (12^5, 3)
col4 <- rchisq (12^5, 2)
df <- data.frame (col1, col2, col3, col4)

В этой части: векторизация, только истинные условия, ifelse.
В следующей части: which, apply, побайтовая компиляция, Rcpp, data.table.

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

В сети есть довольно много материалов, описывающих процесс тестирования инсталлятора и результат его работы. Существует множество чеклистов и других полезностей на эту тему. Речь ниже пойдет о достаточно узкой части процесса инсталляции — тестировании собственно визарда. Достаточно ли пройтись по всем экранам визарда, чтобы утверждать, что он хорошо работает? Возможно, хватит нажать на каждую из кнопок «Назад», «Далее», «Отмена» по одному разу? Как ограничить количество сценариев, если оно бесконечно (можно сколько угодно раз перемещаться между двумя соседними экранами инсталлятора с помощью кнопок «Назад» и «Далее»)?

Для иллюстрации используется инсталлятор LibreOffice 5 под Windows. Решение взять именно его связано с доступностью подробных пошаговых скриншотов. В статье используется нотация из первой и второй статей о покрытии графов.

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

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Периодически возникает вопрос, как можно безопасно хранить логин и пароль в R, не задавая эти данные в явном виде в вашем скрипте. Мне кажется, есть несколько возможных решений. Можно хранить ваши параметры:

1. Непосредственно в скрипте.
2. В файле внутри папки с проектом, который вы не показываете.
3. В файле .Rprofile.
4. В файле .Renviron.
5. В json файле.
6. В безопасном хранилище, к которому вы обращаетесь из R.
7. Используя пакет digest.
8. Используя пакет sodium.
9. Используя пакет secure.

Давайте рассмотрим основную идею, преимущества (или недостатки) каждого из подходов.
[От переводчика: упорядочено по мере возрастания полезности.]

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

Здесь же я опишу свой опыт использования SikuliX в фоновом режиме на облачной IDE Cloud9. В процессе работы с данным инструментом набил немного шишек, поэтому возможно, мой опыт будет кому-то полезен.

Вариантов использования SikuliX достаточно много, вот некоторые из действий, которые вы можете автоматизировать:

• Работа с флеш сайтами (и любими другими)
• Автоматизация браузерных игр (собирать урожай на ферме)
• Работа с десктопными приложениями
• Настройка компьютера
• Разнообразные боты
• Всякого рода рутинная работа с сайтами/документами