Доброго времени суток.
Разбор полетов провожу на Reactjs (сторона клиента) и Nodejs (сторона сервера).
Недавно в моем маленьком проекте встал вопрос, как легко и просто можно обмениваться изображениями по типу клиент — сервер.
Сегодня мы научимся отправлять бинарные данные (конкретно изображения ) со стороны клиента и обрабатывать их на сервере. Добро пожаловать в под кат.
Читать полностью »
Рабочий понедельник начался со следующего диалога:
Руководитель (P): У тебя в команде не понятно, кто чем занимается.
Я (Я): Это да, у нас нет инструмента, который бы отображал общую картину работы над задачами. В гитлабе есть канбан-доски, но они только в контексте проектов и групп. Общая канбан-доска решила бы проблему.
Р: Тогда сделай доску.
Я: К утру будет готово.
В жизни начинающего тимлида рано или поздно настаёт момент, когда он понимает, что его команде нужна канбан-доска. Она снимает беспокойство по поводу контроля процесса разработки и даёт уверенность в завтрашнем дне. Обычно эта проблема решается нижайшей просьбой к завхозу купить магнитную доску, набор разноцветных стикеров и пару-тройку маркеров для доски. Ну или использованием сервисов вроде Jira. Но в нашей команде один разработчик на удалёнке, а гитлаб в закрытом контуре (недоступен из интернетов по соображениям информационной безопасности), поэтому выбирать пришлось наиболее простое из двух возможных решений:
а) создание механической руки и контроллера к ней, который позволит удалённо переклеивать стикеры на доске, при этом, чтобы не усложнять решение, писать на стикерах нам придётся за нашего недосягаемого коллегу, что несправедливо;
б) реализация программной канбан-доски, которая собирала бы все задачи с нашего гитлаба.
Конечно, душа лежала к ламповой физической доске. Я даже начал размышлять об использовании DualShock 4 в качестве контроллера механической руки, но я сам себе обозначил дедлайн утром следующего дня, поэтому пришлось обойтись бездушным программным решением.
17 ноября 2018 года. Нас четверо. Настроение у всех приподнятое — прошли первый этап ШРИ, Школы разработки интферфейсов. Он состоял из лекций и домашних заданий: осваивали разные фронтендерские и околофротендерские технологии, инструменты, Скрам. Знали, что всё это придётся применять в боевом проекте на втором этапе. Но одно дело знать, и другое — действительно реализовать этот проект за ближайшие 5 недель.
Недавно мне передали на поддержку проект на express.js. При изучении кода проекта я обнаружил немного запутанную работу с аутентификацией/авторизацией которая базировалась, как и 99,999% случаев, на библиотеке passport.js. Этот код работал и следуя принципу «работет — не трогай» я оставил его как есть. Когда через пару дней мне дали задание добавить еще две стратегии авторизации. И тогда я начал вспоминать что уже делал аналогичную работу, и это занимало несколько строк кода. Полистав документацию на сайте passport.js, я почти не сдвинулся с места в понимании того, что и как нужно делать, т.к. там рассматриваись случаи когда испольуется ровно одна стратегия, для котрой, для каждой в отдельности, и даются примеры. Но как соединить несколько стратегий, зачем и когда нужно использовать метод logIn() (что то же самое, что login()) по-прежнему не прояснялось. Поэтому, чтобы разобраться сейчас и не повторять тот же поиск еще и еще раз, — я составил для себя эти заметки.
Вот и отгремел наш INTERCOM’18, c преферансом и бизнес-кейсами. Как обычно, вход на коференцию был платным: желающие могли купить билеты на TimePad по полной цене, либо… получить скидку у консультанта-рептилоида прямо на сайте. В прошлом году это работало как привычный коллбэк: вы оставляете телефон в специальной форме, Павел звонит вам через минуту и задает вопросы; чем больше правильных ответов, тем выше скидка. В этот раз мы решили поменять механику, сделав ее сложнее как технически, так и в плане вопросов. Под катом – кишки Павлика 2.0, с текущей нодой и веб-сокетами, не забудьте надеть спецодежду перед вскрытием.
В этой статье автор анализирует количество времени, которое тратится на написание книг или программного кода, и приходит к интересной закономерности. Ее можно применять для планирования сроков работы над проектами.
Закон Хофштадтера: Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.
— Дуглас Хофштадтер, Гёдель, Эшер, Бах
У написания прозы и кода есть много общего. Но самое заметное сходство, вероятно, заключается в том, что ни писатели, ни программисты не могут закончить свою работу вовремя. Писатели славятся отъявленной привычкой срывать сроки. Программисты заслужили репутацию людей, чьи результаты всегда серьезно отличаются от первоначальных расчетов. Возникает вопрос: почему?
Сегодня у меня появилась идея, как можно на него ответить. И мои находки меня поразили.
Обе свои книги, Привет, стартап и Terraform: запускаем и работаем, я написал в среде для создания книг Atlas, которая предусматривает управление всем контентом с помощью Git. Это означает, что каждая строчка текста, каждая правка и каждое изменение были зафиксированы в коммит-логе Git.
Проверим, сколько же усилий было затрачено на написание двух книг.
Привет, стартап
Начнем с моей первой книги Привет, стартап. В ней 602 страницы и примерно 190 тыс. слов. Я запустил cloc в git-репозитории Hello, Startup и получил следующие результатыЧитать полностью »
Всем привет!
В июле 2018 года наш преподаватель курса «Разработчик JavaScript» Юрий Дворжецкий провел открытый вебинар на тему «Cоздание приложения на Webpack+React+Express», правда, в рамках второго курса, где он выступает как преподавателя одного из модулей, посвящённого JavaScript. В этом материале вы сможете ознакомиться с видеозаписью и кратким пересказом прошедшего мастер-класса.
Работа на открытом уроке проходила по следующему плану:
Итак, поехали!
Если вы занимались разработкой для платформы node.js, то вы, наверняка, слышали об express.js. Это — один из самых популярных легковесных фреймворков, используемых при создании веб-приложений для node.
Автор материала, перевод которого мы сегодня публикуем, предлагает изучить особенности внутреннего устройства фреймворка express через анализ его исходного кода и рассмотрение примера его использования. Он полагает, что изучение механизмов, лежащих в основе популярных опенсорсных библиотек, способствует более глубокому их пониманию, снимает с них завесу «таинственности» и помогает создавать более качественные приложения на их основе.
Читать полностью »
При работе с базами данных существует проблема которую принято называть «SELECT N + 1» — это когда приложение вместо одного запроса к базе данных, который выбирает все необходимые данные из нескольких связанных таблиц, коллекций, — делает дополнительный подзапрос для каждой строки результата первого запроса, чтобы получить связанные данные. Например, сначала мы получаем список студентов университета, в котором его специальность обозначена идентификатором, а потом для каждого из студентов делаем дополнительный подзапрос в таблицу или коллекцию специальностей, чтобы по идентификатору специальности получить наименование специальности. Поскольку каждый из подзапросов может потребовать еще один подзапрос, и еще один подзапрос — колчество запросов к базе данных начинает расти в геометрической прогрессии.
При работе с graphql очень просто породить проблему «SELECT N + 1», если в resolver-функции сделать подзапрос к связанной таблице. Первое что приходит в голову — сделать запрос сразу с учетом всех связанных данных, но это, согласитесь, нерационально, если связанные данные не запрашиваются клиентом.
Один из вариантов решения проблемы «SELECT N + 1» для graphql будет рассмотрен в этом сообщении.
Читать полностью »
