еще забыли «Final Fantasy: Spirits Within» 2001 года выпуска с их интерфейсами-голограммами с обратной тактильной связью. Их бы я поставил до «Особого Мнения», да и «Особое мнение» не стал бы называть следующим этапом, как ранее пометили, из-за «Джонни Мнемоника»
Оставлю эту ссылку здесь. В первой главе (там страниц 10-20, не больше) сможете почитать о том, а какая вообще бывает аргументация в пользу или против аспирантуры. Может это и не прямой ответ на ваш вопрос, но дополнительную информацию к размышлению вам даст. Рекомендую для прочтения каждому аспиранту или тому, кто им хочет стать. Да и весь сайт/блог весьма полезен и интересен в этом отношении, хотя материал подан и не с точки зрения IT, а радиотехники/радиоэлектроники в силу специфики нашего вуза.
>Мне казалось нерациональным тратить экранное время на процесс записывания профессором формулы на доске мелом. Однако, опросив знакомых, я к удивлению обнаружил, что многим это нравится, так как они успевают тогда прочувствовать начертанное.
Мы ощутили разницу на курсе высшей математики у нас в вузе: первый семестр лекции проводились с проектором, и мы 1) просто не успевали их писать, пока препод быстро объяснял, что это всё значит 2) ни черта не понимали, так как пока пишешь формулы — пропускаешь все пояснения препода.
Второй семестр препод всё писал на доске, и это давало надо время как и переписать, так и обдумать написанное.
В лекциях с проектора вижу две проблемы (которые в принципе не сложно решить при их составлении): 1) информация на слайдах вываливается дискретными кусками, в отличии от доски, где материал пишется последовательно, и также последовательно с доски исчезает 2) время, уходящее на пояснение слайда преподавателем меньше, чем время, необходимое на его осознание студентами (для доски ситуация опять же более благоприятна студентам)
>Профит: разработчик более вовлечен и мотивирован: ему надо просто предупредить исполнителей о том, что неприменимо в новом (или измененном) интерфейсе, на его взгляд и по его опыту.
По-моему, стоит выделить слово «что», а не «неприменимо».
Статья верная, проблема решается путём объяснения разработчикам важности ТЗ и соответствия проекта оному (возможно, с угрозами неоплаты того рабочего времени, что ушло на переделку из-за незнания ТЗ). На чётко сформулированном ТЗ строится всё тестирование (из литературы по тестированию, кстати, можно многое узнать о том, как писать ТЗ), иначе как проверять продукт, если нет четкого понятия о том, какой он должен быть?
С другой стороны, всегда нужно у разработчиков узнавать, чего им не хватало в ТЗ, или вообще удобно ли им работать с ТЗ в той форме, в которой вы им её предлагаете. Имхо, ТЗ пишется именно для разработчиков, а значит, ТЗ должно быть удобно и понятно для них
Как показывает практика отношений на работе, если сам не позвонишь и не уточнишь — то можешь результатов и не дождаться. Это я и моя работа нуждается в результатах от Иванова, и зачастую подобные «Ивановы» могут сделать поручение, но забыть переслать результаты, или же вообще не сделать поручения/просрочить. А например, как менеджер, я должен контролировать происходящее.
К сожалению, но приходиться работать не в совершенном мире
Интересный подход, избавляет от нудного раскидывания задач по дням/часам/неделям (только по этой причине, наверно, я не могу принять какую-либо систему тайм-менеджмента).
Но если задачу на 3 минуты можно выполнить ни когда угодна, а только после определенного времени/события. Например, звонок Иванову нужно сделать тогда, когда он доделает какое-то своё задание и передаст тебе результаты? Логично, что я не могу позвонить ему сейчас, потому что он доделает через неделю. А значит, минимальное планирование/раскидывание задач (хотя бы по дням) должно присутствовать, вместо простого списка задач с сортировкой по времени выполнения.
Для тех, кто не принимает советы Архангельского, советую к прочтению статью Ивана Пирога. По крайней мере интересные мысли почерпнуть можно.
Скролл определенно лучше. Если на него еще подвесить навигацию по странице для быстрого перехода (где статья начинается, где начинаются комментарии, и где на этой странице новые комментарии) — больше ничего и не надо
Да, соглашусь (и с постом, и с комментарием). В нашем вузе философия преподавалась два семестра, один из которых был полностью посвящен истории философии, и только второй проблемам философии. Не могу сказать, что история философии была для нас бессмысленна (это же не просто история, а «эволюция» человеческого мышления), однако, учитывая количество времени, отведенного на данную дисциплину, лучше было бы посвятить время именно проблемам.
Вики — всего лишь механика, реализация. Статьей я хотел обратить внимание не на реализацию, а на сами средства, позволяющие пользователю удобнее работать с блогом
Мы ощутили разницу на курсе высшей математики у нас в вузе: первый семестр лекции проводились с проектором, и мы 1) просто не успевали их писать, пока препод быстро объяснял, что это всё значит 2) ни черта не понимали, так как пока пишешь формулы — пропускаешь все пояснения препода.
Второй семестр препод всё писал на доске, и это давало надо время как и переписать, так и обдумать написанное.
В лекциях с проектора вижу две проблемы (которые в принципе не сложно решить при их составлении): 1) информация на слайдах вываливается дискретными кусками, в отличии от доски, где материал пишется последовательно, и также последовательно с доски исчезает 2) время, уходящее на пояснение слайда преподавателем меньше, чем время, необходимое на его осознание студентами (для доски ситуация опять же более благоприятна студентам)
по-моему, здесь корректнее перевести не «дизайна», а «проектирования»
По-моему, стоит выделить слово «что», а не «неприменимо».
Статья верная, проблема решается путём объяснения разработчикам важности ТЗ и соответствия проекта оному (возможно, с угрозами неоплаты того рабочего времени, что ушло на переделку из-за незнания ТЗ). На чётко сформулированном ТЗ строится всё тестирование (из литературы по тестированию, кстати, можно многое узнать о том, как писать ТЗ), иначе как проверять продукт, если нет четкого понятия о том, какой он должен быть?
С другой стороны, всегда нужно у разработчиков узнавать, чего им не хватало в ТЗ, или вообще удобно ли им работать с ТЗ в той форме, в которой вы им её предлагаете. Имхо, ТЗ пишется именно для разработчиков, а значит, ТЗ должно быть удобно и понятно для них
К сожалению, но приходиться работать не в совершенном мире
Но если задачу на 3 минуты можно выполнить ни когда угодна, а только после определенного времени/события. Например, звонок Иванову нужно сделать тогда, когда он доделает какое-то своё задание и передаст тебе результаты? Логично, что я не могу позвонить ему сейчас, потому что он доделает через неделю. А значит, минимальное планирование/раскидывание задач (хотя бы по дням) должно присутствовать, вместо простого списка задач с сортировкой по времени выполнения.
Для тех, кто не принимает советы Архангельского, советую к прочтению статью Ивана Пирога. По крайней мере интересные мысли почерпнуть можно.
Спасибо, буду думать :)