Скажу про себя. Эти фобии больше зависят от проекта, чем от человека: Фобия выкатить в релиз. Каждый раз боюсь выкатывать новую версию кода в релиз. Особенно если правок произошло достаточно много с момента последнего деплоя. Лечится частыми и мелкими релизами, тестированием изменений другим человеком и автоматические тесты жизненно важных частей системы. Хотя, фобия часто остается. Особенно, когда ты единственный кодер и вся ответственность на тебе. Фобия что-то менять в коде. Обычно прослеживается в монолитных сложных спагетти системах. Тут естественно поможет TDD, что улучшит качество кода в разы, компонентный подход и нормальное наименование переменных/функций/классов/namespace'ов/п.р… Про комментарии не говорю, потому что хорошая архитектура и грамотно написанный код намного лучше любых комментариев. Страх брать сложные задачи. Не всегда это последствия лени. Пожалуй, это скорее последствия первых двух фобий, когда ты просто боишься сломать все, что уже сделано. Особенно, если можешь получить от этого втык. Лекарства все те же: тесты, хорошая архитектура и чистый код.
Это то, с чем столкнулся я. Сказать честно, думал, что в статье речь пойдет о подобном. Но нет. Тут все намного глубже.
Если говорить о подобных психологических моментах, то сейчас я боюсь работать с другими людьми. Всю свою карьеру работаю один удаленно. Ни разу не работал в команде. Если вдруг начальство решит взять еще одного человека, я даже не представляю, как я ему буду объяснять, что творится в моем коде.
Я с вами согласен. Но частично. Скажу за себя. Я выбрал свой любимый frontend стек для разработки — ReactJS, Redux, Bootstrap, SCSS и т.п. Конечно, хорошо знать все то разнообразие, которое предлагает современное сообщество. Но будучи обычным backend разработчиком я в эти дебри не лезу. Я не знаю, как готовить Angular, Backbone, не умею в Typescript и т.д. Читаю статьи либо общего характера, либо связанные с моими инструментами. И не испытываю того дикого дискомфорта, который ощущаете Вы. Но да, когда я только начал знакомиться с фронтендом, я был потерян и запутан.
Что касательно всяких там вебпаков и бабелей. Эти инструменты слишком универсальны, чтобы быть простыми. Проектов много, они разные, у всех разные потребности. Да и без них пока никак. Браузеры только сейчас научились import, а есть ещё большой процент старых и мобильных браузеров, которые до сей поры про let и const не знают.
Если говорить о разнообразии, то это же здорово! Вспомнить только про npm и yarn. Пока второй не появился, первый не особо стремился оптимизировать скорость загрузки пакетов. Конкуренция это всегда хорошо.
Мне вот интересно, а как использовать этот компонент в связке с Redux, когда я хочу проигрывать звуки по событию? Доки не читал, может там есть решения, но в данной ситуации, мне кажется, это будет сделать не так просто.
Пишу на PHP. Использую что-то подобное cqrs, что упростило код, сделало его симпатичнее, проще в поддержании. Я не знаю, как на шарпе все реализовано, но у меня один маленький тоненький command bus и ещё один такой же query bus куда я кидаю команды и запросы. Они просто пробрасывают запрос/команду в нужный обработчик. Так я смогу в будущем переключить выполнение команд с основного потока в очередь. Единственное, что мне до сей поры очень плохо ясно, это куда во всей этой схеме пихать валидацию? Мне предлагали сделать что-то типо middleware, где я бы перехватывал команду и валидировал данные в ней. В итоге пришел к самому простому: команда с валидацией реализует интерфейс ValidatableInterface с методом validate и command bus выбрасывал бы исключение при ошибке. А что, если мне нужно проверить одни и те же данные в разных местах? Писать валидаторы для каждого свойства? Может быть есть какой-то толковый материал на эту тему? Можно англоязычный. Да и вообще не тему cqrs, но без es.
Автору спасибо за статью. Собираю по крупицам информацию. Не задумывался, почему может быть плохо использовать query внутри command. Тут был поднят вопрос без ответа на него: что делать с автосгенерированными БД ID? Я полагаю, тут истинно верного решения нет?
Исторически так сложилось. Весь проект (стили) собирается из одного SCSS файла с подключаемыми в него другими SCSS файлами. В этой ситуации выбор не особо велик: либо все переписывать, либо оставить как есть. Решили идти путем наименьшего сопротивления и использовать BEM.
В Yii2 есть такая штука, как GridView.
Можете глязануть этот русскоязычный материал: nix-tips.ru/yii2-razbiraemsya-s-gridview.html
Может очень много и позволит на скорую руку слепить красивую таблицу с фильтрами и сортировкой.
Но предупрежу заранее — это НЕ библиотека, и Вам придется подключатьь целый фреймворк. Хотя в случае с Yii2, это не так уж сложно.
Может быть я что-то упустил, но в мобильном хабра-приложении «приведенного выше примера» я не вижу.
Кстати о тестировании. Работаю совсем один над крупным проектом (бывает и такое). Тесты пишу не всегда, но иногда они (те, что есть) просто спасают. Бывает что-то отваливается или просто что-то забываю вернуть, это сразу отображается в результатах тестов. Особенно вдохновляют acceptance тесты, где можно посмотреть на живой браузер и скриншот с ошибкой.
Ещё момент: некоторые плагины под eslint для ReactJS (по крайней мере тот, которым пользуюсь я) буквально заставляют добавлять displayName компонентам-функциям. С одной стороны это удобно при отладке. Но с другой стороны `export default () => Hi!` смотрится лаконичнее.
Также использую подход с декораторами: некоторые компоненты являются обертками для других, используются как декораторы (`@something`) и в displayName указывается `DecoratorsName(ChildComponentName)`. Идея не нова: уже давно используется в react-redux и react-form. Я использую данный подход для bem классов. Можно использовать для темизации. Очень удобно.
Плохо этот комментарий сказался на карме… Сначала думал промолчать. Надо было не передумывать.
Авторам большое спасибо за найденный материал. Из этих дайджестов я на самом деле узнал очень много для себя. Особенно нравится раздел "Инструменты".
Небольшое замечание от себя: Yandex DNS с семейным фильтром почему-то считает Ваш сайт сайтом для взрослых и не пускает:
Сайт для возрослых
Яндекс даже в поиске ничего не выдает:
Я отправил им свое несогласие через форму. Но от меня одного вряд ли что-то зависит
Я тоже предпочитаю качать через консоль. GUI качалки либо слишком просты, либо чересчур загружены. Браузер часто недокачивает. А когда нужно скачать пачкой, намного проще упихать все ссылки в один файл и одной командой все получить.
Судя по тому, насколько реже стали выходить джайзесты, и как уменьшается их содержимое можно сделать вывод: либо PHP достаточно зрел и всё, что можно написать про него, было уже давно написано, либо PHP понемногу умирает. Либо просто хайпа нет столько.
Зато он невероятно удобен для pet проектов. У меня где-то с десяток небольших приложений, написанных за пару дней, для меня и моей семьи.
Про серьёзные приложения ничего сказать не могу, так как это не мой род деятельности. Но мне, как веб разработчику, очень нравится подобная технология из-за знакомого мне JavaScript.
Хочу заметить, что React Native очень хорошо работает с async/await. И тем образом код становится очень аккуратным и легко читаемым. Правда, отловить забытый await порой бывает очень сложно. Вроде как даже перед такими функциями, как componentWillMount, можно ставить async
Люблю статьи, которые освещают темные участки документации. Темные в том смысле, что сам не полез бы разбираться, а в статьях упоминаний мало. Спасибо большое.
Бывает… попробуйте инвалидировать кеш и перезапустить IDE. Если не помогло, переподключите NodeJS в настройках. Иногда, после обновления Web и PHP Storm забывают про папку node_modules. Если и это не помогло, пишите issue. У меня эти проблемы решались именно так
Скажу про себя. Эти фобии больше зависят от проекта, чем от человека:
Фобия выкатить в релиз. Каждый раз боюсь выкатывать новую версию кода в релиз. Особенно если правок произошло достаточно много с момента последнего деплоя. Лечится частыми и мелкими релизами, тестированием изменений другим человеком и автоматические тесты жизненно важных частей системы. Хотя, фобия часто остается. Особенно, когда ты единственный кодер и вся ответственность на тебе.
Фобия что-то менять в коде. Обычно прослеживается в монолитных сложных спагетти системах. Тут естественно поможет TDD, что улучшит качество кода в разы, компонентный подход и нормальное наименование переменных/функций/классов/namespace'ов/п.р… Про комментарии не говорю, потому что хорошая архитектура и грамотно написанный код намного лучше любых комментариев.
Страх брать сложные задачи. Не всегда это последствия лени. Пожалуй, это скорее последствия первых двух фобий, когда ты просто боишься сломать все, что уже сделано. Особенно, если можешь получить от этого втык. Лекарства все те же: тесты, хорошая архитектура и чистый код.
Это то, с чем столкнулся я. Сказать честно, думал, что в статье речь пойдет о подобном. Но нет. Тут все намного глубже.
Если говорить о подобных психологических моментах, то сейчас я боюсь работать с другими людьми. Всю свою карьеру работаю один удаленно. Ни разу не работал в команде. Если вдруг начальство решит взять еще одного человека, я даже не представляю, как я ему буду объяснять, что творится в моем коде.
Что касательно всяких там вебпаков и бабелей. Эти инструменты слишком универсальны, чтобы быть простыми. Проектов много, они разные, у всех разные потребности. Да и без них пока никак. Браузеры только сейчас научились import, а есть ещё большой процент старых и мобильных браузеров, которые до сей поры про let и const не знают.
Если говорить о разнообразии, то это же здорово! Вспомнить только про npm и yarn. Пока второй не появился, первый не особо стремился оптимизировать скорость загрузки пакетов. Конкуренция это всегда хорошо.
Мне вот интересно, а как использовать этот компонент в связке с Redux, когда я хочу проигрывать звуки по событию? Доки не читал, может там есть решения, но в данной ситуации, мне кажется, это будет сделать не так просто.
Вы правы. Но так как это моя основная работа — веб разработка, то на железо не скуплюсь. Окупается почти сразу
А если воспользоваться IDE PHPStorm, то можно провести поиск использования класса Object и везде поменять его на BaseObject.
Автору спасибо за статью. Собираю по крупицам информацию. Не задумывался, почему может быть плохо использовать query внутри command. Тут был поднят вопрос без ответа на него: что делать с автосгенерированными БД ID? Я полагаю, тут истинно верного решения нет?
Исторически так сложилось. Весь проект (стили) собирается из одного SCSS файла с подключаемыми в него другими SCSS файлами. В этой ситуации выбор не особо велик: либо все переписывать, либо оставить как есть. Решили идти путем наименьшего сопротивления и использовать BEM.
Можете глязануть этот русскоязычный материал: nix-tips.ru/yii2-razbiraemsya-s-gridview.html
Может очень много и позволит на скорую руку слепить красивую таблицу с фильтрами и сортировкой.
Но предупрежу заранее — это НЕ библиотека, и Вам придется подключатьь целый фреймворк. Хотя в случае с Yii2, это не так уж сложно.
Кстати о тестировании. Работаю совсем один над крупным проектом (бывает и такое). Тесты пишу не всегда, но иногда они (те, что есть) просто спасают. Бывает что-то отваливается или просто что-то забываю вернуть, это сразу отображается в результатах тестов. Особенно вдохновляют acceptance тесты, где можно посмотреть на живой браузер и скриншот с ошибкой.
Ещё момент: некоторые плагины под eslint для ReactJS (по крайней мере тот, которым пользуюсь я) буквально заставляют добавлять displayName компонентам-функциям. С одной стороны это удобно при отладке. Но с другой стороны `export default () => Hi!` смотрится лаконичнее.
Также использую подход с декораторами: некоторые компоненты являются обертками для других, используются как декораторы (`@something`) и в displayName указывается `DecoratorsName(ChildComponentName)`. Идея не нова: уже давно используется в react-redux и react-form. Я использую данный подход для bem классов. Можно использовать для темизации. Очень удобно.
Нет
Плохо этот комментарий сказался на карме… Сначала думал промолчать. Надо было не передумывать.
Авторам большое спасибо за найденный материал. Из этих дайджестов я на самом деле узнал очень много для себя. Особенно нравится раздел "Инструменты".
Небольшое замечание от себя: Yandex DNS с семейным фильтром почему-то считает Ваш сайт сайтом для взрослых и не пускает:
Яндекс даже в поиске ничего не выдает:
Я отправил им свое несогласие через форму. Но от меня одного вряд ли что-то зависит
Про серьёзные приложения ничего сказать не могу, так как это не мой род деятельности. Но мне, как веб разработчику, очень нравится подобная технология из-за знакомого мне JavaScript.