Как стать автором
Обновить
0
0

Программист

Отправить сообщение
Оператор… не подходит для передачи коллекций с большим количеством элементов. Он представляет собой синтаксический сахар для сворачивания-разворачивания ряда аргументов в объявлении функции или метода. В действительности, аргументы передаются по-отдельности, с соответствующим расходованием памяти и времени. Если бы свёрнутые аргументы реально передавались массивом, в сочетании со строгой типизацией можно было бы реализовать типизированные коллекции, но увы.
Если тур разбивается на несколько игровых дней, группировка более чем желательна. Отложенный же матч вырывается из своего тура, и возвращать его на родное место некорректно. Лучше сделать дырку и сохранить игровую последовательность. Возможно, в один условный тур потребуется сгруппировать отложенные матчи из разных туров, в чемпионатах предусмотрены резервные даты. Например, в Испании недавно был отложенный матч Сельта — Реал. Зато все срезы будут соответствовать ходу чемпионата.

Пропуск игры в любом случае лучше предусмотреть, ведь в группе с нечётным количеством участников в каждом туре есть отдыхающий.
У Мартина Гарднера, и не только у него, по-моему, приводилась ссылка на статью 1961 года о построении обучающегося «автомата» на спичечных коробках. Есть в сети на русском языке, поищите MENACE (Mathbox Educable Naughts and Crosses Engine).
Немного внешней координации, и можно действовать по такой схеме:

1) разработчик делает в своей ветке rebase master, разрешает конфликты.
2) ветка вливается в master.
3) переходят к следующему разработчику или ветке.
При наличии composer, поставьте fxp/composer-asset-plugin, чтобы исключить ось nodejs — npm — bower.
Чутье хорошо для мелкой конторы

Это верно, я работал в компаниях, где работа отдела легко обозрима.
Да что ж вас инфантилизм этот никак не отпустит. Это не тот случай. У нас учёт времени внедрялся с конкретными целями: выставлять контрагентам счёта на основе времени, и как «потогонная система» (фрейдистская оговорка руководителя). Я думаю, внедрение как раз показало расхождение между цифрами и ощущениями о полезности сотрудников. Мне не говорили работать больше: мне говорили записывать больше. А я всё носился с нормами гигиены труда, разными исследованиями эффективности работы программистов, по которым утилизация 2/3 времени в пользу считается прекрасным результатом. Учёт времени упрощает вопрос оплаты, но как инструмент, он более груб, чем элементарное чутьё начальника.
Где вы у меня увидели, что я перекладываю ответственность за свою работу на руководство?

Я не руководитель и никогда им не был, но у меня на каждом месте работы были свои представления о том, кто как работает. Со своей колокольни, исходя из своих ценностей. И у меня есть основания считать, что я часто оказываюсь прав в своей оценке. Так почему я должен считать, что таких мыслей нет у руководства? Это их прямая обязанность: смотреть, кто как работает, а если провисает, то помочь, мотивировать. Или расстаться.
Знает, знает. Если не знает, то это плохое руководство. Со стороны, над схваткой, всё видно. И создаваемую каждым ценность, и качество кода, и насколько вносимые изменения встраиваются в проект, и как эти изменения влияют на работу других сотрудников, и социальный фактор, остающийся за кодовой базой. А вы хотите это измерить только потраченным временем?
Я не об этом. Учёт времени плох потому, что искажает реальное восприятие качества работы сотрудников, хотя должен, по идее, наоборот. Я думаю, руководство прекрасно знает, кто и как работает. Но когда появляется цифра, заманчиво выжать из человека все 100%. Отсюда нереальные нормы в 7-8 часов за рабочий день.

Далее, у каждого программиста индивидуальный подход к учёту времени. Я видел разные. Один фиксирует 15-минутными квантами, округляя в большую сторону. Другой — время от начала до конца, включая все свои отвлечения по офису. У кого-то даже получалось больше фактического времени нахождения в офисе. И если вы будете честно выполнять свою работу, то через год-полтора сгорите. Это отрицательный отбор.

Я для себя выводы об этой системе сделал: больше никаких внешних требований по времени. Хотя для личных проектов использую toggle, мне это интересно.
А вот не всем позволяет совесть, понимаете? Работодатель может даже сам просить сотрудника об этом, если, например, выставляет счета своим контрагентам на основе вашего трекинга. Но это неправильно. Сама система неправильная, ущербная. Время программиста неоднородно. Зафиксированное время ни о чём не говорит.
По идее, такие кадры должны расти быстрее всех.
Когда выгорите, будет поздно. Выхлоп будет падать стремительным домкратом.
И вам тоже стоит задуматься :-)
Какая самодисциплина, вы же не сами поставили себе этот софт? Самодисциплина в голове, а это обычный кнут. Лучше всего мотивирует по-настоящему интересная работа, посмотрите у Фрайда и Хенссона в «Remote».
Мой совет, смените работу. Требование заносить определённое количество часов — это верный путь к выгоранию.
Именно так, сеньорские зарплаты растут меньше остальных. Но, например, за последний год PHP senior выросли неплохо: рынок.
Такое вполне возможно, если смена места работы совпадёт с качественным ростом квалификации. Но под уровень рынка уж точно подстроитесь.
Тут важный нюанс, что у гонщика есть стартовая позиция, да и в ходе гонки она определяется физическим положением болида. В футбольном чемпионате физических ограничений нет, в начальной стадии точно будет беспрерывная чехарда.
Получается довольно любопытный виджет, спасибо. Благодатная тема для исследования и совершенствования, поскольку в каждом чемпионате свои нюансы при равенстве очков. Вижу естественным развитием вынесение конфигурации чемпионата в файл с данными. Причём, в формате JSON, а не CSV, всё-таки.

В самой анимации смущает изменение номера места до перемещения. Может, лучше разбить на три этапа? Начисление очков, сортировка, обновление номера.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность