Pull to refresh
-13
0
Алексей @murkin-kot

Программист

Send message

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

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

И третий случай - реальная защита прав большинства. В чём отличия от банды? В том, что банда живёт ради эгоизма. Эгоизм, в первую очередь, поднимает наверх самых отъявленных эгоистов. И они себе делают много денег. Что останется - бандитам. Ну а большинству предложат пососать лапу.

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

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

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

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

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

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

Каков ваш профсоюз, товарищ автор?

То есть у затопленной струи нет никакого снижения давления в поперечном направление.

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

Расширение струи воды за счёт давления пара при "кавитации" конечно
можно учитывать, только при аккуратном расчёте вам не удастся расшвырять
струю в стороны

Обратите внимание на ваши собственные иллюстрации за номерами 18 и 22. Всё там почему-то "расшвыривается" в стороны.

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

Вам выше подсказали - укажите на подтверждаемые экспериментом противоречия фактов и общепринятых теорий. И ещё лучше - дайте свои формулы, которые указанное противоречие снимают. Но как-то ваш спор выше не показал наличия конструктива в вашем подходе.

Зачем им 40 миллионов запросов в секунду?

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

Значит система явно перегружена внутренними коммуникациями. Но что это за коммуникации? Ответ прост - микросервисы. Вместо пусть миллиона в секунду (и то много) имеем на пару порядков больше.

Но как происходит отсос воздуха в этой конструкции?

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

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

То есть объяснить явление можно без проблем для существующих теорий.

Против ORM массово есть два возражения:

  1. Не знающий SQL всё испортит.

  2. Знающий SQL привык писать только SQL.

Первое устраняется принятием в команду грамотного специалиста. Второе устраняется принуждением написать два варианта - SQL и ORM, с полным пониманием, как оно внутри работает. Второй вариант обычно показывает, что понимания примерно столько же, сколько в варианте №1.

Вывод - вся критика ORM исходит от непонимания. И от нежелания понимать (это про фанатов чистого SQL в первую очередь).

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

В эпоху засилья микросервисного подхода, когда для получения данных из БД пихается сообщение в кафку, которая находит один из тысячи микросервисов, ответственный за выполнение select * from table1, затем отдаёт сообщение микросервису, который уже через сотню фасадов и прочего нагромождения (включая ORM) наконец где-то глубоко в недоступных потрохах передаёт SQL в одну из сотен баз данных (ага, по БД на микросервис), действительно оказывается, что добавление ORM к этому монстроидальному зоопарку ничего не меняет, кроме одного важного момента - без ORM нельзя копипастить готовые шаблоны простейших действий из интернета. Что возвращает нас опять к началу - мы имеем засилье самых примитивных погромистов вместо действительно необходимых специалистов.

Взглянув на такую схему получения данных из БД, пишущие на SQL действительно хватаются за голову и начинают ломать вокруг себя все 4-5 мониторов, которыми окружены как модница приблудами для покраски ногтей. Но граждане, вы не туда смотрите! Точнее - вы видите собачий бред, позволяющий за приложения уровня Hello World получать миллиарды денег. Но ORM здесь не при делах! Неуиноатый он, вот так.

ORM действительно ускоряет разработку. Но не модную, а эффективную. И если вам по жизни не повезло и вы не встречали на трудовом пути эффективные решения с ORM, то хотя бы не вставайте сразу в позу отрицания и вспомните, что в мире есть решения без микросервисов, кафки и прочего лютого треша. И это значит, что вы прошли мимо этих эффективных решений. Что в свою очередь означает - вам ещё учиться, учиться и учиться, много лет. Но ORM в этом не виноват. Это просто вам не повезло. Хотя знайте - так же как и вам не повезло ещё 95% погромистов, потому что когда на каждый приличный банк приходится по 1000 разработчиков, это означает, что 50 из них реально нужны, а 950 - всего лишь перекладывают json-ы из кафки в микросервисы, не создавая при этом ничего полезного с точки зрения логики бизнес-процесса. Так что сломайте свои мониторы не злобы ради, но понимания для. Поймите - инструмент ORM не виноват, а виноваты... ну вот такие у нас социальные условия, таков метод производства общественного продукта.

Вы, опять же, можете лично спросить ChatGPT. Мне он заявил, что знает больше десятка форматов, я выбрал ARIS, он нарисовал. Смысл нарисованного вполне понятен. Возможно, поскольку чат русскоязычный, он перевёл все xml-тэги на русский. Но всё это вы сами можете узнать у него.

Вы не мой читатель, пожалуйста, не читайте больше моих статей

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

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

На этом пункте всё ломается.

Кто напишет плагин? Кто будет хостить сеть доверия? Кто будет перехватывать трафик сети? Кто будет подменять в своих интересах все необходимые ему данные?

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

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

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

Вам самому лень попробовать? Это доступно в РФ, причём бесплатно, нужно всего лишь научиться пользоваться гуглом.

Вот маленький пример генерации:

scss
eEPC
Function Покупка на кассе
Start (Круг)
->  Подойти к кассе (Функция)
->  Провер��ть наличие штрих-кода (Функция) [Да/Нет]
-> Да (Переход)   ->Считать штрих-код (Функция)
-> Нет (Переход) -> Найти товар в списке (Функция)
->  Наполнить списокк ��п��ате (Функция)
->  Нап��ч��тать чек (Функция)
->  Получить деньги (Функция)
End (Круг)

Здесь редактор решил, что язык называется scss, но я просил у чата язык ARIS.

Не могу простить. Потому что вы ушли от своих косяков в неуместные извинения.

Так и остались висеть следующие проблемы:

  • Заголовок не соответствует содержанию.

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

  • Вместо этого много воды про зарплаты, которые есть всего лишь часть настройки процесса, а не отдельное явление, как показалось автору.

  • Размер текста для донесения выше обозначенных мыслей слишком большой.

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

Последний пункт - подсказка, как сократить текст во много раз.

Сегодня актуален ChatGPT. Рассказываем ему процесс и просим текст в интересующем формате в какой-то нужной нотации. Даже правила заполнения таблицы учить не нужно.

Хотя качественно так моделировать не получится. Но и табличное представление так же не даст всей необходимой гибкости.

Поэтому для начала - ЧудоЖПТ, далее - таблицы, затем - зубрить (в процессе работы, что легко) нотацию (или много нотаций).

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

А в мае стартует новая программа «Java разработчик. Уровень Специалист»

А, ну вот и понятна цель текста...

Именно поэтому всё преподносится в духе:

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

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

Хотя один момент подмечен правильно:

большое значение для разработчиков имеют soft skills

Вы должны с пониманием отнестись ко всем требованиям со стороны руководства. Если же на вашем лице нет улыбки - у вас плохие soft skills, мы с вами свяжемся при возникновении потребности.

Как «оптимизация» зарплат вредит бизнесу, и что делать

Вводящий в заблуждение заголовок.

Текста тоже многовато.

Вот его содержание:

Сперва нанимаете лучших сотрудников и платите высокую зарплату, организуете процессы, продолжаете нанимать и инвестируете в людей - потом ожидаете рост результатов

В остальном текст просто обосновывает выше приведённую цитату разного рода примерами про Форда и прочих умельцев на ниве организации труда.

Ну и кривизна - нет акцента на важном. Сначала понимаете, как организовать процессы. Всё остальное - следствие.

Про зарплаты же автор приводит пример Амазона - он тупо создаёт большой перепад давления, чем и засасывает к себе постоянно меняющихся (400% текучки в год) работников. То есть автор топит за самый тупой пылесос - делаете большую з/п и балдеете от огромного стада желающих. Но главное здесь - сначала понимать, как организовать процессы. В том числе, процесс высасывания навыков с рынка. И Амазон здесь - плохой пример. Здоровый и богатый противопоставляется бедным и больным. Где стартапу взять денег на з\п в разы выше рынка? Вот на этом моменте все заявочки про Амазон моментально превращаются в пустой шум.

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

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

Вместо поворота нужно некоторое время ехать боком.

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

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

ЗЫ. Есть ведь расчёты неравномерности износа колёс при повороте? Применяем эти формулы к колесу метра два шириной и получаем точную оценку жизнеспособности конструкции с монолитом. А вот с дифференциалами жизнеспособность вообще непонятно как считать.

Нам кажется, внедрение такого решения оправданно, если разработчиков становится больше тысячи

Мне кажется, что раздувание штата разработчиков до 1000 как раз и явилось главной причиной проблемы в ИТ. Хотя да, кто-то вне ИТ одобрил этот подход.

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

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

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

Напомните пожалуйста, как общий случай запрещает изучать частные?

Истории о вреде локальной оптимизации

Кому война, а кому мать родна...

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

Information

Rating
4,717-th
Registered
Activity