Ну тогда тем более было бы неплохо пояснить, что же это все-таки такое. Этот текст - он неявно предполагает, что читатели и так это все знают (что далеко не факт).
Используете ли вы бескамерные колеса на своем велосипеде?
Автор, вообще для тех кто зашел случайно, как я, было бы неплохо просто пояснить, про что это вообще. Потому что мне вот было бы сильно интереснее читать этот (я знаю что это перевод) текст, если бы я вообще понимал бы, что такое эти бортовые зацепы. И кого реально это все касается (от профессиональных гонщиков до любителей).
Ну, я бы не сказал, что вы слишком упростили. Эта задача сама по себе непростая, если ее еще немного упростить - смысл совсем потеряется. Ваша постановка вполне хороша для "классических" СУБД, когда ресурсы фиксированы.
Я бы сказал, что еще более интересны авторы, которые строчат десятки постов, получают за каждый из них что-то около нуля, и кучу постов в минусах - и продолжают при этом публиковать, ни грамма не меняя в своих текстах. И это не корпоративные блоги...
Я, например, начал использовать Spark c версии 1.Х :)
Я тоже :)
Зная время выполнения запроса Х и зная значения memorySeconds и vcoreSeconds предсказать время выполнения запроса Х с другими ресурсами можно довольно точно).
Вот тут я что-то не уверен. Ну т.е. наверное да, вы правы - что-то предсказать можно, если мы понимаем, что запрос как-то параллелится. Просто знание о "доступных ресурсах" - это фактически в реальности знание о том, что у нас с вами работает на кластере, в том числе помимо нашего запроса, и в общем-то в реальности мы довольно редко хотим оптимизировать один запрос ценой заваливания ресурсами - потому что остальные тогда что будут делать?
memorySeconds и vcoreSeconds.
Ну вот я к этому и клоню, что скорее это показатель эффективности, а не просто время.
Смотрите, с вашей постановкой вопроса я скорее согласен, чем с противоположной. Индустрия никуда "не туда" не сворачивала, она развивается, хотя иногда и не в тех направлениях, куда предполагали 10 лет назад. И мой пример про задачу как раз к тому, что наши задачи тоже сильно усложнились.
Отвечаю же я на конкретное предложение посчитать в штуках языки, ОС или СУБД. Конкретно лишь оно мне кажется малоосмысленным. Многие сегодняшние популярные языки и ОС и СУБД тогда уже существовали. Что мы принципиально нового имеем сегодня в области реляционных СУБД, если к 1995 оракл и DB2 уже были написаны? Нам точно их количество важно? Потому что если их в штуках считать, то была например такая СУБД Informix, довольно популярная когда-то. Где она сейчас? Я думаю мало кто сходу скажет (при том что она существует). Нишевый продукт. Это как оценить, как прогресс или наоборот?
Ну, давайте так - может у кого-то все только начиналось, а я таки в 95 уже 20 лет как программировал. И я вам так скажу: СУБД, ОС и ЯП уже было достаточно. Это не значит, что они были те же, что и сегодня, нет. Но разнообразие уже давно наблюдалось. Вас же не удивляет, надеюсь, что лисп у нас 1958 года рождения, а хаскель - 1990? Разумеется, все что касается интернета, с тех пор изменилось радикально.
Это я к тому, что считать в штуках тут неправильно. Я бы с другой стороны зашел бы: вот у меня чисто в качестве хобби стоит задача анализа видео. Т.е. выделение в кадре объектов, измерение их скорости, вычисление точек пересечения траекторий и т.п. И хотя лично я не готов в одно лицо прямо сесть и такое реализовать, я точно знаю, что сегодня эта задача вполне решаема, и вопрос уже скорее стоит так - решить ли ее на телефоне, или лучше в облаке, и что выгоднее? Я думаю вы легко найдете тут на Хабре пару статей за неделю, где описаны подходы вот прямо к этой задаче (т.е. анализ матчей в футболе, скажем). При этом в том же 1995 такую задачу я с трудом могу себе представить - хотя бы по причине слишком разного железа (в 1995 у меня был мейнфрейм с 16 мегабайтами памяти, и парой гигабайт дисков, что сегодня довольно смешно выглядит).
Вот честно, вы бы лучше текстовые описания бы подправили. А то этож смешно читать: вот есть на Мегамаркете такой "фрезер ермак", китайщина китайщиной. И написано про него вот что:
Напряжение аккумулятора, в вольтах: 220
Количество аккумуляторов комплекте: 1
Фрезер при этом сетевой, ясное дело, и на фотке хорошо видно сетевой шнур. Вам смешно? Мне очень. Ну т.е. написана явная чушь (раньше еще было написано, что обороты у него 120 в минуту, но уже исправили).
И такого барахла в описаниях товаров - вагон и маленькая тележка.
Я подозреваю, что нейросеть вполне могла бы эту чушь выявить.
На самом деле не только время, но для упрощения мы будем считать только время, так как это ключевой параметр.
Если бы авторы немного вникли в то, как выполняет запросы например Spark, то поняли бы, что время вообще не параметр само по себе, потому что его можно разменять на ресурсы. Т.е., вы можете выделить на выполнение запроса скажем, 10 ядер CPU, и 10 гигабайт памяти, а можете - 1000 ядер и 10 терабайт. И результаты по времени выполнения будут совершенно разные. Время актуально при условии, что ресурсы фиксированы, а это далеко не всегда так.
Ну и как резонно выше замечено, на выполнение запросов влияет множество факторов, и кроме наличия индексов можно еще назвать наличие актуальных статистик, про которое (в отличие от наличия индекса) мы вообще ничего не знаем.
В цитате что я привел, Intended - это намерения, а не обещания.
Что тут надо сделать с точки зрения компоновки классов?
Возможно что ничего. А зачем? Если вы следуете цели повысить гибкость и сопровождаемость, задайте себе вопрос - а оно щас легко сопровождается? Если да - забейте на эту цель, зачем тратить на нее ресурсы? Если мне сейчас такой код норм - значит у меня нет цели повышать его понятность, пока я один разработчик на проекте. Если я завтра найму миддла - возможно у меня такая цель появится, а сейчас ее нет. Ну во всяком случае я так обычно подхожу.
Гибкость и сопровождаемость - это декларируемая цель. Принципы эти - они ни разу не гарантируют ничего, это не законы физики. Если вам скажут, что они это гарантируют - это будет брехня. И маркетинг.
И в любом случае применение или неприменение принципов (и выбор того, какой конкретно применить) - за автором. И делать это без применения головы я бы не советовал категорически. А если вы в 95% случаев получаете повышение гибкости - так это более чем хороший результат (особенно - если вы этого реально хотели ;)
изоляция незапланированного импакта. Все.
Так это очень много, на самом деле. Это значит, что вы можете вносить изменения в локальный кусок кода, и не беспокоиться о том, что сломается соседний. Во всех бы проектах так было.
А что для вас в этой формулировке не ясно? Это вполне себе цель. И она не совпадает с просто целью "сделать хорошо".
"гибкость, легкость расширения и поддержки" он как раз таки ломает в угоду изоляции импакта.
Вот тут я не уловил. Изоляция импакта, на мой взгляд, это нормальная формулировка всех принципов SOLID в форме одного принципа (просто я это обычно называю чуть длиннее и другими словами, но думаю что мы об одном и том же). Т.е. все принципы, по-идее, направлены на то, чтобы изолировать влияние изменений минимально необходимым куском кода, потому что эта изоляция и дает легкость расширения и поддержки. Просто разные принципы - про разные причины изменений и разные способы их "расползания" куда не следует.
Если мы импакт таки изолировали, то как и где легкость расширения сломалась?
Только не читайте русский перевод, посмотрите вот сюда, в английский. Вы видите назначение принципов? Что вам тут непонятно? Во-первых, это акроним, т.е принципов пять. Во-вторых, назначение принципов сделать код более понятным, гибким и сопровождаемым.
В принципе, такого понимания достаточно для того, чтобы вы четко знали - вам это нужно или нет. Вы свой код понимаете? Если да, вы можете не заморачиваться этими принципами. Если нет - то вы можете попробовать применить некоторые из них, чтобы сделать его понятнее (но вы не обязаны - вам ничего не будет, если вы это не сделаете). И тем более вы не обязаны применять их все.
про снижение регресса и незапланированного импакта.
Ну как бы, примерно 90% авторов таких статей (по моим субъективным оценкам) вообще не помнят о назначении принципов SOLID (которое изложено во втором предложении скажем статьи википедии). Понимаете? Большая часть авторов, решивших писать про эту тему, не дочитала формулировку, что же такое SOLID, дальше первого предложения.
Да что там стесняться, плохо оно работает. У меня недели две как начал откровенно глючить, автор якобы в чорном списке - а его статьи мне показывают. Я пытаюсь его еще раз - получаю сообщение что он уже там.
Отлично. Так похоже на реальность - вряд ли им гранта хватило бы на реальную S/370.
CP CMS нельзя было приобрести, как вы выражаетесь.
CMS это однопользовательская ОС для одной виртуальной машины. ОС для реальной машины называлась VM/370, или позже VM/SP.
И насколько я знаю, она как правило не продавалась. Ее сдавали в аренду вместе с машиной.
Ну тогда тем более было бы неплохо пояснить, что же это все-таки такое. Этот текст - он неявно предполагает, что читатели и так это все знают (что далеко не факт).
Автор, вообще для тех кто зашел случайно, как я, было бы неплохо просто пояснить, про что это вообще. Потому что мне вот было бы сильно интереснее читать этот (я знаю что это перевод) текст, если бы я вообще понимал бы, что такое эти бортовые зацепы. И кого реально это все касается (от профессиональных гонщиков до любителей).
А должна? Хабр уже довольно давно не только про ИТ.
Ну, я бы не сказал, что вы слишком упростили. Эта задача сама по себе непростая, если ее еще немного упростить - смысл совсем потеряется. Ваша постановка вполне хороша для "классических" СУБД, когда ресурсы фиксированы.
Я бы сказал, что еще более интересны авторы, которые строчат десятки постов, получают за каждый из них что-то около нуля, и кучу постов в минусах - и продолжают при этом публиковать, ни грамма не меняя в своих текстах. И это не корпоративные блоги...
Вот тут я что-то не уверен. Ну т.е. наверное да, вы правы - что-то предсказать можно, если мы понимаем, что запрос как-то параллелится. Просто знание о "доступных ресурсах" - это фактически в реальности знание о том, что у нас с вами работает на кластере, в том числе помимо нашего запроса, и в общем-то в реальности мы довольно редко хотим оптимизировать один запрос ценой заваливания ресурсами - потому что остальные тогда что будут делать?
Ну вот я к этому и клоню, что скорее это показатель эффективности, а не просто время.
Смотрите, с вашей постановкой вопроса я скорее согласен, чем с противоположной. Индустрия никуда "не туда" не сворачивала, она развивается, хотя иногда и не в тех направлениях, куда предполагали 10 лет назад. И мой пример про задачу как раз к тому, что наши задачи тоже сильно усложнились.
Отвечаю же я на конкретное предложение посчитать в штуках языки, ОС или СУБД. Конкретно лишь оно мне кажется малоосмысленным. Многие сегодняшние популярные языки и ОС и СУБД тогда уже существовали. Что мы принципиально нового имеем сегодня в области реляционных СУБД, если к 1995 оракл и DB2 уже были написаны? Нам точно их количество важно? Потому что если их в штуках считать, то была например такая СУБД Informix, довольно популярная когда-то. Где она сейчас? Я думаю мало кто сходу скажет (при том что она существует). Нишевый продукт. Это как оценить, как прогресс или наоборот?
Ну, давайте так - может у кого-то все только начиналось, а я таки в 95 уже 20 лет как программировал. И я вам так скажу: СУБД, ОС и ЯП уже было достаточно. Это не значит, что они были те же, что и сегодня, нет. Но разнообразие уже давно наблюдалось. Вас же не удивляет, надеюсь, что лисп у нас 1958 года рождения, а хаскель - 1990? Разумеется, все что касается интернета, с тех пор изменилось радикально.
Это я к тому, что считать в штуках тут неправильно. Я бы с другой стороны зашел бы: вот у меня чисто в качестве хобби стоит задача анализа видео. Т.е. выделение в кадре объектов, измерение их скорости, вычисление точек пересечения траекторий и т.п. И хотя лично я не готов в одно лицо прямо сесть и такое реализовать, я точно знаю, что сегодня эта задача вполне решаема, и вопрос уже скорее стоит так - решить ли ее на телефоне, или лучше в облаке, и что выгоднее? Я думаю вы легко найдете тут на Хабре пару статей за неделю, где описаны подходы вот прямо к этой задаче (т.е. анализ матчей в футболе, скажем). При этом в том же 1995 такую задачу я с трудом могу себе представить - хотя бы по причине слишком разного железа (в 1995 у меня был мейнфрейм с 16 мегабайтами памяти, и парой гигабайт дисков, что сегодня довольно смешно выглядит).
Вот честно, вы бы лучше текстовые описания бы подправили. А то этож смешно читать: вот есть на Мегамаркете такой "фрезер ермак", китайщина китайщиной. И написано про него вот что:
Напряжение аккумулятора, в вольтах: 220
Количество аккумуляторов комплекте: 1
Фрезер при этом сетевой, ясное дело, и на фотке хорошо видно сетевой шнур. Вам смешно? Мне очень. Ну т.е. написана явная чушь (раньше еще было написано, что обороты у него 120 в минуту, но уже исправили).
И такого барахла в описаниях товаров - вагон и маленькая тележка.
Я подозреваю, что нейросеть вполне могла бы эту чушь выявить.
Если бы авторы немного вникли в то, как выполняет запросы например Spark, то поняли бы, что время вообще не параметр само по себе, потому что его можно разменять на ресурсы. Т.е., вы можете выделить на выполнение запроса скажем, 10 ядер CPU, и 10 гигабайт памяти, а можете - 1000 ядер и 10 терабайт. И результаты по времени выполнения будут совершенно разные. Время актуально при условии, что ресурсы фиксированы, а это далеко не всегда так.
Ну и как резонно выше замечено, на выполнение запросов влияет множество факторов, и кроме наличия индексов можно еще назвать наличие актуальных статистик, про которое (в отличие от наличия индекса) мы вообще ничего не знаем.
В цитате что я привел, Intended - это намерения, а не обещания.
Возможно что ничего. А зачем? Если вы следуете цели повысить гибкость и сопровождаемость, задайте себе вопрос - а оно щас легко сопровождается? Если да - забейте на эту цель, зачем тратить на нее ресурсы? Если мне сейчас такой код норм - значит у меня нет цели повышать его понятность, пока я один разработчик на проекте. Если я завтра найму миддла - возможно у меня такая цель появится, а сейчас ее нет. Ну во всяком случае я так обычно подхожу.
Гибкость и сопровождаемость - это декларируемая цель. Принципы эти - они ни разу не гарантируют ничего, это не законы физики. Если вам скажут, что они это гарантируют - это будет брехня. И маркетинг.
И в любом случае применение или неприменение принципов (и выбор того, какой конкретно применить) - за автором. И делать это без применения головы я бы не советовал категорически. А если вы в 95% случаев получаете повышение гибкости - так это более чем хороший результат (особенно - если вы этого реально хотели ;)
Так это очень много, на самом деле. Это значит, что вы можете вносить изменения в локальный кусок кода, и не беспокоиться о том, что сломается соседний. Во всех бы проектах так было.
А что для вас в этой формулировке не ясно? Это вполне себе цель. И она не совпадает с просто целью "сделать хорошо".
Вот тут я не уловил. Изоляция импакта, на мой взгляд, это нормальная формулировка всех принципов SOLID в форме одного принципа (просто я это обычно называю чуть длиннее и другими словами, но думаю что мы об одном и том же). Т.е. все принципы, по-идее, направлены на то, чтобы изолировать влияние изменений минимально необходимым куском кода, потому что эта изоляция и дает легкость расширения и поддержки. Просто разные принципы - про разные причины изменений и разные способы их "расползания" куда не следует.
Если мы импакт таки изолировали, то как и где легкость расширения сломалась?
А вы прочтите хотя бы статью в википедии. Я серьезно. Вот, смотрите, первый абзац:
Только не читайте русский перевод, посмотрите вот сюда, в английский. Вы видите назначение принципов? Что вам тут непонятно? Во-первых, это акроним, т.е принципов пять. Во-вторых, назначение принципов сделать код более понятным, гибким и сопровождаемым.
В принципе, такого понимания достаточно для того, чтобы вы четко знали - вам это нужно или нет. Вы свой код понимаете? Если да, вы можете не заморачиваться этими принципами. Если нет - то вы можете попробовать применить некоторые из них, чтобы сделать его понятнее (но вы не обязаны - вам ничего не будет, если вы это не сделаете). И тем более вы не обязаны применять их все.
Ну как бы, примерно 90% авторов таких статей (по моим субъективным оценкам) вообще не помнят о назначении принципов SOLID (которое изложено во втором предложении скажем статьи википедии). Понимаете? Большая часть авторов, решивших писать про эту тему, не дочитала формулировку, что же такое SOLID, дальше первого предложения.
Да-да. И на КДПВ тоже ни что иное, как мини трактор CAT, произведенный конечно же в плановой экономике (сарказм).
Ну вообще он Анатолий :), но ответ на вопрос мне тоже интересен.
Да что там стесняться, плохо оно работает. У меня недели две как начал откровенно глючить, автор якобы в чорном списке - а его статьи мне показывают. Я пытаюсь его еще раз - получаю сообщение что он уже там.