Здравствуйте, Андрей Бабошин, Вы писали:

V>>А могут просто ждать причину уволить. Я ни разу не видел подобных сотрудников, чтобы уж совсем совсем плохо. Зато видел таких начальников, которым только дай повод..
АБ>Совсем-совсем плохо обычно выявляется на испытательном сроке. Однако, иногда факапы бывают в управлении и сотрудник успешно проходит испытательный срок (по факту истечения времени)
АБ>и вот тут уже начинается акробатика с увольнением.
Акробатика с увольнением начинается когда надо сократить, а положенные по закону два месяца платить не хочется.

Здравствуйте, Vain, Вы писали:

V>·>С бэкапами почти ничего нельзя интересного сделать.
V>Как это ничего? А ручками помержить?
Для мержа нужен 3-side, а бэкапы линейные. Т.е. основной юзкейс это "откатиться до бекапа на дату D", откуда там мерж? Так что уж очень совсем ручками получается в лучшем случае. В git же одна команда.

Здравствуйте, Vain, Вы писали:

aik>>>"git add -A ; git push" создает новый хэш и у тебя на сервере будут хэши последних коммитов (видно через git reglog) — полезно если вдруг вспомнил что потерял что то в пределах последних дней-недель (ну, если "git gc" не отрабатывал). С файлами придется или отказаться от фичи, или выдумывать имена (дату туда вхреначивать, например).
A>>Мне удобнее видеть незаконченный код незакоммиченным Откатывать коммиты...как-то не очень, коммит — это что-то уже работающее, а не "черновик".
V>У нас в конторе на одной работе был специальный чувак, у которого с утра была одна задача, найти нестабильные коммиты и откатить их. Многие его за это недолюбливали, только был он далеко от офиса (наверно на всякий случай).
Его случайно не Jenkins звали?

Здравствуйте, ·, Вы писали:

V>>·>С бэкапами почти ничего нельзя интересного сделать.
V>>Как это ничего? А ручками помержить?
·>Для мержа нужен 3-side, а бэкапы линейные. Т.е. основной юзкейс это "откатиться до бекапа на дату D", откуда там мерж?
Если не так много изменений было, то и не обязательно откатывать. Можно мержить и поверх.

Здравствуйте, ·, Вы писали:

A>>>Мне удобнее видеть незаконченный код незакоммиченным Откатывать коммиты...как-то не очень, коммит — это что-то уже работающее, а не "черновик".
V>>У нас в конторе на одной работе был специальный чувак, у которого с утра была одна задача, найти нестабильные коммиты и откатить их. Многие его за это недолюбливали, только был он далеко от офиса (наверно на всякий случай).
·>Его случайно не Jenkins звали?
Не, этот был круче в разы. Находил буквально коммиты в последних 10 при количестве тестов в ~600 штук запускающихся каждый не меньше 3 сек и суммарно больше часа. Даже специальная софтина для этого чувака была придумана, где можно было галками подбирать тесты, которые потенциально должны зафейлиться, чтобы не прогонять всё. Дженкинс с таким тогда "лапу" сосал.

Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?
Т.е. предлагают еще значительнее увеличить ущерб? До следующего периода отдыха работник выдаст треть своей производительности.
Ребята, я читаю и у меня глаза округляются от вашего срача, как бы похитровывернутее заставить систему контроля версий исполнить роль бэкапа.

Здравствуйте, Vain, Вы писали:

Pzz>>Меня нервирует сломанная ветка в репозитории.
V>Это лучше чем вообще потерять. К тому же она хотя бы историю будет иметь, есть возможность откатиться. А в несуществующей ветке откатиться нельзя.

Надо сказать, я в жизни своей ничего не потерял...

Здравствуйте, sharpcoder, Вы писали:


S>В пределах месячной заралаты может быть ответственность легко, в данном случае можно лишить недельной заралаты за такое.
S>http://base.garant.ru/12125268/39/#friends

К случаю топикстартера не относится. Это не материальный ущерб. Даже "материализовать" его невозможно.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Gradiens, Вы писали:

G>>Теперь к вопросу оплаты.
G>>Если чел на субподряде попросил столько же денег, сколько штатный сотрудник — сам себе злобный Буратино. Надо учитывать риски.
G>>По личному опыту считаю нормальным повышающий коэффициент от 1.5 до 3-х в зависимости от обстоятельств.

PD>Хорошо. Давай мысленный эксперимент.

PD>Тебе предлагают некую работу. Как сделать все, что требуется — ты знаешь. Сроки тебя устраивают. Конечно, в ходе работы могут возникнуть изменения, но, допустим, задача достаточно хорошо сформулирована, так что мелкие изменения ее сложность серьезно не повышают, а крупные изменения либо невозможны, либо могут быть предметом дополнительного соглашения во 2 фазе, если она наступит.

PD>Ты согласен.

PD>Тебе предлагают 2 варианта оплаты

PD>1. С тобой заключается договор, сумма вознаграждения N рублей, срок M месяцев.
PD>2. Тебя принимают в штат на M месяцев с зарплатой N/M в месяц. Присутствие в офисе не требуется, рабочий день — по твоему усмотрению, ты лишь должен через M месяцев сделать продукт.

PD>Вопросы, связанные с различным налогообложением, вынесем за скобки. Будем считать, что N — это сумма после уплаты налогов. Возможно, работодатель потратит с учетом налогов разные суммы, но это его проблемы, а не твои.

Вопросы, связанные с налогами тяжело вынести за скобки.
У работодателя/заказчика есть бюджет, в который надо вписаться. Сколько из этого бюджета получишь лично ты, а сколько уйдет в налоги — ему пофиг. Это тебе не пофиг. Грубо, очень грубо, при тех же затратах заказчика ты получишь на треть больше, если ты — ИП, а не штатный сотрудник.
То есть хотя бы из этого можно просить больше )

PD>Я согласен, что юридически это разные варианты, а ну а по существу ? В чем отличие рисков ?
PD>Естественно, я предполагаю, что ты добросовестный исполнитель и не намерен ни получать зарплату по варианту 2 в течение M-1 месяца, ничего не делая, ни получить аванс по варианту 1, а потом исчезнуть.

Так по существу отличие в том, кто несет риски.
Повторюсь, штатный сотрудник несет намного, намного меньше рисков чем, скажем, ИП-шник на субподряде.

Примеры:
Исполнитель заболел.
Если он — сотрудник — ничего не попишешь. Придется ему оплачивать больничный (небольшой, но все же), и сдвигать сроки.
Если он — подрядчик — никто ничего ему не оплатит. К тому же придется ему потом впахивать сверхурочно чтобы наверстать упущенное.

У работодателя что-то изменилось/добаваилось в требованиях. (А это происходит всегда. Видимо, расширение объема работ — это некий закон природы, постоянный как расширение вселенной)
Для сотрудника либо работодатель продлит контракт, либо останется с обрезанным функционалом.
Для подрядчика — надо с боем сопротивляться всем изменениям, или с боем выгрызать для них оплату.

Оказалось, оценка сроков/сложности неверна. Не важно, чья это ошибка. Но это — самая распостраненная ошибка даже для очень опытных. Нельзя дать сколько-нибудь точную оценку большому проекту. Это как по моему скромному опыту, так и по мнению многих классиков, от Де Марко до Спольски.
Для сотрудника — то же что и в предыдущем пункте. Честно работает, пока контракт не закончится. Закончил работу раньше — молодец, сиди кури бамбук, зарплата идет. Но это бывает редко. Чаще — закончилось время, а проект по объективным причинам не готов. И заказчик либо платит еще, либо хоронит недоделанный проект.
Для подрядчика — это его риск. Не успел — работай дальше без оплаты, пока не доделаешь. Да еще, как правило, попадаешь на пени.

Ах, да, надеюсь, никто не забыл, что если ты ИП-шник, то отвечаешь своим имуществом? В случае колоссальных продолбов наемный работник просто увольняется, а вот ИП-шник останется без последней рубашки. От продолбов никто не застрахован.


PD>Я понимаю разницу, если речь идет об изготовлении чего-то материального. В этом случае, конечно, предприниматель должен сам искать поставщика материалов и комплектующих, снимать помещение, нанять работников и т.д., а принятый на работу потребует, чтобы материалы и комплектующие ему предоставил отдел снабжения, а помещение вообще не его забота. Тут у предпринимателя риск — а вдруг детали не найдутся, а вдруг они дороже будут, чем он думал, а вдруг дядя Вася запьет и придется срочно искать кого-то еще.

Вот в случае чего-то материального бывают даже более простые ситуации. Допустим, ты профессиональный резчик матрешек — ты прекрасно знаешь свою производитльность, и можешь оценить риски с поставщиками и т.д. То есть ты понимаешь, за сколько ты вырежешь 10000 матрешек.
А если ты профессиональный разработчик в ентерпрайзе — ну не сможешь ты оценить серьезный проект с приемлемой для заказчика точностью. Даже мелкие задачи могут легко расходится с оценкой в два раза.

PD>А у программиста в чем отличия, кроме чисто юридических ?
Так что, в итоге, отличия в том, кто несет риск не только де-юре, но и де-факто.

Здравствуйте, Vain, Вы писали:

V>>>·>С бэкапами почти ничего нельзя интересного сделать.
V>>>Как это ничего? А ручками помержить?
V>·>Для мержа нужен 3-side, а бэкапы линейные. Т.е. основной юзкейс это "откатиться до бекапа на дату D", откуда там мерж?
V>Если не так много изменений было, то и не обязательно откатывать. Можно мержить и поверх.
А "много" это сколько? А если таки "много"? А как собственно бэкап восстановить? Как запустить мержилку? А эта мержилка есть интегрированная в твою любимую IDE?
Ты вроде обещал "проще", а внезапно столько неудобных вопросов возникает.

Здравствуйте, Vain, Вы писали:

V>>>У нас в конторе на одной работе был специальный чувак, у которого с утра была одна задача, найти нестабильные коммиты и откатить их. Многие его за это недолюбливали, только был он далеко от офиса (наверно на всякий случай).
V>·>Его случайно не Jenkins звали?
V>Не, этот был круче в разы. Находил буквально коммиты в последних 10 при количестве тестов в ~600 штук запускающихся каждый не меньше 3 сек и суммарно больше часа. Даже специальная софтина для этого чувака была придумана, где можно было галками подбирать тесты, которые потенциально должны зафейлиться, чтобы не прогонять всё. Дженкинс с таким тогда "лапу" сосал.
У нас этим кластер занимается. 10к тестов (некоторые довольно медленные) — но на сотне многопроцессорных серваках выполняется за 15мин — уже реально проверять почти каждый коммит. А если была пачка коммитов одновременно, то практически всегда очевидно какой из этих ~5 коммитов завалил конкретный тест.

Здравствуйте, Gradiens, Вы писали:

Не скажу, что ты меня убедил на 100%, но определенная логика в твоих соображениях есть, признаю.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тебе предлагают некую работу. Как сделать все, что требуется — ты знаешь. Сроки тебя устраивают. Конечно, в ходе работы могут возникнуть изменения, но, допустим, задача достаточно хорошо сформулирована, так что мелкие изменения ее сложность серьезно не повышают, а крупные изменения либо невозможны, либо могут быть предметом дополнительного соглашения во 2 фазе, если она наступит.

PD>Тебе предлагают 2 варианта оплаты
PD>1. С тобой заключается договор, сумма вознаграждения N рублей, срок M месяцев.
PD>2. Тебя принимают в штат на M месяцев с зарплатой N/M в месяц. Присутствие в офисе не требуется, рабочий день — по твоему усмотрению, ты лишь должен через M месяцев сделать продукт.

В первом случае ты можешь не получить сумму N вообще, а еще можешь неограниченно долго облизывать заказчика, чтобы он акты подписал. Плюс еще геморрой собственно выбить деньги.
Во втором случае ты гарантированно получаешь сумму N за M месяцев, независимо от реального результата. А еще тебе отпуск начисляется если ты более 6 месяцев работаешь и при увольнении должны выплатить компенсацию.

PD>А у программиста в чем отличия, кроме чисто юридических ?
Вот и считай что тебе выгоднее.

Здравствуйте, ·, Вы писали:

V>>>>·>С бэкапами почти ничего нельзя интересного сделать.
V>>>>Как это ничего? А ручками помержить?
V>>·>Для мержа нужен 3-side, а бэкапы линейные. Т.е. основной юзкейс это "откатиться до бекапа на дату D", откуда там мерж?
V>>Если не так много изменений было, то и не обязательно откатывать. Можно мержить и поверх.
·>А "много" это сколько? А если таки "много"? А как собственно бэкап восстановить? Как запустить мержилку?
Господа программисты разучились бекапить и мержить руками? Везде вам рюшечношашечная ИДЕ подавай? А как ты думаешь по-твоему мержили без любименькой VCS?

V>А эта мержилка есть интегрированная в твою любимую IDE?
А нафиг оно надо?

·>Ты вроде обещал "проще", а внезапно столько неудобных вопросов возникает.
Я проще не обещал, а вот хоть как-то будет.

Здравствуйте, ·, Вы писали:

V>>·>Его случайно не Jenkins звали?
V>>Не, этот был круче в разы. Находил буквально коммиты в последних 10 при количестве тестов в ~600 штук запускающихся каждый не меньше 3 сек и суммарно больше часа. Даже специальная софтина для этого чувака была придумана, где можно было галками подбирать тесты, которые потенциально должны зафейлиться, чтобы не прогонять всё. Дженкинс с таким тогда "лапу" сосал.
·>У нас этим кластер занимается. 10к тестов (некоторые довольно медленные) — но на сотне многопроцессорных серваках выполняется за 15мин — уже реально проверять почти каждый коммит.
Не, чувак с инструментом дешевле стоил.

·>А если была пачка коммитов одновременно, то практически всегда очевидно какой из этих ~5 коммитов завалил конкретный тест.
Очевидно, не очевидно, а искать всё равно надо, повторно прогоняя и анализируя результат.

Здравствуйте, John1979, Вы писали:

J>есть мнение, что ситуация, когда у тебя 3 дня лежит код который даже не собирается, не очень нормальна.

У меня бывает неработающий код лежит на рабочем ноуте две-три недели — точнее, он непроверенный — мож работает, а мож и нет

Здравствуйте, Vain, Вы писали:

V>Скорее, об отсутствии банального опыта, что такие ситуации таки случаются и, соответственно, опыта их недопущения/разрешения.
Фигня. В начале нового проекта подобная ситуация совсем нередка, ибо обычно педалится каркас приложения, и бывает, что неделями код представляет из себя тонну слабосвязанных двуг с другом "инфраструктурных" классов.

Здравствуйте, Андрей Бабошин, Вы писали:

АБ>Совсем-совсем плохо обычно выявляется на испытательном сроке. Однако, иногда факапы бывают в управлении и сотрудник успешно проходит испытательный срок (по факту истечения времени)
Как раз такие "инфраструктурные" факапы на испытательном сроке совсем не удивительны, т.к. человек ещё не знает, как тут и что принято. А если устроить 100500 часов тренингов для новичком, как делают некоторые конторы, то после их окончания у человека будет такая каша в голове, что лучше его вообще к коду не подпускать первое время после них Эта проблема особенно остро стоит в публичных компаниях, т.к. правила многих бирж требуют обязательного прохождения определённых тренингов по insider trading, плюс в зависимости от типа бизнеса могут быть похожие требования, установленные законом (например в банках у нас требуют проходить "антиотмывочные" тренинги, на которых скорее учат, как отмывать бабло, а не как с этим бороться ).

Здравствуйте, bazis1, Вы писали:

B>Я про то, что эти 2 недели могут быть последней каплей.
Тогда это не причина, а повод.

Здравствуйте, koandrew, Вы писали:

V>>Скорее, об отсутствии банального опыта, что такие ситуации таки случаются и, соответственно, опыта их недопущения/разрешения.
K>Фигня. В начале нового проекта подобная ситуация совсем нередка, ибо обычно педалится каркас приложения, и бывает, что неделями код представляет из себя тонну слабосвязанных двуг с другом "инфраструктурных" классов.
А я не про "жертву" говорил. А про читак апеллирующим ко всяким фаулерам без банально своего опыта за плечами.