Оповещение о том, что пакет действительно зарелизился и стал доступен в каком-то репозитории, это полезная вещь. Такие штуки довольно просто отслеживать, когда знаешь какой экосистеме принадлежит та или иная библиотека.
Правильнее всего делать не реализовывать этот механизм целиком в AllMyChanges, а положиться на один из существующих трекеров PyPi, Ruby Gems и тд., то есть договориться с другими ребятами, которые уже умеют это делать, но не умеют искать и парсить ченьджлоги. Мы работаем над этим. Скоро всё будет.
Никита, под пунктом 1, ты, вероятно, имеешь в виду Каталог? Мне тоже не нравится, как он там сейчас организован. При большом количестве неймспейсов и пакетов, оно работает плохо. Скоро этот раздел будет переделан.
Что касается работы кнопки follow, то так и задумано. Слежение за выходом новых версий не имеет смысла без возможности присылать куда-то обновления. А для этого надо зарегистрироваться.
Всё верно. Я не копирайтер. И если тут есть грамотеи, я прошу оставлять свои стилистические замечания в этом тредике. Они помогут слудующим статьям быть лучше.
Специфика софтварных библиотек в том, что очень часто названия будут пересекаться. Вероятность того, что и для javascript и для python c ruby и c C# найдется хотя бы одна имплементация с названием «unittest» или «requests», стремится к бесконечности. Поэтому в случае с allmychanges, логичнее всё-таки выделять некие ключевые пространства типа «язык» или «сфера применения». Пример сферы применения — «databases».
Кстати, в AllMyChanges каталог пакетов требует значительной переделки. Хочется сделать так, чтобы прямо по урлу типа allmychanges.com/p/db были видны все пакеты этого namespace.
Да, Тимофей, мне и самому иногда бывает сложно придумать в какой namespace положить проект. Идея тегов кажется разумной. Но namespace нужен всё-равно, чтобы у каждого пакета или библиотеки был свой пермалинк.
Однако с тегами не всё так просто. Дело в том, что скоро на сервисе должна появиться возможность группировать библиотеки посредством тегов, но это, вероятно, не те теги, что ты хочешь.
Идея вот в чём — не привязывать пользователей жестко к понятию «проект», как это делает VersionEye или Gemnasium, но давать проставить библиотеке один или несколько тегов так, что потом по тегу можно увидеть сразу все изменения, которые к нему относятся. И эти теги будут видны только тебе, но не другим пользователям. В качестве тега можно будет выбрать имя проекта, hostname виртуалки или название окружения, где ты эту библиотеку используешь. Важно лишь то, что теги потом будут служить тебе напоминанием, где эту используется эта библиотека, и где её надо обновить, если вышел критический релиз.
Я пока не понимаю, как красиво и понятно дать возможность смешивать публичные и приватные теги. Разве что сделать возможным задавать более одного namespace, превратив их тем самым в публичные теги. Как ты считаешь, такой вариант годен или можно лучше придумать?
Не вижу смысла писать про это. Тот, кто в программировании разбирается, и сам сможет такой плагинчик написать, ничего сложного тут нет. А разжевывать все досконально для остальных — зачем?
Бывает так, что ошибки возникают на клиент-сервере при работе с базой, но при использовании удалённого sentry-сервера мы не потеряем оповещение.
А что произойдет, если сетевое соединение между клиентом и удаленным сервером пропало? Та же хрень. Так зачем городить сложную систему передачи данных по HTTP? Лучше уж сразу в базу писать.
Главое — научиться контролировать что ты делаешь и оптимизировать СВОЙ рабочий процесс. Ну а единственная команда vim, которую действительно стоит выучить, это :help.
Абсолютный bullshit. Было бы гораздо правильнее, если бы картинка генерилась на основе данных, собранных Google Analytics для этого сайта. Не понимаю, почему они не сделали именно так.
Спасибо за ссылку. Проект действительно выглядит весьма интересно.
Правда то, что внешне выглядит здорово, на самом деле может: а) совсем не держать нагрузку, б) плохо масштабироваться (неизвестно какие там объемы данных), с) тяжело администрироваться (это когда весь проект, днем и ночью держат на своих плечах титаны-админы :))
Не согласен на счет «несравнимого». Во первых, у Mongo нет HTTP интерфейса, во вторых, и то и то документ-ориентированные базы, и я считаю что вполне разумно их сравнивать.
Лучше аргументируйте, почему, по вашему, MongoDB «более мощная и универсальная»?
Посмотрите. То что для Linux нет версии меня и самого удручает. С другой стороны, у Адоба и две то версии не очень то получается поддерживать. В некоторых местах их поведение чуть чуть отличается.
Правильнее всего делать не реализовывать этот механизм целиком в AllMyChanges, а положиться на один из существующих трекеров PyPi, Ruby Gems и тд., то есть договориться с другими ребятами, которые уже умеют это делать, но не умеют искать и парсить ченьджлоги. Мы работаем над этим. Скоро всё будет.
Что касается работы кнопки follow, то так и задумано. Слежение за выходом новых версий не имеет смысла без возможности присылать куда-то обновления. А для этого надо зарегистрироваться.
Кстати, в AllMyChanges каталог пакетов требует значительной переделки. Хочется сделать так, чтобы прямо по урлу типа allmychanges.com/p/db были видны все пакеты этого namespace.
Однако с тегами не всё так просто. Дело в том, что скоро на сервисе должна появиться возможность группировать библиотеки посредством тегов, но это, вероятно, не те теги, что ты хочешь.
Идея вот в чём — не привязывать пользователей жестко к понятию «проект», как это делает VersionEye или Gemnasium, но давать проставить библиотеке один или несколько тегов так, что потом по тегу можно увидеть сразу все изменения, которые к нему относятся. И эти теги будут видны только тебе, но не другим пользователям. В качестве тега можно будет выбрать имя проекта, hostname виртуалки или название окружения, где ты эту библиотеку используешь. Важно лишь то, что теги потом будут служить тебе напоминанием, где эту используется эта библиотека, и где её надо обновить, если вышел критический релиз.
Я пока не понимаю, как красиво и понятно дать возможность смешивать публичные и приватные теги. Разве что сделать возможным задавать более одного namespace, превратив их тем самым в публичные теги. Как ты считаешь, такой вариант годен или можно лучше придумать?
А что произойдет, если сетевое соединение между клиентом и удаленным сервером пропало? Та же хрень. Так зачем городить сложную систему передачи данных по HTTP? Лучше уж сразу в базу писать.
Главое — научиться контролировать что ты делаешь и оптимизировать СВОЙ рабочий процесс. Ну а единственная команда vim, которую действительно стоит выучить, это :help.
Такая моя ИМХА :)
Правда то, что внешне выглядит здорово, на самом деле может: а) совсем не держать нагрузку, б) плохо масштабироваться (неизвестно какие там объемы данных), с) тяжело администрироваться (это когда весь проект, днем и ночью держат на своих плечах титаны-админы :))
Интересен был бы «взгляд изнутри».
И где пруфлинк?
Лучше аргументируйте, почему, по вашему, MongoDB «более мощная и универсальная»?