В традиционном программировании это действительно весьма спорная вещь, но в контексте выполнения кода в браузере подгрузка кода по необходимости очень нужна.
Эта фича уже много лет как реализована в webpack через самодельный костыль, но с асинхронными импортами оно используется проще и удобнее.
Нужно это для выноса тяжелых и редко используемых зависимостей из основного бандла проекта.
Не понимаю, почему так много негатива. Мы уже много лет как живём в цифровую эпоху и избавление от бумажных паспортов или даже пластиковые карточек по мне является весьма полезным и актуальным начинанием.
Да, вряд ли это дело выйдет без косяков, и на первых порах оно может получиться кривым и неудобным или даже вовсе не работающим и не безопасным. Но отладить это лишь вопрос времени и денег. Сайт госуслуг тому пример.
Уже много лет как постепенно идёт «цифровизация» всего, что можно, причём во всем мире, и вряд ли этот тренд поменяется в обозримом будущем. А уж нынешний коронавирус и «самоизоляция» и вовсе придали мощнейший дополнительный пинок в этом направлении.
Зачем в телеграме делать бота, если сервис официально заблокирован на территории РФ. Как этим ботом смогут воспользоваться граждане?
У нас же телеграм не работает. Они что намеренно делают услуги, которыми воспользоваться невозможно? Может быть никакого бота и нет? Не коррупция ли это?
«Чем больше я разбираюсь в этой области, тем сильнее осознаю собственную некомпетентность».
Мы все в большинстве случаев полагаемся на веру в определённые авторитеты. Если задуматься, то это распространено буквально на все сферы жизни, начиная с той же физики и заканчивая экономикой, политикой и историей.
Собственноручно проверить можно лишь ничтожнейшее число фактов, достоверность всего остального мы, во-первых, определяем для себя «авторитетностью» источника сведений, а во-вторых, пропускаем полученную информацию через призму собственного мировозрения, принимая или отбрасывая информацию исходя из собственных знаний и убеждений.
Я чётко осознаю для себя, что никаких самостоятельных выводов из приведённых графиков и доказательств, предложенных автором, сделать не могу. Остаётся лишь поверить интерпретации автора. И для меня это явный критерий того, что либо читателем намеренно пытаются манипулировать, либо автор не от мира сего, раз не в состоянии поставить себя на место читателя и пишет подобные статьи.
Лично мне из двух вариантов:
1) Картинка-ничего-непонятно-но-много-букв-и-терминов + интерпретация автора и разные домыслы;
2) Множество учёных/докторов заявляют противоположное;
Множество каких-то графиков и картинок, которые якобы что-то показывают и доказывают, на деле они непонятны подавляющему большинству читателей, не имеющих никаких познаний по молекулярной биологии. А так же множество домыслов и апелляций к произошедшим событиям, большая часть из которых весьма сомнительна.
На фоне того, как множество видных учёных и докторов уже ранее заявляли, что в рукотворность вируса они не верят, всё это описывается одним словом ёмким словом — конспирология.
Особо и не о чем писать. Оба — оконные версии vim. gvim для linux, а macvim для osx.
Ничего другого, кроме запуска вима в отдельном окне, не связанным с консолью, они не делают.
А в отдельном окне вим удобно запускать потому, что в таком случае на вим не действуют ограничения консоли: немного иначе работает буфер обмена, нет ограничения на хоткеи, которые использует сама консоль, и нет упрощения цветовых палитр, когда настройки цвета в виме упрощаются до того уровня, на каком может отобразить консоль.
К сожалению уже не вспомню, в чём было дело, но два раза пытался перейти на неовим с обычного вима. Первый раз давно на линуксе, второй раз где-то с год назад на OSX.
Оба раза возникали различные косяки и проблемы, исправить которые или смириться с ними так и не получилось, в итоге возвращался назад на gvim/macvim.
Для меня лично функциональное программирование в JS заканчивается на применении его огрызков в виде forEach/map/reduce/filter/every/some. Сильно не люблю код с циклами и с переменными-счётчиками, которые можно заменить использованием этих функций.
Очень-очень редко приходилось применять каррирование, лишь буквально в единицах случаев оно мне неплохо облегчало жизнь.
Мысль писать весь код в функциональном стиле вызывает… сильное отторжение. Подозреваю, что это результат воспитания и образования, когда серьёзно погружаться в программирование начинаешь с pascal/c++. Возможно, поколение, которое только-только начинает изучать программирование, при наличии всех современных языков, будет иначе воспринимать ФП.
После императивных языков функциональный подход воспринимается в большинстве случаев как разминка для ума — чистый ФП код выглядит иногда круто, но сам на практике так делать ни за что не будешь.
Раз ФП так и не завоевало мир, то значит в большинстве случаев оно не так уж и хорошо/удобно/просто/понятно/универсально. И было бы интересно почитать как раз о том, когда чистый ФП подход таки стоит применять в тех языках, где поддерживаются оба подхода к программированию.
P.S. Совсем иначе эту статью можно воспринимать, если в примерах кода начать применять pipeline оператор из ES2019 proposal github.com/tc39/proposal-pipeline-operator
С ним чистое ФП или его отдельные элементы выглядят совсем иначе, гораздо понятнее и лаконичнее.
P.P.S В подобных статьях имхо стоит через строчку писать, что это упрощенный учебный пример.
> UI код клиента относительно простой. Например нам не нужно использовать какие-то CSS хаки, чтобы сделать 2 колонки одинаковой высоты.
Чтобы не было хаков для колонок, в css добавили flex и grid.
Даже если предположить, что ваша технология будет развиваться, то спустя годы вы придёте к тому же css, к копированию оттуда большинства свойств, их логики.
Вся эта сложность в css появилась не просто так, а для решения конкретных проблем.
Все эти проблемы возникнут и в вашей технологии, и для их решения вы точно так же будете вводить всё новые и новые усложнения.
Либо не будете, но тогда ваша технология будет со множеством ограничений, которые отсутствуют в классическом вебе.
> Разработку UI можно вести в графическом дизайнере Qt Creator
До тех пор, пока делается стандартный интерфейс из стандартных компонентов.
Потом добавляются собственные компоненты, потом их динамическое отображение, потом responsive вёрстка для разных размеров экранов, и в итоге визуальный редактор можно выкидывать на помойку — он больше мешает и ограничивает, чем помогает.
Визуальные редакторы не просто так не прижились в вебе.
> Предположительно скорость работы приложений будет гораздо выше чем HTML
Пока у вашей технологии будет отсутствовать безопасность и будет сильно ограничен набор фич по сравнению с вебом, то вполне вероятно, что да.
> Использование десктопных UI компонент
Спорный довод. В том же вебе практически всегда при разработке первое, что делают, это добавляют в свой стили какой-нибудь reset css, который убирает всю «платформенную» стилизацию браузерных компонентов.
Так же еще появляются вопросы на счёт кроссплатформенности и работе на мобильных устройствах.
Я стараюсь придерживать правила, что чем проще сделано, тем лучше.
Пустая выключенная форма потребует дополнительных стилей и логики. Если их написания можно избежать, то лучше так и сделать. То есть просто показать крутилку на месте формы.
Подобные оптимизации имеют право на жизнь, но применять их на практике стоит по необходимости, когда что-то начинает тормозить.
> А что есть серьёзная потеря производительности и из за чего она происходит?
Обновления ОС и в некоторых случаях обновления приложений.
Не сразу, и даже не за год. Но в конце концов то, что раньше работало быстро и плавно, начинает долго грузиться, работать рывками и доставлять дискомфорт при использовании.
Не обновляться и искать легковесные аналоги, это конечно вариант решения проблемы, но он несёт в себе много неудобств и далеко не всех устроит.
Имхо лучший способ бороться с выгоранием OLED, это не покупать телефоны такими экранами. Нынешние телефоны из среднего и выше ценовых сегментов проработают без серьёзной потери производительности долго, гораздо дольше 1-2 лет, за которые OLED начнёт выгорать.
Покупая же OLED ты фактически соглашаешься с запланированным устареванием. Для производителей телефонов, которым нужно продавать много и регулярно, это очень удобная технология.
Да я с этим и не спорю, но описанное на картинке точно так же применимо и к действиям китайского видео сервиса.
Цензура — зло независимо от того, кто ее применяет. Когда занимающийся цензурой фейсбук обвиняет других в цензуре, это выглядит весьма лицемерно.
И если приглядеться, то подобный подход присутствует во многих областях. Что лично меня очень печалит. И еще больше печалит то, что находится те, кто поддерживают подобные двойные стандарты, когда одним что-то можно, а другим, объявленным плохими, нельзя.
Ага. Вбиваем в гугл «фейсбук цензура» или «facebook censoring», и что мы же видим?
Под свободой слова нынче понимается ситуация, когда толерасты, либералы и глобалисты имеют право голоса, а все несогласные — это люди второго сорта, и прав они не имеют.
Причина банальна. Она удобна. Комфортна для постоянной работы, достаточно красива, её не нужно предварительно настраивать, большинство нужных для комфортной жизни вещей работают «из коробки».
Она интегрирована с телефоном, автоматически с ними синхронизируется вплоть до общего буфера обмена и приёма звонков с телефона.
Обновился в день выхода Catalina.
Единственная возникшая проблема была с macvim, он не запускался из-за обновлённой версии системного руби. И через homebrew никак не удавалось ни поставить готовый, ни скомпилировать из исходников. В конце-концов пофиксилось компиляцией кода из master ветки
brew install macvim --build-from-source --HEAD
Плеер vlc работает
ffmpeg работает
docker работает
karabiner работает
vpn через windscribe работает (другие способы не пробовал)
Под мусором вы имеете в виду то, что остаётся в домашнем каталоге: конфигурационные файлы, кеши и т.д.? Так их пакетные менеджеры и в других системах не чистят, если разработчики приложений явно не пропишут того в их анинсталлере.
> 2. Это стороннее средство от сторонних разработчиков
Да. Стороннее средство от сторонних разработчиков для сторонних приложений.
Прошедшие же модерацию приложения доступны через официальный аппстор.
Я вполне понимаю, почему тот же homebrew никогда не станет официальной частью osx.
Политика apple такова, что в их апсторе доступны только прошедшие весьма жёсткую модерацию приложения. Все приложения оттуда можно считать условно безопасными и делающими именно то, что написано у них в описании.
Приложения же и пакеты, находящиеся в homebrew, ставится на свой страх и риск. Там внутри может быть что угодно, через brew cask можно установить даже такие сомнительные вещи clean my mac.
Эта фича уже много лет как реализована в webpack через самодельный костыль, но с асинхронными импортами оно используется проще и удобнее.
Нужно это для выноса тяжелых и редко используемых зависимостей из основного бандла проекта.
Да, вряд ли это дело выйдет без косяков, и на первых порах оно может получиться кривым и неудобным или даже вовсе не работающим и не безопасным. Но отладить это лишь вопрос времени и денег. Сайт госуслуг тому пример.
Уже много лет как постепенно идёт «цифровизация» всего, что можно, причём во всем мире, и вряд ли этот тренд поменяется в обозримом будущем. А уж нынешний коронавирус и «самоизоляция» и вовсе придали мощнейший дополнительный пинок в этом направлении.
У нас же телеграм не работает. Они что намеренно делают услуги, которыми воспользоваться невозможно? Может быть никакого бота и нет? Не коррупция ли это?
«Чем больше я разбираюсь в этой области, тем сильнее осознаю собственную некомпетентность».
Мы все в большинстве случаев полагаемся на веру в определённые авторитеты. Если задуматься, то это распространено буквально на все сферы жизни, начиная с той же физики и заканчивая экономикой, политикой и историей.
Собственноручно проверить можно лишь ничтожнейшее число фактов, достоверность всего остального мы, во-первых, определяем для себя «авторитетностью» источника сведений, а во-вторых, пропускаем полученную информацию через призму собственного мировозрения, принимая или отбрасывая информацию исходя из собственных знаний и убеждений.
Я чётко осознаю для себя, что никаких самостоятельных выводов из приведённых графиков и доказательств, предложенных автором, сделать не могу. Остаётся лишь поверить интерпретации автора. И для меня это явный критерий того, что либо читателем намеренно пытаются манипулировать, либо автор не от мира сего, раз не в состоянии поставить себя на место читателя и пишет подобные статьи.
Лично мне из двух вариантов:
1) Картинка-ничего-непонятно-но-много-букв-и-терминов + интерпретация автора и разные домыслы;
2) Множество учёных/докторов заявляют противоположное;
Более достоверным кажется второй вариант.
На фоне того, как множество видных учёных и докторов уже ранее заявляли, что в рукотворность вируса они не верят, всё это описывается одним словом ёмким словом — конспирология.
Ничего другого, кроме запуска вима в отдельном окне, не связанным с консолью, они не делают.
А в отдельном окне вим удобно запускать потому, что в таком случае на вим не действуют ограничения консоли: немного иначе работает буфер обмена, нет ограничения на хоткеи, которые использует сама консоль, и нет упрощения цветовых палитр, когда настройки цвета в виме упрощаются до того уровня, на каком может отобразить консоль.
Оба раза возникали различные косяки и проблемы, исправить которые или смириться с ними так и не получилось, в итоге возвращался назад на gvim/macvim.
Очень-очень редко приходилось применять каррирование, лишь буквально в единицах случаев оно мне неплохо облегчало жизнь.
Мысль писать весь код в функциональном стиле вызывает… сильное отторжение. Подозреваю, что это результат воспитания и образования, когда серьёзно погружаться в программирование начинаешь с pascal/c++. Возможно, поколение, которое только-только начинает изучать программирование, при наличии всех современных языков, будет иначе воспринимать ФП.
После императивных языков функциональный подход воспринимается в большинстве случаев как разминка для ума — чистый ФП код выглядит иногда круто, но сам на практике так делать ни за что не будешь.
Раз ФП так и не завоевало мир, то значит в большинстве случаев оно не так уж и хорошо/удобно/просто/понятно/универсально. И было бы интересно почитать как раз о том, когда чистый ФП подход таки стоит применять в тех языках, где поддерживаются оба подхода к программированию.
P.S. Совсем иначе эту статью можно воспринимать, если в примерах кода начать применять pipeline оператор из ES2019 proposal github.com/tc39/proposal-pipeline-operator
С ним чистое ФП или его отдельные элементы выглядят совсем иначе, гораздо понятнее и лаконичнее.
P.P.S В подобных статьях имхо стоит через строчку писать, что это упрощенный учебный пример.
> UI код клиента относительно простой. Например нам не нужно использовать какие-то CSS хаки, чтобы сделать 2 колонки одинаковой высоты.
Чтобы не было хаков для колонок, в css добавили flex и grid.
Даже если предположить, что ваша технология будет развиваться, то спустя годы вы придёте к тому же css, к копированию оттуда большинства свойств, их логики.
Вся эта сложность в css появилась не просто так, а для решения конкретных проблем.
Все эти проблемы возникнут и в вашей технологии, и для их решения вы точно так же будете вводить всё новые и новые усложнения.
Либо не будете, но тогда ваша технология будет со множеством ограничений, которые отсутствуют в классическом вебе.
> Разработку UI можно вести в графическом дизайнере Qt Creator
До тех пор, пока делается стандартный интерфейс из стандартных компонентов.
Потом добавляются собственные компоненты, потом их динамическое отображение, потом responsive вёрстка для разных размеров экранов, и в итоге визуальный редактор можно выкидывать на помойку — он больше мешает и ограничивает, чем помогает.
Визуальные редакторы не просто так не прижились в вебе.
> Предположительно скорость работы приложений будет гораздо выше чем HTML
Пока у вашей технологии будет отсутствовать безопасность и будет сильно ограничен набор фич по сравнению с вебом, то вполне вероятно, что да.
> Использование десктопных UI компонент
Спорный довод. В том же вебе практически всегда при разработке первое, что делают, это добавляют в свой стили какой-нибудь reset css, который убирает всю «платформенную» стилизацию браузерных компонентов.
Так же еще появляются вопросы на счёт кроссплатформенности и работе на мобильных устройствах.
Пустая выключенная форма потребует дополнительных стилей и логики. Если их написания можно избежать, то лучше так и сделать. То есть просто показать крутилку на месте формы.
Подобные оптимизации имеют право на жизнь, но применять их на практике стоит по необходимости, когда что-то начинает тормозить.
Обновления ОС и в некоторых случаях обновления приложений.
Не сразу, и даже не за год. Но в конце концов то, что раньше работало быстро и плавно, начинает долго грузиться, работать рывками и доставлять дискомфорт при использовании.
Не обновляться и искать легковесные аналоги, это конечно вариант решения проблемы, но он несёт в себе много неудобств и далеко не всех устроит.
Покупая же OLED ты фактически соглашаешься с запланированным устареванием. Для производителей телефонов, которым нужно продавать много и регулярно, это очень удобная технология.
Цензура — зло независимо от того, кто ее применяет. Когда занимающийся цензурой фейсбук обвиняет других в цензуре, это выглядит весьма лицемерно.
И если приглядеться, то подобный подход присутствует во многих областях. Что лично меня очень печалит. И еще больше печалит то, что находится те, кто поддерживают подобные двойные стандарты, когда одним что-то можно, а другим, объявленным плохими, нельзя.
Под свободой слова нынче понимается ситуация, когда толерасты, либералы и глобалисты имеют право голоса, а все несогласные — это люди второго сорта, и прав они не имеют.
Она интегрирована с телефоном, автоматически с ними синхронизируется вплоть до общего буфера обмена и приёма звонков с телефона.
Единственная возникшая проблема была с macvim, он не запускался из-за обновлённой версии системного руби. И через homebrew никак не удавалось ни поставить готовый, ни скомпилировать из исходников. В конце-концов пофиксилось компиляцией кода из master ветки
Плеер vlc работает
ffmpeg работает
docker работает
karabiner работает
vpn через windscribe работает (другие способы не пробовал)
Но что мы увидим, зайдя в рецепт? github.com/Homebrew/homebrew-cask/blob/master/Casks/cleanmymac.rb.
Оно скачивает архив, в котором лежит бинарник.
> 2. Это стороннее средство от сторонних разработчиков
Да. Стороннее средство от сторонних разработчиков для сторонних приложений.
Прошедшие же модерацию приложения доступны через официальный аппстор.
Я вполне понимаю, почему тот же homebrew никогда не станет официальной частью osx.
Политика apple такова, что в их апсторе доступны только прошедшие весьма жёсткую модерацию приложения. Все приложения оттуда можно считать условно безопасными и делающими именно то, что написано у них в описании.
Приложения же и пакеты, находящиеся в homebrew, ставится на свой страх и риск. Там внутри может быть что угодно, через brew cask можно установить даже такие сомнительные вещи clean my mac.