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

История создания терминов

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

Я нередко слышу тезис о том, что есть термины: событие и экземпляр этого события, или переменная и экземпляр этой переменной. Уважаемые аналитики, у меня убедительная просьба к тем, кто использует эти термины, прочитайте конец статьи и подумайте над тем, что там написано. Возможно, вы поймете, что так говорить нельзя.

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

Определение события

Для начала вспомним, что такое физическое и функциональное событие в предметной области.
Событие — это экстент плюс субъективная точка зрения на него.

1. Экстент — это любая 4-Д область из 4-Д пространства-времени. Дело в том, что наше пространство четырехмерно. Просто одно из измерений мы переживаем специфическим образом – как нечто, что разворачивается перед нами в одном направлении. Но для моделирования такая особенность нашего восприятия не имеет значения.
2. Считается, что экстент, который мы считаем событием, с точки зрения рассказчика имеет нулевую временную ширину. То есть с точки зрения рассказчика событие – это мгновение. Однако, всегда существует точка зрения, в которой шириной события уже нельзя пренебречь и нам понадобится рассмотреть временную ширину этого экстента.
3. Событие имеет физический смысл – это факты и ничего, кроме фактов. Мы рассматриваем такое событие как набор фактов без их трактовок. Например, в примере с маяком есть событие смотритель сидит на дровне и отдыхает. Такое событие мы будем называть физическое событие.
4. Кроме физического события существует множество трактовок этого физического события разными субъектами. Например, при описании маяка одно и то же физическое событие «Смотритель отдыхает» может быть описано как: «Розжиг закончен» и «Тушение начато». Такое событие мы будем называть функциональное событие.

В итоге мы имеем такую иерархию объектов:

Довольно часто требуется балансировать нагрузку между несколькими веб-серверами. При этом, как правило, необходимо, чтобы веб-приложения получали реальные IP-адреса клиентов, а не IP балансировщика.

В случае балансировки и терминации HTTP(S)-трафика на HAProxy (Layer 7 [1]) данная задача легко решается добавлением заголовка “X-Real-IP” и его обработкой на Nginx при помощи модуля ngx_http_realip_module [2]. При балансировке TCP-трафика от HTTPS-клиентов и передаче его на веб-сервера напрямую без модификации или терминации (Layer 4 [3]) добавить данный заголовок невозможно, поэтому требуется воспользоваться возможностями, предоставляемыми Proxy Protocol [4, 5, 6].

Рассмотрим оба варианта (балансировка L7 и L4) на примере выдержек из конфигурационных файлов haproxy 1.5.9 и nginx 1.6.2

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

В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].

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

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии :)

Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)

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

1 Один столбец вместо нескольких

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

В предыдущей cтатье мы описали базовые принципы работы с API и консольными утилитами, управляющими отдельными компонентами платформы Openstack (nova, cinder, glance, neutron). Сегодня мы рассмотрим, как с помощью модуля оркестрации Heat можно построить готовую инфраструктуру из виртуальных устройств.

Публикация была перенесена НЛО

Вступление

В прошлой статье я рассказал читателям краткую историю десяти лет развития проекта Openbravo POS. В течении 7 лет я принимал активное участие в нём и совместно с другими участниками разрабатывал систему управления торговой точкой с открытым исходным кодом. Но в этом году я решил перенести все свои накопленные наработки в самостоятельный проект nordpos.mobi и развивать их уже в рамках собственного форка, созданного на базе открытого исходного кода Openbravo POS.

Истоки

Ключевой причиной остановки развития Openbravo POS, стал фактический уход из проекта её основателя Эдрина Ромера, он полностью переключился на разработку коммерческой версии Openbravo Web POS и с 2010 года к исходному коду оригинальной версии больше не прикасался. По этому больших надежд на возрождение проекта я не питал, а необходимость в развитие приложения у меня была.

Добрый день!

В этой статье я рассмотрю unit/integration тестирование в GWT с использованием UI компонентов GWT и GXT и MVP (с Passive View) архитектуры для разделения логики и внешнего вида приложения.
GWT и GXT здесь выделены не случайно — Google разработал несколько framework'ов, которые облегчают поддержку паттерна MVP (точнее, более общее — разделение логики и представления) в GWT. Это Activity and Place для разделения логики приложения на модули, GWT Editor для автоматического мапинга POJO объектов на widget, UiBinding для декларативного описания интерфейса.
Всё это поддерживается ещё и UI framework'ом GXT. Т.ч. по сути не будет большой разницы в использовании UI компонентов GWT или GXT.

В результате получим легко тестируемое приложение без поднятия тяжёлого framework'а GWT.

От переводчика: при разработке Web-payment.ru, сайта с мониторингом обменников и множеством разделов о платежных системах, я на интуитивном уровне использовал принципы, описанные в этой статье. Подсознательно я их знал, но не мог сформулировать. Предлагаю вам ознакомиться с интересным подходом, которым поделился опытный программист, автор многих книг Jeffrey Ventrella.

Мой папа часто говорил мне: «Помедленнее, сынок, ты делаешь дело слишком быстро».

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

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

Потоки ввода-вывода в стандартной библиотеке C++ просты в использовании, типобезопасны, устойчивы к утечке ресурсов, и позволяют простую обработку ошибок. Однако, за ними закрепилась репутация «медленных». Этому есть несколько причин, таких как широкое использование динамической аллокации и виртуальных функций. Вообще, потоки — одна из самых древних частей стандартной библиотеки (они начали использоваться примерно в 1988 году), и многие решения в них сейчас воспринимаются как «спорные». Тем не менее, они широко используются, особенно когда надо написать какую-то простую программу, работающую с текстовыми данными.

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

Сегодня в комментариях у посту возникло обсуждение о медленности iostreams. В частности, freopen пишет

Забавно смотреть на ваши оптимизации, расположенные по соседству со считыванием через cin :)

а aesamson даёт такую рекомендацию

Можно заменить на getchar_unlocked() для *nix или getchar() для всех остальных.
getchar_unlocked > getchar > scanf > cin, где ">" означает быстрее.

В этом посте я развею и подтвержу некоторые мифы и дам пару рекомендаций.

Доброго времени суток.

Изложить свои мысли о теме настоящей публикации натолкнула вполне насущная, «жизненная» необходимость — постепенно приближается время, когда возникнет потребность искать/нанимать на открытом рынке бизнес-аналитиков в штат компании (бизнес в области автоматизации процессов управления документами, контроля исполнительской дисциплины и т.д., в «простонародье» — СЭД). Все специалисты этого профиля, опыт и компетенции которых известны, иными словами тех кого знал и кого видел полезным для компании, либо уже в команде, либо устроены тоже неплохо. Проблему осложняет тот факт, что сколько ни старался, не получается сформулировать кратко и адекватно компетенции, особенности, которыми данный субъект должен обладать. Какие личные качества и таланты должен проявлять — что тоже актуально, так как морально подготовился к тому, чтобы искать талантливых новичков и пытаться их «выращивать». Уверен, что размышления ниже по тексту будут полезны менеджерам проектов, собственникам небольших ИТ-компаний интеграторского типа, да и самим бизнес-аналитикам.

Знакомый владелец интернет-магазина обратился ко мне с просьбой помочь разобраться, почему посетители на сайте есть, а заказов почти нет: при 250-300 посетителях в день у него было 1-2 заказа. Два месяца спустя сайт ежедневно посещает около 500 человек и минимум 10 из них делают заказ. В этой публикации я поведаю о том, что было для этого сделано и как добиться того же для любого другого проекта.

В статье об онлайн-курсе «Введение в Linux» на образовательной платформе Stepic мы обещали рассказать о технической реализации нового типа интерактивных задач, который был впервые применен в этом курсе. Этот тип задач позволяет создавать на лету виртуальные серверы с Linux для работы через веб-терминал прямо в окне браузера. Автоматическая проверяющая система следит за корректностью выполнения заданий.

Пример задания из курса:

---

---

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

Выкладываем доклад мобильного архитектора ТКС Банка Дмитрий Тарасова «Практический пример переиспользования кода. Как повысить качество и ускорить разработку» с конференции мобильных разработчиков #MBLTDev, которая прошла в конце октября.


Презентация

В разработке может сложиться ситуация, когда у вас есть несколько приложений с общей логикой и поведением интерфейса. Дмитрий Тарасов рассказывает о пути, по которому развивалась разработка мобильного банка и кошелька ТКС для Android. Откровенный рассказ о последствиях нетехнологичных решений в стиле copy-paste общего кода из приложения в приложение. Следующий шаг — общая библиотека. Как ее оформить? В виде jar? Оформив, как ее подтягивать в проекты? Grandle или subtree/submodule? Что делать с неравномерным развитием потребителей библиотеки? Решить этот вопрос выстраиванием правил ветвления? Как это вписать в стандартную связку bug tracker — code review — CI (в случае ТКС Jira + Stash + TeamCity)? Что будет, если к изначальным двум приложениям добавится еще два, причем у последнего будет другой backend? Смотрите видео выступления.

Примечание переводчика: Некоторое время назад я прочитал замечательную статью на Medium.com. Автор статьи Samuel Thomas Davies взял за основу исследования профессора Стэнфордского университета Би Джей Фогга об изменении поведения. Сегодня я хочу поделиться ее переводом с хабрасообществом.

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

Очевидно, что делать это намного сложнее, когда вы совершаете ошибки, которые достаточно банальны, но при этом часто недооценены или просто-напросто проигнорированы ввиду их неприметности.

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

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

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

Верстка современных web-проектов – это сложно, долго и дорого. Казалось бы, с переходом IE на автоматические обновления, HTML5, окончанием поддержки Win XP все мы должны зажить в сказочной стране с пони и радугой. Почему легче не стало?

• HTML5 и CSS3 подарили вебу возможность создавать UI, почти не уступающий по сложности и отзывчивости desktop-приложениям. Ничто не дается просто так, HTML, CSS и JS стало в разы больше. Раньше нам хватало трех файлов: styles.css, stupid-ie-must-die.css, scripts.js. Сейчас количество скриптов, стилей, загружаемых шрифтов, картинок измеряется десятками и сотнями. Появилась необходимость в минификации, ускорении рендеринга и организации всего этого барахла в файловой системе.
• Сайты постепенно перестали быть набором связанных гипертекстовых страничек и стали web-приложениями. Если раньше для многих сайтов достаточно было сверстать «главную» и «внутреннюю» страницы, то сейчас все совсем не так просто. Количество дизайн макетов легко достигает десятков и сотен.
• Мы все наслушались про лендинг-пейдж, a/b-тестирование и многократное увеличение конверсии за «просто-так». Оставим за бортом вопрос об эффективности этих методик. Дизайн начали переделывать часто – это факт. Известно, что внесение изменений и поддержка – гораздо дороже и сложнее, чем разработка.
• Появились мобильные устройства и необходимость в адаптивном дизайне. Тестировать стало сложнее и дольше. Цикл исправления найденных при тестировании багов стал дольше. Тестирование UI почти не поддается автоматизации, с ростом функционала время на регрессионное тестирование неуклонно растет.
• Усложнилась интеграция с backend-кодом, появилась необходимость делать это гораздо чаще.

Все это заставляет задуматься об оптимизации работы с фронтэндом.

Хочется:

• Уменьшить время и количество интеграционных работ («натягивание» сверстанного макета на серверную технологию)
• Повысить повторное использование html, css и js, уменьшить количество соответствующего кода
• Снизить время на модификацию существующего кода
• Уменьшить количество ошибок при модификации, особенно регрессии
• Научиться создавать и верстать адаптивный дизайн эффективно

В конце 2008 года на тогда ещё небольшую петербуржскую компанию вышел один западный медиахолдинг примерно так:
— Это вы там упоролись по хардкору и приспособили SSE-инструкции для реализации кода Рида-Соломона?
— Да, только мы не…
— Да мне пофиг. Хотите заказ?

Проблема была в том, что видеомонтаж требовал адовой производительности, и тогда использовались RAID-5 массивы. Чем больше дисков в RAID-5 — тем выше была вероятность отказа прямо во время монтажа (для 12 дисков — 6%, а для 36 дисков — уже 17-18%). Дроп диска при монтаже недопустим: даже если диск падает в хайэндовой СХД, скорость резко деградирует. Медиахолдигу надоело с криком биться головой о стену каждый раз, и поэтому кто-то посоветовал им сумрачного русского гения.

Много позже, когда наши соотечественники подросли, возникла вторая интересная задача — Silent Data Corruption. Это такой тип ошибок хранения, когда на блине одновременно меняется и бит в основных данных, и контрольный бит. Если речь о видео или фотографии — в целом, никто даже не заметит. А если речь про медицинские данные, то это становится диагностической проблемой. Так появился специальный продукт под этот рынок.

Ниже — история того, что они делали, немного математики и результат — ОС для highload-СХД. Серьёзно, первая русская ОС, доведённая до ума и выпущенная. Хоть и для СХД.