JavaScript *
Прототипно-ориентированный язык программирования
Разбор вопросов на стенде hh.ru на #HolyJS18
Мы старались сделать для вас что-то интересное и необычное. Очень надеюсь что у нас получилось. Нам не хотелось оставлять вас без ответов и объяснений почему именно так. Давайте разбираться.
Для начала хочу напомнить как проходил конкурс, было 4 тура по 15 вопросов про JS, 1 внеконкурсный тур на 15 вопросов про React и финал на 10 вопросов.
Под катом — разбор задач первых 4 туров.
Самые популярные Node.js-фреймворки 2018 года
Ещё один dsl на Kotlin или как я печатал PDF из react
Нельзя просто взять и распечатать страницу написанную на React: есть разделители страниц, поля для ввода. Кроме того, хочется один раз написать рендеринг, чтобы он генерил как ReactDom, так и обычный HTML, который можно сконвертить в PDF.
Самое сложное, что у React свой dsl, а у html свой. Как решить эту проблему? Написать ещё один!
Чуть не забыл, всё это будет написано на Kotlin, так что, на самом деле, это статья о Kotlin dsl.
Разбор конкурса-квиза по React со стенда HeadHunter на HolyJs 2018
Привет. 24–25 сентября в Москве прошла конференция фронтенд-разработчиков HolyJs https://holyjs-moscow.ru/. Мы на конференцию пришли со своим стендом, на котором проводили quiz. Был основной квиз — 4 отборочных тура и 1 финальный, на котором были разыграны Apple Watch и конструкторы лего. И отдельно мы провели квиз на знание react.
Под катом — разбор задач квиза по react. Правильные варианты будут спрятаны под спойлером, поэтому вы можете не только почитать разбор, но и проверить себя :)
Поехали!
Руководство по JavaScript, часть 8: обзор возможностей стандарта ES6
→ Часть 1: первая программа, особенности языка, стандарты
→ Часть 2: стиль кода и структура программ
→ Часть 3: переменные, типы данных, выражения, объекты
→ Часть 4: функции
→ Часть 5: массивы и циклы
→ Часть 6: исключения, точка с запятой, шаблонные литералы
→ Часть 7: строгий режим, ключевое слово this, события, модули, математические вычисления
→ Часть 8: обзор возможностей стандарта ES6
→ Часть 9: обзор возможностей стандартов ES7, ES8 и ES9
Итерации цикла: как прошла конференция HolyJS, и что насчёт следующей
В спорте есть выражение «after the game is before the game»: с того момента, когда заканчивается матч, игрокам уже пора готовиться к следующему. Цикл подготовки конференций выглядит похоже. Только на этих выходных отгремела HolyJS 2018 Moscow — а мы уже анонсируем майскую HolyJS 2019 Piter (и сейчас, на старте продаж, билеты дешевле всего).
Из-за этого мы решили совместить обе темы: расскажем вам, как прошла московская HolyJS, и по этому рассказу вы сможете понять, хочется ли вам на петербургскую. В чём были отличия этой HolyJS от предыдущих? Как прошли доклады, и что было интересного, помимо них? Наконец, за что на JS-конференции могли торжественно вручать футболку «ДЖАВА»? Все ответы — под катом.
Объясняем бэкдор в event-stream
Если вы работаете с Javascript, то скорее всего вы заметили много шума об уязвимости в npm-пакете event-stream. (На Хабре тоже опубликовали пост об этом — пер.) К сожалению, детальный анализ ситуации похоронен под более чем 600 комментариями в issue на Github, большая часть которых – флейм о состоянии npm, open-source в целом и т.д. Я подумал, что это плохо, потому что нам самом деле бэкдор исключительно умный и интересный с технической точки зрения, а также преподает нам важный урок о том, как поддерживать безопасность в приложениях на Javascript. Так что я решил написать пост с детальным объяснением, как сработала эта атака и что может сделать Javascript сообщество, чтобы лучше защититься от подобных атак в будущем.
Руководство по обработке ошибок в JavaScript
Выше мы говорили об ошибках, которые люди совершают в обычной жизни. Ошибки в программировании — это нечто иное. Сообщения об ошибках помогают нам улучшать код, они позволяют сообщать пользователям наших проектов о том, что что-то пошло не так, и, возможно, рассказывают пользователям о том, как нужно вести себя для того, чтобы ошибок больше не возникало.
Генерируем красивые SVG-плейсхолдеры на Node.js
Использование SVG-картинок в качестве плейсхолдеров — это очень неплохая идея, особенно в нашем мире, когда чуть ли не все сайты состоят из кучи картинок, которые мы пытаемся асинхронно подгружать. Чем больше картинок и чем более объемные они, тем выше вероятность получения различных проблем, начиная от того, что пользователь не совсем понимает, а что же там собственно грузится, и заканчивая известным скачком всего интерфейса после прогрузки картинок. Особенно на плохом интернете с телефона — там может и на несколько экранов все улететь. Именно в такие моменты заглушки приходят на помощь. Еще один вариант их использования – это цензура. Бывают такие моменты, когда нужно скрыть от пользователя какую-то картинку, но хотелось бы сохранить общий стиль страницы, цвета и место, которое картинка занимает.
Но в большинстве статей все рассуждают о теории, о том, что было бы неплохо инлайново вставлять все эти картинки-заглушки в страницы, а мы сегодня посмотрим на практике, как можно генерировать их на свой вкус и цвет с помощью Node.js. Мы создадим handlebars-шаблоны из SVG-картинок и будем из заполнять разными способами, начиная от простой заливки цветом или градиентом и заканчивая триангуляцией, мозаикой Вороного и использованием фильтров. Все действия будут разбираться по шагам. Полагаю эта статья будет интересна начинающим, которым интересно, как это делается, и нужен подробный разбор действий, но и опытным разработчикам возможно приглянутся некоторые идеи.
Приверженцы статической и динамической типизаций никогда не поймут друг друга. И TypeScript им не поможет
Когда мы с другом учились в школе и только мечтали стать разрабами, мы думали как сделаем вместе какую-нибудь штуковину — игру или супер-полезную программу.
Я начал учить плюсы и C#, он — JavaScript. Закончили школу, отучились в универах, отслужили в армии, устроились на работы. Нас потаскало промышленной разработкой там и тут, и когда мы оба от нее подустали, вспомнили с чего начинали.
Собравшись уже матерыми разрабами, мы решили, наконец, сделать свой проект — двумерную видеоигру. Так как друг был чистый фронт, а я фулстек, очевидной платформой для нас стал браузер. Раньше я разрабатывал фронт только на TypeScript, и мы подумали, никаких проблем, TS — всего-лишь надмножество JavaScript. Возьмем его и все пройдет гладко. Как бы не так. Когда мы начали обсуждать работу, столкнулись с невероятной бездной непонимания друг друга.
11 декабря, Москва — Alfa JS MeetUp
Начинаем в 19:00, территориально — Большая Полянка, 2/10, стр.1 (Corporate Innovations Hub)
Как обычно, вход бесплатный (но надо заранее зарегистрироваться).
Под катом — темы докладов от четырех наших спикеров.
Руководство по JavaScript, часть 7: строгий режим, ключевое слово this, события, модули, математические вычисления
→ Часть 1: первая программа, особенности языка, стандарты
→ Часть 2: стиль кода и структура программ
→ Часть 3: переменные, типы данных, выражения, объекты
→ Часть 4: функции
→ Часть 5: массивы и циклы
→ Часть 6: исключения, точка с запятой, шаблонные литералы
→ Часть 7: строгий режим, ключевое слово this, события, модули, математические вычисления
→ Часть 8: обзор возможностей стандарта ES6
→ Часть 9: обзор возможностей стандартов ES7, ES8 и ES9
Ближайшие события
Frontend DevDay: Карты, команды, два запроса
7 декабря приглашаем на Frontend DevDay. В этот раз мы смешаем формат всем привычного митапа с технической презентацией нового 2ГИС. Присоединяетесь, чтобы посмотреть на знакомую технологию под новым углом, утвердиться в значимости команды и разобраться в отношениях запроса и браузера.
Под катом детали, тезисы и всё про регистрации.
Хотеть странного: обзор предстоящей конференции DartUP в Питере
Фронтенд, алгоритмы и опоссум Фридрих. Разбираем задачи конкурса Яндекса
Задача 1
Первая задача должна была быть разминочной, на 20 минут, и мы решили сделать ее условие таким, чтобы она легко решалась с помощью регулярных выражений.
Дайджест свежих материалов из мира фронтенда за последнюю неделю №340 (19 — 25 ноября 2018)
node.js serverside — работа над ошибками. Часть 1
Эта статья ориентирована на разработчиков, имеющих представление о node.js.
Недавно готовил материал по фактам, которые полезно знать разработчикам под node.js в нашей конторе. Проекты, над которыми мы работаем — это API сервисы, использующие модуль node.js express в качестве веб-сервера. Материал основан на реальных случаях, в которых код работал неправильно или логика в нём была тщательно скрыта, или он провоцировал ошибки при расширении. На основе этого материала был проведён семинар по повышению квалификации сотрудников.
Вот, решил поделиться. Пока только первая часть, это около 30%. Если будет интересно, последует продолжение!
Я старался предоставить возможность быстрого ознакомления, поэтому примеры, рассуждения и комментарии спрятал в спойлерах. Если утверждения очевидны, «воду» можно пропустить. Хотя наши «грабли» в спойлерах тоже могут быть интересны.
Один коллега при проведении семинара задал мне вопрос, зачем об этом говорить, если всё и так есть в той или иной документации. Мой ответ был следующий. Несмотря на то, что посыл верен, всё действительно есть в документации, мы по-прежнему делаем досадные ошибки, связанные с непониманием или незнанием базовых вещей.
Приступим!
Виртуальная машина node.js
Однопоточность
В отличие от javavm, nodejs-vm является однопоточной**.
Источник
Mrr: тотальное FRP для Реакта
При слове «реактивность» обычно вспоминают Rx.js, как эталонный образец FRP. Однако серия последних статей на эту тему на Хабре([1], [2], [3]) показала громоздкость решений на Rx, которые на несложных примерах проигрывали в ясности и простоте почти любому другому подходу. Rx велик и могуч, и прекрасно подходит для решения проблем, в которых абстракция потока напрашивается сама собой (на практике это преимущественно координация асинхронных задач). Но стали бы вы писать, к примеру, простую синхронную валидацию формы на Rx? Сэкономил бы он ваше время, по сравнению с обычными императивными подходами?
mrr — это попытка доказать, что ФРП может быть удобным и эффективным решением не только в специфических «потоковых» проблемах, но и в самых обычных рутинных задачах фронтенда.
«JS становится более зрелым»: интервью с программным комитетом HolyJS 2018 Moscow
А в преддверии конференции мы задали вопросы программному комитету HolyJS: людям, от которых зависит, какие доклады можно будет увидеть. Как они сами видят правильную программу «конференции для JS-разработчиков»? Что в неё может попасть, а что нет? Как борются со сложностями?
В разговоре поучаствовали:
Евгений bunopus Кот
Дмитрий DmitryMakhnev Махнёв
Вадим bmsdave Горбачёв
Алексей zolotyh Золотых
Андрей real_ales Дмитриев
Помимо них над программой также работали Екатерина cakeinpanic Павленко и Михаил v1r Полубояринов.