​Ожидание vs реальность: какие взгляды я поменял за 10 лет в разработке

Старший инженер-программист в Amazon Крис Киль (Chris Kiehl), автор книги по дата-ориентированному программированию на Java поделился заметкой о том, как изменились его взгляды за 10 лет пребывания в индустрии разработки ПО.

А мы решили проверить, насколько мнения разных разработчиков по очевидным и не очень вопросам совпадают или, наоборот, разнятся. Приглашаем обсудить в комментариях.

О чём поменял своё мнение
Вот что я верю сейчас, но о чём раньше бы поспорил:

- Простота — не данность. Она требует постоянной работы.
- Нечем гордиться, если вы оперируете и мыслите сложными конструкциями.
- Типизация в языках программирования нужна в командах с разным уровнем опыта.
- Java — великий язык, потому что скучный.
- Среды REPL (интерактивные среды исполнения) бесполезны в проектировании, но как инструмент для исследований они хороши.
- Львиную долю программирования нужно выполнять задолго до написания первой строчки кода.
- Frontend-разработка — это кафкианский кошмар, который я больше не выношу.
- Привлекательность — это не метрика.
- Эффективное управление бесценно. За свою карьеру я многое повидал и пережил прежде, чем сам узнал, что такое хороший менеджмент.
- DynamoDB — хорошая база данных, только если ваша рабочая нагрузка не выходит за рамки её возможностей.
- Объекты хороши исключительно для тех целей, для которых они предназначены. Слепая преданность функциональному подходу — глупость.

О чём сформировал мнение

- Разработка — это про коммуникацию.
- Никогда не используйте полные монады в Java.
- Планировщик запросов — это злая госпожа.
- Если что-то кажется мне простым — это точно что-то, чего я до конца не понимаю.
- Молодым разработчикам нужно давать пространство для ошибок и экспериментов.
- Нужно активно инвестировать в развитие своих софт-скиллов. Это быстро окупается.
- В разработке приложений мало места для абстракций. Просто пишите нужный код.
- А вот разработка библиотек, наоборот, основана на абстракциях. Потратьте время на поиски алгебраических структур.
- ORM — это дьявол во всех языках и реализациях. Используйте SQL.
- Главная беда функционального программирования — это функциональные программисты.
- В долгосрочной перспективе вы глубоко пожалеете о выборе бессерверных функций.
- Типы — это просто утверждения о мире, в котором работает ваш код.
- Распределённые блокировки по-прежнему и по какой-то непонятной причине остаются очень сложными.
- Навыки формального моделирования и анализа — это база.
- Изоляция — важнейшее свойство хорошего набора интеграционных тестов.
- Худшее, что можно выбрать для разработки приложений общего назначения — это DynamoDB.
- Большинству плевать на ремесло программиста. Берегите тех, кому не всё равно. С остальным смиритесь.
- Будущее за языками с постепенной зависимой типизацией.
- Вы буквально не можете добавлять к тестовому коду слишком много комментариев (готов поспорить с тем, кто сможет).

О чём мнение не поменялось
- Те, кто заморачивается над стилем кода, правилами линтинга и прочими мелочами — извращенцы. Занимайтесь более важными вещами.
- Покрытие кода никак не связано с качеством кода. А зачастую и вовсе обратно пропорционально ему.
- Монолиты остаются довольно няшными.
- Крайне сложно превзойти десятилетия исследований и доработок реляционных баз данных.
- Использование микросервисов нужно обосновывать, а то их всё чаще воспринимают как решение по умолчанию.
- Большинство проектов не нужно масштабировать. Иллюзия этой необходимости только вредит.
- Если завтра исчезнут 93%, а может быть, даже 95,2% проджектов — ничего не изменится, а то и повысится эффективность работы.

А вы согласны с автором или в каких-то моментах готовы поспорить, потому что ваш опыт говорит о другом? Менялось ли ваше отношение к разработке в процессе работы? Расскажите.

👉 @seniorFront

​Переключение между контекстами убивает эффективность разработчиков на корню

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

Как избежать переключения между контекстами

1. 🎯 Ставьте конкретные цели. Задавайте конкретные цели для каждого периода работы, чтобы удерживать концентрацию внимания и эффективно отслеживать прогресс. А ещё ежедневные цели помогают нам понять, что мы хотим успеть за сегодня.

2. 📝 Заносите задачи в список дел. Используйте любой инструмент, например, Todoist или Microsoft To Do, чтобы выгружать задачи из головы. Это снизит напряжённость. В любой момент можно свериться со списком и решить, над какой задачей работать дальше. Выберите самую важную задачу и начните с неё.

3. 🔢 Расставляйте приоритеты. Этот приём поддерживает вовлечённость в работу и не даёт отвлекаться.

4. 🔒 Выделяйте время для сосредоточенной работы. Установите полуторачасовые интервалы для сосредоточенной работы по методике, описанной в книге Кэла Ньюпорта «В работу с головой». Это оптимальное время для сохранения стабильной концентрации внимания. При этом нужно организовать минимум 4–6 часов сосредоточенной работы. Отметьте эти блоки у себя в календаре и для их выполнения выберите время дня, когда вы на пике энергии. Для большинства людей это — утро.

5. 🅿️ Используйте «парковку идей». Во время работы держите открытым текстовый файл. Если вам в голову приходит мысль или возникает новая задача, не переключайтесь на неё, а просто быстро запишите её в файл. Так вы сможете не отвлекаться.

6. 🚧 Оставляйте себе «хлебные крошки» на случай, если вас отвлекут. Когда вы занимаетесь сложной задачей, оставляйте себе подсказки. Если вас отвлекли, лаконичный комментарий о том, почему в файле с исходным кодом в IDE вы написали именно эту строчку, сэкономит вам несколько часов, которые ушли бы на восстановление вашего хода мысли. Этим же приёмом можно пользоваться в конце дня. Тогда завтра вы точно будете знать, с чего продолжить. А ещё это помогает бороться с эффектом Зейгарник — стремлением заполнять рабочую память незавершёнными задачами.

7. 🔕 Минимизируйте отвлекающие факторы. Как вариант, наденьте шумоподавляющие наушники, отключите неважные уведомления или создайте изолированное рабочее пространство. Отличный вариант — выключать на какое-то время мессенджеры и включать на телефоне режим «Не беспокоить».

8. 🤹 Откажитесь от многозадачности. Наш мозг может корректно и сосредоточенно работать только над одной задачей. Так что берите в работу что-то одно.

9. 💺 Продумайте эргономику. Обзаведитесь эргономичным столом и стулом, настройте монитор, чтобы сократить физический дискомфорт.

10. 📂 Организуйте пространство. Не загромождённое рабочее пространство снижает когнитивную нагрузку и помогает сосредоточиться на задаче.

👉 @seniorFront

Интерактивный гайд по CRDT

Благодаря CRDT можно легко создавать приложения с совместным редактированием, такие как Google Docs, но без необходимости подключаться к серверу.

В этой серии статей мы узнаем, что такое CRDT. Затем напишем простой редактор, объединим его с более сложными структурами данных и, наконец, применим то, что мы выучили, чтобы создать совместный редактор, похожий на Paint в онлайне.

https://jakelazaroff.com/words/an-interactive-intro-to-crdts/

#typescript #crdt


Original post link: t.me/tproger_web/5368
Forwarded and filtered by @smartfeed_bot

const

Когда раньше разработчик хотел объявить константу в JavaScript, до ES6 это было лишь условное обозначение переменной в шапке блока. Это не делало переменную безопасной, а всего лишь давало понять другим разработчикам, что перед ними переменная — константа, значение которой не следует менять.

Сейчас мы можем использовать модификатор const. Он не делает переменную неизменной, а просто блокирует ее присвоение (пример 1). Если у вас не примитивное присвоение (объект или массив), в этом случае значение переменной может быть изменено (пример 2).


Original post link: t.me/senior_front/2487
Forwarded and filtered by @smartfeed_bot

Что такое миксины?

Это способ повторного использования кода в различных контекстах. Позволяют вам создавать фрагменты кода, которые могут быть включены в другие объекты или классы. Это помогает избежать дублирования кода и упрощает его поддержку и расширение.

Часто используются для добавления методов или свойств к классам. Это позволяет комбинировать функциональность из разных источников.

let sayHiMixin = {
    sayHi() {
        console.log(`Привет, ${this.name}`);
    },
    sayBye() {
        console.log(`Пока, ${this.name}`);
    }
};

class User {
    constructor(name) {
        this.name = name;
    }
}

// Копируем методы sayHiMixin в User.prototype
Object.assign(User.prototype, sayHiMixin);

let user = new User("Вася");
user.sayHi(); // Привет, Вася
user.sayBye(); // Пока, Вася

В этом примере миксин sayHiMixin добавляет методы sayHi и sayBye к классу User.

Миксины в CSS (Sass/SCSS)
Обычно используются в препроцессорах, таких как Sass или Less. Миксины позволяют определять наборы стилей, которые можно повторно использовать в различных местах стилей.

@mixin border-radius($radius) {
    -webkit-border-radius: $radius;
       -moz-border-radius: $radius;
            border-radius: $radius;
}

.box { 
    @include border-radius(10px);
    width: 100px;
    height: 100px;
    background-color: lightblue;
}

В этом примере миксин border-radius определяет стили для создания скругленных углов. Затем он используется в классе .box для применения этих стилей.

Почему это важно?
- Повторное использование кода: Миксины позволяют избежать дублирования кода, что упрощает его поддержку и уменьшает вероятность ошибок.
- Организация кода: Миксины помогают организовать код, разделяя общую функциональность на логические блоки.
- Удобство и гибкость: С миксинами легко добавлять или изменять функциональность, не затрагивая основные классы или стили.

👉 @seniorFront

​GraphQL или REST: Какой API выбрать, чтобы не прогадать?

Расскажу о GraphQL, сравню с REST. Разберемся в плюсах и минусах каждого подхода к проектированию API. Выбираем лучший для вашего проекта!

Распространенность и интеграция
В 2015 году Facebook представил GraphQL. С тех пор эта технология набирает популярность, но REST остается лидером. По данным Postman на 2024 год, GraphQL используют 29% разработчиков, REST — 90%.

Если заранее неизвестны потребители API, лучше выбрать REST — он проще и популярнее:
- Разработчикам, знакомым с HTTP, легко освоить REST. Он использует стандартные HTTP-методы и принципы.
- REST API можно реализовать на любом языке, поддерживающем HTTP, без дополнительных слоев.
- REST — проверенная технология с сильным сообществом и множеством готовых инструментов.

Получение данных
GraphQL позволяет клиентам запрашивать только нужные данные, избегая избыточного или недостаточного получения. Это повышает эффективность сетевых запросов: передаются только необходимые данные.

Рассмотрим пример. Есть сущность «Игрушка» (Toy), которую создает «Мастер» (Master), привязанный к «Пользователю» (User). У игрушки также есть «Категория» (Category) и «Теги» (Tags).

GraphQL позволяет получить все данные одним запросом:

query getToy {
  toy(id: 1) {
    id
    name
    category {
      id
      name
    }
    tags {
      id
      name
    }
    master {
      id
      info
    }
  }
}

В случае REST API потребовалась бы серия запросов:

GET http://localhost:8080/toys/1 - Получаем игрушку по ID
GET http://localhost:8080/categories/2 - Получаем категорию игрушки по ID, который взяли из объекта игрушки
GET http://localhost:8080/tags?id=1&id=2&id=3 - Получаем теги игрушки по ID, которые взяли из объекта игрушки
GET http://localhost:8080/masters/3 - Получаем мастера игрушки по ID, который взяли из объекта игрушки
GET http://localhost:8080/users/4 - Получаем пользователя, к которому привязан мастер, по ID, который взяли из объекта мастера

В приложениях со сложными связями между доменами GraphQL упрощает получение данных: один запрос вместо пяти (в примере). Кроме того, можно исключить ненужные поля, например, createdAt и updatedAt. GraphQL возвращает только то, что нужно.

Версионирование
GraphQL использует одну версию endpoint. Изменения вносятся в схему без явного версионирования API, что упрощает развитие.

REST API нужно версионировать для безопасных изменений. Обычно это делается в URL, например: http://localhost:8080/v1/toys.

Ошибки и коды ответа
GraphQL всегда отвечает кодом 200 OK, даже при ошибках. Информацию об ошибке ищите в поле errors JSON-ответа. Клиент не может проверить статус по HTTP-коду и вынужден анализировать тело ответа.

REST использует стандартные HTTP-коды (400, 404, 500) для обозначения результата. Это делает обработку ошибок в REST более наглядной

Заключение
Выбор между GraphQL и REST — это вопрос потребностей проекта. REST лидирует благодаря простоте, популярности и развитым инструментам. GraphQL же гибче в запросах: запрашиваем только нужное, не перегружаем сеть лишним, что важно для сложных приложений.

Тестировать GraphQL сложнее, особенно с файлами: больше настроек в запросах, чем в REST. GraphQL проще версионировать — меняем схему, и всё, а в REST приходится менять URL. Наконец, GraphQL всегда отвечает кодом 200 и сообщает об ошибках в теле ответа, а REST использует стандартные коды ошибок, что делает их более заметными.

👉 @seniorFront

– OpenAI представила новый голосовой ассистент, который теперь может в реальном времени анализировать изображение, речь и текст — конкуренция Siri и Alexa становится серьезной.
– Google тестирует поиск с интеграцией ИИ-резюме, который меняет привычный способ продвижения сайтов. SEO-специалисты — держитесь!
– TikTok анонсировал AI Creative Assistant — теперь ИИ помогает создавать и тестировать рекламные креативы за секунды.

Хочешь быть в курсе последних новостей в мире ИИ/ИТ/маркетинга ?

Мы собрали папку Telegram-каналов, где эксперты каждый день:

https://t.me/addlist/gs3Io1EOk2lhNmEy

✔ разбирают тренды
✔ выкладывают кейсы
✔ делятся фреймворками, которые экономят десятки часов
✔ и сразу показывают, как использовать ИИ в маркетинге и ИТ на практике.

📂 Открой доступ к Telegram-папке → https://t.me/addlist/gs3Io1EOk2lhNmEy


Original post link: t.me/frontendnoteschannel/4625
Forwarded and filtered by @smartfeed_bot

Стрелочные и обычные функции в JavaScript: в чём разница?

В JavaScript функции — это основа работы с кодом, и их можно писать разными способами: с помощью обычных и стрелочных функций. На первый взгляд, они решают одну задачу — выполняют код, — но различия между ними влияют на то, как и где их лучше применять.

Давайте разберёмся, в чём заключаются эти различия, посмотрим на пример и выясним, когда какую функцию стоит использовать.

Обычные функции пишутся с использованием ключевого слова function, а стрелочные — с помощью более компактного синтаксиса =>.

//Обычная функция
function greet(name) {
  return "Привет, " + name;
}

//Стрелочная функция
const greet = (name) => "Привет, " + name;

This. Одно из главных различий — как функции работают с контекстом this.

— В обычной функции this зависит от того, как её вызвали.
— В стрелочной функции this берётся из внешнего окружения и не меняется.
Это важно, когда вы работаете с объектами или обработчиками событий.

Аргументы. Обычные функции имеют встроенный объект arguments для доступа ко всем переданным параметрам, а стрелочные — нет (но можно использовать ...args).

Конструкторы. Обычную функцию можно использовать с new для создания объектов, стрелочную — нельзя.

Генераторы. Обычные функции поддерживают синтаксис function* для генераторов, стрелочные — нет.

Чтобы понять разницу работы с this на практике, рассмотрим пример с объектом:

const person = {
  name: "Алекс",
  sayHello: function() {
    console.log("Привет, я " + this.name);
  },
  sayHelloArrow: () => {
    console.log("Привет, я " + this.name);
  }
};

person.sayHello();       // Привет, я Алекс
person.sayHelloArrow();  // Привет, я undefined

— В методе sayHello (обычная функция) this указывает на объект person, и мы получаем доступ к свойству name.

— В методе sayHelloArrow (стрелочная функция) this берётся из внешнего контекста (например, window), где name не определён, поэтому результат — undefined.
Этот пример показывает, почему выбор типа функции важен в зависимости от задачи.

Стрелочные функции отлично подходят для коротких коллбэков (например, в map или setTimeout) и случаев, когда не нужен собственный`this`.

Обычные функции нужно использовать в методах объектов, где важен динамический this, или когда нужны конструкторы и объект arguments.

Стрелочные и обычные функции в JavaScript — это инструменты с разными сильными сторонами. Понимание их различий поможет вам выбрать правильный подход для каждой ситуации.

#простымисловами #javascript

​Зачем нужен Nginx?

Nginx — это мощный веб-сервер, который используется для раздачи статических файлов, балансировки нагрузки, проксирования запросов и обеспечения безопасности.

Как Nginx раздаёт фронтенд-приложение?
Когда мы билдим SPA-приложение (например, React/Vue/Angular), в папке dist появляются статические файлы (index.html, app.js, styles.css).

server {
    listen 80;
    server_name myapp.com;
    root /var/www/myapp/dist;
    index index.html;
    
    location / {
        try_files $uri /index.html;
    }
}

Как Nginx проксирует запросы к бэкенду?
Если фронтенд (myapp.com) и бэкенд (api.myapp.com) находятся на разных серверах, Nginx может перенаправлять запросы на API.

server {
    listen 80;
    server_name myapp.com;
    root /var/www/myapp/dist;
    index index.html;

    location / {
        try_files $uri /index.html;
    }

    # Проксирование API-запросов
    location /api/ {
        proxy_pass http://localhost:5000/; # Node.js, Python, PHP и т. д.
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Как Nginx балансирует нагрузку?
Если у нас несколько бэкенд-серверов, Nginx может распределять нагрузку между ними.

upstream backend {
    server backend1.myapp.com;
    server backend2.myapp.com;
}

server {
    listen 80;
    server_name api.myapp.com;

    location / {
        proxy_pass http://backend;
    }
}

Как Nginx ускоряет сайт с кэшем?
Кэширование уменьшает нагрузку на сервер и ускоряет загрузку страниц.

location /static/ {
    expires 7d; # Кэшировать файлы на 7 дней
    add_header Cache-Control "public, max-age=604800";
}

👉 @seniorFront

​Гореть, но не сгорать: практические советы по борьбе с burnout’ом

Важно понять: выгорание — это не ваш личный факап или ошибка. Это сигнал всей системы — целого организма — что что-то идет не так. Бороться с выгоранием через «затыкание дыр» не выйдет. Если вы наконец-то полноценно отдохнете в эту субботу и даже воскресенье, а потом вернетесь к привычному режиму, проблема никуда не уйдет. И если ее игнорировать, тоже.

Что на самом деле нужно делать?
Только системный подход, только хардкор — смена личных и рабочих привычек, выстраивание нового подхода к рабочему процессу. Ниже — несколько советов.

Отказываемся от перфекционизма
Перфекционизм в ИТ не только бесполезен, но даже опасен. Код не обязан быть идеальным с первой попытки, а технический долг — это нормальная история. Можно попробовать упражнение «достаточно хорошо»: установить четкие критерии завершения задачи и не позволять себе бесконечно её улучшать. Никаких больше «Нет предела совершенству».

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

Беремся за физическое восстановление
Здоровье у вас одно, стимуляторы из Fallout у нас пока не изобрели, а бионические протезы не так доступны, как в Cyberpunk 2077. Поэтому беремся за восстановление организма. Учимся замечать усталость. В глазах рябит от кода, в голове туман — идем отдыхать, а не терпим. Можно попробовать внедрить правило 90/30 (30-минутный отдых каждые полчаса) или другой формат перерывов. Естественно, во время отдыха не скроллим ленты и стараемся вообще не смотреть в экран. Обедаем где-нибудь вдали от клавиатуры, если на удаленке — тем более.

Если новые привычки внедрять сложно, делаем это постепенно. Например, сначала учимся по-настоящему уходить на перерыв от работы. Потом отказываемся от гаджетов во время отдыха.

Главное — помните. К этому состоянию вы пришли не за один месяц, а значит, восстановление тоже займет какое-то время. Не ждите, что после недельки в новом режиме или отпуска сразу все наладится.

👉 @seniorFront

Оптимизация производительности веб-приложений с помощью Lighthouse

Цель этой темы - показать, как использовать инструмент Lighthouse от Google для оптимизации производительности веб-приложений. Lighthouse - это автоматизированное средство для проверки качества веб-страниц, которое анализирует различные аспекты производительности и дает рекомендации по их улучшению.

В этом примере мы используем Lighthouse API для запуска аудита производительности веб-приложения. Сначала мы запускаем Chrome в Headless-режиме с помощью chrome-launcher. Затем мы вызываем функцию lighthouse, передавая URL веб-приложения и необязательный конфигурационный объект.

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

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

Разработка адаптивных веб-приложений с помощью Microsoft Blazor

Microsoft Blazor - это фреймворк для создания интерактивных веб-приложений с использованием языка C# и .NET. Одним из ключевых преимуществ Blazor является возможность создания адаптивных приложений, которые автоматически масштабируются и оптимизируются для различных устройств и экранов.

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

Blazor использует компонентную модель разработки, где каждый компонент представляет отдельную часть пользовательского интерфейса. Вы можете создавать более сложные компоненты, взаимодействовать с данными и использовать возможности языка C# для разработки функциональности вашего веб-приложения.

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

Освоение Microsoft Blazor позволит вам создавать адаптивные и интерактивные веб-приложения, используя знакомые инструменты и язык программирования C#.

​Вайб-кодинг: практика, о которой почему-то не говорят

В феврале мир разработки перевернулся с выходом Sonnet 3.7. Потому что вдруг внезапно оказалось, что джуны уже не очень-то и нужны. И нейросетка нормально заменяет мидлов тоже.

Я откидываюсь в кресле, беру наушники и смотрю, как работает LLM. Можно сразу несколько, работающих над разными частями проекта:

Пример проекта с прикручиванием аналитики к инфраструктуре:
- Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
- Попросил превратить это в архитектурный план.
- Отревьюил, поправил тупые ошибки.
- Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
- Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
- Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
- Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
- Написал манифесты для Kubernetes и Docker Compose для локального запуска.
- Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.

И всё.

А теперь практика — что делать с тем, что современные нейросети учились преимущественно на говнокоде и как быть с джунами. Продолжение в статье

👉 @seniorFront

7 признаков профессиональной стагнации разработчика

В мире кода есть понятие code smells — признаки плохого кода. Сегодня я расскажу о junior smells — характерных признаках «старого джуна». У каждого из них есть яркие черты, по которым их легко распознать. И, что самое важное, — для каждого из этих признаков я подготовил конкретное решение, которое поможет перейти на следующий уровень.

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

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

ИИ-зависимость
Когда-то это был синдром «копипасты» со Stack Overflow. Сегодня — новое поколение зависимости: от нейросетей. Всё начинается с удобства — автодополнение, готовые сниппеты, помощь в дебаге. Но со временем инструменты становятся костылём, без которого разработчик чувствует себя беспомощным.

Мастер временных решений
Это один из самых распространённых и опасных признаков старого джуна. В условиях дедлайнов, давления, багов на проде и непрерывного потока задач, он начинает использовать «временные решения» — быстрые костыли, которые якобы потом будут переписаны.

Переусложнитель
Переусложнитель — это не обязательно джун. Это скорее переходная форма: разработчик, обладающий уже неплохими знаниями, но не научившийся правильно дозировать их применение. Он знает архитектурные паттерны, умеет строить сложные системы, но не понимает, когда это уместно, а когда — просто избыточно.

Скоростной гонщик
Это разработчик, который поставил скорость выше всего остального. Быстрее закрытые тикеты, больше строк кода, меньше обсуждений. На первый взгляд — мечта менеджера. Но только до тех пор, пока не наступает фаза изменений. Проблема не в скорости как таковой. Проблема в игнорировании качества. Код гонщика часто не покрыт тестами, написан без оглядки на читаемость и сопровождение, перегружен неочевидной логикой.

Архитектор незаменимости
Этот тип разработчика не просто пишет код — он строит лабиринты. Сложные, запутанные, полные нестандартных решений, нестабильных зависимостей и неписаных правил. Не потому что так надо, а потому что это делает его единственным, кто может с этим разобраться.

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

👉 @seniorFront

🐙 CSS-Protips – подборка из 29 полезных советов по работе со стилями. В некоторых пунктах есть ссылки на документацию и примеры кода.

Сайтодел | #репозиторий #github


Original post link: t.me/sitodel/2305
Forwarded and filtered by @smartfeed_bot

React vs Vue – подробное сравнение и перспективы

В этой статье мы проведём подробный анализ современных практик frontend-разработки, сравним состояние React и Vue 5 лет назад и на текущий момент, а также попробуем спрогнозировать их перспективность в обозримом будущем с учётом развития LLM моделей и AI агентов. Посмотрим их экосистемы (например, Next.js и Nuxt, Zustand и Pinia), использование в бэкенде, популярность решений в энтерпрайзе и понимание разработчиками и LLM моделями.


Original post link: t.me/seniorFront/5231
Forwarded and filtered by @smartfeed_bot

Какие протоколы взаимодействия существуют в WEB?

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

HTTP (HyperText Transfer Protocol)
Это основной протокол для передачи данных в интернете, используемый для загрузки веб-страниц (HTML, CSS, JavaScript и изображений) от сервера к клиенту, обычно веб-браузеру. HTTP определяет методы (например, GET и POST), которые клиенты могут использовать для выполнения запросов к серверам.

HTTPS (HTTP Secure)
Это расширение HTTP, обеспечивающее зашифрованное соединение между клиентом и сервером. Это критически важно для обеспечения безопасности данных пользователя, особенно при передаче конфиденциальной информации, такой как логины и пароли, платёжные данные.

WebSocket
Это протокол, позволяющий устанавливать двусторонние интерактивные соединения между браузером пользователя и сервером. Это особенно полезно для создания веб-приложений, требующих реального времени обмена данными, таких как чаты, игры и торговые платформы.

FTP (File Transfer Protocol)
Это стандартный протокол передачи файлов между компьютерами по сети. Он используется для загрузки и скачивания файлов с сервера, администрирования сайтов и управления содержимым сервера.

SMTP (Simple Mail Transfer Protocol)
Это протокол для отправки электронных писем. Он используется почтовыми серверами для доставки отправленных писем в почтовые ящики получателей.

MAP (Internet Message Access Protocol) и POP3 (Post Office Protocol version 3)
Это протоколы, используемые для извлечения электронной почты из почтового сервера. IMAP предлагает более сложные функции по сравнению с POP3, включая возможность работы с электронной почтой непосредственно на сервере, что позволяет пользователям доступ к почте с разных устройств.

TCP/IP (Transmission Control Protocol/Internet Protocol)
Это основные протоколы, лежащие в основе интернета, обеспечивающие передачу данных между различными устройствами в сети. Он отвечает за установление соединения и гарантию доставки данных, в то время как IP обеспечивает адресацию и маршрутизацию пакетов данных.

DNS (Domain Name System)
Это система, которая переводит доменные имена в IP-адреса, позволяя пользователям легко находить веб-сайты в интернете без необходимости запоминать числовые IP-адреса.

Эти протоколы являются ключевыми для функционирования интернета и веб-технологий, обеспечивая различные аспекты передачи данных, безопасности, обмена сообщениями и доступа к ресурсам.

👉 @seniorFront

Освойте Promises в JavaScript: пошаговое руководство

Асинхронный код — неотъемлемая часть современного JavaScript. Промисы (Promise) помогают управлять такими операциями, обеспечивая чистый и понятный синтаксис. В этом руководстве вы узнаете, как создавать промисы, обрабатывать их состояния (pending, fulfilled, rejected) и использовать методы .then(), .catch() и .finally() для управления результатами асинхронных операций. Примеры кода и наглядные схемы помогут закрепить материал и применять его на практике.

#фронтенд #javascript #асинхронность


Original post link: t.me/tproger_web/5473
Forwarded and filtered by @smartfeed_bot

​Про реальный опыт, и нужен ли он

Мой реальный опыт в Angular — почти 11 месяцев, а в общем во фронтенде около 2.5 лет. До этого я работал на React.

Теперь к сути статьи, недавно я решил пооткликаться на вакансии junior и middle Angular разработчиков, везде в сопроводительных письмах указывая, что у меня опыта 10 месяцев, но зато он настоящий а не накрученный.

Я принципиально против накрутки, с моими знаниями я бы мог без проблем добавить 2 года опыта и пройти собес на мидла, но мне такое не нравится, я за честность.

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

В целом видна тенденция, где работодатели сами подгоняют накрутку опыта, так как не в состоянии разобраться с горой джунов, хотя в Angular пока их не так много, максимум видал в районе 450 откликов, когда на Реакте и больше 1000 бывает.

Но разве так правильно? Если идти дальше во вранье, то можно и собесы проходить с ИИ, и работать потом с gpt o3 или Claude 3.7 sonnet, самостоятельно мало что умея, разве такой квалификации нужны рабочие компаниям? Так может тогда уже в фильтрах не отсеивать джунов с 6–12 месяцев реального опыта, а концентрироваться на них? Ведь если накручивают опыт, то чаще уже от 2х лет, а вот джуны с полгода‑годом опыта, скорее всего имеют опыт реальный.

Знаю нескольких людей с курса который прошёл, они после него накрутили 2 года опыта, без проблем прошли собес и спокойно работают. Понятно что я бы тоже так мог сделать, для эксперимента даже один раз написал 2 года, и приглашения правда начали появляться, причём в крупные компании. Забавно, согласитесь. В целом такая тенденция в IT меня расстраивает, получается накрутка становится единственным способом попасть на работу. Хочется верить что со временем всё подуспокоится.

В целом я с этим уже смирился, так как делаю это не ради денег, а ради удовольствия. И думаю таких как я тут много.

👉 @seniorFront