Ну вообще, если компания не пользуется налоговыми льготами, то одни налоги дают 54% (134/87). Отпуск и больничные ещё +15%. Плюс офисные сотрудники получают з/п за время, проведённое на рабочем месте, независимо от того работали они там или нет. А это как показывает практика даёт ещё разницу на 50-100%, т.к. реально рабочего времени в офисе получается (4-6 часов)
Теперь осталось это всё перемножить (1.541.151.5) и получится, что офисный сотрудник обходится минимум в 2.7 раза дороже своей зарплаты на руки, это не считая расходы на печеньки, оргтехнику, ДМС, корпоративные мероприятия и другие плюшки.
Да по-моему "в 2 раза чаще писать -> должно быть в 2 раза короче" — это бред полный, а не аргументация… Можно подумать, что пара тысяч сэкономленных символов сделает написание нетривиальной программы хотя бы на 0.01% быстрее…
На отладку 1 ошибки забытого = в == всё это "сэкономленное" время и уйдёт.
Ну, во-первых, везде сумма налогов берётся с 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, тут разницы то принципиальной нет. Просто, имхо, вы преувеличиваете, что необходимость в этом возникает чуть ли не ежедневно.
Я не против цепочки коммитов (напр. рефакторинг, рефакторинг, первая логически атомарная часть фичи, вторая часть фичи и т.д.), но десятки, а тем более сотни — это просто организационный косяк, когда границы фичи вообще не определяют.
Если при ребейзе оставить чери-пикнутый коммит, то он просто покажет предупреждение типа "пустой коммит" и пропустит его автоматически. Но можно и скипнуть, не принципиально.
Ну вообще, если компания не пользуется налоговыми льготами, то одни налоги дают 54% (134/87). Отпуск и больничные ещё +15%. Плюс офисные сотрудники получают з/п за время, проведённое на рабочем месте, независимо от того работали они там или нет. А это как показывает практика даёт ещё разницу на 50-100%, т.к. реально рабочего времени в офисе получается (4-6 часов)
Теперь осталось это всё перемножить (1.541.151.5) и получится, что офисный сотрудник обходится минимум в 2.7 раза дороже своей зарплаты на руки, это не считая расходы на печеньки, оргтехнику, ДМС, корпоративные мероприятия и другие плюшки.
Пфф, изначально и SQL для бухгалтеров разрабатывали, чтобы они не отвлекали программистов на всякие глупости, типа отчётов.
Да по-моему "в 2 раза чаще писать -> должно быть в 2 раза короче" — это бред полный, а не аргументация… Можно подумать, что пара тысяч сэкономленных символов сделает написание нетривиальной программы хотя бы на 0.01% быстрее…
На отладку 1 ошибки забытого = в == всё это "сэкономленное" время и уйдёт.
На отладку ошибок этим вызванных </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, тут разницы то принципиальной нет. Просто, имхо, вы преувеличиваете, что необходимость в этом возникает чуть ли не ежедневно.
Я не против цепочки коммитов (напр. рефакторинг, рефакторинг, первая логически атомарная часть фичи, вторая часть фичи и т.д.), но десятки, а тем более сотни — это просто организационный косяк, когда границы фичи вообще не определяют.
Если при ребейзе оставить чери-пикнутый коммит, то он просто покажет предупреждение типа "пустой коммит" и пропустит его автоматически. Но можно и скипнуть, не принципиально.