Вопрос автору-знатоку по кондиционерам. Сплит-системы неудобны необходимостью сверлить стены и устанавливать вентилятор с помощью альпинистов. Поэтому тепло можно было бы стравливать другими способами, например - отводить водой. Отпала бы нужда во внешнем неудобном и трудносъёмном блоке, а так же в дорогостоящих работах.
При охлаждении водой можно подключиться по той же схеме, что и для стиральной машины. Единственное ограничение - воды должно потребляться меньше по стоимости, чем электричества в сплит-системе. То есть стоимость эксплуатации должна быть близкой к сплит-системе. При отсутствии затрат на сверление и установку суммарно получится выгода, плюс добавится мобильность для тех, кто, например, снимает квартиру. В этом случае можно допустить повышенную стоимость эксплуатации в сравнении со сплит-системой.
Я грубо прикидывал, но всё упирается в знание конкретных параметров фреонов и различных коэффициентов на потери, которые я с достаточной степенью тщательности не изучал. Где-то плюс-минус баланс энергии находится рядом со сплит-системой, но неизвестные параметры всё портят. Может автор знает коэффициенты? Или кто-то уже давно такую схему обсчитал и понял - бесперспективно (но здесь хотелось бы расчёты).
Наука всего лишь показывает путь, а пойти по нему должны сами люди. То есть когда и вы, и много других людей, откажутся от идеологии эгоизма, и не на словах, а на деле объединят свои усилия - вот тогда все проблемы, которые в нынешнем обществе считаются неразрешимыми, внезапно станут вполне доступными для решения.
Если спрашивают про спринг, значит хотят, что бы джун пришёл и сразу начал давать результат именно на спринге. Видимо поэтому и отказали, ведь по спрингу много гораздо более подготовленных.
Оценки базовых навыков так же субъективные, как со стороны кандидата, так и со стороны спрашивавшего. Поэтому не стоит воспринимать их как-то близко к сердцу.
База, на самом-то деле, вычисляется просто - вот ситуация, вот ограничения, как сделать так, что бы всё стало работать в десять раз быстрее? Здесь сразу видно, понимает человек, как оно внутри работает, или только заучил базовые конструкции, которые не помогут писать оптимальные по ресурсам программы. Ну а если такая база есть, то и как внутри устроена JVM, и многое другое человек будет понимать достаточно хорошо, что бы в большинстве мест сказали, что база нормальная.
Но сами интервьюеры далеко не без греха - если они считают какую-нибудь мелочь очень важной, то всё, если вы её не знаете - отказ. На самом же деле это исключительно их личное и никому более не интересное мнение. Но корпоратив устроен так, что никаких вменяемых подходов к проведению эффективных интервью никто делать не будет. Один раз в толстых конторах типа гугла сочинили набор скриптов для собеса, и всё, далее только этот подход. А в конторах попроще вообще ничего не сочиняют, поэтому и пользуются инициативой интервьюирующие. Плюс очень часто подбирают под себя по субъективной психологической совместимости. То есть - всё та же случайность. Даже если вы перед этим очень серьёзные программы писали. Субъективная оценка вас срежет только за то, что вы не подошли по каким-то частным, или вообще личным критериям интервьюера.
Но это всё не отменяет необходимости наращивать базу в глубину. Так что вашему знакомому явно есть куда расти. Как минимум - сам он не дошёл до простейшей мысли - все эти спринги есть производная от именно базовых знаний, обладая которыми, он никогда бы не мешал в одну кучу спринг со всем остальным. Это как смешивать физику с математикой. Без математики ничего не посчитаешь. Но физики должны знать именно предметную область, то есть законы природы. Ваш знакомый же месит в куче квадратные уравнения с законом всемирного тяготения, хотя ещё в школе дети узнают, что это разные дисциплины. Так и в программировании.
Спасибо, стало понятнее, что читателю необходимо хорошо помнить детали работы с КТО, которые есть в той же википедии по вашей ссылке, но для понимания текста они заранее должны быть в голове, либо их нужно туда положить, перейдя в википедию во время чтения и усвоив там с пару страниц формул, а потом уже снова переключиться на статью.
Но вы бы сэкономили читателю это время, указав промежуточные шаги вычисления, благо они довольно простые, хотя и занимают место. Ссылка на документ в dropbox предполагает именно отсутствие экономии времени, точнее даже гораздо большие затраты на дополнительную информацию.
Хотя возможность ответа в комментариях, в общем-то, проблему нивелирует.
Ну и до кучи, просто добавив в ваш комментарий указание "как видно из примера, перебирая точки, получаем на одно умножение полином первой степени, на три - третьей, на шесть - шестой, то есть степень полинома (или разрядность числа) растёт пропорционально количеству умножений, а не его квадрату" ваши затраты выросли бы очень незначительно, но ясность изложения была бы заметно улучшена.
Хотя я понимаю, что краткость изложения в привычном математикам стиле требует ещё большего сокращения объёма статьи. Но вы же пишете на популярном ресурсе, что предполагает несколько другую аудиторию.
БПФ получилось без китайской теоремы об остатках. И вывод быстрого умножения так же возможен без её привлечения. Хотя, возможно, вам известен вывод БПФ через упомянутую теорему?
И про увеличение длины на каждом шаге не понял. При одном умножении степень многочлена увеличивается на единицу. Какая длина при этом увеличивается вдвое?
Описание использования китайской теоремы в статье так же не дошло до моего мозга. Pn = P mod (многочлен) - здесь два неизвестных, Pn и P, многочлен известен, но получение Pn и P непонятно.
Более того, вы далее описываете способ подбора точек так, что бы они образовали мультипликативную группу. Затем эту группу вы находите в преобразовании Фурье. После чего переходите к рассуждениям о совпадении с Фурье лишь при конкретных значениях. Где здесь связь с шагами, которые дают нам степени двойки на каждом из них?
А китайская теорема всего лишь указывает нам на произведение модулей. Но вот свойства мультипликативной группы как раз и позволяют нам комбинировать и заменять отдельные составляющие в квадратичном по сложности алгоритме, сводя их к линейной сложности с логарифмом за счёт рекурсивного использования.
Преобразование Фурье, как и другие преобразования (Хартли и т.д.), используют свойства суммы ряда циклической группы, в частности с домножением на коэффициенты. Выгода от использования подобных преобразований появляется именно из-за свойств используемой группы.
Другое дело, как показать эту выгоду без привлечения подобных преобразований. Сейчас быстрое умножение выглядит как некая магия, считаем по каким-то формулам, и почему-то получается быстрее. Почему? Потому что так получается по формулам. А почему так получается по формулам?
Поэтому математику ещё ждёт открытие свойств циклических групп, более наглядно объясняющих, что же там за занавеской из формул на самом-то деле происходит.
На случай. Всё остальное - не работает. Удачно столкнётесь с правильной конторой/человеком - вам повезло.
У нас Java-джунов ищут годами. Требования минимальные, по сути базовое знание языка, плюс что-то из SQL, ну и хоть какая-то сообразительность. За полтора года нашли одного. Вакансий много. Почему так?
Как и почти везде - в корпоративе очень низка эффективность внутренних процессов. Найм - не исключение. В других местах не лучше. Хотя те, кто вакансии передаёт кадровикам, считают, что рынок пустой, плохой, холодный и т.д. А то, что система в целом неэффективна - никто никогда не скажет, ведь это и их самих в неприятное положение поставит.
Так что надежды джунов могут быть только на массовую рассылку и случай. А до наступления случая - качайте хард-скиллы, их реально нет у многих постучавшихся.
Не учитывая ряд спорных моментов текста, впечатлён как точно автор описал местных комментаторов в образе себя в юности. И вот такое задаёт тон на этом ресурсе.
Авторам урок, стоит или нет увлекать местных высоким (кроме наивысших удовольствий, разумеется).
Вы думаете, западный софт не ориентирован на прибыль? или вы думаете, на западе не было периодов, когда в том или ином направлении складывалась ситуация, аналогичная нашему импортозамещению?
Другое дело, у нас на рост "отечественных" решений направляют деньги, изъятые у населения, а на западе деньги добровольно несут так называемые "инвесторы". Хотя последние тоже косвенным образом изымают деньги у населения, но разница всё же есть.
Разработка приклада - АД кромешный
Большие конторы это делают сами, ну а остальные в большинстве просто не понимают, что им на самом деле нужно. Хотя большие тоже не понимают, но удовлетворяются хотя бы фактом самостоятельного творчества, за которое винить посторонних не очень логично. Зато свои собственные решения для инфраструктуры даже толстые конторы не хотят взваливать себе на плечи. Привыкли, что осей на свете ровно две, и пилят их всегда другие. Запилить свою? Да вы что, это же не наши компетенции! А пилить микросервисы подразделениями в несколько тысяч человек - ну до чего же "своя" компетенция.
Глобально рулят денежные знаки. Ими "управляют" наёмные рулевые. А у них подход простой - деньги направляем туда, где светит максимум прибыли. Это может быть абсолютно любое направление. И разумеется, ни в одном из них компетенций у рулящих деньгами нет, слишком много направлений для столь уважаемых людей. Но есть выход - компетенции покупаются и продаются. Правда оценить качество покупки рулевые опять же не в состоянии, но пока у конкурентов дела идут точно так же - о чём беспокоиться?
Единственное, что удивляет, почему в мире ещё так много людей, которые ждут от такой системы качества? Ведь каждый же считает себя умным, разве нет? Но почему-то ждут чудес, которых, как давно известно, на свете не бывает.
Что насчёт оптимальности предложенных для примера алгоритмов?
Доказать применимость можно для любого алгоритма, но эффективно решать задачу это не позволит. Для эффективности требуется нечто большее. Есть это нечто в описываемой структуре?
В примерах видим два этапа - построение структуры из статьи, а затем использование структуры в дополнительном алгоритме. Есть аналогичное по применимости множество индексных структур, позволяющих делать то же самое, но с доказанной оптимальностью (вычислено О большое и показано, что оно лучше других). Чем индексы хуже предложенной структуры? Точнее - собственно индексирование должно быть менее затратным в случае, если структура из статьи действительно полезна. Хотя возможно уменьшение затрат второго этапа при худших показателях первого. Но эти вопросы автор не осветил. А стоит подумать.
Критика статьи больше в том, что это тепличный и не массовый стиль управления
Это не стиль управления. Это один из способов мотивировать сотрудников. Управлять и мотивировать - очень разные вещи, видимо ортогональные.
Собственно управление, как и везде, осуществляют выборные начальники.
На сколько этих начальников легко сдвинуть с должности - большой вопрос. Весьма вероятно, что они меняются редко, то есть для остальных попытка их пододвинуть фактически бесперспективна. Тогда это самый обычный бизнес, но с хитрой системой мотивации, про которую не сразу ясно, кто кого имеет. В сравнении с "добейся отличных результатов и тебя повысят" это шаг вперёд для собственника. Но для общества это скорее печально - собственник нашёл очередной способ скрыть суть эксплуатации.
Хотя в тексте есть что-то про плоское распределение доходов. Возможно, вся мотивация в основе полностью эквивалентна привычной сдельной оплате, но вот этаким образом занимательно оформленной.
Что порекомендуете в тему "активации" участников к управлению?
Либо готовая система, либо исключительно личный интерес. Если есть готовый кооператив, то они уже знают, что им надо, это и есть ваш рынок. А если нет - вам остаётся искать личный интерес конкретных жильцов. Скорее всего бизнес на "пустом месте", то есть без готовой кооперации жильцов, в итоге провалится. Затраты большие - личный подход к каждому жильцу. Не потянете.
Хотя может найдёте какое-то мотивирующее некую нишевую группу жильцов дело, и предложите в этом деле облегчение. Но суть всё равно та же - личная мотивация, только с поправкой на некоторую массовость в рамках ниши.
Общая проблема наивного подхода к сжатию данных состоит в отвлечении внимания от сопутствующих действий. Таковыми являются, например, вычисления, производимые над сжимаемыми и разжимаемыми данными. Если же обратить внимание на вычисления, то мы заметим небольшую проблему - для сжатия произвольного файла нам потребуется что-то вроде вычислительной мощности, какой нет во всей вселенной.
Но само по себе сжатие на порядки произвольного (и при этом достаточно длинного) файла вполне возможно.
Идея такого сжатия тривиальна - сопоставим выбранному файлу число 1. Ну вот - мы сжали выбранный файл до одного бита. Кто-то будет спорить?
Но есть здесь та самая проблема. Для сжатия второго файла потребуется сопоставить ему другое число, например 2. Для третьего - 3, ну и так далее. Только произвольных файлов , длиной N бит, может быть два в степени N. Значит нам придётся каким-то из них сопоставлять значения из N бит, то есть сжатие куда-то потеряется.
На этом простом примере мы поняли, что сжать все произвольные файлы мы не можем. Но это не значит, что мы не можем сопоставить одному из этих файлов число 1. То есть если мы забудем про общий подход (сжатие всех файлов), то очень большой коэффициент сжатия становится вполне возможным. Да, математики своим генеральным методом несколько обеднили возможные математические же результаты.
Кто-то когда-то предлагал сжатие на основе числа пи. Там всё просто - вбрасываем в игру бесконечные вычислительные мощности и затем играючи находим адрес в бесконечной последовательности знаков числа пи, начиная с которого наш сжимаемый файл в точности повторяется в числе пи. Берём этот адрес и длину файла - вуаля, мы сжали файл до некого меньшего числа. Но возможен нюанс, нет гарантий, что адрес файла в числе пи не окажется по размеру больше самого файла. Опять проблема.
Автор уже столкнулся с подобной нестыковкой, когда понял, что сжатие его способом получается лишь при больших размерах файлов. А при малых получается лишь увеличение размера. То же самое характерно и для числа пи, как и для любой другой достаточно длинной псевдослучайной последовательности.
Собственно вывод:
Да, сжатие на много порядков вполне возможно. Но для этого получатель должен уже обладать оригинальным файлом, то есть без сжатия, хотя и в зашифрованном виде (число пи, например). Далее мы передаём получателю номер файла и он "разжимает" файл в гигабайты из нескольких бит. Вычислительные сложности, разумеется, в полном соответствии с привычкой математиков решать проблемы в общем виде, мы оставляем прикладникам. Альтернатива - способ создания хранилища всех файлов в несжатом виде (дабы "сжимать" их указанием номера) мы тоже оставляем чумазым механикам, ведь наше дело стратегия, правильно?
Автору (и ему подобным) стоит конкретнее определиться, чего они хотят. Моё предположение - хотят денег. Тогда всё написанное автором вообще никак не соответствует заданной цели.
Деньги - это локальная оптимизация. Надо быстрее и при минимуме усилий. Магистратура - это практически максимум из доступного набора усилий. На лицо очевидное проитиворечие.
Поэтому всем желающим денег рецепт такой:
Рассылайте много резюме.
Демонстрируйте "сообразительность" (расплывчатое понятие, сильно пересекающееся с софт-скиллами).
Вызубрите прикладную часть. Здесь очень желательно понимание. Но можно проскочить на невозможности задать вам все возможные вопросы.
Если зубрёжка успешна, но на собеседованиях вас посылают, значит они находят вопросы "на понимание". Тогда ваша задача всё же приобрести это самое "понимание".
Понимание, в применении к начинающим, требуется неглубокое, но всё же достаточно приличное. Поэтому здесь можно посмотреть на какие-то курсы, или даже ролики/тексты.
Курсы предлагают упражнения - это рецепт для понимания. Ролики может и предлагают, но никто их упражнения не делает. Поэтому заплатите денег, что бы ваша жаба заставляла вас выполнять упражнения. Хотя курсы могут не требовать их выполнения, тогда это аналог бесплатного ролика и такие курсы должны идти лесом.
Переходите к пункту 1, и так в цикле, пока вас куда-то не возьмут.
Науковед рассказывает о "науке" в замкнутом идеальном пространстве, лишённом реалистичности.
Главная проблема науки (как и всего общества) - кто ею правит. Но науковедам про это говорить запрещено. То же самое относится и к низким человеческим качествам управленцев среднего звена в научной деятельности. В итоге вместо науки имеем имитацию. Но науковедению про это ничего неизвестно.
Зато много разговоров о бессмысленном:
Дело в том, что последние 10‑15 лет наукометрия всё активнее начинает использоваться чиновниками для оценки эффективности научных организаций и отдельных ученых
То есть о следствии безумства управленцев. Повторюсь - не о причине (о самом безумстве), а видите ли, о не вполне удовлетворительном использовании какого-то там очередного умного слова, для которого в научных кругах находят как плюсы (это как?!), так минусы.
Вот так, обтекаемо и ни о чём, исследуют науку настоящие учёные. Так каких же достижений ждать от таких исследований?
С client_service тоже определенные проблемы - т.к. клиентами могут быть и сервисы
Любая сущность, использующая сервис, является его клиентом. При этом user всегда переводится как "пользователь", то есть сразу исключается все классы программных сущностей.
Но здесь вынужден следовать оригинальной терминологии авторов RINA
Вы сами пишете, что на западе к ним серьёзно не относятся. Кроме того, стоит указать на абсолютно произвольный характер используемых в IT терминов. То есть любое слово, которое понравится лицу, приближённому к бюрократическим глубинам, формирующим мировые стандарты, просто записывается в стандарт как данность. И никого (из бюрократов) не волнуют сложности у пользователей новых стандартов.
Кроме того, я не думаю, что западный мир вообще хоть на миллиграмм заинтересует, как там русские перевели ихние слова для своего внутреннего использования. А вот у нас уже вы можете выходить на массовую аудиторию, учитывая недостатки западного бюрократического подхода. Это означает необходимость глубоко продумывать не только архитектуру, но и терминологию. В конце концов - для чего вы это делаете? Если только для прибавки единички к количеству публикаций, тогда да, можно писать всё, что угодно. Но если вы ожидаете хоть немного большего, то стоит уже думать о восприятии вашего продукта другими людьми, а это опять возвращает нас к терминологии.
По сути возражений о гомогенности/гетерогенности и уровнях:
Если отойти от фиксации на западных названиях, то вы полностью вольны выбирать свои. Принимаю негативные моменты в использовании гомогенности и уровней, но тогда считаю правильным вообще уйти от единичных терминов в сторону более сложных словосочетаний. Например - логическая структура сети из гомогенных сегментов, независимая от физической реализации, поясняя далее, что каждый сегмент состоит из узлов, включающих сервисы, обеспечивающие удалённое взаимодействие клиентских сущностей. Если коротко, то получим - логически гомогенная сеть, но слово "логически", без сомнений, чаще всего будут опускать из-за стремления людей к упрощению.
Можно ещё предложить что-то вроде - сеть независящих от реализации сегментов с единообразной логической структурой. И не стоит бояться количества слов, ведь всегда можно перейти к, например, аббревиатурам, или, ссылаясь на полное название, предлагать краткие.
Очень редко вижу в этом мире приличную архитектуру. Вызывающую приятные чувства - не видел уже лет 15. Предложения автора на этом фоне является очень редким исключением.
Предложу скорректировать терминологию (архитектуру не надо, она достойная).
user_service на самом деле должен быть client_service. Потому что пользователь и клиент - две очень сильно разные сущности. Слово user обязательно будет вводить в заблуждение и запутывать новичков, потому что ассоциируется с людьми, к тому же, часто малограмотными и по части устройства сетей тоже.
Слово "рекурсивные" в словосочетании "рекурсивные сети" нужно заменить на "гомогенные многоуровневые". Гомогенность есть одинаковость принципиального устройства уровней. Ну а уровней может быть много.
Отличие рекурсии от многоуровневости:
Рекурсия определяется обрабатываемыми данными, а количество уровней определяется конфигурацией сети. Конфигурация есть метаданные, которые нельзя путать с обычными данными. Пример - рекурсивно обходим граф, при этом количество уровней вложенности обработки определяется графом (данными). В случае сети метаданные меняются редко (новые слои не так часто добавляются) и не являются непосредственной целью процессов, обеспечивающих работу сети (непосредственная цель - передаваемые данные).
Желаю автор успехов, сожалею о минусах за статью, аудитория ждёт развлечений, а не глубину понимания.
Тут могут предъявить за излишне интенсивное использование динамической памяти - new/delete
Вот это довольно показательный момент. Он суммирует наш разговор. Вместо быстрого решения задач вам приходится думать о быстрой работе компьютера. Про стоимость работы программиста я вам писал, но раз вам "предъявляют" за минимальные попытки ускорить написание программ, то здесь я уже не могу помочь. Выбор в сторону оптимизации скорости исполнения сделан не вами, но вы его полностью приняли и отказываетесь воспринимать альтернативы. 10% по вашему очень много. Ну ладно, я вам писал про в 15 раз дороже в случае сравнения стоимости компьютера и труда. Это тоже вас не заинтересовало. Но чем тогда вас убеждать?
Вот совсем коротко:
Труд дороже железа. Доказать пытался, но не вышло.
Бой за 10% ускорения стоит в разы дороже, чем решение той же задачи без ускорения на 10%. Опять пытался доказать, но не получилось.
Оттуда же, откуда знаю, как решать квадратное уравнение. В математике такие вещи доказывают. В программировании это все по разному называют, я бы назвал - качественное проектирование.
огромное количество собранных статистик у нас показывают что SQL не во всех случаях является оптимальным с точки зрения производительности
Я не говорил, что стандартный инструмент во всех случаях лучше. Я говорил, что он во многих случаях (в большинстве случаев) экономит усилия программиста при достаточно эффективном результате. Достаточно эффективный, это такой, когда нет смысла экономить миллисекунды при времени исполнения минуты.
Это статическая структура, объявленная во время компиляции и куда вы просто читаете с диска блок данных (запись), или класс, у которого в рантайме вызывается конструктор, выполняющий каки-то преобразования?
Эта структура - класс. С накладными расходами в виде конструктора и чего-то ещё. Теперь математика: время чтения с диска, пусть будет SSD, положим 1 миллисекунда, затем преобразование в нужную нам структуру. За миллисекунду пусть прочитали 100 килобайт по сто байт структур (это пиковая, редко в реальности достижимая скорость выборки строго нужных данных). То есть всего 1000 структур. Время выполнения конструктора и прочего для каждой структуры - пусть 100 наносекунд, хотя всё это в кэшах и в цикле, так что процессор много чего может оптимизировать. Итого имеем 100 микросекунд на всё. Всего имеем примерно 10% затрат на конструкторы и 90% на чтение. Далее напишите всю обработку вручную, вместо одной строчки, как я показывал. Сравните свои затраты с моими. Получите в 100 раз больше, чем у меня. Вспомните про стоимость программистов.
для каждой задачи есть наиболее эффективный инструмент
Есть всего лишь эффективные и неэффективные решения. Разница определяется расчётом. Это просто математика. Её вполне способен считать компьютер.
Вот три ситуации:
Всё это шаблон. Шаблон такой: отображение, фильтрация, вычисление, запись данных. План запроса в каждом случае я вам вычислять не буду, это трудоёмко, но единожды написав программу вычисления подобных планов запроса, я автоматизирую все ваши ситуации. Хотя заранее признаю, что план запроса может быть по каким-то критериям неоптимальный. Так что вы, в каких-то случаях, сможете опередить мой планировщик. Но в некоторых случаях даже вы не сможете его победить.
А теперь вспомните, сколько времени вы потратили на решение этих задач. Сравните с программистом, который пользуется оптимизатором, работающим за него. Ну и снова вспомните стоимость труда программиста.
Сэкономили на разработчиках, сэкономили на тестировщиках. Получили плохой код. В результате в период "пиковых нагрузок" все встало колом
Ну вы ожидаете от меня откровенно тупых решений. То есть я увольняю всех умных и оставляю только тупых. Вы действительно думаете, что я умею только вот так работать?
Язык позволяет формулировать новые команды. Таким способом я получаю максимально удобное представление операций. А что там внутри новой команды, в момент использования библиотеки я понимаю, но чаще всего могу просто не думать об этом, потому что знаю, что преобразование в SQL будет достаточно эффективным. Хотя конкретно вам могу объяснить - вы видите, как происходит сбор данных для подготовки SQL, а внутри, уже в момент выполнения запроса, из собранных данных формируется корректный SQL, достаточно эффективный, то есть если нужно получить запись по id, то будет такой результат: select * from table_name where id=?, ну а потом, после получения результата, запись будет скопирована в соответствующую структуру, которая задаётся классом. Итогом будет объект, содержащий данные из запрошенной записи.
И которое не везде применимо. У нас вот не очень
Здесь вы уходите в область вашего представления о разработке. Я вам только замечу - ваше представление не является единственно верным. То есть другие представления могут быть эффективнее. Но что бы доказать это я буду вынужден растягивать эту беседу на очень долгий срок, чего мне не хочется делать. Скажу только коротко, что большая часть задач в теме OLTP (а именно эта часть актуальна и для банка и для кучи других организаций) автоматизируема до уровня "программист вообще не нужен". И без всякого модного ИИ. Другое дело, к счастью для многих программистов, со стороны бизнеса нет достаточного понимания самого себя, что бы эффективно пользоваться такими инструментами. А достигается полезный результат (при условии соответствующего по уровню развития бизнеса) именно переходом на высокие уровни абстракции, которые в RPL вы застрелитесь формулировать.
На самом деле в каждой новой задаче у вас будет свои условия выборки по своим таблицам которая дает свой набор данных
Вот, вот. Условия-то свои, а всё остальное - полностью идентично. Подставляй значения в шаблон и получай радость.
Но вот логика - это основное. Это везде свое. Общих мест не найдете
Найдём. На то и созданы абстракции. Их суть в том, что бы эти общие места находить.
Все структуры формируются в compile time. Дальше туда уже читаются данные
Здесь вы просто не поняли, о чём речь. Классы - это структуры, которые да, формируются при компиляции. И потом наполняются данными во время выполнения программы. Об этом я и говорил.
Идешь и смотришь код - мама дорогая... Какой-то программист-абстракционист писал. Абстракция на абстракции и абстракцией погоняет. Все очень концептуально, но... Работает медленно
Да, можно переусложнить, можно замедлить, можно вообще всё испортить. Но это не значит, что нельзя сделать эффективно. Хотя соглашусь, что эффективно сделать не просто, от того и появляются все перечисленные косяки.
Быстродействие и эффективное использование ресурсов - это то, что тут всех интересует и ценится в первую очередь
Не так. Вы указываете на стандартную ошибку - оптимизацию по простейшему критерию. Вы выбрали критерий - стоимость железа. Допустим ваш сервер стоит миллион долларов. И на него пишут программы суммарно 100 человек (для разных частей АБС). Допустим у них скромная з/п, со всеми накладными (налоги, офис, страховки и т.д.) путь на человека будет 250 т.р. Итого имеем 25 миллионов рублей в месяц, или примерно 3 миллиона долларов в год. Если железо полностью заменяется раз в 5 лет, то расходы на людей в 15 раза больше его стоимости. То есть если сократить затраты труда программистов на 1/15, получим выигрыш в размере стоимости железа. За 5 лет при выделении миллиона долларов на сокращение затрат труда программистов абсолютно реально не то что на 1/15, а весьма вероятно на десятки процентов сократить потребность. Вот вам и пример - вы выбрали ошибочный критерий оптимизации, то есть если бы выбрали критерий "стоимость работы программистов", то получили бы в разы большую экономию.
Одну строчку, примерно как вы её видите. Я немного сократил и переименовал части для большей понятности, а в остальном - именно так и выглядит.
Здесь смысл такой - человечество придумало множество удобств, сокращающих затраты труда программиста. Но пока вы их не прочувствуете на личном опыте, вы не поверите. Надеюсь, что ООП вам знакомо, так вот на его примере мы видим объединение логики со структурами данных, которое даёт нам то самое упрощение. Нам нет необходимости заглядывать внутрь объекта, ведь мы знаем, что всё нужное там уже есть (алгоритмы и данные), поэтому мы просто используем выставленный наружу функционал. Сравните с привычным вам подходом на си - отдельно данные и отдельно функции (алгоритмы). И вам приходится структурировать программу так, что бы ненужные данные не захламляли вашу текущую задачу. А в ООП это структурирование уже выполнено.
И все ваши дальнейшие примеры идут по тому же пути. Вы демонстрируете детали, которые мне просто не нужны в момент решения задачи, поскольку они уже есть и скрыты от меня таким образом, что я могу действительно не задумываться о них. Просто создаю объект, жму точку, IDE показывает список методов, выбираю нужный, и всё - задача решена.
Аналогично, встроенные в RPL средства содержат в себе какую-то логику, которую в них заложили их создатели. Но в тех дополнительных библиотеках, которые вы объявили ненужными, вся эта логика тоже есть, а плюсом к ней идут всяческие дополнения, позволяющие написать запрос, в том числе существенно сложнее показанных ранее, в одну строчку. Вам же приходится бегать по курсору, по сути переходя на уровень обработчика запросов в СУБД. И это всё вы делаете ради экономии на разборе SQL. Но эта экономия ничтожна. В показанном мною первом примере результирующий запрос мог бы выглядеть так: select * from table_name where id=?, или даже так: select id from table_name where id=?, если бы я явно указал список полей. Всё это самые тривиальные запросы, которые планировщик СУБД прекрасно умеет переводить в примерно тот код, который вы написали на RPL. То есть эффективность выполнения запроса будет ровно такая же, как у вас, кроме одного - разбора SQL-выражения. Но такое тривиальное выражение разбирается за микросекунды. Если вы сравните микросекунды со временем загрузки нужной части индекса с диска при поиске, вы поймёте, что экономить эту мелочь просто бессмысленно.
поиск совпадений между адресами клиентов (порядка сотни миллионов адресов) и адресами субъектов списков росфинмониторинга
И это всё тоже эффективно решается на SQL. Если у вас кто-то сумел сделать такое решение неэффективным (выполняется часы), это не значит, что эффективно сделать нельзя. Здесь просто нужно понимать суть алгоритма и то, как работает СУБД. Всё, далее я на SQL дам вам ваши же 15 минут, или даже быстрее. И собственно разбор SQL в СУБД займёт ну пусть даже несколько сот миллисекунд (хотя скорее десятков), но что это в сравнении с 15-ю минутами? И что важно - я это сделаю хоть на IBM i, хоть на любой другой платформе, где есть SQL.
На этом примере очень наглядно становится понятно, почему узкая заточенность на низкоуровневых подходах может вас тормозить. Вы привыкли выжимать всё возможное, но это влечёт за собой переход на низкоуровневые языки, со всей их сложностью, а я же, представляя, как данные обрабатываются на низком уровне, просто укладываю эту обработку в SQL, который и пишется быстрее и ошибок в котором бывает намного меньше.
Хотя стоит признать, что без понимания того, что происходит на низком уровне, действительно можно писать очень неэффективные запросы. Но я всё же ожидаю, что мы обсуждаем тему работы квалифицированного программиста, а не чучела с парой классов образования, но взявшегося писать программы.
Один момент. Здесь нет "подключения к БД". БД - это часть системы. Мы уже "внутри БД"
Вот, вот. Вы опять уходите на уровень деталей реализации, которые в данный момент совсем несущественны. Хотя в реальности, разумеется, существует набор изолированных от вас процессов, выполняющих роль СУБД, и к этим процессам происходит подключение средствами ОС, но вы этого не видите, поскольку подключение скрыто в недрах RPL. Но не суть, главное - вы привыкли видеть низкоуровневые вещи и не можете от них абстрагироваться. Поэтому пишете на RPL там, где вполне можно писать на SQL и быстрее и с меньшим количеством ошибок.
Вот сколько таблиц там у вас? У нас - десятки тысяч объектов (таблиц и индексов). И на все прописывать классы? Извините, но зачем, когда можно работать без этого? Если можно просто прочитать запись как статически описанную структуру и дальше просто работать с ее полями как с обычными переменными?
Ну опять же вы не понимаете, как работают современные средства отображения данных на структуры. Классы - это и есть статическое описание структур данных. То есть те статические структуры, которые вы далее и предлагаете использовать. Единожды описав структуру каждой таблицы, мы получаем, пусть по сотне-двум байт на таблицу, мегабайт-два структур. Сравните это с террабайтами памяти на вашей системе. И посчитайте - какую часть памяти вы сэкономите, если откажетесь от пары мегабайт структур. Мне кажется вывод очевиден.
А теперь представьте, что у вас в распоряжении язык, где все эти типы уже есть
Мне не надо это представлять, сегодня практически в любом языке все типы есть. Другое дело, что они объектные, то есть оборачивают ту же дату в форме long внутрь класса, который уже умеет выдавать вам месяц, год, число и т.д. Да, за счёт расхода памяти на оборачивание мы получаем некоторые издержки, но это же копейки в сравнении с наличными ресурсами. Плюс встроенные средства RPL точно так же обязаны содержать какие-то обёртки над структурой данных, которая в DB2 содержит данные о дате. Так что опять получается никакой существенной выгоды вы от использования RPL не получаете.
То же относится и к формам, упомянутым вами. Вы показали некий формат, который RPL умеет преобразовывать в поля на экране. Но я вам напомню, что в мире есть тысячи подобных форматов. Самый известный - html. И сравните гибкость, предоставляемую разработчику пользовательского интерфейса в современных браузерах с псевдографическими экранами, которые получаются в вашем случае. Пример про модальность именно в сторону этой гибкости и отсылал.
И затраты на написание кода (в части работы с БД и бизнес-логики) на RPG, который специально для этого предназначен, ничуть не выше чем на другом языке с кучей зависимостей, компенсирующих то, чего там нет. Но результат лучше
А здесь я могу сказать одно - вы не пробовали писать по другому. Попробуйте. Вам понравится.
Вопрос автору-знатоку по кондиционерам. Сплит-системы неудобны необходимостью сверлить стены и устанавливать вентилятор с помощью альпинистов. Поэтому тепло можно было бы стравливать другими способами, например - отводить водой. Отпала бы нужда во внешнем неудобном и трудносъёмном блоке, а так же в дорогостоящих работах.
При охлаждении водой можно подключиться по той же схеме, что и для стиральной машины. Единственное ограничение - воды должно потребляться меньше по стоимости, чем электричества в сплит-системе. То есть стоимость эксплуатации должна быть близкой к сплит-системе. При отсутствии затрат на сверление и установку суммарно получится выгода, плюс добавится мобильность для тех, кто, например, снимает квартиру. В этом случае можно допустить повышенную стоимость эксплуатации в сравнении со сплит-системой.
Я грубо прикидывал, но всё упирается в знание конкретных параметров фреонов и различных коэффициентов на потери, которые я с достаточной степенью тщательности не изучал. Где-то плюс-минус баланс энергии находится рядом со сплит-системой, но неизвестные параметры всё портят. Может автор знает коэффициенты? Или кто-то уже давно такую схему обсчитал и понял - бесперспективно (но здесь хотелось бы расчёты).
Наука всего лишь показывает путь, а пойти по нему должны сами люди. То есть когда и вы, и много других людей, откажутся от идеологии эгоизма, и не на словах, а на деле объединят свои усилия - вот тогда все проблемы, которые в нынешнем обществе считаются неразрешимыми, внезапно станут вполне доступными для решения.
Если спрашивают про спринг, значит хотят, что бы джун пришёл и сразу начал давать результат именно на спринге. Видимо поэтому и отказали, ведь по спрингу много гораздо более подготовленных.
Оценки базовых навыков так же субъективные, как со стороны кандидата, так и со стороны спрашивавшего. Поэтому не стоит воспринимать их как-то близко к сердцу.
База, на самом-то деле, вычисляется просто - вот ситуация, вот ограничения, как сделать так, что бы всё стало работать в десять раз быстрее? Здесь сразу видно, понимает человек, как оно внутри работает, или только заучил базовые конструкции, которые не помогут писать оптимальные по ресурсам программы. Ну а если такая база есть, то и как внутри устроена JVM, и многое другое человек будет понимать достаточно хорошо, что бы в большинстве мест сказали, что база нормальная.
Но сами интервьюеры далеко не без греха - если они считают какую-нибудь мелочь очень важной, то всё, если вы её не знаете - отказ. На самом же деле это исключительно их личное и никому более не интересное мнение. Но корпоратив устроен так, что никаких вменяемых подходов к проведению эффективных интервью никто делать не будет. Один раз в толстых конторах типа гугла сочинили набор скриптов для собеса, и всё, далее только этот подход. А в конторах попроще вообще ничего не сочиняют, поэтому и пользуются инициативой интервьюирующие. Плюс очень часто подбирают под себя по субъективной психологической совместимости. То есть - всё та же случайность. Даже если вы перед этим очень серьёзные программы писали. Субъективная оценка вас срежет только за то, что вы не подошли по каким-то частным, или вообще личным критериям интервьюера.
Но это всё не отменяет необходимости наращивать базу в глубину. Так что вашему знакомому явно есть куда расти. Как минимум - сам он не дошёл до простейшей мысли - все эти спринги есть производная от именно базовых знаний, обладая которыми, он никогда бы не мешал в одну кучу спринг со всем остальным. Это как смешивать физику с математикой. Без математики ничего не посчитаешь. Но физики должны знать именно предметную область, то есть законы природы. Ваш знакомый же месит в куче квадратные уравнения с законом всемирного тяготения, хотя ещё в школе дети узнают, что это разные дисциплины. Так и в программировании.
Спасибо, стало понятнее, что читателю необходимо хорошо помнить детали работы с КТО, которые есть в той же википедии по вашей ссылке, но для понимания текста они заранее должны быть в голове, либо их нужно туда положить, перейдя в википедию во время чтения и усвоив там с пару страниц формул, а потом уже снова переключиться на статью.
Но вы бы сэкономили читателю это время, указав промежуточные шаги вычисления, благо они довольно простые, хотя и занимают место. Ссылка на документ в dropbox предполагает именно отсутствие экономии времени, точнее даже гораздо большие затраты на дополнительную информацию.
Хотя возможность ответа в комментариях, в общем-то, проблему нивелирует.
Ну и до кучи, просто добавив в ваш комментарий указание "как видно из примера, перебирая точки, получаем на одно умножение полином первой степени, на три - третьей, на шесть - шестой, то есть степень полинома (или разрядность числа) растёт пропорционально количеству умножений, а не его квадрату" ваши затраты выросли бы очень незначительно, но ясность изложения была бы заметно улучшена.
Хотя я понимаю, что краткость изложения в привычном математикам стиле требует ещё большего сокращения объёма статьи. Но вы же пишете на популярном ресурсе, что предполагает несколько другую аудиторию.
БПФ получилось без китайской теоремы об остатках. И вывод быстрого умножения так же возможен без её привлечения. Хотя, возможно, вам известен вывод БПФ через упомянутую теорему?
И про увеличение длины на каждом шаге не понял. При одном умножении степень многочлена увеличивается на единицу. Какая длина при этом увеличивается вдвое?
Описание использования китайской теоремы в статье так же не дошло до моего мозга. Pn = P mod (многочлен) - здесь два неизвестных, Pn и P, многочлен известен, но получение Pn и P непонятно.
Более того, вы далее описываете способ подбора точек так, что бы они образовали мультипликативную группу. Затем эту группу вы находите в преобразовании Фурье. После чего переходите к рассуждениям о совпадении с Фурье лишь при конкретных значениях. Где здесь связь с шагами, которые дают нам степени двойки на каждом из них?
А китайская теорема всего лишь указывает нам на произведение модулей. Но вот свойства мультипликативной группы как раз и позволяют нам комбинировать и заменять отдельные составляющие в квадратичном по сложности алгоритме, сводя их к линейной сложности с логарифмом за счёт рекурсивного использования.
Может стоит добавить подробностей в статью?
Преобразование Фурье, как и другие преобразования (Хартли и т.д.), используют свойства суммы ряда циклической группы, в частности с домножением на коэффициенты. Выгода от использования подобных преобразований появляется именно из-за свойств используемой группы.
Другое дело, как показать эту выгоду без привлечения подобных преобразований. Сейчас быстрое умножение выглядит как некая магия, считаем по каким-то формулам, и почему-то получается быстрее. Почему? Потому что так получается по формулам. А почему так получается по формулам?
Поэтому математику ещё ждёт открытие свойств циклических групп, более наглядно объясняющих, что же там за занавеской из формул на самом-то деле происходит.
На случай. Всё остальное - не работает. Удачно столкнётесь с правильной конторой/человеком - вам повезло.
У нас Java-джунов ищут годами. Требования минимальные, по сути базовое знание языка, плюс что-то из SQL, ну и хоть какая-то сообразительность. За полтора года нашли одного. Вакансий много. Почему так?
Как и почти везде - в корпоративе очень низка эффективность внутренних процессов. Найм - не исключение. В других местах не лучше. Хотя те, кто вакансии передаёт кадровикам, считают, что рынок пустой, плохой, холодный и т.д. А то, что система в целом неэффективна - никто никогда не скажет, ведь это и их самих в неприятное положение поставит.
Так что надежды джунов могут быть только на массовую рассылку и случай. А до наступления случая - качайте хард-скиллы, их реально нет у многих постучавшихся.
Не учитывая ряд спорных моментов текста, впечатлён как точно автор описал местных комментаторов в образе себя в юности. И вот такое задаёт тон на этом ресурсе.
Авторам урок, стоит или нет увлекать местных высоким (кроме наивысших удовольствий, разумеется).
Вы думаете, западный софт не ориентирован на прибыль? или вы думаете, на западе не было периодов, когда в том или ином направлении складывалась ситуация, аналогичная нашему импортозамещению?
Другое дело, у нас на рост "отечественных" решений направляют деньги, изъятые у населения, а на западе деньги добровольно несут так называемые "инвесторы". Хотя последние тоже косвенным образом изымают деньги у населения, но разница всё же есть.
Большие конторы это делают сами, ну а остальные в большинстве просто не понимают, что им на самом деле нужно. Хотя большие тоже не понимают, но удовлетворяются хотя бы фактом самостоятельного творчества, за которое винить посторонних не очень логично. Зато свои собственные решения для инфраструктуры даже толстые конторы не хотят взваливать себе на плечи. Привыкли, что осей на свете ровно две, и пилят их всегда другие. Запилить свою? Да вы что, это же не наши компетенции! А пилить микросервисы подразделениями в несколько тысяч человек - ну до чего же "своя" компетенция.
Глобально рулят денежные знаки. Ими "управляют" наёмные рулевые. А у них подход простой - деньги направляем туда, где светит максимум прибыли. Это может быть абсолютно любое направление. И разумеется, ни в одном из них компетенций у рулящих деньгами нет, слишком много направлений для столь уважаемых людей. Но есть выход - компетенции покупаются и продаются. Правда оценить качество покупки рулевые опять же не в состоянии, но пока у конкурентов дела идут точно так же - о чём беспокоиться?
Единственное, что удивляет, почему в мире ещё так много людей, которые ждут от такой системы качества? Ведь каждый же считает себя умным, разве нет? Но почему-то ждут чудес, которых, как давно известно, на свете не бывает.
Что насчёт оптимальности предложенных для примера алгоритмов?
Доказать применимость можно для любого алгоритма, но эффективно решать задачу это не позволит. Для эффективности требуется нечто большее. Есть это нечто в описываемой структуре?
В примерах видим два этапа - построение структуры из статьи, а затем использование структуры в дополнительном алгоритме. Есть аналогичное по применимости множество индексных структур, позволяющих делать то же самое, но с доказанной оптимальностью (вычислено О большое и показано, что оно лучше других). Чем индексы хуже предложенной структуры? Точнее - собственно индексирование должно быть менее затратным в случае, если структура из статьи действительно полезна. Хотя возможно уменьшение затрат второго этапа при худших показателях первого. Но эти вопросы автор не осветил. А стоит подумать.
Это не стиль управления. Это один из способов мотивировать сотрудников. Управлять и мотивировать - очень разные вещи, видимо ортогональные.
Собственно управление, как и везде, осуществляют выборные начальники.
На сколько этих начальников легко сдвинуть с должности - большой вопрос. Весьма вероятно, что они меняются редко, то есть для остальных попытка их пододвинуть фактически бесперспективна. Тогда это самый обычный бизнес, но с хитрой системой мотивации, про которую не сразу ясно, кто кого имеет. В сравнении с "добейся отличных результатов и тебя повысят" это шаг вперёд для собственника. Но для общества это скорее печально - собственник нашёл очередной способ скрыть суть эксплуатации.
Хотя в тексте есть что-то про плоское распределение доходов. Возможно, вся мотивация в основе полностью эквивалентна привычной сдельной оплате, но вот этаким образом занимательно оформленной.
Либо готовая система, либо исключительно личный интерес. Если есть готовый кооператив, то они уже знают, что им надо, это и есть ваш рынок. А если нет - вам остаётся искать личный интерес конкретных жильцов. Скорее всего бизнес на "пустом месте", то есть без готовой кооперации жильцов, в итоге провалится. Затраты большие - личный подход к каждому жильцу. Не потянете.
Хотя может найдёте какое-то мотивирующее некую нишевую группу жильцов дело, и предложите в этом деле облегчение. Но суть всё равно та же - личная мотивация, только с поправкой на некоторую массовость в рамках ниши.
Так что переориентируйтесь на готовое.
Общая проблема наивного подхода к сжатию данных состоит в отвлечении внимания от сопутствующих действий. Таковыми являются, например, вычисления, производимые над сжимаемыми и разжимаемыми данными. Если же обратить внимание на вычисления, то мы заметим небольшую проблему - для сжатия произвольного файла нам потребуется что-то вроде вычислительной мощности, какой нет во всей вселенной.
Но само по себе сжатие на порядки произвольного (и при этом достаточно длинного) файла вполне возможно.
Идея такого сжатия тривиальна - сопоставим выбранному файлу число 1. Ну вот - мы сжали выбранный файл до одного бита. Кто-то будет спорить?
Но есть здесь та самая проблема. Для сжатия второго файла потребуется сопоставить ему другое число, например 2. Для третьего - 3, ну и так далее. Только произвольных файлов , длиной N бит, может быть два в степени N. Значит нам придётся каким-то из них сопоставлять значения из N бит, то есть сжатие куда-то потеряется.
На этом простом примере мы поняли, что сжать все произвольные файлы мы не можем. Но это не значит, что мы не можем сопоставить одному из этих файлов число 1. То есть если мы забудем про общий подход (сжатие всех файлов), то очень большой коэффициент сжатия становится вполне возможным. Да, математики своим генеральным методом несколько обеднили возможные математические же результаты.
Кто-то когда-то предлагал сжатие на основе числа пи. Там всё просто - вбрасываем в игру бесконечные вычислительные мощности и затем играючи находим адрес в бесконечной последовательности знаков числа пи, начиная с которого наш сжимаемый файл в точности повторяется в числе пи. Берём этот адрес и длину файла - вуаля, мы сжали файл до некого меньшего числа. Но возможен нюанс, нет гарантий, что адрес файла в числе пи не окажется по размеру больше самого файла. Опять проблема.
Автор уже столкнулся с подобной нестыковкой, когда понял, что сжатие его способом получается лишь при больших размерах файлов. А при малых получается лишь увеличение размера. То же самое характерно и для числа пи, как и для любой другой достаточно длинной псевдослучайной последовательности.
Собственно вывод:
Да, сжатие на много порядков вполне возможно. Но для этого получатель должен уже обладать оригинальным файлом, то есть без сжатия, хотя и в зашифрованном виде (число пи, например). Далее мы передаём получателю номер файла и он "разжимает" файл в гигабайты из нескольких бит. Вычислительные сложности, разумеется, в полном соответствии с привычкой математиков решать проблемы в общем виде, мы оставляем прикладникам. Альтернатива - способ создания хранилища всех файлов в несжатом виде (дабы "сжимать" их указанием номера) мы тоже оставляем чумазым механикам, ведь наше дело стратегия, правильно?
Автору (и ему подобным) стоит конкретнее определиться, чего они хотят. Моё предположение - хотят денег. Тогда всё написанное автором вообще никак не соответствует заданной цели.
Деньги - это локальная оптимизация. Надо быстрее и при минимуме усилий. Магистратура - это практически максимум из доступного набора усилий. На лицо очевидное проитиворечие.
Поэтому всем желающим денег рецепт такой:
Рассылайте много резюме.
Демонстрируйте "сообразительность" (расплывчатое понятие, сильно пересекающееся с софт-скиллами).
Вызубрите прикладную часть. Здесь очень желательно понимание. Но можно проскочить на невозможности задать вам все возможные вопросы.
Если зубрёжка успешна, но на собеседованиях вас посылают, значит они находят вопросы "на понимание". Тогда ваша задача всё же приобрести это самое "понимание".
Понимание, в применении к начинающим, требуется неглубокое, но всё же достаточно приличное. Поэтому здесь можно посмотреть на какие-то курсы, или даже ролики/тексты.
Курсы предлагают упражнения - это рецепт для понимания. Ролики может и предлагают, но никто их упражнения не делает. Поэтому заплатите денег, что бы ваша жаба заставляла вас выполнять упражнения. Хотя курсы могут не требовать их выполнения, тогда это аналог бесплатного ролика и такие курсы должны идти лесом.
Переходите к пункту 1, и так в цикле, пока вас куда-то не возьмут.
Науковед рассказывает о "науке" в замкнутом идеальном пространстве, лишённом реалистичности.
Главная проблема науки (как и всего общества) - кто ею правит. Но науковедам про это говорить запрещено. То же самое относится и к низким человеческим качествам управленцев среднего звена в научной деятельности. В итоге вместо науки имеем имитацию. Но науковедению про это ничего неизвестно.
Зато много разговоров о бессмысленном:
То есть о следствии безумства управленцев. Повторюсь - не о причине (о самом безумстве), а видите ли, о не вполне удовлетворительном использовании какого-то там очередного умного слова, для которого в научных кругах находят как плюсы (это как?!), так минусы.
Вот так, обтекаемо и ни о чём, исследуют науку настоящие учёные. Так каких же достижений ждать от таких исследований?
Любая сущность, использующая сервис, является его клиентом. При этом user всегда переводится как "пользователь", то есть сразу исключается все классы программных сущностей.
Вы сами пишете, что на западе к ним серьёзно не относятся. Кроме того, стоит указать на абсолютно произвольный характер используемых в IT терминов. То есть любое слово, которое понравится лицу, приближённому к бюрократическим глубинам, формирующим мировые стандарты, просто записывается в стандарт как данность. И никого (из бюрократов) не волнуют сложности у пользователей новых стандартов.
Кроме того, я не думаю, что западный мир вообще хоть на миллиграмм заинтересует, как там русские перевели ихние слова для своего внутреннего использования. А вот у нас уже вы можете выходить на массовую аудиторию, учитывая недостатки западного бюрократического подхода. Это означает необходимость глубоко продумывать не только архитектуру, но и терминологию. В конце концов - для чего вы это делаете? Если только для прибавки единички к количеству публикаций, тогда да, можно писать всё, что угодно. Но если вы ожидаете хоть немного большего, то стоит уже думать о восприятии вашего продукта другими людьми, а это опять возвращает нас к терминологии.
По сути возражений о гомогенности/гетерогенности и уровнях:
Если отойти от фиксации на западных названиях, то вы полностью вольны выбирать свои. Принимаю негативные моменты в использовании гомогенности и уровней, но тогда считаю правильным вообще уйти от единичных терминов в сторону более сложных словосочетаний. Например - логическая структура сети из гомогенных сегментов, независимая от физической реализации, поясняя далее, что каждый сегмент состоит из узлов, включающих сервисы, обеспечивающие удалённое взаимодействие клиентских сущностей. Если коротко, то получим - логически гомогенная сеть, но слово "логически", без сомнений, чаще всего будут опускать из-за стремления людей к упрощению.
Можно ещё предложить что-то вроде - сеть независящих от реализации сегментов с единообразной логической структурой. И не стоит бояться количества слов, ведь всегда можно перейти к, например, аббревиатурам, или, ссылаясь на полное название, предлагать краткие.
Очень редко вижу в этом мире приличную архитектуру. Вызывающую приятные чувства - не видел уже лет 15. Предложения автора на этом фоне является очень редким исключением.
Предложу скорректировать терминологию (архитектуру не надо, она достойная).
user_service на самом деле должен быть client_service. Потому что пользователь и клиент - две очень сильно разные сущности. Слово user обязательно будет вводить в заблуждение и запутывать новичков, потому что ассоциируется с людьми, к тому же, часто малограмотными и по части устройства сетей тоже.
Слово "рекурсивные" в словосочетании "рекурсивные сети" нужно заменить на "гомогенные многоуровневые". Гомогенность есть одинаковость принципиального устройства уровней. Ну а уровней может быть много.
Отличие рекурсии от многоуровневости:
Рекурсия определяется обрабатываемыми данными, а количество уровней определяется конфигурацией сети. Конфигурация есть метаданные, которые нельзя путать с обычными данными. Пример - рекурсивно обходим граф, при этом количество уровней вложенности обработки определяется графом (данными). В случае сети метаданные меняются редко (новые слои не так часто добавляются) и не являются непосредственной целью процессов, обеспечивающих работу сети (непосредственная цель - передаваемые данные).
Желаю автор успехов, сожалею о минусах за статью, аудитория ждёт развлечений, а не глубину понимания.
Вот это довольно показательный момент. Он суммирует наш разговор. Вместо быстрого решения задач вам приходится думать о быстрой работе компьютера. Про стоимость работы программиста я вам писал, но раз вам "предъявляют" за минимальные попытки ускорить написание программ, то здесь я уже не могу помочь. Выбор в сторону оптимизации скорости исполнения сделан не вами, но вы его полностью приняли и отказываетесь воспринимать альтернативы. 10% по вашему очень много. Ну ладно, я вам писал про в 15 раз дороже в случае сравнения стоимости компьютера и труда. Это тоже вас не заинтересовало. Но чем тогда вас убеждать?
Вот совсем коротко:
Труд дороже железа. Доказать пытался, но не вышло.
Бой за 10% ускорения стоит в разы дороже, чем решение той же задачи без ускорения на 10%. Опять пытался доказать, но не получилось.
Что ещё сказать? Я не знаю.
Оттуда же, откуда знаю, как решать квадратное уравнение. В математике такие вещи доказывают. В программировании это все по разному называют, я бы назвал - качественное проектирование.
Я не говорил, что стандартный инструмент во всех случаях лучше. Я говорил, что он во многих случаях (в большинстве случаев) экономит усилия программиста при достаточно эффективном результате. Достаточно эффективный, это такой, когда нет смысла экономить миллисекунды при времени исполнения минуты.
Эта структура - класс. С накладными расходами в виде конструктора и чего-то ещё. Теперь математика: время чтения с диска, пусть будет SSD, положим 1 миллисекунда, затем преобразование в нужную нам структуру. За миллисекунду пусть прочитали 100 килобайт по сто байт структур (это пиковая, редко в реальности достижимая скорость выборки строго нужных данных). То есть всего 1000 структур. Время выполнения конструктора и прочего для каждой структуры - пусть 100 наносекунд, хотя всё это в кэшах и в цикле, так что процессор много чего может оптимизировать. Итого имеем 100 микросекунд на всё. Всего имеем примерно 10% затрат на конструкторы и 90% на чтение. Далее напишите всю обработку вручную, вместо одной строчки, как я показывал. Сравните свои затраты с моими. Получите в 100 раз больше, чем у меня. Вспомните про стоимость программистов.
Есть всего лишь эффективные и неэффективные решения. Разница определяется расчётом. Это просто математика. Её вполне способен считать компьютер.
Всё это шаблон. Шаблон такой: отображение, фильтрация, вычисление, запись данных. План запроса в каждом случае я вам вычислять не буду, это трудоёмко, но единожды написав программу вычисления подобных планов запроса, я автоматизирую все ваши ситуации. Хотя заранее признаю, что план запроса может быть по каким-то критериям неоптимальный. Так что вы, в каких-то случаях, сможете опередить мой планировщик. Но в некоторых случаях даже вы не сможете его победить.
А теперь вспомните, сколько времени вы потратили на решение этих задач. Сравните с программистом, который пользуется оптимизатором, работающим за него. Ну и снова вспомните стоимость труда программиста.
Ну вы ожидаете от меня откровенно тупых решений. То есть я увольняю всех умных и оставляю только тупых. Вы действительно думаете, что я умею только вот так работать?
Язык позволяет формулировать новые команды. Таким способом я получаю максимально удобное представление операций. А что там внутри новой команды, в момент использования библиотеки я понимаю, но чаще всего могу просто не думать об этом, потому что знаю, что преобразование в SQL будет достаточно эффективным. Хотя конкретно вам могу объяснить - вы видите, как происходит сбор данных для подготовки SQL, а внутри, уже в момент выполнения запроса, из собранных данных формируется корректный SQL, достаточно эффективный, то есть если нужно получить запись по id, то будет такой результат: select * from table_name where id=?, ну а потом, после получения результата, запись будет скопирована в соответствующую структуру, которая задаётся классом. Итогом будет объект, содержащий данные из запрошенной записи.
Здесь вы уходите в область вашего представления о разработке. Я вам только замечу - ваше представление не является единственно верным. То есть другие представления могут быть эффективнее. Но что бы доказать это я буду вынужден растягивать эту беседу на очень долгий срок, чего мне не хочется делать. Скажу только коротко, что большая часть задач в теме OLTP (а именно эта часть актуальна и для банка и для кучи других организаций) автоматизируема до уровня "программист вообще не нужен". И без всякого модного ИИ. Другое дело, к счастью для многих программистов, со стороны бизнеса нет достаточного понимания самого себя, что бы эффективно пользоваться такими инструментами. А достигается полезный результат (при условии соответствующего по уровню развития бизнеса) именно переходом на высокие уровни абстракции, которые в RPL вы застрелитесь формулировать.
Вот, вот. Условия-то свои, а всё остальное - полностью идентично. Подставляй значения в шаблон и получай радость.
Найдём. На то и созданы абстракции. Их суть в том, что бы эти общие места находить.
Здесь вы просто не поняли, о чём речь. Классы - это структуры, которые да, формируются при компиляции. И потом наполняются данными во время выполнения программы. Об этом я и говорил.
Да, можно переусложнить, можно замедлить, можно вообще всё испортить. Но это не значит, что нельзя сделать эффективно. Хотя соглашусь, что эффективно сделать не просто, от того и появляются все перечисленные косяки.
Не так. Вы указываете на стандартную ошибку - оптимизацию по простейшему критерию. Вы выбрали критерий - стоимость железа. Допустим ваш сервер стоит миллион долларов. И на него пишут программы суммарно 100 человек (для разных частей АБС). Допустим у них скромная з/п, со всеми накладными (налоги, офис, страховки и т.д.) путь на человека будет 250 т.р. Итого имеем 25 миллионов рублей в месяц, или примерно 3 миллиона долларов в год. Если железо полностью заменяется раз в 5 лет, то расходы на людей в 15 раза больше его стоимости. То есть если сократить затраты труда программистов на 1/15, получим выигрыш в размере стоимости железа. За 5 лет при выделении миллиона долларов на сокращение затрат труда программистов абсолютно реально не то что на 1/15, а весьма вероятно на десятки процентов сократить потребность. Вот вам и пример - вы выбрали ошибочный критерий оптимизации, то есть если бы выбрали критерий "стоимость работы программистов", то получили бы в разы большую экономию.
Одну строчку, примерно как вы её видите. Я немного сократил и переименовал части для большей понятности, а в остальном - именно так и выглядит.
Здесь смысл такой - человечество придумало множество удобств, сокращающих затраты труда программиста. Но пока вы их не прочувствуете на личном опыте, вы не поверите. Надеюсь, что ООП вам знакомо, так вот на его примере мы видим объединение логики со структурами данных, которое даёт нам то самое упрощение. Нам нет необходимости заглядывать внутрь объекта, ведь мы знаем, что всё нужное там уже есть (алгоритмы и данные), поэтому мы просто используем выставленный наружу функционал. Сравните с привычным вам подходом на си - отдельно данные и отдельно функции (алгоритмы). И вам приходится структурировать программу так, что бы ненужные данные не захламляли вашу текущую задачу. А в ООП это структурирование уже выполнено.
И все ваши дальнейшие примеры идут по тому же пути. Вы демонстрируете детали, которые мне просто не нужны в момент решения задачи, поскольку они уже есть и скрыты от меня таким образом, что я могу действительно не задумываться о них. Просто создаю объект, жму точку, IDE показывает список методов, выбираю нужный, и всё - задача решена.
Аналогично, встроенные в RPL средства содержат в себе какую-то логику, которую в них заложили их создатели. Но в тех дополнительных библиотеках, которые вы объявили ненужными, вся эта логика тоже есть, а плюсом к ней идут всяческие дополнения, позволяющие написать запрос, в том числе существенно сложнее показанных ранее, в одну строчку. Вам же приходится бегать по курсору, по сути переходя на уровень обработчика запросов в СУБД. И это всё вы делаете ради экономии на разборе SQL. Но эта экономия ничтожна. В показанном мною первом примере результирующий запрос мог бы выглядеть так: select * from table_name where id=?, или даже так: select id from table_name where id=?, если бы я явно указал список полей. Всё это самые тривиальные запросы, которые планировщик СУБД прекрасно умеет переводить в примерно тот код, который вы написали на RPL. То есть эффективность выполнения запроса будет ровно такая же, как у вас, кроме одного - разбора SQL-выражения. Но такое тривиальное выражение разбирается за микросекунды. Если вы сравните микросекунды со временем загрузки нужной части индекса с диска при поиске, вы поймёте, что экономить эту мелочь просто бессмысленно.
И это всё тоже эффективно решается на SQL. Если у вас кто-то сумел сделать такое решение неэффективным (выполняется часы), это не значит, что эффективно сделать нельзя. Здесь просто нужно понимать суть алгоритма и то, как работает СУБД. Всё, далее я на SQL дам вам ваши же 15 минут, или даже быстрее. И собственно разбор SQL в СУБД займёт ну пусть даже несколько сот миллисекунд (хотя скорее десятков), но что это в сравнении с 15-ю минутами? И что важно - я это сделаю хоть на IBM i, хоть на любой другой платформе, где есть SQL.
На этом примере очень наглядно становится понятно, почему узкая заточенность на низкоуровневых подходах может вас тормозить. Вы привыкли выжимать всё возможное, но это влечёт за собой переход на низкоуровневые языки, со всей их сложностью, а я же, представляя, как данные обрабатываются на низком уровне, просто укладываю эту обработку в SQL, который и пишется быстрее и ошибок в котором бывает намного меньше.
Хотя стоит признать, что без понимания того, что происходит на низком уровне, действительно можно писать очень неэффективные запросы. Но я всё же ожидаю, что мы обсуждаем тему работы квалифицированного программиста, а не чучела с парой классов образования, но взявшегося писать программы.
Вот, вот. Вы опять уходите на уровень деталей реализации, которые в данный момент совсем несущественны. Хотя в реальности, разумеется, существует набор изолированных от вас процессов, выполняющих роль СУБД, и к этим процессам происходит подключение средствами ОС, но вы этого не видите, поскольку подключение скрыто в недрах RPL. Но не суть, главное - вы привыкли видеть низкоуровневые вещи и не можете от них абстрагироваться. Поэтому пишете на RPL там, где вполне можно писать на SQL и быстрее и с меньшим количеством ошибок.
Ну опять же вы не понимаете, как работают современные средства отображения данных на структуры. Классы - это и есть статическое описание структур данных. То есть те статические структуры, которые вы далее и предлагаете использовать. Единожды описав структуру каждой таблицы, мы получаем, пусть по сотне-двум байт на таблицу, мегабайт-два структур. Сравните это с террабайтами памяти на вашей системе. И посчитайте - какую часть памяти вы сэкономите, если откажетесь от пары мегабайт структур. Мне кажется вывод очевиден.
Мне не надо это представлять, сегодня практически в любом языке все типы есть. Другое дело, что они объектные, то есть оборачивают ту же дату в форме long внутрь класса, который уже умеет выдавать вам месяц, год, число и т.д. Да, за счёт расхода памяти на оборачивание мы получаем некоторые издержки, но это же копейки в сравнении с наличными ресурсами. Плюс встроенные средства RPL точно так же обязаны содержать какие-то обёртки над структурой данных, которая в DB2 содержит данные о дате. Так что опять получается никакой существенной выгоды вы от использования RPL не получаете.
То же относится и к формам, упомянутым вами. Вы показали некий формат, который RPL умеет преобразовывать в поля на экране. Но я вам напомню, что в мире есть тысячи подобных форматов. Самый известный - html. И сравните гибкость, предоставляемую разработчику пользовательского интерфейса в современных браузерах с псевдографическими экранами, которые получаются в вашем случае. Пример про модальность именно в сторону этой гибкости и отсылал.
А здесь я могу сказать одно - вы не пробовали писать по другому. Попробуйте. Вам понравится.