Несколько месяцев назад разработчики Chrome объявили, что в июле 2018 года начнут помечать как небезопасные все страницы HTTP. Значок «Не защищено» (“Not secure”) появится в адресной строке рядом с URL.

Это важное нововведение, потому что людей приучают избегать сайтов, которые не установили сертификат TLS для шифрования трафика. Ведь такие сайты действительно подвергают опасности пользователей. Например, провайдеры и другие злоумышленники могут внедрять в незашифрованный трафик рекламу, криптомайнеры и другой вредоносный контент. В опросе на Хабре 55% пользователей согласились, что все сайты должны шифровать трафик по HTTPS.

Сейчас стало известно об ещё одном изменении, смысл которого сразу не так очевиден. Оказывается, с версии Chrome 69 (сентябрь 2018 года) у защищённых сайтов HTTPS исчезнет индикатор «Защищено». Спрашивается, почему?

Многие уже научились строить чистые интерфейсы и писать «undo-redo» в несколько строчек. Но как быть с анимациями? Часто их обходят стороной, и они не всегда вписываются в подход (state) ↦ DOM. Есть отличные решения вроде React Motion, но что если вам нужно делать сложные анимации или работать с Canvas, используя физический движок?

В нашем тексте рассказывается, как работать с анимациям в React-приложениях, и сравнивается несколько подходов (D3, React-Motion, «грязные компоненты»). А также о том, как «запускать» анимации в Redux-приложениях. Материал основан на расшифровке доклада Алексея Тактарова с нашей декабрьской конференции HolyJS 2017 Moscow. Прилагаем заодно видеозапись этого доклада:


Осторожно, трафик: под катом много картинок и гифок (сами понимаете, материал про анимации).

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Есть у меня одно увлечение – интервьюировать IT-специалистов из Кремниевой долины. Не с целью приема на работу, а просто о жизни в США и работе в крупных компаниях.
Мой сегодняшний герой – Евгений Краско, программист из YouTube.


Программист из Google о российских дипломах, собеседованиях и работе в Кремниевой долине

– Я родом из Екатеринбурга, после окончания школы поступил в ИТМО на кафедру компьютерных технологий и переехал Петербург. Через 2 года я перевелся на кафедру высшей математики, а на 4 курсе решил, что все-таки надо заняться программированием. Практическому программированию я начал учиться на Java-курсах в Exigen Services, а на теоретические курсы пошёл в Computer Science клуб. Параллельно я начал поступать в магистратуру в Академический Университет на направление Software Engineering.

В магистратуре мне понравилось – я прошёл стажировки в Яндексе и JetBrains; стал работать преподавателем на кафедре – и после её окончания я остался в аспирантуре СПбАУ. Вместе с этим через полгода работы я решил попробоваться в Google (прим. – YouTube принадлежит Google) и получил оффер. Таким образом, Google – это мой второй работодатель, а как программиста и вовсе первый. Процесс переезда оказался довольно долгим: с момента первого интервью и до первого рабочего дня прошло почти полтора года. Даже после того, как ты получаешь оффер, остается еще очень много дел: получение визы, подбор команды и непосредственно сам переезд. Однако, такие длинные сроки сыграли мне на руку – благодаря им я многое успел в аспирантуре. Оставалось только защитить диссертацию, что я и сделал, вернувшись ненадолго в Россию уже из США через два года.

Несколько недель назад я обнаружил пост "Окисляем Source Maps с Rust и WebAssembly"
распространяющийся по Твиттеру и расказывающий о выигрыше в производительности от замены обычного JavaScript в библиотеке source-map на Rust, скомпилированный в WebAssembly.

Пост возбудил мой интерес не потому, что я большой фанат Rust или WASM, скорее потому что я всегда интересовался фичами языков и оптимизациями, которых не хватает Javascript для того чтобы достичь аналогичной производительности.

Так что я скачал библиотеку с GitHub и отправился в небольшое исследование производительности, которое я документирую здесь практически дословно.

Вы все пишите блистательно,
а я потом добавлю шероховатости.
х/ф Трамбо

Написать Java код не просто, а очень просто. Трудности начинаются, когда его запускают или, хуже того, если его требуется изменить. Открыв свой код двухлетней давности, каждый хотя бы раз задавался вопросом: кто же все это написал? Мы в Wrike разрабатываем продукт и делаем это уже более десяти лет. Подобные ситуации случались с нами неоднократно. За это время мы выработали ряд принципов в написании кода, которые помогают нам сделать его проще и нагляднее. Хотя в нашем подходе нет ничего экстраординарного, он во многом отличается от того, как принято писать код на Java. Тем не менее, кто-то может найти нечто полезное в нашем подходе и для себя.

Этот конкретный твит от Сафьи Абдалла сподвиг меня на некоторые размышления:

Пожалуй, непопулярное мнение (и тут немного иронии от меня).

Чтобы быть способным и отличным инженером, вам не нужно писать статьи в блоге, участвовать в проектах open source, выступать с техническими лекциями или делать что-нибудь ещё.

Можете оставить свой код в офисе — и это вполне нормально.

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

Об авторе: Дэниель Лемир — профессор компьютерных наук в Университете Квебека (Канада). Его исследования затрагивают производительность программного обеспечения и инженерию данных

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

Однако мы часто используем текстовые форматы; например, веб-страницы и электронные письма должны быть в текстовом формате. Как же мы отправляем изображения по электронной почте? Как внедряем картинки на веб-страницы? Один из вариантов — поставить ссылку на реальный бинарный файл. Другой типичный подход — встроить бинарный файл непосредственно в тело письма или веб-страницы с помощью base64. Base64 — это просто стандартный текстовый формат, который можно использовать для кодирования любых бинарных данных. Если быть точным, то код base64 — всегда валидный текст ASCII (и поэтому также валидный UTF-8). Каждый байт кода base64 содержит 6 бит данных. То есть мы «теряем» примерно 2 бита на байт. Поэтому эквивалент base64 бинарного файла будет примерно на 33% больше. На практике такое увеличение размера редко становится проблемой. Насколько я знаю, приложения к электронным письмам почти всегда кодируются в base64.

При написании HTML я нашёл удобным внедрять изображения напрямую в HTML-код с помощью схемы data URI. Например, в недавней статье я таким образом закодировал файл PNG. Крупнейшие веб-сайты вроде Google постоянно используют эту схему. Небольшим недостатком становится то, что веб-страницы чуть увеличиваются в размере (что очевидно) и нельзя воспользоваться преимуществами кэширования изображений. Но зато браузер экономит один сетевой запрос.

Всем привет.

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

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

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

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

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

Вашему вниманию предлагается перевод свежей статьи Брюса Доусона – разработчика, сегодня работающего в Google над Chrome для Windows.

Недавнее открытие уязвимостей Meltdown и Spectre напомнило мне о том случае, как однажды я обнаружил подобную уязвимость в процессоре Xbox 360. Её причиной была недавно добавленная в процессор инструкция, само существование которой представляло собой опасность.

В 2005 году я занимался процессором Xbox 360. Я жил и дышал исключительно этим чипом. У меня на стене до сих пор висят полупроводниковая пластина процессора диаметром в 30 см и полутораметровый постер с архитектурой этого CPU. Я потратил так много времени на то, чтобы понять, как работают вычислительные конвейеры процессора, что, когда меня попросили выяснить причину загадочных падений, я смог интуитивно догадаться о том, что к их появлению могла привести ошибка в дизайне процессора.

Однако, прежде чем перейти к самой проблеме, сначала немного теории.

Если сообщения верны, Intel допустила весьма серьёзную уязвимость в своих центральных процессорах, и её нельзя исправить обновлением микрокода. Уязвимость затрагивает все процессоры Intel за последние лет десять как минимум.

Закрытие уязвимости требует обновления ОС, патчи для Linux уже вышли, Microsoft планирует закрыть её в рамках традиционного ежемесячного «вторника патчей». На данный момент детали уязвимости не разглашаются, но некоторые подробности всё-таки выплыли наружу благодаря Python Sweetness и The Register.

Я отличница. Конечно, не совсем та, которая со сложенными ручками, пятёркой по поведению и отглаженным воротничком. Но золотая медаль, олимпиады, красные дипломы в количестве трёх штук и прочая атрибутика «школьного» успеха налицо. Вот уже 11 лет я работаю в бизнесе — всё это время в ИТ: инженером по тестированию, инженером VoIP, коммерсом. Хорошо работаю, почти не придраться. Всё на «пять», часто с плюсом. И у меня, как у любой отличницы, много историй про одноклассниц, которые в 33 года и замужем, и на последних «мерсах», и со своим делом. «Харэ ныть, пора разобраться, какого, собственно, так происходит?» — в один из дней эта мысль плотно засела в голове. И вот он, разбор полётов — для нас, отличников, для будущего поколения и для родителей, которые «тянут» своих детей от пятёрки к пятёрке.

Сказать, что для Docker'а 2017 год выдался тяжёлым, было бы преуменьшением. Не могу вспомнить ни одного столь раскрученного и хорошо обеспеченного деньгами стартапа из Долины, кроме Uber'а, который бы провёл 2017 год так же невнятно, как Docker. 2017 стал тем годом, когда Docker, великолепный образчик программного обеспечения, был полностью уничтожен плохим бизнес-управлением. Эта заметка — сторонний взгляд на то, как и где Docker пошёл не туда, и как попытки что-либо исправить оказались слишком слабыми и запоздалыми.

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

Эта публикация — про то, как программист помогает создавать суррогаты.

Суррогат – это когда сделали не то, что нужно бизнесу. Или не так, как нужно бизнесу.

Суррогаты – это самое страшное зло, происходящее сейчас с российским бизнесом и государственным управлением. Суррогаты – это лучший в мире киллер эффективности. Что особенно приятно, мы, программисты, на этот раз не в стороне – мы на самой оси зла.

С чего все начинается

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

Программист, допустим, толковый – он понимает, что предлагаемая доработка – суррогат.

Вариантов развития событий много, я приведу некоторые из них:
1. Программист говорит: согласуй с моим или своим начальником, тогда сделаю;
2. Программист говорит: напиши мне задачу/поручение/служебную записку, на бумаге или в информационной системе;

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

Уже тысячи и тысячи мужчин и женщин по всему миру используют этот современный подход, который гарантирует потрясающие выигрыши в производительности и эффективности по сравнению с устаревшими методиками, такими, как Scrum, Agile, Kanban.

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

Итак, встречайте — Porozhnyak!

Биохакер Джошуа Зайнер хочет создать мир, в котором любой человек способен и в праве экспериментировать со своей ДНК.

«У нас здесь немного ДНК и шприц», – говорит Джошуа Зайнер в комнате, полной синтетических биологов и других исследователей. Он наполняет иглу и вонзает её в кожу. «Это изменит мои мышечные гены, и даст мне больше мышечной массы».

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

30 ноября в Питере пройдет ежегодная встреча Dart-разработчиков. Что это такое?
Во-первых, это возможность узнать что-то новое (если вы вдруг никогда не слышали о Dart). Во-вторых, это повод хорошо провести время, тем более, что в этот раз всё будет не совсем обычно.

Некоторые владельцы новейшего смартфона от Apple iPhone X жалуются на то, что дисплей телефона при низких температурах (около нуля и ниже) начинает плохо реагировать на прикосновения. Одним из первых об этом сообщил пользователь Darus 214 на Reddit. Он заявил, что его iPhone X практически перестал реагировать на прикосновения к дисплею телефона при низких температурах. Все было хорошо в помещении, но как только этот пользователь вышел на улицу, дисплей практически перестал работать.

Он пытался прокрутить на экране открытый ранее веб-сайт, но ничего не вышло. После сообщения Darus 214 жаловаться на аналогичную проблему стали и другие пользователи. Корпорация Apple отреагировала достаточно быстро, ответив, что все это легко можно исправить при помощи обновления прошивки, что и будет сделано в ближайшее время. Плюс ко всему, компания заявила, что работать с телефоном нужно при температурах от 0 до +35 градусов по Цельсию. В противном случае смартфон может работать неправильно.