Как научиться слепой печати на клавиатуре

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

• Хорошая техника позволяет сократить количество ошибок
• С опытом скорость набора текста станет выше
• При необходимости достаточно легко учатся новые алфавиты

Как это работает?

Слепой набор включает в себя несколько важных компонентов:

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

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

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

Наиболее эффективный набор в слепом режиме происходит когда пальцы постоянно чередуются. Попробуйте проверить это сами. Наберите слово "папа" указательным пальцем левой руки (эти буквы находятся в его зоне), а затем слово "гага" (указательные пальцы обоих рук).
Большинство раскладок проектировалось с учетом этого фактора, например, раскладка ЙЦУКЕН. А вот QWERTY создавалась слишком давно, когда приходилось учитывать другие факторы (например, залипание клавиш), и это отразилось на эффективности. Поэтому были созданы альтернативные раскладки, такие как DVORAK и Colemak. Вот что написано в Википедии по поводу последней:

• Скорость. Быстрее QWERTY и несколько быстрее Дворака, так как в Colemak разгружены мизинцы и чаще применяется чередование рук.
• Эргономичность. 10 наиболее распространённых букв английского языка и клавиша Backspace расположены на втором (домашнем) ряду клавиатуры. В Colemak домашний ряд используется в среднем на 3 % чаще, чем в раскладке Дворака, и 40 % чаще, чем в QWERTY. Благодаря этому при печати на Colemak пальцам приходится меньше перемещаться, чем при печати на QWERTY.

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

Как научиться?

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

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

Ссылки: Телеграм | Youtube | Подкаст

Чему можно научиться у миграций Rails

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

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

В большинстве фреймворков (в микрофреймворках это не так) этот механизм встроенный, но иногда идет как отдельная часть, как в spring boot.

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

Генерация

Rails это db first фреймворк (как. и большинство), то есть модели работают базируясь на структуре базы данных, а не база данных меняется под структуру как в entity framework или django. Поэтому миграцию нужно генерировать самостоятельно, фреймворк этого не сделает.

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

bin/rails generate model Product name:string description:text category:references

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

Автооткат

Сама миграция не содержит привычных up и down. Внутри нее только один метод change. Rails умеет автоматически откатывать почти все, но работает это если мы используем его dsl для описания миграции, чистый sql не подойдет

class CreateProducts < ActiveRecord::Migration[7.1]
  def change
    create_table :products do |t|
      t.string :name
      t.text :description

      t.timestamps
    end
  end
end

Если нужно всегда можно реализовать up и down отдельно

Схема

Вещь, которую после Rails внедрили многие фреймворки, например, Laravel (но сделано это довольно хреново). После того как накатывается миграция, rails автоматически обновляет файлик со схемой schema.rb. Этот файлик позволяет легко увидеть а чо там в базе без необходимости туда лезть. Он автоматически используется при накатывании проекта с нуля или в старте тестов. Работает это так: сначала грузим схему, затем миграции, которые добавились, но еще не применялись в текущем окружении. Наличие такой схемы позволяет легко удалять миграции, которые уже были накачены в продакшене.

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

Еще больше ништяков можно прочитать в офигенном гайде: https://guides.rubyonrails.org/active_record_migrations.html

Удаление

Помимо генераторов в рельсе реализован механизм удаления сущностей, например если я сделаю bin/rails destroy model Product, то она удалит все связанные сущности включая миграции. Это очень удобно когда идет активное добавление новых сущностей и возникают ошибки в именовании. Использовать этот механизм для моделей можно только если это локальные изменения.

Накат/Откат

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

bin/rails db:rollback STEP=3
bin/rails db:migrate:redo STEP=3

p.s. Поделитесь крутыми фишками миграций в ваших фреймворках

Ссылки: Телеграм | Youtube | Подкаст

Ну вы поняли да? https://www.youtube.com/watch?v=dJXV5Y1Pnc8 На самом деле, я попытался собрать от Антона предложения по тому "а как все же сделать чтобы было хорошо" и у нас получился довольно интересный разговор. Мы даже егэ там перемыли

Увидел ссылку на прекрасный пост 2016 года в жж про то как нанимать, который не могу не опубликовать (пришлось чуть подрихтовать чтобы влезло):

1. Читаем резюме. Вырезал чтобы влезло

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

3. Задаем несколько вопросов как в №2, но по теме данной позиции и копаем вглубь пока лопата не зазвенит. Причем годятся любые вопросы, ответы на которые практически невозможно запомнить всухую. "А вы помните в каком релизе там фундепы внедрили?" Правильный ответ "что-то типа NNN или около того, но потом пришлось обратно всем откатываться, потому что оказывается что фундепы сломали тайпчекер, как оно тесты-то прошло, бгггг". Очень хорошо идут вопросы из резюме кандидата (из №2) но в приложении к технологиям из №3: "а вот вы рассказывали что вы делали ХХХ, а как бы вы сделали тоже самое, но уже с использованием YYY, которое нам нужно?". Тут люди очень часто заводятся и начинают увлеченно "проектировать" ибо чувствуют себя в своей тарелке. Вообще говоря, на этом месте иногда можно и закончить и послать человеку оффер (ну или наоборот), если повезет.

4. Даем тестовое задание. Тестовое задание не должно быть больше 8 часов при требуемом вами уровне квалификации, а лучше меньше. Идеально - 4-5. Если есть возможность - не говорить кандидату на этапе №2 сколько именно вы рассчитываете займет задание. Просто отделайтесь "небольшое" и попросите его на этапе №5 оценить время самому. Я стараюсь иметь бюджет на оплату тестовых заданий и плачу по разумной рыночной ставке, чтобы человеку было не обидно и замечено что люди даже за небольшие деньги гораздо внимательнее относятся к выполнению, включается психологический паттерн "работа". Задание даю так, чтобы его можно было сделать за отведенное время аккуратно, без висящих соплей. Стараюсь давать из существующего проекта, либо что-то новое (поскольку заплачено, то не стыдно и использовать будет) либо уже существующее (зато есть reference implementation и можно отдать на глубокое ревью тому, кто писал оригинал). Задание должно быть вырезано из существующего проекта аккуратно и не требовать экзотического тулинга и строго заданных ОС. Человек будет делать задание из дома, а там у него может не быть рабочего окружения, а просто игровой компутер с виндой. Можно дать доступ на EC2 инстанс, где уже все готовое установлено, а потом его просто убить. Задача должна быть реальная, делать что-то полезное, а не сортировать массив пузырьком, прости господи.

5. Ревью задания с кандидатом. Почему вы сделали так, а не иначе, что бы вы сделали если бы было больше времени, покрытие тестами, точки интеграции в "большой" проект, то есть обычная рабочая рутина. Посмотреть как человек вертится, как и что предлагает, насколько хорошо оценивает риски, и т.д. Желательно конечно убедиться что задание компилируется, работает и делает что обещано 🙂

p.s. https://kika.livejournal.com/152388.html

Ребят, хочу порекомендовать канал https://t.me/MicroservicesQuestions в котором собираются вопросы с собеседований и архитектурные решения связанные с базами данных, распределенными системами и проблемами микросервисных проектов. Рекомендую подписаться если вы готовитесь к собесам или учитесь решать подобные задачи. Из последних тем там:

> Взаимно-рекурсивные внешние ключи
> Каскадное удаление за один запрос
> Caching patterns

Bootstrap подходит только для админок

Хекслет и все его сайд-проекты: cv.hexlet.io, code-basics.com, codebattle.hexlet.io, guides.hexlet.io реализованы с помощью Bootstrap. Причем, в основном, это стандартный бутстрап

Почему мы это делаем?

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

Это особенно важно, учитывая, что для современных it-бизнесов наиболее критичная метрика — time to market, то есть скорость, с которой изменения доставляются до пользователей. Быстрые и частые релизы позволяют не тратить время на ненужные вещи и делать только то, что пользователям нужно по-настоящему.

С плюсами понятно, а что насчет минусов? Ведь сайт выглядит не “круто”.

Как показывает практика, влияние дизайна на успешность продукта нередко переоценивается. Более того, на Хекслете происходит ровно наоборот. Сейчас дизайн более стандартный для Bootstrap, чем был в начале 2018 года (у нас была попытка сделать что-то совсем своё), и мы получаем много положительных отзывов:

> Хороший материал, интересные задачи, приятный интерфейс - мне нравится

Но еще большему числу людей это вообще не важно:

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

Наличие контента и его качества решают

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

Проще и быстрее написать свое

Проще ли написать свое? Конечно! Если у вас стоит задача прямо здесь и сейчас заверстать какой-то кусок, который решает конкретную задачу, то намного проще накидать пару-тройку своих классов и радостно перейти к следующей задаче.

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

Как только в проекте появляется своя верстка, то все, кто не принимают участие в ее создании, будут вынуждены ждать тех, кто ее пишет. То есть замедляется time to market. Чем больше верстка заточена под конкретные ситуации, тем меньше возможностей для маневра.

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

- Bootstrap создается тысячами разработчиков, внутри него решены все распространенные проблемы, причем наиболее универсальным способом. Все это благодаря огромному коммьюнити.
- У Bootstrap очень подробная документация. Разобравшись с ним один раз, это будет помогать всю последующую жизнь, так же как и владение git. Своя документация никогда не дойдет до такого уровня.
- Стоимость создания общего решения во много раз дороже создания частного решения. Обычно программисты недооценивают, во что им выльется сделать нечто универсальное. В итоге время будет тратиться на обкатку этого решения, а не на выполнение задач проекта.
- Bootstrap настолько популярен, что для него существуют библиотеки под каждый фронтенд-фреймворк и темы под все популярные виджеты. Еще минус куча работы.

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

Ссылки: Телеграм | Youtube | Подкаст

Где вы сейчас работаете и чем там занимаетесь? (твиттер-тред)

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

Самое страшное когда говорят "начну с самого начала". Началом может оказаться школьные годы и долгий тернистый путь к себе настоящему. Однажды чувак мне сказал "щас я коротко про себя расскажу". Через 30 минут пришлось его останавливать.

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

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

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

Идеальный ответ звучал бы примерно так: "Работаю в компании Хекслет. Это онлайн-школа программирования. Здесь учатся с нуля и повышают квалификацию. Я занимаюсь онлайн-редактором, в котором выполняются практики после уроков и курсов".

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

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

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

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

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

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

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

Ссылки: Телеграм | Youtube | Подкаст

А тем временем вышло видео на ютуб канале: https://www.youtube.com/watch?v=vXrru_QZ31E Обязательно посмотрите, там мы говорим про переход из разработки в менеджмент и сопутствующие проблемы. Разбираем немного Германию и штаты)

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

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

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

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

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

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

⁃ Прозрачность бизнеса. Они понимают как работает бизнес, какую приносит пользу, как зарабатывает, как тратит, куда идет. Это упрощает понимание смысла задач, которые ставят перед разработкой. Иначе у вас будет история про “опять этот маркетинг заставляет делать херню”.

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

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

⁃ Профессиональный рост. У нас нет карьерного трека, потому что разработка небольшая и плоская, но на Хекслете можно прокачаться глубоко во внутрь и в ширь (фронт, бек, девопс). Я всегда стараюсь устроить процесс так, чтобы ребята не только росли, но и понимали свое место в разработке вообще. Насколько я силен не просто в Хекслете, а вообще по отношению к разработчикам вокруг себя.

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

p.s. Как вы оцениваете свою текущую работу? Это то где вам хочется быть или нужно идти дальше?
p.s.s. Стоит пост фаундерам скидывать?)

Ссылки: Телеграм | Youtube | Подкаст

Фиганул на хабр статью (мне кажется оч классную) на тему связи архитектуры и ооп. В ней многое перекликается с тем что я говорил в выпуске подлодки про чистый код. Плюсы к статье приветствуются https://habr.com/ru/articles/833968/

Саасы и печаль
Для своих задач мы используем десятки разнообразных сервисов для кодинга, маркетинга, продаж, аналитики, сапорта и всего на свете. Суммарно около 80 сервисов, большая часть из которых платная. И со всеми этими сервисами есть несколько проблем, которые заставили меня поменять отношение к выбору таких сервисов. Вот они:

⁃ То что дешево в начале, может стать очень дорогим в процессе. Пример zapier, стоимость этого сервиса может расти экспоненциально. Тоже самое со всякими crm типа mailchimp
⁃ Раз в год какой-нибудь сервис так меняет условия или цены, что пользоваться им становится накладно. Приходится искать альтернативы
⁃ Санкции, законодательство и другие форс-мажоры из-за которых приходится постоянно мигрировать туда сюда.

В общем беда, любой сервис так или иначе входит в состояние, когда надо двигать дальше. Кто-то скажет, ребят, ставьте все сразу себе, но для небольших продуктовых компаний это слишком дорого и не нужно по большому счету. Поэтому мы пошли по третьему пути. Сейчас мы стараемся выбирать продукты, которые предоставляют saas, но с возможностью съехать в self-hosted решение. Эта тактика уже не раз себя оправдывала, потому что часть сервисов реально заставила нас съехать на свои сервера. Примеры таких сервисов:

⁃ gitlab, сначала юзали облако, после изменения политики оплаты (за юзеров) съехали к себе
⁃ n8n (коннектор между сервисами), когда событий стало много, поехали к себе. По пути прошли zapier и pipedream
⁃ posthog (продуктовая аналитика), пока на облаке, но в любой момент готовимся переехать. Были на амплитуде.
⁃ mattermost, в какой-то момент начали банить тех кто из россии, поэтому уехали на свои сервера. Съехали со слака.
⁃ airbyte (ELT pipline), переехали на него с какого-то другого сервиса
⁃ sentry.io, пока в облаке, но всегда можем уехать на self-hosted

Не все имеет открытые аналоги, но мы стараемся находить такие решения и использовать если они хороши. А у вас как с этим?

Ссылки: Телеграм | Youtube | Подкаст

Управление конфигурацией

Для настройки окружения проекта можно использовать (а многие так и делают) стандартные средства операционной системы. Такие, как пакетный менеджер (yum, apt), прямое редактирование конфигурационных файлов, bash-скрипты, curl/wget и многое другое.

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

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

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

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

Может показаться, что решением является написание, например, bash-скриптов. И в любом случае это уже шаг вперед. Но есть одна серьезная проблема. Это обеспечение идемпотентности. Идемпотентная операция в информатике — действие, многократное повторение которого эквивалентно однократному. Что на практие означает отсутствие идемпотентности? То, что повторный запуск bash-скрипта (кроме тривиальных случаев) приведет к ошибке и остановке выполнения.

Примеры:

Вызов mkdir упадет с ошибкой что "директория существует". Операции перенаправления вывода повторно запишут данные. Любая операция, связанная с удалением, закончится с ошибкой (mv, rm, rmdir). Клонирование git репозитория упадет с ошибкой. ln упадет с ошибкой. И многое другое. Это означает, что вам нужно либо всегда накатывать bash-скрипт на чистую систему, что невозможно, либо вам нужно будет все скрипты обвешивать проверками, которые и будут обеспечивать идемпотентность.

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

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

К счастью, решение существует, и это не ручные скрипты, а системы управления конфигурацией. Их достаточно много и все они предлагают концепцию «управление инфраструктурой как программным кодом». Это означает, что описание инфраструктуры хранится в файлах (плейбуках, кукбуках и так далее), находящихся под контролем версий, а сама инфраструктура изменяется только посредством запуска процесса накатки изменений. Также эти системы знают про топологию серверов и позволяют вам гибко указывать, что к чему относится, дают возможности легко переиспользовать повторяющиеся сценарии, а так же выполнять множество других полезных функций. Лично я рекомендую Ansible, я даже когда-то делал курс https://ru.hexlet.io/courses/ansible

Ссылки: Телеграм | Youtube | Подкаст

Все же слышали или пользовались Миро? У ребят кодовая база на миллионы строк и спец команда frontops, которая занимается только инструментарием и производительностью. Обо всем этом поболтали с Тимуром Хазамовым, разработчиком core https://www.youtube.com/watch?v=VbQAiETRUwY Если не работает ютуб, то https://vk.com/orgprog?z=video-224967259_456239031%2Fvideos-224967259%2Fpl_-224967259_-2

Ссылки: Телеграм | Youtube | Подкаст

Что такое рыночная зарплата на самом деле? Это не представления людей о том сколько они стоят, это не зарплаты которые вы видите в вакансиях, это не медианные значения которые выводят в аналитических статьях. Рычная зарплата, это та зарплата на которую вы (бизнес не бизнес, не важно) можете найти нужного специалиста на рынке. Поэтому понятия "зарплата ниже рыночной" это миф. Обычно, речь идет про то, что для вас это недостаточно (по вашему опыту или вашему представлению), но это не значит, что таких людей нет. И даже если предположить что в вакансии зарплата действительно ниже рыночной, то благодаря свободному рынку, она достаточно быстро корректируется иначе вакансия просто не закроется. А причина почему бизнес пытается не переплатить очень простая, но я ее расскажу в будущих постах если вам интересно.

- Поставьте палец вверх если интересно и я напишу
- Поставьте палец вниз, если вы не хотите про это читать

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


Ссылки: Телеграм | Youtube | Подкаст

Васятка делает стартап. Часть первая

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

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

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

Вася нанял двух разработчиков, арендовал офис, и за пару месяцев они создали первый прототип. Затем выложил приложение в App Store и рассказал об этом своим друзьям в соц сетях. Первые 50 подписчиков пришли за неделю, что вселило в нашего бизнесмена уверенность. Но во вторую неделю добавилось лишь 10 новых подписчиков, а через неделю отписались 5 старых. В App Store появились негативные отзывы, потому что продукт был сырой. Но Вася не унывал — с командой быстро исправил баги и добавил новые функции. Через пару недель обновленное приложение появилось в App Store, но клиенты перестали приходить.

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

Наш герой осознал, что ему придется заниматься рекламой. Он потратил неделю на настройку и запуск, а затем, вложив в рекламу тысячу долларов, с ужасом обнаружил, что привлек всего 10 клиентов. То есть каждый клиент обошелся ему в $100, при том что подписка приносит только $10 в первый месяц. "При таком раскладе я всегда буду в минусе," — подумал Вася. Он снова пошел к друзьям, которые уже спорили, как долго он продержится до закрытия.

Друзья объяснили ему понятия стоимости привлечения клиента (CAC) и доходов за время его использования продукта (LTV). Вася слышал о юнит-экономике, но только теперь начал понимать её суть. Чтобы зарабатывать, CAC должен быть в несколько раз ниже LTV, иначе бесмысленно.

"Как это возможно, если у меня CAC уже $100?" — спросил Вася. Ему ответили: "Твоя задача — снизить CAC и увеличить LTV, пока юнит-экономика не сойдется. Чтобы увеличить LTV, делай продукт лучше и полезнее для клиента. Чтобы снизить CAC, ищи дешевые каналы привлечения и повышай узнаваемость продукта, пиши статьи и снимай видео. Но это может занять годы без внешних инвестиций"

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

Чо как вам? 😄

Ссылки: Телеграм | Youtube | VK

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

⁃ Ютуб: Выпуски + шортсы
- Facebook: Анонсы
⁃ Сообщество вконтакта (зеркало телеги): Плюс там же подкаст и vk видео где дублируется все с ютуба.
⁃ Инстаграм: Нарезки контента, но планируются авторские рилсы
⁃ Тикток: Тоже самое что и инста, но для тех кто любит тикток
⁃ Рутуб: дубль ютуба
⁃ Одноклассники: а что, а вдруг. Копия вконтакта
⁃ Твиттер: тут свой контент в основном
⁃ Подкасты: Тут все площадки, где можно слушать в аудио (спотифай, apple, яндекс музыка и т.п.)

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