­­ 

На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

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

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

Ребята из французской компании Applidium ровно через месяц после релиза iPhone 4S отреверсили протокол персонального помощника Siri. Ниже перевод статьи, в которой описан сам процесс реверс-инжинеринга и те интересные факты, которые открылись исследователям.

Есть такая потрясающая настольная (не компьютерная!) игра — Сет (The Set). Генетик Марша Фалко (Marsha Falco) изобрела её, делая пометки во время исследования эпилепсии у немецких овчарок. Игра получилась необычной, чрезвычайно увлекательной и мозгозагружающей. Хабралюдям — самое то! Осторожно: может появиться зависимость.

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

Суть задачи

Дано: веб-приложение для совместной работы. Для простоты будем считать, что это CRM или Task Tracker.
Требуется: своевременно уведомлять пользователей о событиях в приложении, на которые требуется их реакция.

В чем проблема?

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

[Статья Armin Ronacher о принципах вычисления коллизий в сетевых шутерах. Носит скорее обзорный и исследовательский, нежели технический характер. Здесь и далее в квадратных скобках примечание переводчика]

Сегодня я хочу выглянуть из своего окошка и поделиться знаниями по весьма сложной теме, в которой я буквально пару месяцев назад ничего не понимал. Зачем? Ну, мне кажется, что это просто здорово – разбираться в этом. А еще это может дать кому-нибудь повод для погружения в эту тему.

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

Введение

Я Ruby on Rails разработчик в одной довольно большой и развивающейся компании. Обожаю свою работу, но также в свободное время пишу различные проекты для души и иногда для денег. В рабочее время писать упомянутое совесть мешает, а личное время всегда хочется сэкономить и потратить на какое-то приятное безделие.

В силу специфики рода деятельности мне нужен следующий реквизит (думаю, это джентельменский набор многих из нас): ноутбук с заряженной батареей, место для сидения и интернет (не постоянно)

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

Введение

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

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

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

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него :)

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

В повествовании будут рассмотрены следующие вопросы:

1. Базовые технологии: XML-RPC, REST, SOAP и краткое сравнение
2. Дао вебсервиса
3. Просветленные API
4. Как отличить сайтовое API от говна
5. Выводы

Метод console.log() — отличный способ вывести отладочную информацию, не мешая пользователю. Но знаете ли Вы, что объект console имеет еще уйму других не менее полезных методов? Очень редко разработчики используют этот функционал, ограничиваясь неблокирующим alert'ом. Что-ж, давайте исправим это положение.

Часть 1. Вступление.
Часть 2. Сбор данных.
Часть 3. Базовые метрики.
Часть 4. От статистики к аналитике
Часть 5. Разделяй и думай
Часть 6. Action!
Счетчики посещаемости знакомы всем пользователям интернета уже много лет. Многие владельцы сайтов ставят сразу несколько иконок разных счетчиков, и день за днём цифры на них растут и всё больше радуют хозяина.



Далеко не все знают, какую информацию можно извлечь из статистики сайта, кроме цифр посещаемости и, иногда, источников посетителей. Однако, современные системы статистики предоставляют куда больше возможностей для подсчета, обработки и анализа данных посещаемости. Их даже стали по-другому называть: «инструменты веб-аналитики»!

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

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

Большинство сайтов можно отнести к маленьким и очень маленьким проектам, масштаба единиц человеко-месяцев. В силу малости размеров такие проекты спокойно поддаются хорошему продумыванию и легко реализуются с помощью водопадной модели, достаточно просто не лениться на каждом этапе разработки (от написания ТЗ до сдачи проекта). Применять к этим проектам гибкие методологии разработки нет смысла, а как раз есть смысл применять хорошее ТЗ. К тем сайтам, которые не попадают под водопадную модель не стоит применять описанный ниже подход.

1. Обоснование необходимости ТЗ

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

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Добрый день, коллеги!

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

Сегодня решил написать статью с одной стороны не IT-ишную, с другой она касается любого человек. Я думаю, многие из вас, уже подсели на сериал «Теория лжи», в этом сериале все события разворачиваются вокруг невербального общения. На эту тему я еще подсел в школе, когда родители мне отрыли секрет, как они определяют, что я вру. Невербальное общение не ограничивается одним враньем, оно охватывает практически все чувства и эмоции человека, это как баги в коде для инжектов и хаков :) Мужчины, как показывает практика, лучше распознают жесты и сигналы тела чем женщины, оно то может и правильно, у них для этого есть интуиция, которая охватывает вообще полу мистические науки, но сейчас не о них.

Все чаще можно услышать про универсальных трекеров-монстров типа ThePirateBay.org, torrents.ru или упоминания трекеров музыкальной либо игровой тематики. Но помимо них давно существуют торрент-трекеры обучающей направленности, о которых мало что известно рядовому пользователю. В основном, это закрытые сообщества образованных людей с регистрацией по приглашениям, которые обмениваются обучающими материалами, будь-то электронные книги, обучающее видео, CBT (computer based trainings), аудио-книги, презентации с конференций или софт для обучения. Преобладающая часть материалов связана с ИТ-технологиями и поэтому будет особенно полезна ИТ-специалистам, от студента, изучающего Linux, PHP или C# и до гуру, который готовится к сдаче CCIE. Также присутствует материал, посвященный изучению иностранных языков, психологии, саморазвитию, соблазнению, развитию бизнес-навыков. Если ты подумываешь сдать на CCNA, MCSE, RHCE, CISSP, Network+, PMP, IELTS/TOEFL и так далее — то здесь можно найти все необходимое и даже больше. Под катом находится обзор англоязычных ресурсов обучающей направленности.

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

Часто приходится слышать, что, мол, если предпринимателю нужна поддержка, это значит, что он плохой предприниматель.
Работая в российском Майкрософт и занимаясь проектами по поддержке технологического предпринимательства, я общаюсь со многими предпринимателями, в том числе с теми, кто многого добился и получил всеобщее признание. И четко вижу, что их отличает в первую очередь то, что они никогда не упускают ни единого шанса получить все, что может помочь их бизнесу.
Поэтому я решил опубликовать топик, посвященный тому, какие ресурсы/программы, имеющиеся сейчас на российском рынке, могут _реально_ облегчить жизнь софтверному стартапу. Опишу те, что известны мне (как предоставляемые Майкрософт и нашими партнерами, так и не имеющие отношения к Майкрософт). А сообщество, надеюсь, дополнит.

Формат «горячей линии», когда читатели топика задают вопросы, а компетентные товарищи (в том числе и читатели) на них отвечают, неплохо показал себя на примере топика о юридических аспектах создания сайта на заказ.

Тема:
Студентам и будущим светилам наук :«Магистратура и аспирантура. Поступление, написание и защита магистерской и кандидатской диссертации. PhD и кандидат наук.»

Правила:

Вступление

Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.