Люблю публикации от студентов на тему того, что их как-то не так учат, не тому учат, не так оценивают и вообще, всё против них.
В конце концов вся система образования направлена на самих студентов, они клиент, и выгодополучатель этой системы, поэтому мнение "объекта" обучения вдвойне/втройне/вдесятеро ценно.
К сожалению, образование, - очень консервативная по своей природе система, любое изменение в ней проходит с большим трудом, преодолевая множество препон. А попытка форсировать перемены сделает только в разы хуже. Поэтому гениальные мысли студента, о том, как его следует обучать, в лучшем случае будут применены уже после того как он получит диплом, точно не раньше, может даже когда он на пенсию выйдет.
Решение? Появление университета созданного студентами для студентов. Есть опасность что это превратится в бесконечную СтудВесну, но попытка - не пытка, вдруг получится. У нас же есть какая-то молодёжная ООН (а тут будет молодёжное министерство образования, с блекджеком). А там рынок порешает.
Согласен, с вектором мысли. Действительно появление гибких методологий сняло целый ряд трудностей. Брукс это признаёт в 19 главе.
Самая большая ошибка в концепции «Создавать так, чтобы потом выбросить» заключается в том, что она неявно исходит из классической последовательной, или водопадной, модели сборки ПО.
Глава 11 — не единственная испорченная последовательной водопадной моделью; эта ошибка проходит через всю книгу, начиная с правила планирования временного графика в главе 2
А в главе 16, где рассматриваются кандидаты в серебряные пули, об этом тоже упоминается в пункте «уточнение требований и быстрое прототипирование»:
В задаче сборки программного обеспечения одним из наиболее многообещающих современных технологических усилий, которое затрагивает существенные, а не случайные признаки, является разработка подходов и инструментов для быстрого прототипирования систем как части итеративного процесса разработки спецификаций.
Конечно книга эта не червонец, чтобы нравится всем, и в ней есть спорные, а есть неактуальные моменты. Почему её превозносят? За всех не отвечу, скажу за себя.
Я нашёл в ней ответы на некоторые вещи которые мне были непонятны. Например, мне было непонятно почему при найме многие гоняются за некими soft scills (я всегда относился несерьёзно, в духе, лишь бы код писать умели, ведь мы пришли работу работать, а не отношения выстраивать), а микросервисная архитектура стала предметом хайпа.
У Брукса нашёл ответ в виде объяснения, что ахиллесова пята - эта взаимодействие между людьми, соответственно, что бы взаимодействие шло как по маслу нужны те самые софт скилы, а чтобы взаимодействия было меньше, нужно раздробить проект, и пусть над каждым микросервисом работает хоть по одному человеку - лишь бы внешний контракт исполнил.
Более того, можно попытаться использовать это утверждение чтобы заглянуть в будущее. Что станет предметом хайпа после микросервисной архитектуры предсказать не берусь, а вот стереотип о том, что программисты это какие-то интроверты которые угрюмо сидят в своих тёмных подвалах, плавно сменится (и уже проделал огромный путь) стереотипом, что это наоборот, такой человек-тамада, ибо софт скиллы зашкаливают.
Идея не нова, может кому-то она очевидна и без Брукса.
Но это устаревший ГОСТ, я сослался на другой (его замену), в котором «как правило» убрали. И «как правило» не относится к расположению осей абсцисс/ординат, а только к направлению положительных/отрицательных величин. Оба раза мимо.
"Следует" и "рекомендует" не синонимы, как бы не хотели видеть обратное. Но даже если «рекомендует» это ли не Coding Сonventions?!
Я так понял, что могу сослаться на тысячу ГОСТов, но Вас это не убедит, «потому что гладиолус»?
ГОСТ Р 50-77-88 ЕДИНАЯ СИСТЕМА КОНСТРУКТОРСКОЙ ДОКУМЕНТАЦИ И ПРАВИЛА ВЫПОЛНЕНИЯ ДИАГРАММ
1.2. В прямоугольной системе координат независимую переменную следует откладывать на горизонтальной оси (оси абсцисс), положительные значения величин следует откладывать на осях вправо и вверх от точки начала отсчета
Т.е. ГОСТ проводит однозначное соответствие между горизонтальной осью и осью абсцисс. Правила есть!
Будьте добры процитируйте, что именно в пункте 1.4. натолкнуло Вас на эту мысль?
1.4. В прямоугольной системе координат положительные значения величин откладывают на осях, как правило, вправо и вверх от точки начала отсчета. В диаграмме без шкал оси координат следует заканчивать стрелками, указывающими направления возрастания значений величин. Допускается применять такие стрелки также и в диаграммах со шкалами—за пределами шкал или самостоятельные стрелки после обозначения величины — параллельно оси координат. В полярной системе координат положительное направление угловых координат должно соответствовать направлению вращения против часовой стрелки.
Это самые сложные моменты, потому что там нужно поддержать баланс между авторитетом учителя и обидой ученика, которого не убедили. А убеждать детей, пользуясь мышлением детей — это как переговоры с инопланетянами.
Самодурство это игнорировать принятые соглашение под соусом: «нет никаких правил», «не всегда удобно», «если не вводил такого требования», «нет особых причин».
А в наличии соглашения откладывать по горизонтальный оси абсциссу, я почему-то не сомневаюсь.
Давайте, чтобы Вы не придирались к примеру, сформулирую свою точку зрения с другого ракурса.
Существуют Coding Сonventions, они появились не просто так. В данном случае автор их нарушил, нарушил грубо, за что его попросили переделать график. И правильно сделали.
Да вы можете апеллировать к тому что «компилятор же съел», если продолжать аналогию с Coding Сonventions. Но работает он с людьми а не с компиляторами, поэтому «дорогой коллега, будь добр не создавай мне тестов на внимательность».
Ну я же не просто так привёл пример. 146% процентов, что где-то, что-то было прописано, в каких-нибудь документах, да ещё и 100500 раз. Думаете нет? В чём же была проблема?!
Не удивлюсь, если разработчики потом ходили, пожимали плечами, и говорили: «ну видно же что не СИ», возможно даже с искренним недоумением.
На первом курсе университета я взял за горизонтальную ось значение ординаты, потому что так график лучше помещался на листе. При том, что он был полностью правильный, работу мне пришлось переписывать.
Не останавливайтесь, делайте не как у всех, и чтобы не сразу был виден подвох, Миру нужно больше историй наподобие Mars Climate Orbiter
Люблю публикации от студентов на тему того, что их как-то не так учат, не тому учат, не так оценивают и вообще, всё против них.
В конце концов вся система образования направлена на самих студентов, они клиент, и выгодополучатель этой системы, поэтому мнение "объекта" обучения вдвойне/втройне/вдесятеро ценно.
К сожалению, образование, - очень консервативная по своей природе система, любое изменение в ней проходит с большим трудом, преодолевая множество препон. А попытка форсировать перемены сделает только в разы хуже. Поэтому гениальные мысли студента, о том, как его следует обучать, в лучшем случае будут применены уже после того как он получит диплом, точно не раньше, может даже когда он на пенсию выйдет.
Решение? Появление университета созданного студентами для студентов. Есть опасность что это превратится в бесконечную СтудВесну, но попытка - не пытка, вдруг получится. У нас же есть какая-то молодёжная ООН (а тут будет молодёжное министерство образования, с блекджеком). А там рынок порешает.
А в главе 16, где рассматриваются кандидаты в серебряные пули, об этом тоже упоминается в пункте «уточнение требований и быстрое прототипирование»:
Конечно книга эта не червонец, чтобы нравится всем, и в ней есть спорные, а есть неактуальные моменты. Почему её превозносят? За всех не отвечу, скажу за себя.
Я нашёл в ней ответы на некоторые вещи которые мне были непонятны. Например, мне было непонятно почему при найме многие гоняются за некими soft scills (я всегда относился несерьёзно, в духе, лишь бы код писать умели, ведь мы пришли работу работать, а не отношения выстраивать), а микросервисная архитектура стала предметом хайпа.
У Брукса нашёл ответ в виде объяснения, что ахиллесова пята - эта взаимодействие между людьми, соответственно, что бы взаимодействие шло как по маслу нужны те самые софт скилы, а чтобы взаимодействия было меньше, нужно раздробить проект, и пусть над каждым микросервисом работает хоть по одному человеку - лишь бы внешний контракт исполнил.
Более того, можно попытаться использовать это утверждение чтобы заглянуть в будущее. Что станет предметом хайпа после микросервисной архитектуры предсказать не берусь, а вот стереотип о том, что программисты это какие-то интроверты которые угрюмо сидят в своих тёмных подвалах, плавно сменится (и уже проделал огромный путь) стереотипом, что это наоборот, такой человек-тамада, ибо софт скиллы зашкаливают.
Идея не нова, может кому-то она очевидна и без Брукса.
Действительно есть схожие моменты. Оба про распараллеливание говорят.
У Брукса всё-таки про то, что есть задачи, которые невозможно распараллелить. А у Амдала про скорость выполнения распараллеленных задач.
Закон Амдала я бы проиллюстрировал такой фразой: караван идёт со скоростью самого медленного верблюда.
Я так понял, что могу сослаться на тысячу ГОСТов, но Вас это не убедит, «потому что гладиолус»?
Т.е. ГОСТ проводит однозначное соответствие между горизонтальной осью и осью абсцисс. Правила есть!
А в наличии соглашения откладывать по горизонтальный оси абсциссу, я почему-то не сомневаюсь.
Существуют Coding Сonventions, они появились не просто так. В данном случае автор их нарушил, нарушил грубо, за что его попросили переделать график. И правильно сделали.
Да вы можете апеллировать к тому что «компилятор же съел», если продолжать аналогию с Coding Сonventions. Но работает он с людьми а не с компиляторами, поэтому «дорогой коллега, будь добр не создавай мне тестов на внимательность».
Не удивлюсь, если разработчики потом ходили, пожимали плечами, и говорили: «ну видно же что не СИ», возможно даже с искренним недоумением.
Не останавливайтесь, делайте не как у всех, и чтобы не сразу был виден подвох, Миру нужно больше историй наподобие Mars Climate Orbiter
Цена, мягко говоря, кусачая. К вам Тони Роббинс приезжает?