Привет Всем! Я недавно запустил на GitHub проект JavaScript Algorithms and Data Structures, который содержит примеры классических алгоритмов и структур данных написанных на JavaScript с объяснениями, примерами и ссылками для дальнейшего изучения (в частности на соответствующие YouTube видео).

Основная задача проекта — помочь программистам в изучении и применении алгоритмов и сделать это на JavaScript-е.

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

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

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

Действующие лица (Команда): разработчиков – 2 человека, админ – 1 человек.

Статья повествует об использовании таких технологий, как Ansible, Docker Swarm, Jenkins и Portainer для реализации CI/CD-пайплайна с возможностью контроля за ним с помощью красивого веб-интерфейса.

Вступление

Чего обычно хочет разработчик? Он хочет творить, не думая о деньгах, и максимально быстро видеть результаты собственного творчества.

С другой стороны, есть бизнес, который хочет денег, да побольше, и поэтому постоянно думает о снижении времени вывода продукта на рынок. Другими словами, бизнес мечтает об ускорении получения MVP (a.k.a. Minimum Viable Product) в новых продуктах или при обновлении существующих.

Ну а чего же хочет админ? А админ – человек простой, он хочет, чтобы сервис не падал и не мешал играть в Кваку Танки и чтобы его пореже дергали разработчики и бизнес.
Поскольку для реализации желаний админа, как показывает правда жизни, его силами должны реализоваться и мечты других героев, представители ИТ-тусовки много работали над этим. Часто получалось достичь желаемого, придерживаясь методологии DevOps и реализуя принципы CI/CD (Continuous Integration and Delivery).

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

Вопросы мошенничества и воровства в магазинах связаны не только с покупателями, но и персоналом. Можно вести дискуссии, кто же из них виновник бо́льших убытков. На практике этот показатель может варьироваться в зависимости от ассортимента, места расположения торговой точки и особенностей системы безопасности конкретного магазина. Опыт наших клиентов показывает, что соотношение между объёмом потерь от покупателей и персонала примерно 50 на 50, с небольшим перевесом в пользу последних. Именно поэтому ритейлеры вынуждены вести борьбу на обоих флангах, и использовать преимущества технологий самообслуживания для снижения убытков.

В интернете уже есть полно книг, статей, да и тех же постов на хабре для начинающих. Но, как по мне, то существует ряд нюансов которые обычно или вообще не упоминаются (видимо, их считают очевидными), либо же упоминаются очень редко. И это не советы из серии «изучайте код других разработчиков», «используйте git», «делайте бекапы» или «мойте руки перед походом в production-консоль». Это обыденные, практические вещи, которые приходят с некоторым опытом. Часть из них не пригодится если вы используете самые современные подходы к разработке, часть из них универсальны. Конкретно в этом посте выражен опыт PHP разработчика, но на самом деле множество пунктов подходят и к другим стекам разработки.

Если вы начинающий веб-разработчик — добро пожаловать под кат, Senior-ы вряд ли найдут там для себя что-то новое

Здравствуйте, в эфире Радио SQL!

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

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

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

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

Прим. перев.: В этой статье, написанной техническим консультантом и сертифицированным администратором Kubernetes из Великобритании — Daniele Polencic, — наглядно показывается и рассказывается о том, какую роль играет kube-proxy в доставке пользовательских запросов до подов и что происходит, когда на одном из узлов кластера возникают проблемы.

Код приложений, развёрнутых в Kubernetes, запускается на одном или более рабочих узлов. Узел может располагаться как на физической или виртуальной машине, так и в AWS EC2 или Google Compute Engine, а наличие множества таких площадок означает возможность эффективного запуска и масштабирования приложения. Например, если кластер состоит из трёх узлов и вы решаете отмасштабировать приложение на четыре реплики, Kubernetes равномерно распределит их среди узлов следующим образом:

Статья опубликована 21 мая 2018 года

Первая часть статьи здесь. Если не читали её, пожалуйста, ознакомьтесь для контекста.

Разобравшись с самыми распространёнными заблуждениями о GDPR, давайте посмотрим на реальное влияние GDPR. Затем рассмотрим наиболее важные полезные советы для владельцев сайтов.

В любом законе кроме его буквального текста есть ещё дух закона, его предназначение. В данном случае предназначение GDPR состоит в том, чтобы обуздать корпорации, которые проявляют худшие практики ведения бизнеса в интернете с нарушением конфиденциальности пользователей. Законодатели стремятся вернуть контроль над данными обратно владельцам этих данных — частным лицам, которые здесь являются субъектами (отсюда термин «субъекты данных»). Есть бесчисленное множество примеров таких нарушений. Не собираюсь их здесь перечислять — на это просто не хватит времени. Но будьте уверены: положение дел таково, что регулирование не начнёт действовать быстро. Постоянные читатели моего блога знают, что тема конфиденциальности мне дорога, поэтому я приветствую GDPR и надеюсь, что закон приведёт к желаемому эффекту. Судя по количеству писем от компаний, которые почти умоляют меня разрешить им присылать спам и дальше — вероятно, это единственный закон, который явно положительно повлиял на мою жизнь ещё до того, как вступил в силу. (По иронии судьбы, эти компании нарушают закон, рассылая такие сообщения…).

Привет! Удивительно, но первая часть статьи даже кому-то понравилась.
Отдельное спасибо за ваши отзывы и комментарии. У меня для вас плохая хорошая новость: нам ещё есть о чём поговорить! А если точнее, то о некоторых деталях работы Reactor.

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

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