Там и кроме технологий двойного назначения много что можно делать: система канализации и переработки отходов, теплицы, способы борьбы с тараканами на станции, орбитальные буксиры, защита от солнечной радиации без стабильного магнитного поля, да мало ли что ещё.
Любые инженеры менее универсальны если они могут такими быть. Ну кто не хочет быть всю жизнь программистом на Python 3.5.2 и больше ничего не учить? Но так не работает. Так что и эти инженеры будут вынуждены учить новые трюки потому что без этого в профессии не удержаться.

Как в своё время аутсорсинг спас и сделал массовой сферу разработку софта так такой же аутсорсинг может спасти космическую отрасль.
Но только если государство найдёт модель когда мелкие компании смогут в этом участвовать. С одной стороны советские КБ крутые: все знают и умеют, но они слишком медленные. А с другой стороны инженерные практики, стандартны качества слишком тяжелые, испытательное оборудование слишком дорогое чтобы новички смогли себе это позволить на старте. Мне кажется можно подобрать модель когда это все заработает, но во-первых все участники должны этого хотеть, а во-вторых нужно начинать с beginners’ mind.

Спасибо за прекрасный обзор! Работаю на Salesforce уже много лет, но компания большая и разрастается на столько быстро, что сложно уследить за всеми новыми направлениями. Благодаря подобным статьям получается узнавать про «the other side of the force»

Если бы не требование программирования, то в какой-нибудь МАУП или что там сейчас есть похожее. Может там и про программирование можно договориться...

Стоит всё-таки получить диплом. Если и не пригодится для работы, то пригодится для рабочей визы.

Так зачем копировать если можно учиться с этих самых открытых курсов? Заодно и английский подтянется. Я, кстати, брал курсы на Coursera по ML от Стенфорда — я поразился на сколько можно понятно объяснять. Потом попробовал такой же курс от Яндекса — это был мрак: много слов, мало полезной информации и ещё меньше смысла.

Александр, прошу прощения за вопрос, но зачем Вам заканчивать специальность связанную с программированием? Позвольте пояснить суть моего вопроса. В Штатах есть классификатор профессий так вот программирование там отнесено к категории «не требует высшего образования», там же статистики, врачи и юристы — «требует степени магистра».
Влад привёл ссылку на стандарт образования по специальности «разработка программного обеспечения». Стандарт в общем-то мало внимания уделяет именно программированию. Там, например, есть работа с людьми. Если говорить про технологии то там рассматривается полный цикл от требований и архитектуры до эксплуатации.
Я это к тому, что бакалавр со специальностью программирование — это очень много времени на всякую политологию, философию и прочее, немного времени на специальность и совсем недостаточно знаний для старта карьеры.
Потому мне искренне интересно в чем Ваша мотивация искать кафедру где преподают программирование? Я бы Вам советовал целиться в то кем Вы хотите быть лет через 15. Если Вы сегодня хотите прокачивать программирование, то проще набраться знаний с Coursera, Udemy и прочих открытых курсов от MIT и Harvard

Ну не знаю, мне кажется отличный стандарт. Я готов под каждым словом подписаться.
Писать на котлине и еще десятке языков дело не хитрое. А вот умение «Донесення до фахівців і нефахівців інформації, ідей, проблем, рішень» дорогого стоит.
Стандарт, к сожалению, слишком фундаментален: он покрывает всю карьеру от джуна до CTO. И, соответственно, его нельзя покрыть хоть сколько нибудь детально за 4 года. Из-за большого размаха он не помогает со стартом карьеры. А большая часть знаний вылетит из головы к моменту когда они понадобятся по жизни. Это наверное стандарт на конец карьеры: освоил все что в стандарте — считай жизнь удалась

Это правда, для отъезда скорее всего будет нужна инженерная специальность в дипломе. Но учитывая что в Днепре нет хорошей программы по CS, то я бы выбрал просто какой-то интересный инженерный курс для саморазвития: робототехника, автоматика и системы управления, какая-то физика. Что автору интересно. Главное понимать что эти 4 года будут для себя и карьере они никак не помогут.

Филфак, политология, иняз? Адекватного CS все-равно нигде нет, а там хоть весело будет.

Мне все эти курсы совсем не помогли: я научился писать письма, но через несколько лет смотреть на этот текст было страшно.
Как-то научиться быстро строить фразы помогли чаты с фриланс заказчиком из штатов. Помню как я словы для следущей фразы искал в Лингво.
Научиться понимать разговорный язык с разными акцентами помог Netflix. В какой-то момент мы решили что смотрим сериалы только на английском. Первые несколько месяцев мы в основном читали субтитры (на английском) но потом отпустило. Не пытайтесь сразу начинать с BBC — американский киношный английский сильно проще. Конечно есть ещё южный, техасский, северо-восточный, индийский и прочие акценты, но это потом.
А разговорный английский помогли подтянуть ежедневные посиделки за кофе с коллегой из Польши — это был просто трёп за жизнь.
Акцент страшная штука — только открываешь рот и первый вопрос: а вы от куда? Акцент искажает речь. Его практически невозможно победить, единственное что остаётся: принять акцент и научиться говорить четко чтобы собеседники понимали. И главное перестать его стесняться.

В те годы Mitsubishi Outlander были весьма хорошие, Subaru Outback, Honda CR-V. RAV4 тогда кажется был с колесом сзади — странная модель. Большинство американских машин тех времён уже на свалке, во всяком случае на дорогах их не видно, а те немногие что остались в ужасном состоянии.
Но главное не в этом, а в том что сейчас очень неудачное время для покупки б/у машины из штатов: здесь цены на них взлетели до небес и 3х летнюю машину выкупают всего на 3-4 тысячи дешевле цены покупки. Продадут ее скорее всего за те деньги что она стоила 3 года назад

DevOps продают под соусом: мы сведем вместе dev и ops, переоткроем для себя матричную модель организации и все эти люди будут получать бонусы только если проект в целом успешен. Не говорим про DevOps инженеров, которые что-то непонятное, но умеют Jenkins и Ansible. В общем DevOps — это отличная модель, в определенных условиях. Но она не очень масштабируется: начиная с определенного количества проектов уже тяжело найти столько Ops и начинается обратный откат в централизованной Ops организации.

В случае в Service Ownership модель немного другая: мы не приписываем Ops к каждому проекту, вместо этого группки ops- и infrastructure- инженеров пилят свои сервиса, которые потом используются dev- инженерами для выкатывания и сопровождения своих поделок. Т.е. ops не приходит в проект и не рассказывает как war копировать куда-то, и перестартовывать что-то, а также как зайти на циску и что-то там подшаманить. Вместо этого они делают так, чтобы «даже девелопер» мог зарелизить что-то в продакшин и настроить что нужно и при этом ничего не сломать.

Мне кажется подобная модель может протянуть немного дольше.

Больше про V2MOM от автора идеи:

The vision helped us define what we wanted to do. The values established what was most important about that vision; it set the principles and beliefs that guided it (in priority). The methods illustrated how we would get the job done by outlining the actions and the steps that everyone needed to take. The obstacles identified the challenges, problems, and issues we would have to overcome to achieve our vision. Finally, the measures specified the actual result we aimed to achieve; often this was defined as a numerical outcome.

От сюда: www.salesforce.com/...​-within-your-company.html

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

Каждый год все начиная от CEO составляют формальный документ с Vision, Values, Methods, Obstacles и Measurements на год, а дальше компания на всех уровнях живет по тому что записали. Обычно такой документ для группы это смесь того что хочет от группы начальство более высокого уровня и того что хочет от жизни группа. Моя команда, например, записала что в течение года мы отчаливаем из текущего проекта и переходим в другой.

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

Культура с формально записанными ценностями может выжить и помочь компании только тогда, когда она разделяется всеми сотрудниками: от интернов до CEO. Это как законы: их исполняют либо все либо никто.

Наша компания как-то проскочила DevOps хайп и сразу перешла к Service Ownership. Отличная модель, как мне кажется: каждая команда пилит какой-то сервис от плана до сапорта, более крупные организации собирают эти отдельные сервиса в системы (бывает, что это даже работает).

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

Сервисом может быть и база данных, и настройтика роутера в стойке, CI/CD, github всех форм и размеров и т.д. и т.п.

Я рад что Вам понравилось.

Прочитайте статью — там есть пара интересный идей ;) Лучше конечно читать на английском — не все получилось хорошо перевести.

Мой проект занимается обработкой сообщений от IoT: железки шлют нам по HTTP какие-то сообщения, а дальше внутри к этим сообщениям подмешивается контекст и все это переводит state machines в новые статусы. Переходы в какие-то статусы могут заканчиваться какими-то действиями.

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

Динамическую глубин логирования уже реализовали — я читал где-то несколько постов. Плюс где-то была интересная идея включить DEBUG логгинг для какого-то подмножества запросов — просто так.

Мы постоянно подмешиваем тестовые события на продакшин системах для контроля связанности сервисов и времени прохождения: контекст и состояния определяют клиенты, так что нам нужно что-то стабильное чтобы можно было сравнивать яблоки с яблоками.

Есть несколько причин.

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

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

Есть вариант парсить их прямо не сервере где они записаны. Я делал такое при помощи collectd для httpd. Если они отправляются сразу в сеть через rsyslog или что-то подобное можно сделать разбор на транзитных узлах — я помню какие-то агенты умеют выкидывать email, SSN и прочее из сообщений, может они и метрики могут вытаскивать.

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

Это имеет смысл делать для, того что называется «off the shelf», продуктов с плохими метриками. Если это наш сервис, то добавить метрики сильно проще чем поддерживать регулярки для логов и всей инфраструктуры для их разбора.