Привет! Вы наверняка слышали множество разговоров о том, как AI изменит мир и нашу работу в будущем. Однако, многие из этих разговоров не концентрируются на том, как именно можно использовать технологию AI для улучшения конкретных процессов. В этой статье мы поговорим о том, как использование GPT-3 может помочь вам улучшить опыт работы frontend-разработчика.

GPT-3 — это мощный искусственный интеллект, который может генерировать тексты на основе анализа огромного количества данных. Он может быть очень полезен для различных задач, связанных с frontend-разработкой, от написания кода до создания документации.

Как GPT-3 может помочь фронтенд разработчикам

Давайте рассмотрим некоторые из задач, с которыми сталкиваются фронтенд-разработчики, и посмотрим, как GPT-3 может помочь в их решении:

• Написание кода. Часто, чтобы написать хороший код, нужно учитывать множество факторов, например контекст, задачу, которую нужно решить, и возможные ошибки. С помощью GPT-3 вы можете генерировать умные подсказки, которые помогут вам написать более качественный код быстрее. Например, инструменты, основанные на GPT-3, могут генерировать код на основе входных данных и контекста, что может сэкономить много времени и усилий. Один из примеров такого инструмента — Github Copilot, который следит за контекстом написания и предлагает умные подсказки.
• Тестирование. Создание тестов — важная часть работы frontend-разработчика, которая помогает убедиться, что код работает правильно и не содержит ошибок. GPT-3 может помочь сгенерировать базовые тесты автоматически на основе ваших данных, что позволит сэкономить время и силы. Также GPT-3 может использоваться для создания автоматических тестов, которые проверяют работу приложения в широком диапазоне сценариев. Я тестировал написание тестов с помощью ChatGPT и результат был отличным. Но в текущем рабочем проекте мы не пишем тесты, поэтому оставлю эту идею на следующую публикацию.
• Документация. Создание документации — это важная, но не всегда приятная работа. GPT-3 может помочь автоматизировать процесс создания документации. Последние полгода я использую VSCode расширение Mintlify для автоматической генерации JSDoc документации. В Javascript это позволяет добиться небольшой типизации и упростить работу для других разработчиков. Более комплексные участки кода я по прежнему документирую вручную.

Developer Experience

Что скрывается за термином «Developer Experience»? Это может быть все, что угодно, начиная от языка программирования и фреймворков и заканчивая конвенциями о форматах API, линтерах, именах переменных, коммитах и т. д. В этой статье мы рассмотрим то, что я подразумеваю под этим термином.

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

Недавно я просил ChatGPT исправить некоторые eslint-ошибки в проекте, и он прекрасно справился с этой задачей. Однако стоит ли создавать отдельный инструмент для этого, если уже есть автоматическое исправление в eslint? Я считаю, что нет. Лучше научиться настраивать eslint.

Однако, что действительно может вызывать проблемы — это коммиты. Для их именования существуют готовые конвенции, например, Conventional Commits. Для проверки этих коммитов можно использовать Commitlint.

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

Атомарные коммиты — это когда каждый коммит задевает минимальную область изменений (обычно до 20-30 строк кода и одного файла)

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

Но вводить 100 символов описания для каждых 10 строчек — лень 🫡

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

Прогаем

Для начала нам понадобится аккаунт OpenAI. Если у вас еще нет аккаунта OpenAI – можете воспользоваться вот этим гайдом. Далее нам нужно получить OpenAI API KEY по этому адресу.

Так же, необходимо установить NodeJS, следуя оффициальному гайду.

Логика формирования запроса к нейронке

Сгенерируем prompt. Путем 10-15 экспериментов с ChatGPT, у меня получился примерно такой prompt, который генерирует осмысленные и подходящие по типу сообщения:

Generate a short commit title based on diff changes above, using gitmoji and conventional commits. Structure: <emoji> <type>: <subject>'

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

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

const getArgs = () => {
  return process.argv.slice(2)
    .reduce((args, arg) => {
      if (arg.startsWith('--')) {
        const [flag, value = true] = arg.split('=');
        args[flag.slice(2)] = value;
      } else if (arg[0] === '-') {
        arg.slice(1).split('').forEach(flag => {
          args[flag] = true;
        });
      }

      return args;
    }, {});
};

const args = getArgs();

const apiKey = args.apiKey || process.env.OPENAI_API_KEY || (() => {
    error('Please set the OPENAI_API_KEY environment variable.');
    process.exit(1);
})();

Проверяем, что запросы уходят

Пишем базовую проверку и запускаем скрипт 👀

const api = new ChatGPTAPI({
  apiKey,
})

async function main() {
  const { text } = await api.sendMessage('Test connection');

  console.log(text)
}

Достаем изменения с помощью git-а.

Теперь, нам нужно собрать список изменений в файле. Для этого используем встроенный в Node модуль child_proccess

Запишем в переменную наш diff и отправим в GPT-3 уже полноценный запрос, который состоит из изменений и промпта.

import { execSync } from 'child_process';
import { ChatGPTAPI } from 'chatgpt'

// Здесь пропущена инициализация клиента, она есть выше.

async function main() {
  const diff = execSync('git diff --staged').toString()

  const prompt = 'Generate a short commit title based on diff changes above, using gitmoji and conventional commits. Structure: <emoji> <type>: <subject>'

  const { text } = await api.sendMessage(`${diff}\n # ${prompt}`)

  console.log(`Proposed Commit:\n------------------------------\n${text}\n------------------------------`)
}

main();

И попробуем добавить в гит эти изменения и запустить скрипт.

Добавляем вариативность

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

// Мы получили коммит сообщение в переменную text выше.

inquirer
    .prompt([
      {
        type: 'confirm',
        name: 'continue',
        message: 'Do you want to continue?',
        default: true,
      },
    ])
    .then((answers) => {
      if (!answers.continue) {
        console.log('Commit aborted by user.');
        process.exit(1);
      }
      // info('Committing Message...');
      console.log('Committing Message...')
      execSync(`git commit -F -`, { input: text }); // Делаем коммит с текущим сообщением. 
    });

Застейджим изменения и попробуем вызвать наш скрипт.

Модифицируем промпт

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

Вот новый prompt:

I want you to act as a senior Frontend developer. I will provide you with my code changes as a git diff and ask you to generate a commit message. In our project, we use conventional commits and gitmoji to design the messages. The commit structure should be in the form of <emoji> <type in lowercase>: <subject>\nHere is a list of changes:\n

Добавим его в проект и попробуем сгенерировать сообщение.

Добавим еще немного функциональности

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

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

const generateListCommits = async (diff) => {
	// Добавили новый промпт с 5 вариантами.
  const prompt = 'I want you to act as a commit message generator. I will provide you with my code changes as a git diff and I would like you to generate an appropriate commit message. Generate 5 variants and send them in one line, separated by commas. Try to understand the meaning of the changes, not just the name of the file. In our project, we use conventional commits and gitmoji to design the messages. The commit structure should be of `<emoji> <type in lowercase>: <subject>`\nHere is a list of changes:\n'

  const { text } = await api.sendMessage(prompt + diff)

  const msgs = text.split(',').map((msg) => msg.trim())

  // add regenerate option
  msgs.push(REGENERATE_MSG)

  inquirer.prompt([
    {
      type: 'list',
      name: 'commit',
      message: 'Select a commit message',
      choices: msgs,
    },
  ]).then((answers) => {
    if (answers.commit === REGENERATE_MSG) {
			// На всякий случай добавим рекурсию, если все 5 вариантов оказались неподходящие
      generateListCommits(diff) 
      return
    }
    console.log('Committing Message... 🚀 ')
    execSync(`git commit -F -`, { input: answers.commit });
    console.log('Commit Successful! 🎉')
  });
}

С force все ещё проще, мы просто убираем возможность отклонить коммит. Вот итоговый код

const generateSingleCommit = async () => {
  const prompt = 'I want you to act as a commit message generator. I will provide you with my code changes as a git diff and I would like you to generate an appropriate commit message. Try to understand the meaning of the changes, not just the name of the file. In our project, we use conventional commits and gitmoji to design the messages. The commit structure should be of `<emoji> <type in lowercase>: <subject>`\nHere is a list of changes:\n'

  const { text } = await api.sendMessage(prompt + diff)

  console.log(`Proposed Commit:\n------------------------------\n${text}\n------------------------------`)

  if (args.force) {
    makeCommit(text)
    return
  }

  inquirer
    .prompt([
      {
        type: 'confirm',
        name: 'continue',
        message: 'Do you want to continue?',
        default: true,
      },
    ])
    .then((answers) => {
      if (!answers.continue) {
        console.log('Commit aborted by user 🙅‍♂️');
        process.exit(1);
      }

      makeCommit(text)
    });
}

Рефакторим

Какой код без рефакторинга? Плохой!

Спустя пару дней тестирования пакета я понял, что генерация gitmoji работает не так, как я ожидал. В большинстве случаев emoji выбирается рандомно из списка допустимых в gitmoji. Упростим prompt, а подставление правильного gitmoji оставим в виде обычной javascript функции.

Для этого воспользуемся ChatGPT и попросим написать функцию за нас.

Используем

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

Я опубликовал пакет по адресу https://www.npmjs.com/package/ai-commit и теперь, для того чтобы его использовать на любом компьютере, мне нужно сделать 3 вещи.

1. Установить глобально env переменную с моим OPENAI_API_KEY. Я добавлял ключ на маке по этой инструкции , для своих ОС можете попросить совет у ChatGPT (ну или загуглить, как бумеры)
2. Установить глобально пакет: npm install -g ai-commit
3. Воспользоваться библиотекой в любом месте, где вы совершаете изменения с помощью команды ai-commit
4. Вы великолепны ✨

Упрощаем, Level GOD!

1. Добавляем в VSCode расширение Command Runner (https://marketplace.visualstudio.com/items?itemName=edonet.vscode-command-runner)
2. Нажимаем Cmd + Shift + P и ищем пункт Open Keyboard Shortcuts (JSON)
3. В конце списка шорткатов добавляем еще один, с таким содержимым:

{
    "key": "cmd+enter",
    "label": "Generate commit and push",
    "command": "command-runner.run",
    "args": {"command": "git add . && ai-commit"},
    "when": "editorTextFocus"
  }

Теперь мы на любое небольшое изменение просто нажимаем Cmd + Enter и получаем готовый коммит. Добавлять файлы вручную для этого не обязательно.

Заключение

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

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

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

Я надеюсь, что моя библиотека и советы помогут вам достигнуть новых высот в вашей работе. Желаю вам удачи и успехов в вашей профессиональной деятельности! Подписывайтесь на мой телеграм канал, ставьте лайки и до скорой встречи 💜

GM! Не знаю, собирается ли СЕО Бинанса запустить свой инфокурс, но он написал рассуждение о тайм-менеджменте и как у него получается быть эффективным.

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

Я сокращаю большинство своих встреч до 15 минут (с) Чанпэн Чжао

Действительно, нужны ли долгие встречи в работе? Ведь часто хочется что-то обсудить, послушать мнение всех и не забыть про «подводные камни», которые могут встретиться на пути. И тут стоит рассказать о первом и наиболее популярном законе Паркинсона:

Но получается, что можно обсуждать большие дела за 5 минут и выполнять все на 100 процентов? Нет, немного не так. Паркинсон был умным чуваком и следом за своим самым популярным законом сразу написал второй:

Можно подробно почитать про «эффект велосипедного сарая», на котором как раз построен закон, но суть достаточно проста.

Чем тривиальнее и проще тема для обсуждения — тем больше человек хочет высказаться о ней. Таким образом, если на одной встрече поставлено несколько тем — большинство времени у всех займет обсуждение менее важной задачи.

Воображаемый пример из криптостартапа

Собирается встреча, на которой нужно обсудить производительность API сервиса. На встречу приглашается вся команда (фронтендеры, бэкендеры, дизайнеры, СЕО) и часовая встреча, в теме которой стоит производительность, завершается тем, что дизайнеры рисуют лоадеры, СЕО придумывает юзер-флоу, в котором данные идут долго, а фронтендеры сразу берут все эти задачи в работу.

Решилась ли проблема? Я считаю, что да. Ведь сама по себе проблема заключалась в неудобстве пользователя продукта, но какими ресурсами она решилась? Давайте возьмем за пример компанию, в которой по 2 человека в каждом направлении и СЕО, да сравним. На встрече находятся 7 человек, каждый из которых потратил по часу своего рабочего времени. Дальше СЕО продумывает новый флоу и отдает ТЗ дизайнерам. Возьмем еще 2 часа времени на это. Ну и дальше уже стандартный рабочий процесс с выполнением дизайна, передаче на фронтенд и имплементации. Пусть будет еще 6 часов суммарной работы между дизайнером и фронтендером.

Но что, если воспользоваться законом Паркинсона и сократить время встречи до 10 минут? Тогда кажется разумным, что приглашать 7 человек не имеет никакого смысла, ведь у каждого будет всего по одной минуте на то, чтобы высказаться и к результату придти сложно (это мы еще не берем в расчет, что половина людей опоздает и времени останется еще меньше). Как решать эту проблему? 🤔

А тут на помощь приходит второй вариант: 10 минутная встреча, на которой находятся 2 бэкендера. Они обсуждают CDN и кэширование данных, им не приходится объяснять свои профессиональные термины, и они гораздо проще договариваются. Один из них берет задачу, тратит на нее 6 часов. И проблема решена. Для наглядности прикреплю таблицу

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

Добавляем тривиальности

Но ведь в «эффекте велосипедного сарая» говорилось о тривиальности проблем. Так давайте расширим пример для большей наглядности.

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

И вот, у нас на встрече 7 человек, из которых только 2 человека разбираются в бэкенде. Вероятнее всего, 80% времени будет обсуждаться тема первоначальной загрузки сайта, потому что тут свои предложения могут вбросить и дизайнеры, и СЕО, да и фронтендеры, потому что им в итоге выполнять задачу. По итогу: всем будет труднее договориться, задача опять может быть разбита на длинную последовательную работу, а до производительности API никто и не дойдет.

Для наглядности опять попробуем построить таблицу, но предсказать результат здесь будет уже сложнее. Возьмем общий X для обеих ситуаций.

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

А как в итоге правильно то?

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

• Поймите минимальное количество людей, необходимых для решения проблемы. Позовите только их. Если будет не достаточно — сделайте summary встречи и отправьте другому человеку, которого хотели пригласить.
• Чем короче встречи — тем эффективнее. Но не забывайте про адекватность. Миграцию продукта на другой стек даже 2 фронтендера не успеют обсудить за 10 минут.
• Готовьтесь к встречам. Не делайте так, что на встречах все остальные люди сидят и смотрят, как вы исследуете проблему в прямом эфире. Каждый человек должен подготовиться к встрече и выписать свои тезисы заранее.
• Если получается так, что нужно обсудить несколько проблем — нужно добавить тайм-блоки на обсуждение каждой проблемы. Если не сделать это заранее — большинство обсуждения пройдет за легкой темой.
• Попробуйте решать проблемы асинхронно. Здесь могут подойти любые мессенджеры, но наилучшим вариантом будет почта. Через почту люди стараются формулировать мысль наиболее полно и не отправляют по 20 сообщений с редактированиями, must have
• Сделайте себе плагин, который будет писать стоимость встречи, как на скриншоте ниже 😎

Ну и подписывайтесь на мой телеграм, я буду делиться советами о продуктивности и качественной командой работе и дальше. Успехов!

Привет! Уже почти 3 месяца я постоянно изучаю тему, которая не даёт покоя каждому "темщику" в сети, а именно – арбитраж.

За 3 месяца экспериментов я успел:

• написать бота для автоматического арбитража
• сделать парсер любой возможности поарбитражить между DEX и CEX
• потерять много денег после введения сжигания токенов на Terra Classic
• полезть в сендвич атаки и арбитраж в одном чейне и потерять деньги и там
• сделать свой клон Via Protocol и написать интеграции для 4 мостов

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

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

Знакомьтесь, Опен

Опен – уникален. Он обыгрывал чемпионов мира OG в доту, после этого долго занимался рисованием картин, а в свободное время "таксует для души".

Погнали 🚀

Insuline: Привет. Я изучаю треугольный арбитраж на крипте. Ты слышал что-нибудь об этом?

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

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

Insuline: А что сложного в сложности расчетов? Ты пробовал написать формулы?

Open: Да. Я писал имплементацию на JavaScript.

Чтобы реализовать алгоритм треугольного арбитража на JavaScript, необходимо иметь доступ к рыночным данным в реальном времени по различным валютам, которыми вы заинтересованы торговать, а также возможность быстрого и эффективного исполнения сделок. Ты можешь использовать библиотеку ccxt для доступа к рыночным данным, ethers – для совершения сделок, а для выполнения необходимых расчетов - математическую библиотеку, например math.js. Вам также потребуется хорошее понимание основ треугольного арбитража и потенциальных рисков и проблем, связанных с реализацией этого типа торговой стратегии.

Insuline: Забыл рассказать – я работаю в Via.exchange, поэтому доступы к множеству курсов на разных блокчейнах у меня есть. Но как дальше их считать?

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

Потенциальная прибыль = (Курс обмена 1 * Курс обмена 2 * Курс обмена 3) - (Курс обмена 1 * Комиссия 1) - (Курс обмена 2 * Комиссия 2) - (Курс обмена 3 * Комиссия 3)

Здесь "Курс обмена 1" - это курс обмена между первой и второй валютами, "Курс обмена 2" - это курс обмена между второй и третьей валютами, а "Курс обмена 3" - это курс обмена между третьей и первой валютами. "Комиссия 1" - это комиссия, связанная с первой сделкой, "Комиссия 2" - это комиссия, связанная со второй сделкой, а "Комиссия 3" - это комиссия, связанная с третьей сделкой.

Insuline: Хм. Ну звучит не сложно, а какие тут подводные камни?

Open: При торговле с использованием стратегии треугольного арбитража необходимо знать о нескольких потенциальных подводных камнях.

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

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

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

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

Insuline: Блин, жестко это. А как еще можно арбитражить?

Open: Существует несколько других способов арбитража криптовалют, помимо треугольного арбитража.

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

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

Insuline: Я слышал про межбиржевой арбитраж, но не хочется связываться с биржами, потому что высокий риск блокировок и так далее. Пример с GALA хорошо это продемонстрировал, хотя в чатиках я видел success кейсы. Наверное тут еще можно добавить p2p арбитраж, да?

Open: Это может быть рискованная стратегия, поскольку биржи могут блокировать или отменять арбитражные сделки, если заподозрят, что трейдер занимается арбитражной деятельностью. P2P-арбитраж, с другой стороны, предполагает использование разницы в ценах между различными платформами peer-to-peer (P2P), где пользователи могут покупать и продавать криптовалюты напрямую друг с другом, без участия центральной биржи. Это может быть менее рискованным способом арбитража, поскольку P2P-платформы обычно имеют меньше ограничений на арбитражную деятельность. Однако P2P-арбитраж может быть и сложным, поскольку он требует от трейдера найти желающих покупателей и продавцов на нескольких P2P-платформах и скоординировать торговлю таким образом, чтобы все стороны остались довольны.

Insuline: Так, ну и последняя сфера арбитража, про которую я знаю – это арбитраж фандинга. Что насчет него?

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

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

Insuline: Ладно, про фандинг нам расскажет Гасерд. Но в общем, опять трейдинг 🥲

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

Open: Существует множество потенциальных возможностей для разработчиков получать дополнительный доход в сфере децентрализованных финансов (DeFi).

Например, разработчики могут создавать и внедрять смарт-контракты на платформах блокчейн, таких как Ethereum, для создания новых финансовых продуктов и услуг. Среди них могут быть децентрализованные биржи, платформы кредитования и заимствования, стабильные монеты, рынки предсказаний и другие. Разработчики также могут создавать и продавать пользовательские инструменты и услуги, которые помогут другим пользователям DeFi, например, арбитражные боты, инструменты управления портфелем и аналитические платформы.

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

Insuline: Является ли Ethereum будущим или ты знаешь другие интересные блокчейны?

Open: Трудно предсказать будущее любого конкретного блокчейна, включая Ethereum.

В настоящее время Ethereum является одной из наиболее широко используемых блокчейн-платформ и сыграл ключевую роль в развитии экосистемы децентрализованных финансов (DeFi). Однако сфера блокчейна очень динамична и конкурентна, и в будущем могут появиться другие платформы, предлагающие иные функции и возможности. Примерами других блокчейн-платформ, набирающих обороты в сфере DeFi, являются Solana, Binance Smart Chain и Polygon. Эти платформы имеют различные характеристики и возможности, которые могут сделать их более подходящими для определенных случаев использования или приложений. Стоит также отметить, что, хотя технология блокчейн имеет множество потенциальных преимуществ и применений, она все еще является новой и развивающейся технологией, и существует множество проблем и ограничений, которые необходимо решить для того, чтобы она полностью раскрыла свой потенциал.

Insuline: А что будет с Layer 2? В чем преимущество таких сетей перед форками Ethereum, такими как binance smart chain?

Open: Сети второго уровня - это блокчейн-сети, которые строятся поверх существующих блокчейн-платформ, таких как Ethereum, и предназначены для улучшения масштабируемости и производительности базовой платформы. Сети второго уровня используют различные методы, такие как внецепочечные транзакции и каналы состояния, чтобы обеспечить более высокую пропускную способность транзакций и более низкие комиссии за транзакции по сравнению с базовой платформой. Преимущество сетей второго уровня перед форками Ethereum, такими как Binance Smart Chain, заключается в том, что они более тесно интегрированы с базовой платформой и поэтому могут использовать преимущества существующей инфраструктуры, безопасности и экосистемы разработчиков. Кроме того, сети второго уровня часто могут быть более гибкими и настраиваемыми, чем форки Ethereum, поскольку их можно адаптировать под конкретные случаи использования и приложения. Однако компромисс заключается в том, что сети второго уровня не могут предложить такой же уровень независимости и контроля, как форки Ethereum, поскольку они по-прежнему в конечном итоге зависят от базовой платформы.

Insuline: Хорошо, спасибо! Мы пошли билдить, если что – еще спишемся с тобой 😎

Навал сделал твиттер тред с коллегой, потом эта идея перетекла в 4 часовой подкаст, а в итоге активно распространяется в версии книги. На русском тоже :)

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

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

Хочу рассказать, как навык программирования помогает мне в моей бытовой жизни :)

1. Алгоритмы

Первое, что отлично помогает в быту — это умение строить в голове алгоритмы (я не о душном переборе деревьев)

К примеру, когда у меня есть какая-то бытовая задача — я представляю в голове все условия (if else), которые могут вызывать трудности. Дальше уже можно построить пошаговый план решения задачи, по необходимости записать его, и приступить к решению.

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

2. Гугл

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

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

Тема может быть любой, к примеру можно попробовать найти и собрать полный список документов на визу. Или найти возможность оплатить заказ на Amazon с помощью русских карт.

В какой-то момент для меня это стало инсайтом 💡


3. DeFi. Мы же всё-таки Web 3.0 бояре

Сложно рассказывать в канале о крипте и не упомянуть в этой статье DeFi.

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

Если вы NFT флиппер — вы легко можете научиться писать базовые скрипты на регистрации аккаунтов. Сможете разобраться, как минтить через смарт-контракты и находить бэкдоры, как Терн или Нифолеко.

Если вы просто инвестируете в крипту — для вас точно будет интересно разобраться в том, как написать смарт-контракт, который реинвестирует прибыль в стейкинг. Или же написать ончейн торгового бота, который будет работать с контрактами 1inch 👀

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

Ах да, в крипте же очень много скама. И даже бейджик Audited by Certik не должен усыплять вашу бдительность. Научитесь анализировать смарт-контракты, лезьте в код и изучайте проекты.

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

Ну, а если вы просто хотите зарабатывать деньги — пойдите в Web 3.0 фронтенд, благо я уже рассказывал о том, как сделать это с пошаговыми инструкциями :)

4. Автоматизация

Ну и last, but not least, это автоматизация.

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

Расскажу, что делал я:
— Веб-сайт для записи показателей по диабету через Firebase
— Платформа, чтобы играть с другом в шахматы
— Туду-лист в Notion с интеграцией через Telegram бота
— Делал 5 итераций своего сервиса для учёта финансов. Финальное решение было через No-Code с помощью Integromat, но была и база в Firebase, 3 версии разных фронтендов.
— Бот для тимлидов Связного, который строил доску из Forwarded сообщений (способ борьбы с дырявым стеком)
— На этой неделе сделал Телеграм бота, который рассчитывает оптимальные размеры позиций в трейдинге с учетом риска и общего депозита по [формуле Келли]

Любые автоматизации позволяют вам перестать полагаться на свою память, освободить свое драгоценное время для дел, которые не подвергаются автоматизации. По крайней мере, я пока не придумал как написать скрипт, который проводит время с девушкой или выполняет упражнения за меня 👀

Happy coding ✨

1. Витамин D-3. Синтезируется только на солнце, поэтому 90% людей имеет его хронический недостаток. Поддерживает опорно-двигательный аппарат (за счет регуляции уровня калия и фосфора), укрепляет кости, улучшает состояние кожи. Влияет на все системы организма, включая гены, иммунную, сердечно-сосудистую и гормональную и даже сперматогенез. Коррелирует с тестостероном, настроением и инсулинорезистентностью.

Способ приема: весной и зимой - 5.000-10.000 в сутки, летом и осенью - 5.000. Если нет солнца в регионе - можно все время 8.000. В любое время суток, неплохая идея принимать на ночь (т.к. во сне происходят гормональные изменения).

2. Витамин К-2.Синергетик для витамина D-3, поэтому принимаем их ВМЕСТЕ в ОДИН ПРИЕМ. Помогает правильно усваивать кальций, участвует в регуляции свертываемости крови, поддерживает иммунитет, нервную систему и мозговую активность.

Способ приема: вместе с витамином Д-3, очень желательно с приемом пищи, содержащей полезные жиры (например, бутерброд с кокосовым маслом). Дозировка: 200 мкг/сутки.

3. Цинка хелат. Хелатная форма цинка - лучшая форма с точки зрения усвоения организмом, сам цинк стимулирует повышение уровня тестостерона, укрепляет волосы (в том числе «пушок» на бороде становится темнее), ногти; является мощным антиоксидантом, предельно важен нашему организму для качественного синтеза белка.

Способ приема: 25-30 мг в сутки. НЕДЕЛЯ ЧЕРЕЗ НЕДЕЛЮ, если не ведете активную половую жизнь. Минералы быстро накапливаются организмом, поэтому неделя через неделю - оптимально.

4. Kelp. Недостаток йода имеет примерно 35% населения земного шара и большинство жителей городов отдаленных от моря. Его недостаток приводит к проблемам с щитовидной железой (очень распространено у нас), с метаболизмом и ухудшению выработки гормонов организмом. Лучше всего не жлобить денег и сдать анализ на уровень йода (он недорогой), поскольку в избыточных количествах может быть токсичным для организма и сделает только хуже. Это важный момент!

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

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

Способ приема: 10 грамм в сутки. Делаете бутерброды с хлебцами или салат с морковкой и едите. Оно к тому же очень вкусное. Можете запивать гранатовым соком, метаболизм будет благодарить вас.
p.s. но есть еще крутой способ приема масла, о котором будут знать только камрады 2 и 3 ступеней.

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

Способ приема: 2 таблетки по 600 мг в сутки. Можно поднимать до 3, если собственный вес большой (85+ кг). Если жалко денег на NAC, для здоровья сердца купите хотя бы фолиевую кислоту, вам одной банки хватит на полгода/плюс, а стоит она дешевле Биг Тейсти!

7. Витамин С. Это здоровье связок, суставов, иммунитет. Недостаток приводит к быстрой утомляемости и старению кожи. Ускоряет заживление организма, улучшает работы печени и надпочечников (еще одна проблема 21 века - истощение надпочечников).

Способ приема: 1000 мг 1-2 раза в день. Когда заболели можно закидывать больше (сюда же и овердозировки витамина Д и цинка, на западе это сейчас популярная практика при симптоматике ОРВИ, короны и прочего дерьма; да и до нас эта практика дошла).

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

Способ приема: 1-3 капсулы в день. Можно курсом пропить 3 (если знаете, что печень барахлит), а потом для профилактики по 1.

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

Способ приема: 1000-2000 мг в сутки. Таблетку перед тренировкой, таблетку перед сном. Выпить воды (чтоб разогнать кровь). Очень круто совмещать с физ активностью и приемом горячей ванны/баней. Тогда эффект будет еще круче.

10. DMAE. Позаботились о печени, сердце, крови, гормоналке, время и мозге подумать! DMAE, по сути, натуральный ноотроп, не вызывающий феномена отмены/отката. Его можно безопасно принимать ВСЕГДА. Повышает концентрацию, улучшает память, улучшает умственные способности и положительно воздействует на иные системы организма.

Способ приема: 250 мг перед началом рабочего дня. Если не почувствовали - 250 мг в два приема, т.е. 500 в день. В корзине будет с содержанием 130 мг вещества, поэтому можно пить до 3 капсул!

11. Селен. Каждый cедьмой житель земли испытывает дефицит селена, чаще всего встречается при болезнях ЖКТ, являясь или их причиной или следствием. Или и тем, и тем вместе. В общем-то, для тех у кого проблемы с пищеваром - мастхэв. Создает защиту от злокачественных опухолей (по данным ученых, снижает вероятность рака в 7 РАЗ).

Способ приема: 1 таблетка в сутки вместе с витамином С. Неделя через неделю, банки хватит на год!

В завершение

Этого набора для НОВИЧКА более чем достаточно. Как видите, здесь мы минимально затронули все системы организма, более подробно мы будем рассматривать их далее. Если есть возможность, то самым грамотным решением будет сдать анализы на минералы и витамины перед их употреблением.

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

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

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

Вот ссылка на полную корзину добавок на iHerb, открываете ее и заказываете!

КОРЗИНА ДОБАВОК (кликабельно)

Но со временем требуемый функционал изменяется. Если раньше мне было достаточно Emmet (встроен в редактор) и CSS IntelliSense, то сейчас в задачах основная работа происходит с .js (.ts) и .vue файлами, в которых нужны функционалы авто-импортов, умных автокомплитов с аннотациями типов и возможностями рефакторинга кода. И тут я задумался о смене рабочего инструмента 👀

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

Процесс перехода

После установки WebStorm сразу установил в настройках Keymap из VSCode, так как к хоткеям я уже полностью привык и переучивать хоткеи заняло бы продолжительное время.

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

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

В принципе, часа на настройку мне хватило чтобы комфортно приступить к работе и 14 дней я вообще не открывал VSCode (ну почти) и выполнял все задачи в WebStorm.

Преимущества WebStorm

1. Автодополнение в процессе набора кода

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

2. Умный рефакторинг

Для второго шага не стану прикладывать видео-подтверждения, но поверьте, что автоматический рефакторинг импортов при изменении названия файла в VSCode либо работает криво, либо не работает совсем 🤷‍♂️

А вот, что действительно порадовало в WebStorm, так это возможность автоматического рефакторинга кода в проекте с отключенными линтерами через Reformat Code. И этот процесс доставляет эстетическое удовольствие. Даже грамотно настроенный ESLint в проекте не будет автоматически расставлять импорты в алфавитном порядке, оптимизировать пути до файлов через относительные пути (через alias) (поправьте в комментариях, если знаете решение)

3. Отсутствие необходимости делать настройки под проект

Огромный плюс WebStorm – его автоматический анализ проекта. IDE понимает в какой директории я работаю и позволяет автоматически применять правила из eslint, webpack, stylelint, jsconfig файлов.

Для примера, работая над проектом с структурой, в которой eslint, stylelint конфиги расположены не в корне – VSCode не сможет их правильно обработать, следовательно работать линтеры не будут 😕 (пока не настроишь пути до конфигов вручную в настройках workspace)

4. Работа с Git

Обычно работу с Git-ом преподносят как удобство продуктов JetBrains над остальными, но я с этим не соглашусь. Расширение GitLense прекрасно дополняет VSCode и позволяет удобно работать с Git-ом. Видеть автора изменений в коде без нажатия дополнительных хоткеев, выборочно коммитить файлы, интерактивное разрешение merge conflicts – весь этот функционал прекрасно работает.

Хотя не буду спорить, что когда я первый раз увидел, как решаются merge conflicts в продуктах JetBrains – немного расстроился, что такого нет в моём редакторе, но уже привык работать со своим интерфейсом.

Результат эксперимента по переходу

Я ставил для себя эксперимент сроком на 14 дней, в рамках которого я не пользовался Visual Studio, но после этого времени подошёл процесс выбора инструмента и я... вернулся обратно.

Но почему?

VSCode быстрее и потребляет меньшее количество ресурсов. В моём случае (я работаю на 8ГБ оперативной памяти) это оказалось очень заметно. Первый процесс запуска проекта, вечные индексации и оперативная память на моём компьютере была полностью забита. Всё же, большинством функций в шторме я так и не воспользовался, а некоторые, требуемые для меня вещи, я так и не смог найти. VSCode расширяем и всегда можно найти необходимое расширение для решения проблемы, а в крайнем случае – написать самому 🙃

Для себя я выделил определённый стэк задач, в которых мне будет удобен WebStorm и ради которых я буду его запускать, но основной рабочий процесс я все-таки продолжу выполнять в VSCode. 3 года, потраченные на настройку и кастомизацию редактора под себя, позволяют решать большинство задач не задумываясь над сложностями, поскольку подобраны оптимальные хоткеи и расширения.

Вывод же из этого эксперимента такой: Выбирайте свой инструмент исходя из ваших необходимостей и ресурсов. Не надо гнаться за самыми современными решениями, так как не всегда профит от них будет вам полезен. Не слушайте людей, которые "принуждают" вас перейти на WebStorm, потому что он круче. Есть люди, которые до сих пор пользуются Sublime Text и от этого их продуктивность не страдает. Другой тип людей будет пользоваться vim-ом и говорить, что ничего удобнее до сих пор не придумали, но из-за нескольких примеров удобства данного инструмента вы можете приобрести кучу неудобств.

Для примера, это Twitter, Instagram, Clubhouse, Telegram и т.д.

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

Так вот, почему бы не превратить наш Github в мини-портфолио? Страница нашего профиля будет включать в себя некоторые, по нашему мнению, важные пункты о нас, как о разработчике, и превью к профилю.

Тем более, что Github в середине 2020 года зарелизили такой функционал.

Сначала об ограничениях

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

Но что, если мы хотим реализовать динамичность в наших данных? Получать какие-то данные из API, обновлять информацию автоматически?

На помощь приходят Github Actions. Это пайплайны, которые позволяют разработчику автоматизировать процессы и задачи. В первой ревизии нашего портфолио мы обойдёмся статическим контентом, но после появления веб-интерфейса моего Telegram канала Вёрстка жизни, я сделаю Github Action для автоматического добавления последних статей в моё README и опишу этот процесс отдельной статьёй 💁‍♂️

Приступим к созданию репозитория

Первое, что нужно сделать – создать репозиторий, название которого совпадает с Вашим логином на Github. https://github.com/new

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

Добавляем баннер

Дисклеймер: дальнейшую идею оформления профиля я взял у Braydon Coyer. Так же, другие примеры вы можете посмотреть на проекте Awesome Github Profiles. Я понимаю, что копировать – плохо, поэтому если Braydon Coyer напишет мне по любому из контактов в профиле – я заменю стартовый баннер на другой :)

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

В корне репозитория добавляем директорию assets, в которой будут храниться все дополнительно требуемые ресурсы. В самом README.md указываем путь до изображения ![GitHub Header Banner](./assets/github-header.png)

Коммитим.

Добавляем бейджи других соц. сетей

Следующее, что я хочу сделать – указать контактные данные для связи со мной помимо стандартной почты в Github профиле.

Для генерации бейджей воспользуемся Shields.io

Я сделаю бейджи Instagram, Telegram, а так же счетчик посещений профиля.

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

[![Instagram Badge](https://img.shields.io/badge/instagram-%23C44569.svg?&style=for-the-badge&logo=instagram&logoColor=white)](https://www.instagram.com/elinoril1337/)

Делаем остальные, коммитим!

Делаем блок с последними публикациями

Это тот самый блок, который в дальнейшем будет автоматизирован с помощью Github Actions. Но я хочу привлечь внимание к своим переведённым и написанным статьям уже прямо сейчас, поэтому пока сделаем этот блок статическим.

Делаем блок в виде обычного списка с ссылками.

## Последние посты 👀

– [Превращаем Github профиль в портфолио](https://teletype.in/@life_verstka/github-profile-to-portfolio)

– [6 полезных паттернов во Vue](https://teletype.in/@life_verstka/6_vue_2_patterns)

– [Хотите сделать анимацию на сайте? Расскажу, как сделать это правильно](https://teletype.in/@life_verstka/good_css_animations)

Коммитим!

Секция с навыками

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

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

Сделаем две секции – первая, в которой вы указываете активно используемые технологии. А уже во второй можно написать все инструменты, с которыми вы работали за свою карьеру. Но вторую часть мы не будем показывать всегда, а выделим в отдельный спойлер, который Markdown позволяет делать, за счёт своей привязанности к HTML.

Полный код данной секции можно посмотреть в коммите, а здесь покажу с помощью чего мы реализуем выпадающую секцию

<details>

<summary>Все навыки </summary>

<!-- Здесь скрытый по умолчанию контент -->

</details>

Коммитим изменения!

Заключение

Теперь, после того как описаны все основные секции, можно сделать репозиторий публичным. Мини-портфолио готово и в дальнейшем его можно улучшать и дополнять. Вы можете прикрутить статистику вашего профиля через Github Readme Stats. Можете выделить ваши самые достойные работы в отдельный блок либо сгенерировать какой-то контент и сделать его динамическим через Github Actions.

Спасибо за прочтение!

Ещё больше контента по разработке, дизайну в моём Telegram канале по разработке – Вёрстка Жизни (life_verstka). Удачи!

1. Управление состоянием загрузки

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

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

const AsyncComponent = () => ({
// Загружаемый компонент (должен быть Promise)
component: import('./MyComponent.vue'),
// Компонент, используемый во время загрузки необходимого
loading: LoadingComponent,
// Данный компонент отображается в том случае, если загрузка завершилась ошибкой
error: ErrorComponent,
// Задержка перед отображением loading компонента. По умолчанию 200мс.
delay: 200,
// Компонент error будет отображен, если таймаут существует и превышен. По умолчанию отсутствует.
timeout: 3000
})

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

2. «Дешёвые» статические компоненты с помощью v-once

Рендеринг простых HTML-элементов очень быстр во Vue, но иногда у вас может быть компонент, который содержит большое количество статического контента. В этих случаях вы можете убедиться, что он вычисляется только один раз, а затем кэшируется, добавив директиву v-once к корневому элементу.

Пример кода:

Vue.component('terms-of-service', {
template:
<div v-once>
<h1>Правила использования</h1>
... огромное полотно статического контента ...
</div>
})

3. Рекурсия в компонентах

Компоненты могут рекурсивно вызывать себя в своём собственном шаблоне. Единственное НО, они могут сделать это только, если имеют параметр name.

Если не быть осторожным, рекурсивные компоненты также могут привести к бесконечным циклам:

name: 'stack-overflow',
template: '<div><stack-overflow></stack-overflow></div>'

Компонент из примера выше, приведет к ошибке «Max stack size exceeded», поэтому убедитесь, что рекурсивный вызов является условным (т. е. использует v-if, который в конечном счёте окажется в значении false)

4. Динамические аргументы директивы.

Аргументы директивы могут быть динамическими. Например, в v-mydirective:[аргумент]="значение", аргумент может быть обновлен на основе свойств данных в нашем экземпляре компонента! Это делает наши пользовательские директивы гибкими для использования во всем нашем приложении.
Вот директива, где динамический аргумент может быть обновлен для каждого экземпляра компонента:

<div id="dynamicexample">
<h3>Scroll down inside this section ↓</h3>
<p v-pin:[direction]="200">I am pinned onto the page at 200px to the left.</p>
</div>
Vue.directive('pin', {
bind: function (el, binding, vnode) {
el.style.position = 'fixed'
var s = (binding.arg == 'left' ? 'left' : 'top')
el.style[s] = binding.value + 'px'
}
})

new Vue({
el: '#dynamicexample',
data: function () {
return {
direction: 'left'
}
}
})

5. События и модификаторы клавиш

Для .passive, .capture, .once Vue предлагает префиксы, которые могут быть использованы с on:

Пример:

on: {
'!click': this.doThisInCapturingMode,
'keyup': this.doThisOnce,
'!mouseover': this.doThisOnceInCapturingMode
}

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

6. Внедрение зависимостей (Provide/Inject)

Есть несколько способов заставить два компонента общаться в Vue с преимуществами и недостатками в каждом из них. Новый способ, введенный в версию 2.2 — это использование внедрения зависимостей с помощью Provide/Inject.

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

Пример:

// родитель передает 'foo'
const Provider = {
provide: {
foo: 'bar'
},
// ...
}

// дочерний компонент получает 'foo'
const Child = {
inject: ['foo'],
created () {
console.log(this.foo) // => "bar"
}
// ...
}

Заключение

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

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

Источник

Цель статьи: рассказать разработчикам, собирающимся работать с анимациями, о том, что не обязательно использовать какие-то специальные JS библиотеки, которые волшебным образом решают проблемы с анимацией. По большей части, можно полностью обходиться современными возможностями браузеров, такими как GPU Rendering и CSS3 Spec.

В разработке анимаций нет «идеального решения», кроме того приходится тратить часть времени на их тестирование и оптимизацию. Но за продолжительное время работы с ними был придуман ряд принципов дизайна и разработки, которые, ИМХО, приводят к хорошим анимациям. Эти методы позволят вам получить на странице гладкое поведение, обеспечить работу во всех современных браузерах (конечно, мобильных и десктопных), и — самое главное — простых в поддержке.

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

Что же такое анимация?

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

Для плавной 60 fps картинки каждый кадр должен быть отрендерен менее, чем за 16 мс. Это не большое количество времени, поэтому нужно искать эффективные способы рендеринга каждого кадра для «гладкой» картинки.

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

Таким подходом пользуется Apple на своих промо-страницах.

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

Да, такой эффект можно повторить CSS-анимациями множеством крошечных элементов, либо SVG анимациями, но это было бы неоправданно сложным и, вполне вероятно, не так гладко бы выглядело.

В большинстве случаев, вы захотите использовать CSS переходы для автоматической анимации элемента при его изменении. Эта техника называется «tweening» — переход между двумя элементами (beTWEEN). Преимущество данного подхода в том, что он легко отменяется или возвращается без необходимости строить логику. Это идеально подходит для анимаций в стиле «сделал и забыл». Например, для появления секций или простых взаимодействий, как hover и т. д.

Дополнительное чтение: Все, что вы должны знать о CSS анимациях.

В других случаях keyframe-based анимации могут стать идеальным решением для непрерывной работы деталей фона. Например, вращающийся loader.

Итак, вот несколько советов, которые должны улучшить производительность ваших анимаций:

1. Не меняйте никаких свойств, кроме opacity и transform

Даже если ты думаешь, что это нормально – не надо :)

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

Это правило довольно просто выполняется и как только вы привыкнете к этому, то даже перестанете задумываться. Например, если вы хотите уменьшить размер элемента – не надо трогать его width и height, когда можно использовать transform: scale(). А если вдруг вы хотите передвинуть элемент – вполне можно обойтись без изменения марджинов тем же трансформом.

Почему это работает?

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

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

Дополнительное чтение: Передвигайте элементы через translate (Paul Irish)

2. Скрывайте содержимое правильно

Используйте pointer-events: none, когда убираете прозрачность у элементов.

Давным-давно, когда анимации делали через jQuery animate(), большая часть проблем была связана с кликабельностью элементов во время анимаций, так как все анимации были завязаны на изменении opacity и дальнейшем display: none у элементов. В итоге из-за рассинхронизации, на страницах был момент, когда есть большой пустой (прозрачный) кликабельный блок при анимации скрытия/появления элемента. А после каждой анимации приходилось делать колбек.

CSS-свойство pointer-events в основном используется для того, чтобы элемент переставал реагировать на клики или любые другие взаимодействия. Его легко можно включить/выключить с помощью CSS, не прерывая анимацию и не влияя на рендеринг элемента. Это прекрасно работает с абсолютно позиционированными элементами, потому что вы можете быть уверены, что они не оказывает абсолютно никакого влияния на странице.

3. Не анимируйте все единовременно

Лучше постройте композицию.

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

Лучше всего распределить время так, чтобы одновременно не выполнялось более 3 анимаций на сайте. Если на вашей странице не одна анимация – стоит задуматься над их композицией. Хоть, каждая анимация – это отдельный элемент, вместе они образуют систему. И у любого элемента система должно быть своё направление и своё время исполнения, чтобы не ломать остальное.

В Material Design гайдах от Гугла концепция правильно выстроенных анимаций называется хореографией, хоть это и танцевальный термин.

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

Дополнительное чтение: Material Design – Motion.

4. Незначительные задержки перехода улучшают общую композицию анимаций

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

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

Пример кода

Есть пара простых приёмов для анимации серии элементов – особенно если это список. Если в нём статическое количество элементов, то можно обойтись всего лишь SASS миксином.

@for $i from 1 through 7 {
&:nth-child(#{$i}) {
.loaded & {
.text {
transition-delay: 500 + (42ms * $i);
}
}
}
}

Для длинных списков или динамического контента, тайминги можно устанавливать с помощью JS и таких же циклов по каждому элементу.

const baseDelay = 350
const randomDelay = 64
document.querySelectorAll('.reports li').forEach((item, index) => {
setTimeout(() => {
item.classList.add('showing')
}, baseDelay + randomDelay * index)
})

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

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

Но не забывайте после этого обратно ускорить :)

В разработке анимаций правильно подобранное время – это всё. Лишь 20% времени вы будете что-то создавать и реализовывать, а оставшиеся 80% будут заключаться в поиске правильных параметров и анимаций, чтобы все анимации были синхронизированы и плавными.

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

Вне зависимости от синтаксиса написания ваших анимаций (CSS, SASS, JS) это не так тяжело реализовать с помощью небольшой помощи математики и использования переменных.

Например, если анимация имеет подвисания даже на скорости в 10x раз меньше, то возможно вы делаете что-то не так. Если же при замедлении в 50x раз анимация идёт плавно, то остаешься лишь определить максимальную скорость, при которой она будет работать. Может быть трудно заметить проблемы в производительности на полной скорости, но если вы замедлите все анимации, то проблемы становятся очевидными.

6. Сетевые запросы могут вызывать лаги

Поэтому не забывайте о предзагрузке данных или откладывайте большие HTTP запросы

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

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

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

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

На страницах с большим количеством контента работа по загрузке этих данных может быть очень требовательной. Анимация, которая хорошо работает с статическим контентом, может начать разваливаться если в неё загружать динамические данные. Если вам кажется, что анимация должна работать, а стабильно работает она не всегда – я бы посоветовал проверить во время выполнения вкладку Network в браузере, чтобы убедиться, что вы не занимаетесь загрузкой данных и другой сложной работой в браузере в это время.

7. Не привязывайте анимацию напрямую к скроллу

Вроде идея звучит круто, но это не совсем так

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

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

Худшим вариантом является создание собственного функционала скролла. Так называемый scrolljacking. Пожалуйста, не делайте этого на своих сайтах.

Это одно из тех правил, которые особенно полезны на мобильных устройствах. Так же, кастомный скролл – это анти user experience паттерн.

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

Дополнительное чтение: Scrolljacking – кошмар для вашего UX

8. Проверяйте на мобильных как можно раньше и чаще

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

Однако, при правильной разработке и оптимизации (см. 1 пункт) работа на мобильных устройствах может быть даже более плавной, чем на компьютере. Когда-то мобильная оптимизация была очень сложной задачей, но теперь новые iPhone работают быстрее, чем большинство ноутбуков! Если вы следовали всем предыдущим советам, то вполне возможно, что у вас сразу же появится отличная мобильная производительность.

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

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

9. Тестируйте на разных устройствах

Размер экрана, плотность и устройство могут иметь большое значение

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

Несмотря на то, что Chrome, Safari и Edge являются браузерами на основе Webkit с аналогичным синтаксом, у каждого из них есть свои особенности.

Каждое обновление Chrome может что-то исправить и внести новые ошибки, поэтому нужно постоянно следить за изменениями.

Я регулярно переключаюсь между своим настольным ПК на Windows 10, рабочим Macbook Pro и iPad с iPhone. Каждый цикл переключения по своим сайтам может выявить проблемы и улучшения, которые необходимо внести – часто это производительность оптимизации, но также это могут быть общий дизайн сайта, шрифты, плотность информации и т.д.

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

Источник

Надеюсь, что эти техники будут полезны вам в разработке ваших следующих проектов, а так же в поддержке текущих. Ещё больше контента по разработке, дизайну в моём авторском Telegram канале по разработке – Вёрстка Жизни (life_verstka). Удачи!