Приведи пример гуев для го, которые лучше

Для начала лучше бы пример гуев на го, где нормальный функционал бы иметь...

Для начала лучше бы пример гуев на го, где нормальный функционал бы иметь...

Примера гуёв привести не могу, но вот функционал https://reqcenter.pro/wp-content/uploads/2015/07/functional.gif

Примера гуёв привести не могу, но вот функционал https://reqcenter.pro/wp-content/uploads/2015/07/functional.gif

Это что?

(простите, просто когда программисты называют функционалом то что на самом деле является функциональностью я не могу себя сдержать)

Ааа

Сори, я прост из деревни

Я думал, кто-то написал редактор латеха

?

Примера гуёв привести не могу, но вот функционал https://reqcenter.pro/wp-content/uploads/2015/07/functional.gif

ужас

Я тебе как фронтэндер скажу, у js охуенный функционал

Не путать js с es5, я конечно же про es2015

Ох и инет же к меня)

https://www.cossacklabs.com/blog/investigating-go-memory-leaks.html

кто-то еще на дельфе что-то пишет, кроме студенческих поделок? О_О

Слышал, что ядро яд на делфях до сих пор крутится. Работает не трогай ;)

Кикайте сразу

всем привет возможно нюбский вопрос опять у меня есть структура вот такого типа map[string][]string я хочу ее передать в буфферизированный канал из которого читает только одна горутина а потом модифицировать эту map и еще раз передать в тот же канал я правильно понимаю что для слайсов так делать не надо, потому что в принимающей горутине в какой то момент времени могут побиться данные?

Рекурсия с помощью каналов?

всем привет возможно нюбский вопрос опять у меня есть структура вот такого типа map[string][]string я хочу ее передать в буфферизированный канал из которого читает только одна горутина а потом модифицировать эту map и еще раз передать в тот же канал я правильно понимаю что для слайсов так делать не надо, потому что в принимающей горутине в какой то момент времени могут побиться данные?

Проще взять мьютекс для этой мапы

нет просто хочу послать в канал несколько сообщений в цикле но хочу использовать для этого один экземпляр структуры map[string][]string потому что часть ключей в map у меня постоянные а часть ключей должны обновиться но похоже надо все таки аллоцировать заново

А, горутина ж

Лучше через канал. Map это ссылочный тип. Лучше его не отправлять в канал. Лучше взять что то по значению отправить

у меня именно мапа ... потому что приходит некий набор параметров ключ-значние список ключей не фиксированный его удобнее всего в map хранить

а почему мапа ссылочный тип?? ну в смысле в качестве элемента мапы конечно может быть слайс как у меня или указатель на другой тип но сама по себе мапа разве не будет копироваться в канал? я ж не указатель на мапу в канал передал

https://play.golang.org/p/P_KkTXyqOB

Если ты передашь указатель на мапу, ты просто ее сможешь подменить полностью

А сама она есть указатель

понял =(

подскажите пожалуйста cms на го

типа друпала-вордпреса

одностраничник на реакте и сокетах

подскажите пожалуйста cms на го

из cms на го знаю только fragmenta

ага, спасибо, похоже она единственная более менее популярная

ага, спасибо, похоже она единственная более менее популярная

еще https://github.com/ponzu-cms/ponzu

Еще qor была

А вот с парсингом русскоязычных pdf-ников встречался?

А вот с парсингом русскоязычных pdf-ников встречался?

Нет Имхо вообще парсить pdf - плохая идея

Да.

Господа, а насколько ужасна идея склавдывать логи в монгу изнутри приложения?

Я один такой изврат?

А текстовая часть внутри без окольных путей лежит

Господа, а насколько ужасна идея склавдывать логи в монгу изнутри приложения?

А что не так? Имхо отлично

складывать логи в монгу изврат уж тогда складывайте в какой structured log и дальше в ElasticSearch

А что не так? Имхо отлично

Просто если зафейлится приложение, то в монгу то, что выблевалось, скорее всего не попадёт

А что не так? Имхо отлично

ну IMHO монга это все таки не про логи от слова савсем

ну то есть смотря какие у вас объемы =) до 100 гигабайт в общем то похуй куда вообще класть всегда можно отмасштабироваться ВЕРИТКАЛЬНО (железо сейчас доступно если у вас выручка в валюте ;) на размерах больше с монгой для ЛОГОВ уже наверняка придется поебаться потому что она для другого паттерна доступа

складывать логи в монгу изврат уж тогда складывайте в какой structured log и дальше в ElasticSearch

ElasticSearch ради логов? Ну как бе можно, но это типа карьерного экскаватора, когда мне нужен траншеекопатель

У меня вопрос в другом:

ElasticSearch ради логов? Ну как бе можно, но это типа карьерного экскаватора, когда мне нужен траншеекопатель

простите вам логи "зачем"? чтобы по ним потом искать и структурировать как то ?? ну так вот монга это будет делать через aggregation framework ХУЖЕ чем Elastic

У меня вопрос в другом:

делать ли это изнутри приложения или снаружи как-то ловить выхлоп, разбирать его и пихать в СУБД?

простите вам логи "зачем"? чтобы по ним потом искать и структурировать как то ?? ну так вот монга это будет делать через aggregation framework ХУЖЕ чем Elastic

Зато ES будет гарантировано дороже Для меня это важнее

делать ли это изнутри приложения или снаружи как-то ловить выхлоп, разбирать его и пихать в СУБД?

если приложение на GO возьмите нормальную какую то либу , у которой логи асинхронные https://github.com/sirupsen/logrus и логируйте сразу куда надо

Зато ES будет гарантировано дороже Для меня это важнее

в каком плане "дороже"?? ;) память и монга и еластик жрут как не в себя

в каком плане "дороже"?? ;) память и монга и еластик жрут как не в себя

По деньгам, лол У меня есть две коробки "забесплатно", на которых у нас всё крутится И если я сейчас скажу, что-то типа "давайте купим кусок облако под логи", это будет ну такое

если приложение на GO возьмите нормальную какую то либу , у которой логи асинхронные https://github.com/sirupsen/logrus и логируйте сразу куда надо

Ну ты как бы понимаешь, что: a) меня не особо интересует библиотека для логирования б) проблема не в библиотеке для логирования? :3

По деньгам, лол У меня есть две коробки "забесплатно", на которых у нас всё крутится И если я сейчас скажу, что-то типа "давайте купим кусок облако под логи", это будет ну такое

простите причем тут "облако"? apt-get install elasticsearch делается почти в слепую но в целом надо было сразу сказать "у нас уже есть Монга, мы хотим срать в нее еще и логами" =) это нормальное желание если у вас в монге уже какие то данные и вы знаете как бороться с ее недостатками то бороться с недостатками эластика вам абсолютно незачем =)

и соответсвенно городить инфраструктуру по "доставке логов" в монгу смысла нету... https://github.com/weekface/mgorus этого вполне будет достаточно =)

простите причем тут "облако"? apt-get install elasticsearch делается почти в слепую но в целом надо было сразу сказать "у нас уже есть Монга, мы хотим срать в нее еще и логами" =) это нормальное желание если у вас в монге уже какие то данные и вы знаете как бороться с ее недостатками то бороться с недостатками эластика вам абсолютно незачем =)

мдааа У меня почему-то сейчас в голове скрестились elastic search и elastic storage

и соответсвенно городить инфраструктуру по "доставке логов" в монгу смысла нету... https://github.com/weekface/mgorus этого вполне будет достаточно =)

Ладно, вы не совсем поняли мой вопрос ^3 Но спасибо за усердие

дак вроде понял =) вопрос дословно был плохо ли писать изнутри приложения логи в монгу? ответ если монга в проекте уже есть если умеете бороться с ее недостатками если сможете потом писать запросы на поиск по этим логам если приложение на GO тогда НЕТ, не плохо, ОЧЕНЬ ХОРОШО и вполне разумно или под логами имеется ввиду не логи приложения а некие write once данные ?

IMHO наверное стоит подумать не только над тем как писать логи но и что потом с ними надо делать ПОТОМ и каким именно образом и от этого уже отталкиваться

Вопрос был в следующем: "плохо ли возлагать ответственность по записи логов в СУБД (наверное зря сделал акцент на монгу) на само приложение, а не перехватывать его вывод, как-то агрегировать, обрабатывать снаружи и только потом класть в СУБД? ". То есть по сути, стоит ли мне разделять обязанности? Я повторюсь, несмотря на то, что я упомянул монгу, проблема вовсе не стоит в выборе СУБД, как и в выборе пакета для логов, а так же формата логов. Проблема именно в следующем: должно ли приложение само отвечать за запись логов в субд?

Мерль, ты про 12 factor app слышал?

Идеальный вариант это когда приложение пишет лог в stdout

А дальше ты уже решаешь, что с ним делать

если так ставить вопрос, тогда ДА, надо разделять и отдельный "доставщик" снаружи приложения

Заруливаешь его в бд, вроде эластика, или пишешь в файл или ещё что

В общем приложение не должно париться о персистентности логов

Его задача лог сгенерировать максимально простым способом

Спасибо Примерно это я и хотел услышать

(А что касается mongodb - то в данном случае асбсолютно эквиписуально, это дело всё равно потом раз в неделю анализирует специально обученный скрипт, который выставляет регулировки термостата и прочей херни)

Изопенисуально говорить надо

Будто теоркат не учил!

Не у учил, и ваще, бурбакисты не нужны и должны страдать!

Ещё один роутер, да сколько можно https://violetear.org/

Посмотрим

Смотрел я на fasthttp, такая шляпа

В ряде случаев просто не отдает контент, пока f5 не нажмешь раз 10

И стартует медленно

И игнорит некоторые http заголовки

Смотрел я на fasthttp, такая шляпа

я не смотрел его исходники, в чем там прикол? он на си вызовах?

Смотрел я на fasthttp, такая шляпа

ну-ка

Смотрел я на fasthttp, такая шляпа

а вот теперь обоснуй

Он не использует map[], он использует []byte вместо string

В заголовке даты последнего изменения статического файла отдавал утреннее время в 12 дня. Хотя файл менялся часто

Он не использует map[], он использует []byte вместо string

а ты не думал, что именно поэтому он работает адекватно?

а ты не думал, что именно поэтому он работает адекватно?

Не понял

Одно дело скорость она есть не спорю