Например о реализации update-interfaces.js (Автоматический скрипт генерации). О том что его нужно явно вызвать с помощью npm run update Так же не сказано, что необходимо иметь токен, дать ссылки или вкратце рассказать о его получении. Больше примеров использования - CRUD, нюансы(если есть). Думаю можно еще чем разбавить.
Так в чем вызовы то были? И оригинальное решение... А какие еще средства автоматизации можно рассмотреть для работы с гугл формами - только Google Apps Script! Хотя безусловно есть негибкие велосипеды на гитхабе. Статья больше подходит под формат гайда
Огромная работа была проделана и думаю много еще предстоит. Как раз хотел изучить деплой nestjs приложений и рассматривал разные варианты работы с процессами, эту очень крутую и доходчивую статью взял в закладки. Почему был выбран именно ztv.su (не смог найти доводы в статье на dev.to)?Полагаю просто по цене?
Так же заметил опечатку в 12 пункте
Так как в режиме "Docker Compose" мы раздаем статику через Nginx,, то наМ не нужно собирать бэкенд...
Лично мне интересно бы узнать про работу Sucrose под капотом. Но боюсь это может не подойти под ваши идеи статьи, но всегда ведь можно написать еще одну. Вообщем я бы с удовольствием почитал!
Стабильная версия вышла в марте, смело уже иметь проду на ней(Переучивались с какого-то стека или давно за Elisya следите?). Bun+Elysia это шустро и круто, но мне не хватает CLI (хотя я только что нашел что-то подобное). В целом думаю, что Bun может потягаться с мастодонтами, и вижу за ним будущее JS Backend разработки.
Node — H3 — Nuxt Node — Express/Fastify — Nest Node — Next Bun — Hono — ? Не знаком с фреймворками построенными на Hono. А как самостоятельный фреймворк для проды выглядит не очень... Пока нет хедлайнера, Hono вряд‑ли получит нужную поддержку и охваты. Кстати, напомнило Ruby с их философией, загуглил — тоже Япония! Как туториал статья выполняет свои цели. На удивление, действительно статей о Hono на хабре раз-два и обчелся. Спасибо автору за просвещение и популяризацию!
Считаю, что это зависит от целей. Вижу 2 направления: pet-проекты для трудоустройства: мелкие проекты приближенные к реальному(а в идеале реальные), задача которых решать бизнес-проблемы. Тогда их будет легко описать в резюме через STAR методику.
pet-проекты для экспертизы в стеке технологий,в архитектуре,полном сопровождении ПО: большие проекты(не обязательно монолиты), которые задействует как можно больше технологий, нюансов, моментов - в таком случае чем тяжелее, тем лучше. По собственному опыту знаю, что самые сложные и "экспертные" моменты возникают там где их не ждешь, и чем сложнее проект, чем индивидуальнее, тем больше этих моментов будет.
Есть еще направления(#для своих нужд, #для набивания руки), кто хочет поделиться своими целями и видением, пожалуйста, самому интересна данная тема.
Дополню комментарий выше. Запуск нескольких процессов в одном контейнере противоречит концепции докера. Докер сделан так, чтобы запускать один процесс (не считая дочерних процессов). Не совсем понятно почему в скобках на схеме указан Docker Container, но уверен что автор имел ввиду что-то иное.
Про авторизацию рискну предположить: Мне нравится своей простотой передача в URL через Query-параметр. Ввиду того что TLS шифрует все кроме хоста и порта это относительно безопасно. У такого подхода есть ряд недостатков, наиболее существенный из которых в том, что query-параметры обычно логируются на промежуточных серверах как части запроса, и если риск попадания токена в логи недопустим, то с таким вариантом возникают сложности. Для решения данной проблемы существует схема, которая основывается на разделении сессионного токена и отдельного токена для установки WebSocket-соединения. Так же есть вариант: Сначала можно выполнить обычный HTTP-запрос авторизации (например, POST запрос для получения токена). После успешной аутентификации можно сохранять токен в локальном хранилище (localStorage) или куках и затем устанавливать WebSocket-соединение.
Проект интересен с точки зрения "подводных камней" и фич, которые могут быть полезны для разработчиков. Жду следующих частей!
Многое из того, что создал человек находит отражение в природе. Он же в ней живет, учится, смотрит на нее, где он еще будет идеи брать? Есть даже теория биомиметики,подразумевающая, что человек позаимствовать решение аналогичной проблемы у природы (самый популярный пример про стрекозу и самолет).
Читал "Мартин Гарднер. Этот правый, левый мир - 1967". Книга о том, как симметричные и асимметричные формы влияют на нашу восприятие и эстетику, а также на структуры и модели в окружающем мире. Графомания, но не мало интересных моментов и простых эксперементов!
Как выходец из подобной платформы обучения алгоритмическому мышлению, хочу сказать, что в качестве негативных(относительно современной разработки) качеств, я научился и ПРИНОРОВИЛСЯ делать спагетти в событийно-ориентированной архитектуре(EDA) на блоках, так затем и на настоящих ЯП без разделения на файлы и описывая все только функциям в процедурно-ориентированном стиле. Тем не менее, Scratch остаётся великолепным инструментом для мгновенной визуализации программ, позволяющим детям абстрагироваться от ненужных деталей на ранних этапах обучения. Это идеальный конструктор для начала, дающий возможность сфокусироваться на сути алгоритмов и логике, не отвлекаясь на технические детали. Помимо разработчиков, появилось много профессий связанных с кодингом, например ИИ. Рассматриваете ли подобные темы для расширения кругозора детей?
«Баланс – это не что-то, что вы находите, это что-то, что вы создаете.» – Джана Кингсфорд.
Думаю необходимо иметь баланс в построении баланса жизни. Иногда люди увлекаются процессом документирования своих целей, идей и планов, что нередко приводит к иллюзии прогресса. Это, в свою очередь, может вести к прокрастинации и разочарованию, когда ожидаемые эмоции от достижения целей не соответствуют реальности.
Я полностью согласен с автором: наличие системы планирования может стать надежным инструментом для уверенности на пути. Это помогает освободить ум, а также эффективно декомпозировать цели, выявляя возможные пробелы в понимании шагов к их достижению и избавляясь от цейтнота.
Интуитивно применял большинство методов еще до того как у знал об их существовании, интересно будет почитать про практические наблюдения во 2 части.
А где картинки, демка, хоть что-то. Стоило бы добавить графического материала, переписывать код, чтоб увидеть - не особо хочется
Например о реализации update-interfaces.js (Автоматический скрипт генерации).
О том что его нужно явно вызвать с помощью
npm run updateТак же не сказано, что необходимо иметь токен, дать ссылки или вкратце рассказать о его получении.
Больше примеров использования - CRUD, нюансы(если есть).
Думаю можно еще чем разбавить.
Обзор без обзора... Ваша же библиотека и продукт, неужели нет мотивации рассказать о нем побольше? Кратко и сердито
Безусловно согласен с вами
Так в чем вызовы то были? И оригинальное решение... А какие еще средства автоматизации можно рассмотреть для работы с гугл формами - только Google Apps Script! Хотя безусловно есть негибкие велосипеды на гитхабе. Статья больше подходит под формат гайда
Огромная работа была проделана и думаю много еще предстоит. Как раз хотел изучить деплой nestjs приложений и рассматривал разные варианты работы с процессами, эту очень крутую и доходчивую статью взял в закладки.
Почему был выбран именно ztv.su (не смог найти доводы в статье на dev.to)?Полагаю просто по цене?
Так же заметил опечатку в 12 пункте
Лично мне интересно бы узнать про работу Sucrose под капотом. Но боюсь это может не подойти под ваши идеи статьи, но всегда ведь можно написать еще одну. Вообщем я бы с удовольствием почитал!
Стабильная версия вышла в марте, смело уже иметь проду на ней(Переучивались с какого-то стека или давно за Elisya следите?). Bun+Elysia это шустро и круто, но мне не хватает CLI (хотя я только что нашел что-то подобное).
В целом думаю, что Bun может потягаться с мастодонтами, и вижу за ним будущее JS Backend разработки.
Node — H3 — Nuxt
Node — Express/Fastify — Nest
Node — Next
Bun — Hono — ?
Не знаком с фреймворками построенными на Hono. А как самостоятельный фреймворк для проды выглядит не очень... Пока нет хедлайнера, Hono вряд‑ли получит нужную поддержку и охваты. Кстати, напомнило Ruby с их философией, загуглил — тоже Япония!
Как туториал статья выполняет свои цели. На удивление, действительно статей о Hono на хабре раз-два и обчелся. Спасибо автору за просвещение и популяризацию!
Считаю, что это зависит от целей.
Вижу 2 направления:
pet-проекты для трудоустройства: мелкие проекты приближенные к реальному(а в идеале реальные), задача которых решать бизнес-проблемы. Тогда их будет легко описать в резюме через STAR методику.
pet-проекты для экспертизы в стеке технологий,в архитектуре,полном сопровождении ПО: большие проекты(не обязательно монолиты), которые задействует как можно больше технологий, нюансов, моментов - в таком случае чем тяжелее, тем лучше.
По собственному опыту знаю, что самые сложные и "экспертные" моменты возникают там где их не ждешь, и чем сложнее проект, чем индивидуальнее, тем больше этих моментов будет.
Есть еще направления(#для своих нужд, #для набивания руки), кто хочет поделиться своими целями и видением, пожалуйста, самому интересна данная тема.
Да, думаю ваше решение хорошее и безопасное при правильной настройке.
Дополню комментарий выше.
Запуск нескольких процессов в одном контейнере противоречит концепции докера. Докер сделан так, чтобы запускать один процесс (не считая дочерних процессов). Не совсем понятно почему в скобках на схеме указан Docker Container, но уверен что автор имел ввиду что-то иное.
Про авторизацию рискну предположить:
Мне нравится своей простотой передача в URL через Query-параметр. Ввиду того что TLS шифрует все кроме хоста и порта это относительно безопасно. У такого подхода есть ряд недостатков, наиболее существенный из которых в том, что query-параметры обычно логируются на промежуточных серверах как части запроса, и если риск попадания токена в логи недопустим, то с таким вариантом возникают сложности. Для решения данной проблемы существует схема, которая основывается на разделении сессионного токена и отдельного токена для установки WebSocket-соединения.
Так же есть вариант:
Сначала можно выполнить обычный HTTP-запрос авторизации (например, POST запрос для получения токена). После успешной аутентификации можно сохранять токен в локальном хранилище (localStorage) или куках и затем устанавливать WebSocket-соединение.
Проект интересен с точки зрения "подводных камней" и фич, которые могут быть полезны для разработчиков.
Жду следующих частей!
На самом деле круто, что у вас есть столько времени на рефакторинг и развитие культуры кода в команде. Советы в конце возьму в обиход.
Многое из того, что создал человек находит отражение в природе. Он же в ней живет, учится, смотрит на нее, где он еще будет идеи брать? Есть даже теория биомиметики,подразумевающая, что человек позаимствовать решение аналогичной проблемы у природы (самый популярный пример про стрекозу и самолет).
Читал "Мартин Гарднер. Этот правый, левый мир - 1967". Книга о том, как симметричные и асимметричные формы влияют на нашу восприятие и эстетику, а также на структуры и модели в окружающем мире. Графомания, но не мало интересных моментов и простых эксперементов!
Как выходец из подобной платформы обучения алгоритмическому мышлению, хочу сказать, что в качестве негативных(относительно современной разработки) качеств, я научился и ПРИНОРОВИЛСЯ делать спагетти в событийно-ориентированной архитектуре(EDA) на блоках, так затем и на настоящих ЯП без разделения на файлы и описывая все только функциям в процедурно-ориентированном стиле. Тем не менее, Scratch остаётся великолепным инструментом для мгновенной визуализации программ, позволяющим детям абстрагироваться от ненужных деталей на ранних этапах обучения. Это идеальный конструктор для начала, дающий возможность сфокусироваться на сути алгоритмов и логике, не отвлекаясь на технические детали.
Помимо разработчиков, появилось много профессий связанных с кодингом, например ИИ. Рассматриваете ли подобные темы для расширения кругозора детей?
«Баланс – это не что-то, что вы находите, это что-то, что вы создаете.» – Джана Кингсфорд.
Думаю необходимо иметь баланс в построении баланса жизни.
Иногда люди увлекаются процессом документирования своих целей, идей и планов, что нередко приводит к иллюзии прогресса. Это, в свою очередь, может вести к прокрастинации и разочарованию, когда ожидаемые эмоции от достижения целей не соответствуют реальности.
Я полностью согласен с автором: наличие системы планирования может стать надежным инструментом для уверенности на пути. Это помогает освободить ум, а также эффективно декомпозировать цели, выявляя возможные пробелы в понимании шагов к их достижению и избавляясь от цейтнота.
Интуитивно применял большинство методов еще до того как у знал об их существовании, интересно будет почитать про практические наблюдения во 2 части.