Аргументировать свою точку зрения тоже было бы неплохо научиться. Мне, как читателю, хотелось бы знать, в чем заключается неправильность. Хотя бы один случай многоугольника, в котором он не сработает, например.
Хорошо, если свойства вам хочется назвать "предефайненными переменными", то это нововведение правильней было бы назвать "юзер-дефайнед константами". В языке С, например, константы принято именовать заглавными буквами (хотя это не строгое требование компилятора, а просто выработанный многолетним опытом программистов code style). Так просто кодить реально удобнее, когда мух от котлет визуально легко отличить, особенно когда у нас килограмм мух в центнере котлет размешан.
P.S. Ну и для совместимостями с будущими версиями — если вдруг у какого-то элемента появится новое свойство в следующей версии HTML/CSS — у программистов, дизайнеров и верстальщиков не будет головной боли по поводу "а не назвали ли мы так наши переменные в нашем коде, и не нужно ли теперь в срочном порядке их везде переименовывать".
Верно подметили. Не успел комментарий исправить, комп заглючило. Я смотрел на случай до перестановки, и соответственно его и имел в виду, когда писал комментарий.
да что ж такое с этим интерфейсом, когда-нибудь исправят этот глюк с комментами «не туда»?
> Ни один из треугольников на самом деле не треугольник. Их гипотенузы искривлены…
Ничего там не искривлено. Просто красный и голубой треугольники не являются подобными (2:5 ≠ 3:8), следовательно, их острые углы не равны, следовательно, гипотенуза большого треугольника, которую они образуют своими гипотенузами, имеет небольшой излом. Поэтому «не треугольник» там только один.
никакой необходимости отделять (как выше комментировано) их нету
Ничего подобного выше не комментировано. Без отделения переменных нет никакого способа визуально отличить объявление переменной от объявлений свойств элемента. Способ выделения — дело вкуса и привычки, это уже вопрос чисто субъективный.
Для библиотеки фото есть DarkTable и AfterShot Pro. И то и то я когда-то попробовал — глючит. Ненадежно. Может быть сейча ситуация уже улучшилась, но экспериментировать ни времени ни желания уже нет.
По поводу безопасности — таки да, все тоже печально. Линукс заточен для работы на сервере, когда под каждое приложение (сервер баз данных, веб-сервер, почтовый сервер и т.д.) создается отдельный пользователь, с отдельной домашней директорией и правами доступа к файлам. В таком случае, если даже какое-то приложение будет взломано, злоумышленник не получит доступа к данным других приложений (если все права настроены правильно). А с секурностью для десктопа разработчики линукса как-то до сих пор не подружились, и менеджер паролей — яркий тому пример. В той же макоси каждому приложению, требующему доступ к кейчейну, нужно явно дать на это разрешение, а в линуксе — один раз разблокировать паролем Gnome Keyring/KWallet, и дальше из него читает кто, что и когда хочет.
где-то я уже это видел… НЕ на debian. И не год назад даже, ещё раньше.
В arch у меня такое. И тоже в dmesg сначала присваивается имя типа eth0/eth1, а потом переименовывается.
Что лучше… в целях домашнего использования (фото-видео, документы, мессенджеры, игры (стим и т.п.)
Как-то все до сих пор печально. Еще лет эдак 10 назад я перешел с винды на линукс, но хватило меня буквально на пару лет: постоянные перезагрузки под винду для фотошопа и игр поднадоели. Потом ушел на макось, и успешно сидел на ней до недавнего времени. Зато в игры стал играть гораздо меньше :) Так как принципиально играл только в те, что шли под макосью. Теперь вот решил вернуться назад на линукс — и как-то там все по-прежнему печально. Что-то, конечно, изменилось, но ключевых инструментов для полноценной повседневной работы до сих пор нет. Либо есть, но в каком-то глючном и ненадежном состоянии. Adobe свои продукты портировать не собирается, т.е. Lightroom/Photoshop для фото отпадает, офис — сильно тормозной и не сильно совместимый, для нормального редактирования видео я вообще ничего не нашел. Играть не пробовал, но судя по стиму — как-то можно, но выбор игр опять же очень ограниченн. В общем, если нет паранойи насчет слива персональных данных злым корпорациям — то для повседневного использования все-таки лучше винда/макось. А если игры в приоритете — то только винда.
А по дистрибутивам линукса — Arch это rolling release, а значит все новинки туда попадают гораздо раньше, чем в debian. Я именно arch использую сейчас для работы, уже месяца 3 на нем — вроде пока полет нормальный. С учетом, что для игр у меня винда+PS4, а для фото-видео остался старый мак. Freebsd как десктопную ось я бы вообще рассматривал в самую последнюю очередь, с выбором софта там еще печальнее, чем в линуксе.
Мне кажется, более активно оставляют негативные отзывы разочарованные зрители. Поэтому они должны уравновешивать фанатов. Могу и ошибаться, конечно. В любом случае, простому обывателю имеет смысл ориентироваться на оценки таких же простых обывателей, так как профессиональные критики слишком искушены в тонкостях и нюансах, на которые обычный зритель даже внимания не обратит, если вообще сможет заметить.
В моем случае как раз совсем не мелочи, так как netty пишет свои логи без MDC, и при куче параллельных запросов все превращается в кровавую мешанину. А мне как раз эти логи и нужно привязывать к контексту, чтобы потом разгребать. Я зарепортил этот "баг" в netty, посмотрю, что там на это скажут.
Хмм, нашел свой старый код, который пытался прикрутить к Netty пару лет назад. Там действительно используется ExecutionContext#prepare, и оставлен коммент, что все хорошо, пока не нужно взаимодействовать с Java-библиотеками. Так как в Java всякие Executor/ExecutorService не имеют механизма, аналогично скаловскому ExecutionContext#prepare. Для этого у меня там еще несколько вспомогательных классов: обертки для Runnable/Callable, и обертки для Executor/ExecutorService, которые заворачивают Runnable/Callable в их обертки, чтобы вместе с ними передать MDC.getCopyOfContextMap(). А дальше идет коммент, что с Netty все это все равно не работает :) Так как у них там NioEventLoopGroup, который создает дочерние EventLoop, причем реализацию, которая объявлена final и поэтому ее нельзя унаследовать и переопределить нужные методы. И фасад для нее нельзя сделать, так как она в нескольких методах передает this вовне, и фасад отваливается. В общем, внутри scala все красиво, а вот на стыке scala-java подобные нестыковки случаются частенько, к сожалению :(
Спасибо за подсказку насчет prepare(), будет случай — попробую применить. На данный момент у меня проблема с Netty, к которому я попытался прикрутить злополучный MDC. И опять ничего не получается. По запросу Netty MDC гуглится вот это решение, но оно мало того, что немного криво написано — так еще и совсем не работает. Наверное, автор его для однопоточного режима писал, или для более старой версии Netty, и с условием, что значения MDC выставляются при создании ExecutionContext один раз и больше не меняются (мне нужно, чтобы они подхватывались из текущих актуальных значений в MDC.getCopyOfContextMap() каждый раз при вызове execute(), но это легко поправимо). Но даже с внесенными мной изменениями оно не заработало: я попытался помимо exec() провернуть подобный фокус со всеми вариациями методов submit() и schedule(), а также переопределить метод newChild() который создает дочерние EventLoop (которые являются по сути SingleThreadEventExecutor и реализуют ExecutorService), и у них также переопределить execute(), schedule() и submit() во всех вариациях. Результатат ноль. Это, правда, уже не Scala, а Java, но тоже асинхронная.
Аргументировать свою точку зрения тоже было бы неплохо научиться. Мне, как читателю, хотелось бы знать, в чем заключается неправильность. Хотя бы один случай многоугольника, в котором он не сработает, например.
Ну следующий логичный шаг — загуглить, что такое c-ares, и за что отвечает, не?
А как быть с Either в случае, например, List[String | Int | Long | Date | URL | SomethingElse]?
Хорошо, если свойства вам хочется назвать "предефайненными переменными", то это нововведение правильней было бы назвать "юзер-дефайнед константами". В языке С, например, константы принято именовать заглавными буквами (хотя это не строгое требование компилятора, а просто выработанный многолетним опытом программистов code style). Так просто кодить реально удобнее, когда мух от котлет визуально легко отличить, особенно когда у нас килограмм мух в центнере котлет размешан.
P.S. Ну и для совместимостями с будущими версиями — если вдруг у какого-то элемента появится новое свойство в следующей версии HTML/CSS — у программистов, дизайнеров и верстальщиков не будет головной боли по поводу "а не назвали ли мы так наши переменные в нашем коде, и не нужно ли теперь в срочном порядке их везде переименовывать".
да что ж такое с этим интерфейсом, когда-нибудь исправят этот глюк с комментами «не туда»?
Ничего там не искривлено. Просто красный и голубой треугольники не являются подобными (2:5 ≠ 3:8), следовательно, их острые углы не равны, следовательно, гипотенуза большого треугольника, которую они образуют своими гипотенузами, имеет небольшой излом. Поэтому «не треугольник» там только один.
Ничего подобного выше не комментировано. Без отделения переменных нет никакого способа визуально отличить объявление переменной от объявлений свойств элемента. Способ выделения — дело вкуса и привычки, это уже вопрос чисто субъективный.
Для библиотеки фото есть DarkTable и AfterShot Pro. И то и то я когда-то попробовал — глючит. Ненадежно. Может быть сейча ситуация уже улучшилась, но экспериментировать ни времени ни желания уже нет.
По поводу безопасности — таки да, все тоже печально. Линукс заточен для работы на сервере, когда под каждое приложение (сервер баз данных, веб-сервер, почтовый сервер и т.д.) создается отдельный пользователь, с отдельной домашней директорией и правами доступа к файлам. В таком случае, если даже какое-то приложение будет взломано, злоумышленник не получит доступа к данным других приложений (если все права настроены правильно). А с секурностью для десктопа разработчики линукса как-то до сих пор не подружились, и менеджер паролей — яркий тому пример. В той же макоси каждому приложению, требующему доступ к кейчейну, нужно явно дать на это разрешение, а в линуксе — один раз разблокировать паролем Gnome Keyring/KWallet, и дальше из него читает кто, что и когда хочет.
В arch у меня такое. И тоже в dmesg сначала присваивается имя типа eth0/eth1, а потом переименовывается.
Как-то все до сих пор печально. Еще лет эдак 10 назад я перешел с винды на линукс, но хватило меня буквально на пару лет: постоянные перезагрузки под винду для фотошопа и игр поднадоели. Потом ушел на макось, и успешно сидел на ней до недавнего времени. Зато в игры стал играть гораздо меньше :) Так как принципиально играл только в те, что шли под макосью. Теперь вот решил вернуться назад на линукс — и как-то там все по-прежнему печально. Что-то, конечно, изменилось, но ключевых инструментов для полноценной повседневной работы до сих пор нет. Либо есть, но в каком-то глючном и ненадежном состоянии. Adobe свои продукты портировать не собирается, т.е. Lightroom/Photoshop для фото отпадает, офис — сильно тормозной и не сильно совместимый, для нормального редактирования видео я вообще ничего не нашел. Играть не пробовал, но судя по стиму — как-то можно, но выбор игр опять же очень ограниченн. В общем, если нет паранойи насчет слива персональных данных злым корпорациям — то для повседневного использования все-таки лучше винда/макось. А если игры в приоритете — то только винда.
А по дистрибутивам линукса — Arch это rolling release, а значит все новинки туда попадают гораздо раньше, чем в debian. Я именно arch использую сейчас для работы, уже месяца 3 на нем — вроде пока полет нормальный. С учетом, что для игр у меня винда+PS4, а для фото-видео остался старый мак. Freebsd как десктопную ось я бы вообще рассматривал в самую последнюю очередь, с выбором софта там еще печальнее, чем в линуксе.
В моем случае как раз совсем не мелочи, так как netty пишет свои логи без MDC, и при куче параллельных запросов все превращается в кровавую мешанину. А мне как раз эти логи и нужно привязывать к контексту, чтобы потом разгребать. Я зарепортил этот "баг" в netty, посмотрю, что там на это скажут.
Хмм, нашел свой старый код, который пытался прикрутить к Netty пару лет назад. Там действительно используется ExecutionContext#prepare, и оставлен коммент, что все хорошо, пока не нужно взаимодействовать с Java-библиотеками. Так как в Java всякие Executor/ExecutorService не имеют механизма, аналогично скаловскому ExecutionContext#prepare. Для этого у меня там еще несколько вспомогательных классов: обертки для Runnable/Callable, и обертки для Executor/ExecutorService, которые заворачивают Runnable/Callable в их обертки, чтобы вместе с ними передать MDC.getCopyOfContextMap(). А дальше идет коммент, что с Netty все это все равно не работает :) Так как у них там NioEventLoopGroup, который создает дочерние EventLoop, причем реализацию, которая объявлена final и поэтому ее нельзя унаследовать и переопределить нужные методы. И фасад для нее нельзя сделать, так как она в нескольких методах передает this вовне, и фасад отваливается. В общем, внутри scala все красиво, а вот на стыке scala-java подобные нестыковки случаются частенько, к сожалению :(
Спасибо за подсказку насчет prepare(), будет случай — попробую применить. На данный момент у меня проблема с Netty, к которому я попытался прикрутить злополучный MDC. И опять ничего не получается. По запросу Netty MDC гуглится вот это решение, но оно мало того, что немного криво написано — так еще и совсем не работает. Наверное, автор его для однопоточного режима писал, или для более старой версии Netty, и с условием, что значения MDC выставляются при создании ExecutionContext один раз и больше не меняются (мне нужно, чтобы они подхватывались из текущих актуальных значений в MDC.getCopyOfContextMap() каждый раз при вызове execute(), но это легко поправимо). Но даже с внесенными мной изменениями оно не заработало: я попытался помимо exec() провернуть подобный фокус со всеми вариациями методов submit() и schedule(), а также переопределить метод newChild() который создает дочерние EventLoop (которые являются по сути SingleThreadEventExecutor и реализуют ExecutorService), и у них также переопределить execute(), schedule() и submit() во всех вариациях. Результатат ноль. Это, правда, уже не Scala, а Java, но тоже асинхронная.