Поддерживаю, мы же не медициной занимаемся, их термины не должны нас путать. Но слово "пациент" уж слишком намекает на медицину, лучше что-то более нейтральное. У нас же паттерны и объекты? Возьмем, например, меридиан - начало отчета, а тут это тоже как бы отправная точка в паттерне. Null все так же переведем как "нулевой" - итого предлагаю "нулевой меридиан", хороший запоминающийся термин. Если не нравится меридиан, ну можно взять, например, стакан - в него ж можно объекты складывать. Такой термин даже на финансовых биржах есть для совокупности позиций - похоже на хранилище, как и тут. А null переведем как "пустой" - итого будет "пустой стакан", тоже неплохо.
Реализация классов шаблоны проектирования также производится с использованием общего абстрактного класса проектирования Принципы объектно-ориентированного программирования, реализованного по паттерну 4.7. Нулевой пациент.
А что сейчас для веб-клипинга используете? Тоже ищу решение получше. Сейчас пробую связку из браузерного плагина для SingleFile, который подсмотрел среди экспортеров в Archivebox, и Obsidian-плагинов HTML Reader и Importer. Действий, конечно, получается больше, чем хотелось бы - "сохранить страницу", "перенести в папку", опционально "конвертнуть html -> md", зато надежно. Еще, если руки дойдут, попробую накрутить хуки на Archivebox и включить его экспорт в синхронизацию; мб даже закидывание на скачивание сделаю через watch папки обсидиана как альтернативу браузерному плагину
Вообще интересная тема, редко с таким сталкиваешься - вот нагуглилась работа, где авторы утверждают, что разработали алгоритм внешней сортировки с O(n log n) по времени, константной RAM-памятью и, похоже, вообще без дополнительного места на диске: надо будет потом попристальнее изучить.
Я тоже засомневался, поэтому полез проверить: можно O(n log n) с константной памятью, просто придется пожертвовать устойчивостью и, возможно, лучшим временем, но, кажется, здесь ни первое не пригодится, ни на втором все равно не выиграть.
Ммм а почему вы игнорируете последнее решение из статьи с двумя указателями? В нем данные предварительно отсортированы по пользователю и странице, поэтому для устранения дубликатов в ответе достаточно при обходе каждого из двух списков пропускать идущие подряд одинаковые записи, а при перекрестном поиске не нужно искать по всему второму файлу, а достаточно просто двигать второй указатель, пока не найдется элемент с userID равным искомому или больше. Сложность получается O(n log n) на предварительную сортировку и всего лишь O(n) на обработку, т.к. каждый из двух списков обходится однократно; итоговая будет O(n log n + n) = O(n log n) при константной памяти.
Какие IO операции? Какие другие машины? Опять что-то выдумываете. Это может быть обход генератора или чтение канала данных в том же процессе, просто другим модулем. Вы сами придумали это ограничение, что список должен быть передан полностью законченным, и теперь пытаетесь всех убедить, что автор сам себя не понял и вообще профнепригоден. С точки зрения ABI задача вообще не описана, поэтому отвечать на рассуждения о компиляторах и теории типов не стану. Мне кажется вполне реальной ситуация, когда я реализовал этот механизм, собирающий полный список, а в памяти не помещается даже готовый список-ответ, поэтому пришлось, например, потратиться на вертикальное масштабирование. Затем приходит заказчик этой ерунды и спрашивает, почему так долго и дорого, и нельзя ли по частям, мол, ему так было бы проще. А единственным оправданием будет "вы же сказали список, а я это понял так".
Хочу пару цитат из статьи привести:
В реальности инженеры постоянно сталкиваются с неоднозначностью, и корень большинства программных проблем можно найти в плохо определённых требованиях.
Наиболее грамотные кандидаты, прежде чем переходить к написанию кода, должны задавать уточняющие вопросы. Я рассчитываю увидеть в соискателях проявление рассудительности, так как в описанных условиях задачи присутствует двусмысленность.
С чего вы взяли, что есть какая-то запись на диск? Механизм может частью пайпа и по мере нахождения новых пользователей их сразу куда-то дальше переправлять, не дожидаясь конца обработки.
Что бы сделать например обобщённую функцию для sqlx нужно описать портянку из параметров шаблонов [...] Но ведь в Go например есть GORM, который без всяких шаблонов делает это.
И он это делает с помощью рефлексии в рантайме, когда шаблоны разворачиваются в куда более простой и прямолинейный код при компиляции. Разница в производительности просто гигантская. Впрочем, гошные дженерики реализованы не так, как многие надеялись: без полной мономорфизации, чтобы сохранить быструю компиляцию, так что в рантайме все же довольно много всего происходит.
А в реальных проектах с кучей библиотек будут огромные строки указания параметров шаблона.
Дженерики в go не полные по Тьюрингу, так что творить на них какую-то чудовищую магию, как это возможно, например, в плюсах, попросту не получится. Их введение прошло с очень длительными и обстоятельными обсуждениями, главный мотив в которых был "не переусложнить язык". На мой взгляд, получилось неплохо: все дженерики, которые я писал или видел, были очень простыми и всего лишь способствовали универсальности функций или контейнеров при сохранении типизации, так что область их применения невелика; никакого SFINAE тут нет, к счастью. К тому же, экосистема уже достаточно крупная и устоявшаяся, чтобы появление дженериков не перевернуло все с ног на голову. Собственно, такого и не происходит, хотя дженерикам уже полтора года.
Как же обходились без шаблонов в Go 13 лет?
Иногда с недовольством недостаточной выразительностью языка и необходимостью вручную писать одни и те же вещи из раза в раз вроде общих алгоритмов для массивов, которые теперь появились в пакете slices; кодогенерация как предлагаемая альтернатива не особо помогала. Собственные контейнеры всегда приходилось затачивать под конкретные типы, их толком не вынести было в библиотеки. Часто для обобщения приходилось уничтожать информацию о типе через пустой интерфейс, а потом ее восстанавливать через попытки приведения: уж лучше дженерики.
Раз теперь код в Go будет выглядеть как в Rust, то зачем продолжать использовать Go?
А зачем нужен был раст, если в нем есть такие же шаблоны, как в уже существующих плюсах? Языки все же отличаются не только синтаксисом, да и обобщение уж слишком натянутое. Go все так же будет иметь намного более низкий порог входа и простоту поддержки легаси, все так же будет управлять сбором мусора, все так же будет хорош легковесными горутинами и т.д.
Интерпретация ответов тоже важна: исследователь все-таки не машина, которая просто проверяет галочки в тесте, на составлении опросника умственная работа не заканчивается. Вопрос "выберите лишний предмет из списка [x, y, z, &]" без критерия объединения имеет смысл, т.к. оставляет подопытному возможность придумать несколько собственных вариантов с разными критериями и таки лучше продемонстрировать способности, хотя некоторым и будет сложнее с таким справиться, нежели с прямолинейным вопросом. Не все так просто. А конкретно описанный случай выглядит некорректно проведенным, т.к. подопытные явно зафиксировались на формулировке "лишний", а исследователь будто этого не заметил и продолжал настаивать, в итоге из-за этого тест "найди что-то общее ровно для 3 из 4 объектов" был воспринят как вызов "докажи, что лишнего нет и исследователь неправ, найдя применимость всех 4 объектов и связи между ними", с которым подопытные в итоге блестяще справились.
tl;dr «Низкая производительность» — это когда выполняется мало задач. Проблемы - это плохо. Что с этим делать - пока неизвестно, надо искать. Надо сделать так, чтобы было хорошо.
Проблема «Низкая ПИТ» — это, когда делается мало задач в интеллектуальной сфере в заданные сроки имеющимися ресурсами. Когда делается мало задач, то получаются скудные результаты Отсюда, проблема «Низкая ПИТ» — это, когда выполняется мало интеллектуальных задач. сделано маленькое количество работы в интеллектуальной сфере – это значит выполнено мало интеллектуальных задач Проблема «Низкая ПИТ» имеет негативный (отрицательный) характер «Низкая ПИТ» вызывает у нас недовольство (дискомфорт). Мы пока не знаем, что нужно сделать, чтобы преодолеть проблему «Низкая ПИТ». у нас есть лишь потребность в преодолении этой проблемы отсутствует понимание, на что воздействовать Пока мы не знаем, на что воздействовать. нужно искать причины появления проблемы «Низкой ПИТ» Надо так настроить её [системы] работу, чтобы все интеллектуальные задачи выполнялись своевременно, ритмично и воспроизводимо. проблема будет считаться преодолённой, если все интеллектуальные задачи в организации начнут выполняться воспроизводимо
Умножение двух чисел x и y имеет линейную сложность, так как требуется выполнить x умножений
Что, простите? Даже если вы имели в виду "умножение на N = N сложений", то это все равно далеко от реальности, иначе перемножение/деление больших чисел занимало бы вечность. Деление, кстати, более сложная для процессора операция, чем умножение.
У нас есть запись вида x = y % z , которая будет эквивалентна x = x - y * (x / y)
А у вас спина белая переменные перепутались.
Обратите внимание, что на практике сложность операции взятия остатка может быть оптимизирована в зависимости от аппаратной архитектуры и используемого компилятора
Так может быть, расскажете, как на практике, а не как у вас в голове на основе мат. модели уровня 5 класса? Ведь задан контекст: браузерный JS, а иначе в этой информации не просто нет смысла, а она еще и вредит, т.к. создает ложные представления.
Если злоумышленник уже захватил машину разработчика, как поможет подпись коммитов, отправленных с этой же машины? Или с любой другой, куда утянули сертификат. Сертификат уже скомпрометирован и точно так же надо сверять историю действий. Имхо единственный сценарий из ваших трех, который закрывает этот механизм, это третий: когда злоумышленник все так же находится уже внутри периметра, все так же смог получить учетку гитлаба, но не смог получить доступ к машине с сертификатом.
Есть отличная пара вопросов для самопроверки, сам пользуюсь и рекомендую: что вы знаете о качестве всеобщего голосования и откуда вы это знаете? Если вдруг механизм, лежащий в основе принятия глобальных решений, не справится со своей работой, то это серьезно повышает риск краха всей цивилизации. Ну и все-таки: кто вопросы будет составлять (пусть отложим очередность) и как минимизировать их влияние на процесс? Для соц. опросов, например, это очень важная тема, т.к. даже формулировки могут с ног на голову переворачивать результаты. Я уж не говорю о злоупотреблениях. В качестве ответа прошу не указывать ИИ, т.к. даже слабой формы ИИ пока еще не создано, а то, что сегодня маркетологами так называется, работает по принципам, похожим на аппроксимацию: "для похожих вопросов чаще всего давали примерно такие ответы, слепим что-то среднее". Плюс как-то надо учитывать хотя бы образование и контекст: какой смысл задавать вопрос о целесообразности апгрейда модуля БАК или МКС стереотипному дворнику из провинции и какова ценность его ответа по сравнению со специалистом в этой области? Мне вот будет бессмысленно задавать даже такой простой вопрос как "должен ли получать слесарь 1-го разряда больше, чем слесарь 2-го": я банально не в курсе, в какую сторону идет рост квалификации и является первый разряд лучшим или худшим.
Вы наверняка знаете, что во множестве игр есть донат: покупка игровых ценностей за реальные деньги. И тут часто смеются двое: один над тем, кто тратит огромные деньги на ерунду, а тот в свою очередь над первым, кто считает эти деньги огромными. У товаров помимо функциональной ценности есть еще как минимум две: эстетическая и статусная. Вот перед вами два браслета: они умеют одно и то же, но один выглядит истрепанным, грязным, угловатым и каких-то неприятных оттенков, на второй приятно просто взглянуть, но он стоит дороже. Вы всегда будете покупать первый? Со статусной чуть сложнее, тут высокая цена является качественной границей, а сам предмет может иметь меньшую значимость, чем сам факт обладания им: это важный в многослойном человеческом обществе сигнал "я выше вас по статусу, т.к. могу себе это позволить, а вы - нет".
Ежедневно по тысячам вопросов? Ок, поставим защиту: пусть только какой-то процент охвата будет. Голосуем: помимо прочих, 1млн шахтеров проголосовали, что шахтеры должны получать больше писателей. 1тысяча писателей прогосоловали, что писатели должны получать больше шахтеров. Выплаты писателям, видимо, снизились, часть писателей перешла в шахтеры. Новый цикл: 1млн+500 шахтеров и 500 писателей прогосовали. Ок, поставим защиту: за себя голосовать нельзя. Включаем в цепочку промежуточный узел: скажем, 10тыс поваров, которые сейчас получают больше писателей. 1млн+500 шахтеров проголосовало, что шахтеры должны получать больше поваров. Ок, поставим защиту...
Самое главное: прежде, чем спорить, неплохо бы договориться о терминах: что понимать под "конечной целью" и целью кого: заказчика, потребителя, программиста, мирового сообщества или кого-то еще. Цель - осознать, где и когда остановиться? Дойти до этой точки? А кто принимает решение? Или каким должен быть идеальный продукт в каждом конкретном случае? Разработка плана, как создавать идеальный продукт? Как перейти от зафиксированного продукта к процессу? Каким должен быть идеальный процесс разработки?
Конечная цель программирования - сам текст программы. Это настолько очевидно, что перестаёт восприниматься как конечная цель
Нередко оказывается, что пресловутая очевидность как раз мешает ясно взглянуть на что-то: мнение уже сформировано и не пересматривается.
Сначала по пирамидке: как у вас Business не оказался основанием? Уровень должен быть самодостаточным, т.е. иметь ценность без верхних, иначе это просто цепочка промежуточных этапов. Нельзя ведь начинать писать код, если не сформулированы хоть какие-то требования? Значит, ниже надо положить постановку задачи. Постановка задачи тоже в свою очередь чем-то будет заблокирована: например, бюджетом и подбором персонала, и так далее. А просто написанный, но неиспользуемый код сам по себе не имеет ценности, только потенциал.
Теперь по сути: имхо в вашей пирамидке не хватает настоящего основания: цели создания конкретной программы. Не универсальной цели, а конкретной для отдельно взятого случая. Посмотрим на примерах.
Для первого варианта положим в основу банальную практику. Хочу, скажем, IDE-шку получше изучить, библиотеку или язык. Для такого проекта у меня будет только Write в ваших терминах: мне даже критические ошибки в этом коде необязательно исправлять, это просто черновик. Никаких compile, run, bisuness, test, modify тут не будет. Да, write тут станет ценным уровнем, хотя выше я утверждал обратное, но только из-за специальной цели всего действа.
Возьмем прикладную утилитку личного пользования, а то и одноразовую. Ее уже надо собрать, запустить, но test, modify, business не будет. Возьмем инди-игрушку: тесты могут быть, могут нет, зато появляются производительность и бизнес. Построитель отчетов для внутренннего пользователя компании: тесты обязательны, это важная информация, зато производительность может быть выкинута, как и легкая модификация. Фреймворк: тесты, производительность, читаемость, документация, но может не быть business и легкой модификации. Ключевой сервис компании: тесты, легкая модификация, производительность. Открытое ПО - необходим выстроенный и поддерживаемый процесс коллективного принятия решений и внесения изменений; кстати, тут появляется "процесс" помимо продукта и исходника.
Возьмем любой программный компонент: при наличии доступного уже готового софта выкидываем (!) write, compile, даже run в случае стороннего сервиса. Можно утратить исходники и остаться с бережно отныне хранимым бинарником, который будет годами успешно работать, процеденты такие есть. А то и вовсе все сделают другим способом - механикой, электрикой вместо электроники или еще как-то. Задача решается без написания единой строчки кода, почти что идеал; круче только удалением.
Для специальных случаев добавим всякие интересные условия типа работы в масштабе миллиардов пользователей, в realtime, в жестких ограничениях по CPU/RAM/IO или обязательного использования особенностей конкретного железа, без которых все опять-таки не будет иметь никакого смысла.
Легко заметить, что ни один из ваших пунктов не оказался сразу во всех перечисленных сценариях - правда, занятно? Кстати, производительность и читаемость/поддерживаемость обычно являются взаимоисключающими, их вместе не запихнешь. Получается, что универсальной схемы развития идеального программного продукта попросту не существует, есть лишь цели на конкретные случаи со своими функциональными и нефункциональными требованиями к готовому продукту, исходникам и рабочим процессам. Как только все требования легли в основание, можно поверх что-то строить, но не линейное, а очевидно (хехе) многовекторное, больше похожее на розу ветров. А раз уникальное и многовекторное - значит, единой цели не может быть.
P.S. есть интересные эксперименты (например, Вселенная-25), косвенно связанные с пирамидой Маслоу, показывающие-таки наличие ее верхней границы.
Ну, фулстек - это все еще разработчик ПО, цельное понятие, и его обязанности мало отличаются от обязанностей более узких специалистов; а вот с аналитикой, контролем качества, менеджментом и т.д. уже скрестить сложнее. Вообще по ТК за совмещение должностей даже без увеличения рабочих часов полагается доплата, если, конечно, должность не прописана как "делать всё и вся" и работник на это согласился.
А теперь воплотим абстракции в реальность, но пойдем не идеальным, а ИМХО более вероятным путем. Раз инженеры получают право голоса, этот голос должен стать частью процесса, а не хватанием за руку в последний момент, следовательно, у инженера появляются новые обязанности, при этом навыки управленца+PO+архитектора в комплекте не идут. Добавим эффективное самоуправление на уровне команды - уже минимум три роли с тимлидом и получаем требования как минимум на ведущего специалиста. Опционально добавим девопс без системных администраторов, работу линией техподдержки, дежурства, прочие процессуальные события, так что в итоге на работу собственно исходным инженером остается один-два дня в неделю. Добавим плоскую структуру компании, так что эти требования автоматически применяются абсолютно ко всем инженерам. Разумеется, бизнесу очень выгодно, когда в проекте есть люди "и швец, и жнец, и на дуде игрец", да еще и инициативные, но где набрать столько универсальных пассионариев, что делать с остальными и можно ли все еще называть такую позицию просто инженером? Ну и пара очевидностей. Первая: если менеджер не интересуется мнением специалистов, допускает тупики, игнорирует смежные проекты, не имеет долгосрочных планов, то это некомпетентный менеджер. Вторая: стиль КД даже в тексте статьи очень часто соседствует со словом "стартап", а в стартапах так-то традиционный уклад с несколькими уровнями менеджеров встречается все же нечасто.
Инфляцию доллара, думается, еще надо учесть. Доллар в рублях стал дороже (курс вырос), при этом еще и его покупательная способность заметно упала: за 4 года набежало около 20%, так что долларов 4-летней давности в пересчете будет всего $1686 / 1.2 = $1405. Отрицательный рост, как нынче говорят.
Поддерживаю, мы же не медициной занимаемся, их термины не должны нас путать. Но слово "пациент" уж слишком намекает на медицину, лучше что-то более нейтральное. У нас же паттерны и объекты? Возьмем, например, меридиан - начало отчета, а тут это тоже как бы отправная точка в паттерне. Null все так же переведем как "нулевой" - итого предлагаю "нулевой меридиан", хороший запоминающийся термин. Если не нравится меридиан, ну можно взять, например, стакан - в него ж можно объекты складывать. Такой термин даже на финансовых биржах есть для совокупности позиций - похоже на хранилище, как и тут. А null переведем как "пустой" - итого будет "пустой стакан", тоже неплохо.
Словы вроде русски, но смысл идею ускользать.
А что сейчас для веб-клипинга используете? Тоже ищу решение получше. Сейчас пробую связку из браузерного плагина для SingleFile, который подсмотрел среди экспортеров в Archivebox, и Obsidian-плагинов HTML Reader и Importer. Действий, конечно, получается больше, чем хотелось бы - "сохранить страницу", "перенести в папку", опционально "конвертнуть html -> md", зато надежно. Еще, если руки дойдут, попробую накрутить хуки на Archivebox и включить его экспорт в синхронизацию; мб даже закидывание на скачивание сделаю через watch папки обсидиана как альтернативу браузерному плагину
Вообще интересная тема, редко с таким сталкиваешься - вот нагуглилась работа, где авторы утверждают, что разработали алгоритм внешней сортировки с O(n log n) по времени, константной RAM-памятью и, похоже, вообще без дополнительного места на диске: надо будет потом попристальнее изучить.
Я тоже засомневался, поэтому полез проверить: можно O(n log n) с константной памятью, просто придется пожертвовать устойчивостью и, возможно, лучшим временем, но, кажется, здесь ни первое не пригодится, ни на втором все равно не выиграть.
Ммм а почему вы игнорируете последнее решение из статьи с двумя указателями? В нем данные предварительно отсортированы по пользователю и странице, поэтому для устранения дубликатов в ответе достаточно при обходе каждого из двух списков пропускать идущие подряд одинаковые записи, а при перекрестном поиске не нужно искать по всему второму файлу, а достаточно просто двигать второй указатель, пока не найдется элемент с userID равным искомому или больше. Сложность получается O(n log n) на предварительную сортировку и всего лишь O(n) на обработку, т.к. каждый из двух списков обходится однократно; итоговая будет O(n log n + n) = O(n log n) при константной памяти.
Какие IO операции? Какие другие машины? Опять что-то выдумываете. Это может быть обход генератора или чтение канала данных в том же процессе, просто другим модулем. Вы сами придумали это ограничение, что список должен быть передан полностью законченным, и теперь пытаетесь всех убедить, что автор сам себя не понял и вообще профнепригоден.
С точки зрения ABI задача вообще не описана, поэтому отвечать на рассуждения о компиляторах и теории типов не стану.
Мне кажется вполне реальной ситуация, когда я реализовал этот механизм, собирающий полный список, а в памяти не помещается даже готовый список-ответ, поэтому пришлось, например, потратиться на вертикальное масштабирование. Затем приходит заказчик этой ерунды и спрашивает, почему так долго и дорого, и нельзя ли по частям, мол, ему так было бы проще. А единственным оправданием будет "вы же сказали список, а я это понял так".
Хочу пару цитат из статьи привести:
С чего вы взяли, что есть какая-то запись на диск? Механизм может частью пайпа и по мере нахождения новых пользователей их сразу куда-то дальше переправлять, не дожидаясь конца обработки.
Не разделяю опасения.
Читаемость можно ухудшить множеством способов. Как вам, например, описание цепочки функций высшего порядка?
func MyfuncA(param1, param2 string) (func (param3 string, param4 func (param5 *interface{}, param6 int64) func () int64) func (param5 *interface{}) int64, error)И он это делает с помощью рефлексии в рантайме, когда шаблоны разворачиваются в куда более простой и прямолинейный код при компиляции. Разница в производительности просто гигантская. Впрочем, гошные дженерики реализованы не так, как многие надеялись: без полной мономорфизации, чтобы сохранить быструю компиляцию, так что в рантайме все же довольно много всего происходит.
Дженерики в go не полные по Тьюрингу, так что творить на них какую-то чудовищую магию, как это возможно, например, в плюсах, попросту не получится. Их введение прошло с очень длительными и обстоятельными обсуждениями, главный мотив в которых был "не переусложнить язык". На мой взгляд, получилось неплохо: все дженерики, которые я писал или видел, были очень простыми и всего лишь способствовали универсальности функций или контейнеров при сохранении типизации, так что область их применения невелика; никакого SFINAE тут нет, к счастью. К тому же, экосистема уже достаточно крупная и устоявшаяся, чтобы появление дженериков не перевернуло все с ног на голову. Собственно, такого и не происходит, хотя дженерикам уже полтора года.
Иногда с недовольством недостаточной выразительностью языка и необходимостью вручную писать одни и те же вещи из раза в раз вроде общих алгоритмов для массивов, которые теперь появились в пакете slices; кодогенерация как предлагаемая альтернатива не особо помогала. Собственные контейнеры всегда приходилось затачивать под конкретные типы, их толком не вынести было в библиотеки. Часто для обобщения приходилось уничтожать информацию о типе через пустой интерфейс, а потом ее восстанавливать через попытки приведения: уж лучше дженерики.
А зачем нужен был раст, если в нем есть такие же шаблоны, как в уже существующих плюсах? Языки все же отличаются не только синтаксисом, да и обобщение уж слишком натянутое. Go все так же будет иметь намного более низкий порог входа и простоту поддержки легаси, все так же будет управлять сбором мусора, все так же будет хорош легковесными горутинами и т.д.
Интерпретация ответов тоже важна: исследователь все-таки не машина, которая просто проверяет галочки в тесте, на составлении опросника умственная работа не заканчивается. Вопрос "выберите лишний предмет из списка [x, y, z, &]" без критерия объединения имеет смысл, т.к. оставляет подопытному возможность придумать несколько собственных вариантов с разными критериями и таки лучше продемонстрировать способности, хотя некоторым и будет сложнее с таким справиться, нежели с прямолинейным вопросом. Не все так просто.
А конкретно описанный случай выглядит некорректно проведенным, т.к. подопытные явно зафиксировались на формулировке "лишний", а исследователь будто этого не заметил и продолжал настаивать, в итоге из-за этого тест "найди что-то общее ровно для 3 из 4 объектов" был воспринят как вызов "докажи, что лишнего нет и исследователь неправ, найдя применимость всех 4 объектов и связи между ними", с которым подопытные в итоге блестяще справились.
tl;dr «Низкая производительность» — это когда выполняется мало задач. Проблемы - это плохо. Что с этим делать - пока неизвестно, надо искать. Надо сделать так, чтобы было хорошо.
Что, простите? Даже если вы имели в виду "умножение на N = N сложений", то это все равно далеко от реальности, иначе перемножение/деление больших чисел занимало бы вечность. Деление, кстати, более сложная для процессора операция, чем умножение.
А у вас
спина белаяпеременные перепутались.Так может быть, расскажете, как на практике, а не как у вас в голове на основе мат. модели уровня 5 класса? Ведь задан контекст: браузерный JS, а иначе в этой информации не просто нет смысла, а она еще и вредит, т.к. создает ложные представления.
Если злоумышленник уже захватил машину разработчика, как поможет подпись коммитов, отправленных с этой же машины? Или с любой другой, куда утянули сертификат. Сертификат уже скомпрометирован и точно так же надо сверять историю действий. Имхо единственный сценарий из ваших трех, который закрывает этот механизм, это третий: когда злоумышленник все так же находится уже внутри периметра, все так же смог получить учетку гитлаба, но не смог получить доступ к машине с сертификатом.
Есть отличная пара вопросов для самопроверки, сам пользуюсь и рекомендую: что вы знаете о качестве всеобщего голосования и откуда вы это знаете? Если вдруг механизм, лежащий в основе принятия глобальных решений, не справится со своей работой, то это серьезно повышает риск краха всей цивилизации.
Ну и все-таки: кто вопросы будет составлять (пусть отложим очередность) и как минимизировать их влияние на процесс? Для соц. опросов, например, это очень важная тема, т.к. даже формулировки могут с ног на голову переворачивать результаты. Я уж не говорю о злоупотреблениях. В качестве ответа прошу не указывать ИИ, т.к. даже слабой формы ИИ пока еще не создано, а то, что сегодня маркетологами так называется, работает по принципам, похожим на аппроксимацию: "для похожих вопросов чаще всего давали примерно такие ответы, слепим что-то среднее".
Плюс как-то надо учитывать хотя бы образование и контекст: какой смысл задавать вопрос о целесообразности апгрейда модуля БАК или МКС стереотипному дворнику из провинции и какова ценность его ответа по сравнению со специалистом в этой области? Мне вот будет бессмысленно задавать даже такой простой вопрос как "должен ли получать слесарь 1-го разряда больше, чем слесарь 2-го": я банально не в курсе, в какую сторону идет рост квалификации и является первый разряд лучшим или худшим.
Вы наверняка знаете, что во множестве игр есть донат: покупка игровых ценностей за реальные деньги. И тут часто смеются двое: один над тем, кто тратит огромные деньги на ерунду, а тот в свою очередь над первым, кто считает эти деньги огромными.
У товаров помимо функциональной ценности есть еще как минимум две: эстетическая и статусная. Вот перед вами два браслета: они умеют одно и то же, но один выглядит истрепанным, грязным, угловатым и каких-то неприятных оттенков, на второй приятно просто взглянуть, но он стоит дороже. Вы всегда будете покупать первый? Со статусной чуть сложнее, тут высокая цена является качественной границей, а сам предмет может иметь меньшую значимость, чем сам факт обладания им: это важный в многослойном человеческом обществе сигнал "я выше вас по статусу, т.к. могу себе это позволить, а вы - нет".
Ежедневно по тысячам вопросов? Ок, поставим защиту: пусть только какой-то процент охвата будет. Голосуем: помимо прочих, 1млн шахтеров проголосовали, что шахтеры должны получать больше писателей. 1тысяча писателей прогосоловали, что писатели должны получать больше шахтеров. Выплаты писателям, видимо, снизились, часть писателей перешла в шахтеры. Новый цикл: 1млн+500 шахтеров и 500 писателей прогосовали. Ок, поставим защиту: за себя голосовать нельзя. Включаем в цепочку промежуточный узел: скажем, 10тыс поваров, которые сейчас получают больше писателей. 1млн+500 шахтеров проголосовало, что шахтеры должны получать больше поваров. Ок, поставим защиту...
Самое главное: прежде, чем спорить, неплохо бы договориться о терминах: что понимать под "конечной целью" и целью кого: заказчика, потребителя, программиста, мирового сообщества или кого-то еще. Цель - осознать, где и когда остановиться? Дойти до этой точки? А кто принимает решение? Или каким должен быть идеальный продукт в каждом конкретном случае? Разработка плана, как создавать идеальный продукт? Как перейти от зафиксированного продукта к процессу? Каким должен быть идеальный процесс разработки?
Нередко оказывается, что пресловутая очевидность как раз мешает ясно взглянуть на что-то: мнение уже сформировано и не пересматривается.
Сначала по пирамидке: как у вас Business не оказался основанием? Уровень должен быть самодостаточным, т.е. иметь ценность без верхних, иначе это просто цепочка промежуточных этапов. Нельзя ведь начинать писать код, если не сформулированы хоть какие-то требования? Значит, ниже надо положить постановку задачи. Постановка задачи тоже в свою очередь чем-то будет заблокирована: например, бюджетом и подбором персонала, и так далее. А просто написанный, но неиспользуемый код сам по себе не имеет ценности, только потенциал.
Теперь по сути: имхо в вашей пирамидке не хватает настоящего основания: цели создания конкретной программы. Не универсальной цели, а конкретной для отдельно взятого случая. Посмотрим на примерах.
Для первого варианта положим в основу банальную практику. Хочу, скажем, IDE-шку получше изучить, библиотеку или язык. Для такого проекта у меня будет только Write в ваших терминах: мне даже критические ошибки в этом коде необязательно исправлять, это просто черновик. Никаких compile, run, bisuness, test, modify тут не будет. Да, write тут станет ценным уровнем, хотя выше я утверждал обратное, но только из-за специальной цели всего действа.
Возьмем прикладную утилитку личного пользования, а то и одноразовую. Ее уже надо собрать, запустить, но test, modify, business не будет. Возьмем инди-игрушку: тесты могут быть, могут нет, зато появляются производительность и бизнес. Построитель отчетов для внутренннего пользователя компании: тесты обязательны, это важная информация, зато производительность может быть выкинута, как и легкая модификация. Фреймворк: тесты, производительность, читаемость, документация, но может не быть business и легкой модификации. Ключевой сервис компании: тесты, легкая модификация, производительность. Открытое ПО - необходим выстроенный и поддерживаемый процесс коллективного принятия решений и внесения изменений; кстати, тут появляется "процесс" помимо продукта и исходника.
Возьмем любой программный компонент: при наличии доступного уже готового софта выкидываем (!) write, compile, даже run в случае стороннего сервиса. Можно утратить исходники и остаться с бережно отныне хранимым бинарником, который будет годами успешно работать, процеденты такие есть. А то и вовсе все сделают другим способом - механикой, электрикой вместо электроники или еще как-то. Задача решается без написания единой строчки кода, почти что идеал; круче только удалением.
Для специальных случаев добавим всякие интересные условия типа работы в масштабе миллиардов пользователей, в realtime, в жестких ограничениях по CPU/RAM/IO или обязательного использования особенностей конкретного железа, без которых все опять-таки не будет иметь никакого смысла.
Легко заметить, что ни один из ваших пунктов не оказался сразу во всех перечисленных сценариях - правда, занятно? Кстати, производительность и читаемость/поддерживаемость обычно являются взаимоисключающими, их вместе не запихнешь. Получается, что универсальной схемы развития идеального программного продукта попросту не существует, есть лишь цели на конкретные случаи со своими функциональными и нефункциональными требованиями к готовому продукту, исходникам и рабочим процессам. Как только все требования легли в основание, можно поверх что-то строить, но не линейное, а очевидно (хехе) многовекторное, больше похожее на розу ветров. А раз уникальное и многовекторное - значит, единой цели не может быть.
P.S. есть интересные эксперименты (например, Вселенная-25), косвенно связанные с пирамидой Маслоу, показывающие-таки наличие ее верхней границы.
Ну, фулстек - это все еще разработчик ПО, цельное понятие, и его обязанности мало отличаются от обязанностей более узких специалистов; а вот с аналитикой, контролем качества, менеджментом и т.д. уже скрестить сложнее. Вообще по ТК за совмещение должностей даже без увеличения рабочих часов полагается доплата, если, конечно, должность не прописана как "делать всё и вся" и работник на это согласился.
А теперь воплотим абстракции в реальность, но пойдем не идеальным, а ИМХО более вероятным путем.
Раз инженеры получают право голоса, этот голос должен стать частью процесса, а не хватанием за руку в последний момент, следовательно, у инженера появляются новые обязанности, при этом навыки управленца+PO+архитектора в комплекте не идут. Добавим эффективное самоуправление на уровне команды - уже минимум три роли с тимлидом и получаем требования как минимум на ведущего специалиста. Опционально добавим девопс без системных администраторов, работу линией техподдержки, дежурства, прочие процессуальные события, так что в итоге на работу собственно исходным инженером остается один-два дня в неделю. Добавим плоскую структуру компании, так что эти требования автоматически применяются абсолютно ко всем инженерам. Разумеется, бизнесу очень выгодно, когда в проекте есть люди "и швец, и жнец, и на дуде игрец", да еще и инициативные, но где набрать столько универсальных пассионариев, что делать с остальными и можно ли все еще называть такую позицию просто инженером?
Ну и пара очевидностей. Первая: если менеджер не интересуется мнением специалистов, допускает тупики, игнорирует смежные проекты, не имеет долгосрочных планов, то это некомпетентный менеджер. Вторая: стиль КД даже в тексте статьи очень часто соседствует со словом "стартап", а в стартапах так-то традиционный уклад с несколькими уровнями менеджеров встречается все же нечасто.
Инфляцию доллара, думается, еще надо учесть. Доллар в рублях стал дороже (курс вырос), при этом еще и его покупательная способность заметно упала: за 4 года набежало около 20%, так что долларов 4-летней давности в пересчете будет всего $1686 / 1.2 = $1405. Отрицательный рост, как нынче говорят.