В этой статье описан личный опыт двух человек: меня и моей коллеги Марии. Опыт людей, у которых совершенно не было знаний в SEO. Во второй половине 2019 года на нас легла ноша в виде продвижения 2-х сайтов проекта Ratatype. Сайтов молодых (рождены в 2019) и на иностранный рынок, языков которого мы не знаем (Франция и Испания), да еще и с очень ограниченным бюджетом.

Что вы найдете в этой статье:

1. Реальный кейс, который работал, работает и будет работать.
2. Пошаговую инструкцию «Что? Зачем? Как?» на простом языке.
3. Описание провалов, куда ж без них.
4. Что-то интересное на рынке SEO, но это не точно.

Чего вы здесь не найдете:

1. Трендов 2020, 2021 или любого другого года.
2. Мнений экспертов.
3. Предложения услуг продвижения.

Если все устраивает — прошу, следуйте ниже по тексту.

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

Окружение и ограничения

Игровое окружение состоит из полигонов. Большинство полигонов блокирует движение, область видимости и стрельбу, однако есть и «низкие» полигоны, только блокирующие движение. Окружение плотно заставлено препятствиями и укрытиями.

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

Представляем вам перевод статьи Simon Holdorf, опубликованной на сайте medium.com. В ней вы найдете ссылки на полезные репозитории, с помощью которых можно прокачать навык разработки ПО.


Фото с ресурса Unsplash. Автор: Vishnu R Nair

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

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

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

Ядро LXD — это привилегированный демон (сервис запущенный с правами root), который предоставляет REST API через локальный unix сокет, а также через сеть, если установлена соответствующая конфигурация. Клиенты, такие как инструмент командной строки поставляемый с LXD посылают запросы через этот REST API. Это означает, что независимо от того, обращаетесь ли вы к локальному хосту или к удаленному, все работает одинаково.

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

Cложность Web меняется ежедневно, и его возможности растут так же быстро, особенно с 3D-рендерингом. Кто только начинает вливаться в тему 3D — добро пожаловать под кат.

Введение

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

"Алготрейдер спит — торговля идет!" — любят говорить некоторые трейдеры. Но в реальности не все так просто. Как вы думаете с чего начинается алгоритмическая торговля? С подключения к бирже или написания алгоритма? Для профессионально участника трейдинг начинается с разработки риск-менеджмента.

Привет! Меня зовут Евгений, я Python-разработчик. Последние полтора года наша команда стала активно применять принципы Clean Architecture, уходя от классической модели MVC. И сегодня я расскажу о том, как мы к этому пришли, что нам это дает, и почему прямой перенос подходов из других ЯП не всегда является хорошим решением.

Автоматическое распознавание речи (STT или ASR) прошло долгий путь совершенствования и имеет довольно обширную историю. Расхожим мнением является то, что лишь огромные корпорации способны на создание более-менее работающих "общих" решений, которые будут показывать вменяемые метрики качества вне зависимости от источника данных (разные голоса, акценты, домены). Вот несколько основных причин данного заблуждения:

• Высокие требования к вычислительным мощностям;
• Большое количество данных, необходимых для обучения;
• В публикациях обычно пишут только про так называемые state-of-the-art решения, имеющие высокие показатели качества, но абсолютно непрактичные.

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

• Расскажем, что можно достигнуть отличного результата в рамках разумного времени, используя лишь две видеокарты NVIDIA GeForce 1080 Ti;
• На всякий случай еще раз представим датасет Open STT для русского языка на 20 000 часов;
• Опишем различные подходы, позволяющие ускорить процесс тренировки STT на порядок.

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

Как анализировать зависимости в IDEA с помощью Dependency Structure Matrix и других инструментов.

Этот перевод продолжает серию об IntelliJ IDEA:

• Лучшие плагины IntelliJ IDEA
• Сравнение файлов и папок
• Анализ зависимостей

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

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

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

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

Невольно хочется сказать: «Zed SEO is dead, baby». Но рано опускать руки. Не получается побороть — возглавьте. Рассказываем, как занять свое место на позиции №0 и перестать делиться трафиком с конкурентами.

Недавно мы с коллегами были на TeamLeadConf — это конференция об управлении, мотивации, найме, процессах и других штуках, полезных тимлидам.

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

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

Всем привет. Вместе с весной в OTUS пришли новые курсы, знакомить с которыми мы начинаем прямо сегодня. Уже сейчас открыт набор на курс «React.js разработчик». Подробнее о курсе можно узнать на бесплатном вебинаре, который пройдет 11 марта. В рамках этого же вебинара будет разработано небольшое веб-приложение на ReactJS.

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

---

Стартовый шаблон Create-react-app и Heroku — это прекрасные инструменты для быстрого создания работающих в облаке приложений, однако документация React и Heroku включает в себя на удивление немного информации о том, как все-таки выкатить свое React-приложение на Heroku. Описанные в этой статье шаги сработают на любом проекте, созданном с помощью create-react-app. В нашей статье мы задеплоим на Heroku простое todo-приложение с самым минимальным бекэндом, просто чтобы посмотреть на сам процесс. Но обо всем по порядку:

Всем привет!

Это третья статья о там, как я делаю небольшой и уютный сервис, который в теории должен помочь с планированием путешествий. В этой статье я расскажу про то, как предсказывать цены на авиабилеты, имея под рукой Clickhouse, Catboost и 1TB* данных.

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

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

Приготовьтесь написать клон сервиса по доставке еды deliveroo.co.uk используя современные технологии: Nuxt.js, GraphQL, Strapi и Stripe!

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

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

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

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

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

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

Правило #1: Организуйте стабильный доход

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

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

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

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



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

Материал, перевод которого мы сегодня публикуем, посвящён рассказу о 10 React-компонентах.

Привет, Хабр, меня зовут Вадим Макишвили. В 2014 году я выступил с докладом «36». Рассказывал про кризис среднего возраста, признавался в собственных слабостях и делился способами, которые помогли мне совладать со страхами. Сразу после выступления друзья стали надо мной подтрунивать, мол, давай каждые десять лет по продолжению. Я отшучивался, мол, обязательно сделаю. Но, вообще-то, не собирался, потому что каждые десять лет рассказывать всему миру про свои страхи — скучно.

Однако несколько месяцев назад на конференции YaTalks в Екатеринбурге я выступил с новым докладом. В заголовке число 42, и возникает вопрос: «Неужели Макишвили — автор одной темы?» Нет. Самокопания не было. А что было? И можно ли «42» считать продолжением «36»?

Мой рассказ имеет отношение к предыдущей лекции лишь косвенно. В «42» я детально обдумываю тему, которой тогда едва коснулся. Но если кому-то удобнее думать, что «42» — вторая серия, пусть так. Тогда впереди ещё и третья, которая не будет иметь ничего общего ни с первой, ни со второй, ну разве что автор — я, и название тоже окажется каким-то числом.

«42» — точно не про кризис среднего возраста.


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