Наверное каждый слышал выражение, что если ты решаешь проблему с помощью регулярных выражение, то у тебя становится две проблемы.
Недавно и сам столкнулся с проблемой производительности регулярок на Node.js, и к чему это может привести.
В один прекрасный момент все инстансы сервиса на Node.js один за одним перестали отвечать на health-check, слать логи и метрики. Пришлось остановить эти контейнеры (мы запускаем Node.js в Docker) и запустить новые.
В интернете опять кто-то не прав – во вчерашнем Node Weekly была ссылка на пост в котором автор пытается измерить и сравнить с "аналогами" производительность Stream API в Node.js. Грусть вызывает, то как автор работает со стримами и какие он выводы он пытается на основе этого сделать:
...this worked pretty well on smaller files, but once I got to the biggest file, the same error happened. Although Node.js was streaming the inputs and outputs, it still attempted to hold the whole file in memory while performing the operations
Давайте попробуем разобраться, что не так с выводами и кодом автора.
Товарищи инженеры, уже четвертый год пошел, как я взялся преподавать в Киевском политехническом институте. За это время у меня накопилось огромное количество примеров кода и материалов, примерно на 90 лекций. Должен сказать, что за весь период своей профессиональной деятельности (а это 24 года почти ежедневного написания кода), я никогда не подымал свой уровень программирования, как за последние годы, работая со студентами. Если раньше мне казалось, что написать кратко, сложно и внушительно — это верх мастерства, то теперь я осознал, что мой код должны понимать студенты после минимальных объяснений, иначе он никуда не годится. Я пришел к выводу, что способность эту можно и нужно распространить не только на обучающий код, но и на весь рабочий код. Более того, обучающий код не должен существенно отличаться от рабочего кода, потому, что мы учим будущих инженеров делать настоящие системы, а не учебные. А после многочисленных просьб, я решил записывать все лекции в виде скринкастов, которые сразу после завершения лекции отправляются на ютюб. За этот учебный год я планирую записать 100 лекций, из которых уже опубликованы 23, готовы материалы еще для 67 лекций и новых 10 лекций еще в процессе подготовки.
В этой статье речь пойдёт о написании и поддержке полезной и актуальной спецификации для REST API-проекта, которая позволит сэкономить много лишнего кода, а также серьёзно улучшить целостность, надежность и прозрачность прокта в целом.
Это миф.
Серьёзно, если вы думаете, что в вашем проекте RESTful API, вы почти наверняка ошибаетесь. Идея RESTful — в построении API, который во всём соответствовал бы архитектурным правилам и ограничениям, описанным стилем REST, однако в реальных условиях это оказывается почти невозможно.
Цель данной статьи – показать на примере зачем нужно reactive programming, как оно связано с функциональным программированием, и как с его помощью можно писать декларативный код, который легко адаптировать к новым требованиям. Кроме того, хочется сделать это максимально кратко и просто на примере приближенном к реальному.
Возьмем такую задачу:
Есть некий сервис c REST API и endpointом /people. При POST-запросе на этот endpoint'a создается новая сущность. Написать функцию которая принимает массив объектов вида { name: 'Max' } и создают набор сущностей посредством API(по-английски, это называется batch-операция).
Давайте решим эту задачу в императивном стиле:
const request = require('superagent')
function batchCreate(bodies) {
const calls = []
for (let body of bodies) {
calls.push(
request
.post('/people')
.send(body)
.then(r => r.status)
)
}
return Promise.all(calls)
}
Давайте, для сравнения, перепишем этот кусочек кода в функциональном стиле. Для простоты, под функциональным стилем мы будем понимать:
В первую очередь, данная статья расcчитана та тех читателей, которые уже знакомы с GraphQL и больше повествует о тонкостях и нюансах работы с ним. Тем не менее, я надеюсь, что она пригодится и новичкам.
GraphQL замечательный инструмент. Думаю, о его преимуществах уже знают и понимают многие. Тем не менее, есть некоторые нюансы, которые следует знать, когда вы строите свои API на основе GraphQL.
Например, GraphQL позволяет возвращать потребителю (пользователю или программе) запросившем данные только ту их часть, в которой этот потребитель заинтересован. Тем не менее, при построении сервера довольно легко совершить оплошность, которая приводит к тому, что внутри сервера (который может быть, в том числе, — распределенным) данные будут курсировать полными "пачками". В первую очередь это связано с тем, что "из коробки" сам GraphQL не предоставляет удобных инструментов для разбора входящего запроса, а те интерфейсы, которые в нем заложены недостаточно документированы.
Доброго времени суток!
Рано или поздно в организациях возникают проблемы с распространением js модулей между проектами, настало то время когда в нашей компании встал этот вопрос.
Копировать и вставлять код это путь на темную сторону, поэтому было принято решение писать не просто js код, а создавать из него npm пакеты чтобы распространять между своими проектами.
Поиск бесплатных, частных npm репозиториев завел в тупик, а использование частных репозиториев на npm требует платы (а это не наш менталитет).
Поскольку в офисе есть сервер, который работает всегда(почти), было решено развернуть локальный npm.
Читать полностью »
На прошлой работе часто были ситуации, когда есть требовательная задача, которая выполняется долго, но желательно быстро отреагировать по окончанию, что делать? Конечно, написать программу...
Первая версия просто использовала notify-send, но время показало некоторое неудобство процесса. Поскольку операции были очень требовательные к машине, то машина становилась на этот момент неюзабельной и хотелось отойти и выпить кофе. Но вернуться, когда процесс завершится. Поэтому появилась идея программы, которая чейнится в консольный пайплайн или оборачивает как sudo программу и по окончании присылает тебе нотификацию в чатик. Таким образом, ты увидишь нотификацию как на десктопе, так и на телефоне.
Всем привет!
Хотим поделиться с вами нашим новым открытым вебинаром, который был проведён в рамках курса «Разработчик JavaScript». На вебинаре Александр Коржиков, преподаватель и создатель курса, рассказал и показал на примерах внутреннее устройство платформы, ее окружение, встроенные модули и базовые концепции, которые используются при разработке приложений.
Вот и отгремел наш INTERCOM’18, c преферансом и бизнес-кейсами. Как обычно, вход на коференцию был платным: желающие могли купить билеты на TimePad по полной цене, либо… получить скидку у консультанта-рептилоида прямо на сайте. В прошлом году это работало как привычный коллбэк: вы оставляете телефон в специальной форме, Павел звонит вам через минуту и задает вопросы; чем больше правильных ответов, тем выше скидка. В этот раз мы решили поменять механику, сделав ее сложнее как технически, так и в плане вопросов. Под катом – кишки Павлика 2.0, с текущей нодой и веб-сокетами, не забудьте надеть спецодежду перед вскрытием.
