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

^{Рыжик помогает мне ревьюить код. А когда ему что-то не нравится — тоже настоящий Терминатор}

«Code review Терминатор», — однажды назвал меня коллега после особо продуктивного ревью. С одной стороны, это тешило ЧСВ и было приятно. С другой — коллега действительно научился чему-то новому, и это позволило писать ему более качественный код. Так что win-win.

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

Открытый стандарт JWT официально появился в 2015 (rfc7519) обещая интересные особенности и широкие перспективы. Правильное хранение Access токена является жизненно важным вопросов при построении системы авторизации и аутентификации в современном Web, где становятся все популярнее сайты, построенные по технологии SPA.

Неправильное хранение токенов ведет к их краже и переиспользованию злоумышленниками.

Каждый раз перед собесом я говорю себе: "Спокойно, не нужно ничего выдумывать, доучивать и врать, твоих знаний и опыта достаточно для того, что бы работать у них. Ты усилишь любую команду, тебе есть что предложить, а пробелы в твоих знаниях — приемлемы. Если бы они знали о твоих навыках всё, что знаешь ты, они бы точно тебя взяли". Но когда начинается собеседование, я всегда перестаю в это верить. Все два часа интервью я хожу как по минному полю, что бы не дай бог не спалиться, что я чего-то не знаю.

Андрей Ситник из Злых марсиан — одно из самых известных российских имён во фронтенде: у его проектов PostCSS и Автопрефиксер счёт GitHub-звёзд идёт на десятки тысяч. Но поскольку Андрей живёт в Нью-Йорке, а путешествует по всей планете, застать в России его можно нечасто.

В мае он будет в Петербурге на конференции HolyJS, и по этому поводу его подробно расспросили участники программного комитета HolyJS Дмитрий DmitryMakhnev Махнёв и Максим Юзва. Почему Андрей считает, что фронтенд стагнирует, а код наших проектов излишне разбухший? В чём различия IT-сообществ разных стран? Как учить английский и почему это менее важно, чем кажется? Куда пропал проект Logux, презентованный на HolyJS ещё в 2016-м?

(Иллюстрация)

Senior web developer’ы Антон и Алексей продолжают рассказ о непростой борьбе с Nuxt. В предыдущем раунде битвы с этим фреймворком они показали, как запустить проект на Nuxt так, чтобы все были счастливы. В новой статье поговорим о реальном применении фреймворка.

Мы начали переписывать проект с огромным техническим долгом. Месячная аудитория составляла 6-7 млн. уникальных посетителей, но существующая платформа доставляла слишком много проблем. Поэтому было решено отправить ее на пенсию. Само собой, производительность была нашим наибольшим опасением, но также не хотелось просесть по SEO.

После пары раундов обсуждения решили не полагаться на традиционный подход с только серверным рендерингом — но и не загонять себя в ловушку клиентского рендеринга. Как итог мы начали строить решение на базе Nuxt.js.

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


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

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

Для начала, кратко перечислю из чего собирается картинка в нашей игре:

Руководитель сервиса для регистрации бизнеса 1С-Старт Александр Раптовский о том, как отменить судебное решение о блокировке статьи на Хабре, инициированное Роскомнадзором.


Кадр из фильма «С меня хватит!» (Falling Down), 1992

tl;dr; В рекрутинге больше бардака, чем вы думаете. Расскажу четыре истории, где отличным инженерам отказали по причинам, абсолютно не связанным с их профессиональными знаниями или соответствием корпоративной культуре.

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

Страшилка № 1: кандидата отвергли из-за фреймворка

На позицию фронтенд-разработчика в агентстве я передал инженера, который участвовал в разработке ECMAScript и сделал значительный вклад в некоторые другие проекты open source. Мне понадобилось несколько недель, чтобы найти этого человека, и несколько часов для его правильной оценки, включая видеоинтервью (мы любим такое делать на coderfit.com). Его кандидатуру отверг программист из агентства после 10-минутного просмотра примеров кода. С ним даже не пообщались лично, а просто прислали «консерву» — шаблонное письмо по электронной почте:

«[…]Хотя ваше резюме и сопроводительное письмо очень конкурентоспособны, наши специалисты по найму рассмотрели вашу заявку и не выбрали её для дальнейшего рассмотрения. […]»

→ Оригинал статьи

Представим что мы разрабатываем функцию isPi:

function isPi(x) {
  return x === 3.14
}

И тут кто-то говорит: "Мы не хотим знать откуда приходят данные (БД, сеть и т.д.), по-этому давайте обернем наш код в Promise":

Расшифровка доклада Ильи Климова на конференции JavaScript fwdays.

Мы с вами попробуем отследить некоторые тренды в развитии JS, как сообщества, как движения, в 2017-ом году. Я очень постараюсь избежать оценочных суждений. Хотя кого я обманываю, все равно не получится. И где-то через год вы сможете с радостью открыть эту презентацию на YouTube, и понять, насколько я был не прав.

Поэтому давайте перенесёмся в 2015 год. Посмотрим, как развивался JS.

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

В этом исследовании мы показываем, что даже если новый HTTP/2 протокол значительно улучшает скорость загрузки страницы, время для полного отказа от фронт-энд оптимизаций ещё не наступило. Сегодня мы сосредоточимся на спрайт-сетах.

HTTP/2 стал доступен в 2015, как альтернатива к замене многоуважаемого HTTP/1.1, используемого с 1997. Многие авторы предсказывают устаревание или, даже, контрпродуктивность фронт-энд оптимизаций. В список классических оптимизаций входят спрайты: группировка множества маленьких изображений (спрайтов) в одно большое (спрайт-сет).

Несмотря на быстрое внедрение поддержки и в браузерах и в серверах (вики, w3techs), мы не смогли найти опубликованные сравнительные замеры для подтверждения утверждения (прим. того, что спрайты больше не нужны). Как веб-архитекторы, тогда, мы естественно, интересовались, следует ли нам отказаться от подхода спрайтов или нет. Как гласит известная цитата Уильяма Эдвардса Деминга: “In God we trust, all others bring data”. Поэтому мы сделали свой собственный бенчмарк.

Первая часть этой статьи описывает основные отличия между HTTP/1.x и 2 и почему они могут способствовать устареванию спрайтов. Во второй части мы покажем сравнительные результаты бенчмарка.

Сегодня завершился финал Яндекс.Алгоритма — ежегодного чемпионата по спортивному программированию, который организует Яндекс. В 2015 году состязание проходило полностью в онлайне — на платформе Яндекс.Контест. Заявки на участие подали программисты из 73 стран. Больше всего участников — из России, Украины, Беларуси, Казахстана, Индии, США, Японии и Китая, но вообще география чемпионата крайне обширна — Бразилия, Индонезия, Перу, Доминиканская Республика, Мозамбик, Сенегал, Каймановы острова. 8,9% зарегистрировавшихся — девушки. Примерно половина всех участников — студенты. Всего мы получили заявки от 3722 человек, из которых до финала дошли 28.

А победителем Яндекс.Алгоритма-2015 стал Геннадий Короткевич. Он по привычке показал лучший результат, решив в финальном раунде пять из шести задач и получив при этом 80 минут штрафного времени. Геннадий занимал первое место в чемпионате Яндекса и в 2013, и в 2014 годах.



Второе место занял Пётр Митричев, а третье — Евгений Капун. Они решили по четыре задачи, при этом Пётр набрал 31 штрафную минуту, а Евгений — 79 минут. Результаты всех финалистов можно посмотреть на сайте Яндекс.Алгоритма.

Задачи для Яндекс.Алгоритма составляет международная команда, в которую входят как сотрудники Яндекса, так и приглашённые эксперты — в том числе победители и финалисты состязаний ACM ICPC и Topcoder Open. И мы по традиции подготовили для вас разборы всех заданий. Решить все из них никому не удалось. Больше всего участников справились с задачей B, а вот задания A и D решило всего по одному человеку.

В стандартном блокноте для всех версий Windows, начиная примерно с 2001 года, имеется ошибка, про которую практически все знают, но никто не собирается её исправлять. И это понятно, ведь это не критическая уязвимость, ничьей безопасности она не угрожает. Да и пользуется ли кто блокнотом вообще?

Тем не менее, сам факт довольно странный, поэтому мы попробуем найти эту ошибку в коде 64-битного и 32-битного notepad.exe от windows 7, исправим её, и выясним наконец, почему же она возникла. Заключается ошибка в следующем:

Если в блокноте включена опция «перенос по словам» (word wrap), то после сохранения файла начинаются всевозможные глюки: строки начинают разъезжаться, курсор улетает, текст вводится не туда, куда вы ожидаете, и так далее.

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

#import <Foundation/Foundation.h>

int main()
  parts := ['hello', 'world']
  greeting := ''
  for String part in parts
    if part == parts[0]
      Locale myLocale = Locale.currentLocale
      greeting << part.capitalizedString
    else
      greeting << ' '
      greeting << part

  Log('%@', greeting + '!')
  return 0

На днях из любопытства решил посмотреть, на какой стадии находится проект Eero — диалект Objective-C с альтернативным легким синтаксисом. Оказалось, что проделан уже большой фронт работ и Eero представляет из себя очень интересную разработку.

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

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

Хакер действовал следующим образом: желая взломать аккаунт с именем, скажем, bigbird, он регистрировал аккаунт с именем ᴮᴵᴳᴮᴵᴿᴰ (в Пайтоне эта строчка выглядит как u’\u1d2e\u1d35\u1d33\u1d2e\u1d35\u1d3f\u1d30′). После запроса ссылки на сброс пароля задавался новый пароль, который подходил к аккаунту bigbird.

Один в поле – ИТ-директор!

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

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

Однажды на пикнике я заметил математиков, толпящихся возле игры, интереса к которой я ожидал меньше всего: крестики-нолики.

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



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