Если бы gorilla-mux так и был бы в архиве, то это еще имело бы смысл. Chi-хорош для просто отображения контента, но с сессиями, куки, websocket и иными взаимодействиями ему не хватает функций, поэтому и костылят как кто может.
На счет gorilla-mux в архиве:
С декабря 2021 года, одна из наиболее разнообразных по функционалу библиотек gorilla-mux (и её дополнения) искали нового поддерживающего (issue-659). В течении года, не найдя того, кто бы реально взял бы на себя обязательства, поддерживающие проекта решили его заархивировать.
Для использующих эту библиотеку (в частности меня) - это было новостью и неприятной. Полагаю, в тот момент был бум активности для Chi. Да, по скорости она была впереди gorilla-mux, но уступала ей в функциональной обвязке (смотри репозитории проекта).
Спустя около полугода нашлись энтузиасты и проект был возвращен из архива и продолжает развитие и закрытие багов.
----------
Относительно поста - ну как еще одна библиотека - ок, но как функциональный фреймворк для более чем одностраничника - не рекомендую.
Если упрощать, то tacs в основном используется для выгрузки данных откуда-то и подстановки их куда-то (я изучал HELM, когда решил сделать TACS). Изначально предполагалось, что для каждого выгружаемого параметра требуется отдельное LDAP поле (ориентируясь на LDAP и массовость).
Специфичных функций для анализа и обработки в шаблонизаторе нет, но они и не нужны, ведь у нас есть JavaScript движок из самого Thunderbird (а сама конфигурация является js-скриптом).
У нас используется максимум 2 ящика с разных серверов, а значит в шаблоне у нас будет проверка:
{{ if .twoEmail }} /*добавляем второй ящик со специфичными параметрами*/ {{ end }}
Рассмотрим ситуацию, что ящиков у нас может быть переменное число, а доменов и подавно, при этом мы не ходим захламлять множество полей LDAP по одному значению.
Вспоминаем, что у нас есть полноценный JS, а потому пишем функции для настройки ящика для каждого типа серверов, которыми будем пользоваться:
{{ define "libs"}}
function server1(email, name, etc){
pref(anything1,name);
pref(anything2,email);
pref(anything3,etc);
}
function server2(email, name, etc){
pref(anything1,name);
pref(anything2,email);
pref(anything3,etc);
}
{{end}}
В LDAP выделяем поле с текстом и в формате JSON прописываем требуемые ящики и сервера:
В шаблоне, присваиваем эту строку в переменную (я так уже делал), а дальше просто анализируем с помощью JS и вызываем соответствующие функции:
{{define "base"}}
// [{"email":"user1@example.com","server":"server1"},{"email":"user2@example.ru","server":"server2"}]
var list = {{.mailList}};
list.forEach((elem)=>{
switch(elem.server){
case "server1":
server1(elem.email,name,etc);
break;
case "server2":
server2(elem.email,name,etc);
break;
default: console.log("anything");
}
})
{{end}}
Исходя из этого мы получим неограниченное число ящиков для каждого домена с индивидуальными параметрами.
Прошу обратить внимание, что я не тестировал описанное выше и моё решение основывается на знании того, что так в принципе можно сделать, а потому в процессе реализации могут потребоваться незначительные корректировки.
Вводят излишние усложнения в язык, забросив в полурабочем состоянии остальное - например плагины.В виде отдельно библиотеки не собрать, зависимость от окружающей среды сборки и основного кода, отсутствие поддержки Windows (issues-19282, 7 лет проблеме!).
Если пользователь состоит в нескольких группах ldap, то будет применен первая совпавшая группа из списка конфигурации, о чем сказано в ReadMe, help и коде.
Если пользователю потребуется несколько ящиков(а у нас такая ситуация так же имеется) - создаётся шаблон конфигурации thunderbird, описывающий 2 ящика, вместо одного.
Создаётся группа для двух ящиков и пользователи, которым это надо- перемещаются в неё
Я пишу из своих рабочих достижений, которыми можно поделиться (т.е. они не узко-внутренние). При таком подходе, частота выхода статей получается не раз в неделю, зато я считаю их гораздо полезнее, чем сотня пустышек "об использовании какой-нибудь популярной библиотеки" или белиберда "о типах разработчиков".
go- для монолитного приложения, микросервиса, т.к. в нем отвратительная система плагинов (разделяемых библиотек). Пока что скудная реализация графической части - всего несколько библиотек отрисовывающих нативные графические интерфейсы.
C#- точно нужен при работе с unity, gamedev; знаю, что он хорошо себя чувствует с отрисовкой графики на windows, хотя net есть и для linux
А для повышения уровня эргономики, этот же джойстик будет использоваться и для управления другими важными функциями, например такими как громкость магнитолы и температура подогрева сидения.
Для базовой теории (с созданием простенькой сетки разбора почерка), рекомендую прочитать "Создаем нейронную сеть" Тарик Рашид (пример). Большая часть книги - это математические основы, но они дают базу для понимая происходящих процессов
На примере последнего набора - ничего оригинального придумано не было, а нейросети на подобных изображениях и обучались. Если бы в задаче реально были описаны некие абстрактные чувства, то результаты могли бы быть различными
Первый критерий запрошенный на капче - самое большое животное. На картинках есть белки, ёжики, птицы и собаки - среди существ, самое большое из них была бы собака.
Второй критерий - рядом с текстовым запросом ставится картинка-пример, на которой изображена собака.
В тексте не указано, кликните по самому большому изображению с живым существом.
Итого: нужно было выбрать изображения собак, а автору нужно потренироваться с логическими задачками
Работаю во внутренней техподдержке и у наших пользователей зоопарк разных линуксов и windows. При обновление основного образа debian или внесении неких локальных изменений постоянно возникала проблема обновления уже имеющихся систем. До этого использовался ansible, но его проблема - если пк нет в сети, обновления не будет, а чем больше не полученных изменений - тем хуже и проще перезалить пк с нуля.
Задался вопросом централизации конфигурации - все настройки лежат на сервере, агент с пк должен подключаться к нему, выгружать и применять их. Были рассмотрены и опробованы:
ansible-pull - жирно по весу, отсутствие контроля за состоянием системы (никаких данных по умолчанию не присылает). Для пользовательского пк не подходит
Puppet - была установка сервера с foreman и агенты на пк. С первого взгляда устраивало всё, функционал работал, но возникли первые проблемы:
Puppet шифрует соединение выпуском ssl сертификатов в своём личном центре сертификации. Его же использует для web-интефейса, а следовательно подключение к web интерфейсу изначально недоверенное. Замена его на корпоративный wildcard сертификат, с последующим обновлением, оборачивается долгими развлечениями с тонкими настройками сервиса, который представляет из себя мутанта из apache и perl (? не помню точно), так, чтобы и web-интерфейс работал и агенты имели возможность подключения к сервису по старому серту. При обновлении сервиса все настройки конечно могут успешно отвалиться и начинать можно с нуля.
Всё тот же ЦС используется для выпуска ssl-сертификатов для агентов на пк. Но есть нюанс - у нас есть пк внутри сети с DNS-сервером и "удаленщики" подключающиеся по vpn без dns, только с DHCP. SSL-сертификаты на IP-адрес не выпускаются. Делать костыль - резервировать для сети vpn dns имена? Проблем станет еще больше - либо обновляй ключи при подключении клиента, либо регистрируй каждый MAC в белом списке. Опять таки проблема.
Pupper DSL - после yaml, jinja2 от ansible puppet dsl смотрится необычно и придется учить его с нуля. По сути не проблема, но компетенция других членов команды расти будет медленно (я же не для себя сервис поднимаю, его еще поддерживать потомкам)
Итог - Puppet конечно хорошо если используется внутри сети с DNS, нет проблем с подменой SSL-сертификата для web-панели или iptables ограничение доступа с определенных хостов, есть навыки работы с ruby. В плане работы отзыв оставить не могу, отказался от него еще на этапе настройки сервиса, по причинам выше.
Chef - не попробовал, но в обзорах он шел под руку с puppet. Причина - сначала деньги, потом - тапки.
SaltStack - начинаю строить систему сейчас на нём. Плюшки и нюансы которые уже удалось выявить:
В отличии от puppet, для безопасного подключения агент-сервер используется AES ключи. Нет страданиям с SSL для web и меж агентами на ПК. Успешная работа при наличии только ip-адреса и nat.
Структура sls-файлов в yaml-формате и адаптация после ansible проходит гораздо проще (в основной части)
Minion может работать без сервера, используя локальные файлы состояний. Пробую схему заливки пк через salt-minion, чтобы структура образа была одинакова и в момент установки и при использовании.
Для web-интерфейса использую https://github.com/erwindon/SaltGUI . Пока идет только подготовка системы про его функциональность ничего не скажу - можно подтвердить ключ агента, посмотреть состояние подключенных агентов и запустить обновление состояний. Вроде бы ОК.
Все огонь и проще- поднимается apt-ng-cacher, который через http кэширует все проходящие через него пакеты и раздает их внутри локальной сети
Если бы gorilla-mux так и был бы в архиве, то это еще имело бы смысл. Chi-хорош для просто отображения контента, но с сессиями, куки, websocket и иными взаимодействиями ему не хватает функций, поэтому и костылят как кто может.
На счет gorilla-mux в архиве:
С декабря 2021 года, одна из наиболее разнообразных по функционалу библиотек gorilla-mux (и её дополнения) искали нового поддерживающего (issue-659). В течении года, не найдя того, кто бы реально взял бы на себя обязательства, поддерживающие проекта решили его заархивировать.
Для использующих эту библиотеку (в частности меня) - это было новостью и неприятной. Полагаю, в тот момент был бум активности для Chi. Да, по скорости она была впереди gorilla-mux, но уступала ей в функциональной обвязке (смотри репозитории проекта).
Спустя около полугода нашлись энтузиасты и проект был возвращен из архива и продолжает развитие и закрытие багов.
----------
Относительно поста - ну как еще одна библиотека - ок, но как функциональный фреймворк для более чем одностраничника - не рекомендую.
Таки дисконект icq случился)
Чертовски плохой маркетинг
цены растут, качество то же самое (а зачастую хуже).
Если упрощать, то tacs в основном используется для выгрузки данных откуда-то и подстановки их куда-то (я изучал HELM, когда решил сделать TACS). Изначально предполагалось, что для каждого выгружаемого параметра требуется отдельное LDAP поле (ориентируясь на LDAP и массовость).
Специфичных функций для анализа и обработки в шаблонизаторе нет, но они и не нужны, ведь у нас есть JavaScript движок из самого Thunderbird (а сама конфигурация является js-скриптом).
У нас используется максимум 2 ящика с разных серверов, а значит в шаблоне у нас будет проверка:
Рассмотрим ситуацию, что ящиков у нас может быть переменное число, а доменов и подавно, при этом мы не ходим захламлять множество полей LDAP по одному значению.
Вспоминаем, что у нас есть полноценный JS, а потому пишем функции для настройки ящика для каждого типа серверов, которыми будем пользоваться:
В LDAP выделяем поле с текстом и в формате JSON прописываем требуемые ящики и сервера:
В шаблоне, присваиваем эту строку в переменную (я так уже делал), а дальше просто анализируем с помощью JS и вызываем соответствующие функции:
Исходя из этого мы получим неограниченное число ящиков для каждого домена с индивидуальными параметрами.
Прошу обратить внимание, что я не тестировал описанное выше и моё решение основывается на знании того, что так в принципе можно сделать, а потому в процессе реализации могут потребоваться незначительные корректировки.
Вводят излишние усложнения в язык, забросив в полурабочем состоянии остальное - например плагины.В виде отдельно библиотеки не собрать, зависимость от окружающей среды сборки и основного кода, отсутствие поддержки Windows (issues-19282, 7 лет проблеме!).
Сомнительное предложение, относительно текущих реалий, выгружать данные в иностранные сервисы, которые могут быть заблокированы по постановлению США
Если пользователь состоит в нескольких группах ldap, то будет применен первая совпавшая группа из списка конфигурации, о чем сказано в ReadMe, help и коде.
Если пользователю потребуется несколько ящиков(а у нас такая ситуация так же имеется) - создаётся шаблон конфигурации thunderbird, описывающий 2 ящика, вместо одного.
Создаётся группа для двух ящиков и пользователи, которым это надо- перемещаются в неё
Я пишу из своих рабочих достижений, которыми можно поделиться (т.е. они не узко-внутренние). При таком подходе, частота выхода статей получается не раз в неделю, зато я считаю их гораздо полезнее, чем сотня пустышек "об использовании какой-нибудь популярной библиотеки" или белиберда "о типах разработчиков".
Г
Отвратительный машинный перевод, отсутствие единой терминологии об одном предмете речи : ветка/вилка, rebase/перемещение
По моему небольшому кругозору-
go- для монолитного приложения, микросервиса, т.к. в нем отвратительная система плагинов (разделяемых библиотек). Пока что скудная реализация графической части - всего несколько библиотек отрисовывающих нативные графические интерфейсы.
C#- точно нужен при работе с unity, gamedev; знаю, что он хорошо себя чувствует с отрисовкой графики на windows, хотя net есть и для linux
А в целом- зависит от задач и целей
Глюканул ИИ - вместо поворота, сгорела жопа?
а еще можно было бы привести примеры и математическое обоснование, всех выполняемых действий, как в "Создаем нейронную сеть" Тарик Рашида
Статья - откровенный мусор и заманиловка на отличные специальные курсы!
Все кто знаком с Go (как упомянуто в начале статьи), уже по любому знакомы и с подобными крупными библиотеками, особенно, которые релизятся с 2016 года.
Всё что описано - почти полная перепечатка официальных примеров, например чат, без внесения чего либо нового или конструктивно отличающегося.
Если на курсах гоняют те же официальные примеры из документации - то они полная хрень
Для базовой теории (с созданием простенькой сетки разбора почерка), рекомендую прочитать "Создаем нейронную сеть" Тарик Рашид (пример). Большая часть книги - это математические основы, но они дают базу для понимая происходящих процессов
На примере последнего набора - ничего оригинального придумано не было, а нейросети на подобных изображениях и обучались. Если бы в задаче реально были описаны некие абстрактные чувства, то результаты могли бы быть различными
Первый критерий запрошенный на капче - самое большое животное. На картинках есть белки, ёжики, птицы и собаки - среди существ, самое большое из них была бы собака.
Второй критерий - рядом с текстовым запросом ставится картинка-пример, на которой изображена собака.
В тексте не указано, кликните по самому большому изображению с живым существом.
Итого: нужно было выбрать изображения собак, а автору нужно потренироваться с логическими задачками
Работаю во внутренней техподдержке и у наших пользователей зоопарк разных линуксов и windows. При обновление основного образа debian или внесении неких локальных изменений постоянно возникала проблема обновления уже имеющихся систем. До этого использовался ansible, но его проблема - если пк нет в сети, обновления не будет, а чем больше не полученных изменений - тем хуже и проще перезалить пк с нуля.
Задался вопросом централизации конфигурации - все настройки лежат на сервере, агент с пк должен подключаться к нему, выгружать и применять их. Были рассмотрены и опробованы:
ansible-pull - жирно по весу, отсутствие контроля за состоянием системы (никаких данных по умолчанию не присылает). Для пользовательского пк не подходит
Puppet - была установка сервера с foreman и агенты на пк. С первого взгляда устраивало всё, функционал работал, но возникли первые проблемы:
Puppet шифрует соединение выпуском ssl сертификатов в своём личном центре сертификации. Его же использует для web-интефейса, а следовательно подключение к web интерфейсу изначально недоверенное. Замена его на корпоративный wildcard сертификат, с последующим обновлением, оборачивается долгими развлечениями с тонкими настройками сервиса, который представляет из себя мутанта из apache и perl (? не помню точно), так, чтобы и web-интерфейс работал и агенты имели возможность подключения к сервису по старому серту. При обновлении сервиса все настройки конечно могут успешно отвалиться и начинать можно с нуля.
Всё тот же ЦС используется для выпуска ssl-сертификатов для агентов на пк. Но есть нюанс - у нас есть пк внутри сети с DNS-сервером и "удаленщики" подключающиеся по vpn без dns, только с DHCP. SSL-сертификаты на IP-адрес не выпускаются. Делать костыль - резервировать для сети vpn dns имена? Проблем станет еще больше - либо обновляй ключи при подключении клиента, либо регистрируй каждый MAC в белом списке. Опять таки проблема.
Pupper DSL - после yaml, jinja2 от ansible puppet dsl смотрится необычно и придется учить его с нуля. По сути не проблема, но компетенция других членов команды расти будет медленно (я же не для себя сервис поднимаю, его еще поддерживать потомкам)
Итог - Puppet конечно хорошо если используется внутри сети с DNS, нет проблем с подменой SSL-сертификата для web-панели или iptables ограничение доступа с определенных хостов, есть навыки работы с ruby. В плане работы отзыв оставить не могу, отказался от него еще на этапе настройки сервиса, по причинам выше.
Chef - не попробовал, но в обзорах он шел под руку с puppet. Причина - сначала деньги, потом - тапки.
SaltStack - начинаю строить систему сейчас на нём. Плюшки и нюансы которые уже удалось выявить:
В отличии от puppet, для безопасного подключения агент-сервер используется AES ключи. Нет страданиям с SSL для web и меж агентами на ПК. Успешная работа при наличии только ip-адреса и nat.
Структура sls-файлов в yaml-формате и адаптация после ansible проходит гораздо проще (в основной части)
Minion может работать без сервера, используя локальные файлы состояний. Пробую схему заливки пк через salt-minion, чтобы структура образа была одинакова и в момент установки и при использовании.
Для web-интерфейса использую https://github.com/erwindon/SaltGUI . Пока идет только подготовка системы про его функциональность ничего не скажу - можно подтвердить ключ агента, посмотреть состояние подключенных агентов и запустить обновление состояний. Вроде бы ОК.