Соглашусь - так не слишком удобно читать. А причина довольно проста: это был самый простой способ внутренней реализации. Разворачивание цепочки происходит с конца, так так под капотом там односвязный список. Но, по опыту могу сказать, что привыкаешь к такому довольно быстро.
Мне кажется - проблема в том, что понятие модуля в разных языках разное. В es модулем является файл, но один файл далеко не всегда (скорее, почти никогда) представляется реализацией целого слоя приложения. Если, скажем, разделить приложение на несколько базовых уровней вроде транспортного, бизнес-логики и хранилища, то связи между ними как раз удобно и правильно реализовывать в виде абстракций и инверсии зависимостей. Но в рамках одного слоя, если требуется работа с конкретной базой данных, скажем, то инверсия уже не требуется - используем прямые импорты. При этом бизнес-логика будет работать с любыми видами хранилища через обобщенный интерфейс.
Это не какое-то строгое правило, и подход применим и к более мелким частям приложения, можно ограничить их пространствами имен или макро-модулями (называйте как хотите), вопрос лишь в потребности. Если есть необходимость использовать различные реализации - используем инверсию, и, как правило, инъекцию. Если же такое потребности нет, то зачем усложнять жизнь себе и тем, кто будет читать код? Собственно, мой вопрос состоит в том - почему вы хотите отделить один прием от другого, если они не противоречат друг-другу? Или я неверно вас понял?
Технически как раз проблема была в изуродованном патчами ядре Linux, и вендору при обновлении ядра приходилось все свои блобы заново править, что сильно усложняло процедуру. Сейчас, вроде как, проблема решена или частично решена.
Если бы вы внимательно прочитали первые пару абзацев и последний, то поняли бы, что цель состоит не в том, чтобы показать, как правильно делать, а в том, чтобы заинтересовать читателя самостоятельно разбираться в вопросе дальше. Отсюда и "упрямство". Это как с изучением какого-то раздела математики, часто можно применять в многих задачах, но, зачастую, есть более оптимальные методы. Я же не призываю делать всегда и именно так, как раз наоборот.
Думаю, вы согласитесь, что последний пример с union ужасен, хотя все зависит от конкретных условий, конечно.
UB возникает, насколько мне удалось понять, только в том случае, если приводятся not aligned типы, так что в данном случае его не будет. Что же касается вашего примера с VTable, то это хороший пример, но он, как вы верно заметили, требует отдельной статьи на которую планов пока нет, ибо этому материалу десяток лет, и на C я давненько не писал, а лишь стряхнул пыль со старого материала. Тем не менее, теперь задумался над вашим предложением.
Все бы ничего, но смущает тот факт, что имя библейского Ноя на английском пишется именно как Noah. Не то, чтобы Википедия была каким-то незыблимым авторитетом, но в данном случае, думаю, показательно:
Ноа (ивр. נֹועָה, נֹעָה) — женское библейское имя. Кроме того, так в русской транскрипции выглядит английский вариант мужского библейского имени Ной (Но́ах, ивр. נֹחַ, англ. Noah), не имеющего отношения к женскому.
Не стану делать вид, что понимаю — о чем вы говорите. Вот у нас есть некий условно обобщенный, тип, допустим, он сделан через union, как вы и сказали, и зашит где-то в библиотеке. Если мне нужно добавить поддержку еще одного типа, то что предлагаете делать в таком случае? В случае со структурами — просто описываете новую структуру.
Разве я что-то говорил про сложность? Добавлять реализаци по мере необходимости означает то, что эти реализации могут добавляться вообще в другом месте. Например, у нас может быть библиотека, работающая с определенным интерфейсом, его реализацию мы можем добавить в своей программе. Как подобная задача будет решаться с использованием объединений скажите, пожалуйста? Сразу отмечу, что вопрос академического характера, то есть не надо рассматривать в контексте "нужно ли оно вообще".
Пример с примитивными типами, очевидно, рассмотрен для простоты. Ниже уже идет чуть более осмысленный пример. Объединения хороши для своих задач и требуют сразу указать все возможные типы, а с "интерфесами" можно добавлять реализации по мере необходимости, лишь бы они соответствовали контрактам интерфейса.
Совершенно верное замечаение, хоть и не имеет прямого отношения к теме, все же не стоит транслировать плохие решения в массы, так сказать. Внес исправления, спасибо.
Вы совершенное правы, в личку мне тоже об этом писали, к сожалению, не было времени вчера еще исправить, но уже поправил. Статья старая, хоть и перечитывал, не обратил на эту досадную ошибку внимания. Имелась ввиду статическая типизация, конечно же.
Не холивара ради, а для саморазвития хочу спросить: а в чем разница между отправкой пароля в открытом виде и отправкой хэша с клиента? Если сервер даёт доступ по этому хэша? А если рандомная соль генерируется на клиенте, то, как сервер проверит этот хэш? Если же позиция и длина истиной части ключа известны, то что мешает тогда злоумышленнику также разобраться и самому подставлять рандомную соль?
Пару лет назад приходилось ковыряться в вопросе. И совсем не все так однозначно, как вы говорите. Да, наши "провайдеры", конечно, скажут, что все надо хранить в их защищённом облаке, да ещё и доступ, желательно по сертифицированному VPN. Но правда часто оказывается далека от сказок. Для тех же онлайн-магазинов, зачастую персональные данные и не требуется хранить вовсе. Само понятие персональных данных подразумевает однозначную идентификацию человека по набору некоторых признаков. Таким образом, ФИО сами по себе — не перс. данные. Также ими не является публичная информация (тут есть нюансы в трактовке), отдельно телефон, e-mail, и так далее. Защита персональных данных сотрудников требуется в том случае, если эти данные могут утечь в сеть. Если все данные на изолированном сервере в сейфе, доступ к которому имеет только физически ген.дир., к примеру — то какие могут быть претензии?
К сожалению, наше законодательство, зачастую устроено так, чтоб имелось побольше поводов для штрафа. Вас напугали 18млн., а потом совершенно неаффилированные частные компании предлагают спасительную услугу всего за 12к.
Помню, в детстве, гопники на улице таким промышляли.
Да, на одну семью, но довольно просторный. Ниже уже писал. Два этажа, подвал, гараж, баня, участок. Много освещения, в том числе, с регулируемой яркостью.
Видно, что у вас наболело. Позволю себе несколько развеять недопонимание. Датчики многие, к сожалению, действительно, китайские, но выбраны такими исключительно по эстетическим целям и соотношении цена/качество. А вот различные реле, ПЛК и модули ввода производства отечественной ОВЕН. Да, местами тоже не без претензий, но историй про саморезы нет. Проектированием и сборкой щитов занимаюсь не я, но обратная связь на силовых схемах везде присутствует.
Теперь по поводу устройств: не датчиков 150, а различных устройств, в том числе светильники, кондиционеры, термостаты, краны и т.д… И имеем мы с них примерно 0р., так как лишь подбирали оборудование, дилерами не являемся. И уж простите, но я понятия не имею, с чего вы взяли, что я что-либо рекламирую? Сигнализация и видеонаблюдение — делают специально обученные люди. Вот к их подходам у меня вопросы имеются. Ну и в целом. Лично я считаю, что включать свет в туалете голосом — это баловство на неделю, но людям надо. В остальном, вполне адекватные требования для двухэтажного дома с подвалом, баней, гаражом и участком.
Подтверждаю, как раз делаем автоматизированный дом. Около 150 устройств, включая различные датчики, исполнительные и управляющие механизмы. Все на проводах и промышленной автоматике, схема частично децентрализована. Как закончим, может, напишу статью.
Кажется, дискуссия из обсуждения проблем языка переросла в обсуждение наличия библиотек и фреймворков для конкретных языков. Есть тот же go-kit далёкий от идеала, но имеет некоторое количество реализованных транспортов, и спрятать реализацию за интерфейсом в go вполне себе можно. Хотя это не отменяет основных проблем go: многословность и невыразительность. В том же go-kit в некоторых местах используется interface{}, считай, void*, что на корню убивает все прелести статической типизации, а иначе сделать не выйдет, потому что нет обобщений. Отсюда и проблемы с библиотеками, которые по определению нельзя реализовать по типу stl, и это печалит. Либо генерировать код, как предлагает Пайк, что странно в 2021, когда все другие языки давно умеют в дженерики, либо — копипастить одни и те же алгоритмы, подставляя свои значения, либо использовать интерфейсы и ломать типизацию, используя на входе и выходе interface{}, и это ужасно. Вот нашелся в интернете человек, скажем, который реализовал нужный алгоритм и выложил в виде пакета. Все классно, но у него, к примеру, используется int32, а мне нужен int64, все, баста карапузики, только копипаста. Некоторые, конечно, заморачиваются и пилят генераторы кода с инструкциями по использованию, но это же очевидный костыль. Есть ещё масса других проблем поменьше, о которых уже выше сказали, типа тех же ошибок, присваивания, nil и приведения типов. Прошу прощения за объем — наболело за два года использования go. Как-то пришлось делать свою реализацию каналов amqp, потому что общедоступная никак не реагирует на разрыв соединения и такого навалом.
Постараюсь чуть более мягко объяснить позиции комментаторов выше. Open Source хоть и весь такой из себя свободный, но следует определенным принципам, в частности, если хотите, чтобы ваше детище не заглохло, а было подхвачено сообществом, то его необходимо подобающим образом оформить, собственно, даже сам github некоторые советы по этому поводу дает. Не стану высказываться по поводу качества кода — тут уже до меня многие все сказали, да и различных книг по теме архитектуры кодовой базы написано множество, а вот про публикацию кода немного скажу. Дело в том, что, зачастую, оказывается, что подготовить даже нормально написанный код для публикации на girhub может занимать больше времени, чем написание самого кода. Например, необходим нормальный README хотя бы с пояснением сути проекта и основных действий для "пощупать". Пояснительные комментарии к неочевидным частям также необходимы. Неплохо покрыть, хотя бы наиболее важные части кода, автотестами, при этом, прикрутить их к какому-нибудь travis или подобному. В идеале же нужна полноценная документация в виде отдельного сайта или github-pages, шаблоны для разных типов issue, обязательно нужна лицензия (для js-кода лучше подходит, как я считаю, MIT или Apache 2.0). Конечно, нужен как до фронта, так и для бека (могут быть в разных репозиториях проекты), package.json со скриптами для сборки и запуска, потому что нормальное приложение должно запускаться примерно так: git clone && cd <repo_dir> && npm ci && npm run serve. Есть ещё всякие плюшки типа code of conduct, npm audit, swagger и миллион других инструментов, увеличивающих презентабельность проекта в глазах сообщества. Поймите, различных поделок на github миллионы, почему сообщество должно обратить внимание именно на вашу? Напоследок обращу ваше внимание на то, что в рамках README очень полезно описать основные цели проекта, его назначение. Тем самым вы сможете ответить на вопрос — нужен ли он этому миру, да и любой уважающий себя инженер сперва изучает имеющиеся аналоги, а только потом приступает к созданию собственной разработки. Возможно, ответ на последний вопрос и даст вам понять — как же правильно позиционировать и продвигать свое творение. Желаю успехов.
Главная страница репозитория проекта гласит следующее: NW.js is an app runtime based on Chromium and node.js.
Вероятно, да, ваш браузер — не форк Chromium, а скорее плагин для одного, собранный со встроенным бекендом в виде node. Впрочем, раз решение есть, значит оно кому-то нужно.
Небольшой совет от пользователя: выделите как-нибудь блок с адресом, в текущем виде он не выглядит как то, по чему можно кликнуть (можно рамку небольшую добавить, чтоб было больше похоже на поле ввода). Вообще, дизайну есть куда стремиться, но я не специалист в данном вопросе — просто выкладываю субъективные ощущения.
С NW.js не работал никогда, отсюда вопрос: почему не Electron? Он, вроде как, побольше контроля даёт.
Исходников, как я понимаю, в открытом доступе нет?
И ещё такой вопрос: как насчёт изоляции вкладок? Одна другой не может чего лишнего передать?
Ну и последний, самый непонятный для меня: почему решили написать свой браузер? Есть же куча готовых, можно написать плагинов для ff или chrome, в обоих, вроде, бы есть режим киоска. Вы написали, что был опыт форка браузера на qt. Так-то можно было прикрутить туда blink с v8 и не заботиться об обновлениях webview qt.
Соглашусь - так не слишком удобно читать. А причина довольно проста: это был самый простой способ внутренней реализации. Разворачивание цепочки происходит с конца, так так под капотом там односвязный список. Но, по опыту могу сказать, что привыкаешь к такому довольно быстро.
Rollup на выходе генерирует более компактный код.
Мне кажется - проблема в том, что понятие модуля в разных языках разное. В es модулем является файл, но один файл далеко не всегда (скорее, почти никогда) представляется реализацией целого слоя приложения. Если, скажем, разделить приложение на несколько базовых уровней вроде транспортного, бизнес-логики и хранилища, то связи между ними как раз удобно и правильно реализовывать в виде абстракций и инверсии зависимостей. Но в рамках одного слоя, если требуется работа с конкретной базой данных, скажем, то инверсия уже не требуется - используем прямые импорты. При этом бизнес-логика будет работать с любыми видами хранилища через обобщенный интерфейс.
Это не какое-то строгое правило, и подход применим и к более мелким частям приложения, можно ограничить их пространствами имен или макро-модулями (называйте как хотите), вопрос лишь в потребности. Если есть необходимость использовать различные реализации - используем инверсию, и, как правило, инъекцию. Если же такое потребности нет, то зачем усложнять жизнь себе и тем, кто будет читать код? Собственно, мой вопрос состоит в том - почему вы хотите отделить один прием от другого, если они не противоречат друг-другу? Или я неверно вас понял?
Технически как раз проблема была в изуродованном патчами ядре Linux, и вендору при обновлении ядра приходилось все свои блобы заново править, что сильно усложняло процедуру. Сейчас, вроде как, проблема решена или частично решена.
Если бы вы внимательно прочитали первые пару абзацев и последний, то поняли бы, что цель состоит не в том, чтобы показать, как правильно делать, а в том, чтобы заинтересовать читателя самостоятельно разбираться в вопросе дальше. Отсюда и "упрямство". Это как с изучением какого-то раздела математики, часто можно применять в многих задачах, но, зачастую, есть более оптимальные методы. Я же не призываю делать всегда и именно так, как раз наоборот.
Думаю, вы согласитесь, что последний пример с union ужасен, хотя все зависит от конкретных условий, конечно.
UB возникает, насколько мне удалось понять, только в том случае, если приводятся not aligned типы, так что в данном случае его не будет. Что же касается вашего примера с VTable, то это хороший пример, но он, как вы верно заметили, требует отдельной статьи на которую планов пока нет, ибо этому материалу десяток лет, и на C я давненько не писал, а лишь стряхнул пыль со старого материала. Тем не менее, теперь задумался над вашим предложением.
Все бы ничего, но смущает тот факт, что имя библейского Ноя на английском пишется именно как Noah. Не то, чтобы Википедия была каким-то незыблимым авторитетом, но в данном случае, думаю, показательно:
Ноа (ивр. נֹועָה, נֹעָה) — женское библейское имя. Кроме того, так в русской транскрипции выглядит английский вариант мужского библейского имени Ной (Но́ах, ивр. נֹחַ, англ. Noah), не имеющего отношения к женскому.
Не стану делать вид, что понимаю — о чем вы говорите. Вот у нас есть некий условно обобщенный, тип, допустим, он сделан через union, как вы и сказали, и зашит где-то в библиотеке. Если мне нужно добавить поддержку еще одного типа, то что предлагаете делать в таком случае? В случае со структурами — просто описываете новую структуру.
Разве я что-то говорил про сложность? Добавлять реализаци по мере необходимости означает то, что эти реализации могут добавляться вообще в другом месте. Например, у нас может быть библиотека, работающая с определенным интерфейсом, его реализацию мы можем добавить в своей программе. Как подобная задача будет решаться с использованием объединений скажите, пожалуйста? Сразу отмечу, что вопрос академического характера, то есть не надо рассматривать в контексте "нужно ли оно вообще".
Насчет UB — надо будет пошерстить стандарт.
Пример с примитивными типами, очевидно, рассмотрен для простоты. Ниже уже идет чуть более осмысленный пример. Объединения хороши для своих задач и требуют сразу указать все возможные типы, а с "интерфесами" можно добавлять реализации по мере необходимости, лишь бы они соответствовали контрактам интерфейса.
Округление переписал с использованием
math.h.Не холивара ради, а для саморазвития хочу спросить: а в чем разница между отправкой пароля в открытом виде и отправкой хэша с клиента? Если сервер даёт доступ по этому хэша? А если рандомная соль генерируется на клиенте, то, как сервер проверит этот хэш? Если же позиция и длина истиной части ключа известны, то что мешает тогда злоумышленнику также разобраться и самому подставлять рандомную соль?
Пару лет назад приходилось ковыряться в вопросе. И совсем не все так однозначно, как вы говорите. Да, наши "провайдеры", конечно, скажут, что все надо хранить в их защищённом облаке, да ещё и доступ, желательно по сертифицированному VPN. Но правда часто оказывается далека от сказок. Для тех же онлайн-магазинов, зачастую персональные данные и не требуется хранить вовсе. Само понятие персональных данных подразумевает однозначную идентификацию человека по набору некоторых признаков. Таким образом, ФИО сами по себе — не перс. данные. Также ими не является публичная информация (тут есть нюансы в трактовке), отдельно телефон, e-mail, и так далее. Защита персональных данных сотрудников требуется в том случае, если эти данные могут утечь в сеть. Если все данные на изолированном сервере в сейфе, доступ к которому имеет только физически ген.дир., к примеру — то какие могут быть претензии?
К сожалению, наше законодательство, зачастую устроено так, чтоб имелось побольше поводов для штрафа. Вас напугали 18млн., а потом совершенно неаффилированные частные компании предлагают спасительную услугу всего за 12к.
Помню, в детстве, гопники на улице таким промышляли.
Да, на одну семью, но довольно просторный. Ниже уже писал. Два этажа, подвал, гараж, баня, участок. Много освещения, в том числе, с регулируемой яркостью.
Видно, что у вас наболело. Позволю себе несколько развеять недопонимание. Датчики многие, к сожалению, действительно, китайские, но выбраны такими исключительно по эстетическим целям и соотношении цена/качество. А вот различные реле, ПЛК и модули ввода производства отечественной ОВЕН. Да, местами тоже не без претензий, но историй про саморезы нет. Проектированием и сборкой щитов занимаюсь не я, но обратная связь на силовых схемах везде присутствует.
Теперь по поводу устройств: не датчиков 150, а различных устройств, в том числе светильники, кондиционеры, термостаты, краны и т.д… И имеем мы с них примерно 0р., так как лишь подбирали оборудование, дилерами не являемся. И уж простите, но я понятия не имею, с чего вы взяли, что я что-либо рекламирую? Сигнализация и видеонаблюдение — делают специально обученные люди. Вот к их подходам у меня вопросы имеются. Ну и в целом. Лично я считаю, что включать свет в туалете голосом — это баловство на неделю, но людям надо. В остальном, вполне адекватные требования для двухэтажного дома с подвалом, баней, гаражом и участком.
Подтверждаю, как раз делаем автоматизированный дом. Около 150 устройств, включая различные датчики, исполнительные и управляющие механизмы. Все на проводах и промышленной автоматике, схема частично децентрализована. Как закончим, может, напишу статью.
Кажется, дискуссия из обсуждения проблем языка переросла в обсуждение наличия библиотек и фреймворков для конкретных языков. Есть тот же go-kit далёкий от идеала, но имеет некоторое количество реализованных транспортов, и спрятать реализацию за интерфейсом в go вполне себе можно. Хотя это не отменяет основных проблем go: многословность и невыразительность. В том же go-kit в некоторых местах используется interface{}, считай, void*, что на корню убивает все прелести статической типизации, а иначе сделать не выйдет, потому что нет обобщений. Отсюда и проблемы с библиотеками, которые по определению нельзя реализовать по типу stl, и это печалит. Либо генерировать код, как предлагает Пайк, что странно в 2021, когда все другие языки давно умеют в дженерики, либо — копипастить одни и те же алгоритмы, подставляя свои значения, либо использовать интерфейсы и ломать типизацию, используя на входе и выходе interface{}, и это ужасно. Вот нашелся в интернете человек, скажем, который реализовал нужный алгоритм и выложил в виде пакета. Все классно, но у него, к примеру, используется int32, а мне нужен int64, все, баста карапузики, только копипаста. Некоторые, конечно, заморачиваются и пилят генераторы кода с инструкциями по использованию, но это же очевидный костыль. Есть ещё масса других проблем поменьше, о которых уже выше сказали, типа тех же ошибок, присваивания, nil и приведения типов. Прошу прощения за объем — наболело за два года использования go. Как-то пришлось делать свою реализацию каналов amqp, потому что общедоступная никак не реагирует на разрыв соединения и такого навалом.
Постараюсь чуть более мягко объяснить позиции комментаторов выше. Open Source хоть и весь такой из себя свободный, но следует определенным принципам, в частности, если хотите, чтобы ваше детище не заглохло, а было подхвачено сообществом, то его необходимо подобающим образом оформить, собственно, даже сам github некоторые советы по этому поводу дает. Не стану высказываться по поводу качества кода — тут уже до меня многие все сказали, да и различных книг по теме архитектуры кодовой базы написано множество, а вот про публикацию кода немного скажу. Дело в том, что, зачастую, оказывается, что подготовить даже нормально написанный код для публикации на girhub может занимать больше времени, чем написание самого кода. Например, необходим нормальный README хотя бы с пояснением сути проекта и основных действий для "пощупать". Пояснительные комментарии к неочевидным частям также необходимы. Неплохо покрыть, хотя бы наиболее важные части кода, автотестами, при этом, прикрутить их к какому-нибудь travis или подобному. В идеале же нужна полноценная документация в виде отдельного сайта или github-pages, шаблоны для разных типов issue, обязательно нужна лицензия (для js-кода лучше подходит, как я считаю, MIT или Apache 2.0). Конечно, нужен как до фронта, так и для бека (могут быть в разных репозиториях проекты), package.json со скриптами для сборки и запуска, потому что нормальное приложение должно запускаться примерно так: git clone && cd <repo_dir> && npm ci && npm run serve. Есть ещё всякие плюшки типа code of conduct, npm audit, swagger и миллион других инструментов, увеличивающих презентабельность проекта в глазах сообщества. Поймите, различных поделок на github миллионы, почему сообщество должно обратить внимание именно на вашу? Напоследок обращу ваше внимание на то, что в рамках README очень полезно описать основные цели проекта, его назначение. Тем самым вы сможете ответить на вопрос — нужен ли он этому миру, да и любой уважающий себя инженер сперва изучает имеющиеся аналоги, а только потом приступает к созданию собственной разработки. Возможно, ответ на последний вопрос и даст вам понять — как же правильно позиционировать и продвигать свое творение. Желаю успехов.
Главная страница репозитория проекта гласит следующее: NW.js is an app runtime based on Chromium and node.js.
Вероятно, да, ваш браузер — не форк Chromium, а скорее плагин для одного, собранный со встроенным бекендом в виде node. Впрочем, раз решение есть, значит оно кому-то нужно.
Небольшой совет от пользователя: выделите как-нибудь блок с адресом, в текущем виде он не выглядит как то, по чему можно кликнуть (можно рамку небольшую добавить, чтоб было больше похоже на поле ввода). Вообще, дизайну есть куда стремиться, но я не специалист в данном вопросе — просто выкладываю субъективные ощущения.
С NW.js не работал никогда, отсюда вопрос: почему не Electron? Он, вроде как, побольше контроля даёт.
Исходников, как я понимаю, в открытом доступе нет?
И ещё такой вопрос: как насчёт изоляции вкладок? Одна другой не может чего лишнего передать?
Ну и последний, самый непонятный для меня: почему решили написать свой браузер? Есть же куча готовых, можно написать плагинов для ff или chrome, в обоих, вроде, бы есть режим киоска. Вы написали, что был опыт форка браузера на qt. Так-то можно было прикрутить туда blink с v8 и не заботиться об обновлениях webview qt.