^{Остовы кораблей в бухте у острова Русский}

Владивосток основан всего 161 год назад, то есть моложе даже современной Австралии. Чуть раньше появиться он не мог: не было подходящей геополитики. Появись он чуть позже — и там был бы Китай или Япония. А так нам в какой-то момент очень понадобилась торговля с Востоком и защита региона. Выбирали главный город на Тихом океане, были варианты из Петропавловска, Хабаровска, Николаевска-на-Амуре, но именно Владивосток был выбран как военно-морская база: конфигурация островов и полуострова прекрасно подходила для выстроения эшелонированной обороны, а бухта почти не замерзала зимой.

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

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

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

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

Всем привет! Меня зовут Артур, я работаю frontend-разработчиком в Exness. Не так давно мы перевели один из наших проектов на веб-компоненты. Расскажу, с какими проблемами пришлось столкнуться, и о том, как многие концепции, к которым мы привыкли при работе с фреймворками, легко перекладываются на веб-компоненты.

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

Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.

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

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

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

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

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

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

Предисловие

Не знаю, все ли программисты всесторонне любознательные люди, но я всегда пытаюсь получить фундаментальные знания во всех областях, которые могут быть практически полезны. В то время, когда мне в голову пришла эта идея я изучал анатомию и физиологию по журналам «Тело человека. Снаружи и внутри», ну а по работе я занимался стерео-варио фотографиями (для тех кто не знает — были такие советские календарики с ребристой поверхностью, где картинка либо казалась объемной, либо менялась). Так вот, в один из вечеров мне пришла в голову замечательная идея, которую я на протяжении уже 4х лет использую для поддержания своего зрения.
Обещаю, что эффект почувствуете сразу!

Почему bash?

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

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

Предисловие

Данное руководство сопровождает ShellHarden, но автор также рекомендует ShellCheck, чтобы правила ShellHarden не расходились с ShellCheck.

Bash — не тот язык, где самый правильный способ решить проблему одновременно является самым простым. Если принимать экзамен по безопасному программированию в bash, то первое правило BashPitfalls звучало бы так: всегда используй кавычки.

Главное, что нужно знать о программировании в bash

Маниакально ставить кавычки! Незакавыченная переменная должна расцениваться как взведённая бомба: она взрывается при контакте с пробелом. Да, «взрывается» в смысле разделения строки на массив. В частности, расширения переменных вроде $var и подстановки команд вроде $(cmd) подвергаются расщеплению слов, когда внутренняя строка расширяется в массив из-за расщепления в специальной переменной $IFS с пробелом по умолчанию. Это обычно незаметно, потому что чаще всего результатом становится массив из 1 элемента, неотличимый от ожидаемой строки.

Друзья, вновь пришло время авторской колонки корпоративного блога PG Day’17. Предлагаем вашему вниманию сравнительный анализ работы с PostgreSQL из популярных ORM от varanio.

ORM (Object-Relational Mapping), по идее, должен избавить нас от написания SQL запросов и, в идеале, вообще абстрагировать от базы данных (от способа хранения данных), чтобы мы могли работать с классами, в той или иной степени выражающими объекты бизнес-логики, не задаваясь вопросом, в каких таблицах всё это по факту лежит.

Посмотрим, насколько это удается современным библиотекам на PHP. Давайте рассмотрим несколько типичных кейсов и сравним ORM с голым SQL, написанным вручную.

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

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

Каждый раз когда речь заходит о Go приходится слышать один и тот же вопрос:

Является ли Go объектно-ориентированным языком?

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

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker — «Understanding docker».

Что такое докер?

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

За последний год в Docker Hub стало доступно уже более 100 000 образов, а загружались образы с Docker Hub уже более 300 миллионов раз. Из них более 20 миллионов загрузок пришлись на 70 официальных образов разработчиков Docker, таких как Oracle, CentOS и NGINX.

NGINX используется на более 40% самых больших сайтов в мире, не только как веб-сервер, но и как реверс-прокси сервер, балансировщик нагрузки и HTTP кэш. Официальный образ NGINX был загружен 3.4 миллиона раз.



В этой статье вы узнаете:

• как развернуть и использовать Docker-образ с NGINX.
• как быстро развернуть реверс-прокси на NGINX и несколько сайтов в Docker
• как развернуть геораспределенную инсталляцию, состоящую из нескольких сайтов и реверс-прокси в каждом из 3х регионов InfoboxCloud.

Если раньше вы не использовали Docker, рекомендуется к прочтению:
Используем Docker и не волнуемся о vendor-lock
Погружаемся в Docker: Dockerfile и коммуникация между контейнерами
Обзор новшеств Docker Engine с 1.0 до 1.8. Введение в Docker Compose

В конце статьи мы раздаем пробные версии InfoboxCloud бесплатно.

Игорь Сысоев ( isysoev )

Меня зовут Игорь Сысоев, я автор nginx и сооснователь одноименной компании.

Мы продолжаем разработку open source. С момента основания компании темпы разработки существенно увеличились, поскольку над продуктом работает множество людей. В рамках open source мы оказываем платную поддержку.

Я буду говорить о масштабируемой конфигурации nginx, но это не о том, как обслужить с помощью nginx сотни тысяч одновременных соединений, потому что nginx для этого настраивать не надо. Нужно выставить адекватное число рабочих процессов или поставить его в режим «авто», поставить worker_connections в 100 000 соединений, после этого заниматься настройкой ядра — это гораздо более глобальная задача, чем просто настройка nginx. Поэтому я буду рассказывать о другой масштабируемости — о масштабируемости конфигурации nginx, т.е. о том, как обеспечить рост конфигурации от сотни строчек до нескольких тысяч и при этом тратить минимальное (желательно константное) время на сопровождение этой конфигурации.

Недостаток знаний, денег, утечка мозгов и ограничения со стороны законодательства: эксперты из ИТ-парка Казани, ФРИИ и Университета Иннополис — о причинах низкой предпринимательской активности российских айтишников.

Статья была опубликована на LayerVault и была переведенна специально для Хабрахабра.

Идея упрощения

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

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

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