но мы точим наш CD под teamcity, это сообществу не очень интересно.

Прочел последнюю дискуссию - верю. В 10 лет опыта, знаний и умений. Искренне

В других чатах по руби сидите? Хотел бы больше читать, если знаниями делитесь не только здесь

есть ещё соседний чят: https://telegram.me/rubylang

этот я случайно нашел, когда попался на руки гит-репо с телеграмочятами

ваще это огромная проблема телеграма, наплодили чятов

и в них половина лиц одинаковая

а всё из-за того что нет /list

/list

:D

Лол)

да, это ботофича

типа тебе бот написал: скажи мне /foo, ты нажал на ссылку и сказал /foo

/list

мда

вобщем я вас услышал, хочется например пойти и сделать https://github.com/SUSE/Portus нормально

но это прямо очень большая задача :(

Писал код, учил других писать код. Занимался архитектурными вопросами, занимался вопросами оптимизации.

А учить писать код широкую общественность не думаешь?) Ну там через сринкасты или статейки?)

бесплатно нет. я придерживаюсь принципа или бесплатно или за полную цену но в обоих случаях в полную силу. сейчас бесплатно в полную силу не получится.

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

Например частая штука, это «разбитые окна»

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

Результат: плохие вещи продолжают происходить

Почему? Потому что кажется что проблем ОЧЕНЬ МНОГО. И их прямо сейчас не решить.

Так как всё надо было вчера.

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

И дальше его включить. После того как все основные проблемы закрыты, анализатор форсится как шаг в CI

есть жалобы? свалили билд

административно вводится жестокое пресение suppersion без детального объяснения почему

и каждый suppersion кладётся в беклог

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

и каждый suppersion кладётся в беклог

Придерживались Scrum в работе?

Ну и последнее на сегодня, про «он же говно мамонта на сквозь прошитый ынтерпрайзом». Фишка в том, что я тоже не фанат ынтерпайза. В общем случае в большой компании создаётся некая очень плотная и устойчивая к изменениям среда, которая обычно плохо адоптируется измененям. В этом есть и плохие вещи и хорошии. Хорошии вещи заключатся в том, что никто не тащит в проект «блесящие новые штуки», потому что они «новые и блестящие и были на продуктханте в топыче». Люди идеалогически больше думают о будущем и принимают гораздо более взвешенные решения и проводится большая исследовательская работа перед любым сильным изменением. Это приводит к общей стабильности продукта. Хорошая и одновременно плохая вещь: всё зарегулированно. Это хорошо, потому что процедуры при авариях расписаны по ролям, секундам и там не надо думать, надо просто делать как написано. Плохо, потому что очень сложно построить процесс который бы позволял эти процедуры быстро менять. Процедуры они вель не только на конкретные вещи, а вообще на какие-то подходы. И иногда их нужно нарушать и процесс получения разрешения на такое нарушение обычно ад. Плохая вещь: за исключением bleeding edge вещей, всем обычно срать. Все сидят на зарплате и уходят домой по звонку. Никто особо не думает как сделать что-то лучше, а просто исполняют. Это пиздец как мешает развитию компании. И это пиздец как сложно сделать управляемым. И это почти невозможно изменить. Очень плохая вещь: «копропативная амнезия» помноженная на отделы «а нам похуй». Какие-то вещи, которые не достаточно контролировали (обычно потому что они всегда охуенно работали) просто исчезают когда внезапно закончились люди которые это поддерживали. Это вообще адовый пиздец. Был проект который пилили чуваки без особого конторя, чуваков больше нет (умерли или уволились), проект остался, как его поддерживать вообще непонятно. И тут выясянется что какой-то другой продукт работал только потому что чуваки реально его пилили. Но знаний нет. Чуваков нет. И всё.

В целом я за компромис. Нужно держать нос по ветру, но думать о завтра. Нужно иметь «мягкие процедуры» и систему контролируемых исключений, чтоб они тоже стали частью процедур и занимали несколько десятков человекочасов, а не сотни.

Придерживались Scrum в работе?

мы перепробовали очень много, но да, Scrum при очень пиздатом PM дал прямо лучший результат.

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

Интерпрайз отучил меня от префекционизма и заставил больше и лучше пользоваться калькулятором для принятния решений. потому что говнокод при хорошей архитектуре, это лучше чем заебись код при хуёвой архитектуре. Но пиздатая архитектура, когда нет денег, это гораздо хуже, когда у тебя хуёвая архитектура и есть деньги. Go figure.

Я например против TDD, прямо сурово. Дроч на code coverage и «давайте покрывать тестами абсткатного коня в вакууме» это пиздец. Сначала сделали что работает, потом покрыли тестами и таким образом зафиксировали поведение. Теперь можно улучшать.

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

С B/G деплоем я могу откатить продакшен на предущие версии за наносекунды

Потому что стойку очень мощного железа можно купить на половину зарплаты одного разработчика

(годовую)

Можно хоть 100 билдов держать в «тёплом» режиме и катить на полную. Хочешь на всех, хочешь на 0.01% человек

На этом я кончу и пойду бухать, хайлайтите, могу повигать ещё телег завтра.

можно делать хороший код сразу без ебли

это вообще не сложнее чем делать хуевый код

и также с архитектурой

если у тебя маленький проект нехуй его тестами крыть

а если планируется что-то большое то это надо делать

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

можно делать хороший код сразу без ебли

;)

анекдот про вилларибо и виллабаджо

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

по CI смотри на teamcity. там надо намного почитать доки и потыкать чтоб набраться опыта, но потом это просто бонба

@dd_bb познавательно и хорошо поставлено ?

3 агента и 20 конфигураций бесплатно

этого за глаза хватает. если не хватает можно ещё один сервер и там ещё 3 агента и 20 конфигураций ;D

супер, спасибо, изучу

а почему не тревис?

тревис больше гонялка тестов, а из тимсити можно сделать CD

ну у тревиса есть вебхуки

ебашь cd сколько угодно

можно делать хороший код сразу без ебли

а можно писать сразу без ошибок, тогда и тесты не нужны будут

зачем вебхуки, если у тебя тимсити может сделатб вообще всё

сплошная экономия времени

тесты на основной функционал это хорошо

а еще лучше на закрытые дырки тесты писать

ERROR: S client not available

зачем вебхуки, если у тебя тимсити может сделатб вообще всё

декомпозиция

тесты нужно писать интеграционные и каждый баг должен улучшать итеграционный тест

твой тимсити хуй знает сколько жить будет еще

а если ты напишешь свой велосипед для cd то нет проблем

твой тимсити хуй знает сколько жить будет еще

а тревис будет типа дольше

тревис завтра выключили и ты хуй

в том то и дело что неизвестно

а тимсити гоняет у меня уже 7 лет и мне вобщем-то срать :)

доставку лучше делать самому а не лохам доверять

потому что java нас всех передивёт

тимсити это on-permises решение

так что лох тут только ты сам

за редким исключением когда говно в тимсити, тогда да, очень больно

но когда у тебя больно == деньгие, ты покупаешь суппорт и больно уже не так больно

и всё ещё у тебя дома

твоё, родное, вот оно

и пока дом стоит, оно работает

а с виртуализацией оно будет работать вечно

короче нам друг друга не понять

потому что я видел как софт 80 годов виртуализировали

я говорю что декомпозиция это хорошо

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

тебе никто не мешает вебхуки из тимсити стрелять

совершенно

мне мешает то что мне нужно ставить тимсити

ну это твои задачи

мне приходится работать в среде тимсити

и потом я не откажусь от него когда надо будет

а так тебе приходится работать в среде тревиса

нет

да

так у тебя все по полочкам