Прим. перев.: в этой статье венчурный капиталист и инвестиционный партнер Upfront Ventures Марк Састер рассказывает о проекте MakeSpace, которому он оказал поддержку.

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

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

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

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Введение

Многие интересуются Full-Mesh (или P2P) VPN, хотят использовать их для игр с друзьями, для связи удаленных офисов, серверов, да для чего угодно. Обычные VPN, вроде OpenVPN или PPTP, пропускают весь трафик через центральный сервер, а Full-Mesh соединяются непосредственно с нодами, зачастую пробивая NAT.

Все чаще крупные компании задумываются о контроле и отслеживанию доступа к критичным для бизнеса серверам. Кто зашел, что сделал и когда? Встроенное логирование не всегда удобно и «читабельно», и вот на российский рынок постепенно стали выходить продукты по «контролю привилегированных пользователей». Мне показалось интересным сравнить два «основных» продукта этой линейки, а именно Balabit Shell Control Box и Wallix Admin Bastion.

Примечание: Для сокращения объема статьи сравнение будет только в разрезе протокола rdp и функционала в целом, в результате чего имеет относительно общий характер. Протокол ssh также поддерживается данными продуктами, однако в этой статье он НЕ рассматривается, чтобы не мешать все «в одну кучу».

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

Собираем подборку вместе. Будем рады добавить книги согласно вашим предложениям, которые было бы удобнее всего высказать в комментариях.

Мегамозг, привет!

Мой сегодняшний собеседник — Егор Волков, генеральный директор и совладелец агентства Greensight.



Greensight известен на рынке за один из самых ярких стартов, или эффект Навального, как они сами его называют. Открывшись за неделю до кризиса, через пару лет агентство оказалось на высоких позициях во всех ключевых рейтингах. В его портфолио только первоклассные работы и известные бренды. Greensight задумывался как дочерняя компания QSOFT, а стал его конкурентом. А еще они живут и работают в Зеленограде и видят в этом одни преимущества.

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

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

Эта статья в первую очередь пригодится тем, кто использует тот же стек технологий, что и наша команда, а именно: ASP.NET, C#, NUnit, Selenium 2, git, MSBuild. Будут рассмотрены такие задачи, как интеграция с git, сборка C#-проектов, NUnit-тесты (как модульные, так и тесты UI), а также деплой на сервер. Впрочем, наверняка найдётся интересное и для других пользователей, кроме разве что съевших на этом вопросе собаку. Но они опять же смогут обратить внимание на ошибки в статье или что-то посоветовать: например, как оптимизировать фазу деплоя.

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

Поэтому фрилансеры очень редко ходят на собеседования. За более чем 10 лет своего профессионального стажа я был на собеседованиях 4 (четыре) раза, включая вчерашнее.

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

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

Однако, было поставлено условие — работа только в офисе. Никакой удалёнки.

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

Я постараюсь рассказать, почему удалённая работа — это особенный статус, от которого очень сложно отказаться.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Перевод статьи «Core Frameworks Don’t Work (most of the time)» от Rudy Lacovara, в которой он критикует практику, когда компании создают собственные универсальные платформы для разработки ПО, на основе которых реализуют несколько совершенно не связанных проектов. На картинке изображен Борг из Стар Трека, это раса киборгов, которая ассимилирует все встречающиеся организмы в единый супер-организм.

Нередко ставится задача объединить офисы или подключить удаленных сотрудников. В 3CX — это можно решить несколькими способами, от стандартных и уже привычных (проброс портов, подключение peer-to-peer и т.д.), до вариантов, которые предлагает система 3CX. Рассмотрим варианты с объединением офисов:

1. Где есть IP-АТС 3CX в обеих точках (Часть 1)
2. Подключение удаленных сотрудников без телефонной станции (Часть 2)

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

Задача

В тестовом заданий от компании Wheely мне предстояло реализовать аутентификацю через код в смс-сообщении. Суть процесса в следующем:

1. Пользователь совершаете какое-либо действие.
2. Для подтверждения этого действия генерируется код.
3. Код отправляется в СМС-сообщении.
4. Пользователь указывает ключ.
5. Ключ проверяется на соответствие.

Результатом должно было стать самостоятельное приложение, которое выполняет задачи, обозначенные в пунктах 2, 3 (только имитация), 5. Пины становятся не актуальны через 2 минуты после генерации. Все остальное на мое усмотрение.

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

Здравствуйте, уважаемые читатели!

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

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



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

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

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

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

Архитектура, которую поощряет Docker — это изолированные контейнеры, каждый из которых выполняет одну команду. Эти контейнеры должны знать только как друг друга найти — другими словами, о контейнере нужно знать его fqdn и порт, или ip и порт, то есть, не более, чем о любой внешней службе.

Рекомендованный способ сообщить такие координаты внутрь процесса, выполняемого в Docker — переменные окружения. Типичный пример этого подхода, не применительно к докеру — DATABASE_URL, принятый во фреймворке Rails или NODE_ENV принятый в фрейворке Nodejs.

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

Посетил я недавно Кипр, поделюсь опытом.

Не хотел прерывать связь с родиной, хотел навигацию для самостоятельных путешествий, да и приглядывать за бизнесами надо было.

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

Вашу Голосовую симку ровно перед вылетом надо переадресовать на один из сервисов переадресации. Из простых путей дешевле magic.mtt.ru найти сложно — переадресация звонков в Европу на мобильные по 3.99 р в минуту, московский номер в 499 коде 300 р в месяц. Есть и сложный путь, например из скрещивания мегафоновского мультифона, pbxes.com и rynga.com, почитать, например здесь

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

Привет! Я Максим Андреев, программист бэкенда Облака Mail.Ru. На последнем Security Meetup’е я поделился результатами своего исследования протокола автоматической настройки прокси WPAD. Для тех, кто пропустил, — сегодняшний пост. Я расскажу о том, что такое WPAD, какие возможности для эксплуатации он предоставляет с точки зрения злоумышленника, а также покажу примеры того, как можно частично перехватывать HTTPS-трафик с помощью этой технологии.

В то время, когда одна небольшая компания открыла для себя Linux в роли ОС для интернета вещей, другие ребятки создали «самую маленькую ОС для интернета вещей». Она требует лишь 10кб памяти — и вроде пора праздновать, однако…

Аксиальный ДВС Duke Engine

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


Классический ДВС

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



С такими проблемами столкнулись инженеры ДВС для первых самолётов. Они, в конце концов, пришли к красивой схеме «звездообразного» двигателя, где поршни и цилиндры расположены по кругу относительно вала через равные углы. Такая система хорошо охлаждается потоком воздуха, но очень уж она габаритная. Поэтому поиски решений продолжались.

В 1911 году Macomber Rotary Engine Company из Лос-Анджелеса представила первый из аксиальных (осевых) ДВС. Их ещё называют «бочковыми», двигателями с качающейся (или косой) шайбой. Оригинальная схема позволяет разместить поршни и цилиндры вокруг основного вала и параллельно ему. Вращение вала происходит за счёт качающейся шайбы, на которую поочерёдно давят шатуны поршней.