Да, многие ад-блочат. И, тем не менее, показы рекламы всегда можно обменять через google ads на деньги. Поэтому я бы не стал говорить, что реклама совсем ничего не стоит. Пускай это будут деньги не большие, но это ровно столько, сколько за такую рекламу готов заплатить рынок.
На хабре существует блог «Я пиарюсь». Я с удовольствием читаю из него статьи.
Чтобы получить возможность писать в этот блог, авторам пришлось написать минимум одну другую интересную статью для хабра, которую пользователи сочли интересной. Именно блог «Я пиарюсь» натолкнул меня на идею неоденег.
У меня есть небольшой open source продукт. О нём практически никто не знает и не использует. Тратить деньги (даже небольшие) на его раскрутку я не готов, поскольку сам продукт я делал для души, а не для заработка. А вот написать интересную статью в обмен на рекламу этого продукта, соразмерную интересности моей статьи, я очень даже готов.
К сожалению, в силу антиобщественной позиции т.н. «правообладателей», Интернет пока не способен предоставить обратную связь — адекватного вознаграждения за пополнение этих богатств. Хочется верить, что эта проблема будет преодолена.
Я, кажется, нашёл способ решить задачу адекватного вознаграждения. Подробно, с аргументацией, этот способ я изложил у себя в журнале: Вот первая статья на эту тему. Все статьи можно найти по тегу неоденьги.
Тезисно:
1. Деньги — это модель обмена товарами и услугами. Деньги не отражают суть процессов, происходящих при обмене информации на информацию, или информации на товары и услуги.
2. Если производителю информации удаётся упаковать и продавать в виде услуги (например SaaS), деньги работают отлично. В остальных случаях они не справляются и участники обмена не считают такой обмен справедливым.
3. Необходимо найти новый материал, близнец золота, которого очень много у интернет порталов, и из которого они смогут чеканить деньги для информационного обмена между пользователями.
4. Имя этому материалу — реклама. Порталы в обмен на генерацию контента пользователями могут им предоставлять «единицы рекламы», и пользователи должны иметь возможность использовать эти единицы для показов любой своей рекламы, свободно между собой обменивать, дарить, продавать, включить опцию «автоматически все мои еденицы рекламы использовать для показов Google Ads с моим ID».
Очень смешно было бы вырвать из контекста и вставить в фильм без изменений самое начало лекции по SICP где лектор расказывает о том, что Computer Science не имеет отношения ни к Science ни к Computer.
Насколько я понял автора, по поводу «Люди подводят». Он говорит тоже, что и вы. Люди подводят. Это ни хорошо, ни плохо, просто так есть и к этому надо быть готовым.
У GoF Singleton не делают полем, потому что «синглтоновость» – это часть интерфейса класса.
В IoCC YourClass не знает о том, будет IMyService синглтоном или нет, «синглтоновость» спрятана как деталь реализации, поэтому под каждый синглтон надо заводить поле, и поэтому первоначальное решение о том, что MyService должен быть синглтоном можно отменить в любой момент.
Да, переменную myService инициализировать руками не нужно, её проинициализирует IoC контейнер в соответствии с аннотациями, которые стоят над IMyService и MyService.
Да, Singleton в определении GoF, содержит фразу: «… и предоставляет к нему глобальную точку доступа...», но IoCC освобождает Singleton от этой обязанности, что позволяет «Синглетоновость» делать деталью реализации а не частью интерфейса. Моя статья именно об этом.
Кстати, модифицируемость – это один из архитектурных атрибутов качества. Т.е. грамотно спроектированная система должна позволять вносить изменения в компоненты, не нарушая целостность системы.
Singleton'овость нужно прятать по той же причине, по которой нужно прятать любые другие детали реализации. Систему рано или поздно приходится менять под новые, постоянно меняющиеся требования.
Я имел в виду то, что за последние пару лет подсказка «Возможно, вы имели в виду:» начала выпадать намного чаще, а её релевантность стала гораздо ниже.
Я просто хочу гинкго попробовать. И если окажется что это пустышка, то не страшно. Но перед тем как пробовать я хочу точно знать есть-ли у гинкго какие нибудь негативные последствия или он безвреден.
Чтобы получить возможность писать в этот блог, авторам пришлось написать минимум одну другую интересную статью для хабра, которую пользователи сочли интересной. Именно блог «Я пиарюсь» натолкнул меня на идею неоденег.
А почему, по-вашему мнению, авторам неоденьги могут прийтись не по душе?
Я, кажется, нашёл способ решить задачу адекватного вознаграждения. Подробно, с аргументацией, этот способ я изложил у себя в журнале: Вот первая статья на эту тему. Все статьи можно найти по тегу неоденьги.
Тезисно:
1. Деньги — это модель обмена товарами и услугами. Деньги не отражают суть процессов, происходящих при обмене информации на информацию, или информации на товары и услуги.
2. Если производителю информации удаётся упаковать и продавать в виде услуги (например SaaS), деньги работают отлично. В остальных случаях они не справляются и участники обмена не считают такой обмен справедливым.
3. Необходимо найти новый материал, близнец золота, которого очень много у интернет порталов, и из которого они смогут чеканить деньги для информационного обмена между пользователями.
4. Имя этому материалу — реклама. Порталы в обмен на генерацию контента пользователями могут им предоставлять «единицы рекламы», и пользователи должны иметь возможность использовать эти единицы для показов любой своей рекламы, свободно между собой обменивать, дарить, продавать, включить опцию «автоматически все мои еденицы рекламы использовать для показов Google Ads с моим ID».
В IoCC YourClass не знает о том, будет IMyService синглтоном или нет, «синглтоновость» спрятана как деталь реализации, поэтому под каждый синглтон надо заводить поле, и поэтому первоначальное решение о том, что MyService должен быть синглтоном можно отменить в любой момент.
Да, Singleton в определении GoF, содержит фразу: «… и предоставляет к нему глобальную точку доступа...», но IoCC освобождает Singleton от этой обязанности, что позволяет «Синглетоновость» делать деталью реализации а не частью интерфейса. Моя статья именно об этом.
public class YourClass { @Inject IMyService myService; // ... }YourClass не знает о том, что реализация IMyService помечена как @Singleton, поэтому мы можем эту аннотацию убирать/добавлять в любой момент.
@Singleton public class MyService implements IMyService { // ... }Возможно, не стоит выдавать подсказки, в том случае если сервис сам не уверен, ошибся я при вводе или нет.