Кому станет хуже от того, что юзер станет чаще выигрывать? Гейм-дизайнеры, полагаю, постоянно такими штуками занимаются. Больше похоже на таракан, чем на профессиональную этику.
UPD:
Это не мой некропостинг, просто кто-то прокрастинировал с одобрением комментария пять лет.
Вот тут субъективно я не уверен, что хуже. Когда тебе отказывают после того, как ты не решил какую-то заковыристую задачу, то в принципе понятно, почему отказали, и куда расти (даже если расти в ту сторону и не особо хочется). А отказ после «собеседования-разговора» всегда оставляет некоторое недоумение: я что, как-то не так разговариваю?
Один раз я прошел в компании всю техническую часть, и мне тимлид сказал, что тестовое задание я выполнил лучше остальных кандидатов. После чего остался последний этап, «culture interview», где мне задавали вопросы вида «каким животным вы хотели бы быть» и «как бы вы изменили мир, обладая неограниченными возможностями». По результату получил отказ. Много думал.
TC, насколько я понял, предлагает использовать его везде. Например, он упоминает node_modules, которые тоже, очевидно, должны были бы переместиться под XDG_DATA_DIRS.
Это делает их неопытными разработчиками. Что совершенно нормально для человека, который только написал диплом. Другое дело, если культура предприятия это поддерживает, тогда развитие у ваших сотрудников будет идти не так хорошо, как могло бы.
В принципе, никакой ракетной техники в git нет — я сам работал на предприятии, где использовался (и, наверное, до сих пор используется) SVN, и переучиться на git стоило, конечно, некоторых усилий, но не то, чтобы запредельных. Но такие мелочи могут накапливаться, и делать предприятие (и, соответственно, строчку в резюме ваших сотрудников) «uncool».
Реальный пример №1: вы работаете над некоторой фичей в ветке. В процессе создаете еще пару веток для каких-нибудь подфич. Наконец, все готово, и вы сливаете ветки для подфич в основную ветку, чтобы затем сделать pull request в master. Если вы будете сливать свои частные ветки с помощью merge, в общей истории проекта будет видно всё ваше грязное белье, где вы бранчились, где вы мерджились и т.п. Это загрязняет историю, поэтому обычно merge используется только для того, чтобы влить вашу главную feature branch в master, тут информация о слиянии веток как раз полезна.
Реальный пример №2 (самый часто используемый сценарий использования rebase, наверное): вы снова работаете над фичей в своей ветке. Пока вы работаете, другие тоже работают, и master уходит вперед. Работа вам еще предстоит долгая, мерджится в master пока рано, но и сильно рассинхронизироваться вам не хочется. Можно было бы смерджится локально (т.е. влить master в свою ветку), но опять-таки, когда работа над фичей будет закончена, у вас в истории останутся «узелки» на всех тех местах, где вы синхронизировались. Чтобы «узелков» не было, вместо этого вы делаете rebase своей ветки относительно обновившегося master, и для стороннего наблюдателя ваш вклад будет выглядеть как линейная последовательность коммитов.
Rebase — инструмент для переписывания истории коммитов, после него получается красивая линейная история изменений. Merge сливает две ветки в одну, притом обе остаются в истории. Рабочая директория в обоих случаях получается одинаковая, а лог — разный.
В США — тоже не короли, но получают заметно больше. По моему кругу общения — в Германии молодежь стремится свалить в США примерно так же, как в России свалить хоть куда-нибудь (ну, может, не так рьяно).
a) С днем рождения! А, сорри, мне показалось, что сегодня исполнилось.
б) Смешно смотреть на бородатых дядек, которые всерьез с вами спорят.
в) А у вас все впереди, конечно.
Хороший пример с двигателями на самом деле. Никто же не скажет, что двигатель А выиграл у двигателя Б в свободной конкуренции за водителя. Просто потому что водитель вообще решения о том, какой двигатель выбрать, не принимает, между ним и производителем еще несколько инстанций.
Да, я думаю, это законно, иначе не был бы возможен, например, макбук.
Ну, тут действительно напрашивается параллель с мистером П., который обязательно выиграл бы честные выборы, но вот как-то всем удобнее проводить нечестные.
Я и не отрицаю, что монопольный сговор выгоден и Microsoft, и производителям железа, и вполне терпим или вовсе незаметен для большинства пользователей. Но он не становится от этого честной конкуренцией.
О том и речь. Для полиморфизма не нужен virtual. Virtual нужен только для того варианта полиморфизма, который использует указатели/ссылки на базовый класс.
Последние две свои копии Windows я купил вынужденно — просто потому что производители лэптопа не давали от нее отказаться. Разумеется, тут же снёс, но дело не в этом. Конкурентный способ — это если бы пользователи покупали пустой компьютер, и сами решали, какую операционку на нее поставить: за деньги, если операционка коммерческая или бесплатно, если нет. То, что происходит сейчас — это фактически монопольный сговор Microsoft с производителями железа — то есть что угодно, но не честная конкуренция.
Кому станет хуже от того, что юзер станет чаще выигрывать? Гейм-дизайнеры, полагаю, постоянно такими штуками занимаются. Больше похоже на таракан, чем на профессиональную этику.
UPD:
Это не мой некропостинг, просто кто-то прокрастинировал с одобрением комментария пять лет.
Я бы даже сказал, полуавтоматический.
Один раз я прошел в компании всю техническую часть, и мне тимлид сказал, что тестовое задание я выполнил лучше остальных кандидатов. После чего остался последний этап, «culture interview», где мне задавали вопросы вида «каким животным вы хотели бы быть» и «как бы вы изменили мир, обладая неограниченными возможностями». По результату получил отказ. Много думал.
Это делает их неопытными разработчиками. Что совершенно нормально для человека, который только написал диплом. Другое дело, если культура предприятия это поддерживает, тогда развитие у ваших сотрудников будет идти не так хорошо, как могло бы.
В принципе, никакой ракетной техники в git нет — я сам работал на предприятии, где использовался (и, наверное, до сих пор используется) SVN, и переучиться на git стоило, конечно, некоторых усилий, но не то, чтобы запредельных. Но такие мелочи могут накапливаться, и делать предприятие (и, соответственно, строчку в резюме ваших сотрудников) «uncool».
Реальный пример №2 (самый часто используемый сценарий использования rebase, наверное): вы снова работаете над фичей в своей ветке. Пока вы работаете, другие тоже работают, и master уходит вперед. Работа вам еще предстоит долгая, мерджится в master пока рано, но и сильно рассинхронизироваться вам не хочется. Можно было бы смерджится локально (т.е. влить master в свою ветку), но опять-таки, когда работа над фичей будет закончена, у вас в истории останутся «узелки» на всех тех местах, где вы синхронизировались. Чтобы «узелков» не было, вместо этого вы делаете rebase своей ветки относительно обновившегося master, и для стороннего наблюдателя ваш вклад будет выглядеть как линейная последовательность коммитов.
Rebase — инструмент для переписывания истории коммитов, после него получается красивая линейная история изменений. Merge сливает две ветки в одну, притом обе остаются в истории. Рабочая директория в обоих случаях получается одинаковая, а лог — разный.
С днем рождения!А, сорри, мне показалось, что сегодня исполнилось.б) Смешно смотреть на бородатых дядек, которые всерьез с вами спорят.
в) А у вас все впереди, конечно.
Нет, не заменили.
Да, я думаю, это законно, иначе не был бы возможен, например, макбук.
Я и не отрицаю, что монопольный сговор выгоден и Microsoft, и производителям железа, и вполне терпим или вовсе незаметен для большинства пользователей. Но он не становится от этого честной конкуренцией.