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

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

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

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

Данная статья будет про то, как одна дружная команда веб разработчиков, не имея в своём составе опытного SQL разработчика, добавила Check Constraint в таблицу и прошлась по нескольким простым, но не сразу очевидным граблям. Будут разобраны особенности синтаксиса T-SQL, а также нюансы работы ограничений (СONSTRAINT’ов), не зная которые, можно потратить не мало времени на попытки понять, почему что-то работает не так. Так же будет затронута особенность работы SSDT, а именно как генерируется миграционный скрипт, при необходимости добавить или изменить ограничения (CONSTRAINT’ы).

Дабы читатель поскорей понял, стоит читать статью или нет, я сначала рассмотрю абстрактную задачу, по ходу решения которой будут заданы вопросы «А почему так?». Если вы сразу будете знать ответ, то смело бросайте чтение и переходите к следующей статье.

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

И лишь одной малюсенькой детали в этой статье не хватало. Правды.


Правды о том, что программировать легко и приятно, что сложности надуманы, а плюсы работы — недооценены. И я думаю стоит исправить эту несправедливость, написав такую статью. И нет, я не буду тут скатываться в трёп о высоких зарплатах, востребованности на рынке и высокой мобильности. Это всё ведь не о программировании, это о стиле жизни программиста, что не совсем то. А мы ведь на Хабре, а не на Мегамозге каком-то, поэтому давайте рассмотрим именно программирование, во всей его завораживающей красоте и устрашающей мощи!

Хотя популярность buzzword «pairwise» уже не та, на собеседованиях до сих пор задают вопрос о том, что представляет собой эта техника тест-дизайна. Однако, далеко не все тестировщики (как те, кто приходят на собеседование, так и те, кто его проводят) могут четко сформулировать ответ на вопрос, зачем нужны комбинаторные техники в общем и pairwise в частности (подавляющее большинство ошибок, все же, находятся на атомарных значениях параметров и не зависят от других). Простой ответ на этот вопрос, на мой взгляд — для нахождения багов, возникающих вследствие явных и неявных зависимостей между параметрами. Для простых случаев техника вряд ли принесет серьезную пользу, поскольку их можно проверить вручную, а для большого числа параметров и сложных зависимостей между ними количество тестов, скорее всего, будет слишком велико для ручного тестирования. Потому основное применение комбинаторных техник (и соответственно, инструментов, осуществляющих генерацию комбинаций параметров) — автоматизированное составление наборов тестовых данных по определенным законам.

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

Добрый день, Иван
Здравствуйте

Расскажите, пожалуйста, что такое проект Code Club, с чего он начинался, кто его придумал?
Code Club — это британская инициатива по обучению детей 9-11 лет основам программирования. Она возникла около трех лет назад и с тех пор бурно развивается — в начале в самой Великобритании, а спустя некоторое время и по всему миру. В Великобритании сейчас уже более 2000 локаций, там это всё поддерживается на государственном уровне: есть база волонтёров, есть база локаций — всё очень серьёзно организовано. После перехода рубежа в 1000 локаций проект начал выходить на международный уровень. Примерно с лета 2013 года заработал сайт codeclubworld.org — занимаются им те же британцы, но задача у них уже более глобальная: координировать обучение детей программированию по всему миру, дать возможность каждому ребёнку получить знания об основах информатики.

Тогда же, летом 2013-го года было объявлено о старте осенью проекта Code Club в Украине. Были названы первые города, в которых планировалось открытие первых локаций и были контактные данные координатора. Так всё начиналось.

Что входит в программу обучения?
Первые семестры проекта Code Club рассказывают о разработке программ с помощью визуального программирования. Мы учим детей работе в среде Scratch — это разработка MIT, которая создавалась именно под возраст 9-11 лет. В следующих семестрах Code Club изучается HTML, CSS и Python.

Социальные сети (Twitter, Facebook, LinkedIn) — пожалуй, самая популярная бесплатная доступная широкой общественности площадка для высказывания мыслей по разным поводам. Миллионы твитов (постов) ежедневно — там кроется огромное количество информации. В частности, Twitter широко используется компаниями и обычными людьми для описания состояния дел, продвижения продуктов или услуг. Twitter также является прекрасным источником данных для проведения интеллектуального анализа текстов: начиная с логики поведения, событий, тональности высказываний и заканчивая предсказанием трендов на рынке ценных бумаг. Там кроется огромный массив информации для интеллектуального и контекстуального анализа текстов.

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

Реализация на R с применением twitteR, dplyr, stringr, ggplot2, tm, SnowballC, qdap и wordcloud. Перед применением нужно установить и загрузить эти пакеты, используя команды install.packages() и library().

Часть 1
Часть 2

Что вы сделаете, если завтра выиграете в лотерею? Купите спортивную машину, бросите работу и поедете в турне по США? А может быть станете основателем собственной компании, приумножите состояние и купите личный самолёт?

Мы все любим делать планы, и чаще всего они опираются на наше финансовое состояние. Такие планы могут быть описаны функцией. К примеру, план покупки машины это:

pair<Car, Cash> buyCar(Cash cashIn)

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

template<class A>
using Plan = function<pair<A, Cash>(Cash)>;

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

template<class A>
Plan<A> got_it(A a)
{
    return [a](Cash s) { return make_pair(a, s); };
}

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

В предыдущей части были рассмотрены основы уровней изоляции транзакций. Здесь я постараюсь копнуть чуть глубже и рассказать при помощи каких инструментов MS SQL Server реализует уровни изоляции.

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

• Основанный на блокировке ресурсов
• Основанный на создании версионной копии ресурсов.

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

Мне часто приходилось сталкиваться с тем, что люди прекрасно понимают, что такое транзакции в базе данных и для чего они нужны, но при этом не всегда умеют ими правильно пользоваться. Безусловно, для достижения 80-го уровня сакрального знания нужно иметь не один год опыта и прочесть множество толстенных книг по SQL. Поэтому в этой статье я даже не буду пытаться описать всё, что может быть связано с транзакциями в MS SQL. Я хочу затронуть один простой, но очень важный вопрос, который разработчики часто упускают из вида – уровни изоляции транзакций.
Несмотря на то, что тема очень проста, во многих источниках она освящается плохо – информации либо очень мало, либо очень много. Т.е. прочитав 5-6 кратких теоретических определений невозможно их применить на практике. Для уверенного понимания предмета статьи нужно обращаться к специализированной литературе, но там информации на столько много, что далеко не каждый может уделить необходимое время для её усваивания.
Сегодня я хочу поделиться своим простым рецептом, который помог мне раз и на всегда запомнить особенности уровней изоляции транзакций и по сей день помогает без проблем принимать взвешенные решения о выборе необходимого уровня.

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

Часть 1
Часть 2

Иногда программисты на С++ просят привести пример задачи, которая не может быть решена без использования монад. Начнём с того, что этот вопрос неверен сам по себе — это всё-равно, что спрашивать, существует ли задача, которая не может быть решена без циклов. Очевидно, если в вашем языке есть поддержка оператора goto, вы можете обойтись без использования операторов цикла. Что монады (и циклы) могут сделать для вас, это упростить ваш код и помочь лучше его структурировать. Как использование циклов превращает спагетти-код в нормальный, так и использование монад может превратить ваш код в императивном стиле в декларативный. Эта трансформация может помочь легче писать, понимать, поддерживать и расширять ваш код.

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

  s e n d
+ m o r e
---------
m o n e y

Каждая буква соответствует цифре от 0 до 9. Нужно написать программу, которая подберёт такие соответствия, чтобы написанная операция сложения была верной. Перед тем, как продолжить чтение статьи — подумайте минутку, как бы вы решили эту задачу?

Ни для кого сегодня уже не является секретом (или даже новостью) успех технологий контейнеризации в общем и платформы Docker, как успешного практического решения, в частности. Каждый, кто хотя бы раз попробовал упаковать своё приложение в контейнер, испытал это ощущения чисто детского счастья от понимания того, что вот она — упакованная и готовая к работе компонента, которая развернется где-угодно, в каких-угодно количествах и заработает там так же хорошо, как работала на компьютере разработчика. Деплоймент стал удовольствием, а не наказанием. «Гибкость» и «масштабируемость» перестали быть маркетинговой чушью из рекламных буклетов и стали реально достижимыми вещами. Писать микросервисы стало не просто «модно», но попросту логично и практично. Контейнеры навсегда изменили мир. (Была, тут правда, вчера мысль о том, что контейнеры — это зло, но в комментариях вроде бы разобрались, что не в контейнерах конкретно беда, а в общем подходе к безопасности)

Не прошло и 100 лет, как это заметила компания Amazon, выпустив в конце 2014-го в бету свой новый сервис — Amazon EC2 Container Service. Общий смысл сервиса — дать возможность разворачивать Docker-контейнеры удобным способом. «Удобным» — означает без необходимости углубляться во внутренности Docker, да и вообще делать что-либо руками в консоли хост-машины. Вы просто создаёте новый кластер, добавляете в него виртуалки, на которых будут работать контейнеры, а потом указываете сколько и каких контейнеров нужно запустить. Всё остальное (выбор на какой машине запустить контейнер, права доступа, проброс портов) Амазон берёт на себя. Кроме того, вы можете использовать из Docker-контейнера всю инфраструктуру Амазона — сохранять файлы на S3, пользоваться очередями SQS, прикрутить на входе амазоновский балансировщик нагрузки, а на выходе — амазоновские логи и сервисы аналитики. Контейнеры могут «видеть» друг друга, делиться (или не делиться) ресурсами, стартовать и быть остановленными из консоли AWS (вручную либо по заданным правилам).



Давайте попробуем что-нибудь запустить в Amazon EC2 Container Service. Например, поднимем Wordpress + Mysql.

Фреймворк Qt предоставляет неплохие средства разработки — входящая в него IDE Qt Creator включает дизайнер, отладчик, профайлер и другие удобные вещи. К сожалению, даже со всем этим иногда не очень понятно, почему приложение в данные момент выглядит так, как выглядит: чего-то не видно, что-то выглядит не так, как ожидалось, где-то неподходящий размер шрифта или неверная картинка.

Часть этих проблем может быть решена в Qt Designer, но только часть. Qt Designer имеет несколько существенных недостатков: во-первых, он неверно отображает положение Qt Quick компонентов в случае активного использования Javascript при расчете их координат и размеров, во-вторых в дизайнере мы видим состояние только «пустой» формы, без загруженных в неё данных. В общем, очень не хватает чего-то вроде инструментов разработчика в любом современном браузере: чтобы можно было посмотреть всё дерево компонентов, найти нужный, увидеть его положение относительно других, свойства, поправить на лету что-то, подобрать цвет\шрифт\размер, увидеть какие обработчики повешены на события и т.д.

И такой инструмент в мире Qt появился! Встречайте — GammaRay, средство интроспекции приложений на Qt. GammaRay понимает, что такое Qt, из чего состоит ваше Qt-приложение, как в нём взаимодействую компоненты, как они выглядят, как генерируются и обрабатываются события и т.д. Давайте посмотрим, что умеет GammaRay.

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

Я постараюсь кратко осветить основные моменты организации кеширования, после чего рассмотрю новшества .Net Framework 4.0, которые должны упростить жизнь разработчиков (речь пойдёт о In-memory кеше вне ASP.NET инфраструктуры).

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

• увеличение скорости чтения/записи данных, что позволяет уменьшить время отклика системы;
• обеспечения «общей памяти» для различных экземпляров, что является одним из необходимых условий горизонтального масштабирования
• снижение стоимости, за счёт более редкого обращения к базе данных (чтение из БД является более дорогой операцией, по сравнению со чтением значения из кеша)

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

Для чего вообще нужно внедрять свои DLL-ки в чужие процессы и устанавливать там хуки? Для того, чтобы понять какие функции будет вызывать это приложение, с какими параметрами и что эти функции вернут. Таким образом мы можем понять внутреннюю логику работы этого приложения, узнать к каким файлам оно пытается получить доступ, какие данные пересылает по сети, мы можем добавить в него логирование, профилирование, отладить баг, получить из приложения некоторые данные или наоборот — добавить в его интерфейс что-нибудь нужное нам. Хуки использует известная утилита Spy++ для работы с окнами приложений, DirectX-отладчики вроде RenderDoc, некоторые утилиты от SysInternals, программы типа ApiMonitor и т.д.

Некоторое время назад я писал вводные статьи об использовании хуков на примерах библиотек Microsoft Detours и madCodeHook (если вы совсем не знакомы с хуками — это то, с чего можно начать). Описанных там техник достаточно для работы с обычными приложениями, но время не стоит на месте и вот сегодня у нас уже есть Metro Modern-приложения, входящие в комплект Windows 8 и Windows 10, а также распространяющиеся через Microsoft Store программы сторонних производителей. К примеру, новый браузер Spartan — это Modern-приложение. Внедрение DLL в эти процессы имеет свои особенности и на первый взгляд может даже показаться невозможным, но это не так. В этой статье я расскажу, как мы можем залезть внутрь Modern-приложения и установить в нём хуки в своих коварных целях.

В данной статье хотел бы рассказать про набор полезных дополнений к Visual Studio, которые могут в значительной мере облегчить разработку баз данных на основе MS SQL Server.
Основными преимуществами использования SSDT я бы выделил следующее:

• возможность простого изменения (refactoring) схемы базы (можно переименовать колонку таблицы и все Views, Functions и Stored Procedures ссылающиеся на неё автоматически будут исправлены для отражения изменений)
• создание юнит тестов для базы данных
• хранение структуры базы данных в Source Control
• сравнение схемы/данных c возможностью генерации скрипта для приведения схемы/данных к требуемому состоянию

Безусловно на этом плюсы использования SSDT не заканчиваются, но остальное не так сильно впечатляет, как то, что упомянуто выше. Если вас интересует, как воспользоваться этими и другими преимуществами — прошу под кат.

20-го марта 2015 года Google получил информацию о существовании поддельных цифровых сертификатов для нескольких своих доменов. Сертификаты были выданы промежуточным центром сертификации, относящимся к компании MCS Holdings. Промежуточный сертификат этой компании был выдан CNNIC (China Internet Network Information Center — административное агентство, управляющее доменом cn и подконтрольное Министерству Информатизации Китая).

CNNIC включен во все основные списки доверенных сертификационных центров и поэтому выданным им сертификатам доверяет большинство браузеров и операционных систем. Chrome на всех операционных системах и Firefox версий 33 и старше отклоняют поддельные сертификаты для доменов Google из-за того, что их публичные ключи вшиты в бинарники браузеров, что, однако, не решает проблему вероятного существования поддельных сертификатов для других доменов.

Google оперативно оповестил CNNIC и разработчиков других браузеров об этом инциденте и заблокировал все выданные компанией MCS Holdings сертификаты путём обновления CRLSet. CNNIC ответили 22-го марта и объяснили, что у них был договор с MCS Holdings о том, что эта компания будет выпускать сертификаты только для доменов, которые будут ею зарегистрированы. Однако, вместо того, чтобы хранить приватный ключ в безопасном аппаратном хранилище, MCS прошила его в свой продукт — man-in-the-middle прокси-сервер. Эти устройства позволяли на лету сгенерировать поддельные сертификаты для посещаемых пользователями https-ресурсов, позволяя, к примеру, компаниям следить за своими работниками таким образом, что у тех не возникало подозрений в том, что их текущее соединение не является безопасным. Ситуация похожа на случай с ANSSI в 2013-ом году.

Хорошо в плане поддержки JSON живётся программистам на Javascript — по какому-то невероятному стечению обстоятельств там JSON входит в спецификацию самого языка: есть JSON — есть объект. Удобно. Неплохо дело обстоит и в языках, где JSON не входит в сам язык, но поддерживается стандартной библиотекой (Python, Ruby): импортируешь модуль — и готово.

Жизнь программистов на С++ никогда не была особо простой — поддержки JSON у нас нет ни на уровне языка, ни в стандартной библиотеке. И не будет, возможно, никогда. «Тоже мне проблему нашел!» — скажут мне опытные коллеги — «Её там и не должно быть, С++ поставляется без „батареек“. Для решения этой задачи мы...» и вот здесь они разделятся на два лагеря:

1. «Мы используем большой фреймворк (boost, Qt, POCO, другой), который применяется во всех наших проектах и умеет 150 000 разных вещей, в том числе и JSON.»
2. «Мы придерживаемся подхода в котором для каждой задачи применяется своя легковесная библиотека. В частности, для JSON мы уже 150 000 лет назад выбрали отличную библиотеку %JSON_LIB%, которая прекрасно работает.»

Да, всё так и есть. Вот только…





Давайте немного помечтаем.

А что, если бы JSON вошел в стандартную библиотеку нового стандарта С++? Что, если бы он был написан в терминах С++11\14 и без требований обратной совместимости со старыми стандартами языка? Что, если бы синтаксис этого модуля попытались бы сделать максимально приближенным к родному для JSON использованию «а-ля Javascript», но в том же время сохранить дух С++ (эффективность, минимальное потребление памяти, совместимость с STL)? Что, если бы его можно было включить в проект одним инклюдом и не беспокоиться о его сборке и линковке? Как бы это всё выглядело и работало?

И у нас есть ответ на этот вопрос! Давайте посмотрим на JSON-библиотеку для С++ написанную в соответствии со всеми этими принципами, ну и вообще написанной людьми для людей, а не чужими для хищников, как это обычно бывает.