Т.е. HTML рендерится с помощью магии? Не благодаря тому, что браузер создает новые объекты? (Я надеюсь, вы не будете меня заставлять делать реверс инжиниринг браузера).
В данном примере «немножко» означает, что за (приблизительно) два года работы с CloudFormation я так и не смог ни настроить для него CI-верификацию, ни поддержку в редакторе за пределами подсветки YAML (заметим, именно базового YAML, а не специфических команд CFN). Для питона у меня есть и то, и другое.
VS Code.
Честно, не знаю насчет VS Code, лично мне он сразу не понравился — не считаю его удобным. Но для Intellij есть плагины, вот например.
Представьте себе браузер без поддержки JS, и вы поймете, почему.
В этом плане — согласен.
HTML — это «всего лишь» язык разметки. Дальше он отображается визуализатором или редактором, или парсится конвертером, или еще что-то.
В моем понимании, HTML — просто текст, если он не парсится. Будь то библиотека (например) или браузер.Но когда HTML парсится, мы же в любом случае создаем функции и переменные. Например, встраивание видео через HTML или iframe для рендеринга задействует API браузера, который, в свою очередь, наверняка задействует API операционной системы. Нам же нужны драйвера для воспроизведения видео/аудио.
немножко
можете объяснить, что в данном контексте означает «немножко»? И какая IDE приведена в качестве примера? PyCharm?
Я вам настоятельно не рекомендую публиковать фреймворк до появления какого-то проекта, хотя бы игрушечного, сделанного с его помощью. Потому что пока вы не соберете проблем, возникающих в прикладном применении, вы не понимаете слабых (и сильных) мест вашего фреймворка.
хорошее замечание. Вообще, 0.0.1 была опубликована с целью сбора как раз таки проблем. Т.е. я никого не заставляю силком устанавливать фреймворк — а на pypi (как и на github) вроде пока нет ограничений по заливке. Моя основная цель как раз — привлечь сообщество. Вот с вами, например, у нас получилась интересная и полезная (по крайней мере, для меня) дискуссия. Я бы вряд ли обратил внимание на многие проблемы, если бы продолжал разрабатывать тихо сам с собой, как я делал примерно год до публикации фреймворка. До этого я его переписал с нуля несколько раз и было произведено множество экспериментов. А wowcore я начал писать еще осенью 2018. На хабре есть несколькостатей, где я рассматривал проблемы оптимизации python кода (как раз оттуда)
В том, что можно ресурс запихнуть в переменную, и из других ресурсов обращаться к переменной. Необъявленные переменные прекрасно ловит линтер питона (и компиляторы для компилируемых языков). В том, что можно повторяющееся создание ресурса запихнуть в компонент, который положить в модуль, распространяемый средствами языка, и переиспользовать между разными проектами.
Ну а в template есть !Ref и необъявленные ресурсы отлавливаются хуками aws deploy. В чем тогда разница?
… может тогда не стоит его приводить как пример?
Я считаю, что стоит, раз у меня есть опыт работы с ним. Я ведь не умничаю, а правда думаю то, что пишу — и с благодарностью принимаю наставления от более опытных людей :)
Это инфраструктура, а не прикладной код.
Прикладной код появится чуть позже. Как я писал ранее, я планирую переписать свой wow сервер на базе моего фреймворка, чтобы определить, какие вообще есть проблемы и подводные камни.
А у вас даже констант нет, вы kwargs.pop('session_storage') в каждом методе повторяете зачем-то.
Да, тут я согласен. Есть такая проблема. Я пока не придумал, как грамотно переместить все строки. Чтобы это было еще и удобно.
Но вы согласны, что хоть пишу-то я на HTML, ноды я генерирую в самом что ни на есть javascript DOM дереве? И добавляя тэг, я использую фактически и функции, и переменные. Это не программирование?
В ту же корзиночку: Pulumi.
Спасибо, я гляну. Пока что начал смотреть aws-cdk и навскидку — хотя и переехали в пайтон, там по прежнему много строк. Ну т.е. по сути кусок конфига переехал в пайтон код. В чем суть удобства в таком случае? Со строками, на мой взгляд, проблемы где-угодно одинаковые: пропущенный символ может стать незабываемым дебаг-приключением на пол-дня.
Вы, скажем, не натолкнулись на проблему, что для CloudFormation-шаблонов нужен отдельный линтер? Что подсветка синтаксиса в них работает не очень, навигация еще хуже, а рефакторинг — вообще никак?
Честно вам скажу, я не фанат AWS. Я с ним работал всего месяцев 8, на высоконагруженном проекте, но не в качестве архитектора, а в качестве пайтон дэва. И общался с AWS на базовом уровне — лямбды, легкие правки в template.yml, деплой, дебаг, бакеты, динамодб и прочие мелочи. Ну т.е. я понимаю, что для деплоя — это крутая штука, но вот работать с ним — это что-то невероятное. Очень неудобная в плане кодинга/настройки вещь.
И то же самое будет с вашими конфигами: вы решили переименовать милдварь, и вам нужно придумывать какой-то тулинг, чтобы поймать все места, где эта мидлварь использовалась, до запуска приложения. Вы решили выделить часто используемый набор мидлварей в какой-то компонент — вы не можете сделать это автоматически.
Да, тут я с вами согласен. Это — хорошее замечание. Более того, я с этим столкнулся еще до релиза и думаю, как решить это минимальными потерями.
Кстати, любопытно посмотреть на пример хотя бы двух реальных middleware, используемых в вашей архитектуре.
Новые функции уже создаете — ваш «пайп» уже и есть такая функция. И переменная у вас уже есть — то, по чему вы делаете маршрутизацию.
Вы используете «конфиг», чтобы задать новый сервер и определить его поведение, собрав это поведение из набора разных элементов. Для меня это программирование.
Мы создаем новые ноды DOM дерева, добавляя HTML тэги. HTML пора объявлять языком программирования?
Так вот. Во-первых, я за последние пару лет написал достаточно этих шаблонов, чтобы понять, что писать их, на самом деле, адски неудобно. А во-вторых, я был не единственным, кто это понял, и поэтому даже сам AWS потихоньку внедряет CDK, который, внезапно, сделан именно на языках программирования.
Про CDK — это очень интересное замечание! Мне нужно изучить, чтобы я мог в полной мере проанализировать обстановку.
Мы в первую очередь задаем конфигурацию системы. Чем больше ее поведения переезжает в этот конфиг, тем сложнее им становится управлять.
Возможно. Я пока еще не натолкнулся на такие проблемы, поэтому не могу как-то парировать ваше замечание.
Ну как минимум, если мне могут понадобиться разные варианты — мне придется держать пять папок с разными py-файлами. Либо одну папку — с пятью разными конфигами. Мне кажется, разница — есть.
Но все зависит, конечно, от набора задач. Они могут быть очень специфические, поэтому вопрос спорный.
Удивительно, но код на питоне тоже «просто указывает порядок выполнения функций».
Но пишете-то вы на yaml.
Да, но при этом я не создаю переменных, новых функций и так далее. Тот факт, что я использую конфиг для указывания порядка еще не делает из yaml среды программирования. А то мы прийдем так к выводу, что HTML — все-таки язык программирования (ведь по сути, мы тоже меняем порядок запрограммированных в другом месте тэгов).
Что за «конфиг AWS»? Вы не про CloudFormation, случайно?
Да, он. Мы в темплейте объявляем AWS ресурсы.
Вопрос в том, для чего они их используют.
Что — «повсеместная практика»? Задавать поведение системы ее описанием в конфигурации?
В качестве примера возьму тот же AWS конфиг (aws cloudformation template.yml). Разве мы не меняем поведение системы, указывая policies, разные набор ресурсов и т.д.?
То, что вы фактически программируете на языке, который для программирования не очень предназначен.
Если быть точнее, я просто указываю порядок выполнения функций. А парсер преобразовывает конфиг в словарь — нативную структуру в пайтоне, которая в качестве значения (да и ключа, в общем-то) может содержать любой тип данных пайтона. И уже после всех преобразований код выполняется в пайтоне. Не в yaml'е.
«Плохое» в том, что вы, на самом деле, изменяете код. Просто этот код теперь не на питоне, а на ямле.
Вообще, если посмотреть в сторону других фреймворков, которые используют yaml-конфиги, мы обнаружим немало интересного. Тот же Symfony2 (к примеру), использует yaml со всякими структурами наподобие imports. Или конфиг AWS (template.yml) со всякими доп. командами. Насколько я вижу, это — повсеместная практика и лично я по прежнему не вижу в этом ничего плохого. Не убедили.
… и вам для этого понадобилась самописная конфигурация на YAML? Печально.
А вы можете развить свою мысль? Что конкретно печального вы нашли при использовании YAML в данном случае?
Это анти-паттерн? Или есть проблемы с производительностью?
Просто я не вижу ничего плохого в том, чтобы имея разные конфиги — получать разный набор серверов, не изменяя при этом код.
Изначально фреймворк разрабатывался для создания MMO RPG серверов. Т.е. допустим, у меня есть набор уже ранее разработанных миддлвэров и при замене датасэта (т.е. данных, которые я используя для наполнения сервера — мобы, предметы и т.д.) и, возможно, замене некоторых миддлвэров мы можем получить сервер другой игры.
Зачем это надо? ну а зачем вообще люди код пишут :) Для саморазвития, наверное. Привлечения сообщества, поиска узких мест, оптимизации, масштабирования. И, возможно, в будущем — выпуска собственной MMO RPG игры.
Я ждал этого вопроса :) Не хотел раздувать статью. Изначально я писал python сервер для WoW. Но потом мне пришла идея сделать инструмент для создания серверов наподобие такого. Т.к. по сути код WoW серверов мало чем отличается. И мой фреймворк облегчает задачу в разработке таких серверов.
Потом я решил, что с учетом необходимости при WoW сервере иметь еще и веб-сайт, было бы неплохо, чтобы фреймворк позволял создавать вообще любые серверы. А с учетом архитектуры я могу создавать интересные вещи, например, веб-интерфейс для взаимодействия с вов. Или можно смотреть онлайн перемещение персонажей, мобов и так далее.
Идей вообще у меня еще много и если я увижу интерес к данной статье, я обязательно напишу еще. В частности, я планирую переписать свой WoW сервер, приведенный по ссылке в данном комментарии, на базе моего фреймворка.
Сомневаюсь, что это перевод. А вопросы такие (с адаптацией под конкретную ситуацию) задавать полезно, по крайней мере для тех, кто работает за деньги, но не ради денег. Например, для того, чтобы определить уровень комфорта и возможности развиваться как разработчику.
Делал тестовое задание для одной конторы, а там эйчар перепутала результаты и мне отправила негативный отзыв о моем коде (как оказалось, все-таки не о моем). Но я то знаю, что мой код достаточно качественный — вобщем, с трудом, но добился справедливости, так как меня это задело, перепроверили все и пригласили на финальное интервью. На встречу ко мне пришел директор в компании вышеупомянутой девушки-эйчара и изможденного кодера. Директор с ходу начал меня допрашивать (буквально, были жесткие вопросы наподобие: «где живешь?», «женат?»), я немного опешил, но практически сразу дал понять, что на такие вопросы отвечать желания не имею. Видимо, директору это не понравилось — потому как согласно фидбэку «нашли более опытного». Но я рад, что туда не попал (судя по отдельным признакам, в частности, внешний вид команды — там мало кого никого не волнует состояние людей).
Мораль: отношение к тестовому заданию — тоже хороший индикатор, какое вообще отношение к разработчикам внутри компании. И по хорошему надо брать ревью. И в качестве бонуса — оценку навыка в линкедине.
можете объяснить, что в данном контексте означает «немножко»? И какая IDE приведена в качестве примера? PyCharm?
хорошее замечание. Вообще, 0.0.1 была опубликована с целью сбора как раз таки проблем. Т.е. я никого не заставляю силком устанавливать фреймворк — а на pypi (как и на github) вроде пока нет ограничений по заливке. Моя основная цель как раз — привлечь сообщество. Вот с вами, например, у нас получилась интересная и полезная (по крайней мере, для меня) дискуссия. Я бы вряд ли обратил внимание на многие проблемы, если бы продолжал разрабатывать тихо сам с собой, как я делал примерно год до публикации фреймворка. До этого я его переписал с нуля несколько раз и было произведено множество экспериментов. А wowcore я начал писать еще осенью 2018. На хабре есть несколько статей, где я рассматривал проблемы оптимизации python кода (как раз оттуда)
Ну а в template есть !Ref и необъявленные ресурсы отлавливаются хуками aws deploy. В чем тогда разница?
Я считаю, что стоит, раз у меня есть опыт работы с ним. Я ведь не умничаю, а правда думаю то, что пишу — и с благодарностью принимаю наставления от более опытных людей :)
Прикладной код появится чуть позже. Как я писал ранее, я планирую переписать свой wow сервер на базе моего фреймворка, чтобы определить, какие вообще есть проблемы и подводные камни.
Да, тут я согласен. Есть такая проблема. Я пока не придумал, как грамотно переместить все строки. Чтобы это было еще и удобно.
Спасибо, я гляну. Пока что начал смотреть aws-cdk и навскидку — хотя и переехали в пайтон, там по прежнему много строк. Ну т.е. по сути кусок конфига переехал в пайтон код. В чем суть удобства в таком случае? Со строками, на мой взгляд, проблемы где-угодно одинаковые: пропущенный символ может стать незабываемым дебаг-приключением на пол-дня.
Честно вам скажу, я не фанат AWS. Я с ним работал всего месяцев 8, на высоконагруженном проекте, но не в качестве архитектора, а в качестве пайтон дэва. И общался с AWS на базовом уровне — лямбды, легкие правки в template.yml, деплой, дебаг, бакеты, динамодб и прочие мелочи. Ну т.е. я понимаю, что для деплоя — это крутая штука, но вот работать с ним — это что-то невероятное. Очень неудобная в плане кодинга/настройки вещь.
Да, тут я с вами согласен. Это — хорошее замечание. Более того, я с этим столкнулся еще до релиза и думаю, как решить это минимальными потерями.
Например
Про CDK — это очень интересное замечание! Мне нужно изучить, чтобы я мог в полной мере проанализировать обстановку.
Возможно. Я пока еще не натолкнулся на такие проблемы, поэтому не могу как-то парировать ваше замечание.
Но все зависит, конечно, от набора задач. Они могут быть очень специфические, поэтому вопрос спорный.
Да, он. Мы в темплейте объявляем AWS ресурсы.
В качестве примера возьму тот же AWS конфиг (aws cloudformation template.yml). Разве мы не меняем поведение системы, указывая policies, разные набор ресурсов и т.д.?
Вообще, если посмотреть в сторону других фреймворков, которые используют yaml-конфиги, мы обнаружим немало интересного. Тот же Symfony2 (к примеру), использует yaml со всякими структурами наподобие imports. Или конфиг AWS (template.yml) со всякими доп. командами. Насколько я вижу, это — повсеместная практика и лично я по прежнему не вижу в этом ничего плохого. Не убедили.
Это анти-паттерн? Или есть проблемы с производительностью?
Просто я не вижу ничего плохого в том, чтобы имея разные конфиги — получать разный набор серверов, не изменяя при этом код.
Зачем это надо? ну а зачем вообще люди код пишут :) Для саморазвития, наверное. Привлечения сообщества, поиска узких мест, оптимизации, масштабирования. И, возможно, в будущем — выпуска собственной MMO RPG игры.
Потом я решил, что с учетом необходимости при WoW сервере иметь еще и веб-сайт, было бы неплохо, чтобы фреймворк позволял создавать вообще любые серверы. А с учетом архитектуры я могу создавать интересные вещи, например, веб-интерфейс для взаимодействия с вов. Или можно смотреть онлайн перемещение персонажей, мобов и так далее.
Идей вообще у меня еще много и если я увижу интерес к данной статье, я обязательно напишу еще. В частности, я планирую переписать свой WoW сервер, приведенный по ссылке в данном комментарии, на базе моего фреймворка.
мало когоникого не волнует состояние людей).Мораль: отношение к тестовому заданию — тоже хороший индикатор, какое вообще отношение к разработчикам внутри компании. И по хорошему надо брать ревью. И в качестве бонуса — оценку навыка в линкедине.