В мире где все бесплатно качается с торрентов действительно трудно обосновать работодателю обучение. Вот когда люди будут платить реальные бабки, действительно обоснование типа "мое обучение усилит команду" будет работать. Сколько не проходил курсов, точно могу сказать - обучение реально усиливает члена команды.
Куча готовых компонентов. Например получить весь список контактов - стандартная задача. На Flutter не придется писать ничего, т.к. уже есть готовый модуль. На нативе такого маркетплейса модулей нет, и пишется уникальный код. С bluetooth - аналогичная ситуация ну и т.д.
Flutter предоставляет лишь возможность строить UI. Все что нужно делать с API устройства - доступ к контактам, музыкальным альбомам, к геолокации, bluetooth, все все все остальное - нужно делать на нативе. Т.е. на Java/Kotlin или Objective-C/Swift. Flutter предоставляет лишь тонкую прослойку, которая позволяет выполнить код на нативном для платформы языке и получить результат на стороне Flutter. Т.е. платформенного кода очень много. Каждый готовый компонент на Flutter - это тонкая прослойка на Flutter + много нативного кода. Но большинство компонентов уже написано, по-этому может быть что и не придется писать ни строчки нативного кода в типовом проекте.
Стоит отметить что Oracle надежнее PostgreSQL: в Oracle Redo logs (запись журнала изменений транзакций, в который пишутся данные до того как запишутся в базу, который и гарантирует возможность восстановления в случае отключения электричества) можно распараллелить, и в случае потери 1 файла система все равно продолжит работать. В PostgreSQL на уровне базы данных распараллелить Wal log нельзя (Wal log - это тот же самый Redo log из Oracle). По-этому если ты потеряешь файл ты можешь потерять и часть данных.
Cron задачи и брокер сообщений успешно дополняют друг друга. Например у нас подключена внешняя CRM в облаке (нет доступов к исходникам) и мы каждую минуту проверяем не пришли ли туда новые заказы (CRM не умеет ставить задачи в очередь). При этом свои заказы в CRM экспортируем через задачи в брокере.
В Go есть массивы. Они жестко заданы по размеру. Срез - это указатель на массив, который может изменять свой размер и "бегать" своим начальным указателем по массиву в пределах нижележащего массива. Например на массив из 5 элементов можно создать срез [0:3] - элементы массива 0,1,2, но затем этот же срез переделать на [3,5] - элементы 3, 4. Но под срезом внутри всегда находится массив. Изменяя элемент среза мы изменяем элемент массива. Но в срез можно и добавить элементы, тогда автоматически создастся новый массив, в него скопируются элементы из старого массива и вернется новый указатель на новый массив, этим и занимается функция append.
Статья устарела. 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 и она в невалидном состоянии. Это как представлять некрасивый стол или стул. Фантазии всегда идеальны. Если бы мы программировали «мозгом», то наверное мы смогли бы написать такой код. Но поскольку как и физический самолет мы ограничены технологиями, то реализовать «чистый код» — трудно (например можно реализовать в очень маленьких программах).
В мире где все бесплатно качается с торрентов действительно трудно обосновать работодателю обучение. Вот когда люди будут платить реальные бабки, действительно обоснование типа "мое обучение усилит команду" будет работать. Сколько не проходил курсов, точно могу сказать - обучение реально усиливает члена команды.
Куча готовых компонентов. Например получить весь список контактов - стандартная задача. На Flutter не придется писать ничего, т.к. уже есть готовый модуль. На нативе такого маркетплейса модулей нет, и пишется уникальный код. С bluetooth - аналогичная ситуация ну и т.д.
Flutter предоставляет лишь возможность строить UI. Все что нужно делать с API устройства - доступ к контактам, музыкальным альбомам, к геолокации, bluetooth, все все все остальное - нужно делать на нативе. Т.е. на Java/Kotlin или Objective-C/Swift. Flutter предоставляет лишь тонкую прослойку, которая позволяет выполнить код на нативном для платформы языке и получить результат на стороне Flutter. Т.е. платформенного кода очень много. Каждый готовый компонент на Flutter - это тонкая прослойка на Flutter + много нативного кода. Но большинство компонентов уже написано, по-этому может быть что и не придется писать ни строчки нативного кода в типовом проекте.
Стоит отметить что Oracle надежнее PostgreSQL: в Oracle Redo logs (запись журнала изменений транзакций, в который пишутся данные до того как запишутся в базу, который и гарантирует возможность восстановления в случае отключения электричества) можно распараллелить, и в случае потери 1 файла система все равно продолжит работать. В PostgreSQL на уровне базы данных распараллелить Wal log нельзя (Wal log - это тот же самый Redo log из Oracle). По-этому если ты потеряешь файл ты можешь потерять и часть данных.
Cron задачи и брокер сообщений успешно дополняют друг друга. Например у нас подключена внешняя CRM в облаке (нет доступов к исходникам) и мы каждую минуту проверяем не пришли ли туда новые заказы (CRM не умеет ставить задачи в очередь). При этом свои заказы в CRM экспортируем через задачи в брокере.
В Go есть массивы. Они жестко заданы по размеру. Срез - это указатель на массив, который может изменять свой размер и "бегать" своим начальным указателем по массиву в пределах нижележащего массива. Например на массив из 5 элементов можно создать срез [0:3] - элементы массива 0,1,2, но затем этот же срез переделать на [3,5] - элементы 3, 4. Но под срезом внутри всегда находится массив. Изменяя элемент среза мы изменяем элемент массива. Но в срез можно и добавить элементы, тогда автоматически создастся новый массив, в него скопируются элементы из старого массива и вернется новый указатель на новый массив, этим и занимается функция append.
Когда ряд последовательно идущих параметров функции имеют одинаковый тип, то тип для них всех можно указывать 1 раз после последнего параметра.
Я слышал что в 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?