Forem: собачья будка

плавающее оглавление на solidjs

собачья будка — Fri, 24 Apr 2026 06:41:32 +0000

иногда плавающее оглавление кажется довольно простой штукой: берёшь заголовки, рисуешь список, добавляешь якоря — готово.

в этой статье — разбор table of contents, который я собрал на solidjs: от поиска заголовков до sticky/fixed поведения и адаптивного ui.

контекст

задача :

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

сбор заголовков из документа

вся система начинается с обхода dom и поиска заголовков внутри контейнера статьи.

const updateHeadings = () => {
  const parent = document.querySelector(props.parentSelector)

  if (!parent) return

  const nodes = Array.from(
    parent.querySelectorAll<HTMLElement>('h1, h2, h3, h4')
  )

  setHeadings(nodes)
  setAreHeadingsLoaded(true)
}

по сути это “снимок структуры документа”.

debounce пересборки оглавления

чтобы не пересобирать список слишком часто:

const debouncedUpdateHeadings = debounce(500, updateHeadings)

это особенно важно, если контент может динамически изменяться.

определение активного заголовка

самая “живая” часть компонента — отслеживание скролла.

const isInViewport = (el: HTMLElement) => {
  const rect = el.getBoundingClientRect()

  return rect.top <= DEFAULT_HEADER_OFFSET + 24
}

и дальше поиск активного элемента:

const updateActiveHeader = throttle(50, () => {
  const index = headings().findIndex((h) => isInViewport(h))

  setActiveHeaderIndex(index)
})

переход к заголовку

при клике происходит ручной scroll с компенсацией fixed header’а:

const scrollToHeader = (element: HTMLElement) => {
  const top =
    element.getBoundingClientRect().top -
    document.body.getBoundingClientRect().top -
    DEFAULT_HEADER_OFFSET

  window.scrollTo({
    top,
    behavior: 'smooth'
  })
}

состояние компонента

оглавление держит сразу несколько слоёв состояния:

const [headings, setHeadings] = createSignal<HTMLElement[]>([])
const [activeHeaderIndex, setActiveHeaderIndex] = createSignal(-1)
const [isVisible, setIsVisible] = createSignal(true)
const [areHeadingsLoaded, setAreHeadingsLoaded] = createSignal(false)
const [isDocumentReady, setIsDocumentReady] = createSignal(false)

подписка на скролл

основная реактивность строится через window scroll:

onMount(() => {
  setIsDocumentReady(true)

  debouncedUpdateHeadings()

  window.addEventListener('scroll', updateActiveHeader)

  onCleanup(() => {
    window.removeEventListener('scroll', updateActiveHeader)
  })
})

реакция на изменение статьи

если меняется тело статьи — пересобираем структуру:

createEffect(
  on(
    () => props.body,
    () => {
      if (isDocumentReady()) {
        debouncedUpdateHeadings()
      }
    }
  )
)

рендер списка

основной ui — это список кнопок, привязанных к заголовкам.

<ul class={styles.TableOfContentsHeadingsList}>
  <For each={headings()}>
    {(h, index) => (
      <li>
        <button
          class={clsx(styles.TableOfContentsHeadingsItem, {
            [styles.TableOfContentsHeadingsItemH3]: h.nodeName === 'H3',
            [styles.TableOfContentsHeadingsItemH4]: h.nodeName === 'H4',
            [styles.active]: index() === activeHeaderIndex()
          })}
          innerHTML={h.textContent || ''}
          onClick={(e) => {
            e.preventDefault()
            scrollToHeader(h)
          }}
        />
      </li>
    )}
  </For>
</ul>

визуальная иерархия заголовков

уровни заголовков просто сдвигаются визуально:

.TableOfContentsHeadingsItemH3 {
  padding-left: 8px;
}

.TableOfContentsHeadingsItemH4 {
  padding-left: 16px;
}

активный пункт

подсветка текущего раздела минимальная, но важная:

.TableOfContentsHeadingsItem.active {
  font-weight: 700 !important;
}

sticky поведение на десктопе

на больших экранах оглавление становится sticky-блоком:

.TableOfContentsContainer {
  @include media-breakpoint-up(xl) {
    position: sticky;
    top: 100px;
    height: calc(100vh - 120px);
    flex-direction: column;
  }
}

mobile режим (fixed bottom panel)

на мобильных это уже не sidebar, а выезжающая панель:

.TableOfContentsFixedWrapper {
  @include media-breakpoint-down(xl) {
    position: fixed;
    bottom: 0;
    left: 0;
    width: 100%;
    max-height: 50vh;
    background: #000;
    color: #fff;
  }
}

toggle видимости

оглавление можно скрывать и показывать:

const toggleIsVisible = () => {
  setIsVisible((v) => !v)
}

итог

в итоге это не просто оглавление.

это:

парсинг DOM структуры статьи
debounce пересборки контента
scroll tracking с throttle
вычисление активного раздела
sticky + fixed адаптивный layout
UI, который живёт вместе со скроллом

и самое интересное — такие компоненты всегда выглядят простыми в начале, но постепенно превращаются в полноценный слой навигации поверх документа, который “понимает” структуру текста и помогает по нему двигаться.

source code

image cropper на solidjs

собачья будка — Fri, 24 Apr 2026 06:28:49 +0000

иногда кажется, что кроп изображения — это просто ui-компонент: выделил область, обрезал, сохранил.

но когда ты начинаешь делать это руками через canvas, drag’n’drop и пересчёт координат с учётом scale — внезапно получается маленький графический редактор.

в этой статье — разбор image cropper, который я собрал на solidjs: от canvas-рендера до экспорта файла.

контекст

задача была простой на словах:

загрузить изображение
дать пользователю выбрать область
добавить зум
сохранить результат как файл

но почти сразу стало понятно, что это не dom-задача, а работа с пикселями.

сам компонент

это основной компонент кроппера. он держит всё состояние внутри: canvas, drag, scale, загрузку и экспорт.

import { UploadFile } from '@solid-primitives/upload'
import { clsx } from 'clsx'
import { createSignal, onCleanup, onMount, Show } from 'solid-js'
import { useLocalize } from '~/context/localize'
import { Button } from '../Button'

import styles from './ImageCropper.module.scss'

interface CropperProps {
  uploadFile: UploadFile
  onSave: (arg0: any) => void
  onDecline?: () => void
}

export const ImageCropper = (props: CropperProps) => {
  let canvasRef: HTMLCanvasElement | undefined
  let imageRef: HTMLImageElement | undefined
  let containerRef: HTMLDivElement | undefined

  const { t } = useLocalize()

  const [isLoading, setIsLoading] = createSignal(false)
  const [cropData, setCropData] = createSignal({
    x: 0,
    y: 0,
    width: 200,
    height: 200
  })

  const [isDragging, setIsDragging] = createSignal(false)
  const [dragStart, setDragStart] = createSignal({ x: 0, y: 0 })
  const [imageLoaded, setImageLoaded] = createSignal(false)
  const [scale, setScale] = createSignal(1)

  // логика ниже
}

стили: это уже не просто ui

.cropperContainer {
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 1rem;
  padding: 1rem;
  background: var(--black-50);
  border-radius: var(--comment-radius-md);
}

идея простая:

центрированная рабочая зона
ощущение инструмента, а не формы
минимум отвлекающего ui

canvas как рабочая поверхность

.cropperCanvas {
  display: flex;
  justify-content: center;
  align-items: center;
  background: var(--background-color);
  border-radius: var(--border-radius);
  padding: 10px;
  box-shadow: 0 2px 8px var(--shadow-color-medium);
}

canvas визуально отделён — как холст в редакторе.

grab vs dragging

.cropperCanvas canvas {
  cursor: grab;
}

.cropperCanvas canvas.dragging {
  cursor: grabbing;
}

zoom контролы

.zoomControl {
  background-color: rgba(0, 0, 0, 0.5);
  border-radius: 50%;
  width: 30px;
  height: 30px;
  font-size: 24px;
  display: flex;
  align-items: center;
  justify-content: center;
  color: #fff;
  cursor: pointer;
}

адаптивность

@media (max-width: 768px) {
  .cropperContainer {
    padding: 0.5rem;
  }

  .cropperCanvas canvas {
    max-width: calc(100vw - 2rem);
    max-height: 300px;
  }
}

как работает рендер

const drawImage = () => {
  const ctx = canvasRef.getContext('2d')
  if (!ctx || !imageRef) return

  const img = imageRef
  const currentScale = scale()

  ctx.clearRect(0, 0, canvas.width, canvas.height)

  const displayWidth = img.naturalWidth * currentScale
  const displayHeight = img.naturalHeight * currentScale

  const offsetX = (canvas.width - displayWidth) / 2
  const offsetY = (canvas.height - displayHeight) / 2

  ctx.drawImage(img, offsetX, offsetY, displayWidth, displayHeight)

  ctx.fillStyle = 'rgba(0, 0, 0, 0.5)'
  ctx.fillRect(0, 0, canvas.width, canvas.height)

  const crop = cropData()
  ctx.clearRect(crop.x, crop.y, crop.width, crop.height)

  ctx.strokeStyle = '#fff'
  ctx.strokeRect(crop.x, crop.y, crop.width, crop.height)
}

drag логика

const handleMouseDown = (e: MouseEvent) => {
  const rect = canvasRef?.getBoundingClientRect()
  if (!rect) return

  const x = e.clientX - rect.left
  const y = e.clientY - rect.top

  const crop = cropData()

  if (
    x >= crop.x &&
    x <= crop.x + crop.width &&
    y >= crop.y &&
    y <= crop.y + crop.height
  ) {
    setIsDragging(true)
    setDragStart({ x: x - crop.x, y: y - crop.y })
  }
}

перемещение области

const handleMouseMove = (e: MouseEvent) => {
  if (!isDragging() || !canvasRef) return

  const rect = canvasRef.getBoundingClientRect()
  const x = e.clientX - rect.left
  const y = e.clientY - rect.top

  const drag = dragStart()

  const newX = Math.max(0, Math.min(canvasRef.width - cropData().width, x - drag.x))
  const newY = Math.max(0, Math.min(canvasRef.height - cropData().height, y - drag.y))

  setCropData({ ...cropData(), x: newX, y: newY })
  drawImage()
}

экспорт кропа

const cropImage = () => {
  const crop = cropData()
  const currentScale = scale()

  const img = imageRef

  const displayWidth = img.naturalWidth * currentScale
  const displayHeight = img.naturalHeight * currentScale

  const offsetX = (canvas.width - displayWidth) / 2
  const offsetY = (canvas.height - displayHeight) / 2

  const sourceX = (crop.x - offsetX) / currentScale
  const sourceY = (crop.y - offsetY) / currentScale
  const sourceWidth = crop.width / currentScale
  const sourceHeight = crop.height / currentScale

  const cropCanvas = document.createElement('canvas')
  cropCanvas.width = 300
  cropCanvas.height = 300

  const ctx = cropCanvas.getContext('2d')

  ctx.drawImage(
    img,
    sourceX,
    sourceY,
    sourceWidth,
    sourceHeight,
    0,
    0,
    300,
    300
  )

  return cropCanvas
}

сохранение файла

const handleSave = () => {
  const croppedCanvas = cropImage()

  croppedCanvas.toBlob(blob => {
    const file = new File([blob], `cropped-${props.uploadFile.name}`, {
      type: 'image/png'
    })

    props.onSave(file)
  }, 'image/png')
}

итог

в итоге это не просто кроппер.

это:

canvas-рендеринг
ручная система координат
drag & zoom
экспорт в файл

и самое интересное — чем дальше ты заходишь, тем меньше это похоже на ui-компонент и тем больше на мини-редактор изображений внутри браузера.

source code

кастомный аудиоплеер на solidjs вокруг нативного audio api

собачья будка — Fri, 24 Apr 2026 06:00:40 +0000

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

данные и состояние

на вход приходит массив медиа (media), который я сначала нормализую:

добавляю id
добавляю флаги isCurrent и isPlaying

const prepareMedia = (media) =>
  media.map((item, index) => ({
    ...item,
    id: index,
    isCurrent: false,
    isPlaying: false
  }))

дальше всё состояние плеера живёт в этом массиве tracks.

текущий трек определяется через isCurrent. если его нет — автоматически выбирается первый.

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

переключение треков и play/pause

при клике на трек или кнопку play я полностью пересобираю массив:

setTracks(
  tracks().map((track) => ({
    ...track,
    isCurrent: track.id === m.id,
    isPlaying: track.id === m.id ? !track.isPlaying : false
  }))
)

только один трек может быть текущим
только один может играть

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

при переключении next/prev:

считается индекс текущего трека
выбирается следующий или предыдущий (с зацикливанием)

синхронизация с `<audio>`

есть отдельный audioRef, который реально воспроизводит звук.

через createEffect я слежу за текущим треком:

if (audioRef.src !== getCurrentTrack().url) {
  audioRef.src = getCurrentTrack().url
  audioRef.load()
}

если трек поменялся — обновляется src.

воспроизведение

при play:

если контекст звука “спит” — резюмлю его
вызываю audioRef.play() или pause()

if (getCurrentTrack().isPlaying) {
  await audioRef.play()
} else {
  audioRef.pause()
}

прогресс и время

прогресс обновляется вручную:

progressFilledRef.style.width = `${(audioRef.currentTime / duration) * 100 || 0}%`

беру currentTime из <audio>
делю на duration
пишу в width

прогресс обновляется напрямую через style — это проще, чем городить отдельную реактивную прослойку.

время форматируется через Date:

new Date(point * 1000).toISOString().slice(14, -5)

перемотка (scrub)

при клике по прогресс-бару:

audioRef.currentTime = (event.offsetX / progressRef.offsetWidth) * duration

при зажатой кнопке мыши — обновляется на mousemove.

используется offsetX, что не всегда идеально, но для этого кейса оказалось достаточно.

обработка событий audio

onTimeUpdate → обновляю прогресс и текущее время
onLoadedMetadata → получаю длительность
onEnded → сбрасываю прогресс и время

громкость через web audio api

я не использовал просто audio.volume, а сделал через AudioContext:

const track = audioContext().createMediaElementSource(audioRef)
track.connect(gainNode()).connect(audioContext().destination)

и дальше:

gainNode.gain.value = Number(volumeRef.value)

громкость управляется через input[type=range].

громкость сделал через web audio api — немного оверкилл, но зато полный контроль.

с range-инпутом пришлось немного повозиться из-за разных браузеров.

header (контролы)

в PlayerHeader:

play / pause
next / prev
кнопка громкости

громкость открывается как popover:

const [isVolumeBarOpened, setIsVolumeBarOpened] = createSignal(false)

и закрывается через кастомный хук useOutsideClickHandler.

плейлист

в PlayerPlaylist:

список треков (<For each={tracks}>)
кнопка play у каждого трека
отображение текущего состояния (play/pause иконка)

getCurrentTrack().id === m.id && getCurrentTrack().isPlaying

список не просто отображает данные — он тоже участвует в управлении плеером.

шаринг

у каждого трека есть кнопка шаринга:

<SharePopup
  title={m.title}
  description={getDescription(body)}
  imageUrl={m.pic}
  shareUrl={...}
/>

используется заголовок трека
описание берётся из текста статьи
ссылка формируется от articleSlug

стили

в css:

flex layout для header и контролов
адаптив через breakpoint
кастомный progress bar (через border и ::after)
кастомный range input для громкости (webkit / moz / ms)

прогресс-бар и ползунок громкости полностью переопределены, дефолтные стили не используются.

в итоге это не отдельный плеер, а часть страницы — с текстом, шарингом и списком треков, которые живут вместе.

source code

как сконвертировать пачку изображений в webp

собачья будка — Wed, 30 Mar 2022 07:14:26 +0000

для этого понадобится либа cwebp, которая принимает на вход степень сжатия (1..100), имя входного и выходного файлов, и простой баш цикл.
соберем все картинки в одну директорию и перейдем в нее, после чего опишем скрипт:

for file in *
do
cwebp -q 100 "$file" -o "${file%.png}.webp"
done

как наложить блюр в фигме

собачья будка — Wed, 30 Mar 2022 07:12:41 +0000

для формы блюра используем любую фигуру (R):

и выделим необходимое для замутнения место:

изменим цвет заливки на белый с полупрозрачностью в 1%:

и добавим эффект background blur:

клик на иконку позволяет настраивать степень блюра. well done!

генерируем xlsx из rss фида

собачья будка — Sun, 27 Mar 2022 06:22:06 +0000

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

сперва набросаем пачку зависимостей:

yarn add rss-parser
yarn add --dev exceljs moment posthtml progress request request-promise yargs

за дело! импортирую переменные и определяю парсер:

const ExcelJS = require('exceljs')
const Parser = require('rss-parser')
const posthtml = require('posthtml')
const rp = require('request-promise')
const moment = require('moment')
const ProgressBar = require('progress')
const yargs = require("yargs")

const parser = new Parser()

описываю обязательные и не очень аргументы, определяю входную функцию и на ходу рассказываю о прогрессе в терминал:

const options = yargs
    .usage(`Usage: -f <rss uri>`)
    .option('f', {
        alias: 'feed',
        describe: 'RSS feed uri',
        type: 'string',
        demandOption: true
    })
    .option('a', {
        alias: 'amount',
        describe: 'Needed RSS feed posts amount',
        type: 'string'
    })
    .option('n', {
        alias: 'outputFileName',
        describe: 'XLS output file name',
        type: 'string'
    })
    .option('o', {
        alias: 'cellOptions',
        describe: 'Sheet cell additional options',
        type: 'array'
    })
    .argv

process.stdout.write(`great options, bruh, let's start already!\n`)

entry(options.feed, options.amount, options.outputFileName, options.cellOptions)

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

let entry = async (rssFeed, amount = 5, outputFileName = 'result', cellOptions = []) => {
    process.stdout.write(`parsing your rss feed...\n`)
    let feed = await parser.parseURL(rssFeed)

    process.stdout.write(`creating excel workbook...\n`)
    const workbook = new ExcelJS.Workbook()
    const worksheet = workbook.addWorksheet(outputFileName)
    worksheet.columns = [{
            header: 'text',
            key: 'col_text'
        },
        {
            header: 'url',
            key: 'col_url'
        },
        {
            header: 'images',
            key: 'col_images'
        },
        {
            header: 'time',
            key: 'col_time'
        }
    ]
}

приступаю к генерации новых строк и добавляю тикающий прогресс бар:

process.stdout.write(`generating posts from rss feed...\n`)
let generatedRows = await generatePostsMetaFromFeed(feed, amount)
let generatedRowsBar = new ProgressBar('[:bar] :current/:total table rows generated\n', {
    incomplete: ' ',
    complete: '#',
    total: generatedRows.length
})

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

let convertFeedToPosts = feed => [...feed.items.map(item => item.link)] // для пагинации по страницам фида понадобятся линки

let generatePostsMetaFromFeed = async (feed, amount) => {
    let res = []

    let posts = []
    let feedLink = feed.link

    if (amount > 10) {
        process.stdout.write(`wow, so much posts? taking care of it...\n`)
        let pages = Math.round(amount / 10) // пагинация для доступа к последующим страницам фида
        let pagesLoadingBar = new ProgressBar('[:bar] :current/:total processed\n', {
            incomplete: ' ',
            complete: '#',
            total: pages
        })

        posts.push(...convertFeedToPosts(feed))

        process.stdout.write(`loading needed pages...\n`)
        for (let i = 2; i <= pages; i++) {
            await rp(encodeURI(`${feedLink}?feed=rss&paged=${i}`))
                .then(async rssPage => {
                    let parsedRSSFeed = await parser.parseString(rssPage)
                    let isLastPage = i === pages

                    if (isLastPage) {
                        let modItems = parsedRSSFeed.items.filter((_, index) => index < amount % 10)

                        posts.push(...convertFeedToPosts({
                            items: modItems
                        }))
                    } else {
                        posts.push(...convertFeedToPosts(parsedRSSFeed))
                    }

                    pagesLoadingBar.tick()
                })
                .catch(err => {
                    console.error('huh, rss pagination failed', err.code)
                })
        }
    } else {
        process.stdout.write(`not a lot of posts, gonna be quick!\n`)
        posts.push(...convertFeedToPosts({
            items: feed.items.slice(0, amount)
        }))
    }

    process.stdout.write(`time to generate some text for our table!\n`)
    let postsHandlingBar = new ProgressBar('[:bar] :current/:total posts handled\n', {
        incomplete: ' ',
        complete: '#',
        total: posts.length
    })

    for (let i = 0; i < posts.length; i++) {
        let postLink = posts[i]
        let title, description, image

        await rp(postLink)
            .then(html => {
                process.stdout.write(`wuush, working on it...\n`)
                posthtml().use(tree => { // парсим дерево и только нужные таблице значения нод
                    tree.match({
                        tag: 'title'
                    }, node => {
                        title = node.content[0]
                    })
                    tree.match({
                        attrs: {
                            name: 'description'
                        },
                        tag: 'meta'
                    }, node => {
                        description = node.attrs.content
                    })
                    tree.match({
                        attrs: {
                            property: 'og:image'
                        },
                        tag: 'meta'
                    }, node => {
                        image = node.attrs.content
                    })
                }).process(html)

                postsHandlingBar.tick()
            })
            .catch(err => {
                console.error('huh, post parsing failed', err)
            })

        res.push({
            title,
            description,
            image,
            link: postLink
        })
    }

    return res
}

строки сгенерированы, пора вернуться во входную entry функцию и прикрутить их к инстансу worksheet, используя метод addRow:

process.stdout.write(`making some rows for your sheet...\n`)
for (let i = 0; i < generatedRows.length; i++) {
    let {
        title,
        description,
        image,
        link
    } = generatedRows[i]
    let columnText = `${title}\n\n${description}\n\n${link}`

    if (cellOptions.length) {
        cellOptions.forEach(cOption => {
            if (cOption === 'noImage') {
                image = ''
            }
            if (cOption === 'noOGCard') {
                link = ''
            }
        })
    }

    worksheet.addRow({
        col_text: columnText,
        col_url: link,
        col_images: image,
        col_time: moment().add(i, 'days').format('DD/MM/YYYY hh:mm').toString()
    })

    generatedRowsBar.tick()
}

lift off! теперь можно отдавать таблицу:

process.stdout.write(`creating your ${outputFileName} file...\n`)
await workbook.xlsx.writeFile(`${outputFileName}.xlsx`)
    .then(() => {
        process.stdout.write(`${outputFileName} created allright!\n`)
    })
    .catch((err) => {
        process.stdout.write('huh, creating error: ', err)
    })

process.stdout.write(`all done, love!\n`)

таблица в кармане, profit!

исходный код: https://github.com/arkatriymfalnaya/xlsx-from-rss-generator

очередной слайдер, которого никто не просил

собачья будка — Sat, 26 Mar 2022 06:17:52 +0000

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

собираем проект, пара библиотек нам пригодится:

npm init
yarn add path express pug path
yarn add --dev nodemon

сразу добавим dev скрипт в package.json, который будет стучаться к нашему сервер-скрипту:

"scripts": {
    "dev": "nodemon src/server.js"
}

создадим папку src и файл server.js, в котором опишем наш сервер и движок для pug шаблонов:

const express = require('express')
const path = require('path')
const fs = require('fs')

const app = express()
const port = '8000'

app.listen(port, () => {
    console.log(`Listening on http://localhost:${port}`)
})

app.set('views', path.join(__dirname, 'views'))
app.set('view engine', 'pug')
app.use(express.static(path.join(__dirname, 'public')))

app.get('/', (_, res) => {
    try {
        let paths = fs.readdirSync(path.join(__dirname + '/public/images/')) // там будут храниться наши картинки для слайд-шоу
        let combinedPaths = paths.map(p => `images/${p}`)

        res.render('index', {
            imagesPaths: combinedPaths
        })
    } catch (err) {
        throw err
    }
})

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

doctype html
html(lang='en')
  head
    meta(charset='utf-8')
    link(rel='stylesheet' href='styles/index.css')
    meta(name='viewport', content='width=device-width, initial-scale=1, shrink-to-fit=no')
  body
    main.wrapper
        section.slider
            each src in imagesPaths
                article.slider__item.slider__item--appear.slide
                    figure
                        img(src=src alt='pic')
            section.slider__controls
                button
                button
    script(type='module' src='scripts/index.js')

переходим к самому вкусному - к интерактивности, которую возьмет на себя скрипт scripts/index.js. сперва обезопасим себя и дождемся загрузки DOM дерева:

document.addEventListener('DOMContentLoaded', () => {
  …
}, false)

вытащим из дерева нужные ноды, объявим переменные для интервала и учёта текущего индекса слайда:

const slidesList = document.querySelectorAll('.slider__item')
const controlsList = document.querySelector('.slider__controls').children
const leftControl = controlsList[0]
const rightControl = controlsList[1] // больше двух детей не предполагается

let interval = null
let currentIndex = 1

в конце скрипта инициализируем события и рендеринг самого слайдера:

document.addEventListener('keydown', e => {
    if (e.key === 'ArrowLeft') moveSlider('left') // переключение левой стрелкой
    if (e.key === 'ArrowRight') moveSlider('right') // переключение правой стрелкой
    if (e.key === ' ' && e.target.nodeName !== 'BUTTON') {
        if (interval) {
            stopSliding() // остановка на текущем слайде по нажатию на пробел
        } else {
            proceedSliding() // продолжение слайд-шоу, если была остановка
        }
    }
})
leftControl.addEventListener('click', () => moveSlider('left'), false)
rightControl.addEventListener('click', () => moveSlider('right'), false)

initSlider(slidesList)

столько функций еще не написано! надо исправлять:

const initSlider = slides => {
    if (currentIndex > slides.length) currentIndex = 1
    if (currentIndex < 1) currentIndex = slides.length

    updateSlider(slidesList)
}

const moveSlider = to => {
    if (to === 'right') updateCurrentIndex('right')
    else updateCurrentIndex('left')

    initSlider(slidesList)
}

…

const stopSliding = () => {
    clearInterval(interval)
    interval = null // очищаем интервал, чтобы остановить слайд-шоу

    slidesList[currentIndex - 1].classList.add('slide--stopped')
}

const proceedSliding = () => {
    interval = setInterval(() => {
        updateCurrentIndex('right')
        initSlider(slidesList)
    }, 3000)
    slidesList[currentIndex - 1].classList.remove('slide--stopped')
}

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

const updateSlider = slides => {
    clearInterval(interval)

    for (let i = 0; i < slides.length; i++) {
        slides[i].classList.add('slider__item--inactive') // стили класса будут удалять слайд из разметки
        slides[i].classList.remove('slide--stopped')
    }

    slides[currentIndex - 1].classList.remove('slider__item--inactive')

    interval = setInterval(() => { // переопределяем интервал, ведь слайд-шоу не просто так шоу
        updateCurrentIndex('right')
        initSlider(slidesList)
    }, 3000)
}

…

const updateCurrentIndex = to => {
    if (to === 'right') currentIndex++
    else currentIndex--
}

ой, почти все! добавим стили и анимации для появления слайдов:

* {
    box-sizing: border-box;
}

body, section, figure, button {
    padding: 0;
    margin: 0;
}

.wrapper {
    width: 100vw;
    height: 100vh;
    display: flex;
    align-items: center;
    justify-content: center;
    background-color: rgba(0, 0, 0, 1);
}

.slider {
    position: relative;
    width: 100%;
    height: 540px;
}

.slider__views-counter {
    position: absolute;
    top: -28px;
    left: 0;
    margin: 0;
    margin-left: 14px;
    font-family: 'Helvetica';
    font-size: 20px;
    line-height: 24px;
    color: white;
}

.slider__item {
    display: flex;
    height: 100%;
}

.slider__item--inactive {
    display: none;
}

.slider__item--appear {
    animation-name: slide-appearing;
    animation-duration: 1.5s;
}

.slide {
    align-items: center;
}

.slide--stopped {
    outline: 5px auto Highlight;
}

.slide figure {
    width: 100%;
    height: 100%;
    display: flex;
    justify-content: center;
    align-items: center;
}

.slide figure img {
    max-width: 100%;
    width: auto;
    max-height: 100%;
    height: auto;
}

.slider__controls {
    position: absolute;
    z-index: 2;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    margin: auto;
    display: flex;
    align-items: center;
    justify-content: space-between;
    width: 100%;
}

.slider__controls button {
    position: relative;
    width: 14%;
    max-width: 80px;
    height: 40%;
    border: none;
    background: transparent;
    cursor: pointer;
    border-radius: 8px;
    background-color: rgba(255, 255, 255, .14);
}

.slider__controls button:hover {
    background-color: rgba(255, 255, 255, .18);
}

.slider__controls button:active {
    box-shadow: 0px 0px 22px rgba(0, 0, 0, 0.2);
}

.slider__controls button::after {
    content: '';
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    margin: auto;
    width: 60%;
    height: 60%;
    background-image: url(/icons/arrow.svg);
    background-size: 100% 100%;
    background-repeat: no-repeat;
    filter: invert();
}

.slider__controls button:nth-child(2)::after {
    transform: rotate(180deg);
}

@keyframes slide-appearing {
    from {
        opacity: .2;
    }
    to {
        opacity: 1;
    }
}

@media screen and (min-width: 1020px) {
    .slider {
      width: 80%;
      max-width: 1020px;
    }

    .slider__views-counter {
        margin-left: 0;
    }

    .slider__controls button {
        max-width: 40px;
    }
  }

пора бы глянуть, чего уже там нарисовалось то. запустим yarn dev и перейдем по http://localhost:8000:

а что, дизайн вышел покурить? ну и пусть, ведь важнее, что внутри.

как я избавлялся от экстремизма в блоге

собачья будка — Thu, 24 Mar 2022 13:28:44 +0000

по мотивам недавних судебных решений блог моей компании о соцсетях и вокруг попадал под длящееся правонарушение. неопределенность по поводу нужных действий от других компаний и отсутствие решения суда сбивало с толку, потому, прежде чем скрывать все статьи с упоминаниями продуктов компании M**a, было решено подстраховаться иноагентскими методами.

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

wordpress хранит статьи в базе, доступ из админки по вкладке записи. встроенные инструменты позволяют экспортировать и импортировать контент из базы в удобном xml формате, осталось разобраться со структурой. для парсинга разогнал библиотеку fast-xml-parser:

const data = fs.readFileSync(path.join(__dirname, fileName), 'utf8')
const parser = new XMLParser()

let jObj = parser.parse(data)

рассмотрев дерево, выделил нужные мне ветки: wp:postmeta и content:encoded, дело за малым. пишем простую регулярку, выискивающую подстроку, которая не начинается с символа [ (используется для markdown тегов), имеет одно вхождение из набора названий запрещенных продуктов (название1|название2|название3) и любое окончание для русской вариации [а-яА-Я]*. для туллтипов использовался wordpress плагин Shortcodes Ultimate. поскольку реплейсить придется для нескольких веток, выносим эту исторую в отдельную функцию и обрабатываем корнер кейсы:

let replaceWithToolbar = str => str.replace(/[^\[|\/](meta|instagram|facebook|инстаграм|мета|фейсбук)[а-яА-Я]*/gi, (subStr, _, subStrIndex) => {
  let nextSymbol = str[subStrIndex + subStr.length]

  if(str[subStrIndex - 3] + str[subStrIndex - 2] + str[subStrIndex - 1] + str[subStrIndex] === 'www.') return subStr

  let space = '<code style="letter-spacing: -7px;"> </code>'

  let start = subStr[0]
  let end = nextSymbol === ' ' ? space : ''
  let updatedStr = subStr.substring(1)

  let tooltipText =
    subStr.includes('нстагра') || subStr.includes('ейсб') || subStr.includes('nstagr') || subStr.includes('aceboo')
      ? 'Продукт принадлежит организации, признанной экстремистской на территории Российской Федерации.'
      : 'Организация признана экстремистской на территории Российской Федерации.'

  return `${start}${space}[su_tooltip text="${tooltipText}" text_align="center"]${updatedStr}[/su_tooltip]${end}`
})

остается только грязно обновить исходные ветки на получившиеся:

let metasArray = jObj.rss.channel.item['wp:postmeta']
let newMetasArray = metasArray.map(m => {
  if(m['wp:meta_key'] === '_crb_description' || m['wp:meta_key'] === '_crb_short_description') {
    let newMeta = replaceWithToolbar(m['wp:meta_value'])
    m['wp:meta_value'] = newMeta
  }

  return m
})
jObj.rss.channel.item['wp:postmeta'] = newMetasArray

let content = jObj.rss.channel.item['content:encoded']
let newContent = replaceWithToolbar(content)
jObj.rss.channel.item['content:encoded'] = newContent

после чего билдим дерево в новый xml и пишем в файл:

const builder = new XMLBuilder({ processEntities:false })
const xmlContent = builder.build(jObj)
fs.writeFileSync(path.join(__dirname, `output_${fileName}`), xmlContent)

ну, вроде подстраховались!

исходный код: https://github.com/arkatriymfalnaya/avoid-extremism

architectural styles and the design of network-based software architectures. representational state transfer [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:43 +0000

Вольный перевод главы диссертации Roy Thomas Fielding "Representational State Transfer (REST)"

Representational State Transfer (REST)

Эта глава представляет и конкретизирует Representational State Transfer (REST) - архитектурный стиль для распределенных гипермедийных систем, описывает принципы разработки программного обеспечения, следуя REST, а также описывает ограничения взаимодействия для сохранения этих принципов, в то же время сопоставляя их с ограничениями других архитектурных стилей. REST - это гибридный стиль, полученный из описанных в третьей лаве архитектурных стилей и определяющий единый интерфейс соединителя коннектора в сочетании с дополнительными ограниченияеми. Структура архитектуры ПО из первой главы используется для определения архитектурных элементов REST изучения примеров просессов, коннекторов и представлений данных прототипных архитектур.

5.1 Процесс выведения REST

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

5.1.1 Начиная с Нулевого Стиля

Как для построек, так и для программного обеспечения существует два общих взгляда на процесс архитектурного проектирования. Первый: проектировщик начинает с пустого состояния, рисовальной или чертежной доски и, пока потребности предполагаемой системы не будут удовлетворены, выстраивает архитектуру из уже знакомых компонентов. Второй: проектировщик отталкивается от потребностей системы без ограничений, после чего постепенно определяет и применяет ограничения к её элементам, чтобы разграничить область проектирования и позволить силам, влияющим на поведение системы, течь естественным образом, в гармонии с системой. Первый взгляд подразумевает креативное и неограниченное видение, второй - сдержанность и понимание контекста нужной системы. REST был разработан с помощью последнего. Фигуры с 5-1 по 5-8 графически описывают, как примененные ограничения разграничивают процесс представления архитектуры в качестве инкрементального набора ограничений.

Нулевой стиль (Изображение 5-1) - это просто пустой набор ограничений. С точки зрения архитектуры, нулевой стиль описывает систему, в которой четкая граница между компонентами не установлена. Это начальная точка для нашего описания REST.

5.1.2 Клиент-сервер

Первыми добавленными к нашему гибридному стилю ограничениями будут ограничения клиент-серверного архитектурного стиля (Изображение 5-2), описанные в Секции 3.4.1. Принцип, лежащий в основе клиент-серверных ограничений, заключается в разделении интересов. Разделением интересов пользовательского интерфейса от интересов хранилища данных, мы улучшаем портативность пользовательского интерфейса на несколько платформ и улучшаем масшабируемость, упрощая серверные компоненты. Для веба наиболее важным, пожалуй, является то, что разделение позволяет компонентам развиваться независимо, тем самым поддерживая требования расширяемости интернета для нескольких организационных доменов.

5.1.3 Отсутствие состояния (Stateless)

Следующее ограничение клиент-серверного взаимодействия: коммуникация должна не иметь состояния по своей природе, следуя стилю client-stateless-server (CSS) из Секции 3.4.3 (Изображение 5-3), что подразумевает, что каждый запрос от клиента к серверу должен содержать всю необходимую для его понимания информацию и не может использовать хранящийся на сервере контекст. Потому состояние сессии полностью хранится на клиенте.

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

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

5.1.4 Кэш

Для того, чтобы улучшить эффективность сети, мы добавляем ограничения кэша для формирования стиля client-cache-stateless-server из секции 3.4.4 (Изображение 5-4). Ограничения кэша требуют, чтобы данные внутри ответа на запрос были явно или неявно отмечены, как кэшируемые или некэшируемые. Если ответ кэшируемый - клиентскому кэшу дается право переиспользовать данные ответа для последующих эквивалентных запросов.

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

Ранняя веб архитектура, как показано на изображении 5-5, определялась client-cache-stateless-server набором ограничений. Таким образом, для обмена статическими документами через интернет представленное для веб архитектуры до 1994 обоснование проектирования было сфокусировано на клиент-серверном взаимодействии без состояния. Протоколы для взаимного взаимодействия имели рудиментарную поддержку для кэшей без общего доступа, но не ограничивали интерфейс согласованным набором семантики для всех ресурсов. Вместо того, в вебе использовалась общая библиотека клиент-серверной реализации (CERN libwww) для обеспечения согласованности между веб приложениями.

Разработчики веб реализаций уже превзошли ранние методы проектирования. Кроме статических документов, запросы могли идентифицировать сервисы, которые динамически генерировали ответы, вроде image-maps [Кевин Хьюз] и server-side scripts [Роб МакКул]. Также была начата работа над промежуточными компонентами в виде прокси-серверов и общих кэшей, но для надежной связи те нуждались в расширених протоколов. Следующие разделы описывают ограничения, которые были добавлены к архитектурному стилю веба, для указания расширений, формирующих современную веб архитектуру.

5.1.5 Унифицированный интерфейс

Главной отличительной чертой REST стиля от остальных является, акцент на единый интерфейс между компонентами (Изображение 5-6). Применение такого принципа к интерфейсу компонент улучшает видимость взаимодействий и позволяет упростить архитектуру системы в целом. Реализации отделены от сервисов, которые они предоставляют, что способствует их независимому развитию. Компромисс в том, что унифицированный интерфейс снижает эффективность, поскольку информацию передается в стандартизированном виде, а не в виде, определенном под нужды приложения. Интерфейс REST был спроектирован для эффективной передачи крупного количества гипермедиа данных, частого случая в вебе, но не оптимален для других видов архитектурного взаимодействия.

Чтобы достчиь унифицированного интерфейса, на поведение компонентов должны быть наложены некоторые архитектурные ограничения. REST определяется четырьмя интерфейсными ограничениями: идентификация ресурсов; управление ресурсами через представления; самоописывающиеся сообщения; и гипермедиа, как двигатель состояния приложения. Эти ограничения будут обсуждены в секции 5.2.

5.1.6 Многоуровневая система

Для последующего улучшения поведения и требований расширяемости интернета, мы добавили ограчения уровневой системы (Изображение 5-7). Как описано в секции 3.4.2, уровневый системный стиль позволяет архитектуре состоять их иерархичных слоев путем особого поведения компонентов - каждый компонент не может "смотреть" за пределы уровня, с которым взаимодействует. Ограничивая знание о системе до одного уровня, мы обеспечиваем подложке незавимость и ограничиваем сложность системы в целом. Уровни могут быть использованы, чтобы оборачивать legacy сервисы и огорождать от них новые, упрощая компоненты за счет перемещения редкоиспользуемых функций в общий промежуточный уровень. Такие уровни также могут использоваться для улучшения расширяемости системы, обеспечивая балансировку нагрузки служб между несколькими сетями и процессорами.

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

Комбинация многоуровневой системы и ограничений унифицированного интерфейса приводит архитектурные свойства к виду pipe-and-filter (секция 3.2.2). Хотя REST взаимодействие является двусторонним, потоки данных большого размера гипермедиа взаимодействия могут обрабатываться как сеть потоков данных с фильтрующими компонентами, выборочно примеяемыми к потокам для преобразования их содержимого. Внутри REST промежуточные компоненты могут активно преобразовывать содержимое сообщений, потому что сообщения самоописывающиеся и их семантика видна на промежуточных уровнях.

5.1.7 Код по требованию

Последним дополнением к нашему набору ограничений будет стиль code-on-demand из секции 3.5.3 (Изображение 5-8). REST позволяет клиенту расширяться функциональности клиента и выполнять код в виде апплетов или скриптов. Это упрощает клиентов, уменьшая количество необходимых для предварительной реализации фич. Благодаря возможности загрузки фич после деплоя, улучшается расширяемость системы. Однако, видимость также уменьшается, потому это ограничение внутри REST является опциональным.

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

5.1.8 Summary

REST состоит из набора рахитектурных ограничений, выбранных из-за присущих им свойст. В то же время, каждое из этих ограничений можно рассматривать отдельно, а описание их с точки зрения происхождения из общих архитектурных стилей облегчает понимание обоснования их выбора. Изображение 5-9 отображает ответвления ограничений REST в терминах сетевых архитектурных стилей, описанных в главе 3.

5.2 Архитектурные элементы REST

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

5.2.1 Элементы данных

В отличие от распределенного объектного стиля, где все данные скрываются внутри компонентами обработки, природа и состояние архитектурных элементов данных - ключевой аспект REST. Обоснование такого проектирования можно увидеть в природе самих распределенных гипермедиа. Когда выбирается ссылка, информация должна переместиться из места хранения в место, где она будет использоваться пользователем. В отличие от многих других парадигм распределенной обработки, где возможно и обычно более эффективно перемещать сам «агент обработки» (например, мобильный код, хранимую процедуру, выражение поиска и т. д.) к данным, а не перемещать данные в процессор.

Распределенная гипермедийная архитектура имееть только три основных свойства: 1) отрисовка данных в месте их хранения и отправка получателю изображений фиксированного формата; 2) инкапсуляция данных с помощью рендер движка и отправка обоих получателю; 3) отправка raw данных получателю вместе с метаданными, описывающими тип данных, чтобы получатель мог выбрать свой собственный движок рендеринга.

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

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

Элементы данных REST обобщены в таблице 5-1.

Untitled

5.2.1.1 Ресурсы и идентификаторы ресурса

Ключевой асбтракцией информации в REST является ресурс. Любая информация, которая может быть названа, может являться ресурсом: документ или изображение, временный сервис (например, "погода в Лос Анджелес на сегодня"), коллекция других ресурсов, невиртуальный объект (например, человек) и так далее. Другими словами, любой концепция, которая может быть целью гипертекстовой ссылки автора, должна попадать под определение ресурса. Ресурс - это концептуальное отображение набора сущностей, а не сущности, которая соответствует сопоставлению в любой конкретный момент времени.

Точнее, ресурс R является изменяющейся функцией M*R(t), которая за время *t mapsотображает набор сущностей или значений, который эквивалентны. Значения в наборе могут быть представлениями ресурсов и/или идентификаторами ресурсов. Ресурс может отображаться на пустой набор, который позволяет создавать ссылки на концепцию перед любой реализацией этой концепции - понятие, которое было чуждо большинству гипертекстовых систем до появления веба. Некоторые ресурсы являются статическими в том смысле, что при рассмотрении в любое время после их создания они всегда соттветствуют одному и тому же набору значений. Другие имеют высокую степень расхождений в занчениях с тчечением времени. Единственное, что требуется для статинчости ресурса - семантика, поскольку именно она отличает один ресурс от другого.

Например, "предпочтительной версией авторов" академической статьи является отображение, значение которого меняется со временем, тогда как "статьи, опубликованные в материалах конференции X" статичны. Это два разных ресурса, даже если они оба отображают одно и то же значение в определенный момент времени. Различие необходимо для того, чтобы оба ресурса можно было идентифицировать и ссылаться независимо. Аналогичным примером из разработки будет являться раздельный идентификатор файла исходного кода с управлением версиями при образении к "последней версии", "версии 1.2.7" или "версии, включенной в релиз Orange".

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

REST использует идентификатор ерсурса для идентификации конкретного ресурса, участвующего во взаимодействии между компонентами. REST коннекторы предоставляют общий интерфейс для доступа к набору значений ресурса и манипулирования им независимо от того, как определена функция членства или от типа программного обеспечения, которое обрабатывает запрос. Инструмент, который назначил идентификатор ресурса, позволяющий ссылаться на ресурс, отвечает за поддержание семантической достоверности отображения с течением времени (т.е. гарантирует, что функция членства не изменяется).
Традиционные гипертекстовые системы, которые обычно действуют в закрытых или локальных окружениях, используеют уникальные идентификаторы узов или документов, которые изменяются сразу после изменения информации, полагаясь на серверы ссылок, чтобы поддреживать отдельно ссылки от контента. Поскольку централизованные серверы ссылок - это анафема для огромного масштаба и многопрофильных сетевых требований, вместо этого REST полагается на то, что автор выбирает идентификатор ресурса, который наилучшим образом соответствует природе идентифицируемой концепции. Естественно, качество идентификатора часто пропорционально сумме денег, потраченной на сохранение его валидности, что приводит к разрыву ссылок, когда эфемерная (или плохо поддерживаемая) информация перемещается или исчезает со временем.

5.2.1.2 Представления

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

Представление состоит из данных, метаданных, описывающих данные, и, иногда, метаданных для описания метаданных (обычно для проверки целостности сообщения). Метаданные представлены в форме пар имя-значение, где имя соответствует стандарту, который определяет структуру и семантику значения. Сообщения ответов могут включать как метаданные представления, так и метаданные ресурса: информацию о ресурсе, которая не является специфичной для поставляемого представления.

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

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

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

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

Например, веб-браузер, который может постепенно визуализировать большой HTML-документ во время его получения, обеспечивает значительно лучшую воспринимаемую пользователем производительность, чем та, которая ожидает, пока весь документ полностью не будет получен перед рендерингом, даже если производительность сети одинакова. Обратите внимание, что на возможность визуализации представления также может повлиять выбор контента. Если размеры динамически изменяемых таблиц и встроенных объектов должны быть определены до того, как они могут быть отображены, их появление в области просмотра страницы гипермедиа увеличит ее задержку.

5.2.2 Коннекторы

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

Untitled

Все REST взаимодействия не имею состояния. То есть, каждый запрос содержит всю необходимую информацию для того, чтобы коннектор понял запрос вне зависимости от любых запросов, которые могли предшествовать ему. Это ограничение выполняет четыре функции: 1) устраняет необходимость коннекторам сохранять состояние между запросами, что, тем самым, сокращает потребление физических ресурсов и улучшает расширяемость; 2) позволяет обрабатывать взаимодействия параллельно, не требуя, чтобы механизм обработки понимал семантику взаимодействия; 3) позволяет посреднику просматривать и понимать запрос изолированно, что может быть необходимо, если сервисы перестраиваются динамически; и 4) заставляет всю информацию, которая может влиять на переиспользуемость кэшированного ответа присутствовать в каждом запросе.

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

Основными типами коннектора является клиент и сервер. Существенная разница между этимти двумя в том, что клиент, отправляя запрос, инициирует взаимодействие, а сервер прослушивает соединения и отвечает на запросы. Компонент может содержать коннекторы как клиента, так и сервера.

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

Некоторые кэш коннекторы являются общими, что означает, что его кэшированные ответы могут использоваться в ответе клиенту, отличному от того, для которого ответ был получен первоначально. Такое совместное кэширование может быть эффективным для снижения влияния "flash crowds" на нагруженный сервер, особенно когда кэширование организовано иерархически для охвата больших групп пользователей, таких как пользователи внутренней сети компании, клиенты интернет-услуг, провайдера или университеты, разделяющие магистраль национальной сети. Однако, совместное кэширование также может приводить к ошибкам, если кэшированный ответ не совпадает с тем, что было бы получено новым запросом. REST пытается сбалансировать стремление к прозрачности в поведении кэша со стремлением к эффективнмоу использованию сети, а не предполагать, что абсолютная рпозрачность требуется всегда.

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

Средство распознавания преобразует частичные или полные идентификаторы ресурса в информацию о сетевом аддресе, необходимую для устноавления межкомпонентного соединения. например, большинство URI включают в себя имя хоста DNS в качетсве механизма идентификации полномочий ресурса по его именованию. Чтобы инициировать запрос, веб браузер извлечет имя хоста из URI и использует распознаватель DNS для получения адреса интернет-протокола. Другой пример: некоторые схемы идентификации (например, URN) требуют, чтобы посредник преобразовывал постоянный идентификатор в более переходный адрес для доступа к идентифицированному ресурсу. Использование одного или нескольких промежуточных распознавателей может увеличить долговечность ссылок на ресурсы за счет косвенного обращения, хотя это увеличить задержку запроса.

Последним типом коннектора является туннель, который просто передает взаимодействия через границу соединения, такую как межсетевой экран или сетевой шлюз более низкого уровня. Единственная причина, по которой он моделируется как часть REST и не абстрагируется как часть сетевой инфраструктуры, в том, что некоторые REST компоненты из поведения активного компонента на поведение туннеля могут переключаться динамически. Основным примером является HTTP прокси, который переключается на туннель в ответ на метод CONNECT запроса, что позволяетс его клиенту напрямую связываться с удаленным сервером используя другом протокол, такой как TLS, который не допускает прокси. Такой туннель исчезает, когда оба конца соединения прекращают связь.

5.2.3 Компоненты

REST компнонеты, выведенные в таблице 5-3, типизируются на основе принимаемых ими ролей в событиях приложения.

Untitled

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

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

Для пересылки запросов и ответов промежуточные компоненты ведут себя и как клиент, и как сервер. Компонент proxy является посредником, выбранным клиентом для обеспечения интерфейса инкапсуляции для своих сервисов, трансляции данных, повышения производительности и защиты безопасности. Шлюзовый (a.k.a., reverse proxy) компонент - посредник, навязанный сетевым или исходным сервером для обеспечения инкапсуляции интерфейса других служб, для перевода данных, повышения производительности или обеспечения безопасности. Заметьте, что разница между proxy и шлюзом в том, что клиенту нужно явно определить, когда ему нужно использовать proxy.

5.3 Архитектурные представления REST

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

5.3.1 Представление процесса

Процессное представление архитектуры в первую очередь эффективно для выявления взаимосвязей взаимодействия между компонентами, показывая путь данных, когда они проходят через систему. Процессное представление архитектуры в первую очередь эффективно для выявления взаимосвязей взаимодействия между компонентами, показывая путь данных, когда они проходят через систему. На изображении 5-10 приведен пример представления процесса из архитектуры на основе REST в конкретном случае во время обработки трех параллельных запросов.

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

Поскольку компоненты подключаются динамически, их расположение и функции для конкретного действия приложения имеют характеристики, аналогичные стилю конвейера (pipe) и фильтра. Хотя компоненты REST обмениваются данными через двунаправленные потоки, обработка каждого направления независима и поэтому восприимчива к преобразователям потока (фильтрам). Общий интерфейс соединителя позволяет размещать компоненты в потоке на основе свойств каждого запроса или ответа.

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

5.3.2 Представление коннектора

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

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

REST не ограничивает связь конкретным протоколом, но ограничивает интерфейс между компонентами и, следовательно, дополняет область предположений о взаимодействии и реализации, которые могли бы быть сделаны между компонентами. Например, основным протоколом передачи в Интернете является HTTP, но в архитектуру также входит беспрепятственный доступ к ресурсам, которые создаются на уже существующих сетевых серверах, включая FTP, Gopher и WAIS. Взаимодействие с этими службами ограничено семантикой коннектора REST. Это ограничение жертвует некоторыми из преимуществ других архитектур, таких как взаимодействие с состоянием протокола обратной связи по релевантности, такого как WAIS, чтобы сохранить преимущества единого универсального интерфейса для семантики коннектора. В свою очередь, общий интерфейс позволяет получить доступ к множеству сервисов через один прокси. Если приложению требуются дополнительные возможности другой архитектуры, оно может реализовать и вызвать эти возможности как отдельную систему, работающую параллельно, подобно тому, как веб-архитектура взаимодействует с ресурсами "telnet" и "mailto".

5.3.3 Представление данных

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

Взаимодействие компонентов происходит в форме сообщений динамического размера. Сообщения малого или среднего размера используются для семантики управления, но основная часть работы приложения выполняется через сообщения большого размера, содержащие полное представление ресурса. Наиболее частой формой семантики запроса является извлечение представления ресурса (например, метода «GET» в HTTP), который часто можно кэшировать для последующего повторного использования.

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

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

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

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

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

Следующее состояние управления приложением находится в представлении первого запрошенного ресурса, поэтому получение этого первого представления является приоритетом. Поэтому взаимодействие REST улучшается с помощью протоколов, которые «сначала отвечают, а потом думают». Другими словами, протокол, который требует множественных взаимодействий для каждого действия пользователя, для того, чтобы выполнить такие вещи, как согласование возможностей функции перед отправкой ответа на контент, будет значительно медленнее, чем протокол, который сначала отправляет то, что наиболее вероятно будет оптимальным, а затем обеспечивает список альтернатив, которые клиент может получить, если первый ответ неудовлетворителен.

Состояние приложения контролируется и сохраняется пользовательским агентом и может состоять из представлений от нескольких серверов. В дополнение к освобождению сервера от проблем расширяемости сохранения состояния, это позволяет пользователю напрямую манипулировать состоянием (например, историей веб-браузера), предвидеть изменения в этом состоянии (например, карты ссылок и предварительную выборку представлений) и выполнять переход из одного приложения в другое (например, закладки и диалоги ввода URI).

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

разбираемся с байткодом v8 [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:36 +0000

Вольный перевод статьи Franziska Hinkelmann "Understanding V8’s Bytecode"

Разбираемся с байткодом V8

V8 - это опенсорсный движок для JavaScript, разработанный Google. Chrome, Node.js и многие другие приложения используют V8. В этой статье будет предложено объяснение формата байткода V8, который, на самом деле, станет очень простым для чтения, как только вы поймете некоторые основные концепты.

Ignition, lift-off! Интерпретатор Ignition является частью пайплайна компилятора с 2016-го года.

Когда V8 компилирует JavaScript код, парсер генерирует абстрактное синтаксическое дерево. Синтаксическое дерево - это древовидное представление синтаксической структуры JavaScript кода, из которого интерпретатор Ignition генерирует байткод. TurboFan - это оптимизирующий компилятор, который берет байткод и генерирует из него оптимизированный машинный код.

Пайплайн компилятора V8

Если хотите узнать, для чего нам нужно именно два режима выполнения, можете посмотреть мое видео с конференции JSConfEU:

video: https://www.youtube.com/watch?v=p-iiEDtpy6I&feature=emb_logo

Bytecode является абстракцией машинного кода. Компилировать байткод в машинный код будет проще, если байткод был спроектирован с одинаковой вычислительной моделью, что и физический CPU. Поэтому интерпретаторы обычно являются регистровыми или стэковыми машинами. Ignition - регистровая машина с аккумулятором (регистром процессора).

Байткоды V8 можно рассматривать как маленькие строительные блоки, которые выстраивают любую JavaScript функциональность, когда складываются вместе. V8 имеет несколько сотен байткодов. Есть байткоды для операций, вроде Add и TypeOf, или для загрузки свойств, вроде LdaNamedProperty. V8 также имеет несколько специфичных байткодов, вроде CreateObjectLiteral и SuspendGenerator. Головной файл bytecodes.h определяет полный их список.

Каждый bytecode определяет входные и выходные данные как операнды регистра. Ignition использует геристры r0, r1, r2, ... и аккумулятор, который также используют почти все байткоды. Он похож на обычный регистр, но байткоды его не определяют его точно. Например, Add r1 добавляет значение регистра r1 к значению в аккумуляторе, что позволяет сохранять память и хранить байткоды в более коротком виде.

Множество байткодов начинается с Lda или Sta. a в выражении Ld**a** и St**a** обозначает aккумулятор. Например, LdaSmi [42] подгружает маленькое целое число (Small Integer - Smi) 42 в регистр аккумулятора. Star r0 будет хранить текущее значение регистра r0.

Пора взглянуть на байткод реальной функции.

function incrementX(obj) {
  return 1 + obj.x;
}

incrementX({x: 42});  // Компилятор V8 ленив. Если вы не запустите функцию - он ее не интерпретирует.

Если вы хотите посмотреть на байткод V8 в JavaScript коде, то исполните команду с флагом --print-bytecode (для D8 и Node.js версии 8.3 и выше). Для Chrome вам нужно запустить его из командной строки с флагом --js-flags="--print-bytecode", см. Запуск Chromium с флагами.

$ node --print-bytecode incrementX.js
...
[generating bytecode for function: incrementX]
Parameter count 2
Frame size 8
  12 E> 0x2ddf8802cf6e @    StackCheck
  19 S> 0x2ddf8802cf6f @    LdaSmi [1]
        0x2ddf8802cf71 @    Star r0
  34 E> 0x2ddf8802cf73 @    LdaNamedProperty a0, [0], [4]
  28 E> 0x2ddf8802cf77 @    Add r0, [6]
  36 S> 0x2ddf8802cf7a @    Return
Constant pool (size = 1)
0x2ddf8802cf21: [FixedArray] in OldSpace
 - map = 0x2ddfb2d02309 <Map(HOLEY_ELEMENTS)>
 - length: 1
           0: 0x2ddf8db91611 <String[1]: x>
Handler Table (size = 16)

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

LdaSmi [1]

LdaSmi [1] загружает постоянное значение 1 в аккумулятор.

Star r0

Далее, Star r0 в регистре r0 хранит значение, которое на момент находится в аккумуляторе (1).

`LdaNamedProperty a0, [0], [4]`

LdaNamedProperty загружает именованное свойство a0 в аккумулятор. ai ссылается на i-ый аргумент incrementX(). В этом примере мы ищем именованное свойство в a0, первый аргумент incrementX(). Имя определяется константой 0. LdaNamedProperty использует 0 для нахождения имени в отдельной таблице:

- length: 1
           0: 0x2ddf8db91611 <String[1]: x>

Here, 0 отображает значение x, потому этот байткод загружает obj.x.

Для чего используется операнд со значением 4? Это индекс так называемого вектора обратной связи функции incrementX(), которые содержит нужную для оптимизаций производительности рантайм информацию.

Теперь регистры выглядят так:

Add r0, [6]

Последняя инструкция добавляет r0 в аккумулятор, возвращая в результате 43. 6 - это еще один индекс вектора обратной связи.

Return

Return возвращает значение аккумулятора. Это конец функции incrementX(). Вызывающий функцию incrementX() операнд получает значение 43 из аккумулятора и может начать работать с ним.

На первый взгляд, байткод V8 может показаться какой-то загадкой, особенно со всей остальной информацией в выводе. Но как только вы поймете что Ignition это регистровая машина с аккумулятором регистра, вы сможете понять за что отвечает большинство байткодов.

Примечание: в статье описывается байткод V8 версии 6.2, Chrome версии 62 и Node версии 9. Мы постоянно работаем над улучшением потребления памяти и производительности V8, потому детали в других версиях могут отличаться.

как начать just-in-time-ить [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:33 +0000

Вольный перевод статьи Fedor Indutny "How to start JIT-ting"

Как начать Just-In-Time-ить

Предпосылки

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

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

В этой статье мы посетим несколько вершин на JIT-острове, и возможно даже реализуем компилятор сами!

С чего начнем

Зная основы компилятора, мы можем вв что каждый компилятор трансформирует входные данные какого-то формата (обычно, исходный код) в выходные такого же или другого формата (обычно, в машинный код). JIT комплияторы не исключение.

Что делает их исключительными, так это то, что они запускаются не раньше времени (как gcc, clang и другие), а Just-In-Time (вовремя) (т.е. прямо перед выполнением выходных данных комплиятора).

чтобы начать разрабатывать наш собственный JIT компилятор, понадобится выбрать язык для входных данных. Принимая во внимание ТОП ЯЗЫКОВ 2013 ГОДА НА GITHUB, JavaScript выглядит подходяще для реализации некоторого ограниченного подмножества с упрощенной семантикой. Более того, мы реализуем JIT компилятор на самом JavaScript. Это можно назвать МЕТА-МЕТА!

Абстрактное Синтаксическое Дерево (AST)

На вход наш компилятор будет принимать JavaScript и возвращать (и немедленно выполнять) машинный код для очень популярной X64 платформы. Но, посокльку люддям удобнее работать с текстовым представлением, разработчики компиляторов обычно стремятся создать несколько Промежуточных Представлений (Intermediate Representations) перед генерацией окончательного машинного кода.

Поскольку мы пишем упрощенную версию, одного промежуточного представления будет достаточно, и для этого я выбрал представление в виде Абстрактное Синтаксическое Дерево (Abstract Syntax Tree).

Получить AST из JavaScript кода достаточно просто и мы можем выбрать несколько (из десятков) библиотек вроде esprima, uglify-js и т.д. . Чтобы не отходит далеко от туториала, я порекомендую вам выбрать esprima. Он имеет неплохой и четко определенный формат выходных данных.

Например, такой код obj.method(42) создаст (с помощью esprima.parse("...")) дерево следующего вида:

{ type: 'Program',
  body:
   [ { type: 'ExpressionStatement',
       expression:
        { type: 'CallExpression',
          callee:
           { type: 'MemberExpression',
             computed: false,
             object: { type: 'Identifier', name: 'obj' },
             property: { type: 'Identifier', name: 'method' } },
          arguments: [ { type: 'Literal', value: 42 } ] } } ] }

Машинный код

Давайте обобщим: у нас есть исходный код (check), его Абстрактное Синтаксическое Дерево (check), осталось только получить машинный код.

Если вы уже знакомы с assembly то можете пропустить эту главу поскольку она содержит только базовое введение в тему. ОДнако, если нет, последующая глава, без этих основ, может показаться вам сложной для понимания. Потому оставайтесь здесь, много времени не займет!

Язык Assembly - это ближайшее текстовое представление бинарного кода который понимает и(или) может запустить ваш CPU. Учитывая, что процессоры выполнябт код читая и запускаю иснтрукции по одной, может показаться логичным, что одна строка asse,bly программы представляет собой одну инструкцию:

mov rax, 1    ; Положить 1 в регистр `rax`
mov rbx, 2    ; Положить 2 в регистр `rbx`
add rax, rbx  ; Вычислить сумму `rax` и `rbx` и положить ее в регистр `rax`

Выходными данными этой прграммы будет являться 3 (при условии, что вы получите их из rax регистра). И, как вы уже наверно догадались, программа будет ложить данные в CPU слоты (регистры) и просить CPU вычислить их сумму.

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

mov rax, 1
mov [rbp-8], rbx  ; Сохранить rbx регистр в слот стека
mov rbx, 2
add rax, rbx
mov rbx, [rbp-8]  ; Восстановить rbx регистр из слота стека

Регистры имеют имена, слоты памяти имеют адреса. Эти ардеа обычно используют [...] синтаксис. Например, [rbp-8] означает: возьми значение регистра rbp , вычти из него 8, и достучись до слота памяти, используя значение результата в качестве адреса.

Как вы можете видеть мы используем rbp регистр. rbp обычно содержит адреса по которым переменные из стека (т.е. переменные, которые хранятся в текущем процедурной стеке) запускаются; 8 это размер rbx регистра (и всех остальынх регистров, название которые начинается на r), и поскольку стек растет снизу вверх, нам нужно вычесть его из rbp чтобы получить адрес свободного слота.

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

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

Генерация кода

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

Лучшим и простейшим способом сделать это будет с помощью прохода по AST с помощью поиска в глубину, генерирую машинный код для каждого узла. Вы можете подумать как можно генерирвоать машинный код для такого memory-safe языка как JavaScript. Здесь я представлю вам jit.js.

Это node.js модуль (и C++ аддон, по сути) способный генерировать и выполнять машинны код используя assembly-подобный JavaScript синтаксис:

var jit = require('jit.js');

var fn = jit.compile(function() {
  this.Proc(function() {
    this.mov('rax', 42);
    this.Return();
  });
});
console.log(fn());  // 42

Давайте уже напишем это

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

Мы внедрим поддержку:

Числовых литералов ({ type: 'Literal', value: 123 })
Бинарных выражений с операторами: +, -, *, /, % ({ type: 'BinaryExpression', operator: '+', left: ... , right: .... })
Унарных выражений с оператором - ({ type: 'UnaryExpression', operator: '-', argument: ... })

Все эти операции выполняются на целых числах, потому не ожидайте что они сработают со значениями вроде 0.5, 0.66666 и т.д. .

Во время обработки выражения мы будем посещать каждый поддерживаемый узел AST и генерировать код, который вернет результат в rax регистр. Звучить легко, да? Здесь есть одно правило: мы должны сохранять все остальные регистры чистыми после выхода из узла дерева. Другими словами, это значит что мы должны сохранять все использованные регистры и восстанавливать их состояние после того как они не нужны. К счастью, CPU имеет две волшебные операцииpush и pop которые помогут нам с этой задачей.

Таким получится код (с комментариями):

var jit = require('jit.js'),
    esprima = require('esprima'),
    assert = require('assert');

var ast = esprima.parse(process.argv[2]);

// Compile
var fn = jit.compile(function() {
  // Создаем шаблон для входных данных по умолчанию
  this.Proc(function() {
    visit.call(this, ast);

    // Результат должен быть в 'rax'

    // Создаем шаблон для выходных данных
    this.Return();
  });
});

// Выполнение
console.log(fn());

function visit(ast) {
  if (ast.type === 'Program')
    visitProgram.call(this, ast);
  else if (ast.type === 'Literal')
    visitLiteral.call(this, ast);
  else if (ast.type === 'UnaryExpression')
    visitUnary.call(this, ast);
  else if (ast.type === 'BinaryExpression')
    visitBinary.call(this, ast);
  else
    throw new Error('Неизвестный AST узел: ' + ast.type);
}

function visitProgram(ast) {
  assert.equal(ast.body.length,
               1,
               'Поддерживается только один оператор');
  assert.equal(ast.body[0].type, 'ExpressionStatement');
  visit.call(this, ast.body[0].expression);
}

function visitLiteral(ast) {
  assert.equal(typeof ast.value, 'number');
  assert.equal(ast.value | 0,
               ast.value,
               'Поддерживаются только целочисленные значения');

  this.mov('rax', ast.value);
}

function visitBinary(ast) {
  // Сохраняем 'rbx' после того, как вышли из AST узла
  this.push('rbx');

  // Посещаем правую стороно выражения
  visit.call(this, ast.right);

  // Перемещаем в 'rbx'
  this.mov('rbx', 'rax');

  // Посещаем левую сторну выражения (результат в 'rax')
  visit.call(this, ast.left);

  //
  // Обобщяя, левая сторона хранится в 'rax', правая - в 'rbx'
  //

  // Выполняем бинарную операцию
  if (ast.operator === '+') {
    this.add('rax', 'rbx');
  } else if (ast.operator === '-') {
    this.sub('rax', 'rbx');
  } else if (ast.operator === '*') {
    // Умножение со знаком
    // rax = rax * rbx
    this.imul('rbx');
  } else if (ast.operator === '/') {
    // Сохраняем 'rdx'
    this.push('rdx');

    // idiv выполняет деление rdx:rax на rbx, следовательно, нам нужно очистить rdx
    // перед запуском
    this.xor('rdx', 'rdx');

    // Деление со знаком, rax = rax / rbx
    this.idiv('rbx');

    // Восстанавливаем 'rdx'
    this.pop('rdx');
  } else if (ast.operator === '%') {
    // Сохраняем 'rdx'
    this.push('rdx');

    // Готовимся выполнить idiv
    this.xor('rdx', 'rdx');
    this.idiv('rbx');

    // idiv помещает остаток в 'rdx'
    this.mov('rax', 'rdx');

    // Восстанавливаем 'rdx'
    this.pop('rdx');
  } else {
    throw new Error('Неподдерживаемый бинарный оператор: ' + ast.operator);
  }

  // Восстанавливаем 'rbx'
  this.pop('rbx');

  // Результат в 'rax'
}

function visitUnary(ast) {
  // Посещаем аргумент и складываем результат в 'rax'
  visit.call(this, ast.argument);

  if (ast.operator === '-') {
    // Делаем аргумент отрицательным
    this.neg('rax');
  } else {
    throw new Error('Неподдерживаемый унарный оператор: ' + ast.operator);
  }
}

Вы можете попробоать сами склонировав исходный код с github, запустив npm install и вуаля!

$ node ./main.js '1 + 2 * 3'
7

назначаем числа [перевод]

собачья будка — Wed, 29 Apr 2020 19:29:31 +0000

Вольный перевод статьи Fedor Indutny "Allocating numbers"

Назначаем числа

Цели

В прошлой статье мы создали JIT компилятор, поддерживающий очень ограниченное количесвто подномежств JavaScript: целые числа, бинарные математические операции операторы (+, -, *, /), и унарный оператор -. В этот раз мы расширим его добавлением поддержки чисел с плавающей точкой, а, чтобы процесс стал живее и веселее, мы будем выделять и хранить эти числа в куче.

Поскольку мы внедряем функциональность небольшими шагами, на этом этапе наша куча не будет иметь сборщика мусора и будет жить внутри чанка памяти фиксированного размера (скажи "ура" простоте!).

Stubs

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

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

Как правило, это считается плохой практикой. Более лучшим подходом будет будет параметризация таких блоков кода в общие процедуры, называемые stubs (я взял это название из кода v8 и, похоже, они имеют такое же название и в других VM). Для еще большей оптимизации эти процедуры можно компилировать лениво, т.е. мы не должны компилировать участки, которые не используются генерируемым кодом. Эта техника хорошо сказывается на времени компиляции и размере выполняемого кода (и, соответснвенно, кэше CPU).

К счастью, jit.js позволяет достаточно легко генерировать stubs:

var stubs = jit.stubs();

stubs.define('Allocate', function() {
  // Наш код здесь
  // ....

  // Возвращаемся к месту вызова
  this.Return();
});

Просто, не так ли? Чтобы использовать это в нашем JIT компиляторе нам нужно передать его в аргументы:

jit.compile(function() {
  // Пояснение:
  // Прочитать адрес стаба 'Allocate' в регистре 'rax' и
  // вызвать его.
  this.stub('rax', 'Allocate');

  this.Return();
}, { stubs: stubs });

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

Куча

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

Куча - это место, где JavaScript (и многие другие) VM создает и хранит обхекты (обычно те которые не могут уместиться в регистрах CPU). Некоторые объекты кучи могут содержать ссылки на другие объекты (другими словами, могут ссылаться на них). Все живущие объекты и их ссылки создают ориентированный граф начиная с так называех корней (который обычно являются глобальными переменными и указателями в стеке).

И хоть она обычно используется для VM, сборка мусора не обязательна для кучи. Многие виртуальные машины и языки выбирают неуправляемую память вместо того (C/C++ как пример). В таких случаях (как пользователь языка) будет необзодимо явно очищать неиспользуемые ресурсы чтобы не исчерпать память.

Но по очевидным причинам компилятор подмножеств JavaScript который мы реализуем должен поддерживать как управляемую память так и сборку мусора (что сделаем позже).

Есть тонны кнги котоыре могут дать вам продвинутое представление о распределении кучи и сборке мусора (я порекомендую The Garbage Collection Handbook) и и значительно много способов выделения и сборки памяти в куче.

Обычно вам понадобится выбрать между скоростью выделения и фрагментацией памяти. Но поскольку мы не углубляемся в тему я порекомендую остановиться на методе "bump allocation".

Bump allocation

bump allocation для фиксированных страниц работает следующим образом.

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

Используя jit.js и стабы, эта процедура может выглядеть следующим образом:

// Создаем чанки памяти фиксированного размера
var page = new Buffer(1024);

// Устанавливаем указатели на начало и конец страницы
var offset = jit.ptr(page);
var end = jit.ptr(page, page.length);

stubs.define('Alloc', function() {

  // Сохраняем регистры 'rbx' и 'rcx'
  this.spill(['rbx', 'rcx'], function() {
    // Загружаем `offset`
    //
    // ПРИМЕЧАНИЕ: Мы будем использовать указатель для переменной `offset`, чтобы была вохможность
    // позже обновить ее
    this.mov('rax', this.ptr(offset));
    this.mov('rax', ['rax']);

    // Конец заргрузки
    //
    // ПРИМЕЧАНИЕ: То же самое относится и к концу страницы, но мы не обновляем его прямо сейчас
    this.mov('rbx', this.ptr(end));
    this.mov('rbx', ['rbx']);

    // Вычисляем новый `offset`
    this.mov('rcx', 'rax');

    this.add('rcx', 16);

    // Проверяем, не переполняется ли буффер фиксированного размера
    this.cmp('rcx', 'rbx');

    // this.j() выполняет условный переход к указанной метке.
    // 'g' означает 'greater'
    // 'overflow' - это имя метки, связанной ниже
    this.j('g', 'overflow');

    // Окей, может двигаться дальше и обновить offset
    this.mov('rbx', this.ptr(offset));
    this.mov(['rbx'], 'rcx');

    // Первый 64-х битный указатель зарезервирован для 'tag',
    // второй имеет значенеи `double`
    this.mov(['rax'], 1);

    // Возвращаем 'rax'
    this.Return();

    // Переполнение :(
    this.bind('overflow')

    // Вызываем javascript функцию!
    // ПРИМЕЧАНИЕ: Штука ниже очень прикольная, но я поясню ее позже
    this.runtime(function() {
      console.log('GC is needed, but not implemented');
    });

    // Краш
    this.int3();

    this.Return();
  });
});

Это все! Не совсем просто, но не так уж и сложно!

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

Стоит отметить пару моментов:

jit.ptr(buf, offset) возвращает Buffer, содержащий указатель на данный buf с добавленным к нему offset.
this.spill() - это процедура для сохранения и восстановления регистров памяти (обычно называется spilling). Принимает список регистров и коллбэк. Эти регистры будут сохранены перед входом в коллбэк и восстановлены после выхода из него. ПРИМЕЧАНИЕ: ВОсстановленный код будет сгенерирован перед каждым this.Return().
this.mov(['rbx'], 'rcx') сохраняет регистр rcx в ячейку памяти, на которую указывает значение регистра rbx. ПРИМЕЧАНИЕ: offset также можно указать здесь: this.mov(['rbx', 8], 'rcx').
jit.js поддерживает ветвления примитивов: this.cmp(a, b), this.j(condition, labelName), this.j(labelName), this.bind(labelName).

Плавающая запятая

Теперь, когда у нас есть предположительно работающая процедура, давайте вспомним что должно храниться внутри чанков нашей кучи. Мы создали чанки со значением тега 8 байт и содержимым 8 байт. Этого достаточно чтобы хранить double (как C тип) числа с плавающей запятой.

Есть множество assembly инструкций для загрузки/хранения и работы с такими числами. Но заметьте что для работы с ними их нужно хранить в разных наборах регистров: xmm0, xmm1, ... xmm15. Хотя, 64-х битные числа с плавающей запятой могут храниться и в регистрах общего назначения: rax, rbx, ... Математические операции возможны только с набором регистров xmm. Ниже несколько инструкций которые присутстввуют в jit.js и могут быть полезными нашему компилятору:

movq('xmm', 'gp') или movq('gp', 'xmm') для перемещения 64-х битных значений из регистра общего назначения в xmm, или наоборот.
movsd('xmm', 'xmm') для перемещения значения из одного xmm к другому.
addsd, mulsd, subsd, divsd - сложение, умножение, вычитание, деление.
cvtsi2sd('xmm', 'gp'), cvts2si('gp', 'xmm') для концертации целых чисел в double, и наоборот.
roundsd('mode', 'xmm', 'xmm') для округления значения регистра src с помощью указанного режима mode (одного из: nearest, down, up, zero) и помещения результата в регистр dst.

Используя это священное знание, мы можем исправить наш код, чтобы он работал с числами с плавающей запятой (да, мы пока удалим целочисленную поддержку).:

// Compile
var fn = jit.compile(function() {
  // Создаем шаблон для входных данных по умолчанию
  this.Proc(function() {
    visit.call(this, ast);

    // Результат должен быть в 'rax'
    //
    // Создаем шаблон для выходных данных
    this.Return();
  });
}, { stubs: stubs });

// Выполнение
console.log(fn());

function visit(ast) {
  if (ast.type === 'Program')
    visitProgram.call(this, ast);
  else if (ast.type === 'Literal')
    visitLiteral.call(this, ast);
  else if (ast.type === 'UnaryExpression')
    visitUnary.call(this, ast);
  else if (ast.type === 'BinaryExpression')
    visitBinary.call(this, ast);
  else
    throw new Error('Неизвестный AST узел: ' + ast.type);
}

function visitProgram(ast) {
  assert.equal(ast.body.length,
               1,
               'Поддерживается только один оператор');
  assert.equal(ast.body[0].type, 'ExpressionStatement');

  // Конвертируем в целое число имеющийся в 'rax' указатель
  visit.call(this, ast.body[0].expression);

  // Получаем число с плавающей запятой из числа кучи
  this.movq('xmm1', ['rax', 8]);

  // Округляем до нуля
  this.roundsd('zero', 'xmm1', 'xmm1');

  // Конвертируем double в целое число
  this.cvtsd2si('rax', 'xmm1');
}

function visitLiteral(ast) {
  assert.equal(typeof ast.value, 'number');

  // Выделяем новое число кучи
  this.stub('rax', 'Alloc');

  // Сохраняем 'rbx' регистр
  this.spill('rbx', function() {
    this.loadDouble('rbx', ast.value);
    this.mov(['rax', 8], 'rbx');
  });
}

function visitBinary(ast) {
  // Сохраняем 'rbx' после того, как вышли из AST узла
  this.spill('rbx', function() {
    // Посещаем правую сторону выражения
    visit.call(this, ast.right);

    // Перемещаем в 'rbx'
    this.mov('rbx', 'rax');

    // Посещаем левую сторону выражения (результат в 'rax')
    visit.call(this, ast.left);

    //
    // Обобщяя, левая сторона хранится в 'rax', правая - в 'rbx'
    //

    // Загружаем их значения в double представлении
    this.movq('xmm1', ['rax', 8]);
    this.movq('xmm2', ['rbx', 8]);

    // Выполняем бинарную операцию
    if (ast.operator === '+') {
      this.addsd('xmm1', 'xmm2');
    } else if (ast.operator === '-') {
      this.subsd('xmm1', 'xmm2');
    } else if (ast.operator === '*') {
      this.mulsd('xmm1', 'xmm2');
    } else if (ast.operator === '/') {
      this.divsd('xmm1', 'xmm2');
    } else {
      throw new Error('Неподдерживаемый бинарный оператор: ' + ast.operator);
    }

    // Выделяем новое число и складываем в него значение
    this.stub('rax', 'Alloc');
    this.movq(['rax', 8], 'xmm1');
  });
}

function visitUnary(ast) {
  if (ast.operator === '-') {
    // Делаем аргумент отрицательным эмулируя бинарное выражение
    visit.call(this, {
      type: 'BinaryExpression',
      operator: '*',
      left: ast.argument,
      right: { type: 'Literal', value: -1 }
    })
  } else {
    throw new Error('Unsupported unary operator: ' + ast.operator);
  }
}

Forem: собачья будка

плавающее оглавление на solidjs

контекст

сбор заголовков из документа

debounce пересборки оглавления

определение активного заголовка

переход к заголовку

состояние компонента

подписка на скролл

реакция на изменение статьи

рендер списка

визуальная иерархия заголовков

активный пункт

sticky поведение на десктопе

mobile режим (fixed bottom panel)

toggle видимости

итог

image cropper на solidjs

контекст

сам компонент

стили: это уже не просто ui

canvas как рабочая поверхность

grab vs dragging

zoom контролы

адаптивность

как работает рендер

drag логика

перемещение области

экспорт кропа

сохранение файла

итог

кастомный аудиоплеер на solidjs вокруг нативного audio api

данные и состояние

переключение треков и play/pause

синхронизация с <audio>

воспроизведение

прогресс и время

перемотка (scrub)

обработка событий audio

громкость через web audio api

header (контролы)

плейлист

шаринг

стили

как сконвертировать пачку изображений в webp

как наложить блюр в фигме

генерируем xlsx из rss фида

очередной слайдер, которого никто не просил

как я избавлялся от экстремизма в блоге

architectural styles and the design of network-based software architectures. representational state transfer [перевод]

Representational State Transfer (REST)

5.1 Процесс выведения REST

5.1.1 Начиная с Нулевого Стиля

5.1.2 Клиент-сервер

5.1.3 Отсутствие состояния (Stateless)

5.1.4 Кэш

5.1.5 Унифицированный интерфейс

5.1.6 Многоуровневая система

5.1.7 Код по требованию

5.1.8 Summary

5.2 Архитектурные элементы REST

5.2.1 Элементы данных

5.2.1.1 Ресурсы и идентификаторы ресурса

5.2.1.2 Представления

5.2.2 Коннекторы

5.2.3 Компоненты

5.3 Архитектурные представления REST

5.3.1 Представление процесса

5.3.2 Представление коннектора

5.3.3 Представление данных

разбираемся с байткодом v8 [перевод]

Разбираемся с байткодом V8

LdaSmi [1]

Star r0

LdaNamedProperty a0, [0], [4]

Add r0, [6]

Return

как начать just-in-time-ить [перевод]

Как начать Just-In-Time-ить

Предпосылки

синхронизация с `<audio>`

`LdaNamedProperty a0, [0], [4]`