Для меня, как преподавателя (по совместительству с основной работой программистом) данный вопрос имеет практическую ценность, но ответа я так и не получил. «Активные формы занятий» — это, конечно, классно, но как это сделать для потока в 100 человек? Дело не только в нехватке времени (интерактив его съест немало, слово за слово, и чисто содержательно за пару будет пройдено очень мало материала), дело в организации процесса: я смутно себе представляю интерактив на 100 человек. Будет либо балаган перекрикивающих друг друга студентов, либо, что более вероятно, в процесс вовлекутся пара-тройка наиболее активных студента, а остальные будут скучать. Какие есть у кого мысли?
Еще я вот что заметил: видеолекции идут «на ура», это да. В той части, где много нюансов, которые сложно записать в конспект или запомнить (например, процесс создания MVVM-проекта с использованием Catel, там много нюансов) — гораздо проще смотреть видео, можно перематывать. Но! Студенты лишаются главного преимущества традиционной лекции: возможности задавать вопросы по ходу, когда что-то непонятно. Получается, что совсем от лекций не уйти. Можно конечно помечтать, что я выдаю видеолекции, после их просмотра — консультация, где я отвечаю на вопросы, но это идиллия, мало кто из студентов мотивирован на такую высокую организованность процесса своего обучения (выписать свои вопросы при просмотре и пр.)
Пока я не вижу способа, как отказаться от лекций, а очень хочется, т.к. приходится давать материал (хоть и адаптированный, со своими примерами и пр.), который при желании можно получить из книг (основы ООП).
Ну так-то да… Но вообще хотелось бы жить по «Фэн-Шую»: переходя на определенный стек технологий следовать принятым там best practice, которые выросли на опыте проб и ошибок людей. Git'оводы обычно против нескольких папок, там вроде бы так не принято, т.е. выбирая систему контроля версий мы «должны» не просто поменять софт, но и идеологию разработки: короткие атомарные коммиты на каждый чих, что дает возможность чуть ли не всегда переключиться на другую ветку.
У нас стратегия очень простая: есть master (релизы), dev (мелкие правки), и на каждую фичу заводится отдельная ветка. Как правило от dev. Фича закончилась — вливается в dev, как правило даже не руками, а через GitFlow. Мерж везде настроен через rebase, это не мое решение, но вроде как народ, пришедший к такой схеме, долго копал тему, ломал копья, в итоге вот так. Мне нравится тем, что в логе я вижу все коммиты по фиче рядышком, где ветка вливается в dev (а не разбросанными по логу).
Картинка вроде бы простая, проблемы начинаются когда процесс хоть чуточку усложняется, как оно на деле бывает, например:
1. Например, долгая разработка фичи. Понятно, чтобы сильно не разъехаться, надо периодически делать integrate to develop. Но веток много, штук 10, разработчика на проекте 3, где-то чуть затянули, в дев влилось что-то мощное — все, адский rebase ветки обеспечен.
2. Бывали потери коммитов. Помню такой пример: есть код в деве, который в ветке был удален, ветку влили. А в другой ветке (от дева) что-то завязано на этот код. При rebase ветки Git'у почему-то снесло крышу, он автоматом потерял часть коммитов.
3. Напрягает идеология Git'а «все в одной папке». Бывает, что мне быстро нужно бросить основную задачу, переключиться на другую ветку, потом еще на одну, потом обратно. В SVN у меня каждая фича лежала в отдельной папке на диске, т.е. я легко мог бросить разломанный код, просто открыть в студии другой проект. Здесь приходится делать финты ушами для переключения ветки: либо stash (который потом может не встать, если что-то в ветке изменилось), либо локальный коммит (который для разломанного кода делать не хочется).
С ним не работал, у нас ни в одной команде не используется, вряд ли на него будем переходить. Вопрос-то не «какую бы еще СКВ попробовать», а «так чем же Git настолько лучше SVN?»
Rebase не от хорошей жизни же. После вливания ветки я обычно в логе смотрю комиты, на всякий случай, без rebase — они разбросаны по логу. Но это ладно. Кроме как «урчание от счастья» что можете сказать?) Конкретно, в чем неудобство\ограниченность функционала\недостаток SVN, которого нет в Git? В чем конкретно профит от перехода на Git, кроме чисто религиозного «Git — это круто»?
Я понимаю, что речь идет о TFS, но в комментариях столько раз прозвучало SVN\Git, что не могу не добавить свои 5 копеек.
Сначала работали на Svn (клиент TortoiseSvn), большие проекты, много разработчиков, каждая фича — в отдельной ветке (т.е. веток и мержей много). Хорошая интеграция с Jira (вкладка, где можно посмотреть коммиты, если чел забыл проставить метку с названием ветки). За несколько лет проблем не было. Ясно дело, что раз в год и незаряженное ружье стреляет, т.е. были случаи тяжелых мержей — но редко, и не идет ни в какое сравнение с тем, что началось потом…
А что потом? Потом настал момент моды на Git. Все стали переходить на Git (я имею ввиду другие команды в компании), при этом в личной беседе никто не мог аргументировать «зачем?». Ну типа это модно, Git крут, все на него уходят (это было год назад). Мы тоже перешли. Идеология Git'а другая, многое было неочевидно и непривычно. Потом мы начали делать все merg'и через rebase, чтобы при вливании ветки видеть все комиты по фиче рядышком (в логе). Каждый rebase — это новый седой волос, поскольку при нем идет протаскивание новых комитов через все старые коммиты от корня ветки, т.е. разрешать много конфликтов приходилось. Иногда merge был просто адским, и хотя Git вроде как лучше под это заточен, с Svn таких проблем никогда не было. Иногда мы теряли коммиты при кривом автомерже, приходилось руками доставать из lostHeads. В общем, это далеко не все беды, начавшиеся с Git. А польза? Никакой, абсолютно. То, что это распределенная система контроля версий — в моей работе скорее мешает, мне эта фича не нужна. По субъективным ощущением merge в Git работает ничуть не лучше. Телодвижений для простых операций приходится делать больше. Работать напрямую с репозиторием, например, без переключения на ветку скачать файл из какой-то ревизии Git не умеет. Stash штука гораздо менее удобная, чем patch, очень часто он не прикладывается. Работать стало труднее, назад на Svn проекты перевозить никто не будет, но поклонники Git'а могут снисходительно говорить «вы просто не умеете его готовить». Буду признателен за примеры того, чем Git лучше, не в open-source, а в больших коммерческих проектах.
Примерно с появлением С++11 я ушел из мира С++ в .net (так получилось, производственная необходимость). Холиварить о языках не хочу, у меня просто вопрос. Сколько смотрю на реализацию лямбд, асинхронности и прочих плюшек в С++, не могу не отметить, что все это несопоставимо более громоздко выглядит, чем в C#. Вопрос к тем, кто имел возможность поработать и с тем, и с тем: в С++ оно действительно нужно? Может быть у этого языка должен быть просто другой путь развития? Или всем ОО-языкам предстоит пройти одни и те же ступени (например лямбды есть в Python и Java 8)? Есть хотя бы в теории альтернатива лямбд?
Картинка 1
Где-то лет 10 назад я пришел на свою первую работу, это был проект 3D автосимулятора. У меня в голове был образ: меня закрепят за наставником, который чуть ли не половину своего рабочего времени будет терпеливо мне все разъяснять и показывать. По факту было следующее: у меня конечно был руководитель, который отвечал на мои вопросы, но процесса обучения как такового не было. Директор сказал: давай в рамках испытательного срока (3 месяца) сделаем мини-испытательный срок в одну неделю, сделай задачу (озвучил какую), сам поймешь, твое ли это, мы посмотрим на тебя, если все ок — тогда уже оформим тебя (но неделю работы оплатим в любом случае). У меня был легкий шок, т.к. реального опыта было ноль, перед глазами огромный проект из 2000 классов (С++), и я даже понятия не имею с чего начать. Ну ничего, разобрался. Не факт, что если бы не разобрался, то уволили бы — думаю, по моему поведению, поиску выхода из ситуации, они бы составили портрет — в этом и смысл. Есть своя ценность в таком подходе, не устраивать «медовый месяц», а сразу в бой.
Картинка 2
Прошло много лет, я давно сменил работу и пр… Очередной проект длинною в пару лет завершился, и меня перекинули на другой проект в нашей команде. Стек технологий тот же (C#, WPF), но используется множество вещей, с которыми тогда еще не успел столкнуться (Catel, WCF и пр.). Архитектура проекта крайне сложная, множество модулей, все сделано для максимальной гибкости и расширяемости (динамические атрибуты). Коллега, который в проекте давно, отдал много времени чтобы меня ввести в проект. Намного больше, чем мой первый наставник. Я гораздо быстрее въехал в проект и смог начать активно в нем работать (на носу был первый релиз). Поскольку расписывать азы мне не нужно было, коллега в сжатом виде за пол часа выдавал мне эквивалент нескольких часов чтения книг и кода проекта.
Не должно ли было быть все наоборот: возиться с джуниором и бросить на амбразуру сениора, ваше мнение?
Ведущий разработчик C++\C# в компании 2GIS (GitHub, vk, LinkedIn).
Свой проект: открытая организация по всестороннему изучению природы времени и разработке хронотехнологий: Академия Времени.
Работаю в офисе, уже лет 8, ведущий разработчик (C#\С++). Работать дома (или в снятом офисе, коворкинге и пр.) — мечта! Останавливает 3 фактора:
1. Стабильность. Семья, дети, ипотека и пр. — просто не могу позволить себе доход ниже определенного уровня.
2. Специализация. Сколько смотрел биржи фриланса, доминирует область web-разработки. Мне это интересно, но придется начинать почти с нуля.
3. Выбор задач и мировоззрение. Я работаю в команде над огромными проектами, которые призваны улучшить жизнь людей. Да, задачи меняются, иногда и проекты — но я знаю, куда идет моя компания, я знаю, что завтра мне не скажут разрабатывать что-то кардинально иное (в плане вектора), что-то такое, что противоречит моим ценностям. Да, удаленная работа и фриланс — не одно и то же, можно также удаленно работать над чем-то, что соответствует мировоззрению. Но опять же, судя по биржам, чаще всего удаленная работа — это именно фриланс, небольшие задачи, среди которых очень много тех, решать которые я принципиально не собираюсь (обход капчей, реинжениринг существующих решений в целях наживы, откровенно отупляющий людей софт в виде казуальных игрушек и пр., всякая коммерция и т.п.).
Так и есть, в статье в общем-то это упоминается) Т.е. dif — это не просто оптимизация, когда при броске монетки копируется не Вселенная, а просто создается dif на событие, dif — как вы совершенно правильно заметили — привязан к конкретному объекту и (что важно) факту наблюдения. В примере Боба и Алисы как раз об этом речь: dif делается в момент регистрации события, а не его реального осуществления. Впрочем, с точки зрения квантовой механики, наблюдение события в каком-то смысле и есть его осуществление… Иными словами то, что мы видим вокруг — это не единая реальность, а срез огромного количества объектов, каждый из которых имеет множество альтернативных вариаций, и мы видим лишь одну из них.
Разная скорость течения времени в ветках — да, мысль здравая, просто в статье я ограничился упрощенной моделью. Здесь сразу приходит на ум аналогия с рекой — максимальная скорость потока в центре, чем ближе к краю, тем медленнее течет вода, у кромки берега она может даже течь в обратную сторону (из-за трения с берегом). А если от реки сделать ответвление в ручей, там вода будет еле-еле течь. Получается, что каждое вмешательство в ход истории порождает бранч с замедленным потоком времени, а при многократном ответвлении, у бранча N-го порядка время просто остановится — у фантаста Головачева это описано как «вырождение реальности», когда Вселенная постепенно затухает. У него же описана идея «матричной ветви» в Древе Времен, некая изначальная реальность, никогда не подвергавшаяся изменениям. Как знать, а вдруг наша реальность бесконечно далека от нее, благодаря многочисленным временным «коррекциям». Возможно ли не выходя за пределы реальности определить тот факт, что она — ветка, а не транк? Возможно, в одной из следующих статей мы об этом поговорим)
Да, интересные опыты. Кстати, мы и так живем с лагом, ведь сигналу с сетчатки нужно время на прохождение нервных путей и обработки в головном мозге. Много лет назад была статья об исследовании на эту тему (в каком журнале, увы, не помню), что скорость реакции при ударе по мячу бейсболистом ПРЕВЫШАЕТ скорость прохождения сигнала, т.е. бейсболист видит мяч там, где его еще нет, мозг экстраполирует траекторию полета, и мы видим ближайшее будущее.
Хочу добавить вот еще что про имитацию замедления времени: в реальности человек «вступает в конфликт» с миром, ходит натыкаясь на препятствия, поскольку пока он получает замедленный поток сенсорной информации, мир уходит дальше. В играх проще: тот же Braid погружает нас в удивительную атмосферу изменчивого времени, его можно ускорять, замедлять и пр. А вот если добавить в игру других реальных игроков, т.е. попытаться виртуально смоделировать изменение хода времени реального мира, мы сталкиваемся с трудностями, решение которых — очень интересный вопрос. Например в TimeShift можно ускорять время (т.е. мир вокруг замедляется, и можно быстро расправиться с врагами, пока они застыли), а в multi-player эта возможность, естественно, отключена. Первое, что приходит в голову: как только один игрок ускорил свое время, нужно всем другим игрокам время замедлить. Есть ощущение, что здесь можно придумать что-то интереснее.
И сон этот хороший. Может быть пока под темой ОС нет солидного научного фундамента, и пока эта тема больше прибежище эзотериков, но ведь феномен есть, и изучать его нужно. Если кому-то интересна эта тема, предлагаю обсудить, могу ответить на вопросы, здесь или в ЛС (занимался данной практикой несколько лет, дойдя до уровня 100%-ной реалистичности ОС).
Никогда не работал с подобными технологиями, но очень интересно, поэтому вопрос: как здесь реализуется собственно модель приложения? Ну т.е. все эти иконки, кнопки, формы — классно, на каком языке реализуются все внутренности (вычисления, БД, сеть, работа с файлами, многопоточность и пр.)?
Не холивара ради, а из чистого любопытства: т.е. в Java лямбды появились только сейчас, спустя 10 лет после .net? Чем вызван столь огромный разрыв во времени (для IT-индустрии просто целая эпоха) — в Java какая-то своя специфика, что ни лямбды, ни атрибуты, ни Linq просто не нужны (компенсируется возможностями библиотек, иной спектр задач....)? В каком тогда направлении эти годы развивалась Java?
Опять же, не хочу принижать Java, наверняка это замечательный язык, просто не представляю уже современную разработку без лямбд, позволяющих писать очень лаконичный и выразительный код, в стиле, близком к декларативному.
Еще я вот что заметил: видеолекции идут «на ура», это да. В той части, где много нюансов, которые сложно записать в конспект или запомнить (например, процесс создания MVVM-проекта с использованием Catel, там много нюансов) — гораздо проще смотреть видео, можно перематывать. Но! Студенты лишаются главного преимущества традиционной лекции: возможности задавать вопросы по ходу, когда что-то непонятно. Получается, что совсем от лекций не уйти. Можно конечно помечтать, что я выдаю видеолекции, после их просмотра — консультация, где я отвечаю на вопросы, но это идиллия, мало кто из студентов мотивирован на такую высокую организованность процесса своего обучения (выписать свои вопросы при просмотре и пр.)
Пока я не вижу способа, как отказаться от лекций, а очень хочется, т.к. приходится давать материал (хоть и адаптированный, со своими примерами и пр.), который при желании можно получить из книг (основы ООП).
Картинка вроде бы простая, проблемы начинаются когда процесс хоть чуточку усложняется, как оно на деле бывает, например:
1. Например, долгая разработка фичи. Понятно, чтобы сильно не разъехаться, надо периодически делать integrate to develop. Но веток много, штук 10, разработчика на проекте 3, где-то чуть затянули, в дев влилось что-то мощное — все, адский rebase ветки обеспечен.
2. Бывали потери коммитов. Помню такой пример: есть код в деве, который в ветке был удален, ветку влили. А в другой ветке (от дева) что-то завязано на этот код. При rebase ветки Git'у почему-то снесло крышу, он автоматом потерял часть коммитов.
3. Напрягает идеология Git'а «все в одной папке». Бывает, что мне быстро нужно бросить основную задачу, переключиться на другую ветку, потом еще на одну, потом обратно. В SVN у меня каждая фича лежала в отдельной папке на диске, т.е. я легко мог бросить разломанный код, просто открыть в студии другой проект. Здесь приходится делать финты ушами для переключения ветки: либо stash (который потом может не встать, если что-то в ветке изменилось), либо локальный коммит (который для разломанного кода делать не хочется).
Сначала работали на Svn (клиент TortoiseSvn), большие проекты, много разработчиков, каждая фича — в отдельной ветке (т.е. веток и мержей много). Хорошая интеграция с Jira (вкладка, где можно посмотреть коммиты, если чел забыл проставить метку с названием ветки). За несколько лет проблем не было. Ясно дело, что раз в год и незаряженное ружье стреляет, т.е. были случаи тяжелых мержей — но редко, и не идет ни в какое сравнение с тем, что началось потом…
А что потом? Потом настал момент моды на Git. Все стали переходить на Git (я имею ввиду другие команды в компании), при этом в личной беседе никто не мог аргументировать «зачем?». Ну типа это модно, Git крут, все на него уходят (это было год назад). Мы тоже перешли. Идеология Git'а другая, многое было неочевидно и непривычно. Потом мы начали делать все merg'и через rebase, чтобы при вливании ветки видеть все комиты по фиче рядышком (в логе). Каждый rebase — это новый седой волос, поскольку при нем идет протаскивание новых комитов через все старые коммиты от корня ветки, т.е. разрешать много конфликтов приходилось. Иногда merge был просто адским, и хотя Git вроде как лучше под это заточен, с Svn таких проблем никогда не было. Иногда мы теряли коммиты при кривом автомерже, приходилось руками доставать из lostHeads. В общем, это далеко не все беды, начавшиеся с Git. А польза? Никакой, абсолютно. То, что это распределенная система контроля версий — в моей работе скорее мешает, мне эта фича не нужна. По субъективным ощущением merge в Git работает ничуть не лучше. Телодвижений для простых операций приходится делать больше. Работать напрямую с репозиторием, например, без переключения на ветку скачать файл из какой-то ревизии Git не умеет. Stash штука гораздо менее удобная, чем patch, очень часто он не прикладывается. Работать стало труднее, назад на Svn проекты перевозить никто не будет, но поклонники Git'а могут снисходительно говорить «вы просто не умеете его готовить». Буду признателен за примеры того, чем Git лучше, не в open-source, а в больших коммерческих проектах.
Картинка 1
Где-то лет 10 назад я пришел на свою первую работу, это был проект 3D автосимулятора. У меня в голове был образ: меня закрепят за наставником, который чуть ли не половину своего рабочего времени будет терпеливо мне все разъяснять и показывать. По факту было следующее: у меня конечно был руководитель, который отвечал на мои вопросы, но процесса обучения как такового не было. Директор сказал: давай в рамках испытательного срока (3 месяца) сделаем мини-испытательный срок в одну неделю, сделай задачу (озвучил какую), сам поймешь, твое ли это, мы посмотрим на тебя, если все ок — тогда уже оформим тебя (но неделю работы оплатим в любом случае). У меня был легкий шок, т.к. реального опыта было ноль, перед глазами огромный проект из 2000 классов (С++), и я даже понятия не имею с чего начать. Ну ничего, разобрался. Не факт, что если бы не разобрался, то уволили бы — думаю, по моему поведению, поиску выхода из ситуации, они бы составили портрет — в этом и смысл. Есть своя ценность в таком подходе, не устраивать «медовый месяц», а сразу в бой.
Картинка 2
Прошло много лет, я давно сменил работу и пр… Очередной проект длинною в пару лет завершился, и меня перекинули на другой проект в нашей команде. Стек технологий тот же (C#, WPF), но используется множество вещей, с которыми тогда еще не успел столкнуться (Catel, WCF и пр.). Архитектура проекта крайне сложная, множество модулей, все сделано для максимальной гибкости и расширяемости (динамические атрибуты). Коллега, который в проекте давно, отдал много времени чтобы меня ввести в проект. Намного больше, чем мой первый наставник. Я гораздо быстрее въехал в проект и смог начать активно в нем работать (на носу был первый релиз). Поскольку расписывать азы мне не нужно было, коллега в сжатом виде за пол часа выдавал мне эквивалент нескольких часов чтения книг и кода проекта.
Не должно ли было быть все наоборот: возиться с джуниором и бросить на амбразуру сениора, ваше мнение?
Свой проект: открытая организация по всестороннему изучению природы времени и разработке хронотехнологий: Академия Времени.
1. Стабильность. Семья, дети, ипотека и пр. — просто не могу позволить себе доход ниже определенного уровня.
2. Специализация. Сколько смотрел биржи фриланса, доминирует область web-разработки. Мне это интересно, но придется начинать почти с нуля.
3. Выбор задач и мировоззрение. Я работаю в команде над огромными проектами, которые призваны улучшить жизнь людей. Да, задачи меняются, иногда и проекты — но я знаю, куда идет моя компания, я знаю, что завтра мне не скажут разрабатывать что-то кардинально иное (в плане вектора), что-то такое, что противоречит моим ценностям. Да, удаленная работа и фриланс — не одно и то же, можно также удаленно работать над чем-то, что соответствует мировоззрению. Но опять же, судя по биржам, чаще всего удаленная работа — это именно фриланс, небольшие задачи, среди которых очень много тех, решать которые я принципиально не собираюсь (обход капчей, реинжениринг существующих решений в целях наживы, откровенно отупляющий людей софт в виде казуальных игрушек и пр., всякая коммерция и т.п.).
Так и есть, в статье в общем-то это упоминается) Т.е. dif — это не просто оптимизация, когда при броске монетки копируется не Вселенная, а просто создается dif на событие, dif — как вы совершенно правильно заметили — привязан к конкретному объекту и (что важно) факту наблюдения. В примере Боба и Алисы как раз об этом речь: dif делается в момент регистрации события, а не его реального осуществления. Впрочем, с точки зрения квантовой механики, наблюдение события в каком-то смысле и есть его осуществление… Иными словами то, что мы видим вокруг — это не единая реальность, а срез огромного количества объектов, каждый из которых имеет множество альтернативных вариаций, и мы видим лишь одну из них.
Разная скорость течения времени в ветках — да, мысль здравая, просто в статье я ограничился упрощенной моделью. Здесь сразу приходит на ум аналогия с рекой — максимальная скорость потока в центре, чем ближе к краю, тем медленнее течет вода, у кромки берега она может даже течь в обратную сторону (из-за трения с берегом). А если от реки сделать ответвление в ручей, там вода будет еле-еле течь. Получается, что каждое вмешательство в ход истории порождает бранч с замедленным потоком времени, а при многократном ответвлении, у бранча N-го порядка время просто остановится — у фантаста Головачева это описано как «вырождение реальности», когда Вселенная постепенно затухает. У него же описана идея «матричной ветви» в Древе Времен, некая изначальная реальность, никогда не подвергавшаяся изменениям. Как знать, а вдруг наша реальность бесконечно далека от нее, благодаря многочисленным временным «коррекциям». Возможно ли не выходя за пределы реальности определить тот факт, что она — ветка, а не транк? Возможно, в одной из следующих статей мы об этом поговорим)
Хочу добавить вот еще что про имитацию замедления времени: в реальности человек «вступает в конфликт» с миром, ходит натыкаясь на препятствия, поскольку пока он получает замедленный поток сенсорной информации, мир уходит дальше. В играх проще: тот же Braid погружает нас в удивительную атмосферу изменчивого времени, его можно ускорять, замедлять и пр. А вот если добавить в игру других реальных игроков, т.е. попытаться виртуально смоделировать изменение хода времени реального мира, мы сталкиваемся с трудностями, решение которых — очень интересный вопрос. Например в TimeShift можно ускорять время (т.е. мир вокруг замедляется, и можно быстро расправиться с врагами, пока они застыли), а в multi-player эта возможность, естественно, отключена. Первое, что приходит в голову: как только один игрок ускорил свое время, нужно всем другим игрокам время замедлить. Есть ощущение, что здесь можно придумать что-то интереснее.
И сон этот хороший. Может быть пока под темой ОС нет солидного научного фундамента, и пока эта тема больше прибежище эзотериков, но ведь феномен есть, и изучать его нужно. Если кому-то интересна эта тема, предлагаю обсудить, могу ответить на вопросы, здесь или в ЛС (занимался данной практикой несколько лет, дойдя до уровня 100%-ной реалистичности ОС).
Опять же, не хочу принижать Java, наверняка это замечательный язык, просто не представляю уже современную разработку без лямбд, позволяющих писать очень лаконичный и выразительный код, в стиле, близком к декларативному.