Летом традиционно снижается и покупательская активность, и интенсивность изменения инфраструктуры веб-проектов, говорит нам Капитан Очевидность. Просто потому что даже айтишники, случается, ходят в отпуск. И CТО тоже. Тем тяжелее тем, кто остаётся на посту, но сейчас не об этом: возможно, именно поэтому лето — лучший период для того, чтобы не торопясь обдумать существующую схему резервирования и составить план по её улучшению. И в этом вам будет полезен опыт Егора Андреева из AdminDivision, о котором он рассказал на конференции Uptime day.

При строительстве резервных площадок, при резервировании есть несколько ловушек, в которые можно попасть. А попадаться в них совершенно нельзя. И губит нас во всем этом, как и во многом другом, перфекционизм и… лень. Мы пытаемся сделать всё-всё-всё идеально, а идеально делать не нужно! Нужно делать только определённые вещи, но сделать их правильно, довести до конца, чтоб они нормально работали.

Failover — это не какая-то такая весёлая фановая штука «чтоб было»; это вещь, которая должна сделать ровно одно — уменьшить время простоя, чтобы сервис, компания, теряла меньше денег. И во всех методах резервирования я предлагаю думать в следующем контексте: где деньги?

С лета 1976-го коротковолновую связь по всему миру начал терроризировать «эфирный хулиган». На ряде частот, выделенных для гражданской связи и авиации, поселился характерный стучащий сигнал с частотой 10 импульсов в секунду, мешающий переговорам и трансляциям во множестве стран. Этот стук доводил до белого каления как радиолюбителей, так и тех, для кого радиосвязь была профессиональным инструментом. Судите сами:

https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:Woodpecker.ogg

Причём сигнал был «плавающий» — поработав несколько минут на одной частоте, он переходил на другую. Загадочность и создаваемые неудобства привели к тому, что военные ряда стран попытались запеленговать источник. Оказалось, что он расположен в глубине Советского Союза. А поскольку сигнал — к тому времени получивший прозвище «Русский Дятел», — периодически вторгался на частоты, зарезервированные для авиации, этим не замедлили воспользоваться США, Великобритания и Канада, заявившие СССР протест. СССР сделал удивлённое лицо и ответил, что ничего не знает ни о каком сигнале.

Часть 4. Дороги и перекрёстки.

Предыдущая часть и её краткое содержание.


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

Но если каждый пункт в разделе — фантазия или война, то зачем писать? Не лучше ли промолчать?

Мда… «Хотелось бы побыть страусом, да пол бетонный.» Я верю, что писать надо. Если что-то работает, пусть об этом знают все. Если нет — что ж, пусть задумаются тоже все.

Как-то так.

Приступим.

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

И в один прекрасный день МВД Украины открыло доступ к реестру транспортных средств. Теперь по номерному знаку стало возможным проверять некоторую информацию про автомобиль (марку, модель, год выпуска, цвет и т.д. )! Скучная рутина линейного программирования померкла перед новой свехзадачей — считывать номера по всей базе фото и валидировать эти данные с теми, что указывал пользователь. Сами знаете как это бывает «глаза загорелись» — вызов принят, все остальные задачи на время стали скучны и монотонны… Мы принялись за работу и получили неплохие результаты, чем, собственно и решили поделиться с сообществом.

Для справки: на сайт AUTO.RIA.com, в день добавляется около 100 000 фото.

Датасаентисты давно уже знают и умеют решать подобные задачи, поэтому мы с dimabendera написали эту статью именно для программистов. Если вы не боитесь словосочетания «сверточные сети» и умеете писать «Hello World» на питоне — милости просим под кат…

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

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

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

Итак, сегодня я покажу, как отрисовывать подобные картинки:

Современная DDR3 SDRAM. Источник: BY-SA/4.0 by Kjerish

Во время недавнего посещения Музея компьютерной истории в Маунтин-Вью моё внимание привлёк древний образец ферритовой памяти.


Источник: BY-SA/3.0 by Konstantin Lanzet

Привет, уважаемые хабровчане!

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

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

Привет, Хабр! В момент разгара битвы бабла со злом, мы объявляем о выпуске очередной версии нашей операционной системы. Совпадение? Не думаем!

В этом выпуске — поддержка новых API, возвращение доктора Ватсона, баги с фантастическими историями.



Скачать установочные образы | Пресс–релиз | Список изменений | TL;DR | Тесты и список регрессий

В конце прошлого года компания Red Hat опубликовала доклад с описанием принципов, которым должны соответствовать контейнеризированные приложения, стремящиеся к тому, чтобы стать органичной частью «облачного» мира: «Следование этим принципам обеспечит готовность приложений к автоматизируемости на таких платформах для облачных приложений, как Kubernetes», — считают в Red Hat. И мы, изучив этот документ, с их выводами согласны, а посему решили поделиться ими с русскоязычным ИТ-сообществом.



Обратите внимание, что эта статья является не дословным переводом оригинального документа (PDF), подготовленного Bilgin Ibryam — архитектором из Red Hat, активным участником нескольких проектов Apache и автором книг «Camel Design Patterns» и «Kubernetes Patterns», — а представляет основные его тезисы в довольно свободном изложении.

DISCLAIMER: вы попались на clickbait. Очевидно, что TDD нельзя назвать ошибочным, но… Всегда есть какое-то но.

Содержание

• Вступление
• Тесты и есть проблема!
  
  • Немного истории
  • Небольшая викторина
• Обзор TDD
  
  • Тесты — это формализованные требования
  • TDD поощряет хорошую архитектуру
  • TDD экономит время
  • Тесты — это лучшая документация
  • Немного выводов
• В чём же решение?
  
  • Несколько примеров
  • Немного про планы

Рынок голосовых ассистентов расширяется, особенно для русскоязычных пользователей. 2 недели назад Яндекс рассказала впервые про платформу Яндекс.Диалоги, 2 месяца назад Google представила возможность писать диалоги для Google Assistant на русском языке, 2 года назад со сцены Bill Graham Civic Auditorium Apple выпустила в открытое плавание SiriKit. Фактически, появляется новая отрасль разработки, где должны быть свои проектировщики, архитекторы и разработчики. Идеальный момент, чтобы поговорить про голосовые помощники и api для них.

В этой статье не будет подробных туториалов. Это статья об идеях и интересных технических деталях, на которых построены инструменты для сторонних разработчиков основных игроков рынка: Apple Siri, Google Assistant и Алисы от Яндекса.

Привет Хабр, ранее, в своем блоге по безопасности, мы объявили о планах по снижению доверия Chrome к сертификатам Symantec (включая принадлежащие Symantec бренды, такие как Thawte, VeriSign, Equifax, GeoTrust и RapidSSL). В этом посте описывается, как владельцы сайтов могут определить, повлияет ли на них снижение доверия к сертификатам Symantec, и если да, то что нужно сделать и когда. Отказ от замены этих сертификатов приведет к поломке сайта в будущих версиях основных браузеров, включая Chrome и Firefox.

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

Рассмотрим визуальный пример (картинка найдена на просторах интернета):

Как мы видим, пользователи пришедшие с "рекламных щитов" AdWords оказались наиболее лояльными к этому конкретному приложению (продолжали активно пользоваться приложением).

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

Данную статью меня побудил написать тот скрытый и для каждого свой смысл должности/роли Team Leader. Многие хотят им стать, многим интересно что там, "под капотом", работы в этой должности. Поэтому кому интересно узнать еще одно мнение об этом всем безобразии, то прошу под кат.

Часто задают вопрос – что такое платформа «Единая фронтальная система» (ЕФС) и как ее можно пощупать.

Платформа ЕФС — это единый базис, который позволяет построить омниканальные процессы, объединив множественные пользовательские сервисы в унифицированный и понятный сценарий как для сотрудника, так и клиента.

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

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

Читайте под катом с юмором и иронией вредные советы владельцам продукта и всем тем, кто занимается внедрением новых сервисов.

Около месяца назад Google сервис Colaboratory, предоставляющий доступ к Jupyter ноутбукам, включил возможность бесплатно использовать GPU Tesla K80 с 13 Гб видеопамяти на борту. Если до сих пор единственным препятствием для погружения в мир нейросетей могло быть отсутствие доступа к GPU, теперь Вы можете смело сказать, “Держись Deep Learning, я иду!”.

Я попробовал использовать Colaboratory для работы над kaggle задачами. Мне больше всего не хватало возможности удобно сохранять натренированные tensorflow модели и использовать tensorboard. В данном посте, я хочу поделиться опытом и рассказать, как эти возможности добавить в colab. А напоследок покажу, как можно получить доступ к контейнеру по ssh и пользоваться привычными удобными инструментами bash, screen, rsync.

Ссылка на изображение

Проблема, связанная с защитой персональной информации, передаваемой по публичным телекоммуникационным каналам, на сегодняшний день представляет большой интерес. Возможности высокоскоростных компьютеров и квантовых компьютеров, интенсивно развивающихся последнее время, значительно упростили процесс расшифровки информации. К примеру, с взломом 1024-битного шифрования RSA процессор Pentium 4 управился чуть более чем за 104 часа.

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

А теперь представьте себе такую линию связи, которую невозможно прослушать никакими способами, поскольку это противоречит законам физики. Что бы ни пытался предпринять злоумышленник, у него не получится перехватить передаваемую информацию. Такие устройства для передачи данных, использующие принципы квантовой криптографии, создаются в ООО «Квантовые коммуникации» – малом инновационном предприятии при Университете ИТМО.

Всем привет.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать сотни тысяч RPS на всю систему.

Это означает, что запросы от клиентов и близко не стоит подпускать к реляционной SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш.

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

Процесс создания сервиса не ограничивается разработкой и тестированием. Помимо этого есть ещё и эксплуатация сервиса в продакшн-инфраструктуре.

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

В статье речь пойдет о том, как мы в 2ГИС выстраивали процессы работы в команде Infrastructure & Operations (9 человек) и взаимодействие с командами разработки (5 команд). На первый взгляд, всё просто и логично.

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

Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2146 в закладки, 339k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Давайте ее переведем, ведь мужик дело говорит.

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

Мы уже перевели 4 главы.

Глава 28. Системная Инженерия

(За перевод спасибо Юлии Перуновской, которая откликнулась на мой призыв в «предыдущей главе».) Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru

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

Если бы в обычном кампусе вы решили опросить некоторую выборку профессоров о том, что они собираются делать в следующий академический час, то услышали бы, что они будут: «преподавать наипростейшие дроби», «показывать, как найти момент нормального распределения», «объяснять модуль упругости и его измерение» и т.д. Я сомневаюсь, что вы бы часто слышали от профессора фразу «Я собираюсь обучить студентов и подготовить их к будущей карьере».