Ranwise

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

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

Видеокурс может запилить любой дурак. Чтобы написать книгу, нужно иметь авторитет достаточный для издательства. Кроме того, текст пройдёт редактуру нескольких профессионалов. Поэтому знания в книгах качественные и систематизированные. Для начинающего это очень важные качества.

К тому же, после достижения профессионального уровня достаточного чтобы называться специалистом, вы обнаружите, что необходимые на этом уровне знания можно почерпнуть только из документации. То есть всё равно придётся читать. Много и часто.

Наконец, постоянная практика чтения неизбежно приводит к увеличению скорости чтения. И наступает момент когда прочитать учебник будет в 10 и более раз быстрее, чем просмотреть видеокурсы по той же теме и в том же объёме.

Кроме того, чтение развивает абстрактное мышление - основной инструмент разработчика.

Ну давай посмотрим на примере тостера.

Попробуем распечатать страницу с вопросом.
Для начала вопрос: для чего мы его распечатываем? Очевидно, нам интересен вопрос, и главное его решение. Именно это мы хотим распечатать на бумаге.



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



Форма комментирования. Ну что же. Наверное я отстал от современных технологий в своей деревне и во всем мире уже давно можно комментировать распечатанные страницы...

В самом конце аж три листа совершенно бесполезной информации.

В общем мы видим совершенно не оптимизированную под печать страницу.

А вот если не забывать про печатные устройства, можно все это лишнее как минимум спрятать.

Нужно изучить принципы SOLID (в своё время это просто перевернуло моё сознание)

Хорошие книги по этой теме:
- Роберт Мартин "Чистый код Создание, анализ и рефакторинг"
- Роберт Мартин "Чистая архитектура"
- Стив Макконнелл "Совершенный код"

Чтобы быстро понять о чём речь - посмотрите эту статью на Хабре (или поищите по фразе SOLID)
https://habr.com/ru/company/mailru/blog/412699/

Посмотреть в сторону предметно ориентированного проектирования (DDD).

- https://habr.com/ru/post/269589/
- https://habr.com/ru/post/269893/
- https://habr.com/ru/post/267125/

Изучить паттерны (шаблоны) проектирования.

- https://refactoring.guru/ru/design-patterns/what-i... (хороший сайт, очень толково описано + много примеров)
- https://habr.com/ru/company/mailru/blog/325492/

Освоить разработку через тестирование (TDD)
реально экономит время + код сразу получается более качественный

- https://habr.com/ru/company/ruvds/blog/450316/

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

— Мне нужно SEO, Игорь. Я запускаю прибыльный магазин по продаже белья. Между прочем на ларавель. Вопросы?
— Я понял, Олег. Скажите, а в чем полезное действие вашего магазина?
— Ладно, вообщем смотри: есть ниша, постельное белье, уже собиралась семантика, сказали что неправильно. Я как ты понял в вопросе разобрался и вижу, что нужно подготовить структуру и категории.
— Я вас понял, Олег. Скажите, а чем ваш магазин будет отличаться от тысячи таких же?
— Ха, ну ты приколист Игорь. У меня белье марки Лёвушка, таких в интернете нет, конкуренции тоже.
— Я вас понял, Олег. Скажите, а почему вы так часто упоминаете сеошника?
— Почему, почему! Потому!
— Вы упомянули, что про сео знаете достаточно мало. А достаточно ли вы знаете про маркетинг? Про информационные архитектуры? Хорошо ли вам известно о продажах? О психологии? — не останавливался Игорь, — О дизайне вам хорошо известно?
— Не грузи меня Игорь. Ты тупой? У меня есть деньги, товар и идея. Мне нужно сделать правильную структуру, собрать семантику и запустить продвижение. Сложно что ли подсказать как правильно?
— Я вас понял, Олег. А каково полезное действие магазина?
— Блин, что за вопрос? Человек ищет товар в интернете, попадает на мой сайт, покупает.
— А почему покупает? — уточнил Игорь.
— ДА ПОТОМУЧТО В ТОПЕ! — вскипел Олег.
— Я вас понял, Олег. А почему вы хотите создать магазин под SEO, а не под людей?
— Игорь я думал ты разбираешься...Что не понятно то? Чтобы человек нашел мой товар, сайт где должен быть? Во-о-о-т, в ТОПе. А чтобы быть в ТОПе, нужно что? SEO продвижение. Я уже делал магазины и зарабатывал на них, че ты понтуешься тогда?

ps я устал, но за 10 лайков быть может продолжу :-))

насколько вообще типична эта ситуация

Более чем типична

у меня есть идея грандиозного IT-проекта

Правильнее сказать, что у вас есть ощущение, что ваш проект грандиозный. Я не знаю ни одного программиста в мире, у которого нет идей "грандиозных" проектов. Помимо программистов, еще десятки миллионов других людей имеют идеи "грандиозных" проектов. В итоге же, из всего количества стартапов выживают спустя 3 года менее 5%. Из них половина работает в небольшой плюс, лишь оставшиеся 2% становятся успешными проектами. Иными словами, даже если ваш проект грандиозный, вероятность того что он станет успешным примерно 2%. Чтобы Вы понимали насколько это мало, просто поставить в рулетке на конкретное число и выиграть намного более вероятно, чем запустить успешный стартап. Только в случае рулетки вы теряете лишь деньги, а в случае с проектом деньги и драгоценные годы.

но почти нет скиллов в программировании

Даже если бы они были, в наше время вероятность запустить успешный стартап в одиночку благополучно стремится к нулю. А уж тем более программисту. Разработчики могут создавать программы, но редко могут создавать продукты. А еще они плевать хотели на маркетинг и упаковку, им кажется что если программа работает, то успех гарантирован(это не так).

Что нужно понять?
1) Понять, что ваша идея это обычная идея, коих в мире миллиарды. Она в среднем не лучше и не хуже других идей.
2) Понять, что даже если ваша идея потрясающая и даже если вы освоили программирование на уровне лучших инженеров гугла, при этом собрали сильную команду из разработчиков, менеджера продукта, специалиста по маркетингу и т.д., все равно ваши шансы на успех равны 2%.
3) Понять, что если у вас нет команды из предыдущего пункта, то ваши шансы примерно чуть более 0%.

Что в таких случаях надо делать?
1) Получить словесное подтверждение того, что идея чего-то стоит. Например, рассказав о проекте 20и людям, посмотреть сколько из них сочтут вашу идею хотя бы "нормальной", не нужно грандиозной.
2) Поискать аналоги. С вероятностью 95% вашу идею уже реализовали ранее, проверить популярность продукта, посмотреть в чем различия с вашим виденьем, плюсы/минусы и т.д.
3) Как только получили предварительное подтверждение, что идея не го*но, пора делать прототип. Тут уже смотрите сами: либо ищите людей, готовых работать на вашу идею, либо сами прокачивайтесь до уровня, позволяющего сделать MVP, либо подзаработайте денег и наймите того, кто сделает MVP.
4) Как только MVP сделан, пора показывать его людям. Если хотя бы 10 человек будут в восторге от вашего продукта - это успех, можно искать инвестора. Если хотя бы 50 человек будут просто пользоваться без восторга вашим продуктом - можно искать инвестора. Если ваш продукт платный и его купят хотя бы 5 человек - можно начинать искать инвестора.

Вообще это все сложный путь и с большой долей вероятности он никуда и ни к чему вас не приведет, поэтому не стройте надежд, чтобы было меньше разочарований. В любом случае удачи

поздравляю, вы решили переизобрести браузер.

Есть такая «секретная» ссылка: www.youtube.com/get_video_info?video_id=XXXXXX
Вместо XXXXXX подставьте хэш видео, который в ссылке на ролик, типа youtu.be/BWCiWZtrWXU после слеша.

По этой (первой) ссылке вернутся URL-encoded данные. Распакуйте их и возьмите параметр url_encoded_fmt_stream_map. Его значение опять надо распаковать как URL-параметры. И из результата вытащить параметр url – это ссылка на единый скачивабельный видеофайл.

Например, в консоли браузера:

function getUrlParams(search) {
    let hashes = search.slice(search.indexOf('?') + 1).split('&')
    let params = {}
    hashes.map(hash => {
        let [key, val] = hash.split('=')
        params[key] = decodeURIComponent(val)
    })

    return params
}
var s = '------'; // здесь длиннющая строка из ответа /get_video_info
var a = getUrlParams(s);
var b = getUrlParams(a.url_encoded_fmt_stream_map);
console.log(b.url); // эту ссылку открываем в браузере - это скачиваемый видеофайл

Очень надеюсь, что вы покопаетесь в этих данных более подробно, разберётесь, как получать прямые ссылки на скачиваемые файлы во всех форматах и размерах, которые предлагает YouTube, и напишете короткий материал на Хабр по результатам, а также опубликуете gist с рабочим кодом для консоли браузера.

https://github.com/it-shark-pro/mobile-school/blob...
https://github.com/it-shark-pro/mobile-school/blob...
https://habr.com/ru/company/edison/blog/430126/

Некоторые страницы содержат примеры мобильных приложений. Можете взять идею и адаптировать под свой стек.