Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.
Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.
В мире JavaScript существуют две фракции. Первая из них — технари, которые все проблемы стараются решать «технично». Вообще технари ребята суровые, я бы даже сказал строгие, и потому любят такую же суровую и строгую типизацию, и везде суют TypeScript, Dependency Injection и другой IoC.
Вторая же — маги. Кто-то, считает их шарлатанами, и уж никто точно не понимает как работает их код. Но он работает. На строгую типизацию у них табу, а про(от) DI у них есть простая отговорка:
«Зачем мне уродовать свой код, смешивая ужа с ежом, если это нужно исключительно для тестов?».
И ведь на самом деле — добавлять в проект DI исключительно чтобы мокать зависимости в тестах — идея не самая умная. Особенно если DI и на самом деле редкий зверь за пределами экосистемы Angular.
Есть только одно но — если технари от своей профдеформации не страдают, то маги… ну как сказать…
В общем пару месяцев назад один добрый человек создал мне в proxyquire-webpack-alias issue. Суть была проста — «не работает». Мне потребовался день чтобы изменить ЧТО не работает, на ГДЕ.
Заметка рассчитана на новичков и пользователей среднего уровня, по этому всех гуру сразу прошу не тратить свое драгоценное время и пропустить данный пост.
В этой небольшой заметке я описываю как настроить REPL(read-eval-print loop) или «консоль» Node JS и при этом не потерять приятную плюшку — сохранение истории. Последние версии Node автоматически сохраняют историю между сеансами в REPL в файле ~/.node_repl_history Но есть одна загвоздка, если вы хотите настроить REPL «под себя», тогда история сеансов автоматически сохраняться прекращает.
Раньше для сохранения истории использовался отдельный пакет rlwrap(ReadLine Wrap).
Который позволяет например разукрашивать promt консоли, но при использовании rlwrap перестает работать автозавершение(autocomple) команд по клавише Tab. По этому его использовать не буду.
Кроме того в контекст REPL сразу загрузим часто используемые модули, такие как axios и lodash.
Иногда для модулей lodash или underscore используют символ подчёркивание _
В REPL этого делать не следует, так как этот символ имеет специальное значение — результат предыдущей операции.
По умолчанию если ввести
let a=1;
или любой другой код в результате которого ничего не возвращается или правильнее сказать возвращатся undefined, в консоли выведется это самое undefined, что как по мне раздражает.
За это поведение отвечает параметр
ignoreUndefined: true
Другой параметр: replMode: Repl.REPL_MODE_STRICT,.Это эквивалент 'use strict';. То есть теперь, например, не получится присвоить переменной значение без ее объявления.
Иначе говоря
b=2;
выдаст ошибку и нужно писать
let b=2;
Все параметры REPL описаны на сайте Node
Остальной код интуитивной понятен.
Читать полностью »
Фабрика виджетов — способ организации клиентского кода, который отлично вписывается в архитектуру multi-page application (MPA).
В статье будет рассмотрено архитектурное решение, которое позволит оптимизировать загрузку скриптов, разделить код на виджеты и упростит передачу данных на клиент со страницы (при серверном рендеринге).
Виджетами будут называться компоненты (или контейнеры компонентов), точкой инициализации которых будет DOM. И в которые можно будет передать данные из шаблона.
А сейчас обо всем последовательно.
Читать полностью »
Привет!
Вот и подоспело продолжение моего рассказа о написании браузерного 3D-футбола. Прошу прощения за длительный перерыв, виною тому работа, производство борщей и прочего съестного для любимого мужа, тягости ремонта и всякое другое. Но статья сама себя не напишет и не прочитает. Поэтому всех интересующихся и ещё не забывших про первую часть — милости прошу под кат.
На всякий случай ссылка на первую часть — Как я браузерный 3D-футбол писала. Часть 1
Читать полностью »
Английскую версию данного поста я написал еще в мае и опубликовал ее в багтрекере проекта ReactJS.NET. Изначально я не планировал переводить данный пост на русский язык, но в понедельник я увидел программу 13-й встречи MskDotNet Community, и решил, что такой перевод был бы полезен сообществу
Для лучшего понимания материала изложенного в посте, я немного расскажу о ReactJS.NET и JavaScript Engine Switcher. ReactJS.NET – это .NET-библиотека, которая производит компиляцию JSX-кода в JS-код. Данная библиотека не является .NET-портом библиотеки React (по аналогии c Less.js и dotless). При создании ReactJS.NET использован совершенно другой подход: JS-код библиотеки React запускается из .NET с помощью JS-движка. Роль этого JS-движка, как раз и выполняет библиотека JavaScript Engine Switcher. JavaScript Engine Switcher определяет унифицированный интерфейс доступа к базовым возможностям популярных JS-движков (MSIE JavaScript Engine for .Net, Microsoft ClearScript.V8, Jurassic, Jint и ChakraCore) и позволяет быстро переключить вашу библиотеку или приложение на использование другого JS-движка (при условии, что ваш JS-код совместим со стандартом ECMAScript 5).
Несколько лет назад, когда я начал работать в Node.js, меня приводило в ужас то, что сейчас известно как «ад коллбэков». Но тогда из этого ада выбраться было не так уж и просто. Однако, в наши дни Node.js включает в себя самые свежие, самые интересные возможности JavaScript. В частности, Node, начиная с 4-й версии, поддерживает промисы. Они позволяют уйти от сложных конструкций, состоящих из коллбэков.
Использование промисов вместо коллбэков ведёт к написанию более лаконичного кода, который легче читать. Однако, тому, кто с ними не знаком, они могут показаться не особенно понятными. В этом материале я хочу показать базовые шаблоны работы с промисами и поделиться рассказом о проблемах, которые может вызвать их неумелое применение.
Обратите внимание на то, что здесь я буду использовать стрелочные функции. Если вы с ними не знакомы, стоит сказать, что устроены они несложно, но в этом случае советую прочесть материал об их особенностях.
Читать полностью »
Раз в год мы устраиваем в Москве конференцию INTERCOM, чтобы пообщаться с коллегами и обсудить, что нового в области автоматики коммуникаций. В этом году мы помогали заменять роботами колл-центры, нанимать сотрудников, связывать докторов с пациентами, вызывать такси, доставлять посылки и много чего еще, о технической стороне вопросов часто рассказывали на Хабре. А на конференции мы это все обсудим с коллегами из Яндекс, Atlassian, Битрикс24 и других компаний. Нейросети, погоня по мессенджерам, гадание на кофейных бизнес-процессах, карманные сети сотовой связи и много всего интересного, о чем я немного расскажу под катом. Еще под катом у меня телефонный робот-ящер, у которого можно нечестным образом получить бесплатный билет и другие фишки для Хабрапользователей. Так что если вопрос «кто виноват в том, что мне позвонил робот» вас интересует — присоединяйтесь!
Можно не знать о модных технологиях, не думать о доступности сайтов, забивать на развитие экосистемы, но, кажется, через год-другой с таким подходом можно стать таксистом-программистом. Нам эта история не близка, поэтому на конференции FrontFest, кроме понятных всем потоков VYORSTKA и JS, мы заложили в программу поток MIX. Как ясно из названия, он для докладов, которые не вписываются в первые два потока — это выступления о кодстайле, производительности фронтенда, форматах данных, экосистеме JavaScript и развитии фронтендера как разработчика.
Читать полностью »
Давайте будем честны, и смиримся с рядом фактов:
1. У нас есть определенный рынок в России и только 5% задач из этого рынка нуждаются в высокой производительности, вся основная нагрузка всегда будет лежать на базе данных.
2. Мы живем в 2017 году и иметь 4-8гб оперативной памяти считается разумным минимумом для пользователя, если человек использует Nokia 3310, то глупо жаловаться на неработоспособность Yandex карт.
3. 90 — 95% задач на нашем рынке, это примитивные приложения по типу:
4. Конечная цель бизнеса — это деньги, помните, что мы пишем код не для себя, а для решения проблем бизнеса.
Читать полностью »