FabiBoom

в закладках лежат пару ссылок по этой теме - ждут своего часа ) - link и link2

Хороший вопрос!
Я интересовался и получил ряд ответов от самих Заказчиков. Так, сказать, их мировозрение в этом плане.

Со стороны Заказчиков:
1. Раз ты работаешь на фрилансе - ты лох, потому, что не смог никуда устроиться.
2. Если ты фрилансер - ты раб, который зарабатывает, чтобы не умереть с голоду. Поэтому, много тебе и платить не за чем.
3. Нет гарантий для нас, что ты сделаешь всё на совесть. Мы не понимаем как сделать самим и, при этом, хотим хорошо сэкономить.
4. (Про время) Мы оцениваем не сложность проекта и твоё умение и опыт, а время, которое никак не может быть дороже медианы фриланса по этому направлению.
5. Нам нужно быстрее, т.к. это получается дешевле для нас, т.к. мы оцениваем время, а не сложность нашего проекта.
6. Все фрилансеры низкоквалифицированные рабы.
7. Каждый, кто мнит себя опытным и будет просить больше, будет сидеть без работы, т.к. высокая конкуренция и есть большой выбор исполнителей на рынке за копейки.
8. Фриланс - это рабы IT сферы для нашего бизнеса.
9. Мы всегда ищем тех, кого сможем обмануть в плане оплаты за работу и их почти 100%.
10. Нам ничего не стоит сбросить сумму оплаты в любой момент сославшись на угрозу отрицательного отзыва.
11. Мы не дорожим репутацией, в отличие от фрилансеров.
12. Вы сами ничего не делаете: всё берёте с гитхаба уже готовое. За что вам платить?!

(и ещё можно продолжать и продолжать...)

И сразу возникает вопрос:
Ждать ли роста дохода фрилансеров IT-сферы и когда?
Ответ прост: когда все IT-шники поймут, что нужно ценить труд друг друга, что они не конкуренты друг другу, а единый целый "организм", который может сам за себя постоять и накормить вне зависимости от места работы и размера дохода.
Итог: Не нужно работать и "ломать" глаза на тех, кто этого не понимает, а значит, и НЕ ЦЕНИТ!

А пока разделяйте качество своих трудозатрат на "хлеб" и на "работу" и сразу озвучивайте 2 суммы заказчикам.

Литерал 0177 в языке С++ - это восьмеричный целочисленный литерал, который имеет тип int и положительное значение 127 - семь младших битов равны 1, а остальные (старшие) равны 0.

Вы не указали в своем вопросе какой тип имеет n, что делает ваш вопрос несколько бессмысленным (или полностью бессмысленным), но если предположить, что n - это переменная некоего целочисленного типа, то в данном выражении операнды оператора & будут неявно приведены к одному общему целочисленному типу (к одной ширине). Этот процесс называется usual arithmetic conversions (UAC). Если в процессе UAC придется расширить операнд 0177, то он будет дополнен до требуемой ширины дополнительными нулевыми битами в старшей части.

Так образом, даже после такого преобразования операнд 0177 по-прежнему будет представлять собой битовую "маску" из семи единичных битов в младшей части и нулевых битов в старшей части. Оператор & в такой ситуации "сохранит" семь младших битов исходного значения n и обнулит остальные биты.

Пусть статья и комментарии будут разными агрегатами. У комментариев будет свой домен.

Можно в контексте комментариев сделать свой класс статьи( Article ). Он даже не будет сущностью:

class Article {
  private UUID id;
  
  private CommentsRepository comments;
  
  ...
  
  public void function addComment(commentData: commentData) {
    this.coments.add(new Comment(this.id, commentData));
  }
}

В контексте комментариев не обязательно нужна статья - нужен только её идентификатор.
Также в контексте комментариев вовсе не нужны данные пользователя - только его идентификатор. Идентификаторы достаточно стабильная информация чтобы не бояться их шарить.

И да, в данном случае мы имеем дело просто с декомпозицией системы, к реальному DDD это мало отношения имеет, потому что domain-driven-design, он domain-driven за счёт того что конексты обсуждаются с бизнесом, а не придумываются разработчиком, в данном случае мы просто берём оттуда немножко терминологии потому что она уже стала довольно общей.

Генератор идей для пет-проджектов.

адалт сайт

1. Python
2. Прокси. Если есть возможность немного потратиться - luminati (быстрые сервера, большое кол-во, сам выгребаю с их помощью инфу с 3х спорт-сайтов ежеминутно). Если нет денег - пишите парсер для прокси-сайтов, фильтруйте эти прокси под конкретный сайт и делайте прокси ротатор, что-бы каждый запрос отправлялся с разного IP.
3. В идеале парсить не сайт, а запросы. Заходите на сайт, открываете dev tools - network и смотрите какие запросы отдаёт/принимает сайт. Очень часто на подобных сайтах используется что-то типа API и у вас будет возможность загрузить json/xml/etc по матчам, что очень сильно ускорит парсинг. Если же нет, то возвращаемся к пункту 1 и добавляем туда lxml что-бы парсить сайт.