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

Меня зовут Антон Титов. Я более 15 лет занимаюсь коммерческой разработкой. Являюсь соавтором Spiral Framework, RoadRunner и Cycle ORM. Основной стек: PHP и Golang.

Как сейчас проходят собеседования на golang разработчика? Что спрашивают?

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

Сразу пишу к чему пришёл в ходе изысканий:

1. ИП на ПСН
2. поступление оплаты за услуги по разработке ПО на счёт ИП в долларах США
3. основание для оплаты инвойс, сумма которого не превышает 200 000 руб.
4. инвойсы выставляются по-мере необходимости
5. ККТ не используется

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

Почему так? Какие могут быть ещё варианты? Чем плохи для меня Upwork, PayPal и Payoneer? Попробую ответить под катом. Кому интересны все эти детали, читаем дальше :-)

Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали

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

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

Я буду использовать термин «время высокой точности». В документации MySQL вы увидите термин “fractional seconds”, но его дословный перевод звучит странно, а другого устоявшегося перевода я не нашёл.

(Update: заменил картинку на более нейтральную)

Коллега упомянул в беседе принцип "Convention over configuration", и я подумал, блин, наверно это что-то крутое, нужно изучить, почитать статьи, а то отстану от жизни.

Каково было моё удивление, что вcё обьяснение помещается в одной фразе "Используй дефолты, которые можно при желании переопределять".

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

В итоге я попытался сделать такую табличку. Можно сказать, своего рода русско-китайский разговорник:

Как похорошел интернет при… или какие полезные (и не очень) госуслуги можно получить онлайн.

Американские хакеры решили повлиять на результаты выборов в России, но пока просто не могут зарегистрироваться на сайте Госуслуг.
_{(с) интернет}

О статье

Сегодня мы выпускаем обновления Yii для нескольких последних версий 2.0.x и официальных расширений поддержки нереляционных баз данных для исправления найденных уязвимостей. Патчи исправляют проблему в методах слоя ActiveRecord: findOne() и findAll(), которые могут допустить SQL инъекцию, если входящие данные не подготовлены должным образом.

Мы рассматриваем это как уязвимость в Yii потому что документация для этих методов не содержала явного предупреждения о том, что в некоторых случаях передача нефильтрованых пользовательских данных может быть опасной. Мы благодарим Analitic1983 (Habr, GitHub) за обнаружение этой уязвимости.

Проблема относится в большей степени не к самому фреймворку, а к документации по использованию данных методов в приложении. Мы обновили документацию и дополнительно привели примеры кода, который может быть опасен. Однако, обновление документации не исправит приложения, в которых разработчики уже используют методы findOne() и findAll() небезопасно. Чтобы избежать наихудшего сценария – SQL инъекции, мы также изменили поведение этих методов и добавили принудительную фильтрацию входящих данных, которая ограничивает перечень возможных имён столбцов списком свойств модели ActiveRecord.

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

У MySQL нет возможности напрямую индексировать документы JSON, но есть альтернатива: генерируемые столбцы.

С момента введения поддержки типа данных JSON в MySQL 5.7.8 не хватает одной вещи: способности индексировать значения JSON. Для того, чтобы обойти это ограничение, можно использовать генерируемые столбцы. Эта возможность, представленная в MySQL 5.7.5, позволяет разработчикам создавать столбцы, содержащие информацию, полученную из других столбцов, предопределенных выражений или вычислений. Генерируя столбец из значений JSON, а затем индексируя его, можно практически индексировать поле с JSON.

Продолжение: Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов