а нужны ли мне эти ваши docker-контейнеры?

Примем, что на AWS был отдельный наезд

На AWS был наезда по поводу охреневших цен на on-demand сервера. Легионер расказывал, как собрался экономить деньги на хостинге, а я ему пояснил, что он не сэкономит ничего и всё это просто эффект «хорошо там, где нас нет».

Просто проблемы, которые решает докер, за вас решали другие люди

С докером проблемы будут просто решать другие «другие люди» — вот и вся разница.

Логгирование, мониторинг, оповещения и пр. вам всё равно нужны, даже если вы apt’ом свой мегасервис разворачиваете

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

Передал запрос сервису — сервис упал. Чо делать?

Варианты:
Забить.
Повторить.

Уточняющий вопрос: откуда вышестоящий сервис узнает, что нижестоящий сервис упал? Следующий уточняющий вопрос — откуда нижестоящий сервис узнает, что вышестоящий сервис узнал, что нижестоящий сервис упал? Еще один уточняющий вопрос: откуда мы знаем. что оба сервиса не упали одновременно и возложенные на них запросы не канули в бездну?

Т.к. выделенные, изолированные слои для отдельных задач лучше помогают понять происходящее, нежели когда всё в кучу свалено

Отдельные задачи? Да, помогают понять. Работу системы в целом? Нет, только усложняет. У тебя какая конечная задача — отчитаться про «сервис авторизации стало проще понять» или же сделать работоспособную систему в целом? Индустрия выбирает первое, вкупе с закрытыми задачками в жире и красивыми графиками на митингах — но все эти отчеты не коррелируют с фактической работоспособностью системы. Как там было у Райкина:

https://www.youtube.com/watch?v=2wxL3DYen5g — Райкин - «Кто сшил костюм?»

- У нас узкая специализация. Один пришивает карман, один - проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть?
- Нет! Пришиты насмерть, не оторвёшь!... Кто сшил костюм? Кто вместо штанов мне рукава пришил? Кто вместо рукавов мне штаны пришпандорил? Кто это сделал?

Магистральное направление обратное, теперь даже в винды добавили обвязку линуксовые контейнеры запускать

Эй, кто из нас там писал про десятилетний софт, который еле ползает? Так-то из сорцов и я чо угодно собрать могу. А как же «живём с тем, что есть»? Винда совсем недавно была мейнстримом, она до сих пор себя неплохо чувствует.

Во-о-от, и я о том же — подбор кадров, а не управление глухими.

Думаешь, слышащими не надо управлять? Нужно и то, и то — и грамотный подбор кадров, и грамотное управление.

Думаешь, слышащими не надо управлять? Нужно и то, и то — и грамотный подбор кадров, и грамотное управление

Да, ставить задачи, общаться с заказчиками — как я уже написал. И подбирать кадры. Всё. Но тут же есть эксперты по менеджменту, которые настаивают на том, что нужно жиру завести, agile планирование (оксюморон), строить кодеров на митингах, ставить тайм-трекеры в анус, и прочее. Я проходил мимо одной вакашки, где в требованиях указывалось «регулярно улучшать английский язык» и при отклике на вакансию требовалось написать, сколько фильмов-сериалов на английском языке ты отсмотрел за последнее время — я не шучу, прямо так и было написано. При этом ЗП что-то вроде $1000 — то есть, помойка с джунами. Я заметил: чем помойнее помойка, тем больше там «мотивируют» и управляют сотрудниками, при этом неадекватнее требования и ЗП.

Если же контора уровнем повыше, то там могут возникнуть такие регулярные мероприятия, как «джуны учат сеньоров проектированию систем». И это тоже не шутка — это вполне серьёзный подход, потому что у сеньоров взгляд замыленный.

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

кант хелп, бат.. я в человеке упоминающего (или вообще считающего возможным упоминать) «Даннинга-Крюгера» вижу идиота.

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

Вот, потому я и говорил про методологию программирования «мозг». Это когда приходишь в фирму, а там жалуются «мы аджайл пробуем-пробуем, но нам не нравится и у нас не получается» — тогда ты им и отвечаешь «а вы мозг применять не пробовали?».

грамотный подход к «мне пофигу, что будет с проектом — главное, что я норм денег поднял».

ты дурак. только так можно и нужно относиться к работе. она нужна только для того, чтобы поиграться с потенциально востребованными технологиями, углубить знания и высосать денег. я например вообще не испытываю угрызений из-за того, что более года решаю копеечную задачу и получаю ЗП, мне пофигу если они меня уволят. сегодняшний мир - это не совок в котором в конечном итоге достигается разумность, гармония и в целом справедливость. работа сегодня совсем по-другому устроена, СОВСЕМ.

про докер. ты прав почти во всем на 99% и всё очень точно описываешь. но ты «уперся» опять. всё таки.. может ли докер принести практическую пользу в работе? ответ да. есть сценарии в которых может принести большую пользу. конечно, и в этом случае он решает проблемы или дефишенсис которых «в идеале» не должно было быть. то есть сценарий при котором докер творит бобро - существует. но то, что лично я наблюдаю - зачастую или совсем не оно, или как бы оно, но отравлено деталями которые человек «не понял», либо отравлено «философией» весьма токсичной.

заметил: чем помойнее помойка, тем больше там «мотивируют» и управляют сотрудниками, при этом неадекватнее требования и ЗП

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

у сеньоров взгляд замыленный

нет никаких сеньёров. долбоклюи с DRY, KISS, SOLID, ЧСВ.

Т.к. выделенные, изолированные слои для отдельных задач лучше помогают понять происходящее, нежели когда всё в кучу свалено.

Когда падает монолит, обычно виден может длинный и страшный, но один стектрейс, который можно распечатать на рулоне бумаги и спокойно вдумчиво его полистать. Когда падает что-то микросервисное, то это превращается в целый криминальный детектив. Что упало ещё обычно можно увидеть, а вот понять почему упало, надо зачастую дебажить соседние сервисы.

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

изучаю проектирование распределенных систем

ты как-то помню на клямпана наезжал. я не такой умный как ты, но всё же подумай еще раз. он как минимум не побоялся про acid сказать одну вещь, которую я понял, но нигде не находил подтверждения.

Всё

Не всё %)

agile планирование (оксюморон)

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

По крайней мере, мне так думается.

тайм-трекеры в анус

Казалось бы, при чем тут аджайл.

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

Еще раз: это актуально только до тех пор, пока ты не разрабатываешь собственный продукт. Когда ты разрабатываешь собственный, то внезапно выясняется, что ты ВООБЩЕ НЕ УМЕЕШЬ проектировать и организовывать разработку софта. Вообще. Потому что вся твоя команда решает копеечную задачу и не испытывает угрызений совести — причем, ты даже не понимаешь этого, поскольку вся разработка идет именно так, как ты привык, так, как ты ожидаешь. Я столкнулся с этим, но не мог понять, откуда у этого явления растут уши, поскольку я сам не разделял эту идеологию.

Такая идеология разработки приводит к тому, что мы видим в силиконовой долине: стартапы-однодневки, с крайне неэффективной организацией разработки и архитектурой систем, где сверху донизу каждому человеку безразлично решительно всё и главная задача — это распилить чужие деньги. То есть, прям как в бюджетных распилах. Естественно, чтобы это работало — нужно чтобы было что пилить. Доткомы в нулевых сходили с ума, распиливая доллары из печатной машинки налево и направо, но эта халява не бесконечна, им всё больше приходится работать и показывать результат, а не только сдавать заказчику эндпоинты по графику.

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

Конечно, не 100% кодеров в долине такие — тот же Торвальдс работал в долине, но! Торвальдс всё время проработал в одной компании, заметь. Это совершенно иной склад мышления, который способен реализовывать долгосрочные проекты, но 99% остальных обитателей долины большую работоспособную систему выдать не способны в принципе, потому что у них нет такой программы в мозгу, как «долгосрочный проект», для них долгосрочный проект — это «когда я делаю стартап, а потом еще такой же на ту же тему, а потом еще много раз такой же».

может ли докер принести практическую пользу в работе? ответ да

Ответ — да, я согласен. Может ли фон рабочего стола с Хацуне Мику принести практическую пользу в работе? Может. Кстати:

Как в 2022 году устроиться в IT компанию разработчиком? (комментарий)

очень много кандидатов в разработчики понятия не имеют о Jira, а про git только что-то слышали

«Вы умеете пить кофе со сливками? Нет? Извините, вы нам не подходите — у нас принято пить кофе со сливками»

——————————————————————————

есть сценарии в которых может принести большую пользу. конечно, и в этом случае он решает проблемы или дефишенсис которых «в идеале» не должно было быть

В свете развития virtualenv и PIP уже неактуально для того же питона. У ноды так было почти всю историю существования. Спор был про «универсальное решение для всех подобных проблем вместо отдельного решения на каждую проблему» — а это очень спорный тезис.

Возвращаясь к треду про Jira и Git — это инструменты, которые вообще не должно быть заметно. То есть, не «достоинства перевешивают недостатки», а вообще незаметно, поскольку у них ничтожная роль, как у калькулятора. Если тебе под докер нужно строить инфраструктуру — это уже проблема.

Конечно, если ты отталкиваешься сразу от готовой инфраструктуры адаптированной под докер — можно считать, что ты «не заметил». Однако, речь шла про докер даже без инфраструктуры. Да, запустить готовый образ не сложно — сложно потом извлечь пользу из этого запуска. Я вот пытался ставить софтины десктопные на flatpak, но это боль и страдание, потому что с системой оно интегрируется плохо, профили хранит отдельные и к остальному диску доступа не имеет, а чтобы его дать, нужно покрыться прыщами и освоить консоль, потому что ни GUI, ни TUI конфигурялки под это дело нет. Вот это я называю «трудности заметны».

Но да, если есть проблемы — контейнеры могут быть решением.

Когда ты разрабатываешь собственный, то внезапно выясняется

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

поэтому когда люди со связями пилят деньги, программисты пользуются моментом и производят говно пытаясь вырвать хоть зп пока оно не лопнуло. 0,01% кода останется, остальное вынесут на помойку всё равно, даже годное (где всё крутое что делалось в 90е? где SGI например?). а если не викинут код, то программисту-то что? его всё равно выкинут. всё это уёдет в никуда, вместе годами жизни, на помойку, как кресла аэрон в 2000

а ты если хочешь, отдай всего себя капиталисту, сделай по уму, сделай хороший код, чтобы correct, чтоб sound. построй будущее для его детей и внуков, обеспечь историю успеха топ-менеджерам на десятилетия вперед. сейв дэ планет, килл ёрселф короче.

нет никаких сеньёров. долбоклюи с DRY, KISS, SOLID, ЧСВ

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

так можно и боба мартина начать читать

ты как-то помню на клямпана наезжал. я не такой умный как ты, но всё же подумай еще раз. он как минимум не побоялся про acid сказать одну вещь, которую я понял, но нигде не находил подтверждения

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

Суть в том, что книга — унылое говно из тезисных перечислений, будто школьника заставили сочинение писать «как я провёл лето, создавая свой амазон». Но у Клепмана есть довольно неплохие работы по CRDT, где он утирал нос даже гуглу. Конечно, не то чтобы в гугле сидели сплошные таланты, но всё же.

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

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

он как минимум не побоялся про acid сказать одну вещь, которую я понял, но нигде не находил подтверждения

Какую вещь он сказал?

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

Какой смысл такого планирования, если ты 100% знаешь, что твой план на год будет неактуален через неделю? И через неделю произойдет то же самое.

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

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

а ты если хочешь, отдай всего себя капиталисту, сделай по уму, сделай хороший код, чтобы correct, чтоб sound. построй будущее для его детей и внуков, обеспечь историю успеха топ-менеджерам на десятилетия вперед. сейв дэ планет, килл ёрселф короче

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

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

дебилам

ну ты прав наверное. мы с тобой на сильно разных уровнях. для меня это всё из разряда труднопостижимой информации от «мощного ученого». для тебя, вероятно, «ну да и чо»

Это базы данных с функцией очередей сообщений.

Я даже боюсь спросить что такое по-твоему база данных?

ZeroMQ — это не база данных

Это библиотека для тех же очередей. А sqlite база данных в твоем мире или тоже нет?

Он в любом случае заметно проще, чем передача данных по сети.

А почему? Объясни. Я правда не понимаю почему строить общение внутри монолита между тредами проще, чем отправить запрос по http к внешнему сервису?

Извини, но я из СНГ и работал до недавнего времени на СНГ, так что у нас айфоны и маки как платформа не существуют

В СНГ не делают софта под iPhone? Серьезно? Мы видимо в разных СНГ живем.

Объект — но не класс.

ООП - это Объектно Ориентированное Программирование. Точка. Почему ты это используешь, если считаешь других использующих дебилами?

Нахрена в лесу коины

В лесу тебе и любая другая валюта не поможет.

инфой про колбасу в сельпо гламурный геймдев не располагает же.

Конечно. GameDev не решает проблемы, которые не может решить государство. (Хотя платит огромные налоги на самом деле).

ну ты прав наверное. мы с тобой на сильно разных уровнях. для меня это всё из разряда труднопостижимой информации от «мощного ученого». для тебя, вероятно, «ну да и чо»

Так и быть, открою секрет: ты пытаешься заучить конкретные реализации и приемы, но в распределенке комбинаторная сложность этих конкретных решений улетает туземун легко и непринужденно. По этой причине заучивать их не имеет никакого смысла, и именно по этой причине я назвал книгу унылым говном. Тот же Армстронг, например, в лекциях годно дает указания на фундаментальные штуки, но он недооценён, на мой взгляд — по тем же причинам, по которым переоценен Клепман, потому что все пытаются учить конкретные решения, а не фундаментальные принципы.

А фундаментальные принципы — это скорость света, из которой следует невозможность одновременности событий и фундаментальные ограничения распределенных систем, это NLP-неразрешимость и CAP-теорема, которые по сути не более чем констатации банальностей вроде «если у тебя нет головы, то ты не можешь думать». Всё, отсюда мы получаем консенсусы Paxos, MultiPaxos, Zab, Raft, отсюда мы получаем распределенные хэш-таблицы, и так далее. Например, невозможность одновременности событий сразу приводит к вопрос: когда происходит успешное завершение алгоритма Paxos? Очевидный ответ — никогда, потому что система распределенная и атомарное завершение невозможно. А это значит, что протокол будет крутиться в бесконечном цикле опроса — том самом, который при голосовании парламентариев на острове выполняли сами людишки, но про который автор статьи про алгоритм Paxos почему-то не упомянул. И отсюда сразу становятся понятна причина и цели организации MultiPaxos, Zab, Raft — это и есть та самая конкретизация бесконечного цикла опроса-уточнения состояния.

Тот же Армстронг на одной из своих лекций прямо так сразу в лоб и говорил — согласованность в распределенной системе из двух узлов подразумевает бесконечную пересылку сообщений в обе стороны. Большая часть проблем у школьников возникает именно потому, что они не хотят расставаться с книжками и пытаются строить систему на атомарных операциях, даже пытаются комбинировать их.

Гибкость-кобминирование-расширение — это еще одна форма рака, смертельная для распределенной системы, но которая поощряется мейнстримом. К сожалению, распределённую систему возможно проектировать только целиком, сверху донизу, она как кубир рубика: повернул одну грань — всё перемешалось. Комбинаторная сложность-с. И в том числе поэтому число фич в распределенной системе — это строго негативное свойство, ухудшающее масштабирование, усложняющее разработку, и подрывающее стабильность. А мейнстрим до сих пор не видит в сложности никакой проблемы, «просто грамотно построим иерархию классов и будем наследовать реализацию по принципу подстановки Лисков».

Всё, ты почти научился разрабатывать распределенные системы.

Может ли фон рабочего стола с Хацуне Мику принести практическую пользу в работе? Может.

блин. ты рассматриваешь всё на каком-то серьезном уровне, где грамотные спецы, серьезные проекты, инфраструктура и прочее.

есть люди, которые могут не очень много. например изготовить веб-сайт или api, работающий на конкретной ОС с конкретными пакетами. сделать чтобы на чуть других пакетах, конфигах и ос - они не могут, да и есть мнение, что это не нужно. просто они сделали один раз как им удобно, пользуюсь уже известным для них инструментарием и средой и всё. еще они могут это описать (но доку нужно поддерживать и ее трудно валидировать), могут плейбук сделать (но это другое), референсную VM - но это неудобно.

с другой стороны админ, который точно не хочет думать как в его дистрибутиве установить такую же версию например ПХП, с теми же расширениями, точно так же собранную с теми же ключами. программист ставил их на свой любимый дистр по какой-то своей инструкции и код написал под эти версии. ставил он из какого-то левого репозитория откуда он «всегда берет». и еще какой-то пакет он пересобрал наложив патч (как Кумар показывал в блоге), т.к. «без этой фичи вообще никак нельзя». то же касается структуры директорий (что у него кол, что популируется PM, что данные которые мусор, что есть ценные данные), которая очевидна только тому веб-программисту и возможно еще автору фреймворка.

и вот этом случае докер даёт громадную пользу. громадную.

разумеется админ, по мере возможности и необходимости может помогать этот Dockerfile доводить до ума и прочее.

не надо только говорить, что в идеальном мире всех этих проблем изначально не должно было существовать, что они могли стандартизироваться на «RHEL N.m», что дока по деплою должна быть, что черный ящик, что в итоге и веб-прогер и админ тупо всё равно освоили еще один дистр (alpine). всё это понятно.

если ты прочитаешь про acid и вдумаешься, то тебе начнет казаться, что оно не имеет смысла. что эти свойства сведенные в одну аббревиатуру дают нового? ничего. сами по себе - да, вместе - нет... в каком-то выступлении он мягко, но прошелся по ней, назвав, кажется, маркетингом. но на мой взгляд, это polite term for говно

А выступление не подскажешь? По поводу ACID — с одной стороны, да, это маркетинг и карго-культ, как SOLID, но с другой стороны в контексте «БД в виде одного файла на диске» ACID приобретает смысл, потому что для согласованности тебе нужна атомарность и изоляция, а вот уже для распределенной системы атомарности просто не существует, ололо. Самая спорна же буква, D — durability, тоже внезапно приобретает неразрывную связь, поскольку у нас есть только файл на диске, и если мы в него ничего не записали, то в базе ничего и нету, а писать мы должны строго атомарно и согласованно.

Короче говоря, никто уже и не помнит, что такое ACID, но все рассказываю «мы ACID-complaint». Особенно какая-нибудь монга, которая так и норовит доложить про ACID, с которым у нее вообще нет ничего общего. Но что ты будешь делать, если прошло 40 лет, а у людей до сих пор реляционные мозги на жестком диске? IT — это очень инертная индустрия, по крайней мере мейнстримовая ее часть.

нашел. не помню на каком месте. сейчас нет времени извини. https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=175s

коротко я хотел вот что сказать. я когда читал про аббревиатуру эту, у меня возникло ощущение, что не хватает Rollbackability, потому как это важнейшая штука на самом-то деле, и в строгом смысле я хз можно ли утверждать, что оно вытекает из I или из A. через неск лет я наткнулся на этого кляпмана и когда он произнес rollbackability (или как-то по другому), я прям офигел.

тогда же мне показалось что, D - это вообще тут лишнее (не помню кляпман упоминул это или нет). потому как это D банально не вяжется. как свойство транзакции может аппаратный сбой распространяться? это глупость. даже если не вдаваться в детали про например диск, который может врать что записал сектора и отчитываться о записи в том же порядке. ну или вот мой довод. in-memory база, которая умеет в seriailisable оно что не полезна или в ней транзакции на S как-то иначе выполняются что ли? второй пример: система, для которой прочесть состояние после аппаратного сбоя будет невозможно вообще или просто не нужно. у нее транзакций нет получается что ли? или есть но они сломаны? тупак же.

и в конце концов, аббревиатура совпадающая со словом…

если я правильно помню, я натыкался на книжки, в которых глава по транзакциям открывается свойствами транзакций, свойства - это вот эта аббревиатура. но я могу понять авторов книг, там «не принято». типичная афёра века.

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

кстати то ли Cod, то ли кто-то такой же популярный, в свое время оказывается опубликовал где-то работу, где предложил какую-то тухлую аббревиатуру, дескать это новый подход, концепцт, не помню точно. а потом вдруг выяснилось: кто-то типа сайбейса разрабатывали набор фич для нового продукта, и решили провернуть такую тухлую схему: ученый высирает «концепт», а после публикации выходит продукт который его уже реализует.

Какой смысл такого планирования, если ты 100% знаешь, что твой план на год будет неактуален через неделю?

Скорее всего, не весь. И пересмотреть нужно будет только какую-то (хорошо бы небольшую) часть.

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

скорость света, из которой следует невозможность одновременности событий

Ничоси. Прямо вот просто из существования скорости света немедленно следует отсутствие одновременности?

Agile помогает быть динамичным и подстраиваться под внешние изменения.

Хорошо-хорошо, вы главное теракты во славу agile не устраивайте и все будут счастливы (или хотя бы живы).

Я даже боюсь спросить что такое по-твоему база данных?

Любое организованное хранилище данных. Даже ФС, как ни странно. Особенно ФС.

Это библиотека для тех же очередей. А sqlite база данных в твоем мире или тоже нет?

«Ведро воды херак туды, хоапку дров — и плов готов» — есть люди с забавным мышлением крупнозернистыми шаблонами.

SQLite — это библиотека для организации хранилища данных. А вот ZeroMQ в хранилище не умеет совсем.

Я правда не понимаю почему строить общение внутри монолита между тредами проще, чем отправить запрос по http к внешнему сервису?

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

То, что ты пишешь, актуально разве что для Erlang или какой-то пытающейся подражать эрлангу системы, построенной на передаче сообщений между процессами-потоками. В случае какой-нибудь Clojure всё «общение» в большиенстве случае сводится к «просто прочитать общую ячейку данных». В питоне многопоточности по сути не существует, но я в своей Python Shared Objects этот баг пофиксил и там точно так же можно просто читать объекты из разделяемой памяти. Да, там под капотом активируются блокировки, при конфликтах один из потоков начинает спать или крутится в цикле, но для пользователя это выглядит как простое чтение переменной.

В СНГ не делают софта под iPhone? Серьезно? Мы видимо в разных СНГ живем

Делают, но айфонов в СНГ маловато, причем, продажи падают — сейчас это сплошное б.у.

есть люди, которые могут не очень много. например изготовить веб-сайт или api, работающий на конкретной ОС с конкретными пакетами. сделать чтобы на чуть других пакетах, конфигах и ос - они не могут, да и есть мнение, что это не нужно. просто они сделали один раз как им удобно, пользуюсь уже известным для них инструментарием и средой и всё

Вот у меня сейчас достаточно «серьезный» проект, но там тесты висят на втором питоне. И тащат устаревшие пакеты питона на разрабские машины, безо всяких докеров. На самом деле, в крайнем случае есть virtualenv даже под двойку.

референсную VM - но это неудобно

Запуская докеры на нелинуксе ты по сути используешь VM.

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

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

Но когда приходит очередной девопёc «я помогу вам контейнеризовать транспиляцию JS кода в контейнерах» — хочется спаросить «ты что, е$#!@тый?». Что тут виртуализировать, что тут оптимизировать, какую зависимость от версий убирать? Нода за всю свою историю не сломала ни одного старого API, она из коробки идет со всегда активным аналогом virtualenv.

нашел. не помню на каком месте. сейчас нет времени извини. https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=175s

Ну да, он говорит про то же самое, только он откатился аж до магнитных ленточек, которые по сути эквивалентны современному WAL. Дальше он говорит, что сейчас под Durability вообще понимают репликацию, что есть полная дичь в контексте ACID.

https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=175s — ACID
https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=216s — Durability
https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=270s - Consistency
https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=380s - Atomicity
https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=590s - Isolation

через неск лет я наткнулся на этого кляпмана и когда он произнес rollbackability (или как-то по другому), я прям офигел

Abortability здесь.

По поводу Consistency — Келпман говорит, что его всунули в ACID для красоты, но я бы делал упор на то, что вообще-то его просто нет в большинстве СУБД. Клепман же настаивает, что согласованность данных — это логическая согласованность на уровне приложения, и на уровне БД она не имеет смысла. Хотя, на мой взгляд SQL сам по себе уже придает довольно много смысла данным.

Как упомянуто в лекции, тот же оракл средствами ANSI SQL (без расширений) не позволяет избегать асимметрии записей (write skew), поскольку в нем максимальный уровень изоляции — снимок (snapshot).

https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=1117s

Клепман приводит этот пример тут, не ссылаясь на «но ведь у нас же была буква C в ACID». Короче говоря, как Atomicity и Durability потеряло смысл для распределенных систем, так Consistency потеряло смысл уже для многоверсионных систем, и корректно было бы называть оракл AID СУБД.

Ну и если ж пошла такая петруха, то Isolation — это на самом деле Conflict Resolution. В это энтерпрайзной терминологии еще много бессмысленного бреда, вроде repeatable reads isolation, которая не дает гарантии воспроизводимых чтений. Кто это хероту выдумывает — мне ясно, вахтёры-менеджеры, у меня больше вопросов к тем, кто сей кал потребляет с умным выражением лица, мол «ага, мы поняли».

серьер-тимлид, который на собесе спрашивает эту аббревиатуру - он совсем дурак и ублюдок, вот что неприятно

Ну да, «расшифровать ACID/SOLID» — для меня это сразу «спасибо, я вам позже перезвоню».

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

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

«О сколько нам открытий чудных...» — тебе еще предстоит узнать, что так работает вообще всё. И учёные будут высирать концепт, и неучёные, и до, и после. Собственно, какая разница между условным учёным, мной, тобой, или вобще любым человеком?

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

У тебя есть опыт, когда через год было торжественно выкачено «нужно» по агильному плану? У меня нет. И я боюсь, что ни у кого из присутствующих нет. Так зачем тогда план? Чтоб был?

Ничоси. Прямо вот просто из существования скорости света немедленно следует отсутствие одновременности?

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

Любое организованное хранилище данных. Даже ФС, как ни странно. Особенно ФС.

Хорошо. А что такое хранилище? И как оно организованно в rabbitMQ и kafka?

Делают, но айфонов в СНГ маловато, причем, продажи падают — сейчас это сплошное б.у.

К счастью интернет у нас еще есть, поэтому и продавать не только жителям СНГ можно.

А что такое хранилище? И как оно организованно в rabbitMQ и kafka?

Оперативная память, жесткий диск, SSD — это вообще не важно. Важно, что организация есть, и важно, что есть данные. Микросервисы — это противоположность БД, у них нет организованного хранения данных, и это самое главное.

Делают, но айфонов в СНГ маловато, причем, продажи падают — сейчас это сплошное б.у.

К счастью интернет у нас еще есть, поэтому и продавать не только жителям СНГ можно

Ну это как бы уже другой вопрос.

У тебя есть опыт, когда через год было торжественно выкачено «нужно» по агильному плану? У меня нет. И я боюсь, что ни у кого из присутствующих нет.

А какой у тебя опыт был? Херак-херак и готово? %)

Блин, ну очевидно же, что скорость света имеет особый смысл только для спец теории относительности

Она объективно существует и измеряется независимо от каких-либо теорий. Так и говори — невозможность одновременности следует из СТО.