Архив недели @jin_ninПонедельникВторникСредаЧетвергПятницаСубботаВоскресеньеПонедельникВторникСредаЧетвергПятницаСсылки
Архив недели @jin_nin
Понедельник
Все говорят code-split, lazy-load, SSR... всё это чтобы показать тривиальную страничку. А у нас бандлы меньше 100КБ. И код даже не минифицирован. Причины тут 4:
- Минимум бойлерплейта и говнокода из NPM.
- Максимум переиспользования.
- Грамотная архитектура.
Server Side Rendering применяется для двух целей:
Отдача HTML не умеющему в JS поисковику (Привет, @yandex ).
Сделать вид, что сайт загружается быстро, а пока пользователь не прочухал и любуется красивой картинкой, в фоне загрузить тонны мусора из NPM (Привет, @momentjs).
Технологии, помогающие скрыть некомпетентность разработчиков:
- Minification
- Code Splitting
- Server Side Rendering
- Optimistic UI
- Prefetch
- Critical CSS
В мире SEO есть два главных заблуждения:
Что нужно рендерить на сервере всё приложение, а не просто отдавать тот же контент. См: developers.google.com/search/docs/gu…
Что типичный сеошник хоть что-то понимает в работе поисковиков и стат анализе.
Чтобы исключить неожиданности и упростить отладку хорошей практикой является идентичность кода исполняющегося на проде и на машине разработчика.
Поэтому у нас нет разделения на production и develop бандлы. Разработчик отлаживает ровно тот же код, что будет крутиться и на проде.
Человек ленив. Между сложным правильным путём и лёгким неправильным он с большей вероятностью выберет неправильный. Поэтому правильный путь должен быть легче неправильного. А лучше, если неправильный вообще не будет доступен.
#принципы_разработки
Человек не идиот. Если делать продукт для идиотов - только идиоты им и смогут пользоваться. Не стоит тратить время на эксцентричные сценарии. И тем более жертвовать удобством/функциональностью/производительностью ради их поддержки.
#принципы_разработки
Если не видно разницы, то незачем делать больше. Такие оптимизации можно производить без спроса. Если же человек может увидеть деструктивность оптимизаций, то они должны явно включаться им вручную. Тогда он не будет воспринимать оптимизацию, как глюк.
#принципы_разработки
Вместе люди способны на большее. Одно общее решение лучше, множества конкурирующих. А кооперация людей с разносторонней экспертизой даёт синергетический эффект.
Сейчас же мы наблюдаем, как каждая компания делает свой уникальный UI-Kit. Не надо так.
#сообщество
В каждой области может быть только один ответственный. Если формально ответственны несколько, то фактически не ответственен никто. А без единого ответственного невозможно построить консистентное решение за разумное время.
#процессы
Предлагая каждому участнику решение множества проблем совершенно бесплатно, сообщество в праве ожидать от него хотя бы минимально полезную отдачу: регулярность обновлений, конструктивную критику, терпимость к несовершенству, а не потребительское отношение.
#сообщество
У каждой проблемы есть не всегда очевидная первопричина. Найдя её, стоит придумать такое решение, которое полностью её устранит.
Зри в корень.
#принципы_разработки
Если проблема не может быть решена полностью, стоит выбрать такое решение, чтобы та же ситуация уже не была проблемой.
Не можешь победить - возглавь.
#принципы_разработки
При выборе решения стоит рассматривать наихудший сценарий развития событий и выбрать наилучшее решение для этого случая.
Сохраняй хорошую мину при плохой игре (с) Теория Игр
#принципы_разработки
Между высокоуровневой простотой использования и низкоуровневой гибкостью... лучше не выбирать, а строить удобные абстракции на гибкой основе.
Лишь поставив себе высокую планку можно чего-то достигнуть.
#принципы_разработки
Даже минимальная наценка помноженная на многие списания выливается в существенную сумму, которая может оказать фатальное влияние.
Не платите за то, что не используете.
#принципы_разработки
Если от чего-то допустимо отказаться в некоторых случаях, то стоит отказаться и в остальных. Незачем тратить ресурсы на то, что не особо-то и нужно. Сэкономленное всегда будет куда применить с большей пользой на то, от чего отказаться никак нельзя.
#принципы_разработки
Минимизация:
- медленная сборка
- отличие дев и прод сборок
- крайне сложно дебажить без сорсмапов
- медленное развертывание дев окружения из-за кучи зависимостей
Минимизация:
сложно поддерживать сворованный код
уменьшение сжатого бандла максимум на 25%
Для 10МБ 25% - это ускорение загрузки на секунды.
Для 100КБ 25% - это не заметно для пользователя.
PascalCase:
Традиционно для имён классов.
МНого нажатий шифта вовремя.
СлипшиесяСловаТрудноЧитать.
Непонятки с аббревиатурами: XMLHttpRequest.
Под виндой такие имена файлов - боль.
В CSS/HTML/XML в зависимости от типа элемента чувствительность к регистру разная.
camelCase:
Традиционно для имён переменных и полей
Много нажатий шифтаВОвремя
слипшиесяСловаТрудноЧитать
Непонятки с аббревиатурами: mxBADownload
В CSS/HTML/XML в зависимости от типа элемента чувствительность к регистру разная.
kebab-case:
Традиционно для имён в html, css, а также в именах файлов
Редакторы не считают эти имена единым именем (выделение даблкликом, ctrl+стрелка и тп)
Не допустимо в большинстве языков программирования
На несколько символов длиннее, чем camelCase
snake_case:
Традиционно в "олдскульных" языках (C, C++, Rust, Erlang, OCaml) и языках с упором на читаемость (Ruby, Python)
Может использоваться где угодно
Везде воспринимается как единый токен
Требуется_много_нажатий_шифта
На несколько символов длиннее, чем camelCase
multiple cases:
Разное именование одной сущности в разных местах
Везде необходимы конвертации между стилями написания
Не везде возможна автоконвертация
Поиск всех вхождений одного имени в проекте приходится повторять для каждой формы написания
Сегодня с твитора аж жир капает twitter.com/nikitonsky/sta…
А ещё некомпетентность разработчика может быть прикрыта скрамом и другими гибкими методологиями.
А часто даже усугубить. twitter.com/pomidore/statu…
Суровая правда о совместном использовании библиотек из CDN:
Каждый сайт всё-равно грузит свою версию библиотеки.
Ваш сайт не единственный, а кеш не резиновый, так что даже намертво закешированное вымывается из кеша.
Уменьшайте бандлы, а не надейтесь на кеш общих частей.
Слушайте что человек говорит. А не оценивайте как он это делает или что он из себя представляет. Пустить пыль в глаза не сложно. И многие этим пользуются, чтобы пустить вас по ложному пути.
#дискуссии
Сейчас популярна тема "микрофронтендов". И ладно бы для этого использовался $mol или Svelte. Но их пилят на чём привыкли. В результате получаются скорее "макрофронтенды", где на каждый чих грузится отдельное приложение умеренной жирности.
Версионирование библиотек:
Хрен загрузишь несколько версий одной либы, когда надо
Когда не надо они так и норовят загрузиться в 10 версиях через зависимости
Часто в одном рантайме разные версии просто не уживаются
А если уживаются занимают кратно больше места в бандле
Типичный фронтендер:
мыслит трендами
катается на хайптрейне
боится изучать что-то новое (а вдруг не пригодится?)
обижается, когда перед ним не расшаркиваются
будет защищать привычную библиотеку, словно это его мать родная
Разработчики обычно сидят в уютных офисах за 8-ядерными машинками с 16гб оперативки подключёнными к гигабитному оптоволокну.
И делают сервисы для обычных работяг, вылезающих в интернет через древние дешёвые смартфоны по лимитированным тарифам, выискивая место, где ловит 3G.
Микрофронтенды - это когда используемая технология настолько не эффективна, что для разработки одного приложения одной команды уже не хватает.
А пользователь страдает.
Виды фронтендеров:
Не умеют в типы. Кричат, что TS не нужон, а типы очень многословны.
Пишут даже там, где компилятор их может вывести сам, чем убеждают первых в своей правоте.
Пишут на JS, абы как описывая типы в JSDoc, но продолжая утверждать, что TS не нужон.
Наследование и композиция - два перпендикулярных понятия. И принцип подстановки Лисков - хороший индикатор, чтобы их не перепутать. Если создаваемый компонент должен соответствовать контракту другого компонента - имеет смысл использовать наследование. Иначе - композицию.
Когда решаются действительно важные архитектурные вопросы, то зачастую всем пофиг. Но самые жаркие дискуссии вспыхивают при обсуждении... стиля написания кода.
Ставить ; или не ставить - вот в чём вопрос.
Часто разработчики думают лишь о 80% случаев использования, когда всё хорошо. Совершенно забывая, что оставшиеся 20% у всех разные и каждый клиент будет регулярно напарываться на эти 20%, проклиная вас всеми известными ему неприличными словами.
Где успешные и плетежеспособные люди могут встретить плохой интернет:
- В подвальном ресторане
- В сапсане по пути между Питером и Москвой
- На лазурном берегу вдали от цивилизации
Хотим ли мы терять пользователей, которые действительно могут позволить себе плохой интернет?
Война и Мир в сжатом виде - пол мегабайта.
Судя по объёмам бандлов, формочки на сайтах рисуют сплошь Львы Толстые. Не меньше.
Critical CSS - это когда ты накопипастил столько одинаковых стилей, что вырезание всего, что не нужно для первого экрана, даёт достаточно существенную экономию, чтобы вообще заморачиваться такой ерундой.
А давайте устроим челлендж: включаем на своих девайсах "Slow 3G" и идём спрашиваем "бизнес" приемлемо работает приложение или надо срочно запланировать итерацию по оптимизации.
Вторник
Все слышали "преждевременная оптимизация - зло".
Многие поняли как "оптимизация - зло".
Мало кто знает: автор этих слов говорил про локальные оптимизации алгоритмов, напирая на первоочерёдность оптимизации архитектуры, ибо при её изменении, алгоритмы тоже поменяются.
Думаю все слышали про TDD. А кто-то так и живёт. Что вы делаете, когда написанный тест изначально зелёный?
Кто угадает, что значит красная горизонтальная черта?
Системное тестирование (всей системы в сборе):
Уверенность в работоспособности системы
- Хрупкие тесты
- Медленный прогон тестов
- Глубоко вложенные модули часто остаются недотестированными
Модульные(единица кода) тесты:
Исполняются быстро
Можно запускать пока система ещё не рабочая
- Ломают инкасуляцию (клиент знает о зависимостях)
- Нет уверенности в работе системы
- Хрупкие тесты (фиксируют не важные бизнесу контракты)
- Код моков больше кода тестов
Чтобы модульные тесты были полны - нужно ещё хотя бы проверить их интеграцию друг с другом, что кратно увеличивает число тестов. А это:
- время на написание
- время на поддержку
- время на исполнение
Компонентные (единица поведения) тесты:
Уверенность в работе системы
Почти нет моков
Запуск на нерабочей системе
Минимум кода тестов
Выявляют недотестированность
- Медленные при неленивой архитектуре
- Сложно локализовать проблему при запуске в случайном порядке
Забыл добавить:
- Сложно локализовать проблему
- Сложно переносить между приложениями
Правильный TDD - и не TDD вовсе.
В погоне за оптимизациями, важно всё время задаваться вопросом: стоит ли очередной маленький шажок к идеалу усложнения и замедления пайплайна, увеличения числа точек отказа и усложнения отладки?
И порой куда эффективней просто зайти с другого конца.
#принципы_разработки
Компонентные тесты так же известны под названием "социальные модульные тесты", что звучит так же глупо как "социальная проверка входной двери" для осмотра новой квартиры.
Чем меньше вы мокаете, тем больше уверенности в работоспособности. Однако, нестабильные API (такие как, например, рандом, время, размеры окна и тп) лучше мокать в любом случае.
А вот персистентное состояние можно не мокать, если писать учитывающие это тесты.
В каком коде больше инкапсуляции?
class Twitter {
constructor( private butt : Butt ) {}
tweet() { this.butt.hurt() }
}
class Twitter {
butt = new Butt
tweet() { this.butt.hurt() }
}
Изоляция - предотвращение доступа извне.
Инкапсуляция - привязка данным к функциям их обработки.
Абстракция - независимость использования от деталей реализации.
Это ортогональные понятия, и хорошо бы их не путать.
Простая задачка на JS. Пользователь приложению даёт длины сторон треугольника, а оно возвращает true или false в зависимости от того, является ли он равносторонним или же нет.
Сколько нужно написать тестов?
Тестирование белого ящика требует обновлять тесткейсы после каждого изменения кода.
Тестирование же чёрного - может оставить код недотестированным, так как вы не знаете про все граничные условия.
Тестирование серого ящика обладает минусами и белого и чёрного одновременно.
Для простоты давайте положим, что у нас тайпскрипт, который не пускает на вход совсем уж треш.
Исполнение тестов в том же порядке, в котором собирается код в бандл, позволяет довольно точно локализовывать проблему: первый упавший тест указывает на сломанный модуль.
А ваш сборщик умеет правильно упорядочивать тесты?
Замерил у нас время исполнения компонентных тестов. 4мс на тест в среднем.
Для сравнения, ангуляровский TestBed только инициализируется перед каждым тестом на порядок дольше.
Секрет в ленивой архитектуре, поднимающей лишь нужные для теста части приложения и простом и быстром IoC.
Для реализации с минимумом ветвлений у меня получилось, что надо минимум 11 тестов.
У кого больше?
Благодаря сортировке мы избавились от комбинаторного взрыва тесткейсов, так что достаточно проверить первый параметр, для которого у нас 3 класса эквивалентности:
Каждый класс эквивалентности даёт по 2 граничных условия:
-∞
0
δ
a + b - δ
a + b
+∞
Плюс NaN конечно же.
В классе эквивалентности "треугольник" надо проверить как вариант с true, так и с false. Итого - 11 тестов.
Тред (@jin_nin)
Кодер выполняет задачу как поставили. Пробелы в ТЗ - не его проблемы.
Девелопер же выяснит все детали. Или же использует свой опыт для уточнения ТЗ самостоятельно.
Как много во фронтенде кодеров и как мало девелоперов.
Падение теста на явно некорректном коде ничего не говорит о том, проверяет ли он хоть что-то в коде, похожем на корректный.
Пока жопу разработчику прикрывает тестировщик, не ждите от первого ответственного отношения к качеству того, что он делает.
Чтобы уменьшить число багов на проде, надо не добавлять тестировщиков, а убирать. И устраивать с разрабом ретроспективу по каждому багу.
Спустя несколько ретроспектив толковый разработчик и в тестировании разберётся и архитектуру поправит, чтобы меньше париться, но максимально тестировать, и чтобы баги минимально возникали.
А бестолкового не стоит и держать.
Среда
Проверяет ли тест хоть что-то, определяется не прохождением или падением теста, а тем как тест написан. Если из кода теста не видно что он проверяет, то это именно та проблема, которую надо решать. А не ломать свой код, ради сомнительного ритуала.
Ну что ж, думаю самые нежные уже отписались, и можно постить теперь настоящую дичь с камел_кейсом и долларами.
Человек не является джуном или сеньёром сам по себе.
Для себя я вывел следующую градацию полезности человека в решении определённых задач:
- Джун сделает задачу, но ему нужно помогать
- Мидлу можно поставить задачу и быть уверенным в её выполнении
- Сеньёр сделает лучше, чем было
Чем проще, изолированнее и линейнее тест, тем проще его писать, понимать и переносить. Поэтому у нас нет никаких describe, setup и teardown.
Тут нет ничего лишнего, лишь описание и некоторая "история" внутри. В данном случае у нас драма.
Почему так странно? Никто же так не делает!
Зато у нас информативные стектрейсы, по которым сразу видно какой тест и почему упал.
Мы вообще упарываемся по стектрейсам в частности и упрощению дебага вообще.
В погоне за "человекопонятностью" очень легко эту человекопонятность лишь потерять.
stackoverflow.com/questions/3261…
Подражание естественному языку, вносит в программную логику лишь свойственную естественному языку неоднозначность смыслов.
А это не то, к чему стоит стремиться.
Чем проще API, тем легче его освоить и сложнее запутаться. Поэтому assertion library у нас верх минимализма.
Поздравляю, вы её уже изучили.
У нас есть 2 одинаково драматичные функции, лежащие в разных файлах. Как вы думаете, для чего?
@jsunderhood Извините за нескромный вопрос, зачем везде приписка $mol? $ сразу навевает у меня воспоминания о PHP, но вопрос не об этом. Почему именно $mol_function, а не mol.function? Это технически чем-то оправдано или философский выбор?
В MAM экосистеме всё, что начинается с $ - это Fully Qualified Names. По ним сборщик понимает что откуда брать. Это аналог autoload из PHP, позволяющий тащить в бандл лишь реально используемое. При отладке такие имена тоже весьма полезны.
github.com/nin-jin/HabHub… twitter.com/batyshkaLenin/…
Разгадка простая: один из этих фалов блекбоксится, что предотвращает остановку отладчика на кидаемых через него исключениях.
$mol_assert_fail же временно подменяет $mol_fail на $mol_fail_hidden, что не даёт остановки на ожидаемых исключениях, но останавливает на неожидаемых.
Также $mol_fail_hidden используется например для rethrow исключений, кидания обещаний и прочих рядовых случаях.
В результате, остановку на исключениях можно всегда держать включённой, а останавливаться отладчик будет лишь когда что-то действительно пошло не так.
Вся коммуникация у нас построена на концепции каналов. Каждое свойство - это некоторая функция, которая может выступать как просто геттер, так и сеттерогеттер. $mol_mem - волшебный декоратор, который реактивно мемоизирует возвращаемое методом значение.
Делегировать ввод/вывод в/из канала удобно в другие объекты, чтобы связывать их вместе. Например, давайте заперсистим свойство, хранящее айдишники, в локальное хранилище.
Теперь вы можете открыть приложение в нескольких вкладках и значение будет всегда синхронизировано.
Обратите внимание на поле $ - это контекст окружения. Он доступен всем компонентам и наследуется через иерархию владения. Через него любой компонент может переопределить любую глобальную переменную для всего своего поддерева. Например, заменим все стандартные кнопки на свои.
$mol_test сразу даёт такой контекст окружения, где все внешние и нестабильные зависимости уже замоканы. Так что мы можем безопасно запускать, например, приложение ToDoMVC, которое мусорит в localStorage. Создадим задачу и проверим, что она создалась, а поле ввода очистилось.
А теперь что-то по сложнее:
Создадим пару задач
Одну завершим
Попереходим по ссылкам и убедимся, что список задач правильно фильтруется.
$mol_state_arg - реактивное состояние адресной строки. Оно, разумеется, тоже мокается автоматически и пишет в память, а не location.
Тред (@jin_nin)
Компонент - это самый обычный класс.
В свойствах с Большой буквы лежат вложенные компоненты. Снова этот $mol_mem.. но на этот раз он не просто мемоизирует, но и захватывает владение над объектом. Он жив, пока кому-то нужен, а потом у него автоматически вызовется destructor.
То же самое можно записать и куда короче.
view.tree - не более чем упрощённый синтаксис для описания классов.
github.com/nin-jin/slides…
Single Responsibility Principle - красивая концепция, оторванная от реальности. Приводит ко кратному увеличению числа объектов на ровном месте. Когда их число исчисляется сотнями тысяч это даёт заметную просадку из-за GC. Да и пользоваться без фасадов за фасадами не удобно.
Open Closed Principle - фактически говорит "никогда не делай рефакторинг". Ну да, пусть кодовая база тухнет под гнётом десятков реализаций одного и того же. Зато у нас ничего не сломается. Не тесты же писать в конце-то концов!
Liskov Substitution Principle - наивно полагает, что подтип может быть подставлен вместо надтипа где угодно. И это действительно так.. в иммутабельном мире. В мутабельных же мирах контравариантность передаёт ей привет.
habr.com/ru/post/477448…
Interface Segregation Principle - такая структурная типизация для бедных. Каждой комбинации имя+сигнатура метода даётся уникальное название и потом из этих названий собираются уникальные комбинации.
Впрочем, протягивать очередную сигнатуру через слои абстракций в любом случае ад.
Обожаю принципы, которые каждый понимает и реализует по своему. Но у кого ни спросишь - только он знает как оно на самом деле, а остальные просто не поняли.
Грош цена принципам, которые можно понять не так.
Dependency Inversion Principle - чудесный способ всех запутать. Вот у вас использование зависимости. Казалось бы рукой подать. Но нет, это только начало увлекательного квеста по определению, что же у тебя сюда приходит на самом деле.
Если человек говорит вам, что он программирует по SOLID - попросите его снять скафандр и выйти из звездолёта. Как и любые паттерны, эти надо применять лишь в тех особых случаях, где от них есть толк, а не везде, где их только можно присунуть.
Четверг
$mol компонент является плоским классом, а view.tree позволяет объявлять его лаконично и не теряя в наглядности иерархии. Например, тут объявляются 13 методов класса. 2 из них (@) локализуются. 5 владеют вложенными объектами. 10 one-way связываний (<=). И 3 two-way (<=>).
Пятница
Don't Repeat Yourself - источник многих звездолётов. Но есть с ним и менее известная проблема - независимые части системы, случайно имеющие похожий код, вдруг начинают реально быть связанными через общий код. Правишь для одного - ломаешь всех.
You Aren't Gonna Need It - известное прикрытие для архитектурных раздолбаев. Ща побырому сделаем, а после нас хоть потоп. Потоп начинается через 2 итерации с дикими костылями и криками "Ну мы же не знаааали, что оно понадобится!".
Keep It Small and Simple, внезапно, единственный принцип, которым стоит руководствоваться. Потому, что всё гениальное - просто. И потому, что довести его до абсурда вам никто не даст - усложнять всё равно придётся, но вы будете искать максимально простое решение.
Так что насчёт челенжа? Или как травить человека в Твиттере, так время есть, а закатать рукава и покодить пару часов, так мы занятые люди, нам некогда?
Пока что все ссутся. Ну или стесняются признаться, что первые два часа только настраивали вебпак и выбирали либу для роутинга.
Суббота
Порой начитаешься этих ваших Твиттеров и думаешь: ну его нафиг этот опенсорс. А потом читаешь отзывы тех, кто взял и попробовал, вместо того, чтобы какашками кидаться издалека. И понимаешь, что всё правильно сделал.
$mol_jsx_view - Real DOM
ReactJS - Virtual DOM
$mol_view - Virtual Render
bench.hyoo.ru/app/#sample=re…
Как бы быстро ни рендерил ваш фреймворк, но если он не умеет лениться, то не может гарантировать отзывчивость приложения независимо от того, что там понавводили пользователи.
Люди, не способные думать своей головой, очень любят повторять за авторитетами и ритуализировать свою работу. Тренды, методологии, паттерны, принципы, код-стайлы.. всё, что угодно, лишь бы не включать голову и не задаваться вопросом: почему я делаю именно так, а никак иначе?
Легко найти человека, способного слепить куличик из песка. Сложно найти человека, способного построить здание, чтобы оно не развалилось под гнётом легаси.
Кому сейчас нужны jQuery программисты? Кому нужны будут React программисты через пару лет?
Чем больше компания, тем лучше у неё коммерческая поддержка и тем хуже некоммерческая.
compare.github.hyoo.ru/#projects=eige…
Теперь этому классу мы можем добавить стилей.
Класс компонента - это аналог БЭМ-блока.
Имя вложенного компонента - аналог БЭМ-элемента.
Можно стилизовать и элементы элемента и тд.
Это можно считать фрактальным БЭМ, но от собственно БЭМ тут уже мало что осталось.
Каждый компонент - это обычный класс, а вложенные компоненты лежат в его свойствах. Это позволяет использовать рефлексию времени компиляции для проверки, что стили вы накладываете на реально существующий вложенный компонент.
К сожалению, с TSX такого уровня CSS-in-TS не достичь.
Ну и, собственно, вот такое не хитрое приложение у нас получилось. При этом мы не написали ни строчки HTML, CSS или JS. Всё компилируется тайпскриптом и проверяется на согласованность.
Реакт:
- Каждый проект - уникальный набор либ и велосипедов
- Лапшевидный JSX
- Параметры компонента меняются через рендер внешнего
- Полный ререндер по умолчанию и куча костылей, чтобы этого не происходило
- Сложности с кастомизацией
- Проблемный SSR
- Толстый и медленный
Бандлы должны быть худыми и быстрыми. Нарезание их на кусочки лишь маскирует проблему, но не решает её.
Скажем нет толерастии и бодипозитиву во фронтенде!
Хотел было воспользоваться для типизации css-in-ts модулем csstype, но вы только гляньте какую чушь оно нагенерировало из MDN.
Пилю теперь вручную нормальные типы, которые ещё и удобнее будут в использовании.
github.com/eigenmethod/mo…
Присоединяйтесь. Потом опубликую их и в NPM.
Добавим логики. Наследуемся от сгенерированного класса и переопределяем свойство, возвращающее список целей, в котором идём за целями на сервер и мемоизируем результат с помощью $mol_mem. Пока идёт запрос, будет показываться анимация. В случае ошибки - соответствующее сообщение.
В ответе от сервера может прийти любая балалайка. Поэтому давайте добавим валидацию по схеме. Заодно получим ещё и типизированный ответ, а не any.
Тред (@jin_nin)
Есть два варианта реализации связываний:
Синхронизация (React, Angular, Svelte). В процессе синхронизации состояние приложения неконсистентно и использование его может приводить к проблемам.
Делегирование (Vue?, $mol). Тут гарантируется консистентность в любой момент.
Какой смысл делать что-то похожее на #myUsualLib, если уже есть #myUsualLib?
Наивно полагать, то качественные изменения возможны в рамках привычных вещей.
Свелт
- Не совместим с тайпскриптом
- Неконсистентность состояния в процессе синхронизации
- Копипастит dirty cheking в каждый реактивный блок, что даёт бонус на маленьких приложухах и антибонус на больших
- Не умеет в саспенс
- Сложности с кастомизацией
Ангуляр
- переусложнённая архитектура
- куча дефектов, которые годами не чинят
- огромный вес
- тормозит
- много бойлерплейта
- традиционная беда с кастомизацией
- головоломки со стримами
- беда с тришейкингом
- лишние узлы в доме
- компонент не управляет своим корневым узлом
Воскресенье
WebCmponents - мертворождённая технология:
Коммуникация через DOM крайне медленная
Никакой реактивности, всё руками
Содержимое ShadowDOM не индексируется поисковиками
Многовложенные компоненты - боль и страдание
При наличие любого фреймворка являются лишней абстракцией.
Работать с дураками - себе дороже. И дурака ничему не научишь, и сам деграднёшь.
Работайте лишь умными людьми - тогда будет синергия.
Отчасти поэтому мы не гонимся за популярностью среди леммингов, которые могут лишь требовать, но не способны ничего дать.
#сообщество
Примечательно, что про мою токсичность плачут в основном те, кто разливаются желчью на весь Твиттер, стоит только пальчиком тронуть их священную корову.
Я пишу в основном про проблемы и недостатки, потому что про достоинства вам и так все уши промоют маркетинговым булшитом, что создаёт ложное впечатление, что с индустрией всё хорошо, она не больна и активно развивается. На деле же стагнация и уверенное стремление ко дну.
При всей мои нелюбви к jQuery, у неё был очень правильный принцип "write less, do more". В какой-то момент что-то пошло не так. Cовременная разработка - это скорее "write more, do less".
Ладно, ребята, выдыхайте. Пришла пора выключать нейронку.
Vue:
- глубоко манкипатчит объекты, что медленно и небезопасно
- пока ещё не совместим с тайпсрипом
- традиционные проблемы с кастомизацией, которые все стараются не замечать
Думаю пришла пора выкладывать карты на стол.
Эту неделю с вами был Дмитрий Карловский.
Начинал я лет в 10 с бейсика ещё под DOS. Игр на нём не было, поэтому пилил их сам себе и баловался демосценами. С появлением интернета, последние лет 15, я занимаюсь в основном фронтом.
Работал и в стартапах, и на галерах, и в интерпрайзе. Как в больших проектах, состоящих из нескольких команд, так и сольно тянул на себе фронт и бэк. Сплавлялся по ватерфолу, скрамил канбан, и пережил кучу тренингов по методологиям.
Из фреймворков глубоко ковырял как первый так и другой Angular, ExtJS, SAPUI5, React, Knockout, RxJS, MobX и, конечно, кучу велосипедов. 4 года назад собрал весь свой опыт и запилил фреймворк $mol. Историю его становления можете почитать тут: github.com/nin-jin/HabHub…
Пишу статьи о программировании вообще и фронтенде в частности. Обычно это лонгриды о необычных решениях наболевших проблем.
На хабре: habr.com/ru/users/vinta…
И перекат: habr.com/ru/users/nin-j…
Иногда выступаю на митапах и конференциях. Глянуть выступления можно тут: github.com/nin-jin/slides…
Сам состою в команде PiterJS. И, кстати, сделал для нас сайт на $mol за пару вечеров: piterjs.org
Из бэкенда работал с NodeJS + OrientDB. Очень понравилось. Хочу теперь свою Графовую СУБД запилить, но всё руки не доходят. Основная идея - иммутабельность, позволяющая избавиться от Write Ahead Log и получить Audit Log из коробки.
Пишите, если хотите поучаствовать.
Разработал формат представления иерархичных данных Tree. Он одновременно и легко читаемый, и компактный, и простой в машинной обработке.
github.com/nin-jin/tree.d
Есть идеи с созданием языка программирования на его основе по типу Lisp, но без скобочек. Опять же - в личку, если что.
Сейчас работаю над одним амбициозным проектом. Когда кому-то говорю о нём - крутят у виска и говорят, что ничего не выйдет. Конкуренты десятилетиями не могут довести свои решения до ума, а я тут за пару лет хочу сделать лучше, чем у них.
Ну а я уже почти, следите за новостями.
Если вас (или кого-то из ваших знакомых) не пугают такие задачи, то у нас открыта вакансия в Москве.
Требования простые:
- Java/Kotlin и/или TypeScript
- Умение и запроектировать, и закодить, и обеспечить качество
Так что пишите в личку и наши люди свяжутся с вашими.
Тред (@jin_nin)
@jsunderhood Так должен был начаться понедельник, а уже потом вот это вот все про фреймворки
Тогда мы бы не смогли вскрыть основную проблему фронтенда. twitter.com/prosazhin/stat…
MAM - это инфраструктура для быстрой и ненапряжной разработки библиотек и приложений.
Порядок в репозитории, минимизация бандлов, автоматичесная загрузка зависимостей, правильное упорядочивание кода и тестов, девсервер - вот это всё.
Вводная по ней тут: github.com/nin-jin/HabHub…
$mol - разработанный в MAM экосистеме фронтенд фреймворк для RAD разработки WEB приложений.
Он не имеет выделенного ядра и состоит из множества ортогональных микромодулей. Модули самые разные, от библиотеки ассертов, до виджета графиков.
Куча готовых виджетов уже в комплекте. Можете их просто использовать, как угодно их кастомизировать под себя, или же запилить свои с нуля. Фреймворк сейчас покрывает следующие уровни потребностей:
Гибкая библиотека
Разумный фреймворк
Удобный конструктор
Метим в платформу.
Из интересного, у нас есть самая шустрая библиотека для рисования графиков $mol_chart:
bench.hyoo.ru/app/#bench=htt…
Причём использует она SVG, а не Canvas.
Ещё у нас есть голосовое управление. Попробовать его в деле можно в приложении, через которое я показываю слайды на выступлениях: slides.hyoo.ru
Есть простой редактор с подсветкой синтаксиса. Попробовать его в деле можно на странице view.tree компилятора: tree.hyoo.ru
Нет лучше способа изучить этот язык, чем своими глазами видеть во что он компилируется.
Тред (@jin_nin)
@jsunderhood Мде) pic.twitter.com/goLZDPOpXM
Обратите, кстати, внимание, что когда что-то пошло не так, приложение показало не белый экран смерти, а сообщение об ошибке, и выключило сбойный виджет. twitter.com/dmtrKovalenko/…
Из крутых фич в $mol есть виртуальный рендеринг. Прикладной программист может даже не знать про её существование, но всё-равно создавать отзывчивые приложения, выводя в них портянки данных.
В деле его работу можно глянуть тут: mol.js.org/app/demo/-/#de…
Привет мир на разных фреймворках. Был бы тут Svelte - он бы всех уделал, конечно.
Angular - прожорливый работник интерпрайза
React - шаткое нагромождение библиотек
Vue - мелкий любитель патчить обезьян
Svelte - ещё ходить не умеет, но уже сосёт
$mol - и на дуде игрец
Разумеется у нас своя система реактивности. Это типа MobX скрещенного с Saspense API, только круче. Тут не просто свойства, а двусторонние каналы.
Подробнее об этом тут: github.com/nin-jin/HabHub…
Я критикую Реакт не потому, что он меня покусал в детстве. А потому, что вижу, как все ломанулись по тупиковому пути. Создавать полный VDOM и.. реконцилировать. Подключать всё подряд и.. тришейкать. Тащить всё в общий стор и.. локально мемоизировать. Создаём сами себе проблемы.
Если заинтересовались - домашняя страница $mol: github.com/eigenmethod/mol
Задать вопрос по $mol и MAM: t.me/mam_mol
Подписывайтесь на мой твиттер: twitter.com/jin_nin
Но не обещаю, что буду туда часто писать.
По всем остальным вопросам: t.me/nin_jin
Попробуем похожую активность, но в телеге, а то твиттер вымораживает?
Каждый день случайный подписчик становится рупором фронтенда. Оффтопить можно, только "тихими" постами. Совсем спам будет пресекаться. Пишите, что было бы интересно другим фронтендерам.
t.me/frontend_happe…
$mol:
- Нет подсказок/рефакторинга во view.tree
- Стандартные компоненты не вылизаны
- Статьи лишь на русском и устарели
- Документация лишь английском
- Тесты/документация есть не на всё
- Нет онлайн песочницы и кукбука
- Нужно изучать новые идиомы и расширять сознание
@jsunderhood @rage_monk @went_out Тогда нужно либо "сп, которая разбирается в технических деталях" — что дороговато. Либо на скриншоте нужны логи, что делает подход скриншотов неактуальным — сентри лучше. Опять же сентри решает проблему "мы знаем, чиним" и "о, новое". + это бесплатно по сравнению с техподом
Для классификации скриншотов много ума не надо.
Вы от кого таким способом защищаетесь-то? Стыдно что ли показать ошибку как она есть? Я вот сейчас еду в поезде и у меня твиттер вообще ничего не пишет. Просто глючит по страшному.
Починят ли они это когда-то? Да нифига. twitter.com/nikmostovoy/st…
Если запрос прошёл, но связь оборвалась твиттер оставляет форму открытой. Тыкаешься как тупой в кнопку "отправить", а прогресс бар "откатывается". Написал бы он честно ответ сервера "такой твит уже был отправлен", можно было бы хоть что-то понять.
Понедельник
Кстати, на тему длинных имён: github.com/eigenmethod/mo…
Всем привет,
Я Сергей (@_sergeikriger) - фронтенд разработчик из Германии и большой фанат доступного веба. По приглашению @DmitryMakhnev эту неделю (с 16 по 22 марта) я буду вести jsunderhood.
Поехали!
Просмотрел посты на канале за этот год - ребята жгут, конечно. Ощущение, что ошибся дверью. Хардкора на канале было много, мне же больше хочется поговорить на темы около фронтенда и разработки, которые, иногда, не менее важны.
Живем не в вакууме, всегда есть что-то вокруг.
Я не считаю себя супер разработчиком, но за те 5 лет, что я работаю в индустрии, накопился кое-какой опыт, которым с удовольствием поделюсь.
Надеюсь, найдете для себя что-то полезное. Если что-то покажется не интересным, смело проходите мимо.
Писать буду не очень много, потому что, во-первых, "кр. сестр. тлнт", а во-вторых, все давно сказано, чего повторяться. Будет несколько тем по дням в отдельных тредах. Вопросы и комментарии приветствуются.
Вот список тем на неделю:
- Доступность
- Около фронтенда
- Выступление на конференциях
- Soft skills (мой приоритет)
- Работа в Германии
- Стать разработчиком после 30 и выжить
- Digital Minimalism и почему это важно
Let's go!
Сегодня говорим про доступность.
На этом канале какое-то время назад @ta_fokina очень здорово разобрала эту тему. Поэтому повторяться не буду, от себя добавлю некоторые вещи, которые считаю важными.
Доступность - это не фича, которую можно либо иметь, либо нет. Доступность - это естественное состояние сайта, когда им могут пользоваться абсолютно все.
Доступность не должна быть бездумной - если Drag-end-Drop компоненты не доступны для незрячих по своей сути, найдите способ дать пользователям другую возможность сделать то, что делает Drag-end-Drop.
Бизнес пока не готов активно двигаться в сторону доступности и это понятно - этой темы никогда не было на виду и тут на тебе - резко вошла в тренд.
Не стоит ждать пока требования к доступности спустятся сверху, но просто каждый день делать свои проекты немного доступнее.
Я лично был свидетелем того, как несколько разработчиков ушли из компании, когда клиент попросил седлать большой и старый сайт доступным.
Понятно, это не тривиальная задача и люди просто не захотели учиться новому.
Учите доступность сейчас - скоро это будет стандартом.
Доступность - это часть профессии как JavaScript, React, flexbox, grid и еще тысяча вещей. Доступность надо учить, а выучив, пользоваться.
По-моему, очевидно...
Чтобы по настоящему понять важность доступного веба, пообщайтесь с людьми с разными ограничениями, посмотрите как они пользуются интернетом. Вопрос "зачем" отпадает сразу.
Если не можете лично пообщаться с людьми с ограничениями, есть несколько ресурсов на эту тему. Важно быть в теме, когда разрабатываете доступные интерфейсы.
Дальше в треде ссылки на пару таких ресурсов, которыми лично пользуюсь.
Youtube канал с миллионными просмотрами от слепого блоггера Molly Burke. Девица просто жжет!
.
.
.
youtube.com/user/MollyBurk…
Тифлострим на канале tiflo.info - передача про незрячих и не только. Посмотреть на мир со стороны не зрячих, узнать их проблемы с интернетом, найти решения проблем - все там.
Большой респект @Olegshevkun.
.
.
.
tiflo.info/category/strea…
Истории незрячих людей на канале @aliya_nurullina "Типичный незрячий". Много историй на разные темы, включая интернет.
.
.
.
vk.com/tipicalblind
Вместо заучивания известных паттернов доступных интерфейсов, попробуйте поставить себя на место людей с ограничениями. Пройдитесь по сайту без мышки, выключите экран и включите скринридер, попробуйте режим свитч кнопки.
Гораздо важнее понять ЗАЧЕМ, нежели КАК.
Есть мнение, что доступность нужно уметь "продать" бизнесу, чтобы получить на это бюджет.
Нет!
Доступность это часть профессии и вам не нужно разрешение на верстку доступного сайта, также как на верстку сайта адаптивного, кроссбраузерного или быстрого.
Вы (не начальник) должны быть инициатором доступной верстки. Вас наняли как специалиста, у вас экспертиза и нет необходимости спрашивать что и как вы должны делать.
На первых порах доступность занимает какое-то время. Научитесь верстать доступные интерфейсы быстро и у бизнеса не будет вопросов, мол "зачем тратить время на ерунду".
При оценке времени на разработку включайте туда время на доступность по умолчанию и умейте аргументированно объяснить что и сколько времени займёт.
Тред (@jin_nin)
Отвечать буду на только на конструктивные комменты, весь треш будет вежливо игнорироваться.
Если хотите что-то спросить лично - @_sergeikriger в личку.
Тред (@jin_nin)
@jsunderhood Общался со слабовидящим человек достаточно долгое время, пока он не переехал в другую страну. В большей степени благодаря ему понял, насколько неудобными бывают интерфейсы в целом. А благодаря @pepelsbey понял, что делать интерфейсы для людей не сложно. Их просто не нужно ломать.
Это да 👍 twitter.com/clickrouc/stat…
Вторник
Привет, сегодня говорим на темы около фронтенда.
Знать JS/CSS/HTML это must have для фронтендера, но чтобы комфортно существовать в компании, нужно также знать и окружение.
В этом треде о том, какие знания вокруг фронтенда нужно иметь и насколько стоит во все это углубляться.
Опережу тех, кто уже подумал "ну началооооось..." и определю диапазон сегодняшней темы - это для тех, кто только-только пришел в разработку, немного освоился в JS/CSS/HTML и потихоньку начал смотреть вокруг.
Если вы матерый волчара, скорее всего вы все это знаете.
"Ээээ, хардкор давай, мясо с кровью, чтобы капало!.."
Сори, сегодня не про это. На сегодня тут 7,388 человек и, поверьте, тех для кого AST, VDOM и Interface Segregation это слова из другого мира, достаточно.
Кому интересно - вперед, кому нет - будет еще $mol на вашей улице.
Если в компании нет привычки к менторству джунов, то часто человек пришел, поднаторел чуток в своей песочнице и не знает, куда идти дальше. Для компании все равно (работает же), а для карьеры беда.
Чтобы быть полезным для компании (особенно для маленькой), надо быть в меру универсалом, то есть уметь делать чуть больше, чем фронтенд. Не обязательно быть экспертом во всем, но понимать надо.
Быстрее, дальше, глубже… Ощущение, что это не разработка, а спорт, замедлился - проиграл. Отсюда стресс, чувство несостоятельности и выгорание.
Знать, где нужно быть экспертом, а где просто понимать о чем речь - это важно.
Фронтенд - это индустрия со многими специализациями внутри. ЗНАТЬ ВСЕ И СРАЗУ не получится, лучше сконцентрироваться на том, что интересно и быть В КУРСЕ того, что происходит рядом.
JavaScript гуру, способный поправить интерфейс и задеплоить проект.
Верстальщик железобетонных интерфейсов со знанием React.
Надежный фронтенд разработчик, который может написать простой mock server на Nodejs.
Ну понятно о чем речь...
Дальше будет перечисление технологий/тем, которые хорошо понимать любому фронтендеру, от мидла и выше. Выбор основан на моем личном опыте и, таки-да, вы не обязаны со всем соглашаться - это просто мое мнение.
Погнали...
Фронтендер должен...
...знать Linux на уровне навигации, работы с файлами, поиска с find и grep, а также основную структуру файлов в OS вроде .bashrc, /etc/hosts и т.д.
Фронтендер должен...
...уметь доставать данные из наиболее ходовых баз. Пускай даже примитивными запросами типа
SELECT * FROM table WHERE date BETWEEN [yesterday] AND [today];
Иначе придется каждый раз кого-то просить.
Фронтендер таки должен...
...знать Vim, ну хоть самые основы. Открыть/закрыть файл, передвигаться по документу, скопировать текст без мышки - хотя бы это.
Всегда казалось, что это лишнее, пока не пришлось дебажить GUI у робота на Linux сервере.
Фронтендер не должен...
...падать в обморок от слов кластер и kubernetes и хотя бы смутно понимать, что это не название каких-то азиатских блюд.
Фронтендер не обязан…
…писать на go или haskell, но должен понимать в чем разница между ними и основные области их применения.
Фронтендер должен...
...знать bash на уровне сэкономить время на печатание комманд. Если сможете прокинуть параметры, еще лучше.
Фронтендер должен...
...уметь быстро поднять проект в любом окружении. Docker в помощь.
Фронтендер должен...
...уверенно понимать процесс деплоя - куда что уходит, где хостится, как доходит до конечного пользователя.
Фронтендер должен...
...уметь проследить HTTP запрос через все сервисы и знать какие данные откуда берутся.
Фронтендер должен...
...уметь нарисовать схему системы (или ее части), в которой он работает. Без деталей, но чтобы понимать общую архитектуру. Это помогает говорить с командой на одном языке.
Фронтендер просто обязан…
…читать на английском. Смогли разобраться с Redux и GraphQL, умеете обращаться с webpack, а английский выучить не можете - ну не верю!
Фронтендер должен…
…постоянно инвестировать в себя. Опыт показывает, что сотни потраченные на книги, курсы или правильный софт довольно быстро возвращаются тысячами.
Фронтендер должен…
…уметь настроить (ну хоть примитивно) CI/CD на проекте. Свой же код будет легче не за факапить, если есть правильный пайплайн.
Парадоксально, но фронтендер не обязан…
...вести твиттер и уж точно наличие твиттера это не показатель успешности или квалифицированности. Нравится узнавать новости через RSS, email подписку или еще как-то - пожалуйста, почему нет.
Фронтендер не обязан…
...иметь собственные opensource проекты или контрибьютить в другие. Никто не спорит, что это полезно, но если компания не берет хорошего разработчика из-за плохой статистики на гитхабе, может ну ее такую компанию?
Продолжая предыдущий твит: можно ли быть неплохим разработчикам без участия в opensource проектах? Думаю, да.
Тред (@jin_nin)
Кажется прошлая неделя всех не хило взбударажила - люди все еще спорят в комментах.
@jin_nin вы просто $molодец 👍💪
Среда
Привет!
3-й день на карантине и сегодня пару слов про конференции и митапы, как важную составляющую профессионального развития разработчика.
Какое-то время назад после одного успешного проекта на работе, понял, что есть чем поделиться с сообществом в теме доступности. Практически на спор с тимлидом начал выступать на конференциях и митапах.
Я не считаю себя уж очень хорошим докладчиком. В моем случае талант (которого нет) относительно неплохо компенсируется содержимым докладов и тщательной подготовкой.
Чего, к слову, достаточно для неплохого (но не для отличного) доклада.
Если есть что рассказать, очень рекомендую выступить с докладом хотя бы раз. И опыт получите, и знаниями поделитесь. Опять же новые лица на сцене это всегда здорово.
Как сказал мой коллега, который сам выступал на больших конференциях, если за 15 минут до выхода на сцену тебя потряхивает, это нормально.
По личному опыту дрожь проходит минут через 5-6 (если еще живой).
Если идёте на многофункциональную конференцию типа @RITFestRussia, очень советую не ограничиваться только фронтендом. Загляните к соседям на девопс, project management или куда-то ещё - расширяет кругозор.
Из последних спикеров, которых я слышал, но до которых мне как до луны, это Денис Мишунов (@mishunov), Вадим Макишвили и Илья Климов (@xanf_ua).
Не знаю, парни, как вы это делаете, но это просто огонь!
Не зависимо от умения держаться на сцене и ораторских способностей, есть 2 качества, которые отличают хорошего докладчика:
- разбираться в теме
- быть интересным
Как правило, оба этих качества одновременно встречаются не часто.
CDD - Conference Driven Development ©
Выступление это очень хороший стимул углубить знания и чему-то научиться. В процессе подготовки узнаешь столько нового.
Никто же не хочет выглядеть идиотом на сцене.
Про Diversity на конференциях
Очень хорошо понимаю тему, но, по-моему, тут налицо подмена понятий.
Равный доступ разных людей НА ОДИНАКОВЫХ УСЛОВИЯХ часто путают с ОБЯЗАТЕЛЬНЫМ УЧАСТИЕМ спикеров из недостаточно представленных групп (underrepresented).
Я ЗА diversity и это ОЧЕНЬ ЗДОРОВО, что в программе конференций могут быть представлены совершенно разные спикеры из разных социальных групп. Штука в том, что помимо выхода на сцену, хорошо бы еще, чтобы и доклад был интересный (что не всегда так).
А что, если дать возможность подаваться АБСОЛЮТНО ВСЕМ и выбирать ЛУЧШИЕ ЗАЯВКИ по качеству тем и по профессионализму докладчиков?
Понятно, что мнение не популярное, но от diversity по принуждению уж сильно разит совком: чтобы и врачи, и учителя, и обязательно кто-то из народа.
Те люди, с которыми встречался на конференциях, это, наверно, самое лучшее, что со мной случилось за последний год. Общение на эвентах поднимает мотивацию в разы.
Нетворкинг это крутая тема.
Тред (@jin_nin)
Четверг
Привет!
В очередной день "околофронтендной" недели говорим про soft skills. Тема уже довольно хорошо исследована, поэтому просто приведу список из 7 софт скилов наиболее актуальных лично для меня.
#1
Умение говорить "нет".
Например, простое умение отказаться от задачи, если она вне вашей компетенции.
- Слушай, сервак полетел, не посмотришь?
- Нет.
Исключением, наверно, может быть челлендж или то, что нужно для роста.
#2
Умение оценивать работу.
Знать свои возможности уметь точно оценить время на задачу и уровень сложности. Если ваша оценка ниже, чем у коллег, значит ниже, все работают по разному. Лучше так, чем потом в стрессе провалить дэдлайн.
#3
Умение слушать и слышать.
Не продавливать свою линию, а услышать оппонента и аргументированно либо согласиться, либо нет. По моему опыту процентов 40-50 проблем в коммуникации из-за неумения слушать.
#4
Умение находить компромисс.
Особенно помогает, когда вводишь начинающего разработчика в проект или при парном программировании. Редко когда задача решается только одним способом, иногда полезно и уступить.
#5
Умение делать работу комфортной.
Если вместо недели на задачу нужно полторы (и они есть) - просите полторы. Глупо тратить полжизни на работу, которая не приносит удовольствие, а только стресс. Результат, конечно, важен, но и процесс тоже.
#6
Умение конструктивно спорить.
Не упираться лбом и повторять одно и тоже, а найти правильные слова для конкретного человека. Считаете свой подход лучше, сумейте объяснить почему.
#7
Умение видеть проблему целиком.
Не просто пилить свой модуль, а знать, что он делает для системы, в которой он находится, и какие задачи решает эта система. Бывает очень полезно проследить всю цепочку от бизнес требований до написания кода.
Как не смешно, но хорошая память тоже soft skill.
Босс: С этого дня на общие собрания запрещено приносить телефоны.
Через 2 недели
Босс: Сделайте фотографию с доски, я сотру.
Я: У меня нет с собой телефона.
Босс: Как так? (достает свой и фоткает)
Постоянно с этим сталкиваюсь.
Несколько ссылок по теме.
"Осознанное развитие и карьера" (очень интересно)
.
.
.
youtube.com/watch?v=47Ef2f…
"The state of soft skills" от @frontendweekend
.
.
.
youtube.com/watch?v=N69EeX…
Тред (@jin_nin)
Пятница
Привет,
Сегодня говорим про работу в Германии - что, как, стоит ли. Сразу скажу, что в России разработчиком не работал, сравнивать не с чем.
Если есть желание посмотреть мир, пожить еще где-то и посмотреть как живут люди, с профессией разработчика это не так сложно сделать. В Европе вообще, а в Германии в частности, есть большая нехватка веб программистов.
Есть мнение, что переезд заграницу это навсегда - уехал и с концами. А что если не "уехать", а "съездить", не "жить", а "пожить"? Мир глобальный, где хотите, там и живите. Вернетесь или нет - не важно, но опыт получите бесценный.
Если уже есть и профессия, и опыт, то уехать работать в Германию не так сложно. Есть программа Blue Card, по которой можно относительно быстро получить визу. Если подходите по всем критериям (о них дальше), то весь процесс может занять от нескольких недель, до пары месяцев.
Чтобы получить Blue Card, нужно 2 вещи:
- высшее образование (желательно по профессии, но не обязательно)
- контракт или гарантия контракта с немецкой компанией с зарплатой не меньше 43,056 евро в год (на 2020, меняется каждый год)
В остальном все дело техники.
По Blue Card есть кое-какие детали, которые надо знать. Тут обсуждать нет смысла, есть много отличных ресурсов по теме. Дальше дам ссылки на те сайты, которыми сам пользовался.
Make it in Germany
Все, что надо официально знать про Blue Card со ссылками на источники.
.
.
.
make-it-in-germany.com/en/visa/kinds-…
Surfin Birds
Блог об иммиграции в Германию от @igor_lkm и его супруги. Дизайн, конечно, идиотский, но контент на 5+. Их личный опыт со всеми деталями.
.
.
.
surfin-birds.ru
Работу можно искать в разных местах, вот мой список:
xing.com
linkedin.com
de.indeed.com
Мне больше везло с linkedin.
Как правило процесс устройства на работу в Германии состоит из нескольких шагов (мой опыт):
- созвон с HR
- интервью по профилю
- техническое задание
- разговор с командой
- интервью с начальником
- подписание контракта
Дальше подробно про каждый шаг.
Созвон с HR
Все стандартно - тех стэк, сильные стороны, языки, инструменты, дурацкие вопросы типа "вы занимаетесь фронтендом, а на Java пишете?" и пр. Думаю HR везде одинаковый.
Этот барьер существует и его надо пройти.
Интервью по профилю
Тут все интереснее. Как правило час разговоров на технические темы: рассказать про проекты, интересные задачи, которые решали, предпочтения и пр. HR уже нет, а есть кто-то из старших разработчиков или CTO.
К этому шагу надо готовиться.
Техническое задание
По результатам тех интервью присылают задачу с условиями вроде
- написать на реакте поиск с Google Books API с автокомплитом
- сверстать часы на SVG и JS
- по шаблону сверстать сайт на любом стеке
Тут надо выложиться, будут проверять. Им же с вами работать.
Разговор с командой
Если прошли тест, могут пригласить в офис, поговорить с будущей командой, обсудить ваше решение теста за ланчем (ну или по скайпу). Будьте готовы объяснить что, почему и зачем.
Кстати, на этом шаге вы тоже можете понять, что команда "не ваша" и отказаться.
Разговор с командой (продолжение)
Был случай, когда после разговора с командой мне отказали, хотя тест сдал на отлично и в срок. Кажется, не понравился одному разработчику, с которым должен был работать в паре.
Так и не понял почему.
Интервью с начальником
Условия работы, контракт, планы на будущее и пр. Это и есть тот берег, на котором надо договариваться - не стесняйтесь спрашивать.
Контракт
В Германии считается хорошим тоном обсуждать контракт до подписания, хотя в больших корпорациях они могут быть стандартные. Однажды я попросил убрать из контракта один пункт и убрали.
Зарплата
Какую запросите, такую и дадут (в разумных пределах, конечно). Больше рыночной редко, если вы не гений, меньше - запросто. Поэтому сумму в голове надо держать еще до интервью.
Pay inequality is a big problem in tech, especially for underrepresented groups like women and minorities. The best way you can help is by sharing yours. I’ll go first. 🏫: B.A. - C.S. ⏳: 5.5 years 🏷: Staff/G06 🌎: NYC 💸: $205k base, $500k equity over 4 yrs #KnowYourWorth
Недавно был интересный тред по зарплатам. Не знаю что на людей нашло, но все вдруг начали постить кто сколько получает.
.
.
.
twitter.com/ZacSweers/stat…
В Германии не принято обсуждать зарплату с коллегами, а иногда это может быть и запрещено по контракту. Может запросто оказаться что ваш коллега получает много больше вас - просто запросил больше.
Чего в немецких компаниях нет, так это прямого фидбэка. То есть всегда "все отлично", а потом бах и куча претензий. Я, чтобы избегать таких случаев, всегда очень подробно все уточняю и напрямую запрашиваю фидбэк.
Ходят даже шутки про славянскую прямоту, видимо это у нас в крови.
В Германии нет разделения на верстку и программирование. Там все фронтендеры и должны уметь и то, и это. Давно мечтаю найти компанию, в которой можно будет только верстать, но, видимо, не случится.
Короче, завидую всем верстальщикам.
Недавно наткнулся на отличный канал Senior Software Vlogger про работу в Германии и не только. Там всего больше и подробнее. Рекомендую.
.
.
.
youtube.com/user/rojkovdima
На этом заканчиваю свою неделю на jsunderhood, спасибо всем, кто читал.
Буду проверять комменты до воскресенья вечера. По всем вопросам после пишите в личку (@_sergeikriger).
Всем пока!
Тред (@jin_nin)
