там может нормальный брокер очередей нужен

NATS Streaming же все еще не умеет в кластерность... или уже научили?

а я кидал недавно, sandglasses, по описанию огонь!

https://github.com/celrenheit/sandglass

для пет проекта огонь, для прода нет

какой пет не мечтает выйти в прод?

нужно больше входных данных в вопросе :)

какой прод не состоит целиком из петов :)

мне кажется, это была просто попытка набросить на вентилятор :)

А так, Я согласен, что kafka весьма специфична, и новичку лучше взять кроля

NATS Streaming же все еще не умеет в кластерность... или уже научили?

Streaming clustering with full replication of data across a set of streaming servers is planned for later this year. чуть подождать)

новичку можно брать что угодно, т.к. у него пока нет понимания во что он упрется :)

я эту надпись уже больше года вижу

jq - и любой джисон как на ладони

любая команда - любой формат как ладони )

новичку можно брать что угодно, т.к. у него пока нет понимания во что он упрется :)

Ну, что угодно весьма обширный термин ... тут главное не вляпаться ))

в конце прошлого года выбирал MQ как раз

я эту надпись уже больше года вижу

?

соглашусь что кролик чуть проще кафки для старта, тонкости начинаются когда хочется пихать МНОГА и чтоб оно не падало :)

ну чтобы кролик начал падать, туда надо уже десятки тысяч в секунду писать

ну чтобы кролик начал падать, туда надо уже десятки тысяч в секунду писать

не обязательно, достаточно не особо сильного железа

любая команда - любой формат как ладони )

не любая и не любой )

у меня на самом слабом DO инстансе иногда падает, хотя там от силы 3-4к в минуту

именно, а лучше под лям, тогда сразу остается только кафка :)

не любая и не любой )

вопрос в организации тестирования

1 раз пишется метод

и все что угодно выводится читабельным

не обязательно, достаточно не особо сильного железа

ну так на кафку еще сильнее импакт будет. джавка же

один раз пишется - второй раз переписывается, третий раз фиксится с джисономписать ничего не надо

ну так на кафку еще сильнее импакт будет. джавка же

Ды, все так

вопрос в организации тестирования

и это вообще вопрос не про тестирование

и это вообще вопрос не про тестирование

не тестирования? те какой-то человек глазами что-то там проверяет на проде - что за чушь?

не тестирования? те какой-то человек глазами что-то там проверяет на проде - что за чушь?

про прод ты зачем сюда вставил? или ты всегда отлаживаешь на проде?

про прод ты зачем сюда вставил? или ты всегда отлаживаешь на проде?

как будто отлаживать на проде что-то плохое ))

про прод ты зачем сюда вставил? или ты всегда отлаживаешь на проде?

о замечательно. теперь тестирование и отладка это совсем разные вещи, которые никак не пересекаются

о замечательно. теперь тестирование и отладка это совсем разные вещи, которые никак не пересекаются

тестирование != отладка

как будто отлаживать на проде что-то плохое ))

как будто русская рулетка плохое развлечение ))

тестирование != отладка

если у меня написан тест. во время разработки я его запускаю - я тестирую или отлаживаю?

как будто русская рулетка плохое развлечение ))

Шаришь ;)

если у меня написан тест. во время разработки я его запускаю - я тестирую или отлаживаю?

ты правда не понимаешь разницы между отладкой и тестированием или просто поспорить хочется а темы нет?

ты правда не понимаешь разницы между отладкой и тестированием или просто поспорить хочется а темы нет?

не отвечать на конкретный вопрос - это очень здраво.

если у меня написан тест. во время разработки я его запускаю - я тестирую или отлаживаю?

Отлаживаешь, а когда вводишь новую фичу, ты тестируешь

А вообще, тыж программист

Сам должен все знать

Отлаживаешь, а когда вводишь новую фичу, ты тестируешь

а если я не ввожу фичу, а правлю старое? А если тот же тест запускает тестировщик из какой-нить среды?

а если я не ввожу фичу, а правлю старое? А если тот же тест запускает тестировщик из какой-нить среды?

зачем ты бредишь? тесты - тестируют. отладка поиск бага.

а если я не ввожу фичу, а правлю старое? А если тот же тест запускает тестировщик из какой-нить среды?

Правишь баги? Значит фикчишь, если нет то оптимизируешь/рефакторишь

а если я не ввожу фичу, а правлю старое? А если тот же тест запускает тестировщик из какой-нить среды?

А если тестировщик то он молодец:))

зачем ты бредишь? тесты - тестируют. отладка поиск бага.

сорян, но я просто пытаюсь выяснить твою логику. у меня есть тесты, они подготовливают условия запуска кода с различными условиями и запускают этот код, ждут определенный результат. это тесты, но они помогают найти ошибки в test-driven девелопмент. инструментарий в них пишется 1 раз, затем с разными наборами данных они гонятся, с помощью них выводятся различные данные, а также ищутся баги, замеряются метрики.. я что-то новое говорю? так большинство серьезных либ на го написано

сорян, но я просто пытаюсь выяснить твою логику. у меня есть тесты, они подготовливают условия запуска кода с различными условиями и запускают этот код, ждут определенный результат. это тесты, но они помогают найти ошибки в test-driven девелопмент. инструментарий в них пишется 1 раз, затем с разными наборами данных они гонятся, с помощью них выводятся различные данные, а также ищутся баги, замеряются метрики.. я что-то новое говорю? так большинство серьезных либ на го написано

ты не новое говоришь - ты просто бредишь, сорян, тесты тестируют, они не ищут баги, они говорят - работает или нет процесс отладки debugging это поиск и устранение бага

ты не новое говоришь - ты просто бредишь, сорян, тесты тестируют, они не ищут баги, они говорят - работает или нет процесс отладки debugging это поиск и устранение бага

с дебаггером можно и тест запустить

Сергей, прости, но по-моему твой уровень разработки = школьник

Сергей, прости, но по-моему твой уровень разработки = школьник

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

повторяю еще раз - тест подготавливает окружение для определенного срабатывания определенного кода. а также инструментарий. определенные ветки кода запустить не так просто. дальше этот тест запускается с отладчиком если нужен его функционал

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

процесс отладки это другое - это поиск бага, невсегда явного, но это не тестирование, мы знаем что не работает мы ищем что, как и почему именно не работает и где ошибка

повторяю еще раз - тест подготавливает окружение для определенного срабатывания определенного кода. а также инструментарий. определенные ветки кода запустить не так просто. дальше этот тест запускается с отладчиком если нужен его функционал

можешь повторить еще раз, а можешь просто подтянуть матчасть и не спорить

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

по-моему конкруктивная беседа все показывает. начиная писать всякую хрень вроде того “ты все путаешь ахахаха” вместо конкретных ответов на конкретные вопросы - уже вполне характеризует человека. Я конечно тоже скатился в эту плоскоть, но все-таки обосновал все сначала. Подтягивать матчасть конечно никогда не лишнее. Только я не теоретик, у меня есть поставленный флоу работы, проекты покрытые тестами, методики поиска багов, которые я использую и они работают. Поиск бага сводится к выяснению входных данных, далее проблемные данные пополняют список входных данных того или иного теста и запуск этого теста позволяет найти ошибку. По такой схеме я успешно поддерживаю довольно много проектов, это мне дает довольно дофига уверенности перед теоретическими троллями ?

Добрее надо быть друг к другу. И понимать что если у кого-то сделано так, не обязательно что у всех должно быть так и это правильно. Мы тут не Мартины Фауэлеры, писать бест-практисы для остальных.

Это к обоим ремарка

по-моему конкруктивная беседа все показывает. начиная писать всякую хрень вроде того “ты все путаешь ахахаха” вместо конкретных ответов на конкретные вопросы - уже вполне характеризует человека. Я конечно тоже скатился в эту плоскоть, но все-таки обосновал все сначала. Подтягивать матчасть конечно никогда не лишнее. Только я не теоретик, у меня есть поставленный флоу работы, проекты покрытые тестами, методики поиска багов, которые я использую и они работают. Поиск бага сводится к выяснению входных данных, далее проблемные данные пополняют список входных данных того или иного теста и запуск этого теста позволяет найти ошибку. По такой схеме я успешно поддерживаю довольно много проектов, это мне дает довольно дофига уверенности перед теоретическими троллями ?

Это ты типа сейчас пытаешься понтануться что крутой разработчик? Смешно. Не стоит пытаться со мной меряться у меня все равно длиннее Напомню суть твоих утверждений - человеку прочитать джейсон и протобаф одинаково легко, тестирование и отладка это одно и тоже Все обоснования есть в моих сообщениях, для больших разъяснений Википедия

Кто-то вообще тесты не пишет. Потому что код сразу пишет правильный.

Это ты типа сейчас пытаешься понтануться что крутой разработчик? Смешно. Не стоит пытаться со мной меряться у меня все равно длиннее Напомню суть твоих утверждений - человеку прочитать джейсон и протобаф одинаково легко, тестирование и отладка это одно и тоже Все обоснования есть в моих сообщениях, для больших разъяснений Википедия

в моем воркфлоу тестирование и отладка одно и то же, да.

Это ты типа сейчас пытаешься понтануться что крутой разработчик? Смешно. Не стоит пытаться со мной меряться у меня все равно длиннее Напомню суть твоих утверждений - человеку прочитать джейсон и протобаф одинаково легко, тестирование и отладка это одно и тоже Все обоснования есть в моих сообщениях, для больших разъяснений Википедия

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

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

Ты мал ещё кого то гнать)) Твоя аргументация - я крут, у меня много проектов и это мой воркфлоу Моя аргументация несколько проще - читать джейсон удобнее потому что он не бинарный Тестирование и отладка это разные процессы, даже если в твоём воркфлоу это одно и тоже, для подробностей в чем разница в Википедия ибо нет смысла сюда её копировать

А основную суть различия этих процессов я пояснил в сообщениях выше

На этом все, диалог с тобой не интересен

все что я пишу просто подтверждается в каждом ответном сообщении

ERROR: S client not available

если надо что-то выводить жсон не жсон для этого пишется тестовая среда и там это выводится в удобном виде да можно продолжать плакать что ведь когда я ищу ошибку я запускаю дебаггер и он просто выводит содержимое переменной а там байты, чем сделать удобный для разработки флоу. зато по википедии - неудобно отлаживаем отдельно, тестируем отдельно.

если надо что-то выводить жсон не жсон для этого пишется тестовая среда и там это выводится в удобном виде да можно продолжать плакать что ведь когда я ищу ошибку я запускаю дебаггер и он просто выводит содержимое переменной а там байты, чем сделать удобный для разработки флоу. зато по википедии - неудобно отлаживаем отдельно, тестируем отдельно.

Да что ты несёшь?

@twentydraft тут срутся

https://golang.org/conduct#unwelcome_behavior

Смотрел не отрываясь. Знакомый тоже хвалил. Отличный доклад.

рад стараться =)

Ребят, поясните пожалуйста. Вот я использую JWT для аутентификации пользователя. Вот отправил ему этот токен, он действует 5 минут. Что происходит через 5 минут? По идее он истекает и я теперь не даю пользователю делать что он делать должен, я его воспринимаю как гостя. Но! Не буду же я кажыде 5 минут спрашивать пароль, верно? Как этот момент вообще решается при работе с токенами?

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

вообще конечно статью бы почитать какую. jwt же разжеван, донельзя. считается хорошей практикой - давать два токена. один для аутентификации, второй - рефреш-токен.

Это понятно, но я ведь не буду каждые 5 минут пароль спрашивать, верно? А токены как я понимаю используются именно по той причине что они быстро истекают, и при получении их злоумышленник не сможет надолго получить доступ к системе

вообще конечно статью бы почитать какую. jwt же разжеван, донельзя. считается хорошей практикой - давать два токена. один для аутентификации, второй - рефреш-токен.

вот, если скажете теги по которым можно искать - буду вообще благодарен, про второй токен знаю, но как их "отделить" - пока не понятно

Впрочем спасибо, про второй токен сам не подумал, хоть и слышал, все что нужно нашел) Благодарю)

да не за что. плюс надо учитывать что jwt в целом не особо подходит для "стандартных" веб-приложений, имхо. там лучше старые добрые сесии и кукисы. а жвт для мобильного бекенда. или если какие-то микросервисы должны друг с другом "защищенно" общаться

Это я понял) Не понял только где эти самые токены хранить надо если у нас веб сервис и пользователь с фронтенда залогинился)

какие эти самые? на стороне сервера не надо токены хранить

у нас есть в итоге access token & refresh token, так? и как я понял jwt является access токеном, и мы ему верим, но есть же еще refresh token?

угу, с refresh токеном мы идем, если access-токен заэкспарился.

и получаем новый access.

и получаем новый access.

и новый refresh тоже получаем

ну и политику обновления и отзыва refresh-токена надо продумывать отдельно.

и новый refresh тоже получаем

вот тут уже кто как для себя решает

но хорошо, допустим я храню Access token в куках, и при каждом вызове страницы он отправляется, а где я храню тогда рефреш токен?

вот тут уже кто как для себя решает

вот если мы получаем его вместе каждый раз - то придумывать не надо, старый просто перестает действовать

вот если мы получаем его вместе каждый раз - то придумывать не надо, старый просто перестает действовать

рефреш-токен действует длительное время, поэтому если его угонят, то потенциального вреда от этого будет больше. а если мы каждый раз будет рефреш-токен обновлять, то потенциально мы злоумышленника не знающего пароль никогда не выкинем

поэтому я бы просто так рефреш-токены не обновлял.

рефреш-токен действует длительное время, поэтому если его угонят, то потенциального вреда от этого будет больше. а если мы каждый раз будет рефреш-токен обновлять, то потенциально мы злоумышленника не знающего пароль никогда не выкинем

вот как раз когда настоящий пользователь войдет в систему - злоумышленника сразу выкинет

именно потому что рефреш токен как я понял может быть только один на пользователя

а так, выкинет сразу как только заэкспарится экссесс-токен, если злоумышленник не угнал рефреш.

а если угнал и его тоже, то выкинет как истечет время жизни рефреш-токена

если угнал access токен - да, а если угнал рефреш что произойдет? он будет год иметь доступ?

ну я говорю, тут каждый для себя решает как правильно

рефреш - долгоживущий