у меня открыт постоянно с десяток проектов в разных продуктах от jetbrains и все на фулскрин, переключение между ними либо свайпом тремя пальцами влево/вправо по тачпаду, либо тремя пальцами вверх (когда открывается mission control) и выбор кликом (название проекта там видно).
для себя принял, что первый экран это обычный, второй браузер, третий это активный проект и дальше экраны с проектами, которые по мере необходимости можно перемещать на место третьего. это позволяет свайпаться между браузером и активным проектом влево/вправо тремя пальцами по тачпаду.
бить по производительности? в pet-проекте? серьезно?
имхо пусть новички везде юзают f-стринги, чем городят страшные конструкции с конкатенацией строк, а оптимизацией всегда можно заняться потом, если в этом вообще будет необходимость, когда упор будет в производительность python-кода, а не во внешние сервисы.
пользователю уже не достаточно просто сухих страниц с информацией, он хочет интерактивности, платой за которую является весь тот ворох технологий, который выше перечислили.
точнее пользователю нужна интерактивность -> разработчик не хочет страдать от лапшевидного кода и императивного управления dom (плюс на него давит бизнес «фича нужна была неделю назад») -> разработчик берет более удобное -> вес итоговой сборки больше, выполняется на клиенте дольше -> пользователь мирится с тормозами в обмен на интерактивность
Мой коммент был именно про «пуш на каждый чих». Когда разработчик не может увидеть результат своего труда до того как он закоммитит, запушит и дождется выкатки feature-ветки. Это слишком долго. А если еще вспомнить, что должны прогнаться тесты, то совсем грустно становится.
А зачем на каждый чих коммитить и пушить? Разрабатываешь локально, с подключенными тестовыми ресурсами, когда убедился, что ок, коммитишь и пушаешь. После этого на тестовом стенде собирается ветка и её можно дать пощупать другим.
Пока не увидел заголовок оригинальной статьи, не понятно, что под перехватчиками вы имели ввиду «Hooks»… в голове возникало «interceptors», что еще больше запутывало.
имхо уже можно назвать ES2015(ES6)+ базовым синтаксисом для новых проектов :)
почему бы новичками сразу не использовать современные и удобные фишки? зачем потом переучиваться?
В общем то я могу и IDEA на проекторе открыть и что-нибудь в ней писать с попутными словесными комментариями. Зачем для этого именно REPL, если оно компилируется моментально?
При каждой компиляции и запуске у вас полностью обнуляется состояние(переменные, функции, объекты и т.д.), в то время как в REPL вы фактически изменяете одно состояние, что позволяет проверять состояние любых объектов и изменять код на лету. Своего рода бесрочный дебаг-режим.
А это очень полезно для подробного объяснения что же на самом деле происходит.
Не говоря о том, что «мгновенная» компиляция и запуск проигрывают REPL в отзывчивости и скорости обратной связи.
Вопрос конечно дискуссионный, но я бы не рекомендовал напрямую вызывать мутации vuex из компонент, сугубо через actions, даже несмотря на то, что на простых кейсах это кажется избыточным.
у меня открыт постоянно с десяток проектов в разных продуктах от jetbrains и все на фулскрин, переключение между ними либо свайпом тремя пальцами влево/вправо по тачпаду, либо тремя пальцами вверх (когда открывается mission control) и выбор кликом (название проекта там видно).
для себя принял, что первый экран это обычный, второй браузер, третий это активный проект и дальше экраны с проектами, которые по мере необходимости можно перемещать на место третьего. это позволяет свайпаться между браузером и активным проектом влево/вправо тремя пальцами по тачпаду.
тогда получилась бы совсем другая статья, более техническая и архитектурная, чем про общий процесс :)
так это гораздо интереснее, чем простое "мы используем запуск ботов по расписанию и потом смотрим отчеты"
по мне это лишь дело вкуса, сам бы я написал бы без f-строк и даже не подумал бы что они тут нужны
бить по производительности? в pet-проекте? серьезно?
имхо пусть новички везде юзают f-стринги, чем городят страшные конструкции с конкатенацией строк, а оптимизацией всегда можно заняться потом, если в этом вообще будет необходимость, когда упор будет в производительность python-кода, а не во внешние сервисы.
точнее пользователю нужна интерактивность -> разработчик не хочет страдать от лапшевидного кода и императивного управления dom (плюс на него давит бизнес «фича нужна была неделю назад») -> разработчик берет более удобное -> вес итоговой сборки больше, выполняется на клиенте дольше -> пользователь мирится с тормозами в обмен на интерактивность
Лучше сделать симлинк на общие ассеты.
почему бы новичками сразу не использовать современные и удобные фишки? зачем потом переучиваться?
Никто не запрещает, главное придерживаться единого стиля на проект/команду ;)
При каждой компиляции и запуске у вас полностью обнуляется состояние(переменные, функции, объекты и т.д.), в то время как в REPL вы фактически изменяете одно состояние, что позволяет проверять состояние любых объектов и изменять код на лету. Своего рода бесрочный дебаг-режим.
А это очень полезно для подробного объяснения что же на самом деле происходит.
Не говоря о том, что «мгновенная» компиляция и запуск проигрывают REPL в отзывчивости и скорости обратной связи.