Вы совершенно правы) Но если копнуть чуть глубже... До любой автошколы дети играют в машинки. До любого тира - играют в стрелялки. Вы всё ещё мыслите с точки зрения взрослого. Вспомните, как сами познавали мир в детстве. Вы просто пробовали. Не нравилось - наверняка бросали, а потом, возможно, снова возвращались к этому. В этом всё детство. Детство - для поисков себя
Для того, чтобы ребёнок сделал первый шаг, ему не нужно читать лекции о правильной ходьбе. Лучше покажи, как круто ты ходишь сам. А для того, чтобы ребёнок заинтересовался роботами - не нужно давать ему книгу о робототехнике. Лучше покажи ему самого необычного робота - и он сам попросит и книгу, и конструктор
Ну слушайте, в какое-то время для детей даже еда могла быть праздником, а сейчас это обыденность. Я рад, что уровень образования, да и жизни в целом, повышается. Сейчас детям легко пробовать себя в самых разных направлениях - это огромный плюс. Раньше было сложнее. Чтобы в чем-то себя попробовать, нужно было трудиться. Обратный путь, или путь в другую специальность, был практически закрыт. И очень хорошо, если сложное окажется интереснее, чем простое. Это значит, человек нашел свое призвание.
Я не согласен с тем, что дети стали избалованными - просто мир меняется, вот и всё
Я в 11 начал с PHP)) но не думаю, что это самый правильный подход. Ребёнку надо давать то, что ему нравится. Если ему нравится делать роботов - надо идти в робототехнику, если нравится делать игры - в unity или java (мне совершенно случайно попался чрезвычайно интересный курс по java именно в геймдеве, причём для desktop). А может ему тоже понравится веб. Думаю, не важно, с чего начинать. Главное, чтобы было интересно, и очень важно получать обратную связь от ребёнка. И если он вдруг решит сменить направление - это совершенно нормально, и это даже стоит поощрить, т.к. не у каждого найдутся силы изучать что-то неизвестное, когда уже столько опыта в другой сфере
На самом деле, зря заминусили. Я себе так и представляю развитие нейросетей. Представьте: модель сама читает книгу, сама по ней ТРЕНИРУЕТСЯ, то есть сама себе генерирует обучающие данные по теоретической базе
Правда, для этого моделям нужно добавить воображение, способность самом себе ставить задачи и цели, реализовать сознание...)) утрирую, конечно, но это тот самый недостижимый AGI
Статья классная, всё по делу. Отдельный респект за настройку пользователя в Dockerfile.
Есть замечания и непонятки:
Вы уверены, что хотите оставить hot-reload в проде? (Или я что-то упустил?)
В своём аналогичном монстре-проекте на 3 FastAPI-сервиса + Vue + React я создал дев и прод конфиги. В дев везде hot-reload, в прод везде npm build и копирование напрямую в образ nginx (multistage сборка). Получается, без proxy_pass, напрямую отдаётся html/css/JS. Это намного быстрее
Не понял посыл статьи. Почему это названо именно связыванием Angular с Symphony? Это универсальный гайд. Аналогичные решения применяют везде. Как я уже писал выше, я аналогичным образом связал FastAPI с Vue и React. nginx, как и любой другой обратный прокси, позволяет связать любые http сервисы. Здесь кстати был бы удобен какой-нибудь apache. Я очень люблю его за htaccess файлы, но это уже вкусовщина
Я, честно, ожидал слегка большего. Думал, будут рассмотрены какие-нибудь интересные принципы взаимодействия angular с бэком. Просто следовало название статьи сделать чуть более точным)
Меня впечатлила теория возникновения сознания как способа моделировать окружение как систему, в которой содержится "я" и предсказывать реакцию окружения на собственные действия. Звучит очень разумно
Любой компьютер, напротив, "углубляется" в рамки МТ, потому как всё, что Вы перечислили, является ограничениями, не позволяющими реализовать на реальном компьютере любой алгоритм для МТ
Дорогие комментаторы. Прочтите пожалуйста внимательно: человек учит ДЕТЕЙ. Если вы детям будете рассказывать о законах Кирхгофа и Ома, они на второе занятие уже не придут, и ничему полезному не научатся. Пусть лучше сначала заинтересуются, а потом уже углубятся. Именно так я и изучал программирование с 11 лет - начинал с верхов, с PHP. Делал красивые сайтики. Сейчас мне 21, и я прогаю на плюсах и ассемблере в embedded
Все так делают, тут автор комментария что-то перепутал явно... Иначе получится, что заказ собрали, а оплату не получили - никакой безопасности. Обычно просто доплата/возврат/замена идут в случае изменения состава заказа
Довольно интересно) в действительности, увы, каждый элемент должен работать стабильно, независимо от того, сколько других элементов во всём рое. Дело в том, что воркеры - это идеальные клоны. Если один из них ведёт себя нестабильно, значит и остальные тоже. Если "забить" на поведение конкретных элементов, приложение/сервис будет работать как Франкенштейн, у которого части тела отказывают. Например, в интернет магазине каталог товаров работает, но заказ из корзины нельзя оформить. "Это же рой, в целом среда рабочая", - увы, не оправдание... Я не к тому, что идея плохая - нужно просто её развить и продумать до конца. Так-то было бы удобно мыслить высокоуровневыми конечными целями вместо конкретных системных фич. Но детальный контроль никуда не девается, увы
А ещё открою секрет: когда вы пишите любую программу, вы уже в парадигме среды. Потому что любая программа запускается на ОС. ОС - среда, в прямом смысле. ОС работает на компьютере. Компьютер - также среда. Да и компьютер, в свою очередь, функционирует в среде, в которой мы живём)) просто за каждую среду отвечают свои люди. Каждая среда - система. От этого не убежишь, во всяком случае, пока что. Любая среда декомпозирована и успешно поддерживается ответственными людьми, контролируется каждый элемент. Без этого не создать процессор. Без этого не создать ОС. Даже браузер, на котором описанный выше сайт-франкенштейн крутится, не создать
В больших компаниях люди, которые только что пришли, тоже живут в своей среде. Остальное для них просто работает. Они могут даже не понять, что в другой среде есть баг, т.к. это не их зона ответственности. Хотя они работают с этой средой, разрабатывают они другую. Что для них - неизведанный рой с набором высокоуровневых конечных целей, описывающих, как это должно работать, для других - понятная система с четкой структурой
Так что отчасти мы уже в этой парадигме. Просто нужно увидеть её. Мы никогда не будем контролировать всё на свете, но будем контролировать то, за что ответственны, и доверять другим ответственным людям. "Разделяй и властвуй"
P.S. надеюсь, я правильно понял посыл статьи. Если что - заранее извиняюсь и прошу поправить
Не знаю, как у вас, а у нас ветка оформляется ПЕРЕД созданием merge request, а не после, чтобы не загрязнять обсуждения в GitLab (там же выводится список коммитов после любого push). В процессе разработки можно как угодно коммиты делать. Но в историю должны пойти чистые и аккуратные коммиты
Про дробление файлов, как мне кажется, идея отличная - можно было вместо всех этих трудностей с пулами просто регулярно говорить клиенту, на какой сервер какой процент блоков файла отправлять
L7 для балансеров, скорее всего. То есть чтобы достучаться до какого-то балансера для получения адреса сервера, нужно пройти через gateway, т.к. балансеров тоже много, но трафик там небольшой
Смотрите. В 1-м своём комментарии я не навязывал обязательное использование стора. Я лишь перечислил плюсы такого подхода. Если есть пагинация, и нужно фильтровать данные в разных местах - стор, скорее всего, не стоит использовать вовсе. Всё зависит от потребностей)
Когда я писал второй комментарий, я неверно вас понял, за что извиняюсь. Решил, что вы собрались писать логику обработки данных прямо в компоненте))
Но тем не менее. Допустим, у вас есть множество сервисов, занимающихся обработкой и получением данных. Стора в проекте пока нет. Вы в компонентах получаете / отправляете данные только через сервисы. Но вдруг появляется первый ваш стор. И прямо в этом сторе прописано:data.value = await (await fetch(...)).json();проходит какое-то время, и в команду приходит новенький. Ему дают задачу: дописать логику получения данных с бэка. Например, поменять формат данных, возвращаемых API. Где он будет искать логику получения данных? Конечно, в сервисах. А найдёт в сторе. И где ему дописывать новую логику?
Вы совершенно правы) Но если копнуть чуть глубже... До любой автошколы дети играют в машинки. До любого тира - играют в стрелялки. Вы всё ещё мыслите с точки зрения взрослого. Вспомните, как сами познавали мир в детстве. Вы просто пробовали. Не нравилось - наверняка бросали, а потом, возможно, снова возвращались к этому. В этом всё детство. Детство - для поисков себя
Для того, чтобы ребёнок сделал первый шаг, ему не нужно читать лекции о правильной ходьбе. Лучше покажи, как круто ты ходишь сам. А для того, чтобы ребёнок заинтересовался роботами - не нужно давать ему книгу о робототехнике. Лучше покажи ему самого необычного робота - и он сам попросит и книгу, и конструктор
Ну слушайте, в какое-то время для детей даже еда могла быть праздником, а сейчас это обыденность. Я рад, что уровень образования, да и жизни в целом, повышается. Сейчас детям легко пробовать себя в самых разных направлениях - это огромный плюс. Раньше было сложнее. Чтобы в чем-то себя попробовать, нужно было трудиться. Обратный путь, или путь в другую специальность, был практически закрыт. И очень хорошо, если сложное окажется интереснее, чем простое. Это значит, человек нашел свое призвание.
Я не согласен с тем, что дети стали избалованными - просто мир меняется, вот и всё
Не думаю, что водитель приуса прям уж без переобучения сядет за Феррари)))
А вообще, если не воспринимать аналогию так буквально, можно вспомнить, сколько ему нужно будет на эту самую Феррари копить...
Я в 11 начал с PHP)) но не думаю, что это самый правильный подход. Ребёнку надо давать то, что ему нравится. Если ему нравится делать роботов - надо идти в робототехнику, если нравится делать игры - в unity или java (мне совершенно случайно попался чрезвычайно интересный курс по java именно в геймдеве, причём для desktop). А может ему тоже понравится веб. Думаю, не важно, с чего начинать. Главное, чтобы было интересно, и очень важно получать обратную связь от ребёнка. И если он вдруг решит сменить направление - это совершенно нормально, и это даже стоит поощрить, т.к. не у каждого найдутся силы изучать что-то неизвестное, когда уже столько опыта в другой сфере
Желаю удачи вашему сыну!
Тут вопрос направления развития: как инструмент, или как замена программистам. Cursor видимо выбрали первое
На самом деле, зря заминусили. Я себе так и представляю развитие нейросетей. Представьте: модель сама читает книгу, сама по ней ТРЕНИРУЕТСЯ, то есть сама себе генерирует обучающие данные по теоретической базе
Правда, для этого моделям нужно добавить воображение, способность самом себе ставить задачи и цели, реализовать сознание...)) утрирую, конечно, но это тот самый недостижимый AGI
Статья классная, всё по делу. Отдельный респект за настройку пользователя в Dockerfile.
Есть замечания и непонятки:
Вы уверены, что хотите оставить hot-reload в проде? (Или я что-то упустил?)
В своём аналогичном монстре-проекте на 3 FastAPI-сервиса + Vue + React я создал дев и прод конфиги. В дев везде hot-reload, в прод везде npm build и копирование напрямую в образ nginx (multistage сборка). Получается, без proxy_pass, напрямую отдаётся html/css/JS. Это намного быстрее
Не понял посыл статьи. Почему это названо именно связыванием Angular с Symphony? Это универсальный гайд. Аналогичные решения применяют везде. Как я уже писал выше, я аналогичным образом связал FastAPI с Vue и React. nginx, как и любой другой обратный прокси, позволяет связать любые http сервисы. Здесь кстати был бы удобен какой-нибудь apache. Я очень люблю его за htaccess файлы, но это уже вкусовщина
Я, честно, ожидал слегка большего. Думал, будут рассмотрены какие-нибудь интересные принципы взаимодействия angular с бэком. Просто следовало название статьи сделать чуть более точным)
Меня впечатлила теория возникновения сознания как способа моделировать окружение как систему, в которой содержится "я" и предсказывать реакцию окружения на собственные действия. Звучит очень разумно
Любой компьютер, напротив, "углубляется" в рамки МТ, потому как всё, что Вы перечислили, является ограничениями, не позволяющими реализовать на реальном компьютере любой алгоритм для МТ
Через телегу скоро весь интернет будет работать
С такими требованиями - не странно))
(без негатива)
Дорогие комментаторы. Прочтите пожалуйста внимательно: человек учит ДЕТЕЙ. Если вы детям будете рассказывать о законах Кирхгофа и Ома, они на второе занятие уже не придут, и ничему полезному не научатся. Пусть лучше сначала заинтересуются, а потом уже углубятся. Именно так я и изучал программирование с 11 лет - начинал с верхов, с PHP. Делал красивые сайтики. Сейчас мне 21, и я прогаю на плюсах и ассемблере в embedded
Неужели никто не пошутит про адский номер релиза?
Все так делают, тут автор комментария что-то перепутал явно... Иначе получится, что заказ собрали, а оплату не получили - никакой безопасности. Обычно просто доплата/возврат/замена идут в случае изменения состава заказа
Довольно интересно) в действительности, увы, каждый элемент должен работать стабильно, независимо от того, сколько других элементов во всём рое. Дело в том, что воркеры - это идеальные клоны. Если один из них ведёт себя нестабильно, значит и остальные тоже. Если "забить" на поведение конкретных элементов, приложение/сервис будет работать как Франкенштейн, у которого части тела отказывают. Например, в интернет магазине каталог товаров работает, но заказ из корзины нельзя оформить. "Это же рой, в целом среда рабочая", - увы, не оправдание... Я не к тому, что идея плохая - нужно просто её развить и продумать до конца. Так-то было бы удобно мыслить высокоуровневыми конечными целями вместо конкретных системных фич. Но детальный контроль никуда не девается, увы
А ещё открою секрет: когда вы пишите любую программу, вы уже в парадигме среды. Потому что любая программа запускается на ОС. ОС - среда, в прямом смысле. ОС работает на компьютере. Компьютер - также среда. Да и компьютер, в свою очередь, функционирует в среде, в которой мы живём)) просто за каждую среду отвечают свои люди. Каждая среда - система. От этого не убежишь, во всяком случае, пока что. Любая среда декомпозирована и успешно поддерживается ответственными людьми, контролируется каждый элемент. Без этого не создать процессор. Без этого не создать ОС. Даже браузер, на котором описанный выше сайт-франкенштейн крутится, не создать
В больших компаниях люди, которые только что пришли, тоже живут в своей среде. Остальное для них просто работает. Они могут даже не понять, что в другой среде есть баг, т.к. это не их зона ответственности. Хотя они работают с этой средой, разрабатывают они другую. Что для них - неизведанный рой с набором высокоуровневых конечных целей, описывающих, как это должно работать, для других - понятная система с четкой структурой
Так что отчасти мы уже в этой парадигме. Просто нужно увидеть её. Мы никогда не будем контролировать всё на свете, но будем контролировать то, за что ответственны, и доверять другим ответственным людям. "Разделяй и властвуй"
P.S. надеюсь, я правильно понял посыл статьи. Если что - заранее извиняюсь и прошу поправить
А, значит, всё-таки антропик захватит мир? Способность читать между строк и тут пригодилась)
...а потом кто-то в переменную $CITY добавит символы
';
И будет весело :)
Не знаю, как у вас, а у нас ветка оформляется ПЕРЕД созданием merge request, а не после, чтобы не загрязнять обсуждения в GitLab (там же выводится список коммитов после любого push). В процессе разработки можно как угодно коммиты делать. Но в историю должны пойти чистые и аккуратные коммиты
Про дробление файлов, как мне кажется, идея отличная - можно было вместо всех этих трудностей с пулами просто регулярно говорить клиенту, на какой сервер какой процент блоков файла отправлять
L7 для балансеров, скорее всего. То есть чтобы достучаться до какого-то балансера для получения адреса сервера, нужно пройти через gateway, т.к. балансеров тоже много, но трафик там небольшой
Смотрите. В 1-м своём комментарии я не навязывал обязательное использование стора. Я лишь перечислил плюсы такого подхода. Если есть пагинация, и нужно фильтровать данные в разных местах - стор, скорее всего, не стоит использовать вовсе. Всё зависит от потребностей)
Когда я писал второй комментарий, я неверно вас понял, за что извиняюсь. Решил, что вы собрались писать логику обработки данных прямо в компоненте))
Но тем не менее. Допустим, у вас есть множество сервисов, занимающихся обработкой и получением данных. Стора в проекте пока нет. Вы в компонентах получаете / отправляете данные только через сервисы. Но вдруг появляется первый ваш стор. И прямо в этом сторе прописано:
data.value = await (await fetch(...)).json();проходит какое-то время, и в команду приходит новенький. Ему дают задачу: дописать логику получения данных с бэка. Например, поменять формат данных, возвращаемых API. Где он будет искать логику получения данных? Конечно, в сервисах. А найдёт в сторе. И где ему дописывать новую логику?