Подавляющее большинство хомячков, как вы называете обычных людей, вообще не смотрят на нанометры. Они просто покупают те процессоры, которые лучше по основным параметрам (цена/производительность/энергопотребление). Сейчас это вот сочетание не в пользу Интел.
По маректинговым параметрам для «хомячков» Intel как раз превосходит AMD.
В чем принципиальная разница спрашивать у разработчиков сроки в попугаях или часах? Те же самые 1 час — 2 часа — 8 часов — 2-3 дня. Время, естественно, не точное, а примерное.
Вы же все равно, как разработчик, будете оценивать задачу для себя в часах — попробуете вспомнить, сколько делали похожую задачу раньше. Представьте, что Вы попали в новую фирму, где используются те самые попугаи. Как Вы будете оценивать свою первую задачу? Скорее всего попросите у руководителя таблицу перевода попугаев в часы конкретно в этой команде этой конторы. Но зачем это промежуточное число, когда можно не переводить ничего никуда и остаться в примерном времени?
Судя по статье автора — чтобы у Вас не было ограничения по времени. Но тогда и делать одну задачу Вы будете вечно.
1. А почему точность оценки сложности у программиста будет выше, чем точность оценки сроков? И какая разница спрашивать сколько в часах или сколько в попугаях, если перевод из одного во второе осуществляется умножением на константу?
2. Соглашусь с Вами, этот вопрос наверное неуместен. Фрилансер должен быть сам себе менеджер.
3. и 4.
Я согласен с Вашими доводами. Но это очень сильно похоже на scrum, но только без спринтов. Главный вопрос: в Вашем описании сроки все таки есть, мы от них не отказываемся, чтобы планировать, чтобы следить за результатом и пр. Но мы скрываем эти сроки от разработчика. И для разработчика происходит именно то, что и должно по закону Паркинсона (в том виде, в котором этот закон представлен в статье) — задача займет столько, сколько на неё есть времени, а время оказывается не ограничено и задачи перестанут завершаться совсем.
То есть моя мысль: или закон Паркинсона не работает, или он работает, но тогда отсутствие ограничения по времени для разработчика должно превращать все задачи в бесконечные.
1.1 Возможно я и правда чуть передергиваю в своем вопросе. Считаю что такая эмоциональная окраска уместна.
1.2 Про примерный срок: нет, автор явно пишет:
… отсутствует их причина – планирование работы программиста и попытки, так или иначе, оценить сроки исполнения работ ...
под так или иначе я понимаю что в подходе автора сроки никак не оцениваются. Я бы не стал писать комментарий, или писал бы совершенно другой, если подход подразумевал примерную оценку сроков. Но он основан на полном отсутствии оценки, что вызывает вопросы.
2. То определение, которое дали Вы — это определение потока как психического состояния. В статье термин поток употребляется в другом смысле, как один из методов планирования. Я сделал такой вывод из следующих фактов:
Автор сам дает определение этому методу:
Поток – это когда есть только скорость. Задачи выстраиваются в очередь, программист садится и решает одну за другой.
Автор дает классификацию методов планирования, в которой поток ставится в один ряд с такими методами как Lean, Scrum
Как мне кажется очевидно, что в статье описан поток, как метод планирования, а не как психическое состояние. Но, возможно, я сделал неправильные выводы.
3. Возможно. Свои предположения по этому поводу я описал в п. 2.
4. Да, своевременность исполнения подходит как критерий к тому вопросу, который я описал, спасибо. Но это не отменяет вопроса — если я не оцениваю сроки, я не могу оценить задачу по этому критерию.
готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности
А не:
готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности, если его метод подходит этому коллективу, а если не подходит то там дальше искусство и может не x2, а x0.5 получится, как пойдет.
Доброго времени суток! Идея описана интересная, но совершенно не понятно, как её применять в жизни. Не могли бы Вы ответить на несколько вопросов?
1. Вы пишите:
Поток – это когда есть только скорость. Задачи выстраиваются в очередь, программист садится и решает одну за другой. Сроки не известны, но их можно вычислить – зная скорость и номер задачи в очереди. Главное – не озадачивать вычислением срока самого программиста.
Как вычислить эти сроки? Дано: скорость и порядковый номер задачи, но мы же отказались от того, чтобы считать сроки на каждую задачу. То есть не важно, задача первая или пятая, если я не знаю, сколько уйдет времени на каждую, мне никак порядковый номер не поможет.
2. Представьте, что Вы придумали проект/идею и нанимаете фрилансера. Час его работы стоит 100$. Вы описываете задачу, и, наверное, хотите узнать, сколько он будет её делать. Но у него поток, он отвечает, что он, вообще-то, творец и сроки будут такие, какие будут. И в процессе работы не отвлекайте его, на «митинги». Он сам напишет, когда закончит. При этом у Вас есть бюджет и сроки, и если Вы за них выйдете — решение задачи не имеет смысла. Что делать?
3. У Вас N команд, каждая занимается своей областью. Итоговый продукт — совокупность результатов работы всех команд. Некоторые вещи можно делать внутри команды, некоторые основываются на результатах работы смежных команд. У всех поток. Команда 1 приступает к выполнению задачи, которая зависит от артефактов работы команды 2. Но у тех был поток и они еще не сделали. Хорошо, команда 1 делает что-то другое (менее важное и не приоритетное). Команда 2 доделала, что хотела и начала делать что-то другое. Команда 1 тоже доделала свое не такое важное дело, вернулась и поняла, что есть вопросы (нужна помощь с тем, чтобы разобраться, как работают артефакты команды 2). Но команда 2: уже куда-то переключилась, забыла в чем там было дело, да и из потока выходить тяжело — идет другая задача. Не понятно, как синхронизировать работу N команд если мы отказываемся от планирования?
4. Похоже, что методом потока убирает критерий «скорости» при выборе решений. Многие задачи можно решить большим количеством разных способов, например: в процессе реализации разработчик решил, что новую функцию можно встроить в существующую кодовую базу (чего он делать не любит, потому что «там надо разбираться», «legacy» и т. д.), а можно все переписать, чтобы было красиво, удобно и так, как он захочет. И программист выберет второе. Мы же не спрашивали у него сроки, он ничего не обещал нам, вопрос случился уже в процессе работы и он исходя из тех данных, что у него были выбрал то, что считал лучшим решением, при этом увеличив время реализации в 5-10 раз. Как выбирать решения на основе скорости их реализации, когда мы не оцениваем сроки?
VHDL мы упомянем в обзоре языков, но на этом все. Мы считаем, что начинать следует с SystemVerilog.
На эту тему мы говорим во второй лекции: сравниваем языки, обсуждаем плюсы и минусы каждого.
Да, такие варианты есть. Но даже там сейчас свободных мест на запись до сентября нет, а если появляются — сразу пропадают. Так что нужно мониторить и как-только появятся — записываться. Но чтобы успеть это сделать — нужно заранее оплатить визовый сбор в нужной стране. То есть сначала нужно выбрать страну, где делать, оплатить визовый сбор, заполнить анкету и ждать, когда появятся подходящие даты (которые могут и не появится) + есть сложности, с тем, чтобы находиться в этой стране, пока виза будет оформляться.
Спасибо за поздравления! Правда конкурс продолжается, следующий этап — Grand Final, который будет проходить в Америке, и куда мы получили приглашение, но попасть туда и представлять наш проект там скорее всего не сможем (оказывается, за месяц получить визу в Америку — задача почти невозможная).
Добрый день! Ну не совсем Метротек. Команда EM077 состоит из трех людей, двое из которых сотрудники Метротека (я и 1an1 ). Но выступаем мы там как студенты ИТМО.
В статье поднят правильный вопрос про универсальность HDL, но, как мне кажется, подход к его раскрытию совсем неправильный. У вендоров есть специальная документация, по тому, как писать HDL код так, чтобы результат был предсказуемым, например:
Конкретно эти ссылки только для примера. Но статья про то, какие есть в этих рекомендациях различия, почему они есть и самое главное — выводы о том, как писать HDL код так, чтобы он удовлетворял и тем и другим рекомендациям была бы намного более полезной, чем выводы:
для правильного описания аппаратуры необходимо знать синтаксис языка
Не совсем понятен ход Вашего эксперимента на ПЛИС. Не могли бы Вы чуть поподробнее рассказать, как именно была реализована эмуляция бистабильных элементов? Как я понял это не просто инстанс блочной памяти, а какая-то более хитрая конструкция?
На графике по оси X — на сколько процентов мы на данном шаге пытаемся заполнить таблицу, то есть 100% — это когда мы попытались добавить туда 1048576-ой уникальный элемент. По оси Y — то, на сколько таблица на данном шаге заполнена и 33% означают, что в ней примерно 346000 записей. В общем да, из всех попыток записи 66% процентов закончились коллизией.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Я часто для таких целей использую tmate: https://tmate.io/
Очень простая в использовании утилита. Получается полноценный опыт парного программирования. Очень советую.
Но это противоречит высказыванию, на которое я отвечаю:
По маректинговым параметрам для «хомячков» Intel как раз превосходит AMD.
Основные отличия:
Я что-то не то сравниваю? Или +10к только за gen 4.0 (и отсутсвие встроенного видео и ухудшения других характеристик) это выгодно? Мне так не кажется.
Вы же все равно, как разработчик, будете оценивать задачу для себя в часах — попробуете вспомнить, сколько делали похожую задачу раньше. Представьте, что Вы попали в новую фирму, где используются те самые попугаи. Как Вы будете оценивать свою первую задачу? Скорее всего попросите у руководителя таблицу перевода попугаев в часы конкретно в этой команде этой конторы. Но зачем это промежуточное число, когда можно не переводить ничего никуда и остаться в примерном времени?
Судя по статье автора — чтобы у Вас не было ограничения по времени. Но тогда и делать одну задачу Вы будете вечно.
2. Соглашусь с Вами, этот вопрос наверное неуместен. Фрилансер должен быть сам себе менеджер.
3. и 4.
Я согласен с Вашими доводами. Но это очень сильно похоже на scrum, но только без спринтов. Главный вопрос: в Вашем описании сроки все таки есть, мы от них не отказываемся, чтобы планировать, чтобы следить за результатом и пр. Но мы скрываем эти сроки от разработчика. И для разработчика происходит именно то, что и должно по закону Паркинсона (в том виде, в котором этот закон представлен в статье) — задача займет столько, сколько на неё есть времени, а время оказывается не ограничено и задачи перестанут завершаться совсем.
То есть моя мысль: или закон Паркинсона не работает, или он работает, но тогда отсутствие ограничения по времени для разработчика должно превращать все задачи в бесконечные.
1.2 Про примерный срок: нет, автор явно пишет:
под так или иначе я понимаю что в подходе автора сроки никак не оцениваются. Я бы не стал писать комментарий, или писал бы совершенно другой, если подход подразумевал примерную оценку сроков. Но он основан на полном отсутствии оценки, что вызывает вопросы.
2. То определение, которое дали Вы — это определение потока как психического состояния. В статье термин поток употребляется в другом смысле, как один из методов планирования. Я сделал такой вывод из следующих фактов:
Как мне кажется очевидно, что в статье описан поток, как метод планирования, а не как психическое состояние. Но, возможно, я сделал неправильные выводы.
3. Возможно. Свои предположения по этому поводу я описал в п. 2.
4. Да, своевременность исполнения подходит как критерий к тому вопросу, который я описал, спасибо. Но это не отменяет вопроса — если я не оцениваю сроки, я не могу оценить задачу по этому критерию.
А не:
готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности, если его метод подходит этому коллективу, а если не подходит то там дальше искусство и может не x2, а x0.5 получится, как пойдет.
1. Вы пишите:
Как вычислить эти сроки? Дано: скорость и порядковый номер задачи, но мы же отказались от того, чтобы считать сроки на каждую задачу. То есть не важно, задача первая или пятая, если я не знаю, сколько уйдет времени на каждую, мне никак порядковый номер не поможет.
2. Представьте, что Вы придумали проект/идею и нанимаете фрилансера. Час его работы стоит 100$. Вы описываете задачу, и, наверное, хотите узнать, сколько он будет её делать. Но у него поток, он отвечает, что он, вообще-то, творец и сроки будут такие, какие будут. И в процессе работы не отвлекайте его, на «митинги». Он сам напишет, когда закончит. При этом у Вас есть бюджет и сроки, и если Вы за них выйдете — решение задачи не имеет смысла. Что делать?
3. У Вас N команд, каждая занимается своей областью. Итоговый продукт — совокупность результатов работы всех команд. Некоторые вещи можно делать внутри команды, некоторые основываются на результатах работы смежных команд. У всех поток. Команда 1 приступает к выполнению задачи, которая зависит от артефактов работы команды 2. Но у тех был поток и они еще не сделали. Хорошо, команда 1 делает что-то другое (менее важное и не приоритетное). Команда 2 доделала, что хотела и начала делать что-то другое. Команда 1 тоже доделала свое не такое важное дело, вернулась и поняла, что есть вопросы (нужна помощь с тем, чтобы разобраться, как работают артефакты команды 2). Но команда 2: уже куда-то переключилась, забыла в чем там было дело, да и из потока выходить тяжело — идет другая задача. Не понятно, как синхронизировать работу N команд если мы отказываемся от планирования?
4. Похоже, что методом потока убирает критерий «скорости» при выборе решений. Многие задачи можно решить большим количеством разных способов, например: в процессе реализации разработчик решил, что новую функцию можно встроить в существующую кодовую базу (чего он делать не любит, потому что «там надо разбираться», «legacy» и т. д.), а можно все переписать, чтобы было красиво, удобно и так, как он захочет. И программист выберет второе. Мы же не спрашивали у него сроки, он ничего не обещал нам, вопрос случился уже в процессе работы и он исходя из тех данных, что у него были выбрал то, что считал лучшим решением, при этом увеличив время реализации в 5-10 раз. Как выбирать решения на основе скорости их реализации, когда мы не оцениваем сроки?
На эту тему мы говорим во второй лекции: сравниваем языки, обсуждаем плюсы и минусы каждого.
Добрый день! Ну не совсем Метротек. Команда EM077 состоит из трех людей, двое из которых сотрудники Метротека (я и 1an1 ). Но выступаем мы там как студенты ИТМО.
В статье поднят правильный вопрос про универсальность HDL, но, как мне кажется, подход к его раскрытию совсем неправильный. У вендоров есть специальная документация, по тому, как писать HDL код так, чтобы результат был предсказуемым, например:
Конкретно эти ссылки только для примера. Но статья про то, какие есть в этих рекомендациях различия, почему они есть и самое главное — выводы о том, как писать HDL код так, чтобы он удовлетворял и тем и другим рекомендациям была бы намного более полезной, чем выводы: