У форм используется много полей для ввода с валидацией и действиями на backend при изменении значения, которые имеют мало общего между собой. Часто приходится писать логическую обвязку на какой-нибудь <ModalDialog /> для выбора элемента из иерархического справочника. В случае с bootstrap — приходилось на каждое из полей ввода создавать stateless-component, или «раздувать» описание одной формы до невообразимых размеров. А для semantic-ui-react — создаем отдельное поле и переиспользуем с <Field.Input as={CustomInput} />.
В ВУЗе хотелось достичь «чего-то» самому — заставлял себя писать код под вышеупомянутом софтом на Asus TF101. Веб-сайты не поднимал, но для веб-сервера на python, запущенном под chroot — более чем хватало.
Т. е. Parcel позволяет использовать любые типы файлов в качестве assets и при этом не требует отдельной конфигурации для нового типа (только запуск в директории с исходниками и index.html)?
На мой взгляд теряется смысл различных связках boilerplate + webpack…
Если правильно понял код к regexp, то тип Regexp в Go — хранит кэш для регулярных выражений, а при обращении к скомпилированному регулярному выражению возвращает в горутину копию объекта типа regexpRO доступную только для чтения (для того чтобы избежать блокировки объекта).
P.S.: А у стандартной библиотеки Go — очень подробные комментарии :)
Мне на текущий момент приходится «переключатся» между проектами. И необходимость навешивать hook'и на выполнения pip/yarn после git clone/pull/checkout меня огорчают. Особенно при смене веток «dev/beta».
ИМХО: В случае с Go — хранить зависимости в репе можно, т.к. на размер и скорость работы с проектом это влияет не существенно. А при наличии go dep в базовых утилитах к языку — придется решить и проблему стандарта пакетов и проблему с необходимостью отслеживать версии зависимых пакетов вручную. Думаю что будет здорово, если при использовании git, вместо загрузки зависимого пакета будет создаватся submodule с необходимой версией.
А если есть необходимость использовать различные ENV-спецефические окружения, то удобнее — docker/lxc…
Недавно в целях изучения языка решил написать свой MitM-proxy на Go. В сравнении с Python 3.* — некоторые вещи на текущий момент выглядят некрасиво, к примеру нельзя сделать slice с отрицательным значением "arr[:-10]", регулярные выражения, которые не могут быть константами и благодаря "магии" внутри Go не перекомпилируются каждый раз (но для того, чтобы об этом узнать — нужно читать документацию), а также другие досадные мелочи, но есть масса преимуществ.
Во-первых — он ОЧЕНЬ быстрый (если сравнивать со стандартными библиотеками Python)!
Во-вторых — первое окружение которое очень просто настраивается (да-да — это камень в сторону venv/node_modules).
Из инструментов для комфортной работы/отладки с ним — было достаточно atom и плагина go-plus.
В случае с тем же React — много без умения работать с Object и Array, а также с функциями, которые они предоставляют не напишешь. А то что можно написать — на HTML+CSS работает быстрее ;)
Недавно принимал участие в «техническом» собеседовании — довольно печально, когда приходят респонденты на вакансию Frontend разработчика со знанием React для работы над SPA, которые не знают как пользоваться assign/concat, а так же зачем они необходимы при действиях связанных с отображением переменных и не могут ответить отличие "==" от «equals»…
Без знания хотя бы основ js создать приложение — можно, но вот заставить его делать хоть что-то полезнее чем отображение шаблона…
На stackoverflow говорят, что вариант с join — самый быстрый.
Для применения темы — собираем отдельный css.
На uBlock Origin — пустые блоки видел.
Попробуйте, в этой же стране проверить сервисы по продаже билетов в кино/театры/на концерты — там не намного лучше.
P.S.: Перестал верить в предоплату после 2014 года :/
С компилятором: C4droid, PascalGUI, AIDE (можно было пользоватся после 2013-го), QPython.
В ВУЗе хотелось достичь «чего-то» самому — заставлял себя писать код под вышеупомянутом софтом на Asus TF101. Веб-сайты не поднимал, но для веб-сервера на python, запущенном под chroot — более чем хватало.
ИМХО: Масштабируется намного проще, чем bootstrap.
yarn config listиexport | grep " PATH=".На мой взгляд теряется смысл различных связках boilerplate + webpack…
От слов своих не отказываюсь. Было бы приятно видеть чаще такой материал :)
P.S.: А у стандартной библиотеки Go — очень подробные комментарии :)
ИМХО: В случае с Go — хранить зависимости в репе можно, т.к. на размер и скорость работы с проектом это влияет не существенно. А при наличии go dep в базовых утилитах к языку — придется решить и проблему стандарта пакетов и проблему с необходимостью отслеживать версии зависимых пакетов вручную. Думаю что будет здорово, если при использовании git, вместо загрузки зависимого пакета будет создаватся submodule с необходимой версией.
А если есть необходимость использовать различные ENV-спецефические окружения, то удобнее — docker/lxc…
Недавно в целях изучения языка решил написать свой MitM-proxy на Go. В сравнении с Python 3.* — некоторые вещи на текущий момент выглядят некрасиво, к примеру нельзя сделать slice с отрицательным значением "arr[:-10]", регулярные выражения, которые не могут быть константами и благодаря "магии" внутри Go не перекомпилируются каждый раз (но для того, чтобы об этом узнать — нужно читать документацию), а также другие досадные мелочи, но есть масса преимуществ.
Во-первых — он ОЧЕНЬ быстрый (если сравнивать со стандартными библиотеками Python)!
Во-вторых — первое окружение которое очень просто настраивается (да-да — это камень в сторону venv/node_modules).
Из инструментов для комфортной работы/отладки с ним — было достаточно atom и плагина go-plus.
Недавно принимал участие в «техническом» собеседовании — довольно печально, когда приходят респонденты на вакансию Frontend разработчика со знанием React для работы над SPA, которые не знают как пользоваться assign/concat, а так же зачем они необходимы при действиях связанных с отображением переменных и не могут ответить отличие "==" от «equals»…
Без знания хотя бы основ js создать приложение — можно, но вот заставить его делать хоть что-то полезнее чем отображение шаблона…