Как информировать сообщество о новой библиотеке?

Question

[Oxoron]

Добрый день.
Я создал небольшую библиотечку для упрощения написания запросов к Azure Storage Table. Где о ней стоит написать? Пока что в голову приходят только reddit и хабр.

Comments

[Rou1997]

А цель у вас какая?

[Oxoron]

Rou1997: Слава, известность, девушки у ног. Если же серьезно - всех основных целей при разработке я добился. Но библиотечка вышла хорошей, и просто хочется чтоб ей пользовались.

[Rou1997]

Oxoron: Если хорошая и реально используется, то продавать нужно.

Answer 1

[Станислав Макаров]

1. Делаете хороший README, разумеется на английском, где указываете, как ей пользоваться, и что ей требуется.
2. Делаете несколько примеров (именно рабочий код в подпапке examples) для основных кейсов применения библиотеки.
3. Льете на опенсурсный хостинг, если еще не сделали.
4. Настраиваете CI (например на AppVeyour), это не обязательно, но желательно.
5. Заливаете готовые пакеты на NuGet. Разумеется, вы должны научиться упаковывать свою библиотеку в нормальный пакет. В nuspec ставите годные правильные теги.
6. Покрываете тестами, хотя бы частично.

После этого к вашей библиотеке начнут относиться более-менее серьезно.

7. Можете попробовать на CodeProject рассказать, там часто рассказывают именно про библиотеки.

Comments

[Oxoron]

Станислав Макаров по пункту 2: создать отдельный проект в подпапке examples и приНюГетить к нему основной?

[Станислав Макаров]

Oxoron стандартная структура репы для проектов на C#/F#, которой я сейчас стараюсь придерживаться:
/docs - документация
/examples - проекты/проект с примерами использования библиотеки. Либо один проект с несколькими файлами кода, если примеры простые, либо, если примеры достаточно объемные, отдельные проекты в подпапках
/src - основной исходный код, "мясо" библиотеки. Также подпапки для проектов.
/tests - тесты, структура аналогична примерам.

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

[Oxoron]

Станислав Макаров: Спасибо за подробный ответ.

[Станислав Макаров]

Oxoron самое главное-то не сказал) Можно принюгеть в примеры, но тогда вам (и тому, кто скачает исходники библиотеки) будет сложнее модифицировать библиотеку, т.к. примеры будут запускаться с релизной версией библиотеки из Нюгета. Так что как по мне лучше примеры (и тем более - тесты, иначе в них нет смысла) линковать к основному проекту/проектам в "src" через обычные проектные зависимости, которые управляются Студией. Я обычно собираю всё в один солюшен, и просто ставлю зависимости.

Answer 2

[Денис Инешин]

Самое главное в хорошей библиотеке - это ваше желание ее поддерживать. Прежде всего оформите проект как следует: GitHub + хорошее описание (примеры API, демки) + немного дизайнерской работы, чтобы привлечь внимание (хорошее лого по крайней мере). Напишите тесты.

Далее о проекте можно будет написать, хоть на тот же хабр. Но учтите, на хабре сразу же посмотрят вашу библиотеку, кто-то ее проверит и будет очень плохо, если она не работает или содержит баги.

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