Как стать автором
Обновить
6
0
Евгений Калитько @Kaluchi

Пользователь

Отправить сообщение
В фильме «Дело было в Пенькове» (1957) главному герою грезились автоматические комбайны.
Вики это хорошо. Но Маркс в оригинале все же лучше.
В PDF:
https://www.marxists.org/russkij/marx/cw/t23.pdf
Открываем стр. 770

В HTML так же стр. 770:
http://www.esperanto.mv.ru/Marksismo/Kapital1/kapital1-24.html#n250
http://www.esperanto.mv.ru/Marksismo/Kapital1/kapital1-24.html#x250

Открываем ссылки и читаем тоже самое, что и в ПДФ на стр. 770:

Маркс пишет:
Tantae molis erat 220 создать условия для свободного проявления «вечных естественных законов» капиталистического способа производства, совершить процесс отделения рабочих от условий их труда, на одном полюсе превратить общественные средства производства и жизненные средства в капитал, на противоположном полюсе превратить народную массу в наёмных рабочих, в свободных «работающих бедняков» — этот удивительный продукт современной истории 248). Если деньги, по словам Ожье, «рождаются на свет с кровавым пятном на одной щеке» 249), то новорождённый капитал источает кровь и грязь из всех своих пор, с головы до пят 250).

Подкрепляя свою мысль приводит цитату из работы другого автора и ссылается на источник, где он это взял:
250) «Капитал», — говорит «Quarterly Reviewer», — «избегает шума и брани и отличается боязливой натурой. Это правда, но это ещё не вся правда. Капитал боится отсутствия прибыли или слишком маленькой прибыли, как природа боится пустоты. Но раз имеется в наличии достаточная прибыль, капитал становится смелым. Обеспечьте 10 процентов, и капитал согласен на всякое применение, при 20 процентах он становится оживлённым, при 50 процентах положительно готов сломать себе голову, при 100 процентах он попирает все человеческие законы, при 300 процентах нет такого преступления, на которое он не рискнул бы, хотя бы под страхом виселицы. Если шум и брань приносят прибыль, капитал станет способствовать тому и другому. Доказательство: контрабанда и торговля рабами» (T. J. Dunning, цит. соч., стр. 35, 36).

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

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

Я ссылаюсь на Маркса, которого читал…
И не ссылаюсь на T. J. Dunning, цит. соч. «Trade’s Unions and Strikes», стр. 35, 36., которое я не читал и мне найти не удалось найти, что бы процитировать.

Именно эта статья сподвигла меня попробовать Rust. Помню как первый раз GO учил. В принципе за спиной уже был php, java, js, python (c++ и C# помню только со времен учебы что-то).

Так вот, после прохождения tour.golang.org/welcome/1 я уже мог что то писать. Оно компилировалось и работало. А если не работало — то компилятор говорил что не так. Язык примитивный и все ограничивалось банальной правкой типов и т.д.

И вот я день прот… хался с Rust. Это ад какой-то. Да, Hello World с божей помощь скомпилировался. Дай думаю забабахаю простенький ендпоинт который будет принимать айдишник и брать доку с монги. Ошибки компилятора — напомнили с++ где читаешь ошибки и хрен знаешь как ее чинить… Столько всего нужно писать — макросы, импорты, неймспейсы… потом конфликты библиотек прилетели…

В интернете нет ни одного нормально рабочего примера. Могу ошибаться, но как я понял язык настолько быстро ломает свои контракты что большинство информации просто устаревает слишком быстро. А разработчики библиотек не успевают выпускать новые версии.

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

А жаль, так хотелось поиграться :(
НЛО прилетело и опубликовало эту надпись здесь
Очень односторонне. Не знаток java, но активно работал с исключениями в Delphi. Разумный подход такой:

  1. Логгируем там, где есть максимум дополнительной информации, которую мы можем записать в лог. То есть не просто «файл не открыт», а файл пытались открыть с такими-то параметрами доступа. Не просто — не удалось преобразование такой-то строки в число, а значение такого текстового поля не числовое. Такой подход дает сообщения об ошибке понятные для пользователей.
  2. Реагируем на ошибку обычно на этом же уровне. Но если нужна ещё и реакция на более высоких уровнях — меняем тип исключения на «логгировать не надо, но ошибка в файлах» или «логгировать не надо, но ошибка во вводе полей».
  3. После реакции меняем тип исключения на самое общее «логгировать не надо, завершаем работу функции». Его назначение — просто быстрый выход из середины кода.

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

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

Как и кибернетика — никто не отрицал ни математику, ни физику (недаром мой родной радиофизический факультет был организован в 1952 году при Сталине — для развития электроники, как писалось в указе) — отрицалась идея, что человеческим обществом должны управлять не люди, а машины (собственно, предпосылки мы уже видим… когда чудак на букву «м», ведомый Google'ом, въезжает в озеро, доверяя машине больше, чем своим глазам).

А раздуто все в миф о запрете науки и отставании в той же электронике именно из-за этого. С электроникой надо благодарить в первую очередь Брежнева, у которого было — зачем что-то изобретать? если что не сопрем — то купим, нефть, газ есть…

Помню, как в аспирантуре хозтему оформлял, прорыл литературу — и честно пишу, что в этом мы впереди планеты всей… На что старшие товарищи пояснили — это — прямой путь к тому, что тема будет зарезана. Писать надо — в США (Японии etc) уже это сделано, поэтому пора бы и нам… — вот тогда деньги дадут.
НЛО прилетело и опубликовало эту надпись здесь
цель -> архитектура данных -> код


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

Но для начала, давайте немного поговорим о терминологии, чтобы мы правильно друг друга понимали, общались едиными терминами:



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

Например: цель — сделать двигатель, который будет перемещать транспортное средство быстрее скорости света; или, скажем, реализовать проект, который поглотит 120% емкости рынка (при очевидном максимуме в 100%).

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

Я считаю это важным при построении дальнейших рассуждений.



Архитектура данных — субъективно я понимаю это как конкретную конфигурацию представления данных (из бесконечного множества конфигураций), понятную инженеру и выбранную им с точки зрения оптимизации по целевым критериям.

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



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



Цель, архитектура данных, код (логика).

Цель не определяет архитектуру данных.
Архитектура данных не определяет цель и не определяет логику.
Логика не определяет цель и не определяет исходную структуру данных, а лишь предполагает исходную структуру данных.

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

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



Причем тут ООП или «что ты несешь?!»

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

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

Говоря об ООП (в контексте статьи), нельзя утверждать, что это «плохо», так как это лишь способ представления композиции функционала и контекста (данных), созданный с определенными целями, в частности для достижения инкапсуляции, полиморфизма и наследования.

Говоря о том, что ООП не так хорош, необходимо более убедительно представить, чем не столь хороши по отдельности инкапсуляция, полиморфизм и наследование, а также в первую очередь постараться осознать для самого себя, «а правильно ли я осознаю эти концепции»?

Вероятно «неудобство» и ограничения связанные с использованием ООП (с учетом конкретных примеров) вполне могут быть метафорически представлены ситуацией, когда ключом на 13 может быть неудобно откручивать гайку на 11, а возможно даже и ситуацией, когда ключом на 13 неудобно или невозможно закручивать саморез…

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

Это не плохо само по себе.

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

Это не плохо само по себе.

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

Это не плохо само по себе.

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

Нет плохих систем или хороших, есть те, которые удовлетворяют или не удовлетворяют целевым критериям.

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

Хорошо спроектированные системы легко адаптировать, так как они воспринимаются простыми и при минимальном вложении труда удовлетворяют целевым критериям.



Устали? Осталось потерпеть одну минутку!

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

Сами по себе эти принципы применяются при формировании сущностей (абстракций), которыми мы непосредственно оперируем при построении систем: классы и абстрактные классы, интерфейсы, трейты, примеси и т.д.

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

Каждый масштабный уровень системы обладает своим набором возможных абстракций.

А потому каждый масштабный уровень системы обладает своими методами оптимизации композиций абстракций.

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

В этот момент мы открываем для себя принципы проектирования ООП, такие как SOLID:

S (The Single Responsibility Principle) — принцип единой ответственности (SRP).
O (The Open Closed Principle) — обозначает принцип открытости/закрытости (OCP).
L (The Liskov Substitution Principle) – принцип подстановки Лисков, описывающий возможности заменяемости экземпляров объектов (LSP).
I (The Interface Segregation Principle) — принцип разделения интерйесов (ISP).
D (The Dependency Inversion Principle) — принцип инверсии зависимостей (DIP).

Эти принципы основаны на ООП, основаны в своей сути на инкапсуляции, наследовании и полиморфизме, но находятся на один уровень выше в системе.

К чему это я? Да к тому, что говорить «хорошо» или «плохо» как минимум слишком ограниченно, причем ограниченно контекстом восприятия. При действительно масштабном представлении системы происходит своего рода «мульти-интерпретация» в рамках которой парадигмы, методы проектирования или методы разработки в целом (Waterfall, SCRUM, Kanban) являются лишь инструментами в ваших руках, и целесообразность их применения зависит от степени осознания их изначального предназначения.



P.S.
Мартышка к старости слаба глазами стала;
А у людей она слыхала,
Что это зло еще не так большой руки:
Лишь стоит завести Очки.
Очков с полдюжины себе она достала;
Вертит Очками так и сяк:
То к темю их прижмет, то их на хвост нанижет,
То их понюхает, то их полижет;
Очки не действуют никак.
«Тьфу пропасть! — говорит она, — и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них».
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.
За те же шесть лет мы раскрыли ровно ноль байтов данных третьим лицам

И это не правда. Банально пуши в ios отправлялись в открытом виде до осени прошлого года. Таким образом как минимум apple получали большую часть текстовых сообщений.

Таки нет. В комментарии выше шла речь о достижении первой космической скорости (~23М), а не о гиперзвуке как таковом. И здесь Boeing пока в пролёте — Waverider на испытаниях развил лишь 5,1М, тогда как Авангард достиг 27М.
Просто пределы роста — когда каждый следующий шаг начинает обходиться в 10 раз дороже и дольше, остановка становится неизбежна.

Физика — почитайте комплекс статей про ITER, установка зашкаливающей сложности и цены, которую строят в буквальном смысле всем цивилизованным миром. Дух захватывает, когда осознаешь что в одном роботе очистки камеры или системе глубокого захолаживания больше человеческих знаний, чем было на всей планете в 20 веке.
Космос — ракеты стоили как города. Последние Сатурн-5 (две замузеили, одну переделали в Скайлэб) стоили по 430млн$ за штуку, плюс на ракете стоит груз: корабль или модуль станции, ценой тоже в сотни миллионов долларов. И всё это — одноразовое.
Компьютеры — тоже начинается торможение. Постройка современных фабрик уже обходится в десятки миллиардов долларов (за каждый шаг на нанометр ниже), разработка архитектурно новых чипов — просто миллиарды долларов.
Проблема в том, что экспансия вытекает из сути человеческой природы, а следовательно — неизбежна.

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

Если вы не заметили, свободных континентов как бы не осталось, не считая Антарктиды, где потребные для выживания технологии не сильно отличаются от потребных на МКС.
Да, пока еще можно купить себе виллу на теплом берегу или остров в Тихом океане, но вот проблема — еще через пару поколений и они тоже закончатся. А лет через 200 — закончатся и домики у озера в своем родном регионе.
Да, социальные лифты еще ездят (хотя уже ощутимо скрипят), но на «верхнем этаже» становится тесновато и скоро выйти из лифта станет проблематично, даже если ты — Илон Маск, ведь миру нужна одна Тесла, может быть — пять, но точно не пятьдесят и не сто. А у жителей верхних этажей и свои дети подрастают, и совсем не хотят понуро брести по лестнице на социальное дно.
Да, условная «Кока-кола» может пока не переживать, у нее есть неохваченные рынки сбыта, но лет через 50 она доберется и до племен людоедов в Африке, а один человек — сколько ее не рекламируй — больше определенного количества той «Кока-колы» (или кокаина, тут разницы нет) не выпьет и не вынюхает. Однажды (причем довольно скоро, по историческим меркам — буквально завтра) расти станет некуда. А акционерам нужна прибыль, нужен рост, нужно увеличение капитализации.

Ресурсы Земли, при всех ее плюсах, конечны. Конечны нефть и газ (но это решаемо), конечен уран и торий (и это решить уже сложнее), конечны, в конце концов, вода и воздух (а вот чтобы решить это — нужны уже технологии сильно покруче, чем для полета на Марс), да и банальная территория, сколько ее не уплотняй, однажды закончится вся. Даже если попытаться построить Корусант (что, конечно, невозможно по очевидным причинам) — закончится текущими темпами лет через 300, если не поубиваем себя раньше.

А ресурсы космоса, в свою очередь, бесконечны. Любая инвестиция в экспансию на кратко-среднесрочном горизонте будет заведомо менее эффективна, чем в развитие чего-то на Земле, но в долгосроке — заведомо и бесконечно более эффективна. Условно, 0.001% акций трансгалактической империи Ситхов будет предсказуемо дороже, чем 100% любой корпорации на Земле.

Поэтому, как бы не казалось, что выбор у нас есть — выбора у нас, на самом деле, нет иного, чем выбор между деградацией и развитием.
Там убиственен следующий абзац:
<At the time when Gmail was being developed, existing email services such as Yahoo! Mail and Hotmail featured extremely slow interfaces that were written in plain HTML, with almost every action by the user requiring the server to reload the entire webpage. Buchheit attempted to work around the limitations of HTML by using the highly interactive JavaScript code, an approach that ultimately came to be called AJAX (Asynchronous JavaScript and XML).
Как мы дошли до жизни такой, когда AJAX, который был призван решить проблему «extremely slow interfaces» стал работать с такой скоростью, что люди готовы от него отказться и вернуться к «plain HTML» версии, которая, после всех рерганизаций, работает реально быстрее, чем этот новейший «дезигн»?
Гироборд признали настолько небезопасным, что во многих странах его эксплуатация была запрещена как на автомобильных дорогах, так и на тротуарах.


С электросамокатами аналогично — они запрещены на дорогах и тротуарах. Можно кататься на частной территории.
Основная ошибка в попытке трактовки пункта ПДД заключается в том, что из нормативно-правового акта взят только фрагмент, а остальная часть документа откинута. Поэтому кажется, что в тексте есть противоречия. А в реальности ПДД выглядят так:
24.1. Движение велосипедистов в возрасте старше 14 лет должно осуществляться по велосипедной, велопешеходной дорожкам или полосе для велосипедистов.
24.2. Допускается движение велосипедистов в возрасте старше 14 лет:
по правому краю проезжей части — в следующих случаях:
отсутствуют велосипедная и велопешеходная дорожки, полоса для велосипедистов либо отсутствует возможность двигаться по ним;
...;
...;
по обочине — в случае, если отсутствуют велосипедная и велопешеходная дорожки, полоса для велосипедистов либо отсутствует возможность двигаться по ним или по правому краю проезжей части;
по тротуару или пешеходной дорожке — в следующих случаях:
отсутствуют велосипедная и велопешеходная дорожки, полоса для велосипедистов либо отсутствует возможность двигаться по ним, а также по правому краю проезжей части или обочине;


И важно учитывать оба этих пункта. Они равнозначны.
Изначально, в соответствии с п. 24.1 все велосипедисты должны ехать только по велодорожке или велополосе. Должны — т.е. только там, если она в наличии, и нигде иначе.
Если велодорожка вдруг исчезла или на ней стройка, например, то допускается поехать по правому краю проезжей части. Но это означает, что как только снова появится возможность по велодорожке, то велосипедист должен снова ехать по ней.
Если нет возможности ехать и по правому краю, то допускается съехать на обочину, откуда мы должны сразу съехать на правый край проезжей части, как только будет такая возможность.
Движение же по тротуару опять же только допускается тогда, когда:
1. Отсутствует велодорожка.
2. Отсутствует возможность двигаться по ней (при её наличии), по правому краю проезжей части, по обочине.
Т.е. тротуар и пешеходная дорожка — это самый крайний случай для движения, откуда велосипедист должен сразу же уехать, как только у него появляется возможность ехать по обочине, проезжей части или велодорожке.
При правильно выставленных заголовках (Cache-Control, Last-Modified и Expires) повторный запрос 304 отправляется только при нажатии CTRL f5 в webkit браузерах и по F5 в фаерфоксе. Либо по достижение Expires.
При типичном использовании(когда пользователь не касается F5) никаких повторных запросов не отправляется.

При этом существуют техники которые заставляют браузер всегда брать обьекты из кеша, вне зависимости от F5 или CTRL f5.

Идее хранить css js и даже шрифты в localstrage сто лет в обед. И не прижилась она по нескольким причинам:
1. вся работа с localstorage снихронна, что означает — если какая то вкладка по каким то причинам запустить длинную операцию с storage то ваш влкадка будет ждать ее завершения.

2. операция stringify не бесплатна. И уже на обьектах в 40 — 100кб вы получите 40мс на десктопе задержку что больше чем если бы браузер сам взял обьекты из своего кеша. (а на мобильный платформах и того больше).

3. Закешированые браузером обьекты генерируют запрос 304 только в случае неверных изначально заголовков кеширования или (в зависимости от браузера) по нажатию f5 или ctrl f5

4. при загрузке ресурсов(css, js, img и так далее) по необхъодимости, а не сразу всего и сразу, даже нажатие ctrl f5 не заставит браузер слать запрос 304, а будет брать их из кеша.

В результате, выгода от local storage только в том случае когда вы:
А) не можете конфигурировать свой веб сервер для правильной отдачи заголовков для кеширования.
Б) если пользователь на очень медленном соединении по каким то причинам давит часто f5 у вас на сайте, при этом вы не используете «умную загрзуку» необходимых для страницы ресурсов.

Да дело не в IDE даже. Меня лично отталкивает то, что не видно никаких особых попыток решить фундаментальные проблемы этих систем. Та же проблема с diff — она повсеместная, и при этом она ломает всю коллективную разработку напрочь. Ну т.е. понятно, что тут нужны какие-то другие средства, включая и IDE — но не очень пока понятно, какие. В визуальном представлении имеется куча семантического "мусора", т.е. не обязательных, или дополнительных свойств этого вида кода, который очень трудно фильтровать от свойств, нужных в первую очередь.


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

Вот это дельная идея. Только не очень масштабируемая :) Я вам расскажу, что Gradle вплоть до относительно поздних версий (0.5, что-ли) вообще по дефолту шёл с отключенной транзитивностью. А потом его начали использовать в энтерпрайзе :D

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

Так что я считаю, что транзитивность можно оставить, но стратегия fail + контроль за изменениями — это наше всё.
Я совершенно не согласен с тем, что решение для jar hell — osgi. Он идеально подходит в случаях, когда несколько версий одного класса необходимы (например, pluggable софт). Но пользоваться им просто потому что ваш инструмент сборки коряв и не может дать вам нормального решения конфликтов? Overkill-чик.

Информация

В рейтинге
Не участвует
Откуда
Беларусь
Дата рождения
Зарегистрирован
Активность