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

Стараясь оставаться в тренде и следуя веяниям моды веб разработки, последнее веб приложение я решил реализовать как набор микросервисов на ruby плюс “толстый” клиент на ember. Одна из первых проблем, вставших перед мной была связана с аутентификацией запросов. Если в классическом, монолитном, приложении все просто, используем куки, сессии, подключаем какой-нибудь devise, то тут все как в первый раз.

Архитектура

За базу я выбрал JWT — Json Web Token. Это открытый стандарт RFC 7519 для представления заявок (claims) между двумя участниками. Он представляет из себя структуру вида: Header.Payload.Signature, где заголовок и payload это запакованые в base64 json хэши. Здесь стоит обратить внимание на payload. Он может содержать в себе все что угодно, в принципе это может быть и просто client_id и какая-то другая информация о пользователе, но это не очень хорошая идея, лучше передавать там только ключ идентификатор, а сами данные хранить где-то в другом месте. В качестве хранилища данных можно использовать что угодно, но мне показалось, что redis будет оптимальным, тем более что он пригодится и для других задач. Еще один важный момент — каким ключем мы будем подписывать наш токен. Самый простой вариант использовать один shared key, но это явно не самый безопасный вариант. Коль скоро мы храним данные сессии в redis, ничто не мешает нам генерировать уникальный ключ для каждого токена и хранить его там же.

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

Привет Хабр! Я опубликовал уже три части из цикла статей (раз, два, три), а тут часть 0, как снег на голову. Как же так? Всё дело в том, что виртуализация является опциональной при построении нашего хостинга. Эта статья — самодостаточна, она не связана с другими частями из цикла. Вы вообще можете их не читать, если просто хотите разделить ваш выделенный сервер на несколько виртуальных машин.

Всё что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

Автор: Вячеслав Михайлов, Solutions Architect.

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

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

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

Продолжение той самой истории.

Многие из нас, наверное, уже устали от этой шумихи вокруг последних стандартов ECMAScript. ES6, ES7 ECMAScript Harmony… Кажется, что у каждого свое мнение на счет того, как правильно называть JS. Но даже несмотря на весь этот хайп, то что сейчас происходит с JavaScript — это самое замечательное, что происходило с ним за последние лет 5 минимум. Язык живет, развивается, комьюнити постоянно предлагает новые возможности и синтаксические конструкции. Одной из таких новых конструкций, безусловно заслуживающих внимания, являются декораторы. Занявшись поисками материалов по этой теме, я понял, что в русскоязычном интернете практически ничего нет о декораторах. В то же время Addy Osmani еще в июле 2015 представил прекрасную статью Exploring ES2016 Decorators на Medium. В связи с этим, я хотел бы представить вашему вниманию перевод этой статьи на русский язык и разместить его здесь.

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

В этой статье будет небольшой обзор по разным типам электродвигателей с фотографиями и примерами применений. Почему в пылесос ставятся одни двигатели, а в вентилятор вытяжки другие? Какие двигатели стоят в сегвее? А какие двигают поезд метро?

Каждый электродвигатель обладает некоторыми отличительными свойствами, которые обуславливают его область применения, в которой он наиболее выгоден. Синхронные, асинхронные, постоянного тока, коллекторные, бесколлекторные, вентильно-индукторные, шаговые… Почему бы, как в случае с двигателями внутреннего сгорания, не изобрести пару типов, довести их до совершенства и ставить их и только их во все применения? Давайте пройдемся по всем типам электродвигателей, а в конце обсудим, зачем же их столько и какой двигатель «самый лучший».

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

Сделаем простую основу для написания сервисно-ориентированной архитектуры. Как стек технологий используем славный Yii2, быстрый Nginx и молниеносный Redis. Почему именно так, станет ясно позднее.

Для управления сущностями на примитивном уровне СREATE, UPDATE, DELETE, GET нам вполне достаточно Rest техники которая заложена в Yii2.

Для облегчения работы в сцепке Nginx + Redis, нам придется использовать немного нестандартный подход, то есть полностью передать как параметры: класс, метод и другие нужные параметры. Для валидации этой компании используем наипростейшую форму Yii2 Model (для экономии места проигнорируем code style):

Привет, Хабр! Меня зовут Владимир, мне 28 лет и я наркоман наркоман. Мой наркотик – простота. На простоту я подсел из-за своего перфекционизма, которым меня наградили при рождении.

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

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

На Хабре не так уж много статей, посвященных Vert.x, раз, два и обчёлся. Поэтому решил внести свой вклад и опубликовать небольшой урок, в котором рассказано, как написать простой чат с помощью Vert.x 3.

Это третья статья цикла, посвященного разработке, управляемой моделями. В предыдущих статьях мы разбирались с OCL и метамоделями, создавали свою метамодель для языка Anchor с древовидным редактором. Сегодня сделаем редактор Anchor-диаграмм.

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Я расскажу, как сделать так, чтобы ваш сайт открывался быстро. Очень быстро.

Индикатор кулачкового аналогового компьютера / Wiki

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

Программы поиска уязвимостей всегда привлекают немало внимания со стороны хакеров и специалистов по безопасности. Ведь это легальный способ неплохо зарабатывать одними только поисками багов (при условии, что есть хороший опыт и голова на плечах). На днях нам представилась возможность взять интервью у багхантера Ивана reactors08 Григорова. Он лидер нашей программы Bug Bounty и занимает 11-е место в общем рейтинге платформы HackerOne.

Как начать искать баги? Может ли это быть единственным источником дохода? В каких Bug Bounty участвовать? Сколько зарабатывают багхантеры? И почему поиском уязвимостей особенно выгодно заниматься в кризис? Ответы на эти и другие вопросы читайте в нашем интервью.

_{На картинке — Ancient Psychic Tandem War Elephant © Adventure Time}

В этой статье будет рассмотрен процесс внедрения в PHP нового оператора. Для этого будут выполнены следующие шаги:

• Обновление лексического анализатора: он будет знать о синтаксисе нового оператора, что позволит потом превратить его в токен.
• Обновление парсера: система будет знать, где может использоваться этот оператор, а заодно какова его приоритетность и ассоциативность.
• Обновление этапа компиляции: здесь происходит обработка (traverse) дерева абстрактного синтаксиса (AST) и извлечение из него кодов операции.
• Обновление виртуальной машины Zend: во время выполнения скрипта она используется для обработки интерпретации нового кода операции для оператора.

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

Вы никогда не задумывались, почему некоторые ноты больше подходят друг другу, чем другие? Как связаны между собой частоты их волн? Почему ноты одной тональности звучат «хорошо»? Почему «хорошо» звучат ноты в составе аккорда?

Читая публикации alexeynadezhin задумался — а не перейти ли мне дома на светодиодное освещение? Как всегда, к вопросу решил подойти скрупулёзно, досконально изучить все тонкости. В итоге пришёл к интересным выводам.

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

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Автор имеет в виду игру слов: «when you assume, you make an ass out of you and me» — «когда вы (что-то) подразумеваете, вы делаете /./удака из себя и из меня»]

И обнаружил кое-что занимательное: почти все регулярные выражения, представлены в интернете как «проверяющие корректность email-адреса», излишне строги.

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