JavaScript *

Выбор вакансии: как я кинулась во всё — и это не дало результата.

Есть разработчики, у которых развитие идёт линейно и предсказуемо: верстальшик → джун фронтендер → мидл → мидл в сильной компании → сеньор/лид/уход в бэкенд

Красиво. Понятно. Логично.

Но у меня кривая черта развития сначала бэк на Java в закрытом предприятии. Потом фулстек в фудтехе: в основном Vue, но ещё и Go (и все сопутствующее), и CUBA Platform (lowcode на java, он же «Тезис»), и n8n.

Широко. Разнообразно. Интересно.

Как я начала откликаться - на всё, что блестит

И сейчас Когда я вышла на рынок, то сначала я откликалась на все что близко:

1. Frontend - Vue / React / Angular
   Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».

2. Go
   а почему бы нет? Знаю , умею , курсы закончены, писала на нем

3. Fullstack (Go или JDK + фронт)

4. N8N, автоматизаторы особенно с ИИ
   Интересно. Растущее направление.

5. Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?

И это фатал еrror

1. Ошибка №1. Переключение контекста
   Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)

2. Ошибка №2. Рынок
   Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
   
   Рынок перегрет:
   - Vue ~ 1000 откликов за неделю,
   - React - 4000 ,
   
   Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».

3. Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue
   Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик.
   - PHP + Vue - норм
   - Node + Vue - норм,
   но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.

4. Ошибка №4. n8n — нравится, но это уже не совсем разработка
   Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.

5. Ошибка №5. Low-code — карьерный тупик
   Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.

Мой Hotfix: Фокус

Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты

Моя новая стратегия:

• Vue 3 + TypeScript + Nuxt (как зона роста)

• n8n — как подработку и интересный дополнительный навык.

Иногда рост — это не добавить ещё стек. А убрать лишнее.

OAuth на практике: что оказалось удобным, а что отпугнуло пользователей

Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).

Бренда и доверия пока нет, поэтому вопрос авторизации быстро стал не техническим, а психологическим.

С чего начали

Для обычных пользователей:
• Email / пароль
• Google
• GitHub

Для разработчиков — жёстче:
• Обязательная привязка Google
• Обязательная привязка GitHub

Логика казалась разумной:
«Разработчик = есть GitHub»
«Двойная верификация = меньше спама»

На практике это не сработало.

Первые тревожные сигналы

Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.

Сначала списывали на:
• новый продукт
• низкое доверие
• отсутствие аудитории

Но после общения с разработчиками (в том числе через Habr) картина прояснилась.

Что отпугивало разработчиков

1. Новый сервис → нежелание делиться данными

Даже если это «просто email», психологический барьер остаётся.

Когда с первого шага нужно:
• линковать внешние аккаунты
• проходить несколько этапов подтверждения
• подключать сторонние сервисы

это воспринимается как лишний фрикцион.

Особенно для соло-разработчиков и небольших команд.

2. Git ≠ GitHub

Ключевой инсайт.

Мы обнаружили, что:
• не все хотят логиниться через GitHub
• часть использует GitLab или Bitbucket
• некоторые принципиально не хотят связывать GitHub с новым сервисом

Обязательная привязка GitHub стала серьёзным барьером.

А мнение стандартных пользователей разделилось:

Часть говорила:

«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».

Логика простая:
• если есть Google / Facebook / Discord — значит не ноунейм
• интеграции с крупными сервисами повышают доверие

Это не про безопасность — это про ощущение легитимности.

Другие говорили ровно противоположное:

«Слишком много кнопок — ощущение перегруженности».

И это тоже справедливый аргумент.

Что мы изменили

1. Упростили форму для пользователей

Оставили:
• Google
• Facebook
• Discord

Достаточно выбора для доверия, без визуального шума.

2. Git-провайдеры вынесли в отдельную группу

Под отдельной кнопкой:
• GitHub
• GitLab
• Bitbucket

Для разработчиков это стало понятнее и логичнее.

3. Убрали обязательный GitHub

Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.

Без принудительного GitHub.

Первые цифры (осторожно)

Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.

Тем не менее:
• Зарегистрированные пользователи: +13%
(было 0–6% в неделю)
• Зарегистрированные разработчики: +16%
(было 0–3%)

Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.

Выводы (пока не финальные)
• OAuth — это не только безопасность, но и психология доверия
• Жёсткие требования на старте почти всегда бьют по росту
• Git ≠ GitHub — и это важно
• Много провайдеров могут как повышать доверие, так и перегружать UI

Для молодой платформы даже такие ранние сигналы уже показательны.

Интересно услышать опыт коллег:
добавляли ли вы OAuth-провайдеров после запуска?
были ли случаи, когда обязательная авторизация через конкретный сервис тормозила рост?

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

Если судить по названию, автор проекта Promethee кары богов нисколько не боится. Некто SMNX взял самый сакральный слой современного компьютера — прошивку UEFI — и добавил туда JavaScript. Как гласит readme.md, на старте загрузки Promethee подхватывает script.js с загрузочного тома и исполняет его, то есть этот скрипт и будет загрузчиком.

Понятно, что на боевую машину это ставить смысла нет, это просто эксперимент. Лабораторный характер подчёркивается сборкой и запуском в QEMU. Проект реализован автономно (freestanding), с минимальными заглушками libc. В качестве движка используется Duktape — встраиваемый JS-движок, рассчитанный на портируемость и компактность.

Для SMNX это уже не первый подобный забавный самопис. На своём сайте автор представляется как Клем и прямо говорит, что любит строить «операционные системы, компиляторы, инструменты и веб-движки». Там же перечислены другие поделки: модульная хобби-операционка SkiftOS, HTML/CSS-движок Vaev, экспериментальные инструменты для генерации документов, а также операционная система с эстетикой брутализма и идеалами UNIX семидесятых BRUTAL.

JavaScript исторически задумывался как язык, который оживляет веб-страницы и делает их интерактивными. Сегодня же он расползся по всем слоям стека, от микроконтроллеров до ультра-лёгких движков для Интернета вещей. В том числе бывают попытки писать на JavaScript то, что не следует, хоть операционные системы. Самый цитируемый пример — это NodeOS, дистрибутив Linux, где вместо привычного пользовательского мира предлагается использовать Node.js и npm как основной пакетный менеджер, и многие утилиты предполагается брать из npm-экосистемы. Другой полюс — runtime.js, библиотечная операционка, где JavaScript-рантайм на базе V8 и минимальная операционка собираются в лёгкий неизменяемый образ виртуальной машины для запуска на KVM, то есть ОС здесь становится упаковкой для единственного приложения на JS.

Promethee — не первый проект, где соседствуют JavaScript и UEFI. Беглый поиск обнаруживает порт Duktape под UEFI-приложения.

Открытый учебный проект JavaScript Mastery — Complete Learning Path — это курс для изучения языка программирования JavaScript. Энтузиасты собрали более 500 учебных материалов — репозиторий заменяет буквально 4 года учёбы в университете. Есть вся база от определения переменных до ООП, замыканий и других сложных, но функциональных концепций. Сотни упражнений для повторения материалов и закрепления знаний. Примеры кода, визуализация всех концепций, каждый учебный пример авторы разжёвывают до последней строчки. В конце есть идеи пет‑проектов, чтобы закрепить знания. В проекте есть гайд для подготовки к собеседованиям со всеми актуальными вопросами.

А как?

Как?

Реально, как? Скажите мне. Почему это происходит так..

Selectel открыл первую часть курса по JavaScript

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

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

• для чего разработчики используют JavaScript,

• как работать с со скриптами, веб-страницами и переменными,

• как создать рабочее окружение на IT-инфраструктуре Selectel.

Участники курса смогут бесплатно протестировать сервисы Selectel, а по итогам тестирования — получить сертификат о прохождении. 

Начните изучение курса прямо сейчас → 

Макротасок не существует.

Один из самых частых вопросов на собеседованиях для frontend разработчиков: Расскажите про событийный цикл? как выполняются таски? что такое микротаски и макротаски?

В архитектуре event loop вообще нет такого слова как макротаски(macrotasks). Я вообще не смог найти ни одной спецификации, где было бы написано слово macrotask. Кроме Promises/A+. Так в чем же разница между Promise и setTimeout? Почему Promise всегда(не всегда) будут исполняться в приоритете?

Браузер имеет несколько очередей задач (task queues) для разных типов тасок. Таска - это любой javascript код, запланированный стандартными механизмами, такие как запуск программы, запуск события или коллбэки. Помимо этого вы можете создать таску с помощью API, например WindowTimers(setTimeout, setInterval). Микротаски же в свою очередь такие же конструкции javascript, которые позволяют выполнять операции не дожидаясь запуска нового цикла event loop (process.nextTick, Promises, queueMicrotask). Так вот, так как setTimeout, setInterval относятся к браузерному API, то очередь микротасок, таких как Promise и т.д. всегда будет в приоритете выполнения, перед браузерным API.

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

Полезные материалы

1. W3 (https://www.w3.org/TR/2011/WD-html5-20110525/webappapis.html#task-queue)

2. MDN Event Loop (https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)

3. Tasks, microtasks, queues and schedules (https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules)

4. Филипп Робертс: Что за чертовщина такая event loop? | JSConf EU 2014 (https://www.youtube.com/watch?v=8aGhZQkoFbQ)

5. Джейк Арчибальд. В цикле - JSConf.Asia (https://www.youtube.com/watch?v=cCOL7MC4Pl0)

Игра на джем "Rush lvl 8"

Ребята всем привет, опубликовал на джем игру простую, но довольно интересную.

Мне посоветовали её на гитхаб pages выложить, что я и сделал.

Если хотите - зацените геймплей и если хотите непосредственно попробовать то вот ссылка

https://prikalel.github.io/they-grow/

Если хотите поддержать то оставьте комментарий под постом или зайдите на страницу джема и поставьте лайк мне будет очень приятно)

Представлен открытый веб-редактор изображений DPaint.js (онлайн-версия) на JavaScript, созданный по образцу легендарного Deluxe Paint, с упором на ретро-форматы файлов Amiga. Помимо современных форматов изображений, DPaint.js может читать и записывать файлы иконок Amiga и изображения IFF ILBM.

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

Коллеги привет, искал себе решение как реагировать на изменения в объекте и нашел отличный сервис, который используется внутри директив таких как NgClass и NgStyle.

KeyValueDiffers позволяет создать KeyValueDiffer для сравнения изменений текущих пар ключ-значение с новыми. Если вы используете иммутабельные объекты, то можно просто обернуть все в эффект, ну а если вы наследники крутого легаси, где все объекты мутируются по ссылке, тогда проверку нужно вешать в DoCheck, чтобы реагировать на каждый тик change detection.

Накидал оба примера, чтобы поделиться с вами:

Иммутабельный с effect:

@Component({
  selector: 'app-test',
  template: ''
})
export class TestComponent {
  public state = input.required<Record<string, string | number>>();
  
  private differs = inject(KeyValueDiffers);
  private differ: KeyValueDiffer<string, string | number> | undefined;

  constructor() {
    effect(() => {
      const currentState = this.state();
      
      // создаем диффер, если он еще не создан
      if (!this.differ) {
        this.differ = this.differs.find(currentState).create();
      }

      // Эффект будет перезапускаться при изменении инпут-сигнала.
      const changes = this.differ.diff(currentState);

      // только если есть изменения
      if (changes) {
        changes.forEachAddedItem((record) => {
          console.log(`В объект добавлена запись: Ключ: ${record.key} | Значение: ${record.currentValue}`)
        });

        changes.forEachChangedItem((record) => {
          console.log(`Изменено: ${record.key} | Новое значение: ${record.currentValue}`)
        });

        changes.forEachRemovedItem((record) => {
          console.log(`Удалено: ${record.key}`)
        });
        
        // Остальные методы forEachItem и forEachPreviousItem по необходимости
      }
    })
  }
}

Легаси подход, которого, надеюсь, ни у кого нет, но на всякий случай :)

@Component({
  selector: 'app-legacy',
  template: ''
})
export class LegacyComponent implements OnInit, DoCheck {
  @Input({ required: true }) state!: Record<string, string | number>;
  
  private differs = inject(KeyValueDiffers);
  private differ: KeyValueDiffer<string, string | number> | undefined;

  ngOnInit() {
    // Создаем диффер при инициализации
    this.differ = this.differs.find(this.state).create();
  }

  // Запускается на каждый тик change detection, так как мутации по-другому не отследим.
  ngDoCheck(): void {
    const changes = this.differ?.diff(this.state);

    if (changes) {
      changes.forEachAddedItem((record) => {
        console.log(`В объект добавлена запись: Ключ: ${record.key} | Значение: ${record.currentValue}`)
      });

      changes.forEachChangedItem((record) => {
        console.log(`Значение изменилось: ${record.key}`)
      });

      changes.forEachRemovedItem((record) => {
        console.log(`Запись удалена: ${record.key}`)
      });

      // Остальные методы forEachItem и forEachPreviousItem по необходимости
    }
  }
}

Почему у PWA до сих пор нет полноценного «магазина приложений» — возможно ли это вообще?

Всем привет.

В течение последних месяцев, работая с PWA-приложениями, мы постоянно сталкивались с одним и тем же вопросом:

Почему в 2025 году у PWA до сих пор нет настоящего App Store?

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

При изучении существующих PWA-магазинов и каталогов обнаруживаются одни и те же повторяющиеся проблемы.

⸻

1. Установка остаётся непонятной для пользователей

Даже сегодня установка PWA вызывает затруднения у обычных пользователей.

Большинство из них не понимают:
• когда приложение действительно можно установить,
• почему инструкции по установке не совпадают с реальными шагами в их браузере или на устройстве.

Во многих PWA-каталогах всё ограничивается текстовой инструкцией — и на этом взаимодействие с сервисом фактически заканчивается.

⸻

2. Отсутствие доверия

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

Со стороны разработчиков наблюдаются крайности:
• либо любой может опубликовать приложение без подтверждения права собственности,
• либо проверка обязательна, но сложна и ограничена одним способом (например, через DNS-записи).

В итоге доверие не формируется ни у одной из сторон.

⸻

3. Разработчики — второстепенные участники экосистемы

Распространённые проблемы:
• медленные и неудобные процессы публикации,
• почти полное отсутствие автоматического заполнения данных из манифеста,
• нехватка инструментов, которые были бы полезны разработчику ещё до установки приложения пользователем.

Экосистема не стимулирует разработчиков поддерживать и развивать свои PWA.

⸻

4. Интерфейс не воспринимается как «нативный»

Это тонкий, но важный момент.

Если магазин:
• выглядит как обычный веб-сайт,
• не вызывает ассоциаций с App Store или Google Play,

пользователи инстинктивно доверяют ему меньше — даже если сами приложения качественные.

⸻

При этом сами PWA как технология за последние годы заметно повзрослели: офлайн-режим, push-уведомления, installability, Web APIs.
Однако именно слой распространения и доверия остаётся самым слабым звеном.

⸻

Главный вопрос, к которому мы пришли

Возможно ли вообще создать PWA-магазин, который:
• пользователи будут воспринимать как настоящий магазин приложений,
• не станет источником боли для разработчиков,
• сможет устойчиво развиваться, а не быть заброшенным через несколько месяцев?

Или же сама идея магазина PWA в текущей экосистеме изначально ошибочна?

Будет интересно узнать ваш опыт.

Вы публиковали PWA-приложения в существующих магазинах или каталогах?
Что вызывало наибольшие сложности — у разработчиков или у пользователей?

Открытый проект blip в режиме онлайн позволяет визуально оценить сетевую задержку (латентность или latency) при передачи данных от ПК до разных серверов в мире. Решение работает в браузере на любом ПК, ноутбуке, планшете, смартфоне с поддержкой javascript и HTML canvas.

ESLint, Prettier и что не так с насаждением единого стиля

Упомянутые материалы:

• Автоформатирование

• Отступы

• Форматирование имён

+ Копилка благодарностей

Функциональное программирование перевернуло фронтенд: почему JS возвращается к платформам?

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

Статья «Как функциональное программирование изменило фронтенд и почему отрасль возвращается к платформе» разбирает эволюцию: от чистого FP к гибридным решениям, с примерами и выводами для фронтендеров.

Виктория Копылова делится своим анализом, основанным на современных наблюдениях и на тех статьях прошлого, где функциональное программирование воспринималось как путь к «правильному» фронтенду.

polluSensWeb теперь поддерживает 26 датчиков и веб-хуки

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

До сих пор polluSensWeb был в основном инструментом визуализации и диагностики. Данные оставались в сессии браузера. Это было удобно для тестирования, калибровки или демонстрации, но ограничивало возможности реального применения.

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

• Пересылать измерения в базы данных.

• Запускать оповещения или автоматизацию.

• Отсылать данные в панели мониторинга, такие как Grafana.

• Интегрироваться с платформами сообществ или пользовательскими API.

Открытый деплоймент
Проект на GitHub

Как получить почти бесконечное зацикливание без использования циклов и без переполнения стека вызовов:

// Установите N = 64, и эта функция никогда не завершится  
// Количество вызовов (calls) = 2^(N+1)  
// Максимальная глубина вложенности = N

let calls = 0
const N = 18
function func(state, visited) {
  calls++
  if (calls > 10_000_000) {
    throw new Error('calls: ' + calls)
  }
  if (visited.includes(state)) return

  const newVisited = [...visited, state]

  func((state + 1) % N, newVisited)
  func((state + 1) % N, newVisited)
}

func(0, [])
console.log('calls:', calls)

Почему это работает без переполнения стека?

func(0, [])
├── func(1, [0])
│   ├── func(2, [0,1])
│   │   └── ... глубина растёт до N
│   │           и перебираются все возможные комбинации значений в newVisited
│   └── func(2, [0,1]) - возвращается, глубина УМЕНЬШАЕТСЯ
└── func(1, [0])       - второй вызов, стек уже освободился

А Garbage Collector (GC) при этом бесконечно удаляет созданные ранее массивы newVisited

Стек "дышит" - достигает максимума N, потом сворачивается, потом снова растёт. Это обход огромного дерева, имеющего небольшую глубину, но очень большую ширину. Это не бесконечная рекурсия. Но при N = 64 количество вызовов будет 2^65 (примерно 10^19) - это займёт тысячи лет, и стек никогда не переполнится.

DDoS-атаки: почему стандартные решения не спасают и как выстроить эффективную защиту. Интервью ispmanager с GreyWeb

Рады вас приветствовать, дорогие читатели!

Тема противодействия DDoS-атакам остается одной из самых острых и актуальных в сфере IT. Атаки постоянно эволюционируют, становятся более сложными и мощными, заставляя специалистов искать новые, более изощренные методы защиты.

В ispmanager мы регулярно сталкиваемся с вопросами наших пользователей о том, как обезопасить свои серверы и проекты. Именно поэтому мы провели глубокое интервью с ведущими экспертами по кибербезопасности из компании GreyWeb, которые специализируются на профессиональной защите от DDoS.

Что мы обсудили и почему это важно для каждого, кто управляет инфраструктурой:

•  Эволюция угроз: Как меняются DDoS-атаки и почему вчерашние методы защиты сегодня уже неэффективны.

•  Ограничения стандартных решений: Разбор типовых ошибок и мифов, связанных с "базовой" защитой.

•  Комплексные стратегии: Какие подходы и технологии позволяют эффективно отражать даже самые мощные и целевые атаки.

•  Взгляд изнутри: Практический опыт GreyWeb по предотвращению и минимизации ущерба от DDoS, кейсы и рекомендации.

•  Подготовка к атаке: Что нужно сделать заранее, чтобы быть готовым к худшему сценарию.

Это интервью — не просто набор теоретических выкладок, а концентрат практического опыта и аналитики от специалистов, которые ежедневно борются с киберугрозами. Если вы системный администратор, DevOps-инженер, разработчик или владелец сервиса, который не понаслышке знает о рисках DDoS, этот материал будет для вас крайне полезен.

Приглашаем к прочтению: ➡️

https://www.ispmanager.ru/news/case-greyweb

Делитесь вашим опытом борьбы с DDoS в комментариях!

Как автоматизировать Photoshop через кодинг

Когда говорят об автоматизации, чаще всего имеют в виду Python. Но важно понимать: Photoshop не выполняет Python-код напрямую.

Зато у него есть встроенная поддержка скриптов — Photoshop умеет исполнять код на JavaScript (ExtendScript).

Это не «JS как в браузере» и не замена Python. Это родной язык автоматизации Photoshop, с прямым доступом к:

• слоям

• тексту

• смарт-объектам

• экспорту файлов

• истории документа

Если задача — управлять самим Photoshop, то скрипты внутри Photoshop — самый надёжный путь.

Что это даёт на практике

Через код можно:

• массово менять текст в PSD

• генерировать сотни изображений из одного шаблона

• автоматизировать экспорт

• исключить Actions и Variables с их ограничениями

По сути, мы описываем действия, которые дизайнер делает руками, но в виде кода.

Пример задачи

Есть:

• один PSD

• текстовый слой

• значения 1 м → 100 м

Нужно:

• автоматически подставить значения

• сохранить 100 PNG-файлов

• вернуть PSD в исходное состояние

Пример скрипта для Photoshop (JSX)

#target photoshop

var doc = app.activeDocument;
var layerName = "1 м"; // имя текстового слоя
var outputFolder = Folder.selectDialog("Выбери папку для сохранения");

if (!outputFolder) {
    alert("Папка не выбрана");
    exit();
}

function findTextLayer(layerSet) {
    for (var i = 0; i < layerSet.layers.length; i++) {
        var layer = layerSet.layers[i];
        if (layer.kind == LayerKind.TEXT && layer.name == layerName) {
            return layer;
        }
        if (layer.typename == "LayerSet") {
            var found = findTextLayer(layer);
            if (found) return found;
        }
    }
    return null;
}

var textLayer = findTextLayer(doc);
if (!textLayer) {
    alert("Текстовый слой не найден");
    exit();
}

for (var i = 1; i <= 100; i++) {
    textLayer.textItem.contents = i + " м";

    var file = new File(outputFolder + "/pkabel_4x2_5_" + i + "m.png");

    var opts = new PNGSaveOptions();
    opts.compression = 9;

    doc.saveAs(file, opts, true, Extension.LOWERCASE);
}

// откат без сохранения
doc.activeHistoryState = doc.historyStates[0];

alert("Готово!");

Звёзды разработки и практикующие инженеры разбирают горячие темы — от FAIL до GOD. Встречайте tech-шоу «АйТир Лист» от МойОфис.

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

Первый выпуск — опенсорс для фронтенда

Дебютный эпизод мы посвятили популярным опенсорс-решениям для фронтенда: от инструментов, которые давно пора отпускать, до стандартов индустрии.

В выпуске:

• Александр Коротаев — эксперт по фронтенду и креативному кодингу

• Алексей Золотых — тимлид команды веб-редакторов МойОфис

• Ведущий — Эдгар Акопян

Обсуждаем инструменты, которые формируют повседневную фронтенд-разработку, и честно отвечаем на вопрос: что сегодня выглядит как GOD-tier, а что застряло на уровне MVP или FAIL.

Смотрите выпуск: YouTube | RuTube | VK

Второй выпуск — фичи и идиомы C++

Во втором эпизоде «АйТир Листа» — уже не инструменты, а язык.
Мы устроили полноценную битву мнений вокруг фич и идиом C++: 14 табличек превращаются в 14 поводов для дебатов, где каждая возможность языка проходит через экспертную оценку.

В выпуске:

• Данил Черепанов — архитектор редакторов МойОфис

• Антон Полухин — эксперт-разработчик C++ техплатформы городских сервисов Яндекс

• Ведущий — Эдгар Акопян

Получилось много споров, неожиданных аргументов и ситуаций, где «привычно» не значит «хорошо».

Смотрите и делитесь мнением: YouTube | RuTube | VK

В следующих выпусках продолжим разбирать технологии без скидок на хайп и «так исторически сложилось». Предлагайте темы, а если готовы к жарким спорам – становитесь участниками нашего шоу) А как стать? Пишите в комменты с какой темой бы хотели поспорить!

Коллеги, всем привет!

За годы менторства по Angular (в том числе в HTML Academy) я заметил одну системную проблему: студенты и даже миддлы часто знают синтаксис RxJS, но не понимают реактивного мышления. В итоге мы получаем subscribe внутри subscribe и императивную лапшу.

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

Курс бесплатный. Делал для себя и студентов, но теперь делюсь со всеми.

Буду рад фидбеку и баг-репортам (проект активно допиливаю).

Ссылка на курс: https://rxjs-course-avy.web.app/