Вместо предисловия

Сегодня приснился сон, как-будто меня ужали до размера нескольких
килобайт, засунули в какой-то сокет и запустили в контейнере.
Выделили транспорт в оверлейной сети и пустили
тестировать сервисы в других контейнерах…
Пока не сделали docker rm

Не так давно мне посчастливилось стать членом очень крутой команды
Centos-admin.ru, в которой я познакомился с такими же, как я: единомышленниками со страстью к новым технологиям, энтузиастами и просто отличными парнями. И вот, уже на второй рабочий день меня с коллегой посадили работать над одним проектом, в котором требовалось «докерировать всё, что можно докеризировать» и было критически важно обеспечить высокую доступность сервисов.

Скажу сразу, что до этого я был обычным комнатным Linux-админом: мерился аптаймами, апт-гет-инсталлил пакеты, правил конфиги, перезапускал сервисы, тайлил логи. В общем, не имел особо выдающихся практических навыков, совершенно ничего не знал о концепции The Pets vs. Cattle, практически не был знаком с Docker и вообще очень слабо представлял, какие широкие возможности он скрывает. А из инструментов автоматизации использовал лишь ansible для настройки серверов и различные bash-скрипты.

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

Что мы будем рассматривать в данной статье?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие

«Определение ада: «Тот человек, которым вы стали, в свой последний день на земле встретится с человеком, которым вы могли бы стать».
— Автор неизвестен

Всем привет!

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

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

Порядок действий для установки PHP 7.1 и разворачивания проекта на PHP на созданном Amazon AWS EC2 instance. Основано на этой статье, с дополнениями отсюда и из других источников. Используется более новая версия PHP, добавлены инструкции по установке HTTPS, и пример настройки проекта на Laravel. Подразумевается, что инстанс используется в режиме разработки.

Многие из нас бывали на айтишных конференциях. А если не бывали, то наверняка смотрели трансляции, записи или читали расшифровки докладов на Хабре. А вы знаете, какие доклады становятся хитами даже на самых-самых хардкорных мероприятиях? Внутренности сложных технологий? Нет. DevOps? Отнюдь. Чаще всего приз зрительских симпатий берут так называемые доклады-кейноуты — презентации людей, вовсе не обязательно связанных с IT. Дело не в красивой презентации и даже не в харизме докладчика, а в том, что эти ребята знают секрет SUCCES. Нет, мы не опечатались.

Источник: Duran

• Виза
• Перелет
• Собственность на Филиппинах
• Особенности филиппинского менталитета
• Английский язык
• Где лучше жить и работать на Филиппинах
• Транспорт
• Безопасность в городах Филиппин
• Образование
• Филиппинский язык
• Уровень жизни
• Джипни
• Филиппинская кухня и продукты
• Медицина
• Техника и интернет на Филиппинах
• Цена на машины
• Поиск рабочей силы
• Внешность аборигенов
• Развлечения
• Тайфуны
• Бюрократия и коррупция

Привет, сообщество!

Увидев это видео, я не смог не поделиться им с вами. Wacom опять на высоте, глядите:



Пишу под большим восхищением. Как же не терпится впустить это чудо в жизнь!

P.S. продажи с 30 сентября.

В нашей команде работает более 30 человек. Мы разрабатываем масштабируемые решения для web. Живем в Томске, Санкт-Петербурге и в Москве. Для организации совместной работы над задачами мы использовали task-трекер. Во время проектов создавались ценные наработки и нужно было организовать работу со знаниями. Мы пробовали различные wiki-системы. Оказалось, что большая часть наших знаний создается при решении текущих задач. Мы сталкивались с проблемами:

• Заносить и вести все задачи в task-трекере неудобно, и поэтому сотрудники все время переходят на общение через мессенджеры.
• Много знаний оседает в e-mail и месенджерах. Перенос знаний из переписки в task-трекер и wiki отнимает много сил и времени.
• Если при планировании проекта в wiki была записана вся концепция проекта, то с каждым днем различий между информацией в wiki и реальным положением дел становится все больше, и поддержка базы знаний становится неоправданно трудоемкой.

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

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

Сегодня бродил по проектам на Google и наткнулся на довольно интересную разработку — pytesser. По утверждению разработчика распознать текст на изображении. Библиотека использует tesseract-ocr и PIL.

Была задача в максимально короткие сроки (зачет нужно было сдавать) человеку далекому от программирования объяснить паттерны на самом простом уровне.
В результате баланса простоты изъяснения и адекватности, образовалась эта шпаргалка.
Просьба оценить эту самую адекватность и простоту.

Не так давно в блоге stackoverflow появился интересный пост от сооснователя компании Stack Exchange Joel Spolsky о расчёте зарплат разработчикам. Далее до хабраката выдержка из этого поста, а после — вольный перевод документа по системе компенсации в Stack Exchange.

Сейчас то самое время года, когда мы пересматриваем зарплату каждого сотрудника с целью убедиться, что она соответствует его уровню. Мы зависим от десятка системных разработчиков и платим им на основе системы компенсации, разработанной нашими двоюродными братьями из Fog Creek, которая настолько отличается от Stack Exchange, что возникали некоторые трения.

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

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

Я уже достаточно давно провожу технические интервью с кандидатами на позицию Software engineer и на моем счету их имеется несколько десятков. Сегодня я попробую сформулировать основные моменты, которые лично мне, как интервьюеру, кажутся довольно важными.

Советы довольно очевидные (хотя, как показывает практика, бывают и те, кто не знает этих очевидных вещей) и субъективные.

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

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

Вопрос: картинки будут?
Ответ: будут.

Вопрос: какое отношение этот топик имеет к Хабру?
Ответ: он интересен читателям Хабра.

Вопрос: нет, всё-таки, какое отношение имеет топик к тематике Хабра?
Ответ: никакого; просто я считаю, что Хабр — это, прежде всего, определённая аудитория, а не тематика.

Вопрос: почему в блог «Интернет»?
Ответ: потому что Internet is for porn.

Третья и заключительная часть стенограммы-трилогии (см. часть 1 и часть 2) доклада про Дополненную Реальность.

Речь пойдет об обработке изображений в применении к дополненной реальности:

• детектирование маркеров и меток;
• многокамерные системы маркерного захвата движений;
• структурированная подсветка;
• Z-сенсоры (в частности, Kinect);
• использование баз данных поз;
• чисто оптические системы захвата движений.

И на закуску — субъективный взгляд на будущее дополненной реальности, который прояснит смысл картинки с собакой.

Это продолжение (см. часть 1) стенограммы одноименного доклада с конференции ADD-2010.

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

Аннотация

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

В докладе после краткого экскурса в историю рассматривается текущее¹⁾ состояние дел в освоении дополненной реальности:

• использование датчиков: акселерометры, гироскопы, магнитные компасы, GPS
  (различные мобильные телефоны, Wii, Sony Move, XSens)
  
• использование маркеров: с инфракрасной подстветкой, в видимом диапазоне
  (Sony Move, OptiTrack, Vicon)
  
• использование структурированной подсветки
  (на примере Microsoft Surface)
  
• Z-камеры, выдающие картику + расстояние до объекта
  (Microsoft Kinect, её предшественники и аналоги)
  
• безмаркерный захват движений
  (OrganicMotion, iPi Soft Desktop Motion Capture)
  
• сканирование 3d-поверхности по набору изображений:
  (стереокамеры, 3d-сканеры, воссоздание 3d-сцены с движущейся камеры)
  

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

Пример кросс-авторизации

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

Есть у меня мечта. Уехать из города (живу в Днепропетровске) в село на ПМЖ. Друзей всех я этой темой задолбал уже наверное, хотя есть товарищи, разделяющие эту идею Решил поделиться с интернет-сообществом, и, возможно, найти единомышленников. Буду рад критике, предложениям, советам.