Нет, текущая система не мотивирует на написание статьи, во-первых, для этого нужно вдохновение, во-вторых, простая базовая возможность ставить плюсы — это то, что должно быть из коробки, а не за принуждение к генерации контента. А другой мотивации и не предусмотрено, ППА — это водораздел, штурмовать его нет никаких причин. Я хочу поддержать чьё-то мнение или не согласиться, почему для этого нужно или написать бесполезный комментарий, или выполнить вообще нерелевантное действие?
Очевидная лигаси система с закосом под индивидуальность и выставлением непрозрачности как фичу security through obscurity. Негативная динамика новых регистраций в этом ключе тривиальна, ещё не известно, сколько среди них реально мультиакков.
Сейчас эра геймификации, ачивок, за ничего даже комментировать нет желания, если при текущей системе рейтинг автодеградирует.
Люди, пишущие на императивных языках, столкнулись с задачами декларативных языков, взяли из них кусочек алгоритма решения и сразу «Вааааау!». Ждём проникновения декларативных возможностей во все популярные ЯП, как это сейчас было (и всё ещё продолжается) с проникновением функционального программирования.
Хах, я тоже так думал. Пока один знакомый в одной из топовых организаций страны не пожаловался, что их хранилище данных — это просто ворох таблиц без связей и индексов, и что поэтому у них постоянно что-то теряется, что-то дублируется. Потом встречался с сокурсником из топового интегратора, который участвовал в проектировании этого хранилища на позиции архитектора, и на мой вопрос он ответил: «Ну а что, мы всегда так делаем, под индексами там данные не зальёшь/не изменишь — это оптимизация». У меня из одного вопроса «почему?» осталось два: «а зачем тогда оно такое надо» и «за что они получают астрономические деньги».
Situation: There are 14 competing standards
«14?! Ridiculous! We need to develop one universal standard that covers everyone's use cases.» «Yeah!»
Situation: There are 15 competing standards
В статье в абзаце про фича-команды расписано про решение конфликтов реализации по этапам: личный баттл, [привлечение начальства,] совместное рисование, привлечение арбитра. Не пробовали ввести позицию Архитектора? Привлекаемые арбитры неявно и исполняют роль архитектора, но если в каждом случае это разные специалисты, то к этапу зрелости продукта вы получите неоднородную кодовую базу и кучу уникальных нетиражированных решений. Архитектор нужен для распространения единого видения, подходов, стиля и опыта между всеми командами.
На моей практике (в т.ч. собственной) элегантные решения встречаются, но вы должны знать, что исключения лишь подтверждают правила. Также, я не утверждал, что против полного переноса логики в БД.
Итак, о чём было утверждение: частичный перенос логики на уровень БД при наличии интеграционного уровня приложения является хаком или костылём, в большом кровавом энтерпрайзе (а мы ведь про него, правда?) решения должны быть изолированы в пределах своей зоны ответственности (инкапсулированы). Потому что за разные уровни отвечают сильно разные люди и политики, взаимодействия. Я не говорю про стартап-компании, где один специалист — и чтец, и жнец, и на дуде игрец, я про серьёзные большие группы.
Отсюда следует, что решение может быть как полностью в БД, так и полностью в интеграционном слое. Все современные топ-ETL средства (Informatica, ODI, etc) покрывают все необходимые задачи, и если подпорку опускают в БД, значит, специалист плохо знает свой ETL-продукт.
Хм, мне кажется в любой (ИТ-)компании благодаря техническому прогрессу и популяризации мессенджеров уже есть свои чаты-сообщества, они уже разбиты по отделам/технологиям/интересам. Создание корпоративного сообщества — это похоже на попытку взять власть над ними. Например, есть чат, в котором среди участников есть директор, туда сотрудники пишут раз в неделю сухую информацию. Как информер — хорошо, как площадка — не очень.
Абсолютно с вами солидарен насчёт битья по рукам. Особенно нужно бить тех, кто часть логики трансформации данных опускают в БД при живом ETL-средстве, в итоге тебе в базу положили одно, а вытащил ты непонятное нечто. Теория информации подсказывает, что любая обработка информации узлом приводит к её потере. Имеем снижение надёжности интеграции и так или иначе однажды возникновение ошибки о получении недопустимых данных.
С абсолютным уровнем ещё бесил минимальный шаг регулировки в 1/10 уровня громкости в андроиде. Иногда реально при разговоре особо громогласные люди при хорошей связи на нормальном аппарате и на минимальном уровне в это первое деление уши выдавливали, и приходилось переключаться из наушников на телефон.
Я к чему, любая фича всегда будет кому-то нравиться, а кому-то — нет. Решение здесь одно: фича должна быть параметризована, использовать её или нет — решение каждого пользователя.
«Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба можно превратить в троллейбус… Но зачем?»
Не спорю, получилось красиво, хотя я вначале был заинтригован и ожидал в основе что-то элегантней обычного eval. В целом, надеюсь, что хайп вокруг ФП скоро уляжется в конкретной ограниченной области его применения.
Вы правы, с точки зрения эволюции социально-негативные умения — тоже таланты. Но у нас таких «талантливых» полмиллиона в тюрьмах и ещё десятки миллионов не выше кражи денег на детскую площадку поднялись.
Думаю, у большинства людей есть фишки, которыми они регулярно пользуются, и эта информация всё время висит в оперативной памяти. Остальное сжато и лежит далеко в долговременной памяти, иногда сжатие происходит с потерями. Не представляю, чтобы на текущем уровне развития ЯП, библиотек и абстракций, кому-то постоянно приходилось реализовывать базовые алгоритмы. Не спорю, есть специфичные области, — это исключение, подтверждающее правило. Также, бывает полезно переписать базовый алгоритм в целях оптимизации, когда данный алгоритм используется в подавляющем объёме операций (как было здесь в статье 1С про то, как они переписывали базовый класс работы со строками).
Поэтому, важно не то, знает ли человек конкретный базовый алгоритм, а знает ли о нём вообще. Поясню: в университете на письменных экзаменах нам разрешали использовать открыто любые источники, — лекции, учебники и т.д. Так как было важно, чтобы студент знал, какие есть методы и законы, где они применимы, и мог ими оперировать для достижения цели — решения задачи. Если он не знал инструментов, то поиск не сильно помогал.
Видимо, если в модели не найдут очевидных расхождений с реальностью, она подтверждает теории о пользе Безусловного общего дохода. В целом это понятно в том ключе, что талантливым людям в сложной социальной позиции не на что раскрывать свой талант, так как это наглядно видно в РФ: хобби/университетская специальность в подавляющем объёме материально сильно менее привлекательны основных трендов экономики и либо вовсе не может обеспечить материальных потребностей, либо оставляет на очень низком уровне.
Собственно, уже на этом этапе у большинства DIY-проектов — чёрная дыра: автор делает что-то совершенно непонятно зачем.
Статьи с непонятным целеполаганием не только по тематике DIY, аналогичная ситуация и по другим сферам. Сколько статей уже было про функциональное программирование, и в частности, про монады. Человеку, который этого не касался, они вообще не приносят никакой пользы, так как начинаются обычно так: «О, ну, монады — это такая штука, абстракция, она упрощает обработку ошибок/инкапсулирует цепочку вычислений/промогает интерпретаторам», а в целом про: «смотрите, на других ЯП монаду написать очень сложно, а в Скала/Хаскель как просто!». И так — везде, а практических примеров ноль, вообще не понятно: оно зачем? Оно мне надо? Для чего вообще пересаживаться на yet another ЯП ради какой-то одной абстракции?
Потому что без таланта и усилий, удача просто ничего не может сделать. Разве что в казино.
Может, посмотрите на наших олигархов и прочих крупных богачей — какие у них выдающиеся таланты? Только не говорите про управленческие, пожалуйста. Статья красиво показывает, что чтобы сильно подняться, достаточно быть не очень тупым (топ-богачи по графикам имеют талант почти медианный), чтобы в случае наступления удачного случая им воспользоваться. Но первично само наступление удачных случаев, было бы чем воспользоваться.
Читая заметки и мемуары некоторых успешных людей, я заметил, что все они отдают должное удаче, но при этом гораздо выше ценят талант и усилия.
Кто же о себе напишет, что он был обычным троечником без каких либо увлечений и квалификации? Все эти истории успеха — они от единиц людей-миллионеров, думаете они такие умные, взяли, сели, написали соц.сеть/купили крипту, и всё — богачи? И никто до них не пытался? До них были миллионы попыток, но выстрелила только одна. Те, у кого ничего не вышло, не пишут книги о своём провале (есть исключения, конечно).
В статье полное непонимание целей и различий университета/института/ПТУ. Университет — это принятие архитектурных решений перед проектированием решения(продукта), в данном случае продукт — это студент. На данном этапе фиксируются решения только по архитектурно значимым и медленно изменяющимся требованиям. Это же касается и курсов в университете: они должны передать студентам широкий спектр знаний, актуальность которых медленно изменяется со временем, но сильно влияет на общие навыки, такие знания называются фундаментальными.
Очевидная лигаси система с закосом под индивидуальность и выставлением непрозрачности как фичу security through obscurity. Негативная динамика новых регистраций в этом ключе тривиальна, ещё не известно, сколько среди них реально мультиакков.
Сейчас эра геймификации, ачивок, за ничего даже комментировать нет желания, если при текущей системе рейтинг автодеградирует.
Situation: There are 14 competing standards
«14?! Ridiculous! We need to develop one universal standard that covers everyone's use cases.» «Yeah!»
Situation: There are 15 competing standards
Возможно дело как раз в этом: в командах участвует enterprise-архитектор, а должен solution architect, который чуть ближе к внутренностям.
Итак, о чём было утверждение: частичный перенос логики на уровень БД при наличии интеграционного уровня приложения является хаком или костылём, в большом кровавом энтерпрайзе (а мы ведь про него, правда?) решения должны быть изолированы в пределах своей зоны ответственности (инкапсулированы). Потому что за разные уровни отвечают сильно разные люди и политики, взаимодействия. Я не говорю про стартап-компании, где один специалист — и чтец, и жнец, и на дуде игрец, я про серьёзные большие группы.
Отсюда следует, что решение может быть как полностью в БД, так и полностью в интеграционном слое. Все современные топ-ETL средства (Informatica, ODI, etc) покрывают все необходимые задачи, и если подпорку опускают в БД, значит, специалист плохо знает свой ETL-продукт.
Я к чему, любая фича всегда будет кому-то нравиться, а кому-то — нет. Решение здесь одно: фича должна быть параметризована, использовать её или нет — решение каждого пользователя.
Не спорю, получилось красиво, хотя я вначале был заинтригован и ожидал в основе что-то элегантней обычного eval. В целом, надеюсь, что хайп вокруг ФП скоро уляжется в конкретной ограниченной области его применения.
Поэтому, важно не то, знает ли человек конкретный базовый алгоритм, а знает ли о нём вообще. Поясню: в университете на письменных экзаменах нам разрешали использовать открыто любые источники, — лекции, учебники и т.д. Так как было важно, чтобы студент знал, какие есть методы и законы, где они применимы, и мог ими оперировать для достижения цели — решения задачи. Если он не знал инструментов, то поиск не сильно помогал.
Статьи с непонятным целеполаганием не только по тематике DIY, аналогичная ситуация и по другим сферам. Сколько статей уже было про функциональное программирование, и в частности, про монады. Человеку, который этого не касался, они вообще не приносят никакой пользы, так как начинаются обычно так: «О, ну, монады — это такая штука, абстракция, она упрощает обработку ошибок/инкапсулирует цепочку вычислений/промогает интерпретаторам», а в целом про: «смотрите, на других ЯП монаду написать очень сложно, а в Скала/Хаскель как просто!». И так — везде, а практических примеров ноль, вообще не понятно: оно зачем? Оно мне надо? Для чего вообще пересаживаться на yet another ЯП ради какой-то одной абстракции?
Может, посмотрите на наших олигархов и прочих крупных богачей — какие у них выдающиеся таланты? Только не говорите про управленческие, пожалуйста. Статья красиво показывает, что чтобы сильно подняться, достаточно быть не очень тупым (топ-богачи по графикам имеют талант почти медианный), чтобы в случае наступления удачного случая им воспользоваться. Но первично само наступление удачных случаев, было бы чем воспользоваться.
Кто же о себе напишет, что он был обычным троечником без каких либо увлечений и квалификации? Все эти истории успеха — они от единиц людей-миллионеров, думаете они такие умные, взяли, сели, написали соц.сеть/купили крипту, и всё — богачи? И никто до них не пытался? До них были миллионы попыток, но выстрелила только одна. Те, у кого ничего не вышло, не пишут книги о своём провале (есть исключения, конечно).