Надеюсь, после этой истории в госструктурах додумаются сделать багбаунти или хотя бы место, куда можно сообщить об уязвимостях на сайтах госструктур и получить рекацию, направленную на устранение уязвимости, а не ответ вида «пнх, терроюга. за тобой уже выехали».
Сайт лежит. Все базу походу выкачивают=)
Если по делу, то против поступка автора раскрыть уязвимость, не дав времени на починку. Дыры есть везде, в сайтах госструктур этих дыр больше, чем где либо, т.к. кфалификация разработчиков в среднем крайне низкая. Провести тест на адекватность и дать хотя бы неделю на исправление — вполне нормально. Если бы не закрыли и пытались наезжать, было бы показательно, да и в публикации это можно было бы отразить. А в данной ситуации я честно не понимаю, чего хотел добиться автор.
Уточните, пожалуйста, как вы именно ведете разработку.Верно ли я понял, что в каждом сервисе есть файлы контроллеров+дтошек и отдельный файл спецификации OAPI3 и когда нужно произвести изменение, оно проводится и там и там руками? Или вы все-таки используете автогенерацию документации или наоборот генерацию дтошек на основе OAPI описания?
Для нас плюсов тоже было больше, чем минусов — иначе бы не переводили.
Пост был не про то, что нельзя перехать, а про то, что даже на средних размеров проекте это вполне себе ощутимые трудозатраты(ну или мы что-то не так делали). Данный момент, как минимум, стоит держать в голове.
Также раз уж написал про проблемы, то напишу и про маленькие приятности, помимо кросплатформенности, которые дает net core:
— удобный механизм переопределения appsettings.json(в прошлом app.config) из коробки: можно таскать переопределения ключей из консоли, файлов, перменных окружения
— csproj файлы стали намного более читаемые и удобные. теперь на них можно смотреть(и мерджить) без боли
— более удобное подключение нугет пакетов: ссылка на пакет добавляется в csproj и все. без всяких там UI и сгенерированных hintPath, как это было в старом csproj.
— стандратный DI вполне адекватен и вообщем-то что-то стороннее ставить не всегда есть смысл
Если кто-то питает иллюзии, что ничего не придется переписывать — стоит перестать это делать.
Из того, на что напарывались:
— Nhibernate -> Dapper
— Ninject -> стандартный DI
— log4net заводится через одно место
— полностью новая инициализация сервиса(на Net 4.6 был OWIN + Topshelf)
— завести NUnit на TeamCity нифига не просто и тащит за собой обновление TeamCity
— переписать билд-скрипты на dotnet build|publish
Переезжать серверным системам стоит если:
а) вы видите профит от снижения затрат на хостинг за счет перехода на линукс
б) у вас (микро)сервисы и вы понимаете зачем вам докер
в) ваш заказчик купил линукс сервера, не посоветовашись с вами
Новые проекты имхо стоит все-таки начинать сразу под netstandard2.0 или вообще на java от греха подальше=)
На РИТ понравилось, спасибо организаторам. Перед конференцией был настроен несколько скептически, но в итоге было много сильных технических докладов, что оказалось приятной неожиданностью.
ЗЫ отдельный респект за afterparty первого дня)
Отправлял заявку на митап, пришло письмо, что заявка на рассмотрении, однако подтверждения участия так и не пришло, также как и отказа. Если тут есть кто-нибудь из организаторов, просьба подсказать, где можно уточнить заапрувили или нет заявку.
Спасибо за отличную статью! Используем похожую схему цикла разработки, но аналог Product Visual QA проводим только для действительно крупных и важных фич, причем смотрит вся команда(тестеры+ разработка+аналитик. благо нас мало и это не так дорого, как могло показаться) — помимо просмотра позитивных сценариев такие мероприятия выполняют роль обмена знаниями о фичах внутри команды. Ну и принцип «1 голова хорошо, а несколько лучше» тоже часто срабатывает в плане полезных идей и замечаний от участников просмотра.
Немного дополню ответ от FJCrux: dotnet publish вне зависимости от ОС, на которой она запускается, можно указывать, под какую целевую ОС собирать бинари. Ну и сборка через CI на Linux вполне себе вариант — мы у себя смотрим именно в эту сторону
К яндексу и яндекс.такси отношусь позитивно, обычно езжу именно через них. Но слияние с убер печалит т.к.:
меньше конкеренции — это меньше стимула разваиваться и больше возможностей задирать цены.
Классная статья, спасибо!
Вопрос насчет вашей системы логирования на основе эластика: сколько ГБ логов туда попало за день при максимальной нагрузке(если не секрет конечно)?
Alerting из X-Pack приятная штука, но цена подписки оказывается неподъемной для небольших компаний. Сами пользовались триалом- понравилось, но теперь придется искать бесплатную альтернативу оповещениям.
Статья — какой-то рекламный буллшит, местами с перевиранием и притягиванием за уши удобных примеров.
Лучше бы вместо отого описали реальные кейсы, в которых Go применять действительно удобно.
Если по делу, то против поступка автора раскрыть уязвимость, не дав времени на починку. Дыры есть везде, в сайтах госструктур этих дыр больше, чем где либо, т.к. кфалификация разработчиков в среднем крайне низкая. Провести тест на адекватность и дать хотя бы неделю на исправление — вполне нормально. Если бы не закрыли и пытались наезжать, было бы показательно, да и в публикации это можно было бы отразить. А в данной ситуации я честно не понимаю, чего хотел добиться автор.
Пост был не про то, что нельзя перехать, а про то, что даже на средних размеров проекте это вполне себе ощутимые трудозатраты(ну или мы что-то не так делали). Данный момент, как минимум, стоит держать в голове.
Также раз уж написал про проблемы, то напишу и про маленькие приятности, помимо кросплатформенности, которые дает net core:
— удобный механизм переопределения appsettings.json(в прошлом app.config) из коробки: можно таскать переопределения ключей из консоли, файлов, перменных окружения
— csproj файлы стали намного более читаемые и удобные. теперь на них можно смотреть(и мерджить) без боли
— более удобное подключение нугет пакетов: ссылка на пакет добавляется в csproj и все. без всяких там UI и сгенерированных hintPath, как это было в старом csproj.
— стандратный DI вполне адекватен и вообщем-то что-то стороннее ставить не всегда есть смысл
Из того, на что напарывались:
— Nhibernate -> Dapper
— Ninject -> стандартный DI
— log4net заводится через одно место
— полностью новая инициализация сервиса(на Net 4.6 был OWIN + Topshelf)
— завести NUnit на TeamCity нифига не просто и тащит за собой обновление TeamCity
— переписать билд-скрипты на dotnet build|publish
а) вы видите профит от снижения затрат на хостинг за счет перехода на линукс
б) у вас (микро)сервисы и вы понимаете зачем вам докер
в) ваш заказчик купил линукс сервера, не посоветовашись с вами
Новые проекты имхо стоит все-таки начинать сразу под netstandard2.0 или вообще на java от греха подальше=)
ЗЫ отдельный респект за afterparty первого дня)
меньше конкеренции — это меньше стимула разваиваться и больше возможностей задирать цены.
Вопрос насчет вашей системы логирования на основе эластика: сколько ГБ логов туда попало за день при максимальной нагрузке(если не секрет конечно)?
Лучше бы вместо отого описали реальные кейсы, в которых Go применять действительно удобно.