Это вводная статья об использовании apply, sapply и lapply, она лучше всего подходит для людей, которые недавно работают с R или незнакомы с этими функциями. Я приведу несколько примеров использования функций семейства apply, поскольку они часто применяются при работе в R.

Я сравнивал эти три метода на наборе данных. Была сгенерирована выборка, и они к ней применялись. Хотелось посмотреть, чем отличаются результаты их применения.

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

method1  method2    method3 
[1,] 0.05517714 0.014054038 0.017260447
[2,] 0.08367678 0.003570883 0.004289079
[3,] 0.05274706 0.028629661 0.071323030
[4,] 0.06769936 0.048446559 0.057432519
[5,] 0.06875188 0.019782518 0.080564474 
[6,] 0.04913779 0.100062929 0.102208706

Такие данные можно симулировать с помощью rnorm, чтобы создать три набора. Первый — со средним, равным 0, второй — со средним 2, третий — со средним 5, и 30 строк.

m <- matrix(data=cbind(rnorm(30, 0), rnorm(30, 2), rnorm(30, 5)), nrow=30, ncol=3)

Возможно, я скажу банальную вещь, но прошедший год был хорошим годом для С++!

Просто факты:

• Вышла Visual Studio 2015 с отличной поддержкой возможностей С++14/17 и даже нескольких экспериментальных вещей
• Вышел долгожданный GCC 5.0
• С++ набрал серьёзную популярность. Где-то с июля — третье место в Tiobe Ranking
• На конференции CppCon 2015 было сделано несколько важных анонсов

А теперь об этом и другом немного подробнее

Есть у нас одно .NET-приложение, которое умеет загружать и использовать плагины. Плагины — дело хорошее. Можно функционал расширять, можно оперативненько обновлять их со своего сайта, можно даже юзерам дать SDK и позволить писать свои плагины. Мы всё это и делали. Наши плагины представляли собой обычные .NET-сборки, которые нужно было подкинуть в определённую папку, откуда основное приложения их загружало и использовало. Ну, вы, наверное представляете как — Assembly.Load(), дальше ищем класс, реализующий необходимый интерфейс, создаём объект этого класса и т.д. Всё это работало давно, стабильно и ничто не предвещало беды. Но вдруг в какой-то момент появилась необходимость создать плагин, состоящий из нескольких файлов. В связи с этим было решено считать плагином не просто .NET-сборку (1 файл), а zip-архив, в котором может быть как одна сборка, так и несколько файлов. В связи с этим пришлось научить билд-сервер паковать плагины в архивы, а основное приложение — разархивировать их в нужное место. В общем-то задача на 10 строк кода. Ничто не предвещало беды. И вот скачиваю я с билд-сервера собранный архив с плагином, разархивирую его в нужную папку, запускаю приложение, и… не работает! Стоп, как не работает? Это ведь тот же плагин!

Дальше — больше. Прошу проделать ту же самую процедуру моего коллегу, на его компьютере. Он пробует — и у него всё работает! Но как же так? Одна версия приложения, один и тот же файл с билд-сервера. Какая-то разница в окружении? Сажусь за компьютер коллеги, пробую ещё раз — не работает! Он в этом время пробует на моём — работает! То есть получается, что файл «помнит», кто его разархивировал! Зовём третьего коллегу понаблюдать этот цирк. Последовательно, на одном и том же компьютере, по очереди делаем одни и те же действия: скачиваем архив с плагином, разархивируем в нужную папку, запускаем приложение. Когда это делаю я — программа не видит плагин, когда это делает коллега — всё работает. На третьем круге этих интересных экспериментов вдруг замечаем разницу в действиях: я разархивировал плагин стандартными средствами Windows, а мой коллега — с помощью 7-Zip. И то и другое вызывалось нами из контекстного меню архива, так что разницу в клик по не тому пункту вначале никто не замечал. Ну ок. Получается, файл, извлечённый из zip-архива с помощью 7-zip, отличается от того же файла из того же архива, извлечённого с помощью стандартного архиватора Windows?

Кстати, пока вы не открыли статью под катом, ответьте-ка сами для себя на вопрос, может ли такое быть, что содержимое файлов валидного zip-архива при разархивации 7-zip и через проводник Windows будет разным?

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

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

Новый проект на стороне инструментарий WebAssembly, о котором я хочу сегодня рассказать, называется Binaryen. Binaryen это библиотека для поддержки WebAssembly в компиляторах, написанная на С++. Если вы лично не работаете над компилятором WebAssembly, то вам, вероятно, не нужно напрямую знать что-либо о Binaryen. Если вы используете какой-нибудь компилятор WebAssembly, то он, возможно, под капотом использует Binaryen — мы рассмотрим примеры ниже.

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

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

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

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

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


Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

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

Ну что же, пора включать голову, брать в руки инструменты и разбираться. Поехали.

Несколько последних месяцев я программирую преимущественно на Scala (по работе) и на Haskell (для души). На этой неделе я, правда, ещё немного пописал на Ruby (по работе) и Clojure (для души).

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

Но вот что касается моего новенького, с иголочки, проекта-любимца на Clojure… О, Clojure! Глоток свежего воздуха! Благодатная земля хорошо скомпонованных функций, иммутабельных структур данных и всего такого. Как прекрасен твой синтаксис и как мудра твоя чувствительность! Вся твоя суть в функциях, принимающих мэпы и возвращающих мэпы. И твой SQL-генератор, и слой доступа к БД, и HTML-парсер, и URL-роутер являют собой одну и ту же завораживающую картину мэпов, гоняемых туда-сюда тактами процессора, прекрасную с своём ритме хорошо собранных швейцарских часов.

Вернуться к Clojure после долгого времени это всё равно, что почувствовать себя дома. Это просто окрыляет программиста. Но почему-то в этот раз я ощутил и ещё одно, неожиданное для себя чувство: неопределённость.

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

В первой части:

• визуализация сетей: зачем? каким образом?
• параметры визуализации
• best practices — эстетика и производительность
• форматы данных и подготовка
• описание наборов данных, которые используются в примерах
• начало работы с igraph

Во второй части: цвета и шрифты в графиках R.

В третьей части: параметры графов, вершин и ребер.

В четвертой части: размещения сети.

В пятой части: акцентирование свойств сети, вершин, ребер, путей.

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

В этой части: анимированная визуализация сетей, эволюция сети во времени.

Здравствуйте, меня зовут Владимир и я анонимный разработчик десктопных приложений под Windows. В этом месте все должны сказать «Здравствуй, Владимир!», а кто-то может быть добавит «Молодец, что осознал!». А потом все похлопают. Нет, правда, иногда от чтения Хабра у меня возникают именно такое ощущение, что нормально, нет, даже не «нормально», а допустимо и одобряемо сегодня писать только микросервисы для каких-то стартапов, которые будут по какому-то REST API отдавать данные какому-нибудь фронтенду на Ангуляре, который и будет, наконец, показывать пользователю что-то невероятно полезное, вроде таблицы с аггрегированными отзывами о стрижках пуделей с возможностью посмотреть на гуглокартах где бы в вашем городе можно было сделать именно такую стрижку вашему пуделю (несуществующему). А никаких других программ писать уже нет-нет, никак нельзя! Что за чушь?!

Да, многое сегодня происходит в вебе и на мобильных устройствах, но, знаете ли, далеко не всё. Значительная часть приложений по-прежнему является десктопным софтом. И даже (о, ужас!) не под Mac Os или Linux, а под тот самый богомерзкий Windows. И, знаете ли, софт этот живёт, развивается, поддерживается и является ежедневным рабочим инструментом миллионов людей. И никуда он мигрировать не собирается, потому что есть причины, по которым иногда именно десктопное приложение является лучшим вариантом.

Microsoft добавит поддержку компилятора Clang в ноябрськом обновлении Visual Studio 2015 — об этом было заявлено на конференции CPPCon 2015, проходящей сейчас в городе Белвью, США.

Clang это компилятор кода на С, С++ и Objective-C, который в связке с LLVM позволяет собирать программы под различные платформы. Visual Studio 2015 уже поддерживает Clang для разработки Android и iOS-приложений. При разработке под Android можно выбирать между GCC и Clang, а для iOS приходится использовать внешний Mac в качестве билд-сервера.

Планируемое обновление принесёт поддержку Clang на качественно новом уровне — теперь им можно будет собирать обычные Windows-приложения.

В первой части:

• визуализация сетей: зачем? каким образом?
• параметры визуализации
• best practices — эстетика и производительность
• форматы данных и подготовка
• описание наборов данных, которые используются в примерах
• начало работы с igraph

Во второй части: цвета и шрифты в графиках R.

В третьей части: параметры графов, вершин и ребер.

В четвертой части: размещения сети.

В пятой части: акцентирование свойств сети, вершин, ребер, путей.

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

В первой части:

• визуализация сетей: зачем? каким образом?
• параметры визуализации
• best practices — эстетика и производительность
• форматы данных и подготовка
• описание наборов данных, которые используются в примерах
• начало работы с igraph

Во второй части: цвета и шрифты в графиках R.

В третьей части: параметры графов, вершин и ребер.

В четвертой части: размещения сети.

В этой части: акцентирование свойств сети, вершин, ребер, путей.

На конференции CppCon, которая проходит прямо сейчас, команда разработчиков компилятора Visual C++ заявила, что в следующем обновлении (Visual Studio 2015 Update 1) в компилятор С++ от Microsoft будет добавлена экспериментальная возможность из нового (ещё не утверждённого) стандарта С++ — поддержка модулей!



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

• Заголовочный файл и библиотека — отдельные файлы, один из них может потеряться, либо они случайно могут рассинхронизироваться.
• Заголовочный файл включается в код директивой препроцессора #include, что во-первых, замедляет компиляцию, а во-вторых добавляет влияние всего, что написано в заголовочных файлах друг на друга и на конечный код. Нередки случаи, когда заголовочные файлы нужно включать в определенном порядке или определять некоторые макросы чтобы код нормально собрался.

В итоге в инфраструктуре С++ отсутствуют понятия «сборок» или «пакетов» и, в отличии от С# или Python, где установка компонентов тривиальна, в С++ подключение каждой новой библиотеки может нести свои неожиданности. Предлагаемый механизм модулей в С++ призван убрать данную проблему, отказаться от директивы препроцессора #include и ссылаться на компоненты, как на некоторую сущность, состоящую из кода и метаданных, целостную и легко подключаемую. В итоге мы вскоре можем получить существенное ускорение внедрения новых компонентов в проект, появления полноценных менеджеров пакетов, установка новой библиотеки сведется к выполнению одной строки или нескольким кликам мышью. Это ли не счастье!

Под катом будут примеры использования и ссылки на документацию.

В первой части:

• визуализация сетей: зачем? каким образом?
• параметры визуализации
• best practices — эстетика и производительность
• форматы данных и подготовка
• описание наборов данных, которые используются в примерах
• начало работы с igraph

Во второй части: цвета и шрифты в графиках R.

В третьей части: параметры графов, вершин и ребер.

В этой части: размещения сети.

На днях исполняется 10 лет с тех пор, как я получил самую странную свою работу.

Шел 2005-ый год. Мой интерес к разработке системы управления контентом на Java для компании, недавно купившей наш стартап, неуклонно улетучивался, в то время как моей настоящей страстью была разработка компиляторов и инструментов языковой инфраструктуры (в основном для SBCL). Как-то раз я заметил открытую вакансию как-раз по этому направлению, что вообще-то было достаточно редким явлением. Я быстро прошел интервью — настолько быстро, что даже не задал нужных вопросов и проигнорировал несколько тревожных звоночков.

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

В первой части:

• визуализация сетей: зачем? каким образом?
• параметры визуализации
• best practices — эстетика и производительность
• форматы данных и подготовка
• описание наборов данных, которые используются в примерах
• начало работы с igraph

Во второй части: цвета и шрифты в графиках R.

В этой части: параметры графов, вершин и ребер.

В деле удалённого вызова процедур дела уже давно обстоят в точности как в известном комиксе «14 стандартов» — чего только тут ни напридумано: древние DCOM и Corba, странные SOAP и .NET Remoting, современные REST и AMQP (да, я знаю, что кое-что из этого формально не RPC, для того чтобы обсудить терминологию даже вот специальный топик недавно создали, тем ни менее всё это используется как RPC, а если что-то выглядит, как утка и плавает, как утка — ну, вы в курсе).

И конечно же, в полном соответствии со сценарием комикса, на рынок пришел Google и заявил что вот теперь наконец он создал ещё один, последний и самый правильный стандарт RPC. Google можно понять — продолжать в 21-ом веке гонять петабайты данных по старому и неэффективному HTTP+REST, теряя на каждом байте деньги — просто глупо. В то же время взять чужой стандарт и сказать «мы не смогли придумать ничего лучше» — совершенно не в их стиле.

Поэтому, встречайте, gRPC, что расшифровывается как «gRPC Remote Procedure Calls» — новый фреймворк для удалённого вызова процедур от Google. В этой статье мы поговорим о том, почему же он, в отличии от предыдущих «14 стандартов» всё-таки захватит мир (ну или хотя бы его часть), попробуем собрать билд gRPC под Windows + Visual Studio (и даже не говорите мне, что инструкция не нужна — в официальной документации упущено штук 5 важных шагов, без которых ничего не собирается), а также попробуем написать простенький сервис и клиент, обменивающиеся запросами и ответами.

Долгие годы С++ программисты, пишущие под Linux язвительно пеняли разработчикам на С++ под Windows отсутствием в Visual Studio нормального профилировщика памяти. Вот в Линуксе, дескать, есть Valgrind, который решает все проблемы, а в студии что: расставляй какие-то макросы, анализируй какие-то логи — мрак. Клевета! Хотя и правда. Вернее, это было правдой до выхода Visual Studio 2015, в которой наконец-то (ура 3 раза!) присутствует нормальный профилировщик памяти, позволяющий ловить утечки памяти с закрытыми глазами, одной левой и даже не просыпаясь!

В этой статье мы посмотрим, что он умеет и как им пользоваться.