Потому, что IT на высшем уровне - это о том, чтобы не делать одну и ту же работу два раза, отказ от ручного труда, а для этого нужно каждый раз проводить НИОКР - не все могут строго декомпозировать, формализовать и алгоритмизировать задачу на компоненты, которые можно переиспользовать.
Сегодня утром при попытке создать образ возникла проблема к попытке подключения к dockerhub. Причем эти люди с альтернативными сексуальными предпочтениями даже не указали Россию в список стран под запретом:
403 Forbidden Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria. If you are not in one of these cities, countries, or regions and are blocked, please reach out to https://hub.docker.com/support/contact/
Думаю, для тех кто знаком с данным сервисом понимают последствия.
Решение появилось достаточно быстро - https://huecker.io/. Также при работе через VPN проблем также не возникает
Постараюсь ужать многолетний опыт изучения навыков в одну малюсенькую статейку. Расскажу , как на практике освоить набор навыков любого размера, включая все необходимое, чтобы получить первую работу в IT. Объясню пошагово, как создать и придерживаться очень практичного и эффективного индивидуального плана обучения, по которому я сам занимался, в результате чего из полного чайника без диплома и платных курсов за пол года смог влететь в разработку на высококонкурентном рынке с 1000+ откликов на вакансию во времена массовых увольнений сразу в топовую IT‑компанию без связей, накрутки опыта и ментора и даже успешно пройти там испыталку, ведь план обучения позволил накопить багаж полезных знаний.
Правильный план обучения — это 70% получения работы. По этому плану ты сможешь освоить программирование без покупки курсов, то есть стать программистом бесплатно. Да и любой другой скилл или профессию тоже сможешь быстро и бесплатно получить, что сейчас особенно актуально с этим ИИ. Гарантирую, что по этому плану за короткий срок ты добьёшься больших результатов, а это автоматически значит, что потребуется тяжелая работа с твоей стороны. В конце статьи также будет секретный ингредиент, о котором никто не говорит и который может сделать процесс твоего обучения чуть ли не вдвое более эффективным. Ещё я приведу пример реального плана обучения и объясню, почему каждый его пункт настолько логичен, что ты просто не сможешь ему не придерживаться. Цель плана ‑получить максимальный результат при минимальных затратах времени и сил.
Почему вообще нужно составлять план обучения самому? Нельзя что ли чей‑то готовый роудмап найти или курс купить, где план уже есть? Составлять план самому — суперважно, потому что когда ты понимаешь, что и зачем в нём делается и насколько это действительно эффективно, то и придерживаться этого плана становится гораздо проще, так как мотивация просто не пропадает. Да и если что‑то в плане не работает, можно всегда его подкорректировать, это же твой собственный план. Поняв, что работает, а что нет, ты в будущем сможешь создавать эффективные планы для освоения любых навыков, в том числе для выхода в синьеры‑помидоры, т.к. одного волшебного курса по становлению синьером вроде еще никто не запилил. Единственный доступный вариант — самому грамотно выстроить процесс обучения, чтобы результат был максимальным.
Самое простое в создании плана обучения — определить, какие именно навыки нужно приобрести. Для этого можно провести небольшое исследование и посмотреть требования к кандидатам на вакансии твоей будущей специализации. Учти, что учить стоит только то, что так или иначе повышает твой доход. Это значит, что стоит фокусироваться только на необходимых для получения работы знаниях и навыках, отметая все лишнее, в обратном случае будет сложно конкурировать с другими челами. Отметать, нужно, например, ассемблер или внутреннее устройство ОС, которые знать не обязательно и даже вредно. Некоторые говорят, что нужно же знать эту «базу», но объяснить зачем толком не могут. Выбрав необходимые для работы скиллы, нужно понять самое главное — как эффективно учиться. Это будет основой твоего плана обучения. Многим кажется, что они и так умеют учиться, но, если бы все это умели, никто бы не мучился с получением первой работы в IT, так как количество твоих навыков прямо пропорционально шансу получения работы. Основы обучения, о которых пойдет речь, очень практичны и я их сам уже много лет использую:
Практика — это самое важное. Хорошее соотношение практики и теории при обучении для новичков — 80% на 20%. То есть, если ты посмотрел 8-минутное видео, например, про декораторы в Python, то в IDE надо потом не меньше получаса с ними поиграться. Большинство людей практику скипают, потому что это гораздо сложнее, чем видосы смотреть. В итоге они застревают в так называемом «tutorial hell», то есть смотрят много контента, но на практике ничего сделать не могут, поэтому их навыки не развиваются.
Непонимание интервальных повторений — причина, по которой 95% вкатунов сливаются в первые месяцы. Работает это так: когда ты что‑то учишь впервые,то это запоминается на пару дней. Если тему повторить через 2 дня после изучения, то запомнится она уже на 4 дня. Повторишь еще раз к концу четвертого дня — тема запомнится уже на целых 8 дней. Потом на 16, 32 и так далее. Бытует мнение, что в итоге доходишь до момента, где выученное запоминаешь на вечно, так, что повторять тему больше не надо. Хоть это и кажется нереальным, это действительно так работает, однако тому есть научное объяснение: допустим, ты повторяешь тему в девятый раз и теперь будешь помнить её ещё целый год. Если вовсе перестать ее повторять, то всё равно имеется почти 100% шанс того, что за этот год в работе ты случайно столкнёшься с этой темой и тебе придётся естественным образом достать информацию из мозга, просто чтобы совершить намеченное действие. Таким образом тема повторится сама по себе и еще лучше закрепится в голове. Затем вероятность того, чтобы ты случайно встретишь эту тему в работе за следующие 2 года возрастает еще сильнее и тем самым цикл замыкается, в результате чего ты запоминаешь тему как бы «на вечно»
Вот что происходит с теми, кто не применяет интервальные повторения: Допустим, им нужно выучить 15 ключевых навыков или больших тем для получения работы. Большинство новичков учат первые 9 навыков, потом приступают к 10-му, одновременно забывая первый. Потом учат 11-й, параллельно забывая второй и так далее. Они застревают на 9 из 15 необходимых тем или навыков и несмотря на все усилия, не могут преодолеть этот барьер, ведь скорость забывания слишком высока. Причина в том, что они не используют интервальные повторения. Они учат что‑то один раз и двигаются дальше, поэтому постоянно забывают то, что учили ранее. Но если использовать интервальные повторения и регулярно повторять пройденные темы, то можно выучить бесконечное количество навыков и тем, не забывая их. Самое важное в том, что интервальные повторения буквально гарантируют, что ты найдешь работу, потому что они обеспечивают постоянное расширение твоего набора навыков без его уменьшения. Это продолжается вплоть до момента, когда твой набор навыков достигает критической массы и ты становишься настолько хорош, что твой будущий работодатель уже просто не в состоянии игнорировать тебя (естественно надо еще получить навык поиска работы, но это уже отдельная тема).
Для внедрения интервальных повторений можно использовать карточки Anki. Карточки Anki — это приложение, используемое для обучения и запоминания. На лицевой стороне каждой карточки находится вопрос, на оборотной стороне — ответ. Карточки становятся доступны ровно в тот момент времени, в который это необходимо для наилучшего применения принципа интервальных повторений. Эти же карточки включают в себя и не менее важный принцип — принцип активного вспоминания.
Активное вспоминание сводится к следующему высказыванию: твой мозг запоминает информацию не когда ты её откуда‑то получаешь, а именно когда извлекаешь её из мозга. Если, ты, например, прочтешь эту статью и сразу переключишься на следующую, то будешь что‑то помнить из этой статьи еще в течение примерно одного часа. Но если при прочтении статьи периодически останавливаться и объяснять себе концепции своими словами, то можно будет запомнить чуть ли не 100% информации статьи чуть ли не на целую неделю. Тот же результат можно достичь, если прочитать статью и в конце всю ее себе пересказать. Вот почему во время интервальных повторений необходимо как можно больше фокусироваться на активном вспоминании. Кстати, когда человек выполняет практические задания, это тоже автоматически является формой активного вспоминания, ведь ты работаешь с ранее изученной информацией и это является частью причины того, почему практические упражнения так эффективны.
Ты, наверное, задаешься вопросом, зачем запоминать что‑то, если можно просто использовать ChatGPT для получения быстрого ответа.
Чем больше полезной информации ты усвоишь и запомнишь, тем легче тебе будет понимать ответы ChatGPT и, что самое важное, сохранять эти ответы в краткосрочной памяти в виде части решения задачи, над которой сейчас работаешь. Ты также будешь глубже понимать ответы ChatGPT и даже вспоминать идеи, которые не были упомянуты в ответе.
Лучше работать над изучением одних и тех же трех навыков каждый день по часу и сосредотачиваться на них пару недель подряд, чем уделять по 3 часа в день одному навыку в течение нескольких дней и затем переходить к следующему. Это один из важнейших принципов. Я понятия не имею, почему он работает, но не обязательно понимать, как что‑то работает, чтобы это делать и получать ощутимый результат. Попробуй поучиться так и будешь поражен скоростью освоения навыков.
В чем заключается разница между профессионалом и любителем? Профессионал очень хорошо знает основы. Основы служат фундаментом для последующих тем, изучаемых в будущем. Например, чтобы быстрее освоить React, нужно знать JavaScript, и чем лучше ты знаешь этот язык, тем легче будет разобраться в React. Поэтому не торопись и досконально изучи компетенции, служащие основой для других компетенций.
После месяца обучения результаты будут намного лучше, если учить предмет по часу каждый день, нежели чем если учить его 7 часов в день раз в неделю. Это банально объясняется принципом работы интервальных повторений.
Утром, перед началом нового дня, удели 10 минут, чтобы вспомнить все, что учил вчера. Это очень эффективно, так как первое повторение в течение первых 24 часов после изучения темы имеет огромный эффект на запоминание.
Теперь у тебя есть основные принципы создания плана обучения, но что насчет секретного ингредиента? Хотя все вышеперечисленные пункты идеально подходят для эффективного долгосрочного обучения, если ты стремишься получить работу, твоя цель не в том, чтобы изучить как можно больше всего, а в том, чтобы достичь уровня, где у тебя есть крутые проекты и ты можешь успешно пройти собеседование. В этом случае секретный ингредиент — интенсивность. Например: чтобы достичь такого же уровня навыков в программировании, который тебе нужен для успешного прохождения собеса, ты можешь либо потратить 1000 часов за полгода, либо 1500 часов за год. Заметили разницу? За 1000 часов достигается тот же результат, что и за 1500 часов. Это объясняется принципом работы интервальных повторений: чем больше проходит дней, тем больше времени нужно тратить на интервальные повторения, в обратном случае информация просто забудется. Поэтому если сжать временное окно, в которое ты достигаешь необходимого уровня навыков, скажем, с года до полу года, то таким образом можно значительно уменьшить общее количество часов, необходимых для достижения цели, и, следовательно, работать меньше, получая бОльшие результаты. Теперь ты знаешь, что должен включать твой план обучения.
Давай теперь посмотрим, как может выглядеть такой план на примере реального плана становления python backend разработчиком:
Пример плана изучения python backend
Каждая колонка — это день, а каждая синяя ячейка — это как минимум 1 час сфокусированного базированного на практике обучения. Первый месяц ты параллельно учишь Python, SQL и алгосы (алгосы не в смысле заучки конкретных алгоритмов, а в смысле умения структурно думать и решать логичские задачки кодом, как, например, на codewars). Это то, что создает основу для всего остального, что ты будешь изучать. После этого добавляешь дни для вспоминания изученного, чтобы ничего не забыть. Далее начинаешь создавать проекты с использованием Django и подучивать немного фронтенд‑технологий, чтобы можно было потом показать рекрутеру хороший и красивый проект (хочешь работать беком? Учи фронтенд, чтоб тебя рекрутер не скипнул с твоими уродливыми проектами, понял да). Все это делаешь параллельно, а также учишь git для развития своего GitHub. Фокусируешься на создании проектов с Django до тех пор, пока не найдешь работу. Дополнительно добавляешь дни, в которые будешь повторять, что учил, чтобы ничего не забыть. Затем учишь параллельно Linux, PostgreSQL и Docker, завершая процесс изучением Django Rest Framework, одновременно повторяя все, что учил ранее. Как видишь, этот план включает в себя много практики, интервальных повторений и активного вспоминания. Ты учишь по нескольку предметов параллельно и сначала фокусируешься на основах. Ты учишься каждый день, начиная каждый день с 10 минут повторения того, что выучил вчера, что еще сильнее оптимизирует твое обучение. А занятия как минимум по 4 сфокусированных часа (а лучше — по 10) в день обеспечивают интенсивность, которая в полтора раза сокращает общее количество часов, необходимых на получение всех этих навыков.
Короткий ответ состоит в том, что можно просто найти бесплатный курс и следовать ему, лично я предпочитаю использовать для этого YouTube. Бесплатные курсы обычно не содержат практических упражнений, являющихся самой важной частью обучения, поэтому упражнения на определенную тему придется отдельно искать в интернете. Или можно даже поступить еще лучше: когда смотришь курс и видишь пример кода, решающего конкретную проблему, попробуй придумать похожий код, решающий аналогичную проблему и поиграться с этим кодом в среде разработки. Это один из самых эффективных способов практики, который мне удалось найти.
Гарантирую, что, прочитав эту статью, ты потратил своё время зря, если не применил к ней вышеупомянутые принципы, так как забудешь все о чем я тут написал. Давай теперь объясню, как применить основные из этих принципов к любой статье или обучающему видео. Возьмем эту статью, например. Если ты проследуешь следующим нескольким шагам в течение следующих 5 минут, то это будут одни из самых полезных 5 минут в твоей жизни. Во‑первых, возьми свой телефон и скачай приложение под названием Anki Cards. Я не спонсирован этим приложением и не имею к нему никакого финансового отношения, поэтому у меня нет ссылки и тебе придется найти его самому. Шаг 2 — Перестань читать и прямо сейчас и попробуй вспомнить все, о чем я говорил. Объясни себе своими словами все, что удается вспомнить (да, прямо сейчас, я жду). Шаг 3. В зависимости от того, что удалось вспомнить, открой приложение Anki и создай несколько карточек об этой статье. Например: что такое интервальные повторения и как их применять? Что такое активное вспоминание? Какое лучшее соотношение между практикой и теорией для начинающих? Шаг 4. Сформируй привычку открывать это приложение время от времени, повторять карточки и добавлять новые о всем важном, что ты изучаешь в программировании. Лично я таким образом не только запомнил всё, что учил, но и ответил на 98% вопросов на своем первом в жизни собеседовании.
И хорошо если пчелки правда знают о проблеме и работают над ее исправлением, но на деле чаще всего вы не видите даже этой ошибки, а просто ждёте бесконечный прогресс бар ... нет, прогрессбар - это про какой-то прогресс, процесс, с хотя бы отдалённо и приблизительно понятной продолжительностью.
Даже эти нехитрые технологии были потеряны
Отголоски развитой цивилизации и сейчас можно найти в виде скриншотов в сети:
Что мы можем увидеть на прогресс-баре здорового человека
На хорошем прогресс-баре мы видим что, собственно, присходит, сколько элементов обрабатывается, общий процент выполненной работы (5), сколько примерно времени потребуется (4), сколько объектов и гигабайтов осталось обработать (2), скорость передачи данных (3), тот же процент но наглядно в виде заполнения бара (1) и даже график изменения скорости обработки данных!
Кстати, давно не пользуюсь windows, но, кажется, там сейчас такой или похожий прогресс-бар на копирование файлов, но...
Но во всех стальных местах где пользователю приходится ждать, его буквально заставляют СТРАДАТЬ!
Я не знаю кто это придумал, но уверен, что сам адский сатана его большой поклонник.
Установка программы, перезагрузка системы, ОБНОВЛЕНИЕ! Какого черта нигде не пишется даже сраный процент прогресса?! Порой вот эта тупая анимация просто крутится в виде зацикленной гифки, и она вообще никак не связана с процессом. Криворукие разработчики зачастую даже не думают потрудиться и сделать ожидание пользователя чуть более предсказуемым по времени и информативным.
Да ладно "по времени", иногда глядя на анимацию не понятно закончится этот процесс вообще когда-нибудь, или что-то там уже бесповоротно сломалось, а анимация эта бесконечная, на экране по-прежнему висит надпись "осталось совсем немножко, подождите, пожалуйста", и так ждать можно до тепловой смерти вселенной!
Неужели только меня одного бомбит от всего этого?
Сейчас придёт кто-нибудь в комменты защищать тугосерь-разработчиков, мол, ненуачо, ненуим манагер сказал так сделать, ненуакак они узнают сколько осталось, когда кампуктеры у всех разной производительности, интернет-соединение разное и, возможно, нестабильное, количественный прогресс может нелинейно зависеть от времени.
Ну так да, дорогие коллеги, в решении этих сложностей и заключается наша с вами профессия!
Ничего невозможного тут нет, а сделать лучше чем сейчас в 99% местах вообще не сложно.
Кто мешает эмпирически подобрать более адекватную кусочно-полиномиальную формулу аппроксимации? Кто мешает собрать статистику у контрольной выборки пользователей и выявить закономерности длительностей разных этапов процесса от примерного уровня оборудования? Кто мешает в ходе самого прогресса замерять скорость тех или иных операций, чтобы предсказать общее время процедуры. Хотя бы очень приблизительно. Хотя бы оценкой сверху "если ничего непредвиденного и редкого не случится".
Кто-то скажет, что, мол, радуйтесь, что вот, к примеру, при загрузке системы вам хоть анимацию с приятной картинкой показываем, а так вообще черный экран был бы. Ведь как пробросишь подробности процесса в тупой фронтенд? А так и пробросишь! Чуть поострее сделать фронт, чуть больше интроспекции, немного статистики и, вуа-ля, у вас дружелюбный информативный интерфейс, а не вот это вот вращающееся бесконечное говно на палочке.
И напоследок. Не надо считать пользователя идиотом, но и оставлять наедине со своими проблемами без какой-либо информации - тоже не надо. Правильная обработка handled и unhandled исключений изучается в институте, но это не рокет-сайнс, тут можно освоить базовые премудрости.
Пользователю должно быть понятно, что что-то пошло не так, ему должно быть понятно имеет ли смысл и имеется ли возможность решать как-то возникшую проблему, или стоит сразу в ужасе удалить поделку неграмотных "погромистов", чтобы не терять время и искать уже более качественный софт.
Винда, кстати, тоже не безгрешная, в плане наплевательства на удобство пользователя при ожидании. Чего стоит только вот это вот внезапное желание обновиться. Сколько было случаев, когда винде (и не только) приспичило срочно обновиться, когда горят сроки и нужно доделать курсовую, или срочно надо распечатать документы, или быстро скопировать нужный файл, или целая аудитория ждёт презентации на подключенном к проектору ноутбуке...
21 век на дворе! Пора делать все эти побочные процессы, которые не нужны, по сути, пользователю, просто незаметными и НИКАК не затрагивающими пользовательский опыт.
Пора писать софт везде так, как это делали для Вояджеров и марсоходов. Предсказуемо, конфигурируемо, надёжно. Что стоит при обновлении делать равнозначный клон ядра операционной системы и обновлять его, а не работающю систему? Потом "щёлк" и у вас обновленный софт! Что мешает? Техническая сложность? Ну так пора сделать это важным техническим преимуществом, чтобы была конкуренция за такое удобство.
Простите, друзья, что-то меня подорвало снизу. Отбомбил. Думаю эта статья уже малость припоздала лет эдак на 10. Сейчас проблема, может быть, уже стоит не так остро, компы у нас быстрые, каналы широкие, нервы правда ни к черту, ну да что поделаешь...
Картинки для иллюстрации взяты из сети, а эмоции из глубин воспалённого мозга.
Привет тебе, всякий читающий! Сегодня расскажу о том, как я проводил оптимизацию одного из своих сайтов с нуля, чего в результате добился, и для чего это вообще всё надо.
Результат оптимизации сайта
Есть сайт на PHP 8.1, Laravel. Под базу взят PostgreSQl. На фронте нативный JS. За основу взят шаблон от Metronic, дабы не делать всё с нуля.
Страниц на сайте больше 2 миллионов. Контент собирался в результате сбора информации с множества источников.
Первоначальная оценка по Google Page Speed была не очень - 36 на мобильных устройствах и 80 на компьютере.
Это мобилки
Это компьютер
Вроде бы на компьютерах выглядит всё адекватно, но не тут то было. Сейчас все поисковики смотрят скорость именно по мобильным устройствам и акцент делают именно на них.
Наша цель - довести показатели на мобилках до максимума.
Поехали проводить аналитику по шагам.
Идём на гитхаб и устанавливаем через композер расширение. Там всего пару кликов, каждый уважаемый программист сделает самостоятельно.
После успешной установки при заходе на страницу (не забудьте в настройках в файле .env поставить APP_DEBUG=true) внизу слева страницы появится иконочка, при клике на которую откроется панель с кучей вкладок.
Залазим во вкладку Queries и смотрим все запросы, которые есть на странице. Получается что-то такое.
Красным отмечена суммарная продолжительность выполнения.
Я использую PHPStorm для работы с базой. Вы же можете использовать что-то иное, это не принципиально.
На этой вкладке нужно проанализировать вызов запросов. Для начала я увидел, что при выводе списка статей в цикле вызывается ещё один дополнительный запрос. Сделал всё в 1 запросе. Это практически минус 12 запросов со страницы. Такие моменты нужно анализировать глазками и оптимизировать под каждый проект самостоятельно.
Далее я взял КАЖДЫЙ запрос и проанализировал план его выполнения. Вот пример:
Смотрим здесь Total Cost
Как видим здесь нет никаких индексов. Лечится это легко. Смотрим по каким полям у нас происходят условия и с какой сортировкой. Затем создаём индекс по этим полям и смотрим результат. Вот что получилось у меня:
А вот результат после создания индексов
Мы оптимизировали запрос с 17к до 207. И это только один пример.
Вот пример простейшего запроса без индекса
А вот результат после создания индекса
Так мы должны пройти по каждому запросу на каждой странице и проанализировать их работу. Вполне возможно, что можно отказаться от каких-то таблиц, лишних джоинов и т.д.
Ещё я советую проанализировать таблицы, которые можно было бы разбить на партиции.
Пример: у нас есть аналитика по годам в одной таблице с 1 миллионом записей. Вы постоянно забираете аналитику на текущий год и выводите пользователю. Здесь так и напрашивается деление таблицы по годам, а может даже и по месяцам. В результате запрос будет идти по ограниченному набору данных, а не по всем данным за всё время.
Результат после оптимизации запросов
Как видим уже есть сподвижки. Работаем дальше.
Сайт грузит очень большое количество различных картинок, css'ов и js'ов. Пришла мысль всё это дело закешировать, чтобы быстро отдавать из оперативной памяти, а не лезть на жёсткий диск.
Для своих проектов я использую VarnishCache, т.к. уже привык и у него очень гибкая настройка.
Если вы используете Laravel, то есть вот такое расширение, чтобы подружить варниш с ларкой:
А вот здесь есть классное руководство по настройке:
А вот ещё ссылочка с конфигом. Если у вас другая версия варниша - поменяйте в урле версию и будет вам счастье.
Я добавил в кеш все js, css и картинки. Будьте крайне внимательны с настройкой. Можно, например, закешировать POST-запросы с формами или какие-то JSON-Ответы. Советую прогонять тестами сайты после добавления таких модулей.
Здесь шаг очень простой. Нужно проанализировать утилизацию ресурсов на вашем сервере. Посмотрите сколько используется процессора, памяти, места. Я на этом этапе просто взял и купил сервер в 2 раза мощнее, дабы мне хватило ресурсов с лихвой.
У меня в проекте использовался дефолтно сборщик webpack и правила на нём были крайне простыми - берём все файлы и засовываем в единый файл bundle.
Представьте, что на КАЖДОЙ странице забираются все js-библиотеки и css. Это очень сильно усложняет вывод страницы, при этом делает работу программиста легче. Не надо думать что и когда подрубить. Просто подключаешь любую компоненту и она работает! Ну не прелесть ли. Но не для поисковиков.
Пришлось переписать сборку. В результате теперь вместо одного большого файла у меня будет парочка сотен небольших. При этом нужно следить за последовательностью их подключения, переписать все страницы и т.д. Да, переписывать готовый проект очень сложно, и очень велика вероятность ошибки. Но на то мы и специалисты, чтобы делать всё качественно, не правда ли?
Классным дополнением будет пул коннектов к базе. Для PostgreSQL я использую PgBouncer. Можете скачать по ссылке ниже.
Пул коннектов позволяет держать постоянные соединения с базой данных для уменьшения потерь при подключений к ней. Вот здесь можете почитать официальную документацию:
Я установил расширение на Laravel для отлова мобильных устройств. качал отсюда:
Далее в коде для мобилок сделал другую вёрстку, более простую, чем в версии для компьютеров. Вырезал половину анимации, блоки с картой, ненужные слайдеры. Такой вариант поможет уменьшить DOM страницы и ускорит её отображение.
Смотрим полученный результат
Можно ещё пытаться оптимизировать файлы и запросы. Я не использовал Reddis для кеширования запросов, но вы можете тоже использовать этот метод.
По капельке можно легко оптимизировать большинство страниц. Благодаря такому подходу ваши сайты смогут быстро улучшить свои позиции в выдаче и увеличить конверсию.
Буду благодарен за подписку на мой tg-канал, если материал был полезен.
Всем привет, работаю java разработчиком 10 лет, хотел бы показать разницу между императивным и декларативным подходом на примере синтетической задачи по обработке списка чисел.
Императивный подход описывает последовательность действий с использованием конструкций языка - то есть позволяет описывать алгоритмы любой сложности. Декларативный подход описывает ожидаемый результат - а на практике состоит в написании кода, который интерпретируется дальше фреймворком.
Задан список чисел, на примере:
List<Integer> input = List.of(1, 2, 3, 4, 5);
Нужно найти сумму квадратов чётных чисел - значений элементов массива. Чётные числа это такие числа, которые делятся нацело на 2, то есть остаток от деления числа на два равен нулю. Чётные числа здесь 2 и 4. Их квадраты это 4 и 16. Искомая сумма 4 + 16 = 20.
Чтобы записать алгоритм в императивном подходе, потребуется объявить переменную-аккумулятор, которая будет содержать сумму, её начальное значение будет 0. Далее пройтись по всем элементам списка, для четных их них посчитать квадрат, и добавить его к текущему значению суммы:
int sumEven = 0;
for (Integer x : input) { //пройти по всем элементам
__ if (x % 2 == 0) { //для четных
____ sumEven += x * x; //посчитать квадрат и добавить к сумме
__ }
}
assertEquals(sumEven, 20);
Декларативный подход можно показать на примере использования апи java.util.stream. Последовательно указываются инструкции для фильтрации, преобразования и аккумуляции результата:
int sumEven = input.stream()
__ .filter(x -> x % 2 == 0)
__ .map(x -> x * x)
__ .reduce(0, Integer::sum);
assertEquals(sumEven, 20);
Декларативный подход более емкий, так как оперирует конструкциями высокого уровня, но менее гибкий. Его удобно использовать при решении стандартных задач. Желаю всем успехов в изучении программирования.
Месяц назад я отключил Codeium и честно начал тестировал GigaCode (альтернативу Copilot от Сбера). Но похоже придётся переключаться обратно, GigaCode ещё сыроват…
Он, конечно, полезен, и действительно иногда упрощает написание кода, да и вообще круто, что появляются такие отечественные продукты.
Но пока то и дело (ну очень часто) возникает ощущение, что GigaCode путается под ногами, и мешает писать код, а вовсе не помогает (карточка 4):
- Он то и дело вставляет ненужные закрывающие скобки и кавычки, которые VS Code уже вставил за меня.
- Другая надоедливая ситуация — он не может уследить, что я уже написал часть слова и предлагает вставить её ещё раз.
В общем, пока ждём улучшенной версии …
Затронута важная тема!
Оригинальный пост:
Заклинание призыва инициатора (вроде так произносится):
Многие программисты, которые сильно погружены в тему, просто не способны рассказать что-то полезное не потому, что не понимают материал, а потому, что не понимаю проблем начинающих. У кого-то были отличные учителя и они не заметили трудностей на этапе обучения. Кто-то просто очень давно учился и уже не понимает проблем начинающих. Кому-то сразу и всё было понятно (большинство, конечно, выберет это вариант! :).
Какой бы ни была причина, суть не меняется. Большое количество контента в сети не даёт понимания материала.
Штука, про которую ты хотел написать, судя по контексту, называется "контейнер инъекции зависимости" (Dependency Injection Container). Хорошо бы подучить матчасть, чтобы понимать зачем оно надо и какие проблемы решает.
IoC - это "принцип инверсии управления (Inversion of Control). Опять таки хорошо бы почитать что это и зачем оно надо.
Вот пояснение о инверсии зависимости с сайта всё тех же «мелко-мягких»:
Зависимость в приложении должна быть направлена в сторону абстракции, а не на детали реализации. При написании большинства приложений направление зависимостей времени компиляции задается в сторону времени выполнения.
Я понимаю о чём речь, но до сих пор читаю такие тексты с усилием. Когда начинал разбираться в теме – это был просто шум. Есть люди, которые сразу и легко такое понимают, но я, к сожалению, не из таких. Поэтому нужны хорошие примеры с плавным погружением в проблему и предоставлением инструментов для решения. А таких в сети хрен целых и ноль десятых.
Вообще подобные рекомендации очень похожи на классическое «учи матчасть». Отправлять учить матчасть – святое дело для каждого, кто разобрался в теме :). Но это так не работает. Я читал Троелсена по рекомендациям, смотрел и читал множество материалов в сети на разных языках, покупал в складчину переводы по разным темам. К сожалению, подавляющее их большинство являются копией содержания популярных книг с полным сохранением сложности формулировок. Мой наставник верно подметил, что с таким же успехом можно учить французский язык по словарику. Владеющему языком словарик сильно помогает, а начинающим такой словарик будет почти бесполезен.
Обе темы не для начального уровня изучения, а уже после того, как осилишь интерфейсы и полиморфизм.
Много раз такое слышал – но это совет, который не решает вопроса. Не понял тему – читай предыдущую. Так вопросов по предыдущей теме и не было (!!!). Снова попадаем в рекомендацию «учи матчасть».
Сейчас же материалов по программированию в интернете полно - бери да учись. И видео, и блоги, и официальная документация. Всё бесплатно. Да вот взять хотя бы документацию от мелко-мягких https://learn.microsoft.com/ru-ru/dotnet/core/extensions/dep... Всё по русски, с объяснением зачем оно надо и примерами.
Чтобы найти нужную статью – надо знать, что искать и уметь вычленять важное из ещё мало понятной темы (вот так задачка!).
Я преподаю компьютерную графику студентам (визуализация интерьеров в 3ds max). Они тоже задают странные (по моему мнению, конечно) вопросы.
Например, если у меня студент спрашивает, как двигать объект, то я не понимаю, почему он не написал это в гугле. Так и пиши - «как двигать объект 3ds max». Будет много видео на первой же странице. Но есть и более сложные примеры - «как сделать здание с плавно меняющимся размером окон». Такой запрос на параметрическое моделирование не выведет и ответов не даст. Хотя с моей стороны очевидно, что информация по параметрическому моделированию в сети уже есть. Её много, она на русском и бесплатна.
Программирование существенно сложнее из-за большого количества мнений. Здесь не всё так однозначно, как в теме 3d моделирования. Даже если известно, что искать. Запрос может привести тебя к тонне материала, в котором большАя часть будет копипастой из словарика, не меньшая будет не по уровню сложной (привет интерфейсы и полиморфизм, я снова иду к вам!), ещё часть будет в стиле «учи матчасть» и совсем малая будет действительно актуальной и полезной. Изучить последнее после процеживания всего остального - та ещё задачка.
Реально понимание приходит, когда ученик сталкивается с нерешаемой ранее задачей, для решения которой вводят новый инструментарий. Тогда и становится понятно на кой оно надо. Для этого важно выделить проблему и без избытка информации подвести к её решению. Но чаще предлагают найти и понять проблему самому (уже задачка). А потом с полным осознанием ситуации (с чего бы?) подобрать нужный инструментарий и решить проблему (а чего не понятно – всё же есть в сети и бесплатно). Абсурд.
Недавно смотрел, как жена игра играет в PS4. Она почти никогда не играла в видеоигры. Сидит и вообще тормозит! А всё дело в том, что для неё задачка – это найти нужную кнопку на геймпаде. Когда думаешь о таком, места на размышления о тактике или оценке поведения врага не остается. Она не видела ничего, что происходит на экране из того, что видел я.
Помните, голова учащегося плотно занята множеством других вопросов, которые кажутся специалисту элементарными, не достойными внимания или даже вовсе незаметными. Но именно из-за них очевидное и простое решение или знание просто ускользает от ученика. Даже если оно написано прямо на экране и на русском языке.
Я верю, что те люди, которые откликаются на помощь с обучением, хотят помочь. Но описанные рекомендации и советы просто не работают. Поэтому, когда тема IoC-контейнеров стала хотя бы более-менее ясна, я написал этот пост радости наполненный
...ошибками и корявым объяснением...
Потому что даже такая мелочь даётся огромным трудом и большим тоннажем перелопаченного материала. И, я надеюсь, что моё объяснение кому-то поможет так же хорошо, как помогло мне.
