Недавно делал код ревью и заметил, что в pnpm-lock.yaml (альтернатива yarn.lock в pnpm) добавлена 17-я версия реакта, хотя на проекте мы используем 18-ю. Нам не нужно тянуть в проект 2 версии реакта — поэтому идём разбираться.
Дело в том, что в библиотеке react-cheetah-grid, которую мы используем для рендера длинных таблиц, реакт указан в секции dependencies вместо peerDependencies.
dependencies vs peerDependencies
- dependencies: пакеты, которые необходимы для работы вашего приложения и устанавливаются автоматически - peerDependencies: пакеты, которые должны быть уже установлены в среде, где используется ваш пакет, чтобы избежать конфликтов версий
Чтобы быстро исправить проблему — можно переопределить версию реакта для определённого пакета в pnpm с помощью метода readPackage. Также нужно откатить изменения в pnpm-lock.yaml и запустить pnpm install .
Это статья для начинающих фронтенд разработчиков, которые с яркими глазами и минимальной зп готовы к первому коммерческому опыту.
Стэк: vue3, nuxt3
P.S. АХТУНГ! Много букаф, смысла null, потому я есть Shaltier Nullfallen! Статья написана ВЕЛИКИМ в "кавычках" грамотеем, если вы любите высококачественный контент, скорее всего вам не стоит читать эту статью. Все названия и имена были заменены, любое совпадение является чистой случайностью.
Добро пожаловать, заблудшие огоньки, сегодня я хочу поговорить о самых обычных моментах работы frontend разработчиком в маленькой фирме. Этот текст наполнен унынием и разочарованием, надеюсь он передаст толику моих эмоций.
Хромые клячи
Конец месяца, собеседование в компанию "Стрекозлы в АйТи" прошло весьма неплохо, я напортачил в предыдущей компании, создав образ посредственного падавана. Фронтендер из предыдущей фирмы "BODUNOV" видимо недавно открыл для себя vue и nuxt. Структура проекта была специфичной (это пример):
Я покажу тебе, как глубока кроличья нора
Примечание: Мне нравится структура из angular и это не мешает использовать похожий стиль в компонентах. Используйте основную структуру из доков nuxt. Старайтесь не допускать больше трех уровней.
Папка partials с огромной вложенностью передавала привет от мистера webpack, а точнее плагина по импорту html.
Разработчик сделал 40% проекта и метался от одного UI kit к другому, а я слушал и крутил барабан револьвера. Сделав одну страницу, меня попросили удалиться, попытка разбить вёрстку на компоненты и избавился от ненужных дубликатов html кода смутила разраба фирмы BODUNOV. И тут меня ждала новая не менее амбициозная компания, с 10-ти летним стажем на рынке.
На собеседование в "Стрекозлы в АйТи" я убедился у интервьюера, в отсутствие глуповатого маркетингового приёма, сверстать статический сайт и показать клиенту, сказав: 'Всё готово шеф, дело осталось за малым'. Люди серьёзные, работают с продукцией 1с и считаются в ней экспертами.
Битрикс есть, а отчеты пиши в excell. И не забывай щелкать таймер и писать отчёт в конце дня. Джира? Какая Джира? Продукты 1С топ! Мы пробовали только Яндекс и это был отстой.
Ну хоть хорошо что excell не используется как база данных для бэка. А вместо word не используют markdown. Вот тупые, кто `markdown` придумал.
После ознакомительного диалога ПМ-а по работе со Шмитрикс, я не понял как они ведут разработку. На канбан доске вместо привычных столбцов было несколько столбиков связанных со временем:
// Без срока // Запланированные // Сделаю сегодня // Сделаю на недели //
Хмм... наверное для перевода на тест нужно делегировать тестировщику, а потом...
А нееее... кроме менеджера, разработчиков и дизайнера больше никого нету. То есть нет тестировщиков, контент-менеджеров, seo, devops и т.д.
Менеджер сказал (не дословно, почти): "Всех кого-ты перечислил сомнительные личности и результат их работы не ясен. У нас было много SEO специалистов, целых 3, ой, 2 человека. Ну руководство не поняло их трудов и уволило."
Окей... Нам не в первой работать по старинке. Пока нам платят, мы будем радостно визжать как свиньи. Ну что погнали за работу!
Three Days Later...
Прошло 3 дня, а я ничего не сделал. Нет, вина не в моём титуле Капитан Улитка, просто задач нет! Как объяснил менеджер, он болеет, неделя очень тяжелая, задачу выдать не могу. (На самом деле было ещё 2 менеджера которые могли его подменить, но заставлять работать больного сотрудника веселее)
Обычно первым делом в любой компании заставляют читать документацию на 6 часов, ставить vpn, но в документах Шмитрикса было почти пусто, компания не хотела покупать продвинутую подписку, поэтому каждый создавал файлы в облаке, кто в гугл, кто в яндексе. Каждый держал файл у себя, а не в общей папке, поэтому узреть могли только избранные.
Первое задание. Разместить статический сайт выполненный начинающим верстальщиком Рыжий. Видимо только вчера прошел курс ХалалАкадемии и решил проверить новоиспеченный скил. Где-то пагинация была сделана картинкой, где-то отсутствовали блоки, где-то хромал адаптив.
Пишите а вам попадались сайты где не было верстки, только backgroundImage?
Мне дали доступ по ssh и попросили поставить сайт с сертификатом на nginx. В принципе окей, но в вакансии про эти скилы не слова.
One Day Later...
Разговор с дизом и ПМ. Дизайн находится под слоём черновик, каждый макет не имеет статуса готового к разработке.
Примечание: кнопка фигмы Ready For Dev, некоторые дизайнеры делают свой компонент для статусов макета или используют цветовые зоны, т.к. макет может иметь много статусов (прототип / в процессе доработки / на утверждение / готов)
Даже без матёрого глаза можно приметить множество огрехов в дизайне. Отсутствие модалок, элементы не интерактивные, нет статусов элементов форм. В некоторых местах много воздуха, неравномерные отступы... В общем полный комплект ошибок ждуна. Дизайнер пытается скрыть смущение, намекая на сроки, мол времени на UX и полировку UI не было. Удивительный факт, разработчикам всегда представляют диза так: "А это наш UI/UX дизайнер". Вот только времени на UX исследования у него нет.
И теперь работа? Нет. Доступа к гитлабу нет, задач в шмитриксе нет.
На следущий день получил доступ к гитлабу, сразу начал создавать проект, хотя задачи не было, есть интуиция и особая минтайная связь. ПМ захлебывался соплями и издавал предсмертный хрип, получить инфу по проекту было нельзя.
А инфы по проекту не было / LOL / Редизайн предполагалось делать на основе нового диза и поглядывая на старый сайт. Только новый дизайн сильно отличался. Не было к примеру локализации (был выбор региона) и ПМ сказал твёрдо её НЕ БУДЕТ! Вот тут и была первая подстава.
ПМ тоже не одобряет дизайн, но продолжает сюсюкаться (чей-то родственник или мидихлориан в избытке). Дизайн сделан посредственно и как оказывается не является техническим документом.
Спойлер: По мнению руководства я должен был делать не по дизайну, а по старому сайту, дизайн лишь красивый фантик для клиента и задача разработчика самому продумать адаптивность и функционал сайта.
Благо старый сайт не имел минификации и обфускации.
Примечание: После компиляции кода, файл со скриптом крайне тяжело прочитать. Начинающие разработчики умеют кидать скрипты в конец документа, чтобы не мешать прорисовке странице, на этом их знания исчерпываются. Раньше мы прописывали чанки в webpack ручками, теперь с vite многие разрабы не знают про это.
Ладно с дизайном всё ясно, ну мне нужно делать динамический сайт похожий по типу на интернет магазин, где взять бэкенд? Старый сайт был выполнен в php шаблонизаторе и имел мобильное приложение (отличается по функционалу от сайта), теперь предстояло сделать его на nuxt, а значит старое api не подходило.
Угадайте кто должен был придумать дизайн API? Бэкенд! Не угадали. Конечно же фронтенд (по факту vue SSR это уже fullstack)
Примечание: Бэкенд разработчики могут разработать API самостоятельно, а значит они могут приступить к работе сразу без верстки. После одобрения прототипа, уже можно предположить какие данные будут выводится. Прототип дазайна уже определяет базовое расположение блоков и медиаконтента
Мне позвонил специалист по отделу кадров, спрашивает как дела и мол я буду звонить тебе каждый месяц (это был последний звонок). А я такой: "not bad, но знаешь, тут ..."
- А покажи что ты сделал.
Я отправляю ему ссылку на сайт.
- Скажи, то что сделал Рыжий, тебе как-то помогло?
- Как я говорил на собесе, всю эту вёрстку все равно нужно переделывать, к тому же там было много косяков, вёрстка была абсолютная не валидна по w3c. Я начал с начала.
- Ну ты же понимаешь я не могу показать это?
На тот момент навигация еще не приходила с бэка, перемещаться по сайту было нельзя, а также были видны некоторые косяки. Я и не хотел демонстрировать сайт.
- Ну да, вы показали клиенту фантик без конфеты. Без серверной части нельзя оставлять заявки или отправлять формы, сайт и делается ради интерактивности, иначе мы могли бы продавать фотографию сайта.
Менеджер посмотрел на меня как на шарлатана. Почему кадровик ведет переговоры по проекту с клиентом? А может он, вовсе и не кадровик?
Если это была свежая компания из 5 человек, я бы понял. Но персонала было не менее 20 чел. А компании уже 10 лет. Наверное за это время можно было собрать базовую комплектацию.
Два месяца спустя или 44 раб дня
Бэкендер выходит из долгожданного отпуска...
4-5 остальных видимо были очень заняты. Я лично работал с двумя, но официально в штате их должно быть больше. Да и как-то на созвоне созвали толпу, которой объяснили как сделать 1 эндпойнт с получением данных из firebase. Результат: я поднял nuxt и сделал сам. Ну что сказать команда профессионалов, умеют убеждать.
Ах, да... Бэкенд выходит из отпуска и заходит в шмитрикс. Бэкендер плачет ПМ: "Там слишком много! Апи уже почти готово, там всё есть"
Конечно же там много чего не было, апи первой версии сделано не по REST, которому далеко до стандартов JSON:API.
Swagger-а нету, есть postman, апи которое написано ручками (тока шайтаны пишут доки в аннотациях и используют модуль автодокументации)
Примечание: Незнаю как в Yii, но в Symfony генерировать коллекции с готовыми Rest Api эндпоинтами милое дело. По идее мы один раз заморачиваемся пишем ядро, а далее используем от проекта к проекту. Документацию легко можно импортировать в postman. Если у вас будет фронтенд SPA/SSR в виде отдельного приложения, задумайтесь, а нужно ли его писать на php? Бэкенд на nodejs может сэкономить время. Низкой порог вхождения !== выгода. Nodejs может быть serverless, а php это танцы с бубном в плане деплоя. А там типизация от бэка почти готовая
Меня попросили переделать для бэка документ с api запросами и как вы думаете он приступил к правкам сразу? Конечно же нет. Рабочий день начинался в 9 часов, точнее так было у удалёнщиков, офисные планктоны почти всегда приезжали на работу после обеда. Оказывается часть сотрудников работают во вторую смену, а бэкендер на протяжения дня занимается бумажками от шефа, сам шеф со спокойной душой уезжал в командировку. По более сложному проекту с картами, мне приходилось ждать фидбека от шефа компании каждый вечер, а днём по указаниям из аудиосообщения я пилил приложение.
Конечно для написания ТЗ необходимо время, а наболтать по телефону сообщение это дело не сложное. Ну и тупые эти разработчики, носятся со своими ТЗ.
Хороший мальчик Бобби
Не курит, не пьёт. Деньги в копилку кладёт. Большая часть рынка разработки это ждуняшки ожидающие маны небесной. В один прекрасный день армию ждунов без тимлида, мидлов или сеньоров, только ждуны, только харкор. Банда маркетологов оказывается чаще всего во главе малого бизнеса (будем честны в крупных компаниях, тоже не всегда руководители инженеры), это приводит к печальным последствиям для IT рынка. Сначала нанимают партию разработчиков, через год или два, шеф проходит специальные курсы по бизнесу и открывает новые слова: "B2B" и "B2C". Он смотрит в собственное отражение и видит гениального человека, способного открыть свой телеграм канал и продовать свои собственные курсы. Увольняем 90% разрабов, получаем чистый профит с курсов. \ STONKS /
Судная ночь
Сайт в итоге сделали, правда за несколько часов до презентации (они решили все вместе приехать в офис клиента и открыть бутылку шампанского), а тут оказывается на сайте должно быть так, а ни сяк.
-- Эту кнопку убрать! Батюшки, я ведь всё ни так! Клиент? Какой клиент! Я так вижу! Сделать по моему! Клиент потом посмотрит и скажет. В смысле, конечно макет утвержден! Видишь дизайнер тока что стрелочки в дизайне дорисовал, а у тебя их нет! А ну быстро отсеките голову этому халопу! Стража! Стража!
Титры
Нет повести печальней, чем история о Shaltier и потерянном времени. Почему никто не плачет? Не забываем купить мои курсы "Как открыть IT стартап для ...". Продолжение пишем в комменты.
Спасибо за ваше потраченное время, надеюсь в следующий раз, контент будет лучше. Обычно мы начинаем работать в компании для поднятие скила, но этот опыт равносилен фрилансу, да еще платят меньше и мозг съедают чайной ложкой.
В воскресенье, 5 мая, Ренд Фишкин (известный во всем мире как основатель популярного сервиса Moz.com) получил электронное письмо от человека, утверждающего, что у него есть доступ к массивной утечке документации API из внутреннего подразделения поиска Google. В письме также утверждалось, что эти утекшие документы были подтверждены как подлинные бывшими сотрудниками Google, и что эти бывшие сотрудники и другие лица поделились дополнительной, приватной информацией о работе поиска Google.
Один из скринов "слитой" базы Google
Многие из их заявлений прямо противоречат публичным заявлениям сотрудников Google, сделанным за последние годы. В частности многократным отрицаниям компании о том, что сигналы пользователя, связанные с кликами, используются, что субдомены рассматриваются отдельно в ранжировании, отрицаниям существования песочницы для новых сайтов, отрицаниям того, что возраст домена собирается или учитывается, и многому другому.
"Сливщиком" информации оказался Эрфан Азими (ссылка на Линкедин). В его профиле указана Грузия как страна проживания. Именно он показал Ренду саму утечку: более 2,500 страниц документации API, содержащей 14,014 атрибутов (функций API), которые, по-видимому, происходят из внутреннего "Content API Warehouse" Google. Судя по истории коммитов документа, этот код был загружен на GitHub 27 марта 2024 года и не удален до 7 мая 2024 года.
Что интересного в этих документах?
Ложные Утверждения Google, Опровержения которых обнаружены в Документации API
Утечки документации API Google раскрыли значительные противоречия между публичными заявлениями Google и их реальными
Авторитет домена: Google неоднократно отрицал использование "авторитета домена", утверждая, что они не используют метрику для измерения авторитета сайта в целом. Однако утекшие документы показывают существование метрики под названием "siteAuthority", используемой в внутренних системах Google, что противоречит их публичным заявлениям. Такие известные личности, как Гэри Илш и Джон Мюллер, неоднократно заявляли, что Google не использует метрику авторитета сайта, что теперь кажется вводящим в заблуждение.
Использование кликов для ранжирования: Представители Google давно отрицают, что клики влияют на ранжирование в поиске. Несмотря на эти утверждения, свидетельства из антимонопольного процесса Министерства юстиции США и различных патентов указывают на существование систем, таких как NavBoost и Glue, которые используют данные о кликах для влияния на результаты поиска. Эти системы существуют с 2005 года и используют обновляемые данные для настройки результатов поиска на основе кликов пользователей. Эта практика противоречит публичным отрицаниям Google и подчеркивает их попытки ввести в заблуждение сообщество SEO.
Эти открытия подчеркивают разницу между публичными заявлениями Google и их внутренними операциями, вызывая вопросы об их искренности.
Что будет дальше?
Пожалуй, ничего. Google наверняка будет открещиваться и утверждать, что все это фейк. Признавать свои ошибки никому не хочется:) В любом случае мир SEO теперь не умрет совсем, но людям, которые работают в этой сфере будет наверняка интересно сопоставить свои знания с тем, что упоминается в слитых документах.
Что лично почерпнул для себя автор этих строк
Даты публикаций очень важны - Google ориентирован на свежие результаты, и документы иллюстрируют многочисленные попытки ассоциировать даты со страницами.
Фрагмент с упоминанием про важность упоминания дат изменений контента
Лучший подход – указать дату и быть последовательным в ее использовании в структурированных данных, заголовках страниц, XML-картах сайта. Указание дат в URL, которые противоречат датам в других местах на странице, скорее всего, приведет к ухудшению ранжирования контента. Что ж попробую протестировать полученные знания в своем блоге :)
За последние годы, как бы это ни было странно, но моим основным облачным хранилищем стали «Избранные» в Telegram, потому что сервис доступен на всех платформах и сам открыто рассказывает об этой возможности в своих соцсетях. В какой-то момент я столкнулся с проблемой того, что куча файлов в «Избранном» выглядит слишком кучно и разбирать во всем этом неудобно.
Недавно я наткнулся на проект Teledrive, который позволяет сделать из вашего Telegram настоящее облачное хранилище со структурой, папками и возможностью делиться ссылками на загрузку файлов с другими людьми.
В этом материале я расскажу, как установить Teledrive на свой облачный сервер и получить свое безлимитное облачное хранилище за 300 рублей в месяц. И это не кликбейт! Процесс установки займет всего 15 минут.
Создаем базу данных
Первое, что я советую сделать это создать базу данных postgresql — она как раз отвечает за хранение информации о структуре файлов и папок в Teledrive. Получается, что вы можете развернуть Teledrive на любом железе и при подключении базы данных у вас всегда будет ваша привычная структура файлов.
Для удобство создание postgresql я использую бесплатный сервис Neon.
После того как вы зарегестрируетесь в нем, на стартовом экране введите любое название проекта и название базы данных. В списке выбора хранилища выберите Франкфурт — так получение информации из базы данных будет максимально быстрым.
После создание у вас появится окно с ссылкой на базу данных, отобразите скрытые данные и скопируйте ссылку в заметки. Она пригодится позже.
Далее необходимо арендовать облачный сервер. Nwo
Арендуем сервер
Далее необходимо арендовать облачный сервер, на котором мы будем разворачивать Teledrive. Я использую российский хостинг VDSina (реф), так как у них стабильная скорость интернет-порта 1 Гбит/сек и объём трафика 32 ТБ в месяц. Вы можете использовать любой другой хостинг, которым вы пользуетесь.
Файлы, которые вы будете загружать в Teledrive будут храниться на серверах Telegram в вашем аккаунте! Сервер нужен только для работы приложения, на нем никакие файлы храниться не будут.
Главное, чтобы облачный сервер соответствовал следующим характеристикам:
Процессор: 1 ядро
RAM: 2 Гбайт
Хранилище: 50 Гбайт
Локация: Москва
Стоимость: 13 рублей в день (390 рублей в месяц)
Особенно обратите внимание на объем оперативной памяти, её должно быть не меньше 2 Гбайт. На сервере с 1 Гбайт у меня Teledrive не заработал.
Подготовка к установке
После того как вы создали базу данных и арендовали сервер, откройте данные для подключения к серверу из тикета, запустите терминал и поочередно вводите следующие команды:
ssh root@ip-адрес сервера (его можно найти в Поддержка/Тикеты)
Согласитесь с подключением — yes
После введите пароль сервера (его также можно найти в тикете)
apt-get update (обновляем сервер)
apt-get install build-essential (устанавливаем пакеты, необходимые для компиляции программы)
nvm install v18.16.0 (устанавливаем Node.JS версии 18.16.0 через NVM)
npm i -g yarn (устанавливаем Yarn)
sudo apt install postgresql -y (устанавливаем ПО для базы данных)
apt-get install tmux (устанавливаем мультиплексор для фоновой работы Teledrive)
tmux new -s teldr (создаем сессию мультиплексора для фоновой работы Teledrive)
После этого окно терминала должно обновиться, начнется новая сессия tmux, в которой мы будем держать запущенный Teledrive. Теперь приступаем к установке.
После у вас появится окно с вводом данных для подключения приложения. Переходим на сайт my.telegram.org и входим под тем аккаунтом.
Переходим в раздел API и копируем из окна следующие данные в терминал. Поля ввода будут появляться друг за другом
TG_API_ID: ID приложения
TG_API_HASH: хэш-номер
ADMIN_USERNAME: имя пользователя Telegram, у которого будут права администратора
DATABASE_URL: адрес базы данных из сервиса Neon, который вы должны были сохранить в начале
PORT: номер порта
REACT_APP_API_URL: адрес, через который вы будете заходить на Teledrive (вводите в формате: http://IP-адрес сервера:номер порта, например, http://123.4.56.7.8:1234)
После ждем 10 минут, пока Teledrive устанавливается. Когда процесс будет завершен появится сообщение «running at (адрес порта)».
После этого можете закрыть терминал и начинать пользоваться Teledrive. Вход в оболочку осуществляется также, как вход в приложение Telegram. Загружать файлы в хранилище можете через браузер с любого устройства.
Объём хранилища не ограничен. Единственное, что максимальный размер одного файла составляет 4 Гбайт для Premium-пользователей и 2 Гбайт для тех, кто не имеет подписки.
Так что бэкап целого компьютер не сохранить, однако я нашел применение Teledrive для сохранения сериалов, чтобы всегда иметь к ним удобный доступ, например в дороге. А также в сохранении документов и фото, рассортированным по папкам.
Учитывая что общая ёмкость не ограничена, за 300 с небольшим рублей в месяц получается приятная альтернатива стандартным облачным хранилищам.
Пользуйтесь! Если есть вопросы — пишите в комментарии.
На сайте SQLize.online версия БД Сокол (SoQoL) обновлена до 3.0.1 - все кто следит за развитием проекта могут ознакомиться с новыми функциями добавленными в этой версии.
useOptimistic — новый хук, который позволяет отобразить “оптимистичное” состояние. Оно называется “оптимистичным”, потому что мы “оптимистично” надеемся, что наш запрос не свалится с ошибкой и после выполнения запроса состояние будет выглядеть именно так.
❓Как используется
- В useOptimistic передаётся реальное состояние (cart) и функцию-reducer, для обновления оптимистичного состояния - Компонент (Cart) использует “оптимистичное” состояние (optimisticCart) для рендера - Перед выполнением запроса обновляется “оптимистичное” состояние - Когда запрос завершился, нужно обновить реальное состояние - Как только реальное состояние обновилось, оптимистичное состояние обновится автоматически, так как оно передано в useOptimistic первым параметром. ⚠️ Поэтому важно следить, чтобы приходило одно и то же состояние. - Если запрос упал с ошибкой, нужно откатить изменения в оптимистичном состояниb.
ℹ️ Первый вопрос, которым я задался, а в чём отличие от обычного setState, путём экспериментов, вот что удалось найти:
- useOptimistic работает с формами. Работать с обычной кнопкой в Single Page Application мне не удалось, обновление происходило только после завершения запроса - useOptimistic работает только внутри асинхронного обработчика, что логично. Если убрать async/await, обновление произойдёт только после завершения запроса - Параметр в useState используется только для инициализации, и игнорируется в последующих рендерах. useOptimistic будет сихронизироваться со значением переданным первым параметром.
🤷♂️ Очень мало полезного удалось найти о useOptimistic. Во всех статьях и видео тривиальные примеры, нигде не рассказывается как обрабатывать более сложные ситуации:
- Как обновлять оптимистичное состояние, если запустить несколько запросов одновременно? - Как использовать useOptimistic в SPA вне форм?
Поэтому пришлось создать пару ишью: раз и два. В любом случае, пока useOptimistic выглядит каким-то низкоуровневым API. Надеюсь скоро появится больше Best Practices по его применению. Если вам есть что добавить — пишите в комментах.
use — новый хук, который позволяет считывать данные из промиса и при этом интегрирован с Suspense и ErrorBoundary.
ℹ️ Основные моменты:
- На этот хук не распространяются правила хуков — его можно использовать внутри циклов и условных операторов. - Если мы используем хук use(Promise), то где-то в родительском компоненте мы должны положить сам промис (не данные как мы делали раньше) в стейт (useState). Это позволяет избавиться от useEffect’а, который был нужен, чтобы запросить данные при первом рендере. - Хук интегрирован с Suspense, поэтому пока промис не разрезолвится — будет показан fallback объявленный в ближайшем Suspense. - Если промис зареджектился, то будет показан fallback объявленный в ближайшем ErrorBoundary
Опытные специалисты предпочитают работать за компьютером, обходясь без мышки. Зачем? Все действия можно выполнить с помощью клавиатуры, что значительно повышает эффективность работы. Запомните хотя бы три комбинации клавиш, которые значительно увеличат скорость работы за ПК.
1. Поиск на странице: Используйте комбинацию клавиш «Ctrl+F», чтобы быстро найти нужную информацию на странице. Это сокращает время, потраченное на поиск, и делает работу более продуктивной.
2. Открытие новой вкладки: Нажмите «Ctrl+T», чтобы мгновенно открыть новую вкладку в браузере. Это удобно, если вам нужно быстро переключаться между несколькими страницами или источниками информации.
3. Переход в адресную строку: С помощью комбинации «Ctrl+L» можно мгновенно перейти в адресную строку браузера. Это позволяет быстро вводить новые адреса веб-сайтов или выполнять поиск без необходимости использовать мышь.
Запоминая эти три простых комбинации клавиш, вы сможете значительно увеличить свою производительность за компьютером.