Пожалуйста.
По возможности лучше, конечно же, не писать, а взять готовое. Мне, например, нравится ещё semantic-ui.
Но бывает, что готовое не подходит, нужны свои стили или сверстать компонент по-другому, свои компоненты со своими фичами, и тогда готовое может не подойти.
В моём случае у нас есть некий шаблон со своими стилями и вёрсткой, который используется в нескольких системах и все они выглядят единообразно. Автор шаблона его забросил. Мы использовали его под Angular.js. Новые системы мы будем писать на React + мигрируем некоторые старые, а стили менять не хотим, чтобы сохранить единообразие и вообще мигрировать постепенно и незаметно для пользователя. Из этих требований и рождается наша библиотека компонентов на React. Благо мне верстать и писать css не надо (по минимуму), просто компонентов напилить, а ещё можно подсматривать в готовые бибилотеки.
Если посмотреть на опыт других компаний, то много кто пишет свой UI-kit. Навскидку JetBrains, Яндекс, Тинькоф, Сбербанк — правда, у этих ребят толпы разработчиков, отдельные команды под это, могут себе позволить.
При должной сноровке и опыте, я не сомневаюсь, что можно и из CRA стартовать библиотеку. Кстати, CRL базируется на CRA — тянет за собой react-scripts-ts, который в свою очередь основан на react-scripts, правда старой версии. Я попробовал перетащить это на последний react-scripts и не смог натянуть сову на глобус. Пришлось распотрошить и собрать сову самостоятельно.
Далее. Существует 2 способа перегнать TS в ES5 — tsc и babel 7. CRA, CRL и tsdx используют именно последний. А babel 7 в свою очередь имеет ряд ограничений для такой задачи, что не слишком круто, но и не фатально в общем случае. Это влечёт за собой обязательную опцию компилятора — isolatedModules, которая в свою очередь не хочет работать вместе с declaration-опцией, а мне таки хотелось генерировать `d.ts`. Вот тут предлагают использовать 2 конфига, но что-то у меня рука тянется к лицу от этого.
Про свои неудачи я написал под спойлером «А потом что-то пошло не так...».
Также в той заготовке, что я сделал руками, не используется babel для сборки TS. Однако, да, он есть в devDependencies. Это из-за `webpack-blocks` (говорит есть в его peerDependecies, хочу его, не могу), который в свою очередь используется в `webpack.config.js`. Что? Webpack? У нас же вроде Rollup. Ага. Для самой библиотеки Rollup, вот только StoryBook не может сам без конфига для своего внутреннего webpack работать с TS-компонентами. Такие дела. Может быть можно и проще, но я пока не вижу больших проблем от этого — это же devDependencies, к пользователям эта орава не поедет.
Хороший вариант, спасибо. Дополнил статью. Есть недостаток — не нашёл способов как-нибудь расширить конфигурацию или сделать eject. Про это есть issue. Конечно, зависит от проекта. Для многих это может быть не критично.
Согласен, это можно записать в use-case кроссплатформенности. Однако, по факту, получается, что в тестах вы тестируете интеграцию с небоевой базой и это может как-нибудь аукнуться. Наверное, скорее всего, с этим большинство проектов не столкнуться, но вероятность есть.
А она и не нужна чаще всего. Это очень редкая операция. Часто видел, слышал, принимал участие в переезде на NoSQL, а вот про переезд на другую реляционную базу — это событие века. И потом, а почему мы выбрали БД, но не используем её фишки? Может они больше профита нам дадут здесь и сейчас, чем мифический переезд на другую базу хз когда в будущем? Кроме того, читать патчи на знакомом и привычном всем SQL намного приятнее, чем на очередном dsl. Конечно же, это ИМХО, в неопределившихся стартапах переносимость мб и нужна.
Полностью согласен с вами. Кроме того, Паскаль очень простой язык, а новичку в самом начале надо набраться опыта с самыми базовыми конструкциями подавляющего большинства ЯП — ветвления, циклы, функции, массивы, ввод-вывод, указатели. В нём больше и нет ничего, а значит ничего не будет отвлекать и вводить в заблуждение. Никаких классов, адских шаблонов, исключений, декораторов и т.д. Писать простые первые программы на нём сплошное удовольствие. И переходить в другие языки после Паскаля легко и приятно
Я имею в виду, что разработчик за зарплату — это про решение проблем работодателя в первую очередь. В этом контексте вообще не важно, будет ли получено удовольствие от языка, ведь нужно проблему решить.
Я вот не фанат интерпретируемых языков с динамической типизацией, но если надо быстро набросать утилитку, которую не надо будет веками поддерживать, то почему бы и не воспользоваться одним из этих товарищей?
Тут, конечно, можно это решить старательно подбирая место работы под любимый язык. Однако не всегда работа — это только про язык и набивание кода. А иногда и на работе всё может неожиданно поменяться, и проект, и язык.
P.S. Но как разработчик, я вас прекрасно понимаю. Наверное у большинства из нас есть любимый и избегаемый язык.
Никто не говорит, что надо знать досканально несколько языков или я за институт освоил все 8. Чаще всего язык надо знать настолько, насколько это нужно для решения задачи.
Например, я в основном пишу на Java лет 5, а Python я знаю на уровне «за 24 часа», но для всяких мелких скриптов для автоматизации рутины и генерации каких-нибудь файлов, отчетов, статистики я выбиру Python и решу задачу быстрее и проще. frontend я тоже на Java писать не буду.
После того, как я попробовал n-язков ещё в ВУЗе, начать писать на n+1 не видится большой проблемой. Вернуться к одному из n, углубиться в него и перейти в сферу с его использованием от уютной Java тоже. Как писал Макконнелл: «Программируйте с использованием языка, а не на языке.»
Извините, видимо нечетко выразился. К вам лично это никак не относится. Можно смело заменить «вы» на «читатель».
Отношение прямое — начальные возрастные рамки автор берёт приближённые к своему возрасту — 35-40, а возраст с 40 до 55 лет приводится как противопоставление. Т.е. автор адресует свою статью читателям (не только, а в первую очередь) 35-40 лет и обращает их внимание на то, что с 40 до 55 лет они будут ещё плодотворнее, чем сейчас и всё ещё впереди.
Это только моё понимание статьи. Есть также предположение, что автор использовал 35-40 только исходя из своего возраста и рамки в этой статье весьма условны (35+) и верхней границы нет — она будет одинаково полезна всем возрастам.
Рискну предположить. Я так понял, что если вам сейчас 35-40 лет и вы задумались над этим вопросом, то бросьте эту фигню, ибо «возраст с 40 до 55 лет для специалистов инженерных профессий самый плодотворный» — т.е. вы ещё даже не вошли в ваш самый плодотворный возраст.
Язык программирования — это просто инструмент. То, что преподают в ВУЗах на Паскале, на нём прекрасно пишется. У нас это были базовые алгоритмы. Более того, это первый семестр. Я за 5 лет вуза на 8 языках успел пописать, из которых Scala, Python и Go (2014 год) мне предложил преподаватель. Менять язык для разработчика не должно быть проблемой.
Сразу скажу, что в игру не играл, ибо то, что я видел в обзорах и стримах, не вызывает желания платить. Ладно глюки, кого сейчас не глючит после релиза, но ведь мир реально пустой. Что там делать, кроме как ходить и тупо мочить и мочить монстров бесконечно? Это просто мочилово вместе с друзьями? Ну такое, на любителя. Fallout 4 совсем не фонтан, но там хоть какие-то квесты были, какая-то движуха. Чем 76 лучше 4, тем более NV? Что-то такое эдакое добавили с момента выхода?
Я даже не знаю, в 2019 году рассказывать про геттеры-сеттеры и как ими пользоваться.
Допустим ваша целевая аудитория абсолютные новички, допустим вы случайно не заметили этой уймы статей про Lombok на хабре. Но, чёрт возьми, как же у меня подгорает, когда для новичков в статьях пишут о «магии», что всё работает волшебно, просто поставь аннотацию, «Просто, быстро, удобно». Хотите рассказать про Lombok? Так расскажите как он работает внутри, расскажите про Annotation Processing Tool, аннотацию поставить много ума не надо. Возможно вы сами в профессии недавно, но так это же какой отличный повод разобраться как оно устроено, как там работает внутри, что скрывают эти «волшебные» аннотации. Сходите к Lombok на гитхаб, посмотрите как оно устроено, разберитесь хотя бы с одной простейшей аннотацией. Вот это была бы статья!
P.S. и да, Lombok умеет генерировать билдеры, «магическая» аннотация в наличии.
Я давно не слежу за выходом игр. Можете подсказать пару примеров из «огромного количества сложных, многогранных игр», которые сравнимы с третьими Героями? Уже вышел достойный «героезаменитель»?
Извините, я понимаю, что IT полно англицизмами и это моё субъективное мнение, но
онбординг
моббинге
тим
немного усложняет восприятие статьи на русском языке. Может быть статья читалась бы легче, если бы такие откровенно английские слова были заменены на аналоги из русского языка?
А в modelMapper можно посмотреть получившиеся мапперы? Он их генерирует или как? Рефлексирует в runtime как Dozer? Если что-то не маппится, то он в runtime упадёт или при компиляции? Хотелось бы увидеть описание того, как он работает под капотом, подробностей реализации. Чем он лучше других решений?
MapStruct прекрасен тем, что по интерфейсам с аннотациями(это поле в вот это поле, если есть разногласия) или абстрактным классам (если надо сделать что-то больше, чем просто «из этого поля в это») просто сгенерит реализующий класс, где будет тупо использование геттеров-сеттеров и создание объектов. Как будто вы писали это влоб руками. Сгенерированный конвертер можно тестить, можно дебажить. Он просто используется в runtime. Никаких оверхедов на рефлексию. Если что-то не маппится, то падает при компиляции.
Может несколько параллельный к теме статьи вопрос. Однако, у java-господ нет усталости от обилия аннотаций в коде?
Казалось бы, делает жизнь проще, столько работы за собой скрывают. Но вот приходишь в какой-нибудь типовой проект с Lombok, Spring, Hibernate и что-нибудь ещё. Весь код просто увешен как ёлка с ног до головы аннотациями.
А молодые неокрепшие умы восхищаются, для них кругом магия, понять которую они не спешат. Зачем? Поставь аннотацию, всё сразу заработает. Не работает? Не хватает какой-то аннотации.
А мне всё больше кажется, что есть в этом что-то костыльное. Повышается ментальная нагрузка — глядя на аннотацию, надо вспоминать, что она добавляет или какую аннотацию ещё надо добавить. Как будто ключевых слов в языке прибавилось раза в два. Аннотации не нарушают принцип «явное лучше неявного»?
К Lombok, наверно, тут меньше всего претензий — он порождает довольно простой код, но тоже вносит свою лепту в общую копилку. Хотя можно же просто жмакнуть пару клавиш в IDEA для генерации геттеров/сеттеров и проч.
Всё чаще начинает казаться, что уж лучше я руками.
По возможности лучше, конечно же, не писать, а взять готовое. Мне, например, нравится ещё semantic-ui.
Но бывает, что готовое не подходит, нужны свои стили или сверстать компонент по-другому, свои компоненты со своими фичами, и тогда готовое может не подойти.
В моём случае у нас есть некий шаблон со своими стилями и вёрсткой, который используется в нескольких системах и все они выглядят единообразно. Автор шаблона его забросил. Мы использовали его под Angular.js. Новые системы мы будем писать на React + мигрируем некоторые старые, а стили менять не хотим, чтобы сохранить единообразие и вообще мигрировать постепенно и незаметно для пользователя. Из этих требований и рождается наша библиотека компонентов на React. Благо мне верстать и писать css не надо (по минимуму), просто компонентов напилить, а ещё можно подсматривать в готовые бибилотеки.
Если посмотреть на опыт других компаний, то много кто пишет свой UI-kit. Навскидку JetBrains, Яндекс, Тинькоф, Сбербанк — правда, у этих ребят толпы разработчиков, отдельные команды под это, могут себе позволить.
Далее. Существует 2 способа перегнать TS в ES5 — tsc и babel 7. CRA, CRL и tsdx используют именно последний. А babel 7 в свою очередь имеет ряд ограничений для такой задачи, что не слишком круто, но и не фатально в общем случае. Это влечёт за собой обязательную опцию компилятора — isolatedModules, которая в свою очередь не хочет работать вместе с declaration-опцией, а мне таки хотелось генерировать `d.ts`. Вот тут предлагают использовать 2 конфига, но что-то у меня рука тянется к лицу от этого.
Про свои неудачи я написал под спойлером «А потом что-то пошло не так...».
Также в той заготовке, что я сделал руками, не используется babel для сборки TS. Однако, да, он есть в devDependencies. Это из-за `webpack-blocks` (говорит есть в его peerDependecies, хочу его, не могу), который в свою очередь используется в `webpack.config.js`. Что? Webpack? У нас же вроде Rollup. Ага. Для самой библиотеки Rollup, вот только StoryBook не может сам без конфига для своего внутреннего webpack работать с TS-компонентами. Такие дела. Может быть можно и проще, но я пока не вижу больших проблем от этого — это же devDependencies, к пользователям эта орава не поедет.
Я с некоторых пор стал предпочитать Testcontainers
Я вот не фанат интерпретируемых языков с динамической типизацией, но если надо быстро набросать утилитку, которую не надо будет веками поддерживать, то почему бы и не воспользоваться одним из этих товарищей?
Тут, конечно, можно это решить старательно подбирая место работы под любимый язык. Однако не всегда работа — это только про язык и набивание кода. А иногда и на работе всё может неожиданно поменяться, и проект, и язык.
P.S. Но как разработчик, я вас прекрасно понимаю. Наверное у большинства из нас есть любимый и избегаемый язык.
Например, я в основном пишу на Java лет 5, а Python я знаю на уровне «за 24 часа», но для всяких мелких скриптов для автоматизации рутины и генерации каких-нибудь файлов, отчетов, статистики я выбиру Python и решу задачу быстрее и проще. frontend я тоже на Java писать не буду.
После того, как я попробовал n-язков ещё в ВУЗе, начать писать на n+1 не видится большой проблемой. Вернуться к одному из n, углубиться в него и перейти в сферу с его использованием от уютной Java тоже. Как писал Макконнелл: «Программируйте с использованием языка, а не на языке.»
Отношение прямое — начальные возрастные рамки автор берёт приближённые к своему возрасту — 35-40, а возраст с 40 до 55 лет приводится как противопоставление. Т.е. автор адресует свою статью читателям (не только, а в первую очередь) 35-40 лет и обращает их внимание на то, что с 40 до 55 лет они будут ещё плодотворнее, чем сейчас и всё ещё впереди.
Это только моё понимание статьи. Есть также предположение, что автор использовал 35-40 только исходя из своего возраста и рамки в этой статье весьма условны (35+) и верхней границы нет — она будет одинаково полезна всем возрастам.
Допустим ваша целевая аудитория абсолютные новички, допустим вы случайно не заметили этой уймы статей про Lombok на хабре. Но, чёрт возьми, как же у меня подгорает, когда для новичков в статьях пишут о «магии», что всё работает волшебно, просто поставь аннотацию, «Просто, быстро, удобно». Хотите рассказать про Lombok? Так расскажите как он работает внутри, расскажите про Annotation Processing Tool, аннотацию поставить много ума не надо. Возможно вы сами в профессии недавно, но так это же какой отличный повод разобраться как оно устроено, как там работает внутри, что скрывают эти «волшебные» аннотации. Сходите к Lombok на гитхаб, посмотрите как оно устроено, разберитесь хотя бы с одной простейшей аннотацией. Вот это была бы статья!
P.S. и да, Lombok умеет генерировать билдеры, «магическая» аннотация в наличии.
MapStruct прекрасен тем, что по интерфейсам с аннотациями(это поле в вот это поле, если есть разногласия) или абстрактным классам (если надо сделать что-то больше, чем просто «из этого поля в это») просто сгенерит реализующий класс, где будет тупо использование геттеров-сеттеров и создание объектов. Как будто вы писали это влоб руками. Сгенерированный конвертер можно тестить, можно дебажить. Он просто используется в runtime. Никаких оверхедов на рефлексию. Если что-то не маппится, то падает при компиляции.
Казалось бы, делает жизнь проще, столько работы за собой скрывают. Но вот приходишь в какой-нибудь типовой проект с Lombok, Spring, Hibernate и что-нибудь ещё. Весь код просто увешен как ёлка с ног до головы аннотациями.
А молодые неокрепшие умы восхищаются, для них кругом магия, понять которую они не спешат. Зачем? Поставь аннотацию, всё сразу заработает. Не работает? Не хватает какой-то аннотации.
А мне всё больше кажется, что есть в этом что-то костыльное. Повышается ментальная нагрузка — глядя на аннотацию, надо вспоминать, что она добавляет или какую аннотацию ещё надо добавить. Как будто ключевых слов в языке прибавилось раза в два. Аннотации не нарушают принцип «явное лучше неявного»?
К Lombok, наверно, тут меньше всего претензий — он порождает довольно простой код, но тоже вносит свою лепту в общую копилку. Хотя можно же просто жмакнуть пару клавиш в IDEA для генерации геттеров/сеттеров и проч.
Всё чаще начинает казаться, что уж лучше я руками.