Как стать автором
Обновить
2
0
Максим Лапшин @erlyvideo

Пользователь

Отправить сообщение

прийдете на доклад?

у главбуха есть помощники, у генерального директора есть зам, уборщица в принципе — это функция, а не человек.

Так что да, на всех важных позициях есть резерв.

А ещё, что очень неприятно, его нельзя уволить если он например начинает активно разваливать отдел.

Но с другой стороны в попытке уволить такого неприятного человека, может наконец-то появиться внятный перечень требований к сотруднику и внятный план, которого не было до этого.

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

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

Он вроде есть, числится где-то, но кто будет его увольнять то?

Такая неэффективность может появиться в любой компании от 50 человек.

совершенно непонятно, на основе чего вы делаете такие заверения на тему того, что там в головах у МЦСТ

не, проблема не в feature flags. Проблема в том, что может тупо уйти полторы недели на то, чтобы написать 10 строк кода.

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

у нас всё таки немножко специфика: задачи бывают сложные. Делали бы магазин/вебпроект, там задачи лучше дробятся и прогнозируются.
фича доделана, фиче-ветка мержится в мастер и ветка навсегда удаляется, больше никогда не переоткрывается.

Всё это должно занимать не больше 1-2 недель времени _кодирования_ (со всеми прототипированиями, продумываниями и прочим, бывает и побольше конечно) и мержреквест должен быть обозрим и инспектируемым коллегами.

Если кто-то 4 недели самозабвенно писал код, то конечно никто не может это вмержить в мастер, потому как оценить последствия от таких огромных изменений нереально.

Оказывается то, что мы у себя внедрили, называется trunkbaseddevelopment.com
очень похоже, что не вы общались с западными вендорами. NDA — это обычная практика везде и во всём и не у нас она придумана.
> через некоторое количество лет производители GPU просто добавили нужные аппаратные блоки в свои чипы

а потом выясняется, что производители GPU забили большой длинный болт на поддержку интерлейса и вообще не очень горят повышать стабильность своих закрытых библиотек.

И понимаешь, зачем нужен FPGA.

Какой кодек вы реализовывали на FPGA?
отделывайся =)

Лампы действительно офигенные, куда смог — туда их поставил.

Очень хочется от них диммируемых двухцветных ламп.
У нас в flussonic ещё и своя реализация tftp и попытки ускорить его работу в убуте в несколько раз.
устаревшего H.264 (слева) с современным VP9 (справа)

я понимаю, что перевод есть перевод, но не оставлять тут комментарий на тему ангажированности авторского текста — это не очень хорошо

проблема то понятная: вы не даете доступ к своим данным, зато с особой радостью хантите сотрудников вендора.
ясно.

Это сильно отличается от того, как у нас принято.

Каждый девелопер коммитит в фиче-ветку, которая как правило дольше 1-2 недель жить не должна.

Мержить её можно только при полном позеленении.
ага, интересно.

У вас можно мержить MR если тесты не все зеленые?
и как, получается отдетектить такое?
У меня стойкое ощущение, что «релизные команды» — это всё как раз от страха того, что не выстроен процесс жизни без них.
О, очень интересная тема.

Следующий вопрос будет про ограничение GPU.
Очень крутой набор докладов

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность