Чтобы не нарываться на 152-ФЗ вместо регистрации лучше использовать авторизацию через социалки с открытым указанием того, что никакие ПД (которые потенциально могли бы быть извлечены из авторизуемого аккаунта) нигде не сохраняются.
moneymakerXA: Идей вообще море. Но сами по себе идеи без возможностей к реализации бесполезны. Все зависит от ваших возможностей, которые зависят от ваших данных. Говоря простым языком: "Что у вас есть такого, чего нет у других?". Ответ на этот вопрос определяет направление в котором следует искать годные для вас идеи (для другого человека эти идеи будут бесполезные, а полезные будут в другом направлении).
Если у вас в активе только базовые навыки сайтостроения, то тут сложно будет подобрать какую-то прорывную идею. Есть правда один старый универсальный рецепт: найти себе узкую нишу (в 2017 ниша должна быть очень-очень узкой, так как все узкие уже заняты) и слепить сайт под нее.
Но, если честно, то это принесет вам намноооого меньше, чем просто работа "на дядю" по своей специальности.
idebian: Законно ли некоторое действие и как это можно доказать - это разные вопросы.
У любого контента существует конкретный владелец прав, даже если контент доступен в разных источниках.
Например, какой-то фильм ОТКРЫТО доступен в торрентах, но правообладателю все равно, что я получил ЕГО фильм из какого-то открытого источника. Если он поймает меня, то отвечать в этот раз придется мне, а не моему источнику.
На счет публикации данных в другой форме представления: Ответ на этот вопрос, обычно дается в лицензии к контенту. Например в лицензиях Creative Commons этот момент очень четко прописан. Другие частные лицензии могут не упоминать это, тогда считаться, что правила публикации распространяются на ЛЮБЫЕ формы представления.
Для численных данных есть еще одна лазейка. Агрегированные данные могут быть признаны отдельным произведением вашего авторства, а не формой представления оригинальных данных. Например, я подсчитал количество слов в, защищенной копирайтом, книге и открыто публикую это значение как собственный контент. Издательство (владелец прав) не будет иметь претензий ко мне в этом случае. Но иногда и против этого тоже закладывают подводные камни в лицензии. Что-то вроде: "запрещено использовать данные данные в расчетах с целью автоматического извлечения других данных". В общем, это - довольно неоднозначная тема, которая обеспечивает работой многих юристов.
fortael: Парсер пишется под конкретную задачу. Все, что живой человек может получить вручную, парсер может получить автоматически (кроме прохождения капчи). В общих чертах написание парсера сводится к следующему: открываете в браузере инструменты разработчика, на вкладке Network смотрите отправляемые запросы в момент совершения действия (логин, переход по ссылке), на любом языке программирование пишите отправку точно таких же запросов (с теми же заголовками и параметрами). Если на каком-то шаге сервер отвечает вашему скрипту не так, как живому человеку, то смотрите в чем различие в запросах, подправляете скрипт, переходите на следующий шаг, и.т.д.
Вы не поверите, я писал именно эту задачу в далеком 2005 году. Мы выпустили демо-версию для заказчика за два месяца. Мы - это я - кодер, плюс один дизайнер (понятия UI/UX тогда еще не было), плюс четыре директора, которые ставили взаимоисключающие требования и старались любыми способами спихнуть с себя ответственность за последствия.
Проект был успешно сдан (на уровне вполне работоспособной демо-версии), но в продакшн не вышел, так как заказчик в итоге осознал бесперспективность своей "блестящей идеи" (но виду, конечно, не подал).
Через много лет после этого (где-то в начале десятых годов) я общался с человеком, который в тот момент участвовал в точно таком же по сути проекте. Его команда и их заказчик были полностью уверены в том, что их идея абсолютно оригинальная, новаторская и раньше никому в голову не приходила. Работы там было где-то на год (технологии совершенствуются, а проекты пишутся все медленнее), но и через несколько лет в продакшн я так ничего и не увидел.
У меня складывается впечатление, и мы в свое время были не первые с этой "гениальной идеей".
Это, как поиск кубка Грааля, периодически приходит в голову многим, итог всегда одинаковый, но никто (в бизнесе) не докладывает другим о своих ошибках.
А какой смысл вызывать run_until_complete ради исполнения одной простой функции?
Ваша fr выполняет один запрос и ожидает его завершения, это полностью эквивалентно синхронному вызову.
При этом ничего другого параллельно с этим происходить не может, так как вызов (снаружи) происходит из синхронного кода. Если вы запускаете event loop только для того, чтобы совершить одиночное действие и дождаться его завершения, то лучше вообще не морочить себе голову с asyncio, а делать все просто синхронно. Кстати, так будет намного быстрее при условии низкой latency (запрос к локалхосту - именно такой случай).
В чем задача: самому автоматизированно выкачать контент один раз или предоставить юзерам своей страницы доступ к чужому защищенному контенту?
Первое решается написанием парсера.
Второе невозможно в современных браузерах.
В "лихие" 90-е мы проходили решения подобных уравнений в пятом классе (это когда 10 лет от роду).
Но сегодня в школах, вместо математики, ОПК + строевая подготовка + проплаченное ЕГЭ (тест на способность давать взятки).
myspace: Это все равно будет делаться свойствами CSS. Пусть будет некоторый элемент управления (например slider), на который юзер будет воздействовать. На событие change можно повесить обработчик, который будет менять соответствующее свойство CSS.
Nikita Shchypylov: Есть масштабирование обычное Ctrl++ / Ctrl+-, но оно не влияет на размер вьюпорта, то есть масштабирующий сам контент, а вьюпорт остается фиксированный (задается через Responsive Design Mode). Масштабировать контент вместе с вьпортом, кажется, нельзя :(
Зачем им это делать, если это противоречит их интересам (это же вызовет инфляцию).