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

На прошлой неделе мы включили в Яндекс.Почте шифрование для межсерверных SMTP-соединений с использованием STARTTLS — как на приём, так и на отправку писем. Теперь все письма из нашей почтовой системы пользователям других сервисов, которые поддерживают такое шифрование (например, Gmail) передаются в зашифрованном виде, и никто по дороге не сможет их прочитать. По этому поводу я немножко расскажу о протоколах, которые используются при передаче электронной почты в зашифрованном виде.

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



Исследователям ещё предстоит найти причину истинной любви интернет-технологов к аббревиатурам. Со времён ARPANET все сети, протоколы, стандарты и т.д. предпочитают называть буквенными сокращениями. Этот простой и понятный способ словообразования приводит к появлению предложений вида: «IETF published RFC6594 by CZ.NIC on the use of SHA-256 with RSA, DSA and ECDSA in SSHFP». Как видно, особенно много таких сокращений в криптографии.

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

От переводчика: с момента выхода популярной статьи Мартина Фаулера «Микросервисы» (перевод на Хабре) прошло уже достаточно времени, чтобы автор смог дополнить свои наблюдения свежим опытом проектирования и разработки микросервисов в различных компаниях, и рассказать о нем в новом посте, чей перевод представляется вашему вниманию.
Многие команды разработчиков нашли архитектурный стиль микросервисов подходом, превосходящим монолитную архитектуру; другие команды выяснили, что для них микросервисы — лишняя обуза, подрывающая производительность разработки. Как и у любого стиля архитектуры, у микросервисов есть свои плюсы и минусы. Для того, чтобы делать осознанный выбор, вы должны понимать эти свойства и уметь рассматривать их на фоне собственных конкретных условий.

Микросервисы дают преимущества…	…ценою издержек
Жесткие границы модулей Strong Module Boundaries Микросервисы усиливают модульную структуру, что особенно важно для больших команд разработчиков.	Распределённость Distribution Распределенные системы тяжелее программировать, поскольку удаленные вызовы медленные и всегда рискуют неудачей-отказом.
Независимый деплоймент Independent Deployment Простые сервисы проще деплоить, и, поскольку они автономны, меньше вероятность отказа системы в случае, если что-то идет не так.	Консистентность в конечном счете Eventual Consistency Поддержка cтрогой консистентности чрезвычайно сложна для распределённых систем, и это означает, что придется иметь дело с консистентностью в конечном счете.
Технологическое разнообразие Technology Diversity С микросервисами вы можете смешивать несколько языков, фреймворков и технологий хранения данных.	Эксплуатационная сложность Operational Complexity Вам потребуется опытная команда эксплуатации для управления множеством сервисов, которые будут регулярно редеплоиться.

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.

Всем привет!
В первой статье мы рассказали о нашей инфраструктуре в целом. Теперь пришло время сосредоточиться на конкретных продуктах. В этой статье речь пойдёт о DSP. Как многие знают, DSP (Demand Side Platform) — автоматизированная система покупки рекламы. Требования к системе жёсткие: она должна держать высокую нагрузку (тысячи запросов в секунду), быстро отвечать (до 50 мс, а то и меньше) и, самое главное, выбирать максимально подходящие объявления. Чаще всего такие проекты разрабатываются под Linux, мы же смогли создать по-настоящему высокопроизводительный сервис под Windows Server. Как этого добиться, и как это удалось нам? Об этом я и расскажу.

Привет, Хабр! Все привыкли ассоциировать обработку больших данных с Hadoop (или Spark), которые реализуют парадигму MapReduce (или его расширения). В этой статье я расскажу о недостатках MapReduce, о том, почему мы приняли решение отказываться от MapReduce, и как мы приспособили Akka + Akka Cluster на замену MapReduce.

Здравствуйте.
Мы — группа разработки Targetix, и мы занимаемся разработкой всего, что имеет отношение к автоматизированным системам закупки рекламы на просторах интернета. Сразу оговорюсь, что статья ознакомительная, пробежимся по верхам, а детальные разборы отдельных моментов to be continued…

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

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

Всем привет! Мы, в компании Cackle, занимаемся разработкой облачных SaaS-решений для сайтов с 2011 года. Наши продукты установлены более чем на 10 000 сайтах, каждый день мы обрабатываем в среднем 65 миллионов уникальных хитов. Полоса пропускания (bandwidth) в пики доходит до 780 мбит/сек, а БД в сутки принимает до 120 миллионов запросов на чтение, и до 300 тысяч запросов на запись. Такие нагрузки заставляют изобретать непростые решения, частью которых мы и хотим поделиться.

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

К сожалению некоторые конференции

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

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

С видео

Без нормального видео

CodeFest  — большая, Новосибирск 404fest Frameworks days  — про код WebStandardsDays (офф) — про веб Test Automation Days  — про qa SQA days (офф) — про тестирование MoscowJS (офф) — про js КРИ  — про игры WinterNights (офф) — про мобильники Mobius (офф) — про мобильники, Питер ZeroNights  — про безопасность AddConf HappyDev (офф) BitByte (офф) — про железо YaC  — Москва Dump (офф) — Екатеринбург Wake up province  — Саратов Devclub  — Таллинн ITGlobalMeetup (офф) — Питер MsDevCon - 2014 FrontendDevConf (офф)

РИТ++ (офф)- ontico, большая, Москва HighLoad - ontico, большая, Москва RootConf (офф) UXPeople ПрофСОUX (офф) - Стас Фомин, Питер CEE-SECR (офф) - Стас Фомин СПИК (офф) UWDC (офф) DevConf (офф) DevConfu — Таллинн TopConf — Таллинн ITCampus (офф) Кампус (офф) — Казань

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



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

Примечание переводчика: Перевод первой статьи из блога «A Year of Productivity» был благосклонно встречен хабра-сообществом, и меня попросили перевести еще несколько статей из этого блога. Приведенная ниже статья — самая большая и самая близкая к практике, её перевод затянулся у меня на несколько месяцев. Как и прошлый раз рекомендую читать комфортными порциями, записывая (или копируя куда-нибудь) советы, которые хочется попробовать применить на практике.

«Хаки» времени

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

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

Для начала вот несколько моих любимых приемов по тому как:
-  получить больше времени;
-  тратить время на правильные вещи.

Недавно на хабре была публикация о том, как реализована аналитика на ivi.ru. После прочтения захотелось рассказать об аналитике, которую мы делали для одного крупного сайта. Заказчик, к сожалению, не разрешил публиковать в статье ссылку на сайт. Если верить Alexa Rank, то трафик на сайте, для которого мы делали аналитику, раз в 10 больше, чем на ivi.ru.

Среди concurrent коллекций наибольшей популярностью пользуется ConcurrentDictionary. Также часто исползуются ConcurrentQueue и ConcurrentStack.

Вообще, решение локкирования частей коллекции для thread-safe хеш-таблицы является очень простым, логичным и оттого ещё более красивым.

Структура ConcurrentDictionary даже была описана в статье на хабре Под капотом у Dictionary и ConcurrentDictionary. ConcurrentBag же является не столь популярной, так как используется в основном там, где реализуется паттерн Producer-Consumer. Причем данная структура наиболее оптимально работает тогда, когда один и тот же поток занимается добавлением и изъятием данных из коллекции. Почему так происходит, будет рассказано далее.

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

На прошлой неделе случилось то, что хотелось оттянуть на как можно больший срок, но что все равно было неизбежным. Самый инновационный предприниматель Америки, а может, и мира, Стив Джобс оставил пост CEO компании Apple.
Некоторым везунчикам в жизни предоставляется шанс работать над одним революционным устройством. Стив Джобс – человек, который совершил сразу несколько революций в цифровом мире, – по праву может считаться успешным человеком. 
В этой статье собраны 10 наиболее известных и символичных выступлений, которые характеризуют жизнь и карьеру мастера. 

После небольшого перерыва продолжаю переводить видео. Пока еще осталось несколько роликов с Ричардом Фейнманом.

В этот раз знаменитый физик пытается объяснить, насколько сложны вопросы «почему?». Если честно, то мне приятнее осозновать, что на любой ответ можно задать еще десяток «почему?», такая бесконечная рекурсия природы может и немного пугает, но зато гарантирует интересные вещи! Было бы очень обидно, если бы существовал конечный ответ…

(Оригинал ролика на английском языке)

Не секрет, что на ebay, DX, KD и прочих онлайн-магазинах существует много гаджетов и товаров, которых в РФ не найти. Чтобы удовлетворить свои гиковские потребности, а также просто тратить с умом, рано или поздно приходится обращаться к интернет магазинам. Однако новички теряются во всех этих «палках, клеймах, лотах, диспутах, EMS, USPS и прочее», а также некоторые не владеют английским для того, чтобы элементарно зарегиться в paypal.
Для этой цели админом форума ebay-forum.ru был создан подробнейший pdf-мануал, с которым я и предлагаю всем желающим ознакомиться.