Программист
В последнем посте я рассказывал о Kubernetes, о том, как ThoughtSpot использует его для собственных нужд по поддержке разработки. Сегодня хотелось бы продолжить разговор о короткой, но от того не менее интересной истории отладки, которая произошла совсем недавно. Статья базируется на том, что containerization != virtualization. К тому же наглядно показывается, как контейнеризированные процессы конкурируют за ресурсы даже при оптимальных ограничениях по cgroup и высокой производительности машины.
Это, пожалуй, самая интересная статья о перспективах применения смарт-контрактов в деловой практике, которая мне попадалась (правда, попадалось их не так уж много). Она написана юристами и опубликована в конце мая на сайте Гарварда. Хоть и на примере США, текст раскрывает такие вопросы как применение законодательства к сделкам на смарт-контрактах, проблему понимания сторонами кода, проблему оракулов, риски и другие.
В том числе вы найдете объяснение, почему вендинговые аппараты (как пример наиболее наглядной и простой реализации смарт-контракта) люди используют давно и успешно, а использование более сложных смарт-контрактов, например в логистике или страховании, пока затруднительно.
Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»
У Go есть некоторые замечательные свойства, которым посвящён раздел «Хороший». Но когда речь заходит о применении этого языка не для создания API или сетевых серверов (для чего он и был разработан), а для реализации бизнес-логики, то я считаю Gо слишком неуклюжим и неудобным. Хотя даже в рамках сетевого программирования найдётся немало подводных камней как в архитектуре языка, так и в реализации, что делает Go опасным, несмотря на его кажущуюся простоту.
| Концепция | Описание |
|---|---|
| Атомарная операция — это операция, которая выполняется полностью или не выполняется совсем, частичное выполнение невозможно. | |
| Visibility (видимость) | Условия, при которых один поток видит изменения, сделанные другим потоком |
Не понимаю желания ностальгировать на старые фотографии. Но девчонок не переделаешь, поэтому пришлось подумать про хранилище для всех, чтобы больше не приставали показать с компа карапузов и котиков. В публичное облако выкладывать все фотки подряд не хочется.
Ресурс работы SSD накопителя теоретически не ограничен, если не превышать количество циклов перезаписи в ячейку.
Сделать систему хранения и просмотра домашнего фотоархива с любого устройства в доме,
и убрать подальше на ближайшие 10 или 20 лет. При этом иметь возможность залить и посмотреть фотки с любого устройства подключенного к internet не использую публичные сервисы хранения и не устанавливая дополнительного клиентского ПО.
Выбор железок дело субъективное, но для себя сформулировал требование к малому формфактору. Кроме того все что скрыто от глаз в квартире, как правило лежит в пожароопасном месте, по этому хотелось питание в по USB, и минимум проводов.
В компании, где я работаю — большинство сервисов запускаются и работают в docker-контейнерах.
В связи с этим, у моих коллег-новичков-в-докере часто возникает вопрос — а как писать код и запускать его в этом чёртовом контейнере???
Для человека, написавшего около сотни docker-образов и запускающего их несколько раз в день — такой вопрос уже не стоит, но когда я разбирался с докером в давние времена — мысль "Как же писать код в докере? Это же сверхнеудобно!" долго была актуальной.
В статье я опишу свои практики работы с образами docker, которые позволяют писать код "как у себя в home", и даже лучше.
