немножко дезигна

I Type NY: шрифтовой веб-эксперимент, иллюстрирующий впечатления от транспорта в Нью-Йорке. Много скролла — http://bit.ly/2VgOYHF

Гигантская, но крутая преза от Яндекс.Денег по теме
"Прикладная криптография и защита информации: базовые понятия и техники криптографии, протоколы TLS/SSL"
https://yadi.sk/i/Qew5KVpiXRBI4Q

ну а пока ребята думают как в постгресе сделать рубильник для материализации CTE, в Sql Server в 2019 году IN сканирует индексы:

курсы от Вышки и Яндекса по Data Science: https://elearning.hse.ru/news/231200464.html

чутка Куберовских сетей:
статья https://morioh.com/p/ecb38c8342ba/an-illustrated-guide-to-kubernetes-networking
и пару докладов: https://youtu.be/rLF-CqPhdaI
https://youtu.be/knIJEzTd3kc

Последний, от Google, про то как это добро траблшутить

Вот такая телега подъехала: https://channel9.msdn.com/Events/dotnetConf/2018/S205

Кому лень смотреть, теперь можно дебажить .Net прямо в k8s. Сейчас все, конечно, сыровато и, в целом, больше вопросов чем ответов(что с лимитами по ресурсам на кластере, как жить с этим, если комманда большая и несколько разрабов запустят дебаг одновременно и т.д.), но выглядит очень перспективно. Жаль что работает пока только для Azure AKS.

Распределенный кеш от Netflix на базе memcached https://github.com/Netflix/evcache/wiki

Рисование на чистом CSS. Топ 5 CSS свойств, на которые я полагаюсь при создании CSS искусства

http://diana-adrianne.com/how/

Для тех кто все еще хочет нормальную профессию)

​​📖 Руководство по Figma

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

Фигма — единственный графический редактор, который делает возможным совместную работу дизайнеров и разработчиков над интерфейсными макетами и спецификациями в реальном времени.

Скачать

@itlibrary

Вэб-комикс про сети от Julia Evans:

https://wizardzines.com/zines/networking/

#linux #networking

Брошура по архитектуре с использованием NoSql-баз от Aerospike: https://www.infoq.com/vendorcontent/show.action?vcr=5039

Вот только вопрос как из https://habr.com/ru/post/439104/ получилось раздуть столько бойлерплейта? Только вдумайтесь, что бы написать простое приложение на React+Redux надо написать: компонент, props к нему, коннектор, фабрику actions, сами actions, редьюсеры, саги\thunk'и, стор. И это если у вас не TypeScript, иначе еще надо определить кучу типов, интерфейсов и констант. И все это удовольствие нужно для того что бы создать один экран с простой формой. Фронтенд, что ты делаешь, аххахха, прекрати

DC/OS в версии 1.11 добавил поддержку Kubernetes.

Для тех кто не в курсе - DC/OS это уровень абстракции над Mesos, и в качестве контейнерной оркестрации там используется Marathon.
Разумеется, DC/OS проигрывает в битве с Kubernetes, и не важно почему: хайп, Google, you name it - причин там очень много.

Поняв, что конкурировать с кубером в поле контейнерной оркестрации нельзя, Mesosphere сделала следующее. Выпустила распрекрасный блог пост о том, что “Кубер нам не конкурент, мы вон, смотрите, даже внедрили его поддержку”. (https://mesosphere.com/blog/the-docker-vs-kubernetes-vs-apache-mesos-myth/)

Любой куберовод задастся вполне логичным вопросом: зачем мне поднимать кластер DC/OS и ставить на него Kubernetes, когда я могу сразу поставить Kubernetes? Вопрос вполне себе валидный.

В свою очередь DC/OS помимо оркестрации предлагает запуск различных сервисов. То есть непосредственно на фреймворке Mesos вы можете запустить кластер Kafka, балансировщики, ElasticSearch, Jenkins, Cassandra… Да в целом много всего. Самое смешное, что это все еще контейнеры запущенные на уровне Marathon’а, но пользователь видит их как отдельные сервисы.

Штука, на самом деле прикольная. Ну а что? Получается такой себе cloud provider на коленке. Хочешь какой-то сервис (будь он stateful или stateless) - выбери из каталога, да установи. Если его в каталоге нет, то запакуй его в “правильном” формате да и выкати. Удобно.

Вот только у Кубера есть операторы, которые (как я понял из документации) делают ровно тоже самое.
Посему вопрос остается прежним. Зачем нужен DC/OS?

Ну ваще зачем нужен Mesos-то понятно: в инфраструктуре нельзя обойтись только контейнерами. Всегда будут RDBMS, которые в контейнер ставить грешно, кластера всяких Хадупов-Кликхаусов, которые вроде можно и поставить в контейнер, но хз зачем, и вот тут, типа, Mesos и аналоги вылазят из своих болот. Но вот зачем нужна прослойка в виде Marathon'а — непонятно, ведь унифицировать ландшафт можно и просто загнав куб в марафон

Раз уж сегодня маленькая пятница, то вот прикольная статья про разные "законы" в IT: https://vk.com/@javarush-izvestnye-zakony-mira-razrabotki

От себя еще добавлю вот этот: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%90%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0
и вот этот: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9B%D0%B8%D1%82%D1%82%D0%BB%D0%B0

Интересный рамс за процессы в Amazon: http://highscalability.com/blog/2019/3/4/how-is-software-developed-at-amazon.html

Наиболее интересным мне показалось вот это:
- Developers on a team are responsible for architecture, the architecture doesn't come from architects. Once they have an architecture it's reviewed with an architect or a principal engineer. The role of a principal engineer is to review and teach, not do the architecture. Same with security. The role of a security engineer is not to create the threat model, that's a developer in the team, they review threat models. Same with testing. A team owns the entire process. A lot of time is spent teaching because you want developers to learn.

- The best way to plan is bottom up. Teams closest to the product are closest to the customer. They know what the customer wants. The people closest to the customer should tell Amazon what to do. Every year there are two docs OP1 and OP2 (Operating Plan). Every organization level writes a 6 page document about what they want to do next year. In the plan you say what you would do if you had flat resources and incremental resources. These 6 page business plans are presented at every level of the organization. Managers take the 6 page docs from all the teams they manage, make their own 6 page doc and present it to their management. This happens all the way up to Bezos. Resources then flow down to the teams.