Comments 37
В тот момент, когда люди вместо того что бы чинить старое, создают новое.
Не просто создают новое, а объявляют старое безнадежным и ожидают, что новое само собой будет лучше. Вместо старых проблем получают новые, плюс в новом коде непременно будут новые (свежие, если вам так приятнее) ошибки, какое-то время правят, потом «новое» опять объявляют безнадежным, процесс продолжается бесконечно.
Наверное когда ученик из этого коана стал учителем.
Мастер Фу и десять тысяч строк
Однажды Мастер Фу сказал заезжему программисту: «В одной строке кода shell-сценария больше духа UNIX, чем в десяти тысячах строк кода на С!»

Программист, гордый своими познаниями в С, ответил: «Может ли быть такое? Ведь С — язык, в котором реализовано само ядро UNIX!»

На это Мастер Фу ответил: «Это так. Тем не менее, в одной строке shell-сценария больше духа UNIX, чем в десяти тысячах строк С!»

Программист выглядел удрученным. «Но ведь через язык С мы познаем просвещенность патриарха Ритчи! Мы уподобляемся человеку с операционной системой и компьютером, который получает непревзойденную производительность!»

Мастер Фу сказал: «То, что ты говоришь, правда. Однако в одной строке shell-сценария больше духа UNIX, чем в десяти тысячах строк С».

Программист усмехнулся и поднялся, чтобы удалиться. Но Мастер Фу кивнул своему ученику Ньюби, который писал строку shell-кода на стоящей рядом белой доске, и сказал: «Господин программист, посмотрите на этот конвейер! Не заняла бы его реализация на C десять тысяч строк?»

Просматривая то, что писал Ньюби, программист что-то бормотал в бороду. В конце концов, он согласился, что это так.

«И сколько часов потребовалось бы вам для реализации и отладки этой программы на языке С?»

«Много», — признал заезжий программист. «Но только безумец стал бы тратить столько времени, когда его ждет множество более достойных задач».

«Так кто лучше понимает дух UNIX?» — спросил Мастер Фу. «тот, кто пишет десять тысяч строк, или тот, кто, сознавая тщетность этих усилий, извлекает пользу, не программируя?»

Услышав это, программист достиг просветления.

При том что коан изначально очень мудрый. Но описанное в посте — это просто рекурсия этого коана. Учителя — ученики учеников этого ученика.
Подмена понятий. Можно написать аналогичный текст на тему «зачем мне IDE, гит, скрам, багтрекер, юнит-тесты, приемочные тесты, дженкинс, автоматический деплоймент, если я хочу написать hello world для лабораторки в универе».

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

С распределенными отказоустойчивыми системами всё то же самое.
Насколько увидел я, тут высмеивается использование over9000 технологий как раз таки для «лабораторки в универе».
Да, статья имеет несколько граней, в том числе, «не использовать модные новые технологии там, где они и правда не нужны, просто потому что это тренд». Т.е. как всегда, для каждого случая — определенный инструмент/подход.
А напишите про IDE, раз можно, а то от vim отвыкнуть не могу (даже для небольших java коннекторов к разным API).

А пост классный, я для себя много почерпнул и увидел как все это связывается во едино.

А что про IDE? IDE — это качественный автокомплит, линтер, навигация по исходникам и документации. Если вы хорошо знаете все нужные вам API и используете скриптовый язык (или автоматическую рекомпиляцию), то IDE не так уж и нужно. Но лично я слишком быстро меняю библиотеки и технологии, чтобы заучивать их наизусть.

Насчет технических подробостей в этом посте — отнеситесь аккуратно, там есть неточности.
Вы немного лукавите. Если вы всерьёз используете vim, то у вас там к нему прилагается тонна собственноручно изготовленных или подобранных конфигов и скриптов, которые обеспечивают нормальную работу. Подсветку, автокомплит, рефакторинг, вот это вот всё.
Т.е. вы по сути написали собственную IDE, взяв vim в качестве основы. Ну, а кому-то не хочется тратить время на написание IDE, и он берёт уже готовую.
Вы плохо себе представляете работу в Vim.
Чем больше вы познаете его, тем больше плагинов вы начинаете удалять.
Значит не достаточно познали еще? :D

Это не моя фраза, а из какой-то книжки, может быть practical vim, но за собой замечал такое, что все больше и больше плагинов убиваю.
Да, все так. Недавно поймал себя на этой мысли.
Однко же, удивительно встретить холивар vim/IDE в посте про докер.
It’s San Francisco. Everyone’s into distributed systems and BDSM.
Это из Сан-Франциско. Все, кто относятся к распределенным системам. BDSM.

facepalm.jpg

Перевод стоило бы вычитать перед публикацией. Две глобальные проблемы — повсеместная калька в порядке слов («Kubernetes кластер», «RestAPI слой») и то, что названия технологий то в оригинале, то транслитерированы на русский и склоняются. Нужно определиться.
Две глобальные проблемы — повсеместная калька в порядке слов («Kubernetes кластер», «RestAPI слой»)
Кубернетовый кластер и рестапишный слой, нет?
Прямой порядок слов подошел бы лучше, но и так тоже можно, если выдержать всю статью в едином стиле.
А вам не кажется, что «кластер Kubernetes» и «слой RestAPI» звучит как-то более… приятно для русскоязычного уха?

У меня есть своя теория заговора. Мне кажется, что Русский Язык пытаются захватить страшные люди с другой планеты, которые везде на вывесках пишут что-то типа «Эверест консалтинговая компания» и «33 Зуба стоматология».
А вам не кажется, что «кластер Kubernetes» и «слой RestAPI» звучит как-то более… приятно для русскоязычного уха?
Приятнее, но смысл не совсем совпадает. Лексически «кластер Kubernetes» ≈ кластер, составленный из Kubernetes'ов, тогда как Kubernetes-кластер («кубернетовый») — кластер, управляемый (или как оно там организовано?) Kubernetes'ом. Так же и «слой RestAPI» ≈ «слой всяких RestAPI», а «RestAPI-слой» — это слой, [отвечающий за / предоставляющий] RestAPI.
Во-первых, вы написали «Kubernetes-кластер» (через дефис), что уже значительно грамотнее. Во-вторых, никто не мешает написать «кластер типа Kubernetes» или «Kubernetes-управляемый кластер». Просто в оригинальном тексте было много игры слов, основанной на терминах и их альтернативном прочтении, поэтому, видимо, переводилось для «людей, которые знают английский, но которым лень читать по-английски всё».

Есть такая категория переводчиков, которые стремятся писать по-английски, но русскими словами и пунктуацией. Некоторые даже утверждают, что так «правильно» переводить художественные тексты. Правда как всегда где-то посередине. В любом случае, для того, чтобы ХОРОШО перевести текст, его придется спера ПОНЯТЬ. См. выше отличный пример про BDSM.
Ну а что ж Вы корректный перевод не указали?
Это Сан-Франциско. Здесь все увлечены распределенными системами и BDSM.
Попробую еще точнее:

«Здесь все вовлечены в занятия или распределенными системами, или BDSM»

Так игра слов сохраняется. C «into».
Какая тут игра слов? Вариант Source вполне точен, и звучит более естественно.
Это такой известный прием — заставьте своего оппонента выглядеть косноязычно. Например, попросив его без подготовки объяснить что-то очень сложное кому-то очень некомпетентному.
Монговато букв, но плюсанул)) «Усложнять — просто. Упрощать — сложно» (с).
Крутая статья, спасибо. Нужно было её переводить, а не вот что сверху.
Про сеть забыли!

Что бы оркестрировать сеть — нужно построить оверлейную SDN сеть, например на OpenContrail, оно как раз прекрасно дружит с Kubernetes.
Недавно на /sysadmin наткнулся на девопсовкий цитатник про это самое:
“Re the LXD discussion above. I totally agree about containers being the best way to virtualize machines, and I can’t wait to start using it when Sun integrate it into Solaris ten years ago.”
Вы вот смеётесь, а мне сейчас один клиент мОзги клепает что чтобы переслать XMLку от одного приложения к другому, вероятно на одной и той же машине, нужно поднять SOAP Server (как он это называет). И если начать думать про все возможные alternative и exception flows, то становится уже как-то совсем не смешно.
Only those users with full accounts are able to leave comments. Log in, please.