Статья устарела. gorilla/mux уже год нет релизов, и пакет ищет мейнтейнера.
go-chi/chi наоборот сильно вырос, и
Как и httprouter, он также не поддерживает маршруты на основе хоста.
уже поддерживает маршруты на основе хоста.
Пакет gorilla/mux, пожалуй, самый известный Go роутер, и на то есть веские причины.
Может и самый известный, но chi его уже сильно обогнал по возможностям. Если посмотреть структуру папок и полазить в коде, то увидим, что chi имеет гораздо больше возможностей чем mux.
Я не претендую, что chi - это то что нужно выбрать, т.к. есть и навороченнее типа gin есть и быстрее и легче.
Я считаю что в идеале код должен быть разделен на минимальные частицы, насколько это возможно.
Но мы можем "схитрить" и упростить код - взять на себя ответственность и объединить некоторые участки вместе, как это сделано в варианте 1 - get_post_for_user_id, заранее предполагая, что этот функционал тоже будет меняться вместе. Т.е. мы упрощаем архитектуру - ради повышения удобочитаемости и когнитивного восприятия кода, под собственное видение программиста каким образом бизнес будет развивать свой проект и с какими задачами на изменение бизнес будет приходить к нам (с какими "осями изменений", "линиями разреза" бизнес будет приходить к нам).
Написав метод get_post_for_user_id мы потеряли информацию.
Во-первых метод должен называться get_post_by_post_id_and_user_id. Потому что название get_post_for_user_id больше подходит для get_posts_for_user_id - когда мы достаем все посты по user_id. Еще есть за что зацепится по П.1: у нас в базе нет одной сущности post для user_id, у нас есть массив posts для user_id. Т.е. в базе есть только однозначное соответствие массива постов posts и user_id. И нет однозначного соответствия какого-то одного поста для user_id. Но может быть last_post_for_user_id, most_rated_post_for_user_id, random_post_for_user_id и т.д. В названии get_post_for_user_id теряется однозначность - какой пост мы достаем = теряется информация.
Во-вторых при применении этого метода в проверке прав доступа, при отсутствии поста (пост с post_id не существует) должна быть одна ошибка, а если post.user_id != user_id, то это уже другая ошибка. Если мы и там и там создаем одну и ту же ошибку - информация теряется. Даже если мы наружу отправляем и там и там одну - 404 ошибку, внутренняя ошибка должна быть разная (для логов, для security отдела и т.д.).
А вот если относить все существующее к неживому, но неживому тупому - камень и неживому активно реагирующему на окружающие внешние изменения (человек), то получается все же наша активная реакция, которую мы называем сознанием - это очень даже клево.
А что такое ДНК? Это набор молекул, таких как углерод, гелий и т.д. А что такое молекула - это набор электронов, протонов и т.д. Давайте тогда уж мыслить на самом базовом уровне - все мы - это набор элементарных (каких-то м.б. электрон м.б. еще элементарнее) частиц. Всего лишь набор элементарных частиц. Но в том то и красота, что элементарные частицы собрались в нечто большее - ДНК. А в том тогда тоже есть красота, что ДНК собрались в нечто большее - сознание.
Неужели есть какие-то люди, которые специально лазят в свободное (или оплачиваемое) время по сайтам и выискивают запрещенку, опасную для граждан РФ? И борются за мое здоровье, и оно кому-то не безразлично.
"Финальное слово про Laravel Nova." По поводу админок в PHP: все они появляются, а затем умирают. Честно говоря, если уж хотите адинку - возьмите Django. Развивается с 2005 года (сколько админок на PHP умерло с того года, а сколько "мало поддерживается"), достаточно хорошо кастомизируется (шаблоны, кастомные поля, роуты и т.д.), много плагинов, сильное коммунити (много коммитов и контрибьюторов), совместима с последними версиями Python и его библиотеками. Я прям не знаю админки на PHP, которая могла бы поспорить по этим показателям с этой админкой, только CMS'ки вроде Wordpress могут поспорить, но это немного другой подход к разработке уже. Пишу просто для информации, может кому поможет.
чистит данные от мусора, ( intervolga@gmail.ru -> intervolga@gmail.com )
ведет учет остатков,
взаимодействует с десятком учетных систем,
cтроит отчеты партнеров на сайте
middleware хранит цены для нужных товаров для текущего пользователя
проверяет наличие договоров и их условия, запоминает рассчитанные данные и возвращает результат на сайт
анализирует цены от разных поставщиков
Что вы нам тут рассказываете что вы написали одну мега-систему которая собственно делает вообще всё, что можно сделать. Вы представляете что за гигантский монолит это будет?
А какую проблему вы решаете? Чтобы сотрудники не уходили к конкурентам? Или чтобы они не уходили на более высокие зарплаты? Или чтобы сотрудник хоть что-то делал по работе? Или чтобы ничего он не делал кроме работы (100% времени посвящал работе)? Или чтобы сотрудник был активным и сам предлагал новые идеи и варианты реализации (бил как фонтан)?
Как раз по этой инструкции я и выполнял настройку.
Скажите, у вас лично был опыт запуска Hyper-V под Proxmox? Или доступа к веб-серверу расположенному на другой Guest OS из такой же Guest OS по публичному IP?
Брал dedicated сервер на proxmox и esxi. На proxmox не смог обратиться к своему же внешнему (то что дал хостер) ipшнику из гостевой ОС (хощу ферму веб серверов, хотел заходить на свои же сайты из гостевой ОС). Так же лично я не смог запустить hyper-v на гостевой windows.
Например физический (реальный) самолет сделан так, что он имеет неровности, шероховатости и неоптимальную форму. Теоретический самолет сделан так, что он не имеет недостатков. Я могу «представить» себе идеальный самолет. Или идеальный стол или стул. Они существуют, но лишь в моем уме. Теоретический самолет (или машину например или еще что-то) можно лишь вообразить в уме. Так и эти архитектурные шаблоны. Глупо/неправильно представлять в уме программу, в которой существует entity и она в невалидном состоянии. Это как представлять некрасивый стол или стул. Фантазии всегда идеальны. Если бы мы программировали «мозгом», то наверное мы смогли бы написать такой код. Но поскольку как и физический самолет мы ограничены технологиями, то реализовать «чистый код» — трудно (например можно реализовать в очень маленьких программах).
Допустим мы имеем переменную isPresent. Мы можем упростить ее до present. Но если у нас есть несколько объектов (products и filters), то уже становится непонятно, что конкретно «present» — товар или фильтр. По-этому человеку придется держать в голове к чему относится переменная: products или filters. А человек может держать одновременно в голове не более 7 вещей. По-этому название переменной present придется расширить до productsPresent (а англичане может быть добавят туда еще «are», т.к. у них так принято). Теперь держать контекст переменной present в голове не нужно.
Для появления любой новой вещи или явления необходимо взаимодействие двух или более частей. Чай появляется из взаимодействия горячей воды и листьев, а атом водорода из взаимодействия протона и электрона.
Я пока лишь додумался, что абсолютно все состоит из каких-то «опорных точек» (физики сейчас докопались вроде до кварков, а в информатике это — «бит»). Все процессы (например взаимодействие электронов осуществляется переносчиками — фотонами), все предметы — всё. Многое из статьи мне близко. Спасибо за необычную и хорошо написанную статью.
Я слышал что в Go одновременная запись в map запрещена. По-этому наверное map следует обернуть в блоки синхронизации.
Статья устарела. gorilla/mux уже год нет релизов, и пакет ищет мейнтейнера.
go-chi/chi наоборот сильно вырос, и
уже поддерживает маршруты на основе хоста.
Может и самый известный, но chi его уже сильно обогнал по возможностям. Если посмотреть структуру папок и полазить в коде, то увидим, что chi имеет гораздо больше возможностей чем mux.
Я не претендую, что chi - это то что нужно выбрать, т.к. есть и навороченнее типа gin есть и быстрее и легче.
Я считаю что в идеале код должен быть разделен на минимальные частицы, насколько это возможно.
Но мы можем "схитрить" и упростить код - взять на себя ответственность и объединить некоторые участки вместе, как это сделано в варианте 1 - get_post_for_user_id, заранее предполагая, что этот функционал тоже будет меняться вместе. Т.е. мы упрощаем архитектуру - ради повышения удобочитаемости и когнитивного восприятия кода, под собственное видение программиста каким образом бизнес будет развивать свой проект и с какими задачами на изменение бизнес будет приходить к нам (с какими "осями изменений", "линиями разреза" бизнес будет приходить к нам).
Написав метод get_post_for_user_id мы потеряли информацию.
Во-первых метод должен называться get_post_by_post_id_and_user_id. Потому что название get_post_for_user_id больше подходит для get_posts_for_user_id - когда мы достаем все посты по user_id. Еще есть за что зацепится по П.1: у нас в базе нет одной сущности post для user_id, у нас есть массив posts для user_id. Т.е. в базе есть только однозначное соответствие массива постов posts и user_id. И нет однозначного соответствия какого-то одного поста для user_id. Но может быть last_post_for_user_id, most_rated_post_for_user_id, random_post_for_user_id и т.д. В названии get_post_for_user_id теряется однозначность - какой пост мы достаем = теряется информация.
Во-вторых при применении этого метода в проверке прав доступа, при отсутствии поста (пост с post_id не существует) должна быть одна ошибка, а если post.user_id != user_id, то это уже другая ошибка. Если мы и там и там создаем одну и ту же ошибку - информация теряется. Даже если мы наружу отправляем и там и там одну - 404 ошибку, внутренняя ошибка должна быть разная (для логов, для security отдела и т.д.).
Если делить природу на живое/неживое то сложно.
А вот если относить все существующее к неживому, но неживому тупому - камень и неживому активно реагирующему на окружающие внешние изменения (человек), то получается все же наша активная реакция, которую мы называем сознанием - это очень даже клево.
А что такое ДНК? Это набор молекул, таких как углерод, гелий и т.д. А что такое молекула - это набор электронов, протонов и т.д. Давайте тогда уж мыслить на самом базовом уровне - все мы - это набор элементарных (каких-то м.б. электрон м.б. еще элементарнее) частиц. Всего лишь набор элементарных частиц. Но в том то и красота, что элементарные частицы собрались в нечто большее - ДНК. А в том тогда тоже есть красота, что ДНК собрались в нечто большее - сознание.
Неужели есть какие-то люди, которые специально лазят в свободное (или оплачиваемое) время по сайтам и выискивают запрещенку, опасную для граждан РФ? И борются за мое здоровье, и оно кому-то не безразлично.
"Финальное слово про Laravel Nova."
По поводу админок в PHP: все они появляются, а затем умирают. Честно говоря, если уж хотите адинку - возьмите Django. Развивается с 2005 года (сколько админок на PHP умерло с того года, а сколько "мало поддерживается"), достаточно хорошо кастомизируется (шаблоны, кастомные поля, роуты и т.д.), много плагинов, сильное коммунити (много коммитов и контрибьюторов), совместима с последними версиями Python и его библиотеками.
Я прям не знаю админки на PHP, которая могла бы поспорить по этим показателям с этой админкой, только CMS'ки вроде Wordpress могут поспорить, но это немного другой подход к разработке уже. Пишу просто для информации, может кому поможет.
Middleware:
чистит данные от мусора, ( intervolga@gmail.ru -> intervolga@gmail.com )
ведет учет остатков,
взаимодействует с десятком учетных систем,
cтроит отчеты партнеров на сайте
middleware хранит цены для нужных товаров для текущего пользователя
проверяет наличие договоров и их условия, запоминает рассчитанные данные и возвращает результат на сайт
анализирует цены от разных поставщиков
Что вы нам тут рассказываете что вы написали одну мега-систему которая собственно делает вообще всё, что можно сделать. Вы представляете что за гигантский монолит это будет?
Скажите, у вас лично был опыт запуска Hyper-V под Proxmox? Или доступа к веб-серверу расположенному на другой Guest OS из такой же Guest OS по публичному IP?
per layer:
import{ fetchMostPopularComment } from '@/api/comment';
import { dispatchSetMostPopularComment } from '@/state/comment';
per feature:
import { fetchMostPopularComment } from '@/comment/api';
import { dispatchSetMostPopularComment } from '@/comment/state';
вроде разница не очень заметная (а она и не должна быть заметной в том коде, что я привел). Можете пояснить по подробнее пожалуйста.
Я пока лишь додумался, что абсолютно все состоит из каких-то «опорных точек» (физики сейчас докопались вроде до кварков, а в информатике это — «бит»). Все процессы (например взаимодействие электронов осуществляется переносчиками — фотонами), все предметы — всё. Многое из статьи мне близко. Спасибо за необычную и хорошо написанную статью.
я так полагаю, что абсолютно любое изменение от бизнеса требует ровно O(1) трудозатрат изменений в коде
Может сеньер это тот человек, который знает что возможно сделать, а что — нет?