"Богатое государство" не означает "богатые граждане"
Коммунистических государств в истории пока не было. И КНР и СССР - социалистические государства со смешанной, в той или иной степени, экономикой. В СССР, например, на всём протяжении его истории существовали кооперативные и различные коллективные формы собственности (артели, товарищества). Да и с колбасой не всё так однозначно, как некоторым сейчас кажется - я застал времена советских магазинов, под завязку забитых продовольственными и промышленными товарами - той же колбасой. И пропало это всё не из-за идеологии, как таковой...
А кто мешает использовать модули? И хранимые процедуры?
Так о них и речь - думаете, это что-то меняет?... Вместе с тысячестрочными процедурами... Просто, чтобы это всё правильно использовать, нужно худо-бедно заниматься проектированием - а кто там об этом думает, когда надо быстро и вчера? Проект начинали, грубо говоря, два человека - DBP и DBA (database programmer и database administrator)...
Кстати Oracle Pl/sql поддерживает объекты и работу с ними
Ну, это ещё не объектно-ориентированный, а, скорее, чисто объектный подход... В общем, в PL/SQL нет полной парадигмы, так, что-то похожее накручено. И снаружи этим не воспользуешься (из Oracle Forms, скажем)
Похоже писали чтобы было и прибивали гвоздями.
Не, ну так о том и речь - оно и есть... до сих пор, причём двенадцать лет это я только наблюдаю, а сам проект больше двадцати лет существует... Я в своё время пытался спросить "вы чё делаете?" На меня смотрели (и до сих пор смотрят), как на идиота, который ничего не понимает в fast stupid programming (а я действительно не понимаю). Но дело ещё в том, что сам процедурный подход стимулирует такой стиль.
У каждого подхода есть свои канделябры - просто каждый, отдельно взятый разработчик выбирает свой метод освещения...
Я на протяжении 12 лет наблюдаю жизнь PL/SQL кода в одной системе.
"Сделайте вот это!" "Ща, пять минут!"
Через два месяца "Чего-то данных не видно!" Через пару часов "Блин, бажина, надо чинить, дописывать" Через два дня "Вроде работает"
Через полгода "У нас появился новый клиент, у него всё то же самое, только чуть-чуть по другому" "Напишем IF..." Через месяц "Не, нужно отдельную процедуру лепить, Ctrl-C/Ctrl-V"
Через пару месяцев "Блин, у нас тут, оказывается, в самом начале баг - нужно всех клиентов править" "Ёлки, у всех по-разному написано...'
Через три года "Нужно после процедуры сохранять всё в истории". Через два месяца "Чё та в историю не всё попадает..."
Через двенадцать лет. "Процедура длиной в четыре тысячи строк? Да вы ох...ты боже мой..." "А они что, у каждого клиента в схеме разные?" "Да нет, там разница небольшая - ты на IF'ы смотри!"
Есть два подхода (ИМХО) к решению задач - системный и последовательный. Последовательный - когда человек, видя перед собой задачу, садится и начинает описывать последовательность действий, которая приводит его к решению, по пути перед ним встают сопутствующие задачи, которые он также описывает в виде неких последовательностей...
Системный подход - когда задача сначала подвергается декомпозиции (разбиению на простые сущности, слабо связанные между собой), анализу - для выявления связей между сущностями и синтезу в виде создания формального аналога исследуемой задачи в целевом диапазоне входных-выходных параметров. ООП - это способ (или метод) описания таких задач программным способом без необходимости разворачивать это всё в последовательное решение. Всякие там особенности ООП - это просто технология конкретного метода. Не нравится? Да решайте вы свои задачи как хотите и можете. Только не проклинайте потом всех вокруг, когда понадобится что-то решительно изменить, от чего-то решительно избавиться, а что-то решительно добавить...
Сложность задачи - величина постоянная и она не зависит от метода её решения. Сложность решения - величина переменная и она, как раз, зависит от его (решения) метода...
Это все вообще без особых проблем перекладывается на чистый С (без ++)
Первый компилятор с С++ просто переводил текст в С и компилировал его компилятором С. Любая корректная программа на любом языке может быть переписана в машинный код. ООП - это не язык...
Ну, для меня базой была книга Гради Буча "Объектно-ориентированный анализ и проектирование...". Там всё довольно просто. И ответ на вопрос "для чего нужно ООП" довольно банален - для борьбы со сложностью (это, скорее, на этапе проектирования), для борьбы с повторяемостью кода (в случае наследования, скажем), для упрощения развития готового продукта (масштабирование, внесение изменений, исправление ошибок)... ООП позволяет решать задачи примерно тем же способом, как это делает мозг - познание через анализ и синтез - это наше всё.
А я не понимаю тех, кто говорит, что ООП - это что-то непонятное, обман и т.п. По-моему, там всё просто и понятно. Просто ООП надо начинать изучать не с изучения каких-то языков, в которых накручено множество инструментов для реализации тех или иных концепций ООП, а с базовых понятий, которых не так уж и много. Понять, что ООП - не способ писать код, а способ решения сложных задач...
Похоже, автор подразумевал шпиндель токарного станка в комплекте с патроном - с большой натяжкой можно уловить некоторое сходство... Ну или он представляет себе посадочный модуль по картинкам в поп-журналах 50-х годов... Но вообще переведено странно. Скажем, у автора в статье вместо "Их капсула упала" написано "Их капсула приводнилась" (splashed down), ну или "плюхнулась", если с юмором переводить :).
Фейковые отзывы или накрутка цифр: Если пользователь раскроет обман, доверие к бренду будет подорвано.
Ключевая фраза - "если пользователь раскроет обман". Раскрыть такой обман невозможно в принципе, поэтому здравомыслящий пользователь будет считать такой способ изначально враньём, а, следовательно, использовать такой способ с целью привлечения здравомыслящих (я подчёркиваю эту характеристику) пользователей - ошибка, то есть сам бренд ориентируется на "стадное" чувство и соответствующих пользователей...
Странно. Может, я чего-то не понял? Написано, что в версии 24H2 Bitlocker шифрует данные "по умолчанию". Полез у себя смотреть - Windows11Pro 24H2, C: Bitlocker off...
Принесите факты - вот тут и тут конкретно его действия ухудшают общий результат. Скажите ему чтобы так не делал, а делать давайте вот это и вот это
А вам в ответ принесут кучу фактов, где ваши действия ухудшают общий результат и скажут, что нужно делать и не делать... К тому же действовать постфактум (уже заполучив факап в виде результата), как правило, бессмысленно, - говорят о предполагаемом результате, а это далеко не такой сильный аргумент в вопросе выбора действий. Недаром ведь есть поговорка "не говори мне, что делать, и я не скажу куда тебе идти". И будет сказка про белого бычка, и серьезный негатив во взаимоотношениях (наличие врага не решается общим собранием, враг просто есть в силу установленного порядка вещей, а не в силу доброй или злой воли).
Мы с вами просто представляем два идеализированных взгляда на управленческие функции... Честно говоря, лениво писать много текста, да и идеального ответа нет. Просто мне сейчас приходится работать в такой вот не формализованной среде, где никто ни за что не отвечает - в итоге вся ответственность падает на конечного исполнителя, у которого нет ни административных, ни чисто информационных возможностей для решения не поставленных толком задач. В результате принятие пустяковых решений занимает от полудня до года (я не шучу). Начальники (на самом деле, "-цы") ведут дела под лозунгом "все делают всё", что на самом деле враньё. Слава богу, сюда как раз не добавляется фактор двоевластия, но я думаю, что это впереди...
Первая задача нового руководителя понять как процессы работают сейчас... Постепенно забирая процессы на себя, ...расширять свою зону влияния
То есть нет ни функционала, ни зон ответственности, ни того, что раньше называлось должностной инструкцией? Привели мальчика в банду и, даже не дав пистолета, сказали "крутись, как хочешь"?
Нужно понимать что второй руководитель не враг, а партнёр, имеющий схожие цели
Да нет. При таком раскладе это именно враг, особенно с учётом "схожести целей"
Конфликты в таком подходе рождаются только в следствии позиции "я знаю как надо"
Вот при таком подходе как раз конфликты и рождаются. И если у нового начальника нет позиции "я знаю, как надо" - на фига он там тогда нужен? Он же не мальчик с улицы - он профессионал со своими взглядами на способы решения задач, на организацию процессов...
В случае нерешимых противоречий нужно собрать фактуру и эскалировать вопросы на команду и вышестоящего руководителя.
"Собрать фактуру" - это такой эвфемизм для "собрать компромат"? "Эскалировать вопросы" на команду - это, типа, в курилке шептать всем на ухо "ну и м**ак же этот ваш РП!"? И ябедничать на него директору? Охренеть, подходы...
Впрочем, если это была такая тонкая ирония, я сразу извиняюсь, ибо не допер...
Вообще-то руководитель проекта и руководитель группы - это разные должности. При правильном подходе их функции должны быть разными - они должны не дублировать, а дополнять друг друга. РП - это больше техническая часть проекта, в то время как РГ - это, скорее, административная часть, если исходить из названий. Если два начальника начинают толкаться локтями - значит границы их ответственности размыты, а функции неопределённы. И никакие личностные подходы не помогут разрешить конфликт - сначала всегда нужно четко отработать формальные зоны ответственности, вопросы подчинения и полномочий.
А чего её искать? Неонка - это реклама, которую мы видим непрерывно. Недаром же речь идёт именно о неоновой лампе... А уж всучивают нам ИИ точно так же, как Привалову "черный ящик"
Да, — страстно сказал я, — но мой Черный Ящик — это не ящик… Точнее, — не совсем ящик…
Я чувствовал, что на меня надвигается какая-то тоска, что будущее мое заполняется каким-то унылым кошмаром, непоправимым и совершенно иррациональным.
— Высочайшие достижения нейтронной мегалоплазмы! — провозгласил он. — Ротор поля наподобие дивергенции градуирует себя вдоль спина и там, внутре, обращает материю вопроса в спиритуальные электрические вихри, из коих и возникает синекдоха отвечания…
У меня потемнело в глазах.
Я специально переставил цитаты...
Вопрос: что у нея… гм… у нея внутре за лпч?.." Лэпэчэ… Кэпэдэ, наверное? Что еще за лэпэчэ?
— Лампочка, значит, — сказал старичок, хихикая и потирая руки. — Кодируем помаленьку...
Странно, что автор не предлагает померить размеры черепов и поискать отличия в ДНК... Буквально любое утверждение из приведенных в "наборе качеств", а также утверждение о "центральной фигуре" - это чистой воды безумное самолюбование, основанное на вранье - ни одно из этих качеств не присуще "когнитариату", как какой-то социальной группе. Типично элитаристский подход с соответствующими выводами.
Во-первых, не "Питерс", а "товарищ Питерс". Во-вторых, вашу идею профессионального объединения… успокойся, Сиверсон… я считаю вредным бредом. Вы начитались скверных книжек о тайных организациях, Мак-Конти. Сиверсон, старина, успокойся, еще раз прошу тебя. В-третьих. Вы собираетесь требовать особых прав у людей? А вы кто? Марсианин? Кто вас вырастил и воспитал, Мак-Конти? Чей вы хлеб едите? И кто вам дал вот это? — Питерс двумя пальцами взял и приподнял полу роскошной тоги. — Какой срам, Мак-Конти!
А чего бы тогда не открывать курсы "для самых маленьких" по вождению экскаватора, например, или по бухгалтерскому учёту? Тоже полезные навыки, которые могут в жизни пригодится... Интересно, что по этому поводу могут сказать педагоги, специалисты по детской психологии (только настоящие, а не выпускники всяких полугодовых "курсов", или последователи экзотических "школ")... Конечно, экономически выгодно (особенно для основателей всех этих онлайн-занятий) с пяти лет приковать ребенка к станку или к тачке, чтобы таскать уголь из шахты - ему же надо быть готовым к "взрослой" жизни...
"Богатое государство" не означает "богатые граждане"
Коммунистических государств в истории пока не было. И КНР и СССР - социалистические государства со смешанной, в той или иной степени, экономикой. В СССР, например, на всём протяжении его истории существовали кооперативные и различные коллективные формы собственности (артели, товарищества). Да и с колбасой не всё так однозначно, как некоторым сейчас кажется - я застал времена советских магазинов, под завязку забитых продовольственными и промышленными товарами - той же колбасой. И пропало это всё не из-за идеологии, как таковой...
Так о них и речь - думаете, это что-то меняет?... Вместе с тысячестрочными процедурами... Просто, чтобы это всё правильно использовать, нужно худо-бедно заниматься проектированием - а кто там об этом думает, когда надо быстро и вчера? Проект начинали, грубо говоря, два человека - DBP и DBA (database programmer и database administrator)...
Ну, это ещё не объектно-ориентированный, а, скорее, чисто объектный подход... В общем, в PL/SQL нет полной парадигмы, так, что-то похожее накручено. И снаружи этим не воспользуешься (из Oracle Forms, скажем)
Не, ну так о том и речь - оно и есть... до сих пор, причём двенадцать лет это я только наблюдаю, а сам проект больше двадцати лет существует... Я в своё время пытался спросить "вы чё делаете?" На меня смотрели (и до сих пор смотрят), как на идиота, который ничего не понимает в fast stupid programming (а я действительно не понимаю). Но дело ещё в том, что сам процедурный подход стимулирует такой стиль.
У каждого подхода есть свои канделябры - просто каждый, отдельно взятый разработчик выбирает свой метод освещения...
Я на протяжении 12 лет наблюдаю жизнь PL/SQL кода в одной системе.
"Сделайте вот это!" "Ща, пять минут!"
Через два месяца "Чего-то данных не видно!" Через пару часов "Блин, бажина, надо чинить, дописывать" Через два дня "Вроде работает"
Через полгода "У нас появился новый клиент, у него всё то же самое, только чуть-чуть по другому" "Напишем IF..." Через месяц "Не, нужно отдельную процедуру лепить, Ctrl-C/Ctrl-V"
Через пару месяцев "Блин, у нас тут, оказывается, в самом начале баг - нужно всех клиентов править" "Ёлки, у всех по-разному написано...'
Через три года "Нужно после процедуры сохранять всё в истории". Через два месяца "Чё та в историю не всё попадает..."
Через двенадцать лет. "Процедура длиной в четыре тысячи строк? Да вы ох...ты боже мой..." "А они что, у каждого клиента в схеме разные?" "Да нет, там разница небольшая - ты на IF'ы смотри!"
Ну, вы меня поняли... Схематичненько так...
Есть два подхода (ИМХО) к решению задач - системный и последовательный. Последовательный - когда человек, видя перед собой задачу, садится и начинает описывать последовательность действий, которая приводит его к решению, по пути перед ним встают сопутствующие задачи, которые он также описывает в виде неких последовательностей...
Системный подход - когда задача сначала подвергается декомпозиции (разбиению на простые сущности, слабо связанные между собой), анализу - для выявления связей между сущностями и синтезу в виде создания формального аналога исследуемой задачи в целевом диапазоне входных-выходных параметров. ООП - это способ (или метод) описания таких задач программным способом без необходимости разворачивать это всё в последовательное решение. Всякие там особенности ООП - это просто технология конкретного метода. Не нравится? Да решайте вы свои задачи как хотите и можете. Только не проклинайте потом всех вокруг, когда понадобится что-то решительно изменить, от чего-то решительно избавиться, а что-то решительно добавить...
Сложность задачи - величина постоянная и она не зависит от метода её решения. Сложность решения - величина переменная и она, как раз, зависит от его (решения) метода...
Первый компилятор с С++ просто переводил текст в С и компилировал его компилятором С. Любая корректная программа на любом языке может быть переписана в машинный код. ООП - это не язык...
Ну, для меня базой была книга Гради Буча "Объектно-ориентированный анализ и проектирование...". Там всё довольно просто. И ответ на вопрос "для чего нужно ООП" довольно банален - для борьбы со сложностью (это, скорее, на этапе проектирования), для борьбы с повторяемостью кода (в случае наследования, скажем), для упрощения развития готового продукта (масштабирование, внесение изменений, исправление ошибок)... ООП позволяет решать задачи примерно тем же способом, как это делает мозг - познание через анализ и синтез - это наше всё.
А я не понимаю тех, кто говорит, что ООП - это что-то непонятное, обман и т.п. По-моему, там всё просто и понятно. Просто ООП надо начинать изучать не с изучения каких-то языков, в которых накручено множество инструментов для реализации тех или иных концепций ООП, а с базовых понятий, которых не так уж и много. Понять, что ООП - не способ писать код, а способ решения сложных задач...
Похоже, автор подразумевал шпиндель токарного станка в комплекте с патроном - с большой натяжкой можно уловить некоторое сходство... Ну или он представляет себе посадочный модуль по картинкам в поп-журналах 50-х годов... Но вообще переведено странно. Скажем, у автора в статье вместо "Их капсула упала" написано "Их капсула приводнилась" (splashed down), ну или "плюхнулась", если с юмором переводить :).
Ключевая фраза - "если пользователь раскроет обман". Раскрыть такой обман невозможно в принципе, поэтому здравомыслящий пользователь будет считать такой способ изначально враньём, а, следовательно, использовать такой способ с целью привлечения здравомыслящих (я подчёркиваю эту характеристику) пользователей - ошибка, то есть сам бренд ориентируется на "стадное" чувство и соответствующих пользователей...
Странно. Может, я чего-то не понял? Написано, что в версии 24H2 Bitlocker шифрует данные "по умолчанию". Полез у себя смотреть - Windows11Pro 24H2, C: Bitlocker off...
Не, не удержался:). Одна реплика
А вам в ответ принесут кучу фактов, где ваши действия ухудшают общий результат и скажут, что нужно делать и не делать... К тому же действовать постфактум (уже заполучив факап в виде результата), как правило, бессмысленно, - говорят о предполагаемом результате, а это далеко не такой сильный аргумент в вопросе выбора действий. Недаром ведь есть поговорка "не говори мне, что делать, и я не скажу куда тебе идти". И будет сказка про белого бычка, и серьезный негатив во взаимоотношениях (наличие врага не решается общим собранием, враг просто есть в силу установленного порядка вещей, а не в силу доброй или злой воли).
Мы с вами просто представляем два идеализированных взгляда на управленческие функции... Честно говоря, лениво писать много текста, да и идеального ответа нет. Просто мне сейчас приходится работать в такой вот не формализованной среде, где никто ни за что не отвечает - в итоге вся ответственность падает на конечного исполнителя, у которого нет ни административных, ни чисто информационных возможностей для решения не поставленных толком задач. В результате принятие пустяковых решений занимает от полудня до года (я не шучу). Начальники (на самом деле, "-цы") ведут дела под лозунгом "все делают всё", что на самом деле враньё. Слава богу, сюда как раз не добавляется фактор двоевластия, но я думаю, что это впереди...
То есть нет ни функционала, ни зон ответственности, ни того, что раньше называлось должностной инструкцией? Привели мальчика в банду и, даже не дав пистолета, сказали "крутись, как хочешь"?
Да нет. При таком раскладе это именно враг, особенно с учётом "схожести целей"
Вот при таком подходе как раз конфликты и рождаются. И если у нового начальника нет позиции "я знаю, как надо" - на фига он там тогда нужен? Он же не мальчик с улицы - он профессионал со своими взглядами на способы решения задач, на организацию процессов...
"Собрать фактуру" - это такой эвфемизм для "собрать компромат"? "Эскалировать вопросы" на команду - это, типа, в курилке шептать всем на ухо "ну и м**ак же этот ваш РП!"? И ябедничать на него директору? Охренеть, подходы...
Впрочем, если это была такая тонкая ирония, я сразу извиняюсь, ибо не допер...
Вообще-то руководитель проекта и руководитель группы - это разные должности. При правильном подходе их функции должны быть разными - они должны не дублировать, а дополнять друг друга. РП - это больше техническая часть проекта, в то время как РГ - это, скорее, административная часть, если исходить из названий. Если два начальника начинают толкаться локтями - значит границы их ответственности размыты, а функции неопределённы. И никакие личностные подходы не помогут разрешить конфликт - сначала всегда нужно четко отработать формальные зоны ответственности, вопросы подчинения и полномочий.
https://youtu.be/6NaVWAeQwGU?si=rsF3HA4HiVPRugde
Прям "Звёздные войны" :)... Вообще, вопросы двоевластия - это стандартная проблема управления.
А чего её искать? Неонка - это реклама, которую мы видим непрерывно. Недаром же речь идёт именно о неоновой лампе... А уж всучивают нам ИИ точно так же, как Привалову "черный ящик"
Самый гениальный текст об ИИ, ИМХО:
Я специально переставил цитаты...
Не говоря уже о том, что "старичок" сам задаёт вопрос и сам же на него отвечает...
Странно, что автор не предлагает померить размеры черепов и поискать отличия в ДНК... Буквально любое утверждение из приведенных в "наборе качеств", а также утверждение о "центральной фигуре" - это чистой воды безумное самолюбование, основанное на вранье - ни одно из этих качеств не присуще "когнитариату", как какой-то социальной группе. Типично элитаристский подход с соответствующими выводами.
Недавно совсем читал какую-то статью на похожую тему - фраза слово в слово повторяется...
А чего бы тогда не открывать курсы "для самых маленьких" по вождению экскаватора, например, или по бухгалтерскому учёту? Тоже полезные навыки, которые могут в жизни пригодится... Интересно, что по этому поводу могут сказать педагоги, специалисты по детской психологии (только настоящие, а не выпускники всяких полугодовых "курсов", или последователи экзотических "школ")... Конечно, экономически выгодно (особенно для основателей всех этих онлайн-занятий) с пяти лет приковать ребенка к станку или к тачке, чтобы таскать уголь из шахты - ему же надо быть готовым к "взрослой" жизни...