Ответ героя поста хабровчанам:
" Перед чтением, я извинения за ужасно коверкая русский язык. Я не говорю это (пока), но все еще хотел бы сказатьнесколько вещей.
Во-первых, спасибо за все положительные комментарии, они действительно делают мой день.
— Я читал комментарии, используя Google Translate и, возможно, неправильно некоторые из них, но я считаю, что было некоторое замешательство о мне упомянуть SourceTree. Я использую командную строку для многих вещей, в том числе и Git Mercurial. Я просто хотел, чтобы использовать программу, люди будут распознавать, но его не то, что я хотел бы использовать часто. Это хорошо для " конфликтов слияния ", но это очень раздражает, чтобы исправить с помощью SourceTree так что я обычно использую командную строку.
— В-третьих, и финал, позвольте мне поблагодарить переводчика для перевода свой пост. Мы будем иметь водку вместе, если вы когда-либо в Нидерландах:"
На интервью попросился студент, у которого очень серьезные проблемы со зрением. Ни текста, ни картинок он не видит. Может быть видит какие-то общие очертания больших объектов (типа человека, машины и т.д.), но не уверен (спрашивать не удобно). Для меня это было удивительно, как человек с такой патологией может эффективно взаимодействовать с компьютером и работать программистом. По его рассказам, если резюме было интересно и ему звонили, то как только узнавали про патологию, разговор заканчивался (такое было несколько раз). Мы все равно решили провести интервью. Сам я на собеседовании не был, но отзыв интервьюеров был положительный. На интерью, кроме общих и достаточно глубоких знаний, он спокойно писал код и решал поставленные задачи.
Сейчас он работает в моей команде. Вся работа происходит под Linux. Экранный диктор. Какое-то время назад купили дисплей Брайля (хотя этот девайс дисплеем я бы не назвал никогда, если бы мне не сказали :) ). Задачи решаются так же спокойно, как и в случае других коллег. Есть некоторые особенности при постановке и обсуждении задач. Особенно если часть функционала описана в виде картинок. Но мне кажется, что это в какой-то степени тренирует и окружающих, чтобы объяснения были не в стиле «смотри, есть вот такая фигня, она помещается вот эту штуку» и т.д., а была какая-то связная речь. :)
Ну и в целом, человек живет полноценной жизнью. Вот недавно родился второй ребенок. :) Меня, конечно, это до сих пор поражает, хотя работаем вместе уже больше года наверно.
Более того, история Нокии не заканчивается на сделке с Microsoft. Кроме мобильных телефонов (которые ушли Microsoft), есть и другие направления, которыми компания продолжает заниматься. Об этом в статье вообще нет ничего. Понятно, что широкому кругу потребителей в основном был виден бизнес мобильных телефонов, но все-таки можно было бы и это отметить. Ну и сейчас Нокиа выпускает планшеты, которые к Microsoft не имеют никакого отношения.
Я не спорю ради спора. :) Просто написал, что для вашей задачи можно найти решение (как мне кажется) с 13 шарами/монетами (как хотите) за 3 взвешивания. Вы же прикрываетесь мат. обоснованием, которое относится к другой задаче. При этом, я вполне допускаю, что вы даже не подумали о поиске возможного решения для вашей задачи с 13 шарами/монетами.
Про разницу, формулировка задачи по ссылке, для которой приводится мат. обоснование звучит следующим образом:
«Представьте себе, что на стол высыпана кучка совершенно одинаковых по виду монет, но вам сказали, что одна из этих монет — фальшивая. Она отличается от остальных монет по весу, но вам не сообщили, легче она или тяжелее. В вашем распоряжении имеются чашечные весы без гирь. Как нужно действовать, чтобы выделить эту монету и выяснить её тип (то есть узнать, легче она или тяжелее) за минимальное число взвешиваний?»
Обратите внимание на жирный текст. Его в вашей формулировке нет. Теперь, пожалуйста, подумайте над решением задачи в вашей формулировке. Есть решения для случая с 13 монетами/шарами?
Ваша задача:
«На столе лежат 12 совершенно одинаковых по виду шаров, но один из них — фальшивый. Он отличается от остальных шаров по весу (мы не знаем, легче он или тяжелее). В вашем распоряжении имеются чашечные весы без гирь. Нужно найти аномальный шар за минимальное количество взвешиваний (подсказка — решение можно найти за 3 взвешивания).»
Задача по ссылке, которую вы приводите, и где дается мат. обоснование:
«Представьте себе, что на стол высыпана кучка совершенно одинаковых по виду монет, но вам сказали, что одна из этих монет — фальшивая. Она отличается от остальных монет по весу, но вам не сообщили, легче она или тяжелее. В вашем распоряжении имеются чашечные весы без гирь. Как нужно действовать, чтобы выделить эту монету и выяснить её тип (то есть узнать, легче она или тяжелее) за минимальное число взвешиваний?»
Разницу видите? Для вашей задачи, как мне кажется, есть решение с 3 взвешиваниями и 13 монетами.
Когда прочитал «3. Четкие цели на спринт для всех участников проекта». Появилась мысль, что цели ставятся для каждого члена команды отдельно. Отсюда появился вопрос «Как обстоит дело с достижением общей цели на спринт?». И ниже читаю «Внедрение описанных выше механизимов обнажило другие проблемы: рассинхронизация команды и расфокусирование отдельных ее членов». Поэтому хотелось бы уточнить как вы до этого цели ставили? Например, Вася, ты делаешь вот это и это. Петя с тебя вот это и то. И т.д. Или это было в каком-то другом виде?
Еще был бы интересен технический момент. Контроль версий, прогон регрессии. Сколько времени это занимает? Какие уровни тестирования у вас вообще используются? На каких из них есть регрессия? Гоняется ли она для каждого изменения?
И еще комментарий насчет «С самого начала нужен хороший проектный план. Хороший — значит очень детальный: вся функциональность должна быть описана, продумана и запланирована. Очень похоже на первый этап каскадной модели.» Это же совсем не про Scrum. :) Одна из заявляемых вкусностей Scrum — это быстрая адаптация к новым требованиям, именно поэтому (как мне кажется) рисовать детальный план в начале проекта деятельность спорная. Однако, в вашем случае, как я понял, быстрая адаптация к новым требованиям не нужна, т.к. этого или совсем нет или бывает редко. Это так? Если да, то у вас получается что-то вроде Scrum в рамке водопада? И еще интересно было бы узнать как вы спецификацию пишите? Как правило вы же ее пишете до начала спринта, где будет идти разработка, или нет?
А вам действительно надо что-то показывать в конце спринта? Вы же не отдаете продукт конечному пользователю каждый спринт? Может тогда и время на это не тратить? Ведь основной момент — это понять, что конкретно было сделано за спринт, где вы находитесь, и где находится весь проект с точки зрения end-to-end продукта. Или я что-то пропустил? Это можно понять и по состоянию тест плана. Или нет?
Если вы про Нокию говорите, то фирма вполне себе существует и достаточно неплохо. Ушли только телефоны.… пока по крайней мере. Планшеты от Нокии уже есть. Может и телефоны когда-нибудь вернутся?
Если учить ребенка самому, вы представляете сколько времени надо тратить на подготовку? Или вы можете по памяти взять и выдать всю школьную программу по физике, матемитике, русскому, географии, истории, химии, и т.д. прям вот сразу?
Я не против обучения ребенка родителями, если у них к этому есть способность/желание и достаточное время. А последнего, мне кажется, надо очень много. У меня есть некий опыт чтения тренингов в своей профильной области (т.е. она связана с работой), и даже в этом случае времени на подготовку нужно достаточно много. А если говорить про какие-то направления, с которыми ты не сталкивался более десяти лет, то время на подготовку увеличивается в несколько раз. И вряд ли такое направление даже в рамках школьной программы одно.
" Перед чтением, я извинения за ужасно коверкая русский язык. Я не говорю это (пока), но все еще хотел бы сказатьнесколько вещей.
Во-первых, спасибо за все положительные комментарии, они действительно делают мой день.
— Я читал комментарии, используя Google Translate и, возможно, неправильно некоторые из них, но я считаю, что было некоторое замешательство о мне упомянуть SourceTree. Я использую командную строку для многих вещей, в том числе и Git Mercurial. Я просто хотел, чтобы использовать программу, люди будут распознавать, но его не то, что я хотел бы использовать часто. Это хорошо для " конфликтов слияния ", но это очень раздражает, чтобы исправить с помощью SourceTree так что я обычно использую командную строку.
— В-третьих, и финал, позвольте мне поблагодарить переводчика для перевода свой пост. Мы будем иметь водку вместе, если вы когда-либо в Нидерландах:"
Ссылка: twishort.com/VZxic
Твитился Vlad Gramovich
На интервью попросился студент, у которого очень серьезные проблемы со зрением. Ни текста, ни картинок он не видит. Может быть видит какие-то общие очертания больших объектов (типа человека, машины и т.д.), но не уверен (спрашивать не удобно). Для меня это было удивительно, как человек с такой патологией может эффективно взаимодействовать с компьютером и работать программистом. По его рассказам, если резюме было интересно и ему звонили, то как только узнавали про патологию, разговор заканчивался (такое было несколько раз). Мы все равно решили провести интервью. Сам я на собеседовании не был, но отзыв интервьюеров был положительный. На интерью, кроме общих и достаточно глубоких знаний, он спокойно писал код и решал поставленные задачи.
Сейчас он работает в моей команде. Вся работа происходит под Linux. Экранный диктор. Какое-то время назад купили дисплей Брайля (хотя этот девайс дисплеем я бы не назвал никогда, если бы мне не сказали :) ). Задачи решаются так же спокойно, как и в случае других коллег. Есть некоторые особенности при постановке и обсуждении задач. Особенно если часть функционала описана в виде картинок. Но мне кажется, что это в какой-то степени тренирует и окружающих, чтобы объяснения были не в стиле «смотри, есть вот такая фигня, она помещается вот эту штуку» и т.д., а была какая-то связная речь. :)
Ну и в целом, человек живет полноценной жизнью. Вот недавно родился второй ребенок. :) Меня, конечно, это до сих пор поражает, хотя работаем вместе уже больше года наверно.
Про разницу, формулировка задачи по ссылке, для которой приводится мат. обоснование звучит следующим образом:
«Представьте себе, что на стол высыпана кучка совершенно одинаковых по виду монет, но вам сказали, что одна из этих монет — фальшивая. Она отличается от остальных монет по весу, но вам не сообщили, легче она или тяжелее. В вашем распоряжении имеются чашечные весы без гирь. Как нужно действовать, чтобы выделить эту монету и выяснить её тип (то есть узнать, легче она или тяжелее) за минимальное число взвешиваний?»
Обратите внимание на жирный текст. Его в вашей формулировке нет. Теперь, пожалуйста, подумайте над решением задачи в вашей формулировке. Есть решения для случая с 13 монетами/шарами?
«На столе лежат 12 совершенно одинаковых по виду шаров, но один из них — фальшивый. Он отличается от остальных шаров по весу (мы не знаем, легче он или тяжелее). В вашем распоряжении имеются чашечные весы без гирь. Нужно найти аномальный шар за минимальное количество взвешиваний (подсказка — решение можно найти за 3 взвешивания).»
Задача по ссылке, которую вы приводите, и где дается мат. обоснование:
«Представьте себе, что на стол высыпана кучка совершенно одинаковых по виду монет, но вам сказали, что одна из этих монет — фальшивая. Она отличается от остальных монет по весу, но вам не сообщили, легче она или тяжелее. В вашем распоряжении имеются чашечные весы без гирь. Как нужно действовать, чтобы выделить эту монету и выяснить её тип (то есть узнать, легче она или тяжелее) за минимальное число взвешиваний?»
Разницу видите? Для вашей задачи, как мне кажется, есть решение с 3 взвешиваниями и 13 монетами.
И какое количество секторов на БС у вас сконфигурено? 6?
Еще был бы интересен технический момент. Контроль версий, прогон регрессии. Сколько времени это занимает? Какие уровни тестирования у вас вообще используются? На каких из них есть регрессия? Гоняется ли она для каждого изменения?
И еще комментарий насчет «С самого начала нужен хороший проектный план. Хороший — значит очень детальный: вся функциональность должна быть описана, продумана и запланирована. Очень похоже на первый этап каскадной модели.» Это же совсем не про Scrum. :) Одна из заявляемых вкусностей Scrum — это быстрая адаптация к новым требованиям, именно поэтому (как мне кажется) рисовать детальный план в начале проекта деятельность спорная. Однако, в вашем случае, как я понял, быстрая адаптация к новым требованиям не нужна, т.к. этого или совсем нет или бывает редко. Это так? Если да, то у вас получается что-то вроде Scrum в рамке водопада? И еще интересно было бы узнать как вы спецификацию пишите? Как правило вы же ее пишете до начала спринта, где будет идти разработка, или нет?
Я не против обучения ребенка родителями, если у них к этому есть способность/желание и достаточное время. А последнего, мне кажется, надо очень много. У меня есть некий опыт чтения тренингов в своей профильной области (т.е. она связана с работой), и даже в этом случае времени на подготовку нужно достаточно много. А если говорить про какие-то направления, с которыми ты не сталкивался более десяти лет, то время на подготовку увеличивается в несколько раз. И вряд ли такое направление даже в рамках школьной программы одно.