uvelichitel
Если честно не совсем понял, что вы мне пытаетесь доказать))
nil - это нулевой адрес памяти.
var foo []uint8 равен nil по той причине, что у слайса нет внутреннего массива, на который он указывает. Точнее есть, но это нулевой адрес памяти.
[]uint8{} - вот это слайс с инициализированным внутренним массивом, именно по этой причине его внутренний указатель не равен nil
uvelichitel
А что вы ожидали? Slice внутри - это указатель на массив + длинна и емкость. Кроме того null у Golang нету.
По сути new([4]uint8)[:] значит: создать массив из четырех uint8 со значениями по умолчанию 0, на его основе создать срез и вернуть переменной slice
Skid Raw
> учусь на 5 курсе на программиста, а знания в программировании равны нулю
> Мне нравится программировать, как не нравится больше ничего - я пытаюсь научиться этому
Либо я чего не понимаю, либо тут явное противоречие
> Если у вас есть какие то методики, как бороться с прокрастинацией, или как мотивировать себя к учёбе - делитесь!
> Хочешь себя мотивировать - не вопрос: поставь себе реальную цель с четко оговоренными сроками. Например сделать такой-то софт за 2 месяца. Поспорь с девушкой, другом, родителями (не важно, с кем угодно): если за этот период на сделаешь - отдаешь 2к$ наличными.
Конкретная методика
> На основании чего вы сделали подобные выводы?
На основании ваших же слов. Единственное "за" программирование:
>> Мне нравится программировать, как не нравится больше ничего
Вы не говорите, что хотите этим на хлеб с маслом зарабатывать, вы не говорите, что хотите сделать какой-то проект, вам это просто нравится. Это примерно тоже самое, что говорить: я хочу быть строителем, потому что люблю забивать гвозди, правда меня от этого дела иногда ВК отвлекает.
Проблема в том, что программирование - не есть сама цель. Программистам нравится не сам факт клацанья по клавишам (это ~10% потраченного времени), а решение логических задач, получение результата, разные новые штуки поковырять, и т.д.
sbh
Зря вы так думаете. Смысл сказанного мной выше в том, что задавать вопросы "не работает" - это пустая трата времени.
Я не спорю, Влад Животнев угадал, молодец, пирожок ему вкусный за это.
Но есть нюанс: тот же fpm могут падать по миллиону причин.
Решение любой проблемы начинается с ее локализации, в этом вопросе она началась только в комментариях.
В текущем виде формулировка вопроса никуда не годится. Это тоже самое что спросить: у меня все работало, а теперь ничего не работает, уточняю: на компьютре.
Сделай запрос к другому сервису вручную и посмотри, что отвечает (проставь таймаут 3 минуты). Если к логам сервиса доступа нету - обращайся к его вендорам.
> Поделитесь мыслями - почему вам было бы удобнее так работать, какие преимущества вы получили бы при таком подходе?
Многие из системы предрасположены к репликации. Например: почтовые рассылки (Z). В случае повышения нагрузки не составит труда поднять еще несколько нод под это дело. При этом даже в случае, если X ведет себя не корректно - Z будет работать корректно.
Пример из жизни: есть задача по вытягиванию платежных данных пользователя и отправки их партнерам. Я использовал один из классов соседней подсистемы, которая это дело умеет. Но как результат - не работает. Оказалось, что этот класс оставлен только для обратной совместимости и более не используется. В случае разделения на сервисы подобная ситуация невозможна, потому как спецификация API обязана быть, как документ.
Основной плюс подобного подхода - это независимая разработка сервисов. Например фронт сайты требуют что бы быстро (на вчера), красиво, ну и качество так себе. Сервис платежей разрабатывается в более медленном темпе и должна быть: безопасной, 100 раз перепроверенной. Сервис чатов живет тоже в своем темпе, он не на столько безопасен, как платежи, но должен выдерживать огромную нагрузку.
Так же плюсом является то, что каждый из сервисов определяет свои собственные требования к окружению. Например фронт сайтики - вполне ок на php, тяп-ляп и в продакшн. Платежи - ява. Чаты - нода, или erlang. Чатонить специфическое, например тегирование пользователей - можно на golang.
Как следствие есть возможность делать такой финт ушами: концепты писать на одном стеке, и в случае успеха - быстро переписать на другом.
@kazhuravlev
> лишь бы разработчики могли сосредоточиться на бизнесе а не на выравнивании контрактов и интерфейсов
))) Разработчики не занимаются бизнесом, а имплементируют бизнес логику. Контракты и интерфейсы нужно выдерживать в любом случае, иначе система будет вести себя не предсказуемо.
Еще раз: один репозиторий вас ни капли не спасет.
Как пример функция login($login, $pass): я залью туда "" и ресурс, что произойдет? По хорошему я должен словить исключение, и это будет контрактом.
Поймите, один репозиторий - вас рано, или поздно приведет к монолиту, что бы вы не делали. И в один прекрасный момент при заливке только сервиса Х вы будете обязаны заливать всю систему, со всеми вытекающими.
kazhuravlev
> если бы все сервисы находились бы в одном репозитории, все было бы проще - изменил модель, от которой все наследуются - и все готово.
Никто не мешает общие классы и хэлперы вынести в общий репозиторий, который будет зависимостью каждого из микросервисов.
Правда как и в случае с одним репозиторием: изменение одной сущности может привести к непредсказуемым последствиям.
kazhuravlev увы, от этого вы не сможете застраховаться.
Все изменения должны быть задекларированы в спецификациях API каждого из сервисов. Если X перешел на новую версию API, а Z с ней работать не умеет - в интеграционных тестах смысла нет потому как контракт у вас выполняться не будет в любом случае.
Если это ошибки в имплементации API одного из сервисов - это должно вылезти в тестах этого же сервиса.
Конкретно связь X и Z проверяется уже в масштабах системы во время подготовки к релизу. Это значит, что в релиз попасть новая версия X и старая Z не могут.
Безусловно есть очень большой минус в данном подходе: 7-меро одного таки ждут.
Инструкции для CI вполне можно хранить в заранее оговоренном виде, например как у того же travis: .travis.yml
> В жтом случае необходимо будет для каждого микросервиса прописывать зависимости от других микросервисов, которые необхоимы для тестирования текушего.
Тут - только эмуляторы, на основании спецификации. В отличии от SOA тут нет понятия "я работаю с сервисом А", вместо этого "я пытаюсь работать по спецификации с неизвестным сервисом". Подход микросервисов предполагает, что связанные с ними могут в любой момент отвалиться по любым причинам.
Что касается релиза системы в целом, и интеграционных тестов: создается общий репозиторий с фиксированными зависимостями от конкретных версий микросервисов И набором интеграционных тестов. Конкретной бизнес логики там нет, его задача - собрать все в кучу. При этом каждый из сервисов живет своей независимой жизнью.
Общий релиз в данном случае - обновление зависимостей.
На счет настроек в массивах такой подход тоже имеет право на жизнь, но есть подводный камень: когда их будет реально много - ориентироваться по нему станет не просто.
На счет констант: когда я впервые увидел этот подход - сначала думал, что эт какой-то шлак, но на деле оказалось очень здорово то, что вам нет необходимости прописывать геттеры, IDE константы само подтягивает + в случае если что-то забыли - сразу четко знаем что. В случае с массивом - обязательно необходимо выполнять проверку существования, иначе будет бида.
