Эта статья основана на моём выступлении на конференции ITSubbotnik, прошедшем 2 ноября 2019 года в Москве.

Вообще я бэкенд программист, но меня заинтересовала эта технология, она позволяет использовать мои знания бэкенда на фронте.

Проблема

Начнём с проблемы, которая решается этой (относительно новой) технологией. Проблема эта — быстро исполнять код в браузере. Быстро — это значит, «быстрее чем JavaScript», в идеале настолько быстро, насколько позволяет имеющийся у нас процессор.

До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

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

Этой весной прошла HolyJS 2019 Piter — большая конференция для JavaScript-разработчиков. Вместе с программным комитетом конференции мы составили для вас список лучших докладов, посвящённых следующим темам:

• Алгоритмы на графах;
• Протокол Chrome DevTools и Puppeteer;
• Статические типизаторы;
• CI/CD;
• Миграции: с Backbone на Polymer, с Polymer на Angular.js;
• Большие данные на Node.js в serverless-архитектуре;
• SEO с точки зрения разработчиков Google Search;
• GraphQL;
• Продвижение опенсорс-проектов.

Под катом всё это структурировано следующим образом:

• Видеоролик на YouTube;
• Страница доклада с полным описанием на сайте конференции;
• Ссылка на слайды или специальный сайт доклада (если они есть).

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

Всем привет! Меня зовут Дмитрий Новиков, я javascript-разработчик в Альфа-Банке, и сегодня я расскажу вам про наш опыт выведения Action type при помощи Typescript, с каким проблемами мы столкнулись и как их решили.

Это расшифровка моего доклада на Alfa JavaScript MeetUp. Код из слайдов презентации можно посмотреть здесь, а запись трансляции митапа — здесь.

Наши фронтовые приложения работают на связке React+Redux. Redux data flow упрощенно выглядит так:

С выходом macOS 10.14.5, Apple добавила обязательную процедуру нотаризации (Notarization process) приложений перед их распространением. Что это и какие сложности возникли с этим обновлением при разработке на Electron.js я и хотел бы рассказать.

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



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

UPD. CardInfo больше не работает. Используйте BinKing.

Гайд по использованию: habr.com/ru/post/527796
Сайт сервиса: binkng.io

Тут и демо, и документация: cardinfo.online — это API. Вы ему 6 первых цифр банковской карты, оно вам ссылку на логотип банка, его фирменные цвета, бренд (Visa, MasterCard, и т.д.) и прочее в формате JSON. CardInfo нужен тем, кто создаёт форму для приёма банковских карт у себя на сайте, чтобы улучшить UX (удобство, впечатления, чувство безопасности) пользователей. Принимать платежи прямо у себя на сайте позволяет cloudpayments.ru в России и странах СНГ, и stripe.com во всём остально мире.

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

Однако, крупные компании уже давно сделали свои формы такими, а мелкие всё ещё нет. Почему? Создание такого решения для своей формы займёт около 7 дней работы программиста и ещё 7 работы дизайнера (логотипы выкачивать, обрабатывать, перерисовывать). Крупные компании могут себе позволить потратиться на создание такой формы. Мелкие компании считают ценность такой формы не достаточной, чтобы платить за неё столько.

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

Всем привет!

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

Однажды я нашел уязвимость на серверах небезызвестной компании Facebook. Ребята забыли обновить ImageMagick (библиотеку по обработке изображений) и поплатились за это:) Этим примером я хотел показать, что все мы люди, и все можем допускать ошибки, неважно, в каких компаниях и на каких должностях мы работаем. Проблема только в том, что эти ошибки могут приводить к разного рода рискам.
Чем сложнее у вас приложение/сайт/инструмент, тем больше вероятность того, что что-то может пойти не так.
Проверять на уязвимости нужно. Глупо не делать этого совсем.

Здравствуйте! Представляю вам любительский перевод руководства реализации своего языка программирования на JavaScript — PL Tutorial.

От переводчика

Мы создадим свой язык программирования — λзык (в оригинале — λanguage). В процессе создания мы будем использовать достаточно много интересных техник, таких как рекурсивный спуск, стиль передачи управления, базовые техники оптимизации. Будет создано две версии интерпретатора — обычный и CPS-интерпретатор, транс-компилятор в JavaScript.

Автор оригинала — Mihai Bazon, автор известной библиотеки UglifyJS (инструмент для минимизации и форматирования JS-кода).

Веб-краулер (или веб-паук) — это важная составная часть поисковых систем для обхода веб-страниц с целью занесения информации о них в базы данных, в основном, для их дальнейшей индексации. Такая штука есть у поисковиков (Google, Yandex, Bing), а также у SEO-продуктов (SEMrush, MOZ, ahrefs) и не только. И штука эта — довольно интересная: как в плане потенциала и вариантов использования, так и для технической реализации.



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

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

TL;DR: базовая логика redux помещается в 7 строк JS кода.

О redux вкратце (вольный перевод заголовка на гитхабе):

Redux — библиотека управления состоянием для приложений, написанных на JavaScript.

Она помогает писать приложения, которые ведут себя стабильно/предсказуемо, работают на разных окружениях (клиент/сервер/нативный код) и легко тестируемы.

Я склонировал репозиторий redux, открыл в редакторе папку с исходниками (игнорируя docs, examples и прочее) и взялся за ножницы клавишу Delete:

• Удалил все комментарии из кода
  Каждый метод библиотеки задокументирован с помощью JSDoc весьма подробно
  
• Убрал валидацию и логирование ошибок
  В каждом методе жёстко контролируются входные параметры с выведением очень приятных глазу подробных комментариев в консоль
  
• Убрал методы bindActionCreators, subscribe, replaceReducer и observable.
  
  … потому что мог. Ну или потому что поленился писать для них примеры. Но без корнер-кейсов они ещё менее интересны, чем то, что ждёт вас впереди.
  

А теперь давайте разберём то, что осталось

История реальная, я все видел своими глазами.

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

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

От переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.

Привет.

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

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

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

Привет всем!

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

Валентин Васильев (Machinio.com)

Что же такое Browser Fingerprint? Или идентификация браузеров. Очень простая формулировка — это присвоение идентификатора браузеру. Формулировка простая, но идея очень сложная и интересная. Для чего она используется? Для чего мы хотим присвоить браузеру идентификатор?

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

На днях я буду делать внутренний доклад, на котором расскажу нашим разработчикам про неприятные ошибки, которые могут возникнуть при написании юнит тестов. Самые неприятные с моей точки зрения ошибки — когда тесты проходят, но при этом делают это настолько некорректно, что лучше бы не проходили. И я решил поделиться примерами таких ошибок со всеми. Наверняка ещё что-нибудь подскажете из этой области. Примеры написаны для Node.JS и Mocha, но в целом эти ошибки справедливы и для любой другой экосистемы.

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

Добрый день, дорогие друзья.

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

Итак, начнем.

Всем привет! Меня зовут Роман Дворнов, я Lead Engineer в команде Frontend Architecture в Авито. Мы занимаемся созданием и развитием технической платформы фронтенда, чтобы другие команды могли быстрее создавать интерфейсы и продукты. Мы с коллегами запланировали серию онлайнов, в которых будем обсуждать актуальные вопросы разработки клиентской части.

11 декабря на нашем ютуб-канале пройдёт первый прямой эфир. Обсудим инфраструктуру фронтенда. В дискуссии будут участвовать эксперты из Яндекса, Tinkoff, Mail.Ru и Авито. Под катом — примерные вопросы, которые планируем обсуждать (дополняйте список), и ссылка на предстоящую трансляцию. Добавляйте пост в закладки: после встречи обновим его и выложим видео.