Category: it

Category was added automatically. Read all entries about "it".

Cloud native

AWS недавно выкатил свой способ описывать инфраструктуру, способ называется CDK (cloud development kit), существенными особенностями которого являются:
  1. Использование нормальных языков программирования (typescript/python/java)
  2. Примитивы более высокого уровня (asset, pipeline, ...) и можно писать свои
  3. Трансляция в Cloud Formation и Cloud Assembly
  4. Поддержка производителя
Так же попутно выяснилось что в AWS можно держать весь цикл разработки (source code -> build pipeline -> deployments), и управлять доступом ко всему единообразно (AWS IAM).

Описал один и тот же deployment двумя способами (typescript/python), и что могу сказать:
  1. typescript подходит больше чем python:
    1. типы и типизированные хеши сильно помогают
    2. сам cdk написан на typescript, и все примеры оттуда тоже
    3. минус один слой трансляции (python -> typescript -> cloudformation)
  2. AWS работает медленно: сборка AMI ~10 минут, развернуть deployment (3 az, 3 ec2, elb) в аккаунте ~10 минут
  3. cross-account deployments -- есть что улучшить: поиск AMI по имени в другом аккаунте приводит к попытке задеплоить AMI с индексом ami-00001234, без всяких ошибок до.
В целом выглядит перспективно: можно поручить разработку примитивов отдельным командам, а другие будут просто потреблять готовое стереотипным образом через интерфейс AWS Console, или любым другим удобным способом.

Однако для масштабирования потребуется некоторая дисциплина описывать зависимости между модулями, и документировать параметры (что вроде работает для CloudFormation out of the box). источник
  • Tags

Data science!

Потрясающая история: https://github.com/mrc-ide/covid-sim/issues/165, краткое содержание.

Какие-то прекрасные люди когда-то давно написали модель заражения населения на языке fortran, с которого потом другие прекрасные люди переложили на c++, и в таком виде все это жило последние 20 лет. Когда стало надо, то внезапно выяснилось что других моделей у нас для вас нет, а эти прекрасные люди на языке c++ вообще программировать не умеют, и не только на c++ (модель запущенная на тех же данных выдает разные результаты потому что race condition и memory leak). Однако полученные таким образом "результаты" используются для принятия таких судьбоносных решений как country-wide lockdown, и для написания "научных" статей в качестве приятного бонуса.

Что ставит интересный вопрос -- а как писать доказуемые программы (и, по идее, только такие и должны использоваться в научных статьях), с весьма неочевидными ответами (isabelle/hol, coq, concrete semantic, вот это всё). Однако в ближайшем будущем моделировать таки будут исключительно на языке python, про который доказать вообще ничего нельзя (динамический и без типов). Так и живем.

P.S. Ссылки:

1. https://lockdownsceptics.org/code-review-of-fergusons-model/
2. https://twitter.com/ID_AA_Carmack/status/1254872368763277313
3. https://www.whatdotheyknow.com/request/software_code_used_for_the_covid источник

Слава роботам!

Есть такой OpenAI который умеет играть в стратегические многопользовательские игры, и из последних достижений -- уверенно обыгрывает лучшие человеческие команды игроков в Dota 2. На тренировку правда уходит 10 месяцев, однако натренированная модель может быть адаптирована к изменившимся правилам существенно быстрее. Если посмотреть на человеческие войны между собой с этой точки зрения, то легко можно видеть что некоторые признаки стратегических онлайн игр есть и там: необходимость тактики и стратегии, быстрое принятие решений в условиях неполной информации, ограниченная видимость, и так же далее. Сложив одно с другим можно предсказать военные применения: летающие дроны уже есть, координацию с наземными юнитами разворачивать умеют быстро и эффективно в любой точке планеты (некоторые страны, хе-хе), а планирование (стратегия) и руководство (тактика) маленькими победоносными операциями берет на себя openai.

источник

State of affairs

Написал недавно проект на go/vue, так несколько наблюдений/соображений.

1. Управление зависимостями сейчас на каком-то фантастическом уровне (`cat go.sum | wc` = 455 штук, `yarn list --depth 0` = 1114). Эти сотни и тысячи зависимостей собираются все вместе и работают без плясок с бубном, у каждого пакета есть разработчики (разной степени живости) и доступный исходный код.

2. Microsoft таки приносит пользу пропихивая в массы Language Server Protocol, унифицированный способ редакторам текста общаться с компиляторами и интерпретаторами (определения функций и структур, ошибки видны прямо по ходу написания, etc, etc), писать с такой автоматизацией намного легче и быстрее. То, что прямо сейчас доступно для go (alpha) и vue (alpha) уже вполне работоспособно.

3. Kubernetes (вместе с docker) дает возможность формально описать приложение целиком, со всеми run-time зависимостями, порядком запуска, проверками живучести, и так далее. Разработанное таким способом приложение работает одинаково что локально (docker k8s, minikube, etc), что на реальных кластерах. Как эффективно писать сразу в k8s вопрос пока открытый (telepresence, skaffold, knative, etc).

4. Если изначально заложить cloud native в архитектуру приложения, то развертывание, масштабирование и поддержка становятся легким и приятным делом. Собственно, не так уж и много надо и закладывать: управление конфигурацией, и отсутствие общей файловой системы у разных instances.

5. Заложенная в golang идея распихивать модули по репозиториям таки имеет смысл -- можно брать части других проектов и интегрировать себе, все работает из коробки.

6. CI/CD тему можно закапывать: github actions, docker hub, argo cd и google/aws k8s позволяют разрабатывать что угодно не задумываясь ни о ci, ни о cd.

--

Если просуммировать, то писать приложения end to end сейчас очень легко, намного легче чем раньше, можно брать готовые компоненты на разных уровнях (библиотеки, куски кода из других проектов, готовые контейнеры) и собирать из этого что угодно с минимумом усилий, и это очень хорошо.

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

Есть, конечно, и обратная сторона -- всем этим надо уметь пользоваться, оправдания вида "я тут front-end developer, и ваши серверы не понимаю, и наоборот" выглядат жалко, было бы что там понимать.

И еще, собственно сами языки программирования не столь важны, как важна легкость управления зависимостями, возможность включть себе части других проектов в одну строчку (golang) действительно впечатляет.

источник
  • Tags

Еще о diversity

The Planned Obsolescence of Old Coders

tl;dr:
Lifelong programmers must keep their skills up to date, but they are in a race against time in a constantly transforming industry.

It is commendable that these companies [Microsoft, Amazon, Google, Apple] have revealed some measures of their diversity, but there is an omission: None report their age distribution.

--

Не первый раз встречаю утверждение что дескать индустрия меняется стремительно, и поэтому no country for old men. Так вот, на мой взгляд индустрия если и меняется, то только к худшему (что как раз и позволяет людям с опытом выгодно отличаться).

1. Весь этот модный DevOps вертится вокруг make и shell, и собирает ровно все те же проблемы что и 30 лет назад: разные версии shell приводят к неожиданным ошибкам в скриптах, пользоваться make и bash хипстеры не умеют потому что не положено, про аргументы команды find можно написать статью и выступить на конференции.

2. Операционная система UNIX (40 лет) никуда не делась вместе со своим дизайном, а даже наоборот -- бурно развивается. Однако принципы работы unix за все эти годы изменились незначительно, окружение работает примерно так же как и 20 лет назад.

3. TCP/IP Stack (35 лет) никуда не делся, и никуда не денется в обозримом будущем. Единственное отличие тогда от сейчас -- RFC никто не читает, и не подозревает об их существовании. Хипстеры знание об окружающем мире получают экспериментами.

4. C-образные языки (47 лет). Сами C и C++ окончательно стали нишевыми, однакось на смену им есть Golang и Rust, причем последний выглядит куда более привлекательно. Поэтому триумф Golang неизбежен. Однако принципиальных причин почему опытный C-программист не может писать на Golang или Rust примерно через неделю я не вижу, собственно, для них и придумывалось.

5. LISP (60 лет). Опять же никуда не делся, и никуда не денется. Применения таким системам будут всегда, с несущественными косметическими отличиями. Однажды научившись писать на LISP все остальные реализации осваиваются легко и непринуждённо (см. clojure, racket).

6. SQL (45 лет). Если SQL понимать как принципы хранения и работы с данными, вместе с языком описания и запросов, то это тайное знание не меняется годами, и никогда не изменится по очевидным причинам.

7. Узкоспециальные системы типа Embedded, SS7, Erlang.

8. Actor model. Под разными соусами подается начиная с 1972 года (Smalltalk), далее со всеми остановками: COM/CORBA, Erlang, Acca, теперь вот micro services architecture (о нет, только не это)

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

С другой стороны, есть технологии стремительно увядающие и исчезающие (XML, DCOM/CORBA, IPX, UML/RUP, ASP/JSP, ...), знание которых не приносит никакой пользы кроме краткосрочной. Но так надо понимать же отличие: есть явления фундаментального порядка, и есть то что называется хайп (решения продвигаемые отдельными коммерческими компаниями как универсальные). Способность отличать одно от другого достигается опытом, размышлением и упражнением.


--

А разнообразие такое разнообразие, только для особенно разнообразных. Кого сказали разнообразить, того и будут.

источник
  • Tags

И еще о DevOps

Как известно, devops это ops из которых сделали dev, причём наоборот (dev->ops) случается намного реже (вообще следовало бы различать devops и opsdev, но такого различия уже никакой отдел hr не осилит). В этой связи devops открывают для себя новый и увлекательный мир программирования со всеми метастазами типа agile, scrum, и твот ещё и ux. Что бы жизнь мёдом не казалась специально для них придумали язык go, отличительной особенностью которого является простота, и как раз та, которая хуже воровства, но основными инструментами бурной деятельности по автоматизации являются make и shell. Легко представить каких чудовищ можно наплодить таким способом, тайное знание доступно уже лет 30. Ситуация еще усугубляется тем, что результатом применения devops-усилий является "инфраструктура" понимаемая как сервера, сервисы и сети, конфигурация которых является внешним состоянием (тот самый world из "hello, world"). Бороться с этим state предлагается идеями вида immutable infrastructure, но immutable здесь значит это совсем другое -- административный запрет вносить изменения вручную.

источник
  • Tags

Go, the good parts.

При всей косорылости (aka opinionated) Go у него есть и плюсы: статическая компиляция и интерфейсы. Первое упрощает жизнь девопсам (хотя я уже видел контейнеры в которых запускается скомпилированный go бинарник), а второе управление проектами. Менеджер проекта может нанять для программирования стадо баранов и следить лишь за интерфейсами (должны быть небольшие и повсюду), тем самым изолируя части проекта друг от друга, и делая зависимости явными.

источник
  • Tags

Обращение в Erlang

Товарищ вот дал себе труд разобраться в Erlang и OTP, так первые впечатления вида я тут довольно давно распределенными системами занимался, а там это всё есть из коробки, и уже отлаженное за 20 лет применений на практике. И вот зачем городить свои распределенные системы?

источник
  • Tags

Про DevOps.

Выступал недавно с рассказами, так запишу и сюда. Последнее время термин DevOps весьма популярен [особенно у рекрутеров], однако понимание ещё не устоялось (Google, к примеру, так и вообще поясняющие видео выкладывает). Итак, приступим. Крупные фирмы внезапно открыли для себя облачные сервисы, и захотели такие же. Оказалось что по старинке такие сервисы создавать и поддерживать весьма накладно, поэтому появились идеи управлять инфраструктурой явно и декларациями, что назвается infrastructure-as-a-code (можно усмотреть параллели с недавным поветрием *-as-a-service), что переводит управление инфраструктурой фирмы в плоскость разработки программного обеспечения (где есть scrum и agile, и типа понимание как этим процессом управлять). Ввиду того что слово code подразумевает что кто-то этот код должен писать, а написанный код есть по сути описание системного администрирования, то люди которые этим занимаются получили название DevOps, и для них придумали специальный язык программирования Go (созданный дебилами для дебилов). Дальше оказалось что в описанной таким способом инфрастуктуре сами собой возникают полезные фирме сервисы (ради которых всё и затевалось), а сервисы пишут обычные разработчики, которые Dev, без Ops. Однако написанный произвольно взятым писателем код просто так без усилий в сервис не сконвертируешь, поэтому всех таких писателей активно пинают в сторону подумать как ваши поделия в облаках жить будут, что естественным образом приводит к тому же DevOps, но уже с другой стороны -- Dev.

источник
  • Tags

Куда засунуть нейросети.

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

Our initial results show, that by using neural nets we are able to outperform cache-optimized B-Trees by up to 70% in speed while saving an order-of-magnitude in memory over several real-world data sets.

источник
  • Tags