Пользователь
На собеседованиях на позицию, предполагающую понимание DevOps, я люблю задавать кандидатам такой вопрос (а иногда его еще задают и мне):
Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc?
Сегодня я хочу рассказать про своё видение идеального пайплайна. Материал ориентирован на людей, имеющих опыт в построении CI/CD или стремящихся его получить.
Пока музыкальные площадки хвалятся прибылью за 2020-й и результатами первого квартала этого года, да еще и призывают авторов и исполнителей записывать и выкладывать свои произведения как можно чаще, последние зачастую вынуждены развиваться чуть ли не на голом энтузиазме. Обсудим кто им помогает, и как складывается ситуация в индустрии.
Когда мы говорим о тестировании документации, то обычно подразумеваем тестирование требований, ТЗ. И это тестирование на полносту, однозначность и прочая. Смотрим, как новый функционал будет коррелировать со старым, не будет ли проблем. Заранее продумываем свои тесты, обсуждаем реализацию...
Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Давайте посмотрим, какая бывает документация:
Что касается нынешнего ИТ-рынка, среда DevOps — один из лучших вариантов для ИТ-специалистов с точки зрения заработной платы и карьерного роста. И мне довольно часто задают вопрос: «Как стать инженером DevOps?»
В этом блоге я попытаюсь ответить на него на примере своего собственного опыта работы DevOps в различных организациях.
Apache Kafka — распределённый программный брокер сообщений, применяемый в обработке в реальном времени данных большого объёма. К отличительным особенностям Apache Kafka можно отнести: надёжность, масштабируемость и высокую производительность. В докладе разберём основные архитектурные особенности и сценарии использования Apache Kafka. Рассмотрим неочевидные моменты и грабли, которые мы собрали на пути Востока.
В мире Java за последнее время произошло много интересных событий. Одним из таких событий стал выход первой production ready версии Graal VM.
Лично у меня Graal давно вызывает нескрываемый интерес и я пристально слежу за докладами и последними новостями в этой области. Одно время попался на глаза доклад Криса Талингера. В нём Крис рассказывает как в Twitter удалось получить значительный выигрыш в производительности, применив для настройки Graal алгоритмы машинного обучения. У меня появилось стойкое желание попробовать подобное самому. В этой статье хочу поделится тем, что в итоге получилось.
Надоело заморачиваться с доверенностями, банками, судами, госорганами и решили прописать в Устав второго директора. Плюс заодно избавиться от дурацкого большого устава давно было желание, чтобы не копировать толстый устав на тендеры и крупным заказчикам. Но коллеги говорили, что будет не солидно, возникнут вопросы при рассмотрении устава юристами контрагентов, которые должны оправдывать свою зарплату. И всё как-то не решались. Но год назад решились. Сделали одностраничный устав. Кстати, в поиске в Яндекс.Картинках не нахожу одностраничного устава в электронном виде. Наш первый значит будет. Год прошёл — полёт нормальный, проблем нет. Солидность не пострадала. Банк устав принял, второго директора признал. Хотя тупил страшно. Дальше о том, что должно быть в одностраничном Уставе, какие трудности были с регистрацией в налоговой и с банком. Мы всё хотели сделать принципиально в электронном виде и удалённо.
