Не соглашусь с этим выражением. Боль - это не мотивация. Боль - это основа страха. За сохранение жизни, за сохранение статуса итд. И как отдельный индивидум справляется со своим страхом - начальнику часто не понять, тк. это целая наука. может быть кто-то в страхе найдёт источник для мотивации, но это не гарантировано. Поэтому, я-бы не ставил знак равенства.
Про перестановку - соглашусь. Но Ваше первое и последнее заявления не разделяю. В название сказано - самый быстрый алгоритм. Там ничего не сказано про "должен он быть общего назначения". И не знаю как у других, но я сортирую больше всего числа. Поэтому и беру для этого Countingsort, т.к. разница по скорости сортировки даже с Timsort раз в 10. И для многих, кто впервые сталкивается с таким заголовком - начинают верить, что оно так и есть.
И не понимаю, в чём Вы не согласны с моим выражением " заголовок и правда не соответствует содержанию". Если заголовок уточнить условиями, которые описали Вы, то да, мой пример не подходил-бы. Не люблю, когда неточно выражаются, а потом это приводит к непониманию - "иди, мол сделай вон то и не делай вид, что не понимаешь..."
а в этих методиках куда ни глянь - всё надуманно, всё возведено в статус "не поддаётся оспариванию", за основу берётся выдуманное или нереальное поведение людей. Люди в своём начале ленивые, хитрые, алчные, преследующие свои цели, а не цели каких-то дядей. Конечно никто не будет хотеть брать на себя ответственность. Зачем она нужна, если это не восполняется и не оплачивается дополнительно. По мне agile - это совок. Никто ни за что не отвечает, всё общее, а значит - зачем выпендриваться - будь как все, ведь на фоне всех никто и не увидит твою ненужность. Качество? Да кому оно нужно, ведь работает как-нибудь, сроки просчитывать и исполнять - себя не уважать. А всё почему? Да потому что нет никакой ответственности за весь этот бардак. Ни product owner, ни scrum master, ни отдельные участники всяких там squad(ов) - никто ни за что не отвечает. Ни за костыльную архитектуру, ни за плохое качество, ни за отсутвие документации, ни за говно-код, ни за срыв сроков итд. - никто и ни за что не отвечает. Но в теории - методика классная. Всё может, всё обещает..
Это- надо-ж так - целую науку Project Management с формулами, с огромным багажем работающих механизмов снесли за раз и взамен предлагают только в теории работающие представления.
Нет, сопротивление бесполезно. Это как религия. Если это в головах, то никакое логическое обоснование не помогает. И потери как финансовые, так и по времени и качеству игнорируют как непоказательные. И весь менеджмент должен свой сук сами себе пилить и видоизменять всю иерархию на agile. И доказательство, что это плохо или хорошо лежит не на тех, кто с этими agile методами пришли, а те должны доказывать, кто в этом не уверен. Т.е. не тот должен доказыват, кто утверждает, что бог существует, а тот, кто в его существование не верит...А как это сделать, если это невозможно в принципе.
чел, ты крут. Можно я переведу всё твоё высказывание на нац. язык (живу в Европе) и отправлю своему шефу или многим шефам. т.к. при агиле их у нас тьма. Все какие-то owner(ы), но ничего не происходит, кроме того, что ты в краткой и ёмкой форме описал.
Не соглашусь с оценкой, что по быстроте один из самых быстрых. да, может быть Нотация Big O для Timsort O(n log n), но эта нотация говорит только о поверхностном анализе. Детали кроятся в другом.
Если речь идёт о числах, то алгоритму Countingsort нет равных. Если речь идёт об строковых значениях, то в алгоритме Timsort элементы перставляются очень большое (из перспектив других алгоритмов - ненужное) количество раз, если изначальная ситуация значений из average case/worst case. А перестановка строк - очень интенсивная операция. Сравнение тоже, но если не обращать внимание на усилия по перестановки, то можно быстро получить сюрпризы по скорости выполнения, когда задача будет отсортировать не десять значений, а например 1 миллион.
И хоть сортировка неплохая, но всё равно - заголовк не соответствует содержанию.
IBCS вообще классная вещь. Это настолько здорово, что до сих пор не понимаю, почему это до сих пор не стандарт. В музыки есть стандарт — ноты, в эелктронике есть стандарт — схемы и эл. компоненты Везде есть стандарты — только в описании данных их нет. И каждый рисуит их так, как хочет. И потом — никто не понимает, делают исходя из этого непонимания неправильные выводы итд…
Счтаю, что черезчур завышено значение/неправильность использования иконок. Простое слово «нормально» после вопроса «как дела?» несёт тоже не всегда то, для чего это используется. Но нам это не мешает. Мы продолжаем использовать в разговоре упрощенные формы общения. Так-же и с иконками. В руках багатых на слова людей — они обагащают речь. В руках людей, не владеющих и человеческим языком — и язык иконок будет тоже непонятным, поверхсностным итд.
Согласен. Тоже так думаю. И везде так и говорю. Хотя убедился — редко, кто в это верит.
Пойду дальше в высказывании. В большем количестве фирм, где используется Excel, то со всеми в встроенными возможностями (vba, автоматизация) можно делать много чего, что будет получше, чем тонна всякого черезчур платного софта. Почти все бизнес процессы можно с Excel и Office оцифровать. А с пакетом Office 365 (Excel, Word, PowerPoint, Teams, OneNote, PowerBI etc.) так и вообще — все.
Кстати на примере с Excel я вижу как думают люди. Там сразу видно, если созданные ими конструкции нелогичны, сложные, часто не поддающие пониманию или последующему сопровождению или видоизменению итп. Это как своего рода визитная карточка. Мне сразу понятно, кто передо мной.
Эти вами описываемые шаги были нужны и при постройки пирамид. И при постройке атомной бомбы или ракеты на марс. В этом нет ничего нового. В этом то и суть, что не изучать, опыт других, можно открывать для себя истины и думать, что это что-то новое и неизвестное. Почитайте Дейла Корнеги по управлению людьми. Его книгам больше сотни лет, а в них вы найдёте много из того с чем вы сталкиваетесь впервые. Или из того, что вы здесь упоминайте.
Спасибо за ответ. Не желаю обидеть лично вас. Но сейчас куда не "ткни палкой" — везде скрам мастера. Без технического образования, без образования в области проект менеджмента, без навыков в психологии или поведения человека. Но прошедшие н-дневные курсы. И уверенные в себе, что в состоянии воссоеденить, контролировать и довести до результата технические, специализированные и организационные задачи. При этом думающие, что все люди стремятся к одной цели. Всё это не работает от слова совсем. Только единичные случаи или тривиальные задачи. Но и то и другое часто зависит не от навыков скрам мастера а от ситуации или уже установившейся культураы, подходящего психоттипа команды, как выше уже упомянул- от тривиальности задачи, ну и пару других исходный параметров. Проект менеджмент- это наука, которую нельзя за два дня прослушки взять и владеть. Потому что всё, что не было выучино, будет с командой на личном опыте пережито… И по большей части это будут ошибки. Как-бы этого не хотелось.
Конечно — попробовать исполнение в виртуализации стоит того. Например используя вот это https://www.tinkercad.com/dashboard, я иногда отлаживаю кое-какие классы. Но. только работа с платиной и только реальные условия помогут отладить и довести до ума программу, которая на самом деле будет работать. Так как реальные условия, как работают сенсоры или акторы не возможно просимулировать. Только живьём.
… но больше в сторону увеличения скорости, чем замедления. Не последнюю роль играют здесь «register renaming» и «Instruction Issue», которые увеличивают скорость выполнения микрокоманд за счёт их параллельного исполнения.
ну как-же — это ведь цикл. Или под-программа.
если вы пишите программу то это выглядело где-то так:
100 СТАРТ
101 1 команда
102 2 команда
103 call к 500
104 3 команда
…
500 1 команда под-программы
501…
510 return
и чтобы не замарачиваться, этот отрезок вырезался и вставлся после. Особенно, когда между частью кода и этим отрезком вставлялись другие команды. Простая экономия времени. тогда не было Visual Studio :)
А ещё был Форт. Одно из первых моих соприкосновений с ИИ.
Фортран был моим первым языком, потом Ассемблер. Фортран — это был один из языков, который придерживался строгих правил. Да, и с ним человек мог совершить кучу ошибок. Но сам язык — в своей сущности можно с ассемблером сравнить. По строгости, по типизации данных, невозможности сваливать всё в кучу. И многие, кого я знал и владеющие Фортраном — думали и решали задачи совсем по другому, чем те поколения, которое начинали/ют на Pascal, Basic, C++, Java, Phyton итд. Это было ещё время инженеров. А у инженеров совсем другой подход ко многим вещям. А начиная с Фортрана или Ассемблера — потом и на «простых» языках совсем по другому программируешь.
Инженерный подход к языкам имел свой отвечаток на качество, документацию итд. Никого не хочу обидеть. Не имею в виду отдельных лиц- а именно массовое проявление. По своей сути — сейчас шлёпают программы, не пишут. Потому что знают — совсем на маленький промежуток времени. Поэтому и не стоит сильно над этим корпеть. И это стало массовой культурой — не создавать архитектуру, до миллимитра доводить всё и поддачивать. Нет. Дешовое или сырое — ничего, пользователь проглотит. А подавится — тоже ничего. Сошлёпаем новую версию.
Спасибо за то, что перенесли мыслями в очень интересные времена.
Я с Вами соглесен, "… можно проект обвешывать..", но это никто не делает. Почему? Не знают-ли или не хотят? Наверное первое. Но от этого не меняется суть. Это совсем не инженерный подход. Тяп-ляп. И так сойдёт. Да, и в таких Agile проектах находятся проффессионалы, которые и в таких условиях совершают чуда. Но это больше исключение из правил.
… покажите мне хоть одну формулу в Agile. Для посдчёта чего-нибудь. Вы возьмёте кучу книг и не увидите ни одного расчёта. Ни о чём. В этом и заключается беда, что это просто теория, завёрнутая в конечно-же хорошую обёртку. И работает только там, где или сама ситуация не так уж и сложная или если вопреки всем усилиям находятся пару, которые вытягивают «проект» на боллее менее нормальное положение. В остальных случаях — обречено на успех провал. Хотя конечно-же с видоизменением этого самого Agile на что-нибудь подходящее и работающее — конечно-же можно чего-нибудь и добиться. Но тогда — с Agile это имеет мало чего общего.
Не соглашусь с этим выражением. Боль - это не мотивация. Боль - это основа страха. За сохранение жизни, за сохранение статуса итд. И как отдельный индивидум справляется со своим страхом - начальнику часто не понять, тк. это целая наука. может быть кто-то в страхе найдёт источник для мотивации, но это не гарантировано. Поэтому, я-бы не ставил знак равенства.
Про перестановку - соглашусь. Но Ваше первое и последнее заявления не разделяю.
В название сказано - самый быстрый алгоритм. Там ничего не сказано про "должен он быть общего назначения". И не знаю как у других, но я сортирую больше всего числа. Поэтому и беру для этого Countingsort, т.к. разница по скорости сортировки даже с Timsort раз в 10. И для многих, кто впервые сталкивается с таким заголовком - начинают верить, что оно так и есть.
И не понимаю, в чём Вы не согласны с моим выражением " заголовок и правда не соответствует содержанию". Если заголовок уточнить условиями, которые описали Вы, то да, мой пример не подходил-бы. Не люблю, когда неточно выражаются, а потом это приводит к непониманию - "иди, мол сделай вон то и не делай вид, что не понимаешь..."
а в этих методиках куда ни глянь - всё надуманно, всё возведено в статус "не поддаётся оспариванию", за основу берётся выдуманное или нереальное поведение людей. Люди в своём начале ленивые, хитрые, алчные, преследующие свои цели, а не цели каких-то дядей. Конечно никто не будет хотеть брать на себя ответственность. Зачем она нужна, если это не восполняется и не оплачивается дополнительно. По мне agile - это совок. Никто ни за что не отвечает, всё общее, а значит - зачем выпендриваться - будь как все, ведь на фоне всех никто и не увидит твою ненужность. Качество? Да кому оно нужно, ведь работает как-нибудь, сроки просчитывать и исполнять - себя не уважать. А всё почему? Да потому что нет никакой ответственности за весь этот бардак. Ни product owner, ни scrum master, ни отдельные участники всяких там squad(ов) - никто ни за что не отвечает. Ни за костыльную архитектуру, ни за плохое качество, ни за отсутвие документации, ни за говно-код, ни за срыв сроков итд. - никто и ни за что не отвечает. Но в теории - методика классная. Всё может, всё обещает..
Это- надо-ж так - целую науку Project Management с формулами, с огромным багажем работающих механизмов снесли за раз и взамен предлагают только в теории работающие представления.
Нет, сопротивление бесполезно. Это как религия. Если это в головах, то никакое логическое обоснование не помогает. И потери как финансовые, так и по времени и качеству игнорируют как непоказательные. И весь менеджмент должен свой сук сами себе пилить и видоизменять всю иерархию на agile. И доказательство, что это плохо или хорошо лежит не на тех, кто с этими agile методами пришли, а те должны доказывать, кто в этом не уверен. Т.е. не тот должен доказыват, кто утверждает, что бог существует, а тот, кто в его существование не верит...А как это сделать, если это невозможно в принципе.
чел, ты крут. Можно я переведу всё твоё высказывание на нац. язык (живу в Европе) и отправлю своему шефу или многим шефам. т.к. при агиле их у нас тьма. Все какие-то owner(ы), но ничего не происходит, кроме того, что ты в краткой и ёмкой форме описал.
Не соглашусь с оценкой, что по быстроте один из самых быстрых. да, может быть Нотация Big O для Timsort O(n log n), но эта нотация говорит только о поверхностном анализе. Детали кроятся в другом.
Если речь идёт о числах, то алгоритму Countingsort нет равных. Если речь идёт об строковых значениях, то в алгоритме Timsort элементы перставляются очень большое (из перспектив других алгоритмов - ненужное) количество раз, если изначальная ситуация значений из average case/worst case. А перестановка строк - очень интенсивная операция. Сравнение тоже, но если не обращать внимание на усилия по перестановки, то можно быстро получить сюрпризы по скорости выполнения, когда задача будет отсортировать не десять значений, а например 1 миллион.
И хоть сортировка неплохая, но всё равно - заголовк не соответствует содержанию.
Пойду дальше в высказывании. В большем количестве фирм, где используется Excel, то со всеми в встроенными возможностями (vba, автоматизация) можно делать много чего, что будет получше, чем тонна всякого черезчур платного софта. Почти все бизнес процессы можно с Excel и Office оцифровать. А с пакетом Office 365 (Excel, Word, PowerPoint, Teams, OneNote, PowerBI etc.) так и вообще — все.
Кстати на примере с Excel я вижу как думают люди. Там сразу видно, если созданные ими конструкции нелогичны, сложные, часто не поддающие пониманию или последующему сопровождению или видоизменению итп. Это как своего рода визитная карточка. Мне сразу понятно, кто передо мной.
Может быть стоит обратить внимание на социальные проблемы в космосе? Например отсутствие женского начала. И его компенсировать.
Эти вами описываемые шаги были нужны и при постройки пирамид. И при постройке атомной бомбы или ракеты на марс. В этом нет ничего нового. В этом то и суть, что не изучать, опыт других, можно открывать для себя истины и думать, что это что-то новое и неизвестное. Почитайте Дейла Корнеги по управлению людьми. Его книгам больше сотни лет, а в них вы найдёте много из того с чем вы сталкиваетесь впервые. Или из того, что вы здесь упоминайте.
Спасибо за ответ. Не желаю обидеть лично вас. Но сейчас куда не "ткни палкой" — везде скрам мастера. Без технического образования, без образования в области проект менеджмента, без навыков в психологии или поведения человека. Но прошедшие н-дневные курсы. И уверенные в себе, что в состоянии воссоеденить, контролировать и довести до результата технические, специализированные и организационные задачи. При этом думающие, что все люди стремятся к одной цели. Всё это не работает от слова совсем. Только единичные случаи или тривиальные задачи. Но и то и другое часто зависит не от навыков скрам мастера а от ситуации или уже установившейся культураы, подходящего психоттипа команды, как выше уже упомянул- от тривиальности задачи, ну и пару других исходный параметров. Проект менеджмент- это наука, которую нельзя за два дня прослушки взять и владеть. Потому что всё, что не было выучино, будет с командой на личном опыте пережито… И по большей части это будут ошибки. Как-бы этого не хотелось.
если вы пишите программу то это выглядело где-то так:
100 СТАРТ
101 1 команда
102 2 команда
103 call к 500
104 3 команда
…
500 1 команда под-программы
501…
510 return
и чтобы не замарачиваться, этот отрезок вырезался и вставлся после. Особенно, когда между частью кода и этим отрезком вставлялись другие команды. Простая экономия времени. тогда не было Visual Studio :)
А ещё был Форт. Одно из первых моих соприкосновений с ИИ.
Фортран был моим первым языком, потом Ассемблер. Фортран — это был один из языков, который придерживался строгих правил. Да, и с ним человек мог совершить кучу ошибок. Но сам язык — в своей сущности можно с ассемблером сравнить. По строгости, по типизации данных, невозможности сваливать всё в кучу. И многие, кого я знал и владеющие Фортраном — думали и решали задачи совсем по другому, чем те поколения, которое начинали/ют на Pascal, Basic, C++, Java, Phyton итд. Это было ещё время инженеров. А у инженеров совсем другой подход ко многим вещям. А начиная с Фортрана или Ассемблера — потом и на «простых» языках совсем по другому программируешь.
Инженерный подход к языкам имел свой отвечаток на качество, документацию итд. Никого не хочу обидеть. Не имею в виду отдельных лиц- а именно массовое проявление. По своей сути — сейчас шлёпают программы, не пишут. Потому что знают — совсем на маленький промежуток времени. Поэтому и не стоит сильно над этим корпеть. И это стало массовой культурой — не создавать архитектуру, до миллимитра доводить всё и поддачивать. Нет. Дешовое или сырое — ничего, пользователь проглотит. А подавится — тоже ничего. Сошлёпаем новую версию.
Спасибо за то, что перенесли мыслями в очень интересные времена.
успехпровал. Хотя конечно-же с видоизменением этого самого Agile на что-нибудь подходящее и работающее — конечно-же можно чего-нибудь и добиться. Но тогда — с Agile это имеет мало чего общего.