Современные web-приложения зачастую содержат множество "движущихся частей" и сторонних зависимостей. В процессе рефакторинга и добавления/изменения функциональности в таком приложении может произойти поломка существующих use-case сценариев и нестабильная работа в определенных браузерах.

Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:

• https://devexpress.github.io/testcafe/
• http://nightwatchjs.org/
  

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

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

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

Привет хабр!

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

"Пфф, ссылки они и в Африке ссылки, чего тут разбираться?" — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?

• http://example.com
• www.example.com
• //www.example.com
• mailto:user@example.com

Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Эрик Рэймонд (Eric Raymond) в своем эссе «Собор и базар» сказал знаменитую фразу:

«При достаточном количестве глаз все ошибки выплывают на поверхность».

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

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

Однако переломным моментом для закона Линуса стало обнаружение уязвимости Heartbleed в OpenSSL — катастрофического эксплойта в результате серьезной ошибки в ПО с открытым исходным кодом. Каковы были масштабы катастрофы? Уязвимыми оказались примерно 18% всех сайтов с включённым HTTPS в мире. В результате злоумышленники могли просматривать весь трафик этих сайтах в незашифрованном виде… в течение двух лет.

Вы считали эти сайты защищёнными? Как же. Эту ошибку не замечали два года.

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

Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.

ownCloud, как утверждает Википедия — это Свободное и открытое веб-приложение для синхронизации данных, расшаривания файлов и удалённого хранения документов в «облаке». И, как мне кажется, довольно интересное решение для организации собственного домашнего облака.

Однако, ownCloud, устанавливающийся в виде плагина в системе FreeNAS, да и просто из коробки, имеет ряд недостатков, от которых хотелось бы избавится даже при использовании дома:

• Во-первых, устанавливается в связке с SQLite, что подходит только если у вас небольшое кол-во файлов и пользователей, и абсолютно не подходит, если вы планируете синхронизацию с помощью клиента. У меня же хранилище уже расползлось почти на 5Tb и установленный таким образом ownCloud просто отказывался видеть часть файлов. Да и без синхронизации отдача от облака не велика. Заменим базу данных на MariaDB.
• Во-вторых, отсутствует работа по https, а мне совсем не нравится мысль о том, что кто-то может перехватить мои файлы. Включим https.
• В-третьих, начисто отсутствует защита от банального подбора пароля методом брутфорса. Защитимся от брутфорса с помощью fail2ban.
• В-четвёртых, мне лень часто просматривать логи на предмет взлома, но очень хочется оперативно узнавать о таких попытках. Настроим push-оповещения о попытках подбора пароля с помощью сервиса pushover.net.

Предисловие

В 2013 году с целью популяризации робототехники в России и создания среды программистов и инженеров, ориентированных на данную тематику компания КРОК (г.Москва) организовала конкурс «Летающие роботы». Наша команда «iKar» (3 человека из Барнаула и 1 из Москвы) участвовала в 2013 году (конкурс «Улететь и вернуться») и 2014 году («Догнать и перегнать Крок») не победила, но добилась неплохих результатов.

1. С чего все началось или условия конкурса

Будучи по профессии программистом 1С, нередко приходится пользоваться форумом forum.mista.ru. Один из моих друзей-коллег первым заметил объявление на тему «Кому лимон» и предложил участвовать.

Условия конкурса выглядели заманчиво: необходимо было построить или купить летающего робота и научить его перемещаться/ ориентироваться в помещении-полигоне, автоматически взлетать и садиться и распознавать посадочные маркеры. Срок на всю работу 1 год, а приз — 1 миллион рублей.



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

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

Недавно один знакомый попросил меня помочь с проблемой. Он занимается разработкой LED ламп, попутно ими приторговывая. У него скопилось некоторое количество ламп, работающих неправильно. Внешне это выражается так – при включении лампа вспыхивает на короткое время (менее секунды) на секунду гаснет и так повторяется бесконечно. Он дал мне на исследование три таких лампы, я проблему решил, неисправность оказалась очень интересной (прямо в стиле Эркюля Пуаро) и я хочу рассказать о пути поиска неисправности.

Приветствую всех читателей! Сегодня хотелось бы поговорить об основных принципах мониторинга бизнес-приложений, которые ежедневно используют многие компании по всему миру. Само понятие «бизнес-приложение» следует понимать как программный комплекс, который обеспечивает поддержку определенного бизнес-процесса компании.

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



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

^{Ачивка, которая даётся вам за то, что вы посмотрели свои ачивки (Galaxy Trucker)}

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

Посмотрите на эту ачивку, например:


Она не только позволяет быстрее распознавать профиль пользователя, но и содержит важную опорную информацию. По ней мы узнаём, что рейтинг топика больше 50 — это хорошо, а 30 постов с таким рейтингом — крутое достижение. То есть здесь решается и задача ускорения передачи информации о юзере, и задаётся цель (что правильно для сообщества), и обозначаются критерии достижения этой цели.

Так получается, что я провожу в консоли (терминале) достаточно времени, порой даже больше, чем хотелось бы. Порой даже исполняю там какие-то команды и внимательно изучаю их вывод. Часто случается, что к выводу той или иной команды приходится возвращаться, а он постоянно теряется: то терминалы захлопываются, то в tmux окно закрываешь, то выводы прочих команд уже давным-давно забили и похоронили ту самую полезную строчку.

Для того, чтобы сохранить вывод какой-либо утилиты я, как и многие, пользовался tee. Это работало, но постоянная суета среди бесконечных error.log, out.log, output.log, err.log log.log, lll.txt и тп если не сводила с ума, то безумно раздражала; вместо того, чтобы вести какой-то порядок, постоянно подмывало создать Новую Папку (1), где и похоронить эти самые логи, периодически бэкапя могильничек: порядок предполагал какую-то систематизацию, а в разгаре работы вспоминать как назвать свой файл крайне не хотелось.

Тогда я написал ah, крохотную утилитку, которая сильно-сильно улучшила мою жизнь.