Ну, во-первых, везде сумма налогов берётся с gross, а не от «денег на руки». Так что получается 34%. Во-вторых, в России компании в разных отраслях платят разные налоги, для IT получается по факту 20-22% c gross платит работодатель, а 13% — работник. Т.е. если даже считать с общей суммы (до налогов), то получается (1-87/122) => 28.7%, а не 34% и уж тем более не 50%.
P.S. А считать всё-таки корректно только с gross, т.к. именно эти зарплаты фигурируют везде в статистике. И какие там налоги платит работодатель в других странах мы знать не знаем.
Да понятно, что урна (образца 90-х)… Но выглядит всё равно отстойно.
Соглашусь, что оригинальный логотип хоть и странный, но гораздо лучше, чем представленные в статье.
На самом деле людям часто нравится результат, а не процесс, включающий проблемы на пути. Но не полюбив процесс решения этих проблем невозможно достигнуть и результата. Это как представлять себя с Оскаром на сцене, и ждать что тебя просто с улицы на главную роль пригласят. Или мечтать стать миллионером и идти на работу секретаря в офис. Или как в анекдоте: мечтать выиграть в лотерею и не покупать билет.
Это свойственно всем людям, мечтать о каком-то результате и ничего для этого не делать, все мы хотим чтобы "что-то появилось у нас просто так".
Просто нам, как программистам, очевидно что умение программировать так никогда не появится. Но это не значит, что у нас самих нет таких же иллюзий на другие темы.
И что это даст? Если вы разрабатываете мобильные приложения под iOS, то всё равно придётся принять факт, что это уже есть. Купите или не купите, от этого ничего не зависит. В этом плане eshimischi полностью прав.
Очевидно, что тесты лучше, но если у вас их нет, то за 5 минут их не добавишь. Но это ж кем надо быть, чтобы убрать строку, не прочитав комментарий рядом с ней?
я акцентировал внимание на том, что Ваше «зачем искать почему написано ТАК, если проще просто исправить» — неприменимо, ИМХО, к не-опечаткам
Да, но не-опечатки крайне редко тесты проходят… А вот в к-н строке опечатка может проскочить. Поэтому это единственная вероятная ситуация, которая мне пришла в голову для случая, когда ошибка не обнаружилась во время rebase. Конечно, бывают и более хитрые случаи, но весьма редко.
Тогда можно комментарии хотя бы писать. А то что толку от вашей истории коммитов, если assert всё равно убрали не глядя?
благодаря git bisect стало понятно кто и почему виноват и, главное, как это исправить
git bisect будет так же работать и в случае с rebase, тут разницы то принципиальной нет. Просто, имхо, вы преувеличиваете, что необходимость в этом возникает чуть ли не ежедневно.
Я не против цепочки коммитов (напр. рефакторинг, рефакторинг, первая логически атомарная часть фичи, вторая часть фичи и т.д.), но десятки, а тем более сотни — это просто организационный косяк, когда границы фичи вообще не определяют.
Если при ребейзе оставить чери-пикнутый коммит, то он просто покажет предупреждение типа "пустой коммит" и пропустит его автоматически. Но можно и скипнуть, не принципиально.
Да, деплой на staging лучше всё-таки с ручным управлением оставить. Чтобы тестировщики сами могли определять, какую ветку они в текущий момент тестируют и она не изменилась случайно, только из-за того, что новый PR пришёл.
Странная у Вас логика… Типа между версиями один автор мог закоммитить только 1 фичу?
Рефакторинг — да, может затронуть много строк, но если делать 1 вид рефакторинга в 1 коммите (а это по сути и есть границы технической фичи), то никаких проблем не возникнет, вне зависимости от кол-ва затронутых строк.
Нужно смёржить мастер в ветку, прогнать тесты, поправить код, сделать git commit --amend, а потом уже мёржить ветку в мастер.
Ну вариант, да. Хотя лично для меня все эти мерджи master в ветку выглядят как какое-то дикое извращение.
Вы вроде не выступаете за то, чтобы делать squash при мёрже?
У меня нет строгого правила, что должен остаться обязательно 1 коммит, т.к. иногда удобнее сделать 3-5 коммитов в одной ветке, чем дробить это на 3-5 минифич. Но ветки по 100 коммитов, или как тут писали на 10000 значимо измененных строк, я не одобряю.
Видимо под удобной в работе историей вы имеете в виду линейную. Чем она удобна? В чём преимущество перед нелинейной?
Ну тут имхо очевидно. Что может быть проще прямой линии? Всё красиво и откатывать при необходимости можно фичи целиком, а не по 100 коммитов. Зачем засорять себе восприятие какими-то коммитами, которых по факту никогда не было в master? Чтобы найдя к-н опечатку вооружиться git bisect в поисках коммита, в котором она была сделана? Чтобы что? Чтобы revert сделать? А если там ещё изменения есть кроме той опечатки… И эти все пляски с бубном вместо того, чтобы за пару секунд исправить опечатку и закоммитить исправление? Или это так важно найти кто виноват и оштрафовать его на ползарплаты?
На отладку ошибок этим вызванных </troll-mode>
Верно. Вычисления в физике — это просто определение частного случая равенства на основе известных значений переменных. Никаких присваиваний.
Да у него вообще с математикой полный швах… достаточно любое его видео посмотреть, где хоть какие-то расчёты фигурируют.
Ну, во-первых, везде сумма налогов берётся с gross, а не от «денег на руки». Так что получается 34%. Во-вторых, в России компании в разных отраслях платят разные налоги, для IT получается по факту 20-22% c gross платит работодатель, а 13% — работник. Т.е. если даже считать с общей суммы (до налогов), то получается (1-87/122) => 28.7%, а не 34% и уж тем более не 50%.
P.S. А считать всё-таки корректно только с gross, т.к. именно эти зарплаты фигурируют везде в статистике. И какие там налоги платит работодатель в других странах мы знать не знаем.
Да понятно, что урна (образца 90-х)… Но выглядит всё равно отстойно.
Соглашусь, что оригинальный логотип хоть и странный, но гораздо лучше, чем представленные в статье.
Какие у них социалисты расслабленные… У нас при социализме такое уголовно преследовалось по статье за тунеядство :-)
Просветите, что такое "корешок" денег?
Насчёт статей не знаю, но списки библиотек есть:
http://lisp-lang.org/wiki/article/recommended-libraries
https://github.com/CodyReichert/awesome-cl
На самом деле людям часто нравится результат, а не процесс, включающий проблемы на пути. Но не полюбив процесс решения этих проблем невозможно достигнуть и результата. Это как представлять себя с Оскаром на сцене, и ждать что тебя просто с улицы на главную роль пригласят. Или мечтать стать миллионером и идти на работу секретаря в офис. Или как в анекдоте: мечтать выиграть в лотерею и не покупать билет.
Это свойственно всем людям, мечтать о каком-то результате и ничего для этого не делать, все мы хотим чтобы "что-то появилось у нас просто так".
Просто нам, как программистам, очевидно что умение программировать так никогда не появится. Но это не значит, что у нас самих нет таких же иллюзий на другие темы.
Ну да, как же… Gotchas and common mistakes in Go
По количеству WAT Go может влёгкую побороться за второе место после JavaScript.
И что это даст? Если вы разрабатываете мобильные приложения под iOS, то всё равно придётся принять факт, что это уже есть. Купите или не купите, от этого ничего не зависит. В этом плане eshimischi полностью прав.
Веб-мастерами их называли. Но суть та же, понемногу отовсюду и ничего на уровне программиста.
Очевидно, что тесты лучше, но если у вас их нет, то за 5 минут их не добавишь. Но это ж кем надо быть, чтобы убрать строку, не прочитав комментарий рядом с ней?
Да, но не-опечатки крайне редко тесты проходят… А вот в к-н строке опечатка может проскочить. Поэтому это единственная вероятная ситуация, которая мне пришла в голову для случая, когда ошибка не обнаружилась во время rebase. Конечно, бывают и более хитрые случаи, но весьма редко.
Тогда можно комментарии хотя бы писать. А то что толку от вашей истории коммитов, если assert всё равно убрали не глядя?
git bisect будет так же работать и в случае с rebase, тут разницы то принципиальной нет. Просто, имхо, вы преувеличиваете, что необходимость в этом возникает чуть ли не ежедневно.
Я не против цепочки коммитов (напр. рефакторинг, рефакторинг, первая логически атомарная часть фичи, вторая часть фичи и т.д.), но десятки, а тем более сотни — это просто организационный косяк, когда границы фичи вообще не определяют.
Если при ребейзе оставить чери-пикнутый коммит, то он просто покажет предупреждение типа "пустой коммит" и пропустит его автоматически. Но можно и скипнуть, не принципиально.
Да, деплой на staging лучше всё-таки с ручным управлением оставить. Чтобы тестировщики сами могли определять, какую ветку они в текущий момент тестируют и она не изменилась случайно, только из-за того, что новый PR пришёл.
Странная у Вас логика… Типа между версиями один автор мог закоммитить только 1 фичу?
Рефакторинг — да, может затронуть много строк, но если делать 1 вид рефакторинга в 1 коммите (а это по сути и есть границы технической фичи), то никаких проблем не возникнет, вне зависимости от кол-ва затронутых строк.
Ну вариант, да. Хотя лично для меня все эти мерджи master в ветку выглядят как какое-то дикое извращение.
У меня нет строгого правила, что должен остаться обязательно 1 коммит, т.к. иногда удобнее сделать 3-5 коммитов в одной ветке, чем дробить это на 3-5 минифич. Но ветки по 100 коммитов, или как тут писали на 10000 значимо измененных строк, я не одобряю.
Ну тут имхо очевидно. Что может быть проще прямой линии? Всё красиво и откатывать при необходимости можно фичи целиком, а не по 100 коммитов. Зачем засорять себе восприятие какими-то коммитами, которых по факту никогда не было в master? Чтобы найдя к-н опечатку вооружиться git bisect в поисках коммита, в котором она была сделана? Чтобы что? Чтобы revert сделать? А если там ещё изменения есть кроме той опечатки… И эти все пляски с бубном вместо того, чтобы за пару секунд исправить опечатку и закоммитить исправление? Или это так важно найти кто виноват и оштрафовать его на ползарплаты?