«Свобода — это возможность сказать, что дважды два – четыре. Если дозволено это, всё остальное отсюда следует.»
Джордж Оруэлл — «1984»

В современном мире активно развиваются различные распределенные технологии. Уже не первый год успешно функционируеют такие проекты как пиринговая платежная система Bitcoin, распределенные микроблоги (Twister), распределенные мессенджеры (например, Tox). Дошло дело и до полноценных распределенных сайтов.

Частично функционал распределённых сайтов уже реализован в таких проектах как Freenet и I2P. Однако подобные проекты имеют ряд недостатков. Например, в настоящее время Freenet не может быть использован для создания или распространения динамического контента, такого, который использует базы данных или скрипты. Для доступа к подобным сетям часто необходимо устанавливать специальное программное обеспечение или скачивать базы данных огромных размеров. Многие пиринговые сети имеют большое время отклика. Между публикацией информации и тем когда ее увидят остальные пользователи проходит немало времени.

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

Визуализация в бизнес-аналитике очень важна. Например, концепт этих графиков отрисован совместно с Infographer.

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

Первое и главное применение бизнес-аналитики — это тупо в лоб уметь строить произвольные отчёты, пока руководители подразделений или члены совета директоров совещаются. Один из моих любимых примеров — с какого завода поставлять водку в магазины: с далёкого (дорогая логистика и 2 недели в дороге), но дешёвого по себестоимости производства или же с ближайшего (1 день), но дорогого?

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

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

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

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

Привет Хабр! Последние 1.5 года я работал над своим проектом, которому был необходим надежный облачный хостинг. До этого момента я больше 10 лет занимался веб-программированием и когда я решил построить свой хостинг у меня были относительно поверхностные знания в этой области, я и сейчас не являюсь системным администратором. Все что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

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

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

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

Вы пришли на мероприятие лично, хотя могли потом посмотреть его в записи в любимых тапочках дома или в вагоне метро по пути на работу. Вы сделали это с какой-то целью, не правда ли? Пообщаться с какими-то важными специалистами; послушать, как решают аналогичные проблемы с анализом больших данных в Hadoop или уменьшают глюки отслеживания Google Analytics более опытные специалисты; познакомиться с новым потенциально интересным стартапом или журналистом, а может, вы сами – стартап и пришли искать полезные знакомства; окучить множество новых клиентов; найти и замотивировать будущих сотрудников. Ваша задача – в течение следующих нескольких часов оставить положительное неизгладимое впечатление на максимальное количество людей. Уже начинает посасывать под ложечкой?

Для синхронизации данных в приложениях не подходят обычные «файловые» облачные хранилища. Слишком много проблем с консистентностью данных приходится решать самим авторам приложений. Поэтому сегодня мы открываем всем желающим технологию DataSync API, которую команда Яндекс.Диска разрабатывала для собственных сервисов Яндекса. Она позволяет синхронизировать структурированные данные между облачным хранилищем и устройствами. API использует логин Яндекса, который есть почти у каждого пользователя интернета в России и у многих в других странах. DataSync мультиплатформенный и не завязан только на Android или iOS.



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

Уже более двух лет Яндекс.Браузер работает на технологиях синхронизации Я.Диска. В ближайшем будущем другие крупные сервисы Яндекса начнут объединять свои платформы на DataSync. Под катом — больше подробностей о том, как он устроен, зачем нужен, и примеры, на которых можно посмотреть и попробовать, как всё работает.

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

Закачка, установка и получение первых результатов — минут 20 максимум.

Я говорю про RapidMiner — опенсорсную среду, которая при всей своей бесплатности некисло «уделывает» коммерческих конкурентов. Правда, сразу скажу, что разработчики всё равно её продают, а в опенсорс отдают только предпоследние версии. Дома можно попробовать потому, что есть вообще бесплатные сборки со всей-всей логикой с всего лишь двумя ограничениями — максимальный объем используемой памяти 1 Гб и работа только с обычными файлами (csv, xls и т.п.) в качестве источника данных. Естественно, в малом бизнесе это тоже не проблема.

Привет, Хабр!



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

Напомню, Хекслет — это платформа для создания практических уроков по программированию в настоящей среде разработки. Под настоящей средой разработки мы подразумеваем полноценную машину, подключенную к сети. Эта важная деталь отличает Хекслет от других образовательных проектов (например, Codecademy или CodeSchool) — у нас нет симуляторов, все по-настоящему. Это позволяет обучать и обучаться не только программированию, но и работе с базами данных, серверами, сетью, фреймворками и так далее. В целом, если это запускается на Unix-машине — этому можно обучать на Хекслете. При этом, понимая это или нет, пользователи используют Test-Driven Development (TDD), потому что их решения проверяются юнит-тестами.

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

Мы уже рассказали о том, как проектировали и стоили наш TIER III ЦОД. Пора уже показать, что получилось.



Сначала на месте дата-центра было чистое поле, затем вырыли здоровенный 100–метровый котлован. Потом дата-центр стал похож на бетонную площадку, а еще позже – из металлоконструкций построили шестиугольное здание, внутри которого расположены шесть модулей ЦОД (на схеме выделены зеленым), «командный центр» для мониторинга магистральной сети по всей стране и офис (подробнее о строительстве можно почитать в публикации «ЦОД нашей мечты в Ярославле: фото строительства и запуска»).



Осторожно, трафик и гикпорн из ярославского дата-центра: 91 фотография только-только запущенного первого модуля, в главном здании кое-где ещё идут финальные работы, но капитального строительства больше не будет.

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

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

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

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

Исследование, проведенное Software Engineering Institute, показывает, что программисты делают 15-20 распространенных ошибок. Добавив такие ошибки в чеклист, вы можете быть уверены, что заметите их в момент появления и поможете от них избавиться надолго.

Чтобы вам было от чего отталкиваться, вот вам список типичных пунктов:

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

КДПВ (эта картинка актуальности не потеряет, наверно, никогда):



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

В этой теме хотелось бы познакомить читателей с относительно новым подходом к контролю доступа под названием Attribute-based access control. Знакомство будет происходить на примере сравнения с популярным нынче Role-based access control.

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



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

Привет.
Хочу рассказать вам несколько интересных новостей о том, что происходит с Portaller — небольшим сервисом для использования Pandora, Spotify, Netflix и еще нескольких сервисов за пределами США.

Одной строкой, если у вас нет времени идти под кат — кроме Pandora и Spotify теперь поддерживается Netflix и Amazon Video, сервис работает на всех устройствах, включая клиентов на Android (почему на нем такой акцент — читайте ниже) и к нему можно присоединиться на GitHub.

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

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

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

Я хочу поделиться своим опытом использования MS Project для управления проектами по разработке программного обеспечения. Я уже лет 10 занимаюсь управлением проектами,
и в результате у меня родилась некоторая методология использования MS Project, которая позволяет получить от него немалую пользу и при этом меньше зависеть от его недостатков.