на 1

тогда на 6 где-то

Пройти за выходные tour.golang.org будет достаточно чтобы не ссать

а если еще и https://golang.org/doc/effective_go.html то вообще отлично

особенно у юниоров

ха, я первые пару недель с gobyexample не расставался, постоянно синтаксис из головы вылетал

в самоотверженности

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

ну и не нужно переживать изначально, что ничего не понимаешь, у нас например онбординг 6 недель, в течении которых ты вливаешься и делаешь всякие простые вещи

это может стать проблемой

У меня будет месяц, чтобы более-менее освоиться. Думаю, это время уйдёт на чтение gobyexample, effective go и книги Кернигана. Только вот в конечно итоге из меня хотят сделать ФУЛЛ-СТЕК. Придётся параллельно изучать Angular2. А фронт-енд никогда не входил в число моих любимых занятий.

Обязательно ангуляр или есть выбор?

Обязательно Angular, обязательно второй. Эх

Сочувствую... там все бы ничего, но дёрти чекинг это тотальное зло

Сочувствую... там все бы ничего, но дёрти чекинг это тотальное зло

Поясни

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

Обязательно Angular, обязательно второй. Эх

Пока что для меня это все незнакомо. Я твоё сообщение сохранил, когда хоть немного проникнусь, так сказать, фронт-ендом, перечитаю. Дерево рендера - ты имеешь ввиду DOM? И его рендеринг?

Ребят, нужно регистрировать много мейлов я вот хз как реализовать мб есть какой то сервис?

keytag пусть будет uint32

ну тогда я вижу в rfc откровенный бред

А можно линк?

ну тогда я вижу в rfc откровенный бред

Дык unsigned long зависимости от всего может быть как 32, так и больше

Там кстати это написано

и? что это меняет в конкретном месте в контексте итоговых двух строчек?

Если ac больше 32 бит, то это имеет смысл Если ровно 4 байта - то конечно нет

какой смысл?

Если они про переполнение, то почему не ac = ac & 0xFFFF + (ac >> 16) & 0xFFFF;

Если ac - 64 бита, то при сдвиге у нас будет 16 бит нулевых, а потом 48 бит с неизвестными значениями Нас интересуют только 16 младших, собственно за этим и нужно & 0xFFFF

это не эквивалентно ac += (ac >> 16) & 0xFFFF; return ac & 0xFFFF;

стоп. но у нас первое слагаемое один фиг с мусором

Ну да И из этого мусора нам важны только биты с 8-15

естественно return такой же остается в коде

Да не в return дело код ac = ac & 0xFFFF + (ac >> 16) & 0xFFFF; не то же самое, что ac = ac + (ac >> 16) & 0xFFFF;

ну. это верно для обоих слагаемых. почему для второго сделано исключение?

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

Я неправильно выразился Судя по RFC нам нужно прибавить к ac значение в битах 8-15

А меня одного смущает эта строка? ac += (i & 1) ? key[i] : key[i] << 8;