Pull to refresh

Comments 43

Забавно, насколько иногда сходятся мысли — я тоже начал так делать, и тоже в августе. (Посредине там отпуск, на морько ЭВМ решил не брать. Да, да, я оправдываюсь перед зелеными квадратиками.)

Отличное средство для дополнительной мотивации, в самом деле.
Это немного странно, но интересно. Использовал этот же календарь во время написания текста диплома (в мае), и правда ведь помогал: нужно было каждый день хоть абзац да написать.
Счастливый вы. У меня вот так совместно с работой не получается.
Взгляните на эту картинку трезво, взгляните попристальнее — и Вы увидите, Вы поймёте тотчас же, что Wolf6969 всего-навсего отфотошопил мой календарь.

(А не то, например, цифры были бы под ним другими.)

Счастье ли в этом?
Прошу прощения. Написал случайно в ветку, а не в основание. Этот комментарий предназначался вам с вашей настоящей историей коммитов.
А вот с коммитами комментариев на Хабр у автора похуже. Есть места по19 коммитов в один день в последние 100 дней, а есть 0:


(Плотность коммитов любого автора можно посмотреть через юзерскрипт habrActivity.)
как жутко выглядит ваш Хабр, что вы сделали с ним?
Без него всё гораздо разреженее, но специально для Вас повторил скриншот на стандартном Х.:
imagehttp:

Я не встречал пока ещё средств для аналогичного учёта труда
коммиты засчитываются только при попадании в основной репозиторий — более того, только в его ветку по умолчанию или в ветку gh-pages


Странно. То есть при политике master = stable держать steak в одиночку, без pull-request самому себе, не получится? напомните старику, какая у гитхаба предпотительная политика по стабильным/дев веткам — я почему-то был уверен что master обычно стабилен — с него же все рекомендуется кланировать?
У самогó Гитхаба — политика GitHub Flow.

И она также (как и календарь) предполагает частые коммиты в master (aka stable).
Github Flow, насколько я понимаю, подразумевает master = stable. Правильно ли я понимаю, что если я работаю над проектом в гордом одиночестве и не хочу каждый день радовать пользователей новыми непротестированными коммитами в мастер — то steak мне не светит?
Есть обходные пути.

Во-первых, можно новый код покрывать сразу и тестами. Настроить Travis CI, превратив каждый коммит в master-ветке в протестированный. (Пример.)

Во-вторых, пользователям можно рекомендовать брать итоги Вашего труда не из ветки master, а из источников кода, пополняемых Вами менее часто (в те моменты времени, когда в коде Вы уверены). На самóм Гитхабе для этой цели служит механизм GitHub Releases. У разработчиков модулей для этой цели служат внешние хранилища (в Node.js — npm; в Python — PyPI; в Ruby — RubyGems; ну и так далее).
Я что-то полгода не заходил в статистику, глянул хоть…
image
Тогда и я поделюсь =)
image
Солиднее моего, молодцом!
Раз уж такое дело — тоже есть что показать)
image
Жаль, только master учитывается
А с чего Вы взяли, что только master?
Не забывайте, что роль играют только OS проекты. Я вижу ваш профиль иначе:

image
У меня максимум получилось 20 дней, а вот у Qiang Xue, архитектора Yii, наверное, рекорд: github.com/qiangxue
Я натыкался на треки у которых практически все дни были зелёные. Так что ИМХО до рекорда ему далеко :)
Не пойдёт.

У него только 17 дней нынешний период ежедневной работы, 37 дней самый длинный.

(Даже я его превосхожу по этому показателю.)

А вот у Qiang Xue — 141 день.
аа, вы про дни активности. Меня больше сама активность интересует
а вот у Qiang Xue, архитектора Yii, наверное, рекорд
Longest Streak: 177 days
:)

Я бы, впрочем, предпочел видеть данные по неделям. То есть не за последние 7 дней, а вот прямо по неделям, чтобы с чистой совестью валять пень отдыхать в выходные.
Согласен с автором на 90% т.к. сам использую такой же подход уже давно. Issues — это тоже шаг вперёд т.к. иногда бывают дни когда писать код не хочется, тогда просто запускается проект и ищутся ошибки в нем, или описываются фичи которые хочется сделать в будущем. Таких дней не много, так что особо плутовством на мой взгляд это не назовешь. Просто другой тип работы.

Вот мой трек:

image

В июле был отпуск, а предыдущий год «пропал» после смены работы :)
Да ) Специально искал в каментах. Кто-то должен был это запостить
Предложенная вами методика, calendar-driven development, реализуема на практике далеко не всегда. У меня на работе, например, используется достаточно распространенная схема с ветками master-develop и форком основного репозитория. Задачи достаточно крупные, логически и функционально законченные, в большинстве случаев выходящие за рамки 2-3 дней.

Как бы мне не хотелось стимулировать себя закрашиванием квадратиков, если я начну отправлять мелкие PR-ы, то уже через полчаса будет «ай-йа-йа-й» от человека ответственного за кодревью — проверять достаточно больший, законченные по смыслу куски кода значительно проще.

Да, моя работа — не оупенсорс, но, во-первых, многие проекты с открытыми искодниками придерживаются подобной схемы разработки, а, во-вторых, большинство хабравчан, я полагаю, всё-таки занято на ниве разработки коммерческого ПО с очень похожими требованиями к PR.
Я знаю, какой буду делать проект на гитхабе — скрипт, чтобы убирать знаки ударения из текстов автора.
Хабр поломал гитхаб? Я вижу розового единорога и сообщение об ошибке :)
Это временно. (Гитхаб починили ужé.) Случайное совпадение, вероятно.
Вы меня простите, ибо не моё, но автор LeechCraft просил передать: image
Расскажите лучше о интересных проектах, которые стоит поддерживать.
image

Текущий мой трек. Это чисто заливы кода, Issue Tracker я не юзаю
Немного моей истории про Форки. Тут было сказано что коммиты не засчитываются в Fork репозитарии. Это верно.

Но бывает это неудобно, когда репозитарий форкнут, но Пуллов в основной репозит не будет. Мое действие — я например в Support, и мне сбросили Fork статус
40 дней в русской традиции специфическая дата.
Проект еще жив?
Sign up to leave a comment.

Articles