Forwarded from Alpha Centauri | Космос (Paul Potseluev)
На Reddit прошла Ask me anything-сессия разработчиков ПО из SpaceX. Один из наших читателей, SP, собрал интересные тезисы из их ответов пользователям. Возможно, чуть позже мы подготовим текст с более подробным разбором, а пока держите вот такие краткие итоги:
- Кодеры SpaceX подтвердили, что на мониторах в драконе крутится GUI на Chromium и Javacript. сначала они этот вариант сделали для презентации НАСА, а потом им самим понравилось
- Пока игр на Crew Dragon нет, но в будущем их скорее всего добавят
- Симулятор стыковки не имеет ничего общего с реальным софтом, его начали только как шуточный проект
- В "Драконах" не используются детали Tesla (дисплеи совершннно другие)
- "Старлинки" сейчас генерируют в районе 5 терабайт телеметрии сутки, миссия Dragon -- сотни гигабайт
- Софт Starlink сейчас обновляют примерно раз в неделю. Получается, что ПО на выведенных спутниках новее, чем на тех, что находятся в процессе запуска
- Спутники Starlink это скорее датацентр с серверами, чем космический аппарат
- Каждый запуск 60-ти Starlink'ов -- это вывод более 4000 компьютеров с линуксом. На данный момент в группировке на орбите более 30К компьютеров и 6К контроллеров
- Про алгоритмы посадки рассказывать не могут - секрет :)
- Много программистов пришли в SpaceX из геймдева, из-за похожей математики и умения решать проблемы с производительностью
- Используемые языки программирования:
-- основной С/С++, сторонние библиотеки используют по минимуму, предпочитая писать собственные для контроля качества кода, применяют в основном ООП, хотя любят также упрощать код;
вебстек для дисплеев - HTML / CSS / JS + веб-компоненты + собственный фреймворк;
-- python для тестирования и автоматизации
- на бортовых компьютерах RTLinux (linux ядро с патчем PREEMPT_RT, превращающим ее в ОС реального времени), на контроллерах голый код;
- GUI в ЦУПе основаны на LabVIEW
- Качество кода обеспечивается модульными тестами и интеграционными тестами в том числе и на летных образцах
- Управление Драконом создано исходя из принципа минимального взаимодействия с пилотом
- Спутники Старлинк настроены переходить в режим высокого аэродинамического сопротивления при долгом отсутствии связи с землей для быстрого схода с орбиты.
- В SpaceX есть мощный инструмент для сопоставления программы полета с симулятором. Можно полностью смоделировать миссию или любые сценарии сбоя даже на оборудовании, разложенном на столе.
- Наземное ПО для Старшипа основано на вебстеке и GUI Дракона, оно же будет использовано и в интерфейсах самого Старшипа.
- Возможно скоро поделятся скриншотами с дисплеев Дракона
- Система безопасности полета работает не на бортовом компьютере, а исключительно на контроллерах и сама взаимодействует с датчиками. Эта система отвечает за прекращение полета, к примеру когда ракета сходит с курса
Ну и ответ на самый важный вопрос: "Of course we play KSP :)"
- Кодеры SpaceX подтвердили, что на мониторах в драконе крутится GUI на Chromium и Javacript. сначала они этот вариант сделали для презентации НАСА, а потом им самим понравилось
- Пока игр на Crew Dragon нет, но в будущем их скорее всего добавят
- Симулятор стыковки не имеет ничего общего с реальным софтом, его начали только как шуточный проект
- В "Драконах" не используются детали Tesla (дисплеи совершннно другие)
- "Старлинки" сейчас генерируют в районе 5 терабайт телеметрии сутки, миссия Dragon -- сотни гигабайт
- Софт Starlink сейчас обновляют примерно раз в неделю. Получается, что ПО на выведенных спутниках новее, чем на тех, что находятся в процессе запуска
- Спутники Starlink это скорее датацентр с серверами, чем космический аппарат
- Каждый запуск 60-ти Starlink'ов -- это вывод более 4000 компьютеров с линуксом. На данный момент в группировке на орбите более 30К компьютеров и 6К контроллеров
- Про алгоритмы посадки рассказывать не могут - секрет :)
- Много программистов пришли в SpaceX из геймдева, из-за похожей математики и умения решать проблемы с производительностью
- Используемые языки программирования:
-- основной С/С++, сторонние библиотеки используют по минимуму, предпочитая писать собственные для контроля качества кода, применяют в основном ООП, хотя любят также упрощать код;
вебстек для дисплеев - HTML / CSS / JS + веб-компоненты + собственный фреймворк;
-- python для тестирования и автоматизации
- на бортовых компьютерах RTLinux (linux ядро с патчем PREEMPT_RT, превращающим ее в ОС реального времени), на контроллерах голый код;
- GUI в ЦУПе основаны на LabVIEW
- Качество кода обеспечивается модульными тестами и интеграционными тестами в том числе и на летных образцах
- Управление Драконом создано исходя из принципа минимального взаимодействия с пилотом
- Спутники Старлинк настроены переходить в режим высокого аэродинамического сопротивления при долгом отсутствии связи с землей для быстрого схода с орбиты.
- В SpaceX есть мощный инструмент для сопоставления программы полета с симулятором. Можно полностью смоделировать миссию или любые сценарии сбоя даже на оборудовании, разложенном на столе.
- Наземное ПО для Старшипа основано на вебстеке и GUI Дракона, оно же будет использовано и в интерфейсах самого Старшипа.
- Возможно скоро поделятся скриншотами с дисплеев Дракона
- Система безопасности полета работает не на бортовом компьютере, а исключительно на контроллерах и сама взаимодействует с датчиками. Эта система отвечает за прекращение полета, к примеру когда ракета сходит с курса
Ну и ответ на самый важный вопрос: "Of course we play KSP :)"
Reddit
From the spacex community on Reddit: We are the SpaceX software team, ask us anything!
Explore this post and more from the spacex community
Gwern Branwen (чтобы перечислить способности этого человека, нужен отдельный пост; особо стал известен, когда запилил GAN-сетки для генерации аниме-лиц и фигурок) в отношении недавно запущенной OpenAI GPT-3 (языковая модель со 175 миллиардом параметров, генерирующая тексты на уровне неплохих журналистов) заявил:
"GPT-3 реально пугает, потому что это ведь крошечная модель по сравнению с тем, что потенциально возможно, причём обученная самым глупым способом на единственной хилой модальности на крошечном датасете, но уже в первой версии проявляется сумасшедшее мета-обучение в рантайме, а кривые масштабирования всё еще не прогибаются!"
В США в июне начались слушания в Конгрессе по поводу Algorithmic Accountability Act ("Об алгоритмической подотчётности"), чиновники хотят по максимуму зарегулировать деятельность AI-организаций с позиций "непредвзятости результатов" (чтобы люди не подвергались дискриминации AI, которые принимают решения совершенно непонятно как). Какая-то погрешность в модели всё равно будет присутствовать, но конкретному человеку выяснить, что он попал в процент ошибки, невозможно. "Вам отказано в кредите" и всё. А если речь о здоровье, о медицинских диагнозах?
Поэтому параллельно конечно будут продолжать активно развиваться и формальные AI-технологии, где процесс решения прозрачен и понятен, и всегда можно вытащить подозрительное рассуждение. Microsoft например на днях выпустила новый язык программирования Bosque для AI-проектов, очень полезная и, надеюсь, перспективная вещь:
https://github.com/Microsoft/BosqueLanguage
"GPT-3 реально пугает, потому что это ведь крошечная модель по сравнению с тем, что потенциально возможно, причём обученная самым глупым способом на единственной хилой модальности на крошечном датасете, но уже в первой версии проявляется сумасшедшее мета-обучение в рантайме, а кривые масштабирования всё еще не прогибаются!"
В США в июне начались слушания в Конгрессе по поводу Algorithmic Accountability Act ("Об алгоритмической подотчётности"), чиновники хотят по максимуму зарегулировать деятельность AI-организаций с позиций "непредвзятости результатов" (чтобы люди не подвергались дискриминации AI, которые принимают решения совершенно непонятно как). Какая-то погрешность в модели всё равно будет присутствовать, но конкретному человеку выяснить, что он попал в процент ошибки, невозможно. "Вам отказано в кредите" и всё. А если речь о здоровье, о медицинских диагнозах?
Поэтому параллельно конечно будут продолжать активно развиваться и формальные AI-технологии, где процесс решения прозрачен и понятен, и всегда можно вытащить подозрительное рассуждение. Microsoft например на днях выпустила новый язык программирования Bosque для AI-проектов, очень полезная и, надеюсь, перспективная вещь:
https://github.com/Microsoft/BosqueLanguage
Segment (одна из крупнейших customer data platform - сервисов с топовыми клиентами), рассказала, как решила понемногу отходить от монолитной архитектуры в 2013-м на микросервисы, но когда в 2017-м количество клиентов и нагрузка ощутимо возросли, микросервисы не смогли нормально смасштабироваться, всё поломалось, и решено было вернуться обратно к монолиту.
https://www.infoq.com/news/2020/04/microservices-back-again/
https://www.infoq.com/news/2020/04/microservices-back-again/
InfoQ
To Microservices and Back Again - Why Segment Went Back to a Monolith
When Segment moved to a microservices architecture, they gained environmental isolation, but at a cost of higher operational overhead. Three years later, the costs were too high, and the team migrated back to a monolith. At QCon London, Alexandra Noonan told…
Как США борются с Китаем в научных исследованиях по искусственному интеллекту. Вкратце: китайцы стремительно захватывают всё :-)
https://www.nytimes.com/2020/06/09/technology/china-ai-research-education.html
Пока лидер США, но Европа уже сдаёт второе место Китаю, у них на троих где-то 70% всех научных исследований на ведущих конференциях.
Далее идут Канада, Англия, Израиль, Индия, Иран (по 3-5%), и в "Другие" -- оставшиеся 10% процентов, попал соответственно весь остальной мир, включая и Россию.
Похоже, что Монголия по AI скоро нас обгонит (если не уже): совместное исследование итальянских и монгольских учёных по созданию фреймворка визуального распознавания для дронов, слабенькое бортовое железо тянет одновременное отслеживание нескольких объектов на частоте видеопотока 20 кадров/с.
https://arxiv.org/abs/2004.06154
https://www.nytimes.com/2020/06/09/technology/china-ai-research-education.html
Пока лидер США, но Европа уже сдаёт второе место Китаю, у них на троих где-то 70% всех научных исследований на ведущих конференциях.
Далее идут Канада, Англия, Израиль, Индия, Иран (по 3-5%), и в "Другие" -- оставшиеся 10% процентов, попал соответственно весь остальной мир, включая и Россию.
Похоже, что Монголия по AI скоро нас обгонит (если не уже): совместное исследование итальянских и монгольских учёных по созданию фреймворка визуального распознавания для дронов, слабенькое бортовое железо тянет одновременное отслеживание нескольких объектов на частоте видеопотока 20 кадров/с.
https://arxiv.org/abs/2004.06154
Nytimes
A U.S. Secret Weapon in A.I.: Chinese Talent (Published 2020)
New research shows scientists educated in China help American firms and schools dominate the cutting-edge field. Now industry leaders worry that worsening political tensions will blunt that edge.
Парадокс с искусственным интеллектом в том, что это сегодня один из самых востребованных навыков в ИТ, однако AI-проекты очень сильно сдерживаются нехваткой специалистов, и получается замкнутый круг. Нету спецов -- AI-проекты развиваются медленно -- мало вакансий. А ведь точка входа в AI-профессию сама по себе весьма высокая, и вдобавок надо постоянно прикладывать много усилий, чтобы держаться на современном уровне. В AI/ML это особенно явно заметно. У кого есть время регулярно читать объёмные научные работы по AI или изучать новые фреймворки и платформы, выходящие каждый месяц?
Происходят всё время ведь очень крутые вещи, вот например как научили нейросеть играть в NetHack -- это такая олдскульная очень сложная roguelike, люди месяцами мучаются :)
https://ai.facebook.com/blog/nethack-learning-environment-to-advance-deep-reinforcement-learning/
Да и с чего вообще тут начать? Какие первые шаги делать? Классические когнитивные теории утверждают, что даже если хотя бы по 5-10 минут каждый день делать/изучать/развиваться в какой-то конкретной темке, в одном направлении, то через определённый период времени (месяцы, годы) вы станете в ней весьма и весьма опытным. Главное -- регулярность.
А начать движение в AI можно например с моего нового курса по SMT-солверам с нуля (автоматические решатели задачек и головоломок)
https://vk.com/wall-152484379_2878
Происходят всё время ведь очень крутые вещи, вот например как научили нейросеть играть в NetHack -- это такая олдскульная очень сложная roguelike, люди месяцами мучаются :)
https://ai.facebook.com/blog/nethack-learning-environment-to-advance-deep-reinforcement-learning/
Да и с чего вообще тут начать? Какие первые шаги делать? Классические когнитивные теории утверждают, что даже если хотя бы по 5-10 минут каждый день делать/изучать/развиваться в какой-то конкретной темке, в одном направлении, то через определённый период времени (месяцы, годы) вы станете в ней весьма и весьма опытным. Главное -- регулярность.
А начать движение в AI можно например с моего нового курса по SMT-солверам с нуля (автоматические решатели задачек и головоломок)
https://vk.com/wall-152484379_2878
Обращались за консультацией ребята с классической проблемой. Разрабатывается некоторая внутрикорпоративная система, и тут же эксплуатируется; на всё с десяток серверов, клиенты ноуты и десктопы. Сервера покупались в разное время, сконфигурированы по разному, и хорошо ещё, что везде линуха :) Но тоже самая разная, и легаси немало. Железо Intel, AMD, ещё что-то; про китайский Rockchip я, к огромному стыду своему, и не слышал доселе :) Сисадмин как-то это всё суппортит ручками.
Основная проблема, что везде нужны одинаковые версии компиляторов, но обновлять их в таком зоопарке очень трудно. На старых дистрибутивах линукса например они пытаются тащить какие-то совсем странные версии библиотек, которые ставятся очень криво, и т. д. А сам линукс обновлять ещё опаснее, вообще может всё грохнуться.
На очевидный вопрос почему бы не заюзать VirtualBox/VMware они жалуются, что пробовали, и хоть и декларируется, что накладные расходы там 5-10%, на самом деле нет. Ну я сам много лет работал с virtualbox, и потенциальные траблы хорошо знакомы.
Следующая более реалистичная схема -- заюзать Docker, оверхед там действительно куда ниже. Я бы даже сказал, что скорость близка к нативной на bare metal. Кроме того, докер ведь вообще можно отвязывать от физической инфраструктуры, запущать в облаках, в Windows, да вообще на любом хосте.
И вот ребята прям горели этой темой, потому что действительно удобно: настроил контейнер на первозданное состояние, каждый раз стартуешь его точно известно как, и вся система получается очень даже предсказуемой.
И всё вроде бы прекрасно, но есть нюансы :)
продолжение следует
Основная проблема, что везде нужны одинаковые версии компиляторов, но обновлять их в таком зоопарке очень трудно. На старых дистрибутивах линукса например они пытаются тащить какие-то совсем странные версии библиотек, которые ставятся очень криво, и т. д. А сам линукс обновлять ещё опаснее, вообще может всё грохнуться.
На очевидный вопрос почему бы не заюзать VirtualBox/VMware они жалуются, что пробовали, и хоть и декларируется, что накладные расходы там 5-10%, на самом деле нет. Ну я сам много лет работал с virtualbox, и потенциальные траблы хорошо знакомы.
Следующая более реалистичная схема -- заюзать Docker, оверхед там действительно куда ниже. Я бы даже сказал, что скорость близка к нативной на bare metal. Кроме того, докер ведь вообще можно отвязывать от физической инфраструктуры, запущать в облаках, в Windows, да вообще на любом хосте.
И вот ребята прям горели этой темой, потому что действительно удобно: настроил контейнер на первозданное состояние, каждый раз стартуешь его точно известно как, и вся система получается очень даже предсказуемой.
И всё вроде бы прекрасно, но есть нюансы :)
продолжение следует
вторая часть про контейнеры
Минусы контейнеров вытекают из их плюсов. Насколько удобно иметь детерминированную инфраструктуру, подсистемы которой можно перезапустить в известном состоянии, настолько же и критично, когда внесение самых крохотных правок или новых настроек подразумевает приличную переделку.
Главная сложность, что мы работаем с контейнером как с песочницей, которая не имеет доступа к своему хосту, ну и прозаически, так как это временный имадж, все наработанные данные надо сохранять куда-то вовне. Это качественное отличие от виртуалок, о котором часто забывают. В виртуалке вполне можно, поработав, сохранить её текущее состояние, сбросив сам промежуточный образ на флешку или в облако для страховки, и завтра продолжить как в обычном компьютере со вчерашнего состояния. При этом есть возможность откатываться к предыдущим контрольным сэйвам и т. д.
С контейнерами принципиальный момент, что он незыблем в своём исходном виде. Такая иммутабельность в крупной инфраструктуре хороша: нельзя что-то где-то случайно испортить, немного "подправив" вручную.
Да, и с контейнера можно сделать слепок, затем создать новый стартовый имадж на его основе, но это ещё сложнее и непрактичнее, нежели работа с виртуалками.
Ну а типовой выход такой, что в контейнер загоняем только инструменты для разработки, всё идеально настраиваем, подчищаем, даём сразу образу доступ к некоторому файловому ресурсу во внутренней сети, и сам проект храним за пределами контейнера. Таким образом получаем фиксированные рабочие места, которые можно запускать где угодно.
Нюанс опять в том, что докер на вашей конкретной машине надо всё равно конфигурировать локально :) Могут быть проблемы с правами доступа компиляторов в контейнере к каталогу с проектами, а в привилегированном режиме запускать докер нежелательно. Ещё неприятность, что проектные файлы на хосте, с которыми ведётся работа из разных контейнеров, могут получать очень странные permissions :) Это уже проблема самого докера в связи с правами и безопасностью, они могут тащиться с компьютера-хоста. И наконец, для такой схемы работы с контейнерами придётся запоминать настройки командной строки....
Резюме такое, что выбор между виртуалками и контейнерами неоднозначный,
и если цель -- прежде всего единообразие платформы разработки, которая редко конфигурируется или обновляется, для всех разрабов, то лучше взять докер, но придётся его вручную как следует допилить удобными скриптами, ну и поизучать доки.
Если же у каждого кодера своя, довольно уникальная роль в проекте, и свой набор инструментов, который часто обновляется, то лучше выбрать виртуалки и немного проапгрейдить под них железо.
Минусы контейнеров вытекают из их плюсов. Насколько удобно иметь детерминированную инфраструктуру, подсистемы которой можно перезапустить в известном состоянии, настолько же и критично, когда внесение самых крохотных правок или новых настроек подразумевает приличную переделку.
Главная сложность, что мы работаем с контейнером как с песочницей, которая не имеет доступа к своему хосту, ну и прозаически, так как это временный имадж, все наработанные данные надо сохранять куда-то вовне. Это качественное отличие от виртуалок, о котором часто забывают. В виртуалке вполне можно, поработав, сохранить её текущее состояние, сбросив сам промежуточный образ на флешку или в облако для страховки, и завтра продолжить как в обычном компьютере со вчерашнего состояния. При этом есть возможность откатываться к предыдущим контрольным сэйвам и т. д.
С контейнерами принципиальный момент, что он незыблем в своём исходном виде. Такая иммутабельность в крупной инфраструктуре хороша: нельзя что-то где-то случайно испортить, немного "подправив" вручную.
Да, и с контейнера можно сделать слепок, затем создать новый стартовый имадж на его основе, но это ещё сложнее и непрактичнее, нежели работа с виртуалками.
Ну а типовой выход такой, что в контейнер загоняем только инструменты для разработки, всё идеально настраиваем, подчищаем, даём сразу образу доступ к некоторому файловому ресурсу во внутренней сети, и сам проект храним за пределами контейнера. Таким образом получаем фиксированные рабочие места, которые можно запускать где угодно.
Нюанс опять в том, что докер на вашей конкретной машине надо всё равно конфигурировать локально :) Могут быть проблемы с правами доступа компиляторов в контейнере к каталогу с проектами, а в привилегированном режиме запускать докер нежелательно. Ещё неприятность, что проектные файлы на хосте, с которыми ведётся работа из разных контейнеров, могут получать очень странные permissions :) Это уже проблема самого докера в связи с правами и безопасностью, они могут тащиться с компьютера-хоста. И наконец, для такой схемы работы с контейнерами придётся запоминать настройки командной строки....
Резюме такое, что выбор между виртуалками и контейнерами неоднозначный,
и если цель -- прежде всего единообразие платформы разработки, которая редко конфигурируется или обновляется, для всех разрабов, то лучше взять докер, но придётся его вручную как следует допилить удобными скриптами, ну и поизучать доки.
Если же у каждого кодера своя, довольно уникальная роль в проекте, и свой набор инструментов, который часто обновляется, то лучше выбрать виртуалки и немного проапгрейдить под них железо.
А я предупреждал! Вот уже автоматический code reviewer появился
https://aws.amazon.com/codeguru/
и те, кто пытается попасть "поскорее в профессию" через веб-фреймворки, а не через computer science, продолжат стремительно терять в своей и без того невысокой ценности.
Сегодня буквально уже ежемесячно такие AI-усиленные фичи для программистов выходят. А вот для тех, кто хорошо разбирается в cs, они наоборот будут дополнительным усилением.
Слабые слабеют, сильные сильнеют :)
https://aws.amazon.com/codeguru/
и те, кто пытается попасть "поскорее в профессию" через веб-фреймворки, а не через computer science, продолжат стремительно терять в своей и без того невысокой ценности.
Сегодня буквально уже ежемесячно такие AI-усиленные фичи для программистов выходят. А вот для тех, кто хорошо разбирается в cs, они наоборот будут дополнительным усилением.
Слабые слабеют, сильные сильнеют :)
9 карьерных ловушек
по материалам
https://www.infoworld.com/article/3270728/9-career-pitfalls-every-software-developer-should-avoid.html
1. Надолго застревать в одной технологии
В конце 1990-х, когда начался хайп вокруг проблемы 2000-го года и спешно переписывались и правились миллиарды строк, программисты на Коболе получали 300 долларов в час. И хотя и сегодня под некоторые кобол-проекты набирают 70-летних старцев, в целом найти работу по легаси-технологии (как минимум, под боком, без релокации) нереально.
Или, например, в начале 21-го века, когда расцвели завышенные ожидания в отношении Java на фоне бума дот-комов, такие же суммы, сотни долларов в час, платили программистам-консультантам на Java. Сегодня же крупные компании набирают их на галеры оптом по дешёвке.
Не совсем очевидное следствие из того, что застревать в легаси плохо, заключается в том, что наоборот вовремя попасть в новую технологию может быть очень круто. Сегодня это в частности машинное обучение, искусственный интеллект за пределами нейросетей, новые, мультипарадигмальные языки программирования с оригинальными фичами, и т. д.
2. Ставить всё на одну технологию
Входить в модную горячую тему тоже надо с умом -- по схеме хеджирования ставок (снижаем риск потери от провала ставки через параллельную ставку на противоположный или другой исход). Вроде бы, стремиться поскорее стать экспертом в доминирующей теме здорово -- но и конкуренция в стремительно взлетающих нишах тоже высочайшая. Поэтому продумайте план выхода.
Отслеживайте набирающие популярность технологии и языки программирования, схожие и ближайшие к используемым вами, и изучайте их в объёме, достаточном для создания проекта на тысячу строк (20% изученного дадут 80% результата). В таком случае вы сможете при необходимости очень быстро переключиться в подходящую сферу, и кроме того, здорово расширите свое видение программирования в целом.
продолжение следует
по материалам
https://www.infoworld.com/article/3270728/9-career-pitfalls-every-software-developer-should-avoid.html
1. Надолго застревать в одной технологии
В конце 1990-х, когда начался хайп вокруг проблемы 2000-го года и спешно переписывались и правились миллиарды строк, программисты на Коболе получали 300 долларов в час. И хотя и сегодня под некоторые кобол-проекты набирают 70-летних старцев, в целом найти работу по легаси-технологии (как минимум, под боком, без релокации) нереально.
Или, например, в начале 21-го века, когда расцвели завышенные ожидания в отношении Java на фоне бума дот-комов, такие же суммы, сотни долларов в час, платили программистам-консультантам на Java. Сегодня же крупные компании набирают их на галеры оптом по дешёвке.
Не совсем очевидное следствие из того, что застревать в легаси плохо, заключается в том, что наоборот вовремя попасть в новую технологию может быть очень круто. Сегодня это в частности машинное обучение, искусственный интеллект за пределами нейросетей, новые, мультипарадигмальные языки программирования с оригинальными фичами, и т. д.
2. Ставить всё на одну технологию
Входить в модную горячую тему тоже надо с умом -- по схеме хеджирования ставок (снижаем риск потери от провала ставки через параллельную ставку на противоположный или другой исход). Вроде бы, стремиться поскорее стать экспертом в доминирующей теме здорово -- но и конкуренция в стремительно взлетающих нишах тоже высочайшая. Поэтому продумайте план выхода.
Отслеживайте набирающие популярность технологии и языки программирования, схожие и ближайшие к используемым вами, и изучайте их в объёме, достаточном для создания проекта на тысячу строк (20% изученного дадут 80% результата). В таком случае вы сможете при необходимости очень быстро переключиться в подходящую сферу, и кроме того, здорово расширите свое видение программирования в целом.
продолжение следует
InfoWorld
9 career pitfalls every software developer should avoid
If you love to code, and don’t think much about your career or your business, it’s time to get real and rethink how you approach software development
9 карьерных ловушек
3. Оставаться влюблённым в странные вещи
Ruby, Groovy, Erlang -- по своему мощные и прекрасные языки, однако их магия давно исчезла. Вы не получите надбавки к зарплате за знание этих языков. Если ваш начальник разрешит вам программировать в проекте на этих языках, то это потому, что либо ему всё равно, либо то, что вы делаете, не очень важно в целом, а он просто хочет вас поддержать, либо он не в курсе, что таких экзотических программистов находить всё сложнее и сложнее.
Поэтому, с одной стороны очень полезно быстро въезжать во взлетающие технологии. Полезно быть одним из первых, кто разберётся с ними, и преподаст себя в качестве эксперта.
Однако также будьте готовы к выходу, когда спрос упадёт. Всегда есть и будут другие новые увлекательные технологии, на которые можно переключиться.
4. Игнорировать политические игры в компании
Каждая организация, независимо от того, большая она или маленькая, имеет какую-то корпоративную политику. Так что вам полезно оттачивать свои "социально-политические" навыки. Если вы думаете, что можете оставаться за пределами таких игр, то на самом деле просто будете пешкой в чужих играх. Как минимум, придерживайтесь политики, явно защищающей ваши интересы.
продолжение следует
3. Оставаться влюблённым в странные вещи
Ruby, Groovy, Erlang -- по своему мощные и прекрасные языки, однако их магия давно исчезла. Вы не получите надбавки к зарплате за знание этих языков. Если ваш начальник разрешит вам программировать в проекте на этих языках, то это потому, что либо ему всё равно, либо то, что вы делаете, не очень важно в целом, а он просто хочет вас поддержать, либо он не в курсе, что таких экзотических программистов находить всё сложнее и сложнее.
Поэтому, с одной стороны очень полезно быстро въезжать во взлетающие технологии. Полезно быть одним из первых, кто разберётся с ними, и преподаст себя в качестве эксперта.
Однако также будьте готовы к выходу, когда спрос упадёт. Всегда есть и будут другие новые увлекательные технологии, на которые можно переключиться.
4. Игнорировать политические игры в компании
Каждая организация, независимо от того, большая она или маленькая, имеет какую-то корпоративную политику. Так что вам полезно оттачивать свои "социально-политические" навыки. Если вы думаете, что можете оставаться за пределами таких игр, то на самом деле просто будете пешкой в чужих играх. Как минимум, придерживайтесь политики, явно защищающей ваши интересы.
продолжение следует
9 карьерных ловушек
5. Демонстрировать незаинтересованность в бизнесе компании
Я просто программист, я не интересуюсь бизнес-задачами.
Это просто карьерное самоубийство. У вашей компании всё хорошо? Каковы её основные бизнес-задачи? Какие у нее самые важные проекты? Как технологии и софт помогают в их достижении? Какова ваша роль в этом? Если вы не заморачиваетесь ответами на эти вопросы, если вы демонстрируете свою отрешённость от корпоративных интересов, вы так и будете работать над неактуальными проектами для неактуальных людей в неактуальных компаниях за относительно неактуальную сумму денег.
6. Иметь "профсоюзную" ментальность
Ситуация, когда пожилой человек, которому остаётся полгода до пенсии, уходит в отпуск, тебя назначают на его проект, и ты за две недели доделываешь его до конца и ждёшь похвалы. Однако дед, вернувшись из отпуска, начинает на тебя всячески жаловаться, и после этого долго постоянно ябедничает до самой пенсии.
В довольно большом количестве контор царит такая ментальность: не торопись, не высовывайся, не перевыполняй норму, не проявляй много инициативы и активности. Рекомендация, что конечно не увязайте в таком болоте, всегда старайтесь развиваться, однако будьте готовым ко всему, и имейте в виду, что отношение к вашей ударной работе вполне может быть совсем не таким, как вы ожидаете. Если ситуация печальная, то у вас всегда есть возможность проголосовать ногами.
продолжение следует
5. Демонстрировать незаинтересованность в бизнесе компании
Я просто программист, я не интересуюсь бизнес-задачами.
Это просто карьерное самоубийство. У вашей компании всё хорошо? Каковы её основные бизнес-задачи? Какие у нее самые важные проекты? Как технологии и софт помогают в их достижении? Какова ваша роль в этом? Если вы не заморачиваетесь ответами на эти вопросы, если вы демонстрируете свою отрешённость от корпоративных интересов, вы так и будете работать над неактуальными проектами для неактуальных людей в неактуальных компаниях за относительно неактуальную сумму денег.
6. Иметь "профсоюзную" ментальность
Ситуация, когда пожилой человек, которому остаётся полгода до пенсии, уходит в отпуск, тебя назначают на его проект, и ты за две недели доделываешь его до конца и ждёшь похвалы. Однако дед, вернувшись из отпуска, начинает на тебя всячески жаловаться, и после этого долго постоянно ябедничает до самой пенсии.
В довольно большом количестве контор царит такая ментальность: не торопись, не высовывайся, не перевыполняй норму, не проявляй много инициативы и активности. Рекомендация, что конечно не увязайте в таком болоте, всегда старайтесь развиваться, однако будьте готовым ко всему, и имейте в виду, что отношение к вашей ударной работе вполне может быть совсем не таким, как вы ожидаете. Если ситуация печальная, то у вас всегда есть возможность проголосовать ногами.
продолжение следует
9 карьерных ловушек
7. Не заботиться о своей ценности
Это вообще пожалуй самый ужасающий баг в карьере :)
"Я тут не из-за денег". Ну тогда займись хобби. Не ходи на работу каждый день во что бы то ни стало, думая о своей следующей тысяче рублей.
Но будь последовательным -- не ходи также и на такую работу, где зарабатываешь вполовину меньше, чем все остальные.
Знай свою ценность, и стабильно наращивай её.
8. Думать, что дело только в деньгах
Чем выше у человека квалификация, тем меньше он готов работать с другими людьми только за деньги. Работа -- это существенная вещь в жизни, в которую можно вложить все свои силы и получить хороший результат. Я хочу работать только с теми, кто увлечён своей работой. А что насчет тебя?
С другой стороны -- не будь занудой. Если ты на работе всерьёз паришься, что лучше -- пробелы или табы, лучше попринимай таблеточки.
9. Относиться к своей работе просто как к работе
"Это просто работа". Нет, это шаг в твоей карьере. Ты не будешь на этой работе вечно. И чему же ты сможешь здесь научиться? Какой следующий шаг? Кто ты там, в будущем, где в конце концов ты хочешь оказаться? Как эта работа поможет тебе попасть туда?
Развивай стратегическое понимание всей своей карьеры и профессии в целом. Это не просто работа, это путешествие длиною в жизнь.
7. Не заботиться о своей ценности
Это вообще пожалуй самый ужасающий баг в карьере :)
"Я тут не из-за денег". Ну тогда займись хобби. Не ходи на работу каждый день во что бы то ни стало, думая о своей следующей тысяче рублей.
Но будь последовательным -- не ходи также и на такую работу, где зарабатываешь вполовину меньше, чем все остальные.
Знай свою ценность, и стабильно наращивай её.
8. Думать, что дело только в деньгах
Чем выше у человека квалификация, тем меньше он готов работать с другими людьми только за деньги. Работа -- это существенная вещь в жизни, в которую можно вложить все свои силы и получить хороший результат. Я хочу работать только с теми, кто увлечён своей работой. А что насчет тебя?
С другой стороны -- не будь занудой. Если ты на работе всерьёз паришься, что лучше -- пробелы или табы, лучше попринимай таблеточки.
9. Относиться к своей работе просто как к работе
"Это просто работа". Нет, это шаг в твоей карьере. Ты не будешь на этой работе вечно. И чему же ты сможешь здесь научиться? Какой следующий шаг? Кто ты там, в будущем, где в конце концов ты хочешь оказаться? Как эта работа поможет тебе попасть туда?
Развивай стратегическое понимание всей своей карьеры и профессии в целом. Это не просто работа, это путешествие длиною в жизнь.
Ещё одна коварная ловушка -- устроиться на работу, где хорошо платят, а программирование в спокойном режиме. Это очень опасная ситуация, когда расслабляешься и на работе, так как нету вызовов, и после работы, когда вроде много денег и начинаешь ими разбрасываться. Весьма часто она заканчивается тем, что в компании начинается сокращение, и тебя внезапно увольняют в самых первых рядах :-)
При том, что ты ведь мог потратить кучу времени на работе не впустую, а для повышения своего профессионального уровня, чтобы например точно сохранить за собой эту должность. В конце концов, можно было просто регулярно изучать то, что пользуется спросом на рынке труда, и усиливать свою квалификацию, а не метаться в последний момент и лихорадочно скачивать "типовые вопросы на интервью".
При том, что ты ведь мог потратить кучу времени на работе не впустую, а для повышения своего профессионального уровня, чтобы например точно сохранить за собой эту должность. В конце концов, можно было просто регулярно изучать то, что пользуется спросом на рынке труда, и усиливать свою квалификацию, а не метаться в последний момент и лихорадочно скачивать "типовые вопросы на интервью".
repl.it запускает code jam с 10 по 31 августа: надо разработать свой язык программирования, и кто запилит действительно стоящий проект, получит приз 10,000 долларов.
Хотелось бы верить, что выиграет проект в духе вот такого например
https://github.com/cedille/cedille
но это вряд ли.
Подробнее и туториалы по теме:
https://blog.repl.it/langjam
Хотелось бы верить, что выиграет проект в духе вот такого например
https://github.com/cedille/cedille
но это вряд ли.
Подробнее и туториалы по теме:
https://blog.repl.it/langjam
GitHub
GitHub - cedille/cedille: Cedille, a dependently typed programming languages based on the Calculus of Dependent Lambda Eliminations
Cedille, a dependently typed programming languages based on the Calculus of Dependent Lambda Eliminations - GitHub - cedille/cedille: Cedille, a dependently typed programming languages based on the...
После относительного спада количество айтишных вакансий медленно но уверенно начало восстанавливаться, сообщила некоммерческая ассоциация CompTIA. По данным на конец июня, количество вакансий в США достигло 263 тысяч. На программистов спрос почти 83 тысячи предложений. В феврале-марте вакансий было 350 тысяч, в мае их количество провалилось до 200 тысяч.
В целом всё позитивно: стабильно растут сектора разработки, ИТ-суппорта, облачных инфраструктур и информационной безопасности.
https://www.comptia.org/newsroom/press-releases/2020/07/02/tech-job-gains-confirm-pockets-of-strength-in-recovering-labor-market
Интересно, кто больше всех хантит: айтишники Amazon и IBM, финтех Wells Fargo, медики Anthem Blue Cross, производитель бытовых инструментов (внезапно) Stanley Black & Decker, и военные Northrop Grumman и Boeing.
В целом всё позитивно: стабильно растут сектора разработки, ИТ-суппорта, облачных инфраструктур и информационной безопасности.
https://www.comptia.org/newsroom/press-releases/2020/07/02/tech-job-gains-confirm-pockets-of-strength-in-recovering-labor-market
Интересно, кто больше всех хантит: айтишники Amazon и IBM, финтех Wells Fargo, медики Anthem Blue Cross, производитель бытовых инструментов (внезапно) Stanley Black & Decker, и военные Northrop Grumman и Boeing.
Очередное исследование популярности языков программирования, на этот раз весьма серьёзное -- от авторитетнейшего Института инженеров электротехники и электроники IEEE, разработчика множества ИТ-стандартов.
Резюме двумя словами: доминирование Python. Второй Java, далее Си, С++ и JavaScript.
Надо конечно учитывать определённую специфику IEEE -- прежде всего инженеры-электронщики, которым нужен мощный и простой технический инструмент программирования и вычислений, и чтобы его можно было легко освоить. В некотором смысле Python сегодня -- как Basic в 1980-1990-е :-) Ну и конечно широчайшая популярность Python и в веб-разработке, и в научных вычислениях, и в машинном обучении, и как стандартный язык прикладного программирования во всех дистрибутивах Linux.
https://spectrum.ieee.org/at-work/tech-careers/top-programming-language-2020
Резюме двумя словами: доминирование Python. Второй Java, далее Си, С++ и JavaScript.
Надо конечно учитывать определённую специфику IEEE -- прежде всего инженеры-электронщики, которым нужен мощный и простой технический инструмент программирования и вычислений, и чтобы его можно было легко освоить. В некотором смысле Python сегодня -- как Basic в 1980-1990-е :-) Ну и конечно широчайшая популярность Python и в веб-разработке, и в научных вычислениях, и в машинном обучении, и как стандартный язык прикладного программирования во всех дистрибутивах Linux.
https://spectrum.ieee.org/at-work/tech-careers/top-programming-language-2020
IEEE Spectrum
Top Programming Languages 2020
Python rules the roost, but Cobol gets a pandemic bump
Глубокомысленное исследование North Carolina State University и Microsoft внезапно выявило факт, о котором раньше как будто бы никто и не знал (это сарказм :).
https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/
Оказывается, если в ходе собеседования программисту приходится писать решение/код фломастером на доске перед некоторой аудиторией, попутно рассказывая, что он делает, то он показывает в два раза худшие результаты, нежели если бы он как обычно писал код за компьютером, а интервьюер просто следил за его экраном со своего компа. В результате отсеивается приличный процент действительно хороших специалистов, так как собеседование фактически подразумевает скиллы, сильно далёкие от тех, что потребуются на повседневной работе.
И следствие отсюда по Кэпу Очевидность, что и кадровые агентства этим занимаются, и сами кандидаты это хорошо знают и практикуются, и я на курсе карьеры подчёркиваю: к успешному прохождению интервью надо готовиться целенаправленно, чётко понимая, что это совершенно отдельный набор скиллов, к прямой работе особого отношения не имеющий. Ну и вот в Microsoft этим обеспокоились, видимо поднабрали ребят, которые хорошо выступают у доски и красиво вешают лапшу на уши :-)
https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/
Оказывается, если в ходе собеседования программисту приходится писать решение/код фломастером на доске перед некоторой аудиторией, попутно рассказывая, что он делает, то он показывает в два раза худшие результаты, нежели если бы он как обычно писал код за компьютером, а интервьюер просто следил за его экраном со своего компа. В результате отсеивается приличный процент действительно хороших специалистов, так как собеседование фактически подразумевает скиллы, сильно далёкие от тех, что потребуются на повседневной работе.
И следствие отсюда по Кэпу Очевидность, что и кадровые агентства этим занимаются, и сами кандидаты это хорошо знают и практикуются, и я на курсе карьеры подчёркиваю: к успешному прохождению интервью надо готовиться целенаправленно, чётко понимая, что это совершенно отдельный набор скиллов, к прямой работе особого отношения не имеющий. Ну и вот в Microsoft этим обеспокоились, видимо поднабрали ребят, которые хорошо выступают у доски и красиво вешают лапшу на уши :-)
Есть такая классическая проблема двух генералов. Две армии окружили город с двух сторон, но у них нет связи друг с другом. Город можно захватить, только если атаковать одновременно, поодиночке каждая армия погибнет.
Можно послать посыльного, но весьма вероятно, что его перехватят, и как 1-й генерал узнает, что он доставил сообщение о времени начала атаки? 2-й генерал может отправить ответного посыльного, но как он сам узнает, что 1-й генерал получит его? А вдруг его перехватят, и 1-й генерал решит, что и первый посыльный не добрался, и отложит атаку...
Проблема эта решения не имеет. Она часто упоминается на курсах по сетям при изучении протоколов TCP/UDP.
По этой причине создание распределённых систем -- тяжёлая задачка, и достичь 100% надёжности невозможно. Едва только возникает режим взаимодействия серверов, мы обречены на вероятности. А ведь с ростом популярности модели serverless вообще абсолютно всё становится распределённым :)
Правильный распределённый бэкенд должен базироваться на трёх архитектурных принципах:
-- Всё что может сломаться (а может сломаться всё что угодно), рано или поздно сломается;
-- Система всё равно должна продолжать работать;
-- Сбои должны легко фикситься.
Какими подходами этого достичь, рассмотрим далее.
Можно послать посыльного, но весьма вероятно, что его перехватят, и как 1-й генерал узнает, что он доставил сообщение о времени начала атаки? 2-й генерал может отправить ответного посыльного, но как он сам узнает, что 1-й генерал получит его? А вдруг его перехватят, и 1-й генерал решит, что и первый посыльный не добрался, и отложит атаку...
Проблема эта решения не имеет. Она часто упоминается на курсах по сетям при изучении протоколов TCP/UDP.
По этой причине создание распределённых систем -- тяжёлая задачка, и достичь 100% надёжности невозможно. Едва только возникает режим взаимодействия серверов, мы обречены на вероятности. А ведь с ростом популярности модели serverless вообще абсолютно всё становится распределённым :)
Правильный распределённый бэкенд должен базироваться на трёх архитектурных принципах:
-- Всё что может сломаться (а может сломаться всё что угодно), рано или поздно сломается;
-- Система всё равно должна продолжать работать;
-- Сбои должны легко фикситься.
Какими подходами этого достичь, рассмотрим далее.
Есть несколько стратегий обеспечения надёжности (их можно пересчитать на пальцах полутора рук), которые надо уметь пропорционально комбинировать в своих проектах.
1. Изоляция багов.
Помните эпический сбой интернета весной 2017-го?
Инженеры AWS ничтоже сумняшеся решили провести эксперимент на живой системе :-) А давайте отключим несколько серверов S3 и посмотрим, что получится? (серьёзно). Отлаживался балансировщик нагрузки, и как всегда что-то пошло не так -- отключилось слишком много серверов, нагрузка на остальные резко возросла, ну и они посыпались.
А так как на S3 как на хранилище файлов завязана по сути вся AWS, то поломалась и её существенная часть. А на AWS завязана половина интернета...
То есть ошибки надо изолировать, чтобы они не вызывали каскадные отключения. Как? снижением числа внутренних взаимосвязей в системе. Например, тормоза в автомобиле будут работать до последнего, даже если существенная часть других подсистем вышла из строя (правда, хакеры добираются до тормозов через музыкальные подсистемы...).
Три правила:
1. У каждой операции в системе единственная ответственность.
2. Каждая операция атомарна (и в идеале работает как транзакция с возможностью отката если что-то пошло не так).
3. Количество взаимосвязей между операциями минимизируется.
Механизм serverless например хорошо для этого подходит и поощряет такую практику.
Например, в случае AWS надо было критически важные файлы хранить в нескольких резервных режимах, потому что тогда даже дашборды AWS затупили просто потому, что их иконки хранились на S3.
1. Изоляция багов.
Помните эпический сбой интернета весной 2017-го?
Инженеры AWS ничтоже сумняшеся решили провести эксперимент на живой системе :-) А давайте отключим несколько серверов S3 и посмотрим, что получится? (серьёзно). Отлаживался балансировщик нагрузки, и как всегда что-то пошло не так -- отключилось слишком много серверов, нагрузка на остальные резко возросла, ну и они посыпались.
А так как на S3 как на хранилище файлов завязана по сути вся AWS, то поломалась и её существенная часть. А на AWS завязана половина интернета...
То есть ошибки надо изолировать, чтобы они не вызывали каскадные отключения. Как? снижением числа внутренних взаимосвязей в системе. Например, тормоза в автомобиле будут работать до последнего, даже если существенная часть других подсистем вышла из строя (правда, хакеры добираются до тормозов через музыкальные подсистемы...).
Три правила:
1. У каждой операции в системе единственная ответственность.
2. Каждая операция атомарна (и в идеале работает как транзакция с возможностью отката если что-то пошло не так).
3. Количество взаимосвязей между операциями минимизируется.
Механизм serverless например хорошо для этого подходит и поощряет такую практику.
Например, в случае AWS надо было критически важные файлы хранить в нескольких резервных режимах, потому что тогда даже дашборды AWS затупили просто потому, что их иконки хранились на S3.
Количество вакансий для программистов в США практически вернулось к исходному уровню перед пандемией, по данным Dice Tech Job Report.
https://insights.dice.com/2020/07/28/dice-tech-job-report-q2-offers-optimism-tech-industry/
Топовым хантером этим летом стал Амазон, берёт всех подряд, Java C++ ML... Интересно, что не особо отстают от него по активности крупнейшие военные подрядчики General Dynamics и Northrop Grumman.
Аж на 51% вырос спрос на Data Engineer (видимо, имеется в виду и data science, и бигдата, и классические базы данных). Техподдержка подросла на 30-35%, программисты -- на 31%, и отдельно на Java-сеньоров большой спрос, +30%.
https://insights.dice.com/2020/07/28/dice-tech-job-report-q2-offers-optimism-tech-industry/
Топовым хантером этим летом стал Амазон, берёт всех подряд, Java C++ ML... Интересно, что не особо отстают от него по активности крупнейшие военные подрядчики General Dynamics и Northrop Grumman.
Аж на 51% вырос спрос на Data Engineer (видимо, имеется в виду и data science, и бигдата, и классические базы данных). Техподдержка подросла на 30-35%, программисты -- на 31%, и отдельно на Java-сеньоров большой спрос, +30%.
Dice Insights
Dice Tech Job Report: Q2 Offers Optimism for Tech Industry
How is the COVID-19 pandemic impacting the job market? The latest edition of the Dice Tech Job Report analyzed data from the second quarter, giving us a fuller picture of how employers are dealing with the current landscape.
Правила изоляции багов (продолжение темы про обеспечение надёжности).
1. У каждой операции в системе единственная ответственность.
Каждая функция, каждый метод должен делать что-то одно (на курсах по ООАП мы подробно этот момент разбираем). Например, функция не должна менять какое-то состояние и одновременно возвращать справочную информацию: либо изменение состояния, либо выдача данных гарантированно без модификации состояния.
Лайфках тут простой: если в комментариях, что делает функция, вы пишете "то И сё" (имеется союз И), значит её надо дробить.
1. У каждой операции в системе единственная ответственность.
Каждая функция, каждый метод должен делать что-то одно (на курсах по ООАП мы подробно этот момент разбираем). Например, функция не должна менять какое-то состояние и одновременно возвращать справочную информацию: либо изменение состояния, либо выдача данных гарантированно без модификации состояния.
Лайфках тут простой: если в комментариях, что делает функция, вы пишете "то И сё" (имеется союз И), значит её надо дробить.