• О книге Varghese «Web Development with Go»
    +3
    > «т.е. по сути код продолжит выполнятся с той точки, где была вызвана паника»

    это не так работает, как совершенно справедливо заметил astec. И в этом легко убедится самому, например так play.golang.org/p/OVcx_zDjDx
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    0
    ничего не понял. кем отправлятся? что именно слушает клиент? что значит назад?

    Насколько я себе представляю, этот рефреш токен должен быть у клиента и получит он его в момент login, вместе с access token, где его, теоретически можно украсть, например если есть физический доступ к компьютеру жертвы. Потом он (клиент) его будет время от времени посылать auth серверу для получения нового access token. Я не вижу как в этой схеме помешать злодею который завладел этим refresh token.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    0
    > Компрометация refresh tokenа сама по себе еще не обязательно приведет к возможности получения злоумышленником новых токенов

    Вот это мне непонятно. Какой механизм может этому помешать? Передача рефреш токена, как бы она не просиходила, будет идти от клиента к серверу auth и в ответ на валидный refresh token auth server радостно создаст новый access token. Кроме условного «усиления refresh token» путем добавления туда чего-то типа source ip и/или агента или еще нечто в таком роде, я не вижу какой тут механизм помешает.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    +1
    эээ… а это что? «я лишь подчеркнул что это не правильно...», «вы не правильно пишите что application server должен знать секрет ...»

    я не спорю, что для определенных случаев ассиметричный ключ будет безопасней, я всего лишь подчеркиваю, что категоричность приведенных выше цитат не соответствует действительности.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    +1
    > в примере в статье речь о симметричном шифрование и секрет получается один и тот же что на auth сервисе, что на application.

    да, именно об этом и идет речь в статье. И это, повторю в 3й раз, вполне правильная трактовка. С точки зрения JWT нет ничего неправильного в использовании симметричного ключа, это один из легальных способов.

    Что касается «удобней» — это уже вопрос к вашей системе. Я могу придумать случаи когда использование HMAC будет удобней, но суть не в этом, а в том, что это один из нормальных методов подписи и верификации JWT.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    0
    это вполне вполне правильная трактовка. HMAC именно так (общий секрет) и работает.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    +6
    Нет, смысл вовсе не в этом. Строго говоря «application server может читать данные из payload без ключа» — это очень плохая идея. Никакого доверия таким данным нет и их можно использовать только после того, как сделана проверка подписи. Это действительно делает application server и он делает это на каждый запрос в котором JWT представлен.

    Какой-то ключ application server должен знать, но это не обязательно должен быть тот же секрет, который использовался при создании токена. А может быть и тот-же, зависит от Signing Method — HMAC (shared key) или RSA/ECDSA (asymmetric).
  • Что такое dinghy или как ускорить docker
    0
    я не вижу никакой проблемы с мounted volumes. Изменения появляются сразу, без всяких костылей с NFS и прочим.
  • Что такое dinghy или как ускорить docker
    0
    > В любом случае — это особенность, которая в «плюсы» точно не попадает.

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

    > если ждать загрузки страницы на локальной машине приходится по 15 секунд — это ужасно медленно

    Опять непонятно, какую именно проблему предложенное решения адресует. Телепатически могу догадаться, что речь идет о volumes (исходя из разных упоминаний NFS).

    > В комплекте идёт прокси — зачем же изобретать свой велосипед,
    Если это используется как среда для локальной разработки, то я могу (с трудом, но могу) представить пользу от подобного. Но если это использование для чего-то более близкого к тому, как докер используют в реальной жизни, то решать «проблему» портов вот этим велосипедом на настощем, боевом сервере — это не самая лушая идея. Для этого есть много разного, готового и проверенного в бою, что умеет делать динамическое проксирование нормальным образом.
  • Что такое dinghy или как ускорить docker
    +1
    > «В качестве слоя виртуализации он использует HyperKit. Недостаток — вы можете использовать только одну виртуальную машину.»

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

    По поводу «ужасно медленный» — это про что вообще? Про доступ к хостовой FS? Если он «ужасно медленный» то где результаты того, как он станет «прекрасно быстрым», где бенчмарки подтверждающие это?

    Проблема нескольких контейнеров на одном порту — это вовсе не проблема докера и решать ее надо на уровне прокси, который часть вашей системы, а не добавлением магической надстройки над docker-machine.
  • Путешествие за бугор и обратно: как не надо устраиваться работать за рубежом
    +1
    у вас, какая-то очень особая точка зрения не факты. Вы уже 5 раз сказали про «393 доллара ЕЖЕМЕСЯЧНО» но упорно отказываетесь слышать, когда вам говорят что речь идет о «monthly premiums» и, обычно (практически всегда в области IT) 90%, а бывает и 100% платит работодатель.

    Что касается «зачем людям нужна государственная страховка Obamacare» — во первых, она не государственная. Во вторых, если вам кажется, что народ стоит в очередь за этой «государственной страховкой», то оно тоже не так.
  • На пути к Go 2
    +7
    это мне кажется просто классическим примером пожелания, нарушающего все идеи и все методы/подходы принятия решений об изменениях в этом языке. То, что такое предложения вообще возникло, скорее всего означает нарушение первого пункта («используй язык, набирай опыт»). Я не могу себе представить как кто-то, кто разрабатывает на Go предложит настолько радикально и калечаще поменять нечто, что совершенно не важно для тех, кто этот код на самом деле пишет. И тут подходим к нарушению второго пункта — а какую проблему это должно решить? Проблемы тут нет никакой, но есть «мне так приятней/привычней, и вообще — хочу как в питоне».
  • IntelliJ против Eclipse: JetBrains Toolbox или Yatta Launcher?
    +1
    Какая-то, на мой взгляд, бесмысленная тема — «Кто первый сделал запускалку для своих продуктов». Сам смысл этих запускалок не особо ясен, ничего не мешает это сделать 33 другими способами, включая средства ОС и разные универсальные ланчеры типа Alfred. А тут это подается как достижение программистской мысли. Я сильно сомневаюсь, что есть живые люди которые выберут одну IDE вместо другой из за того, что там есть Launcher/Toolbox или нет. Этот фактор, лично для меня, не то что не в первой десятке причин для выбора, но даже и не в первой сотне.
  • Вышел GitLab 8.15
    0
    это не баг, но отсутствие очевидной фичи — https://gitlab.com/gitlab-org/gitlab-ce/issues/17801
  • Микросервис на Golang
    0
    назвать это гордо «интрументом» я бы не решиился. Там весь код это 50-60 строк определяющие структуру параметров, заворачивающие «templates» со всем, что человек туда положил в bindata и делающее по всем файлам в нем filepath.Walk с ExecuteTemplate. Могу, конечно, выложить, просто мне казалось это тривиальным.
  • Вышел GitLab 8.15
    0
    Я нежно люблю и активно исползьую gitlab и этот релиз мне нравится, однако приоритеты разработчиков иногда вводят в ступор. В 8.14 поломали совместимость со всеми текущими версиями git (точнее это git поломал, но результат от этого не меняется) и месяц было невозможно никому пушить в protected branch. Починка там была почти тривиальная, но по непостижимым для меня причинам она ждала 8.15, хотя просто просилась и кричала войти в скорейший, минорный релиз 8.14.х

    То, что авторы прокручивают новые свистелки — это конечнно хорошо, но то, что они стремительно теряют интерес к старым — это грустно. Месяца три как ждем элементарной починки для registry чтоб с ним наконец можно было работать, но нет — новые странные штуки появляются, а допилить то, что было выпущено несколько месяцев назад — никак.

  • Микросервис на Golang
    +2
    насколько я вижу, у тебя это тоже типа middlware, но с нестандартной сигнатурой func(http.ResponseWriter, *http.Request) (http.ResponseWriter, *http.Request). Если поменять на func(h http.Handler) http.Handler то станет как у всех, и самое главное — ты сможешь использовать все подобные, готовые middlware без всяких модификаций.

    Общее замечание: в принципе, идея создания фреймоврка такого рода мнe кажется делом сомнительным. Во первых, есть неплохие и проверенные боем библиотеки, которые это уже делают основнию часть, например chi. Во вторых — идея добавления туда и конфигурации и еще чего мне не кажется полезной. Да, я понимаю, что при создании сервиса хочется упростить начальные телодвижения, однако лично я пошел по другому пути и написал простой кодо-генератор, который делает рабочий скелет приложения с chi, набором middlware для него (у меня в каждом сервисе надо определенный набор, например JWT), логгером, main с флагами и env (github.com/jessevdk/go-flag) перехватчик сигналов и еще по мелочи. Кроме того, оно генерит не только исходный текст, но и все, что надо для сборки и деплоя (Dockerfile, CI yml, ansible yml)
  • Микросервис на Golang
    0
    в очередь я вкладываю понимание, что это queue куда кладут, в общем случае, данные. Кладут и достают последовательно. Конечно, очередь можно использовать мнoго для чего разного, например RPC, но насколько я понимаю, в статье не об этом речь. Конвейер, в моем понимании, это последовательность функциональных шагов для обработки неких данных.

    Для термина middleware в го мире есть довольно четкое соглашение, что это такое, и что люди под этим подразумевают, особенно в контексте http обработок. Например вот это https://github.com/pressly/chi/tree/master/middleware

    по поводу транслятора — по моему мнению лучше это поменять на оригинал до прогона через перводчик. То, что там читать трудно, а понять — невозможно.
  • Микросервис на Golang
    +3
    Удивительно непонятное описание продукта, просто исключительно странное. Даже мое понимание области в которой автор копает, не вносит ясности. Термины используется так, как я нигде не видел. Видимо очередь это не очередь а конвейер? И что за storage, для чего, куда и почему его основное достоинство это авто–дополнение в IDE? Хотя, похоже и storage это не то, что все под этим понимают, т.к. в нем автор предлагает хранить (?) middleware про которое я тоже уже не уверен, что это такое у автора и зачем его там хранить.

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

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

  • Языку программирования Go — семь лет
    0
    У меня к вендорингу есть свои претензии, но похоже, что вы называете этим слово что-то такое, что не относится к обычному, появившимся еще в версии 1.5. С этим вендорингом все IDE и продвинутые редакторы работают как должно. Вопрос «каким вендорингом вы пользовались» заставил меня даже посмотреть на дату сообщения — сейчас есть единый и неповторимый vendor, который понимают все тулзы и все IDE и который не требует переписывания импортов.

    Эту часть «хочу работать попроектно (вендоринг), что в каждом проекте был repeatable build (нестандартный вендоринг)» я не понял вообще. Как попроектно относится к вендорингу? Если речь идет о том, что вы хотите все свои зависимости завендорить — ну так они ничем не отличаются от внешних зависимостей и положив их в vendor вы добьетесь repeatable build без всяких плясок и усилий. И «форкнуть какую-нибудь популярную либ, изменить её и использовать мой форк» тоже не проблема. Форкаем, меняем, кладем в vendor.

    «хочу, чтобы моя IDE не была на Java и работала быстро» — и чтоб синенького цвета? Если надо именно IDE то выбора особого нет, только на java. Если надо продвинутый редактор с пониманием Go – то таких есть штук пять.

    «ещё хочу не только билдить локально, но и деплоить на тестовый сервер по нажатию кнопки в IDE» — а это для Go делается каким-то особым и сложным способом? Я не знаю, какой уровень волшебства вы ожидаете, но у меня вообще ничего не надо нажимать и все это делается по коммиту. Ну и в IDE как и в редакторах это делается десятком разным плагинов, на любой вкус.

    Для всего этого, что перечислено, никаких костылей не надо. В принципе, для этого вообще ничего не надо, оно уже там есть и оно работает.

  • Скрипт для тех, кому лень разбираться в Linux
    +18
    Добавлю, что кроме ложной уверенности, это еще и набор вредных и весьма опасных практик, собранный в одном флаконе. Кроме того, что оно должно запускаться под root, оно еще смело загружает по http черт знает что из интернета и потом запускает под тем же самым рутом.

  • Ansible-container: новый шаг в управление контейнерами
    0
    Ну это ведь о другом. У меня тоже ansible используется из контейнера по понятным причинам — все зависимости, что ему нужны там, все скрипты и все ключи доступны и прочее. Тут ansible просто еще одна докерезированная штука которая мало отличается от любого другого сервиса. Мой комментарий относился к идее запускать плейбук и в самом docker контейнере для инициализации/создания этого контейнера и именно такой кейс я назвал диковинным.
  • Ansible-container: новый шаг в управление контейнерами
    +1
    идея запускать плейбук и в самом docker контейнере мне кажется еще более … диковинной, мягко говоря. Если вдруг по каким-то, совершенно непонятным мне причинам, хочется делать такие странные, полуготовые и мутабельные докер контейнеры и деплоить внутрь код с помощью ansible, то совсем непонятно зачем тут docker вообще, и почему бы не делать это прямо на хост.

    > полагаю, что идея(использования ansible-container) приобретает ценность, когда при помощи ansible-container производится только сборка и push в registry

    С трудом могу себе представить эту ценность. Возможно, для этого нужны какие-то совсем дикие многофункциональные контейнеры, которые муторно и сложно описать обычным образом, но мне это видится кривой дорогой — я за контейнер-на-сервис, а не контейнер-как-легкая-vm.
  • Ansible-container: новый шаг в управление контейнерами
    0
    Dockerfile примерно такой же «shell-script» как и ансибловый yaml. Ну да, там в RUN пиши что надо, но примерно с тем же успехом можно сказать, что и ansible это такой «shell-script» с ssh запускалкой.

    Короче, как по мне, так очень странная затея. Понятно, почему это надо ansible, но как (а главное зачем) этим будут пользоваться живые люди я все еще не могу понять. Мотивация «этот язык описания мне нравится больше» мне кажется какой-то неубедительной для введения такого сомнительного велосипеда в свой процесс построения контейнеров.
  • Ansible-container: новый шаг в управление контейнерами
    +4
    Что-то я упускаю прелесть этой идеи. В моем понимании построение контейнера, это часть построения сервиса/программы, которое создает артифакты в виде docker image и пушит, и все это происходит в CI системе и, строго говоря, никакого отношения к asnible не имеет. Именно тут нужен Dockerfile, и он нужен на уровне сервиса а не на уровне композа, т.е. каждый сервис строится со своим собственным Dockerfile и никакой зависимости с прочими частями, типа nginx ему не надо.

    Сам деплоймент никакого отношения к этим Dockerfile не имеет, он их даже не видит. Все, что ему надо это docker-compose.yml в котором прописано все сервисы, порты, зависимости и прочее. Это (деплоймент) можно делать с помощью ansible (я так и делаю) но никакой хитрости для этого не надо, просто доставить compose файл плюс что надо еще (конфиги, например) и дернуть docker-compose.

    В какой модели удобно использовать подход описанный здесь, я не могу себе представить. Это если строить на боевом сервер контейнер? И в этом, странном случае, это можно делать с помощью compose. Единственный, но на мой взгляд сомнительный, плюс это разбиение на роли для сборки образов, но я не очень вижу зачем, например dumb-init иметь в виде роли, но не базовым контейнером.

    Кроме того, реализация своего сборщика, это дело муторное и требующее постоянной гонки за обновлениями docker. Даже они сами не поспевают с этим, и compose иногда обновляется сильно позже чем та или иная фича добавилась в докер. А тут теперь надо будет ждать пока и ansible это добавит.
  • Запуск cron внутри Docker-контейнера
    0
    ну, строго говоря, мы тут и так городим свой entrypoint.sh. Без особого труда тут можно сделать и какой sed для автоматической замены SHELL на то, что надо, и больше об этом не думать.
  • Запуск cron внутри Docker-контейнера
    0
    откуда, в моем примере, следует что данные надо скачивать и именно в файловую систему? Даже если и речь идет о подобных данных, то есть масса случаев когда они не персистент и это ответственность сервиса/контейнера их себе добыть. Это никак не ухудшает переносимость. Однако, в случаях когда данные прокидываются, тоже есть большая разница откуда вызывать скрипт. Если это скрипт (хотя я про скрипты ничего не говорил) делает нечто, что часть вашего сервиса, то его оторванность от вашего сервиса это совсем не тоже самое, как технически так и концептуально. И идея запускать это нечто на хосте, означает, что хост к такому должен быть подготовлен, что непонятно зачем надо. Ну и перенести это все просто средствами докера будет невозможно, т.к. часть работы делает внешний скрипт.

    Есть много случаев, когда задачи по расписанию чего-то в контейнере – это его внутреннее дело. Например, есть микросервис, который раз в день берет немного данных из внешнего мира, парсит их и вносит новые в некий store, специально для этого сервиса существующий. А все остальное время этот сервис отдает данные по запросам. Мониторинг к этому всему слабо относится — т.е. он никак не мешает мониторить как процесс так и конечное состояние.
  • Запуск cron внутри Docker-контейнера
    +1
    cron бежит со своим окружением. это не специфика контейнера/докера, но крона
  • Запуск cron внутри Docker-контейнера
    0
    помочь в каком случае? передать env в контейнер это не проблема, проблема – как передать env в cron
  • Запуск cron внутри Docker-контейнера
    0
    по поводу плясок вокруг «как крону передать env» — по моему можно несколько проще. В entrypoint сделать export > env.file а в кроне, в качестве SHELL, дать скрипт, который первым делом этот env.file применит.
  • Запуск cron внутри Docker-контейнера
    +3
    В отличии от комментаторов выше, я не вижу ничего странного в том, что в контейнере запускается нечто по расписанию. На мой взгля, во многих случаях это вовсе не «пытаются использовать его как виртуальную машину» и никак не противоречит мифической «документации по docker». Если, например, внутри контейнера живет процесс которому надо по расписанию нечто активировать, например обновить какие данные, нечто очистить/загрузить и прочее в этом роде, то дернуть процесс (сигналом либо каким прочим вызовом) из контейнерного крона вполне нормально, Идея делать это с хостовой машины — это, как мне кажется, совсем плохая идея, убивающая переносимость и прибивающая конкретный контейнер к конкретному инстансу ржавыми гвоздями.

    Нет никакой особой разницы как именно генерируется этот «специальный сигнал по времени» внутри контейнера. Можно прикрутить нечто прямо в процесс сервиса если есть такое религиозное неприятие к второму процессу, но оно ничем не лучшее обычного крона.
  • Переговоры о зарплате — как не прогореть
    0
    нет, не было таких.
  • Переговоры о зарплате — как не прогореть
    +2
    Предположение о том, что это такой особый, американский путь переговоров — оно не совсем верное. Т.е. может кто-то тут так и делает, начитавшись подобных… рекомендаций, однако во всех 3х компания, где я набирал людей, вопрос о компенсации и я и мои коллеги всегда прямо задавали кандидату. И это вопрос на который кандидат должен уметь ответить. Он может назвать и нечто, что за пределами бюджета, тогда я пытался понять насколько ему именно такая сумма важна и можем ли мы сойтись на компромиссе или убеждал тех, кто дает бюджет его скорректировать. Иногда бывало и наоборот, когда кандидат просит меньше чем мне кажется адекватным для его позиции и его опыта, и тогда я прямо ему об этом говорил и предлагал больше. Однако, ни одного случая когда человек вообще упирался и не говорил, сколько он хочет, у меня не было. А если бы был, то я бы попрощался с таким «умником» который либо не в состоянии принять решение, либо достаточно глуп чтоб слепо следовать подобным этой рекомендациям.

  • За и против: Когда стоит и не стоит использовать MongoDB
    +4
    меня вовсе не "бомбит", однако я подозреваю, что определенная неграмотность замечания и вызвала то, что ты видишь. Совсем непонятно о чем это ты говорил, если про write concern который в какой-то древней версии несколько лет назад был по умолчанию самый низкий — ну это вполне понятно удивляет некоторой… неактуальностью. Кроме того "не гарантировала strong consistency" видимо подразумевает что сейчас оно это гарантирует? Тут тоже много удивлений может быть вызвано у читателя, т.к. во первых там все не так прямо, а во вторых речь идет о продукте, который eventually consistent с разной степенью этой "eventually".
  • Веб-платформа на Java за 30 минут
    +3
    Если уж предлагать подобный метод «нажми кнопки не понимая что делаешь» то проще делать с spring-boot. Останется такая-же магия для новичков, но хотя бы меньше писать и никаких бубнов «как мне поднять томкат в IDEA» и прочих ненужных телодвижений.

    Вот тут они показывают простой и короткий пример — docs.spring.io/spring-boot/docs/current/reference/html/getting-started-first-application.html
  • 11 ошибок ваших бэкапов
    +3
    Я ничего не имею против Acronis True Image 2016 и Acronis True Image Cloud. Однако, утверждение что они "… позволяют делать резервное копирование данных с учётом всех вышеперечисленных советов и рекомендаций", и идея, что встроенный в ОС TM это то, чему «не стоит полностью доверять» и всего лишь «вспомогательный бэкап-инструмент», а ваш продукт то, чему стоит — мне кажется маркетинговым… преувеличением. Я не знаю вашего продукта, и необходимости его знать у меня нет, однако, я сильно сомневаюсь в его идеальности. Не потому, что вы программы писать не умеете, а потому, что никто не умеет писать идеальные программы.

    Совет «пользуйтесь только нашими продуктами» — это очень плохой совет. Привязать бэкапы к единому стороннему поставщику — это очень плохая идея.

    Что касается практических рекомендаций от меня (для дома) — делать бэкап TM на два устройства (локальный диск и nas) и завести альтернативный бэкап в облако (я для этого пользую arq).
  • IBM упрощает разработку программного обеспечения в облаке с помощью платформы Bluemix
    0
    Возможно ваше решение очень крутое и вообще новое слово, но ваша активность затянуть меня в свою секту граничит со спамом. Я никогда не подписывался на этот Bluemix, но вы спамите меня с разными «Hi there (almost) Bluemixer ...» через день.
  • Вышел JetBrains Toolbox со всеми обновленными десктопными продуктами
    0
    поправка самому себе — свежий плагин для питона таки есть, он просто не обновлялся от версии 4.чего.то.там то 5 пока я не переустановил его. Так что все не так плохо как казалось.
  • Вышел JetBrains Toolbox со всеми обновленными десктопными продуктами
    0
     А IDEA 15 для которой нет совместимого с ней питона, это действительно называется «обновленная версия»? Или просто забыли обновить до конца? Или я что-то совсем не так понял? Или теперь стабильные версии это как раньше были EAP?
    Я искренне не понимаю, как новая, видимо стабильная версия продукта, может прийти без одного из «встроенных» плагинов.
  • Рецепты Docker: Monkey patch, часть третья
    +3
    у меня нет вопросов и я знаю ответы. Единственная цель моих комментариев это оградить незрелые в докер умы, от вредных советов.