Jump to content
View in the app

A better way to browse. Learn more.

T.M.I IThub

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

IThub

Administrators
  • Joined

  • Last visited

Blog Entries posted by IThub

  1. Технические интервью пугают не сложностью задач, а неопределённостью. Кажется, что могут спросить абсолютно всё — и поэтому многие начинают готовиться хаотично: читают десятки статей, пересматривают сотни видео, зубрят определения. Результат? Знаний больше, а уверенности — меньше.
    На самом деле, техническое собеседование устроено гораздо проще и предсказуемее, чем кажется. Если понимать, что проверяют на самом деле, подготовка превращается из хаотичного марафона в точечный и эффективный процесс.
    Что реально проверяют на техническом интервью
    Смотря на разные компании, подход почти всегда одинаковый:
    База и понимание, а не зубрёжка.
    Интервьюера интересует не «знаешь ли ты все методы массива», а понимаешь ли, как работает код. Часто просят объяснить понятие своими словами или разобрать на примере. И сразу видно, где теория заучена, а где есть настоящее понимание.
    Умение думать, а не угадывать.
    Даже если точного ответа нет, логическая цепочка рассуждений и умение задавать уточняющие вопросы сильно выигрывают у молчания или попыток вспомнить «правильную формулировку».
    Опыт применения знаний.
    Коммерческий проект, учебный проект — не важно. Главное, чтобы ты мог рассказать, где и как применял то, о чём говоришь. Пустые слова сразу считываются.
    Почему большинство проваливается
    Готовятся как к экзамену.
    Заученные ответы срабатывают до первого уточняющего вопроса. Как только интервьюер меняет формулировку или просит пример — «картонная» подготовка разваливается.
    Перекос в теорию.
    Можно часами объяснять, что такое замыкания или REST, но теряться при вопросе «покажи, как это выглядит в реальном проекте». Для работодателя это сигнал: знания не применялись на практике.
    Страх сказать «не знаю».
    Многие пытаются выкрутиться и уходят в общие слова, а честное «не знаю, но могу подумать» выглядит сильнее и честнее.
    Как готовиться правильно
    Ориентируйся на вакансии.
    Реальные описания вакансий показывают, что повторяется из раза в раз. Разбирай эти темы глубоко, не поверхностно.
    Объясняй вслух.
    Пока знания живут в голове, кажется, что всё понятно. Попробуй проговаривать темы — сразу видно пробелы. Это один из самых эффективных способов подготовки.
    Проекты как опора разговора.
    Проект нужен не для резюме, а как база для диалога. Ты должен уметь рассказать, что делал, почему выбрал подход и с какими трудностями столкнулся. Даже учебный проект может выглядеть убедительно, если ты понимаешь его.
    Тренируй сам формат интервью.
    Стресс, паузы, прямые вопросы — к этому нужно привыкнуть. Те, кто имитировал собеседования или уже проходил их, почти всегда выглядят сильнее.
    Итог
    Техническое интервью — это не тест на идеальность, а способ понять, можно ли с тобой работать как с инженером.
    Если ты:
    понимаешь базу,
    умеешь рассуждать,
    не боишься признавать пробелы,
    можешь рассказать про свой код —
    …то ты уже на практически стопроцентной дороге к успеху.
  2. Если ты начинающий frontend-разработчик, рано или поздно сталкиваешься с вечным вопросом: «Знаний много, а опыта работы нет. Что делать?»
    Ответ простой — делать pet-проекты.
    Что такое pet-проект и зачем он нужен
    Pet-проект — это личный или учебный проект, который ты создаешь самостоятельно, чтобы:
    Закрепить знания HTML, CSS, JavaScript.
    Показать, что умеешь работать с фреймворками (чаще всего React).
    Продемонстрировать мышление разработчика, а не просто умение сверстать экран.
    Для работодателя pet-проект — это возможность увидеть, как ты думаешь и решаешь реальные задачи.
    Почему большинство pet-проектов не помогают найти работу
    Типичные ошибки новичков:
    Слишком простые проекты. Todo-листы, калькуляторы или прогноз погоды без архитектуры и логики — это разминка, а не портфолио.
    Проекты не похожи на реальные задачи. Работодателю важно увидеть работу с состоянием, API, формами, ошибками, а не просто «сделал экран».
    Невозможно объяснить проект. Если ты не можешь рассказать, что и зачем сделал, проект не работает на собеседовании.
    Какой pet-проект действительно работает
    Хороший проект для junior frontend-разработчика:
    Заменяет коммерческий опыт.
    Показывает, как ты думаешь.
    Демонстрирует, что умеешь доводить задачи до конца.
    Характеристики:
    Решает понятную задачу.
    Использует современный стек (JavaScript / React / API).
    Имеет структуру, а не набор файлов.
    Содержит состояния, обработку ошибок, пользовательские сценарии.
    И главное — проект можно разобрать и защитить на собеседовании.
    Идеи pet-проектов, которые реально ценятся
    1. Упрощённый интернет-магазин
    Один из лучших вариантов для новичка.
    Что важно реализовать:
    Каталог товаров.
    Фильтры и сортировку.
    Корзину и работу с состоянием.
    Загрузку данных через API или mock-сервер.
    Такой проект показывает, что ты понимаешь, как выглядят реальные frontend-задачи.
    2. Личный кабинет пользователя
    Проект ближе к реальным продуктам.
    Можно добавить:
    Регистрацию и авторизацию.
    Формы с валидацией и обработку ошибок.
    Редактирование профиля.
    Работа с токенами на базовом уровне.
    3. Дашборд с данными
    Сильный проект, если сделан грамотно:
    Аналитика продаж или статистика пользователей.
    Трекинг задач и прогресса.
    Показывает умение работать с графиками, таблицами, состояниями.
    4. Сервис с поиском и фильтрами
    Отличная идея для демонстрации frontend-навыков:
    Работа с API и асинхронность.
    Отображение состояний: loading / error / empty.
    Базовая архитектура компонентов.
    Примеры: каталог фильмов, база книг, список курсов или вакансий.
    Сколько pet-проектов нужно junior frontend-разработчику
    Частый вопрос: «Сколько проектов достаточно?»
    Ответ: 2–4 продуманных проекта лучше, чем 10 слабых.
    Идеальный набор:
    1 крупный проект.
    1–2 средних.
    1 экспериментальный, где видно твой рост.
    Как оформить pet-проект для портфолио
    Чтобы проект реально работал на трудоустройство:
    Выложи код на GitHub.
    Напиши понятный README.
    Опиши, какие задачи решал.
    Добавь деплой (GitHub Pages, Vercel).
    Будь готов объяснить архитектурные решения.
    Помни: работодатели оценивают не только результат, но и ход мысли.
    Итог
    Pet-проекты — это не формальность и не «галочка». Это главный инструмент, который заменяет коммерческий опыт на старте.
    Если хочешь работать frontend-разработчиком:
    Делай проекты, похожие на реальные продукты.
    Думай как инженер, а не ученик.
    Используй проекты как повод для диалога с работодателем.
  3. DevOps — это не профессия.
    Это состояние души, когда ты одновременно чинишь прод, объясняешь, что он «не падал», и пишешь постмортем, в котором виноват «непредсказуемый внешний фактор».
    Если программисты шутят про код, то DevOps шутят про боль.
    Про ночь без сна. Про алерты всюду. Про «всё работало на стейдже».
    Ниже — подборка самых смешных и одновременно правдивых DevOps-шуток, которые любят люди из индустрии. Если ты смеёшься — значит, ты в теме. Если не смеёшься — подожди, скоро дойдёт.
    1. DevOps — это когда ты знаешь, почему всё упало
    …но не знаешь, кто именно это сделал.
    2. «У нас ничего не менялось»
    — последняя фраза перед инцидентом.
    3. Прод не упал
    Он просто временно перешёл в режим обучения пользователей терпению.
    4. DevOps не ломают прод
    Они проверяют отказоустойчивость в боевых условиях.
    5.
    — Почему сервис упал?
    — Потому что он был жив.
    6. Лучший мониторинг — это Twitter
    Пользователи всегда узнают первыми.
    7. Если у тебя нет бэкапа —
    значит, ты веришь в себя.
    8. DevOps — это человек,
    который может исправить проблему за 5 минут,
    но будет объяснять, почему она произошла, две недели.
    9. Всё автоматизировано
    …кроме того момента, когда горит прод.
    10. «Это не баг, это фича»
    В DevOps-версии звучит так:
    «Это временное архитектурное решение».
    11.
    — Можно задеплоить в пятницу?
    — Можно.
    — А вы смелый.
    12. Kubernetes решает все проблемы
    …кроме тех, которые он создаёт.
    13. DevOps — это когда ты знаешь,
    что алерт сработал правильно,
    но всё равно его ненавидишь.
    14. Самый надёжный сервер —
    тот, к которому никто не прикасался.
    15. Если сервис работает —
    не трогай его.
    Если не работает —
    не трогай его ещё сильнее.
    16. «Мы просто обновили одну маленькую зависимость»
    — историческая причина 90% аварий.
    17. Хороший DevOps не тот,
    у кого ничего не падает,
    а тот, кто знает, где лежит кофе в 3 ночи.
    18. Infrastructure as Code —
    пока не нужно срочно починить одну мелочь в проде.
    19.
    — Почему алерты не пришли?
    — Потому что алерты тоже лежат.
    20. Самый опасный человек в компании —
    DevOps с правами администратора
    и хорошим настроением.
    21. «Мы воспроизвели проблему»
    — и она исчезла.
    22. Если DevOps молчит —
    значит, либо всё идеально,
    либо он уже принял неизбежное.
    23. Документация — это то,
    что обязательно появится после инцидента.
    24. DevOps — это когда ты одновременно
    инженер, психолог и громоотвод.
    25. Всё можно починить
    …если у тебя есть доступы и rollback.
    Вместо вывода
    DevOps-шутки смешные не потому, что они черный юмор.
    А потому что они слишком правдивые.
    Если ты узнал себя хотя бы в половине — поздравляю, ты настоящий DevOps.
    Если во всех — пожалуйста, возьми выходной.
  4. Многие уверены, что программисты — замкнутые интроверты, которые разговаривают только с монитором и питаются кофе.
    На самом деле это не так.
    Программисты — это люди с богатым внутренним миром, высокой концентрацией на цели и очень специфическим чувством юмора 🤓
    Да, их шутки не всегда понятны тем, кто далёк от IT, но именно в этом и суть — они смешные, болезненно правдивые и иногда пугающе точные.
    Итак, встречайте: топ-30 шуток о программистах, после которых вы либо засмеётесь, либо задумаетесь, либо уволитесь.
    1. Не переживай, если что-то не работает как надо.
    Если бы всё работало идеально — тебя бы здесь давно не было 😌
    2. С программистами есть одна проблема:
    ты не понимаешь, что он делает… пока не становится слишком поздно 😐
    3. Настоящий программист всегда смотрит налево и направо,
    даже переходя улицу с односторонним движением 🚦
    4. Плохо написанный код одного —
    это стабильная работа и хлеб другого 🍞
    5. Если девушка просит починить компьютер — не радуйся.
    Возможно, там уже ничего не спасти 💀
    6. Пиши код так, будто человек, который будет его поддерживать,
    — психопат…
    и он знает, где ты живёшь 🔪
    7. Не получилось написать хорошую программу с первого раза?
    Назови её «Версия 1.0».
    Все так делают 👍
    8. Придя на работу, не торопись начинать.
    Дай компьютеру прогреться минут 20.
    Он тоже не жаворонок ☕💤
    9. Никогда нет времени сделать всё правильно…
    Зато всегда хватает времени сделать ещё больше неправильно 🤦‍♂️
    10. Компьютер — это зло 😈
    Но стоит его выключить, как появляются два новых зла:
    телевизор 📺 и холодильник 🥪
    11. 90% кода занимают 90% времени проекта.
    Оставшиеся 10% кода требуют ещё 90–100% времени.
    Магия ✨
    12. Существует два типа языков программирования:
    на одни все жалуются,
    а другими никто не пользуется 🤷‍♂️
    13. Всегда не хватает времени на разработку,
    но его почему-то хватает, чтобы сделать вдвое больше багов 🐞🐞
    14. Если бы появился язык программирования на разговорном английском,
    выяснилось бы, что большинство программистов его не знают 🇬🇧❌
    15. Если в Java добавят функцию очистки мусора,
    большинство Java-приложений удалят себя сразу после установки 🗑️
    16. В теории между теорией и практикой нет разницы.
    На практике — есть 😬
    17. Компьютерам можно доверять…
    пока они не научились думать самостоятельно 🤖
    18. Сходство между Java и JavaScript
    примерно как между Сомали и сомом 🐟
    19. Плохого кода не существует.
    Есть код, который неправильно поняли 🙃
    20. Перед тем как удалить файл, убедись, что он твой.
    Самые надёжные компоненты — те, которых нет ❌
    21. Если айтишник пришёл на работу вовремя —
    значит, он просто не уходил 🌙
    22. Слишком много мыслей в голове?
    Попробуй… заархивировать 📦
    23. Хотел задать вопрос:
    IT — это ориентация или всё-таки диагноз? 🤔
    24. Вы даже не представляете,
    сколько психической энергии разработчики потратили,
    пытаясь понять разницу между алгоритмом и программой 🧠🔥
    25. Бог создал мир за 6 дней по одной простой причине —
    у него не было предыдущих версий 🌍
    26. Хотите получать от программирования только пользу?
    Ответ прост:
    не программируйте 😎
    27. Главная задача разработки —
    сделать что-то, что доживёт хотя бы до релиза 🏗️
    28. Компьютер отлично выполняет инструкции,
    но, к сожалению, не читает ваши мысли 🧠❌
    29. Финальной версии не будет,
    пока жив хотя бы один пользователь 👀
    30. Баг — это не ошибка.
    Это ещё не задокументированная фича 🐞✨

  5. Top DevOps Jokes That Hit Way Too Close to Home

    DevOps is not a profession.
    It’s a state of mind where you’re fixing prod, explaining that it “never actually went down,” and writing a postmortem blaming an “unpredictable external factor” — all at the same time.
    If programmers joke about code, DevOps joke about pain.
    About nights. About alerts. About “it worked fine on staging.”
    Below is a collection of the funniest and at the same time painfully accurate DevOps jokes loved by people in the industry.
    If you’re laughing — you’re one of us.
    If you’re not — give it time. It will hit you.
    DevOps is when you know why everything went down
    …but you don’t know who did it.
    “Nothing has changed”
    —the last sentence before an incident.
    Prod didn’t go down.
    It temporarily entered user patience training mode.
    DevOps don’t break prod.
    They test fault tolerance in real combat conditions.

    — Why did the service go down?
    — Because it was alive.
    The best monitoring system is Twitter.
    Users always find out first.
    If you don’t have backups —
    it means you believe in yourself.
    A DevOps engineer is someone
    who can fix an issue in 5 minutes,
    but will spend two weeks explaining why it happened.
    Everything is automated
    …except the moment when prod is on fire.
    “It’s not a bug, it’s a feature.”
    In DevOps language, that’s:
    “It’s a temporary architectural decision.”

    — Can we deploy on Friday?
    — We can.
    — You’re a brave person.
    Kubernetes solves all problems
    …except the ones it creates.
    DevOps is when you know
    the alert fired correctly,
    but you still hate it.
    The most reliable server
    is the one nobody touched.
    If a service works —
    don’t touch it.
    If it doesn’t work —
    don’t touch it even harder.
    “We just updated one small dependency”
    —the historical cause of 90% of outages.
    A good DevOps engineer isn’t the one
    whose systems never go down,
    but the one who knows where the coffee is at 3 a.m.
    Infrastructure as Code —
    until you urgently need to hotfix one tiny thing in prod.

    — Why didn’t the alerts fire?
    — Because the alerts are down too.
    The most dangerous person in a company
    is a DevOps engineer with admin rights
    and a good mood.
    “We reproduced the issue”
    —and it disappeared.
    If a DevOps engineer is silent —
    either everything is perfect,
    or they’ve already accepted the inevitable.
    Documentation is something
    that will definitely appear after the incident.
    DevOps is when you are simultaneously
    an engineer, a psychologist, and a lightning rod.
    Everything can be fixed
    …if you have access and a rollback.
    Final Thoughts
    DevOps jokes aren’t funny because they’re mean.
    They’re funny because they’re too true.
    If you recognized yourself in at least half — congratulations, you’re a real DevOps engineer.
    If in all of them — please take a day off.
  6. Top 30 Programmer Jokes (ENG Ver)

    Many people believe that programmers are socially awkward introverts who only talk to their monitors and survive on coffee.
    That’s not entirely true.
    Programmers are people with rich inner worlds, extreme focus on goals, and a very specific sense of humor 🤓
    Yes, their jokes aren’t always clear to those far from IT — but that’s the point. They’re funny, painfully honest, and sometimes frighteningly accurate.
    So here it is: the top 30 programmer jokes that will make you either laugh, think… or quit your job.
    Don’t worry if something doesn’t work as expected.
    If everything worked perfectly, you wouldn’t be here 😌
    There’s one problem with programmers:
    you don’t understand what they’re doing… until it’s too late 😐
    A real programmer always looks left and right,
    even when crossing a one-way street 🚦
    Bad code written by one developer
    is job security and daily bread for another 🍞
    If a girl asks you to “fix her computer,” don’t get excited.
    There might be nothing left to save 💀
    Write code as if the person who will maintain it
    is a psychopath…
    and knows where you live 🔪
    Didn’t manage to write a good program on the first try?
    Call it “Version 1.0.”
    Everyone does 👍
    When you get to work, don’t rush to start coding.
    Give the computer 20 minutes to warm up.
    It’s not a morning person either ☕💤
    There’s never enough time to do things right…
    But there’s always enough time to do them wrong again 🤦‍♂️
    A computer is evil 😈
    But turn it off and two new evils appear:
    the TV 📺 and the fridge 🥪
    90% of the code takes 90% of the project time.
    The remaining 10% takes another 90–100%.
    Magic ✨
    There are only two kinds of programming languages:
    those everyone complains about,
    and those nobody uses 🤷‍♂️
    There’s never enough time for development,
    but somehow there’s always time to create twice as many bugs 🐞🐞
    If a programming language were invented in plain spoken English,
    it would turn out that most programmers don’t actually know English 🇬🇧❌
    If Java ever gets a “clean garbage” function,
    most Java apps will delete themselves right after installation 🗑️
    In theory, there’s no difference between theory and practice.
    In practice — there is 😬
    You can trust computers…
    until they learn to think for themselves 🤖
    The similarity between Java and JavaScript
    is about the same as between Somalia and a salmon 🐟
    There is no bad code.
    There is only code that was misunderstood 🙃
    Before deleting a file, make sure it’s yours.
    The most reliable components are the ones that don’t exist ❌
    If an IT guy shows up to work on time,
    it means he never went home 🌙
    Too many thoughts in your head?
    Try… compressing them 📦
    Serious question:
    is IT an orientation or a medical condition? 🤔
    You have no idea
    how much mental energy developers have wasted
    trying to understand the difference between an algorithm and a program 🧠🔥
    God created the world in six days for one simple reason —
    there were no previous versions 🌍
    Want to get only benefits from programming?
    The answer is simple:
    don’t program 😎
    The main goal of development
    is to build something that survives at least until release 🏗️
    A computer follows instructions perfectly,
    but unfortunately, it doesn’t read your mind 🧠❌
    There will never be a final version
    as long as at least one user is still alive 👀
    A bug is not a mistake.
    It’s just an undocumented feature 🐞✨

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.