@proGO

Страница 1488 из 1674
Kaspar
06.06.2018
10:53:53
https://www.youtube.com/watch?v=g4Pq4phAzoo

Alan
06.06.2018
11:31:47
помогите поставить ftp на sentos
Фтп пора хоронить...

Artem
06.06.2018
11:32:42
маштабирование нет, но когда вместо 10 серверов пыхи нужно 2 сервера с го

Google
Artem
06.06.2018
11:33:51
То расмотреть и взвестить альтернативу стоит.

Den
06.06.2018
11:46:04
Что значит такое объявление функции? func (m *MoviesDAO) FindAll() ([]Movie, error) {}

Artem
06.06.2018
11:46:35
То что это метод обьекта?

Harotobira
06.06.2018
11:54:22
Вот тут описано: https://tour.golang.org/methods/3

Денис
06.06.2018
12:26:12
Всем привет, а кто-нибудь может подсказать по парсингу ast для кодогенерации? Есть структура, допустим: type Foo struct { ID uint32 TS time.Time } Объявление структуры я нашел и иду по ее полям, печатая допустим тип каждого поля for _, field := range currStruct.Fields.List { switch v := field.Type.(type) { case *ast.Ident: //напечатать что uint32 case ВОТ_ТУТ_ВОПРОС: //напечатать что time.Time } Вот встроенные типы *ast.Ident хорошо ловит, а вот time.Time пропускает. Как его отловить?

Ilya
06.06.2018
12:54:58
Коллеги, помогите советом провинциальным разработчикам не выстрелить себе в ногу. Разбиваем монолит (php, кластер из 10 машин) на сервисы (не микро), пока выделено 3 отделных сервиса и один из них начал использовать 2 базы данных, вторая база от другого сервиса в котором он был изначально. Мы пришли к тому, что нам нужна шина для связи всех сервисов (event bus), Сегодня после 3-х часового планирования поняли, что никто не знает как построить надежную шину и на каких технологиях чтобы потом это не превратилось в хрустальный домик который развалится от любого чиха и в нашем городе нет специалистов с таким опытом. Система в среднем генерирует 3 события в секунду и важны надежность доставки, ни к коем случае нельзя терять данные, и идемпотентность. Да, на go переписываем аутентификацию

Anton
06.06.2018
13:11:51
Коллеги, помогите советом провинциальным разработчикам не выстрелить себе в ногу. Разбиваем монолит (php, кластер из 10 машин) на сервисы (не микро), пока выделено 3 отделных сервиса и один из них начал использовать 2 базы данных, вторая база от другого сервиса в котором он был изначально. Мы пришли к тому, что нам нужна шина для связи всех сервисов (event bus), Сегодня после 3-х часового планирования поняли, что никто не знает как построить надежную шину и на каких технологиях чтобы потом это не превратилось в хрустальный домик который развалится от любого чиха и в нашем городе нет специалистов с таким опытом. Система в среднем генерирует 3 события в секунду и важны надежность доставки, ни к коем случае нельзя терять данные, и идемпотентность. Да, на go переписываем аутентификацию
ну с 3 событиями в секунду и кролик справится хорошо

Ilya
06.06.2018
13:16:02
ну с 3 событиями в секунду и кролик справится хорошо
А как быть если шина упадет на минуту и продюсер не сможет отправить данные? Данные нельзя терять

Artem
06.06.2018
13:16:15
если честно при отсусвтие опыта максимум надежности я бы в базу писал бы

Google
Roman
06.06.2018
13:16:33
Чем не устраивает python(django), php(wordpress, laravel, symfony, yii2)?
а какие конкретно (именно конкретно) проблемы вы видите в использовании Go для реализации веб-магазина?

Anton
06.06.2018
13:16:56
если честно при отсусвтие опыта максимум надежности я бы в базу писал бы
а если база упадет, а продюссер не успеет данные отправить?

это был сарказм конечно

Artem
06.06.2018
13:17:23
у нас реализована запись в базу на уровне 3 раза пытается писать, нет пишет в файл, дальше считывает из него

как поднялась

Anton
06.06.2018
13:17:32
Artem
06.06.2018
13:17:49
что бы потерялись данные надо что бы умер и демон и база

Ilya
06.06.2018
13:18:18
продьюсер должен быть устойчивым к потере коннекта
Куда он должен девать данные если такое произойдет?

Artem
06.06.2018
13:18:18
и то еще и файловая система должна навернутся

Anton
06.06.2018
13:18:51
Куда он должен девать данные если такое произойдет?
он должен ждать, или как писал выше человек, сохранять в файл

Anton
06.06.2018
13:19:55
и вообще, когда много компонентов в системе общаются, network failure - это первое, о чем нужно подумать

А если продюсер stateless?
тут надо решать, или передавать кому-то что-то и уметь переживать сетевые проблемы, или никому ничего не передавать))

Ilya
06.06.2018
13:21:09
ну с 3 событиями в секунду и кролик справится хорошо
У нас 2 оснновных кандидата на роль брокера это rabbit и nsq, rabbit уже используется в системе

Artem
06.06.2018
13:21:56
rabbit или тарантул, но с вашими требованиями к надежности это надо уметь готовить

Anton
06.06.2018
13:21:59
кролик достаточно гибкий в настройке и в выборе подходов в передаче сообщений, с nsq не работал

насчет nsq у них в доках написано, что: messages are delivered at least once messages received are un-ordered

Ilya
06.06.2018
13:23:52
кролик достаточно гибкий в настройке и в выборе подходов в передаче сообщений, с nsq не работал
Коллеги из соседней конторы перешли с рэббита на nsq мотивирую тем, что rabbit плохо себя ведёт при большом объёме сообщений. Ну и сегодня это 3 rps а через пару лет это 300 или больше

Anton
06.06.2018
13:24:52
300 rps и больше один инстанс кролика держит абсолютно спокойно + кролик-кластер можно поднять

кролик не любит большие payload

Google
Anton
06.06.2018
13:25:15
а не rps

Alan
06.06.2018
13:25:43
+ за клустер кролика

Ilya
06.06.2018
13:26:00
Ок, будем иметь ввиду, rabbit вроде бы и так в кластере

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

Artem
06.06.2018
13:27:56
тарантул и проганье на луа?

или уже за шиной это решать

Ilya
06.06.2018
13:28:50
Мы думали о тарантуле, но в плане кэша

Anton
06.06.2018
13:30:42
А как быть с идемпотентностью если вдруг сбился порядок событий в шине?
ну сбиться он может по вине продьюсера, не брокера (по крайней мере в кролике, nsq не гарантирует порядок), так что решать надо будет проблему на стороне консьюмера

Ilya
06.06.2018
13:32:52
Отлично, может ещё какой-нибудь литературы по теме шин и сервисной архитектуре посоветуете?

Anton
06.06.2018
13:33:58
Отлично, может ещё какой-нибудь литературы по теме шин и сервисной архитектуре посоветуете?
ну вот отсюда можно поплясать: http://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageBus.html

Anton
06.06.2018
13:35:18
ну и там дальше в гугл на тему ESB

Ilya
06.06.2018
13:35:46
Ок, спасибо, надеюсь нас не разгонят после спринта

John
06.06.2018
13:39:22
Ок, спасибо, надеюсь нас не разгонят после спринта
Если чо, тут еще есть канал с работой по соседству :)

Ilya
06.06.2018
13:42:46
Если чо, тут еще есть канал с работой по соседству :)
Рано или позно, но он точно пригодится :)

Артем
06.06.2018
13:45:39
А как быть с идемпотентностью если вдруг сбился порядок событий в шине?
в rabbitmq порядок соблюдается только при попадании в конечную очередь то есть при "путешествии" события во внутренней маршрутизации по exchange порядок может меняться можете посмотреть на kafka - там порядок сообщений вроде соблюдается с самого начала

только конечно никто не отменял гонки в ваших собственных сервисах

Артем
06.06.2018
13:48:11
хотите однозначный порядок - делайте "сервис идентификаторов" как бы это смешно ни звучало и централизованно выдавайте id события сервисам

Google
Ilya
06.06.2018
13:48:47
в rabbitmq порядок соблюдается только при попадании в конечную очередь то есть при "путешествии" события во внутренней маршрутизации по exchange порядок может меняться можете посмотреть на kafka - там порядок сообщений вроде соблюдается с самого начала
Я имел ввиду, что порядок может нарушиться если вдруг по какой-то причине отправка сообщения зафэйлится в продюсере и до ретрая успеет проскочить другое сообщение. Но про порядок в эксченжах хорошее замечание

Eugene
06.06.2018
14:27:49
Всем привет. Мы ищем golang-разрабов на удаленку, тут можно написать или есть отдельная группа про работу?

Eugene
06.06.2018
14:29:03
Спасибо!

Dmitri
06.06.2018
14:37:15
но почему-то не могу соединиться
Фтп - он такой... Тебя файер режет, т.к. порты закрыты

sudo scp -r -i /key /from user@host:/to/
А sudo тут при чем? И почему пути абсолютные?

Admin
ERROR: S client not available

Dmitri
06.06.2018
14:44:17
Нет, не режет
Уверен? conntrack? Или порты посечены?

Artem
06.06.2018
14:44:26
кто нить пользовал вот это ?https://github.com/hoisie/web

Danil
06.06.2018
14:44:28
Я уже подключился

Artem
06.06.2018
14:44:41
не могу чот понять как подкючить к ней middleware какой нить чтобы авторизация работала

Danil
06.06.2018
14:46:13
А не думал ли ты вначале

Поебаться с стандартной библиотекой?

Artem
06.06.2018
14:46:48
да чот нет

я набрал в гугле golang web framework rest

Dmitri
06.06.2018
14:48:38
Вот зря ты не предался со стандартной библиотекой

Artem
06.06.2018
14:48:54
ладно предамся

Dmitri
06.06.2018
14:48:56
Автозамена шарит

Google
FRD Official - Dmitriy
06.06.2018
15:02:29
А как быть с идемпотентностью если вдруг сбился порядок событий в шине?
В payload заводите поле sequence и инкрементируете для каждого сообщения. Ввводите дополнительно два типа сообщений reset_sequence по которому ноды сбрасывают счетчик и sequnce_error по которому ноды сообщают о потере сообщения, заведете такую байду и кролик будет ненужен (вобщем-то он не особо нужен)

Vadim
06.06.2018
15:54:58
Ребят, я тут смотрю проекты, а что keccak нигде не используют?

Все на sha2

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

Subbotin
06.06.2018
16:08:47
К sha1 гугл на куче железа сделал коллизию второго рода. этого конечно тоже плохо но это даже не коллизия первого рода. а sha2 мало того что в полтора раза длиннее но и на 10 лет развития криптоанализа более продвинутее

Dmitri
06.06.2018
16:27:43
К sha1 гугл на куче железа сделал коллизию второго рода. этого конечно тоже плохо но это даже не коллизия первого рода. а sha2 мало того что в полтора раза длиннее но и на 10 лет развития криптоанализа более продвинутее
Кто-то может пояснить разницу? Стойкость к коллизиям первого рода: для заданного сообщения M должно быть практически невозможно подобрать другое сообщение N, для которого H ( N ) = H ( M ) Стойкость к коллизиям второго рода: должно быть практически невозможно подобрать пару сообщений ( M , M ′ ), имеющих одинаковый хеш.

Subbotin
06.06.2018
16:38:23
ну типа в первом случае у тебя есть сообщение (например какой-то документ или коммит в гит, где кстати sha1) у которого есть такая-то хэшсума. ты хочешь его подделать и сделать другую пдфку или другой коммит с той же чексуммой. чтобы например подложить кому-то не настоящий пдф. а он поверил что пдф настоящий. во втором случае ты сам делаешь ОБА документа с разным содержанием но одинаковой чексуммой. в таком случае ты грубо говоря можешь подкручивать оба файла. и сперва например опубликовать один документ а потом подменить его на другой.

не знаю как короче объяснить

Dmitri
06.06.2018
16:39:43
ну... оба выражения это ДВА разных документа с одной суммой

и первое и второе

Subbotin
06.06.2018
16:42:07
ну да. и? что непонятно то?

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

Bogdan (SirEdvin)
06.06.2018
16:51:44
ну... оба выражения это ДВА разных документа с одной суммой
Разница в том, что для коллизии первого рода нужен только хеш, а для второго и хеш и документ. А сам документ обычно получить значительно сложнее, чем хеш.

Человек
06.06.2018
17:44:27
Здравствуйте. Кто подскажет как можно одноразово запустить файл? Нужно показать приятелю программу, но нужно сделать так чтоб он больше ею не смог воспользоваться.

Dmitri
06.06.2018
17:45:09
ну сделай проверку по времени?

что б не мог запустить после завтра?

Человек
06.06.2018
17:47:16
ну сделай проверку по времени?
чтоб вообще не смог больше никогда запустить

Dmitri
06.06.2018
17:47:44
чтоб вообще не смог больше никогда запустить
ну если дата после завтра то return

Страница 1488 из 1674