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



Далее я познакомлю вас с принципами STUPID и SOLID. Следует иметь в виду, что это принципы, а не законы. Однако, рассматривая их в качестве законов было бы хорошо для тех, кто хочет усовершенствоваться в написании кода.

Мы заканчиваем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting

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

Системные метрики...

Мы продолжаем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting

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

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

Итак,

Как собирать пользовательские метрики?..

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



Прикладной уровень является самой надежной защитой. Уязвимости, с которыми мы тут встретимся, зачастую полагаются на сложные сценарии ввода данных пользователем, что делает их трудноопределимыми с помощью систем обнаружения вторжений. Этот уровень — самый доступный извне. Для нормального функционирования приложения должен быть доступ через порт 80 (HTTP) или порт 443 (HTTPS).

Тестирование и анализ производительности — тема, которую хотелось бы обсуждать побольше. Мы начинаем публикацию перевода руководства от небезызвестной команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод — спасибо Игорю Щегловитову из Лаборатории Касперского, нашему бессменному автору материалов про тестирование. Остальные наши статьи по теме тестирования можно найти по тегу mstesting

Введение

Анализ производительности – дисциплина сложная. Она изучает систему на предмет выполнения требований производительности и определяет причины, если эти требования оказываются не достигнутыми. Статья Performance Analysis Primer из этого цикла содержит введение в эту тему, описывая инструменты и подходы, применяемые в облачной разработке для того, чтобы достичь хорошей производительности.

Недавно я участвовал в профориентационном лагере для школьников. Меня попросили рассказать про Хабр и про то, какие есть ИТ-специальности и что будет в будущем.

Как школьнику рассказать, кто такой тестировщик и зачем нужен процесс тестирования?

Я как-то выкрутился, но чувство незавершенности осталось и по сей день.
На Хабре шикарно умеют объяснять почему трава зеленая или почему программист это супергерой. Если бы вы объясняли 10-класснику, кто такой тестировщик, как бы вы описали этот процесс?

(Есть замечательная книга Сеймура Пейперта «Переворот в сознании: Дети, компьютеры и плодотворные идеи», где рассказывается о том, как сформировать в мышлении детей хорошие стратегии отладки, но эта книга достойна отдельной статьи ->)

«Пугать надо» — посоветовали мне бывалые. Ну что ж, сделал подбоку самых сочных программистских ошибок.

Рад представить дополнение оригинального списка из 300 потрясающих бесплатных сервисов. Автор оригинальной статьи Ali Mese добавил ещё +100 новых сервисов, которые помогут найти все — от источников вдохновения и редакторов фотографий до создания опросов и бесплатных иконок.

И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные веб-сайты

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly: Конструктор веб-сайтов.
• Layers: Создание сайтов на WordPress (new).
• Bootstrap Zero: Самая большая коллекция бесплатных шаблонов Bootstrap (new).
• Landing Harbor:  Продвижение мобильного приложения c помощью бесплатного лендинга (new).

В данной статье я хочу рассказать о некоторых возможностях бесплатной и крайне полезной, но пока еще мало известной надстройки над MS Excel под названием Power Query.

Power Query позволяет забирать данные из самых разных источников (таких как csv, xls, json, текстовых файлов, папок с этими файлами, самых разных баз данных, различных api вроде Facebook opengraph, Google Analytics, Яндекс.Метрика, CallTouch и много чего еще), создавать повторяемые последовательности обработки этих данных и загружать их внутрь таблиц Excel или самого data model.

И вот под катом вы можете найти подробности всего этого великолепия возможностей.

Три дня назад я рассказал о тех докладах конференции DotNext 2015 Piter, которые, согласно опросу участников, заняли места с 6 по 10. Теперь пришло время рассказать про лучшую пятерку докладов.

---

5 место

Кирилл Скрыган, JetBrains — ReSharper vs. Roslyn
Средняя оценка: 4.33



Казалось бы, ReSharper — плагин к Visual Studio, который расширяет возможности IDE. Roslyn — компилятор (набор компиляторов). Что общего?

Дело в том, что для того, чтобы делать все возможные рефакторинги, подсказки и пр., ReSharper строит собственную модель, собственное синтаксическое дерево. А значит, в нем есть, фактически, половина компилятора, компиляторный front-end. А значит, его можно сравнить с фронтэндом Roslyn, что Кирилл и сделал в этом докладе.

Акценты Кирилл расставил не в пользу Roslyn:

• ReSharper на 10 лет старше, в нем гораздо больше фич
• Roslyn работает только для C# и VB, никаких JavaScript и прочих прелестей
• синтаксическое дерево у ReSharper изменяемое и поэтому быстрое, а у Roslyn неизменяемое, генерит много memory traffic и поэтому медленное.

Основной вывод, который сделал я — Roslyn еще пока довольно сырой продукт, а почти все описанные Кириллом болезни — «детские». Пройдет время и наверняка от всех от них Рослин избавится. Ну а что будет на самом деле — покажет время.

На hh/gt не нашел ни единого упоминания о этом замечательном расширении для Google Chrome. Хочу поделиться им с сообществом, потому как в последнее время оно помогает мне каждодневно экономить минут 10 — уж очень много скриншотов из социальных сетей на разных языках которые с помощью этого плагина переводятся в два клика.

Встречайте — Project Naptha (Chrome webstore).



Список возможностей:

• копировать текст с картинки
• выделить весь текст
• гуглить выделенный текст
• переводить выделенное (бета)
• проговорить (TTS) выделенное

Вчера в блоге Apache FSF появилась интересная запись. Уязвимым оказалось практически все ПО, которое использует сериализацию и десереализацию данных совместно с apache commons collections и некоторыми другими библиотеками.
Сама уязвимость была описана 6 ноября, а сегодня Oracle выпустил первые патчи к WebLogic.

Кратко

Тип: Удаленное исполнение кода
Опасность: высокая
Уязвимое ПО: Oracle WebLogic, IBM WebSphere, JBoss, Jenkins, OpenNMS и другое ПО с commons collections в classpath.
Описание: Уязвимость позволяет злоумышленнику создать такой пакет сериализованных данных, который при распаковке заставит уязвимый сервер исполнить произвольный код.

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



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

Наверняка вам трудно поверить приведённым данным. Если вы работали с Perl, то вряд ли подмечали за ним низкую производительность при работе с регулярными выражениями. Дело в том, что в большинстве случаев Perl обращается с ними достаточно быстро. Однако, как следует из графика, можно столкнуться с так называемыми патологическими регулярными выражениями, на которых Perl начинает буксовать. В то же время у Thompson NFA такой проблемы нет.

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

Я с удивлением обнаружил, что многие разработчики, даже давно использующие postgresql, не понимают оконные функции, считая их какой-то особой магией для избранных. Ну или в лучшем случае «копипастят» со StackOverflow выражения типа «row_number() OVER ()», не вдаваясь в детали. А ведь оконные функции — полезнейший функционал PostgreSQL.
Попробую по-простому объяснить, как можно их использовать.

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

Подробно о преобразовании асинхронного кода, осуществляемого компилятором

Механизм async реализован в компиляторе C# при поддержке со стороны библиотек базовых классов .NET. В саму исполняющую среду не пришлось вносить никаких изменений. Это означает, что ключевое слово await реализовано путем преобразования к виду, который мы могли бы написать и сами в предыдущих версиях C#. Для изучения генерируемого кода можно воспользоваться декомпилятором .NET Reflector или ILSpy. Это не только интересно, но и полезно для отладки, анализа производительности и других видов диагностики асинхронного кода.

1. Вступление

Сталкиваясь с необходимостью контролировать работу других программистов, начинаешь понимать, что, помимо вещей, которым люди учатся достаточно легко и быстро, находятся проблемы, для устранения которых требуется существенное время.

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

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

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

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

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

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!

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

Валентин Холмогоров профессионально занимается описанием вредоносных программ, и поэтому вся информация — действительно из первых уст.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

В нашем блоге мы уже неоднократно рассказывали о создании интерактивных email-рассылок с помощью CSS и HTML. Сегодня мы представляем вашему вниманию адаптированный перевод заметки Джастина Ку о том, как сверстать интерактивные вкладки, которые будут работать в почтовых программах iOS, Android и популярных веб-приложениях.

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

Демо материалы лежат здесь.

Предупреждение: эффекты работают только в современных браузерах, поддерживающих возможности CSS3.

Подготовка к работе.

Итак, для того, чтобы создавать наши эффекты нам понадобится вот такая простая дефолтная html-структура:

<div class="effect>
  <img src="img/ef1.jpg" alt="Effect #1" />
  <div class="caption">
    <h4>Title is Here</h4>
    <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut.</p>
    <a class="btn" href="#" title="View More">View More</a>
  </div>
</div>