Gennady S

Языков с нативными (родными для языка, поддерживаемыми крупной компанией и/или авторами среды языка и/или ОС) UI-библиотеками мало. Неслучайно прошел бум Electron, Cordova, React Native, что и сейчас в ходу, наряду с перспективными Flutter и MAUI. До сих пор жив Qt, что долгое время был практически безальтернативен по ряду причин, прижившись на многих языках (в том числе несколько проектов для Go). Хорошо обстоит дело со своими UI на C/C++, C#, Java , где немало достойных решений, например, Compose, Avalonia или старожилы wxWidgets, GTK2+ и тот же Qt. Большая часть библиотек для других языков являются мостами, слоями для C/С++ библиотек. Для Go так же существуют прослойки, а «нативных» (на самом деле тоже слоев) решений для языка ничтожно мало и они любительские, едва ли подходящие для серьезных решений — разве что для каких-то своих узких задач. Решением остается прямой вызов инструментария ОС, вроде Win32 API, что едва популярно в наше время.

https://github.com/go-graphics/go-gui-projects — есть сайты-сборники, где перечисляются многие библиотеки. Но придется изучать:

• Имеющийся функционал, стабильность и удобство
  
• Качество поддержки среды, есть ли обновления и перспективы
  
• Наличие документации и сообщества
  

— на что может уйти прорва времени на фоне решений на других языках. На мой взгляд, на сегодня, для UI одним из лучших вариантом будет C# , тем более если нужна кроссплатформенность. Хорошим выбором будут Electron / JS, Python / PySide, тем более если нужен быстрый прототип. Go — вряд ли, лично я ничего не нашел, свыше прослоек, но зачем тогда Go и трудности слабого сопровождения этих проектов? И да, в ряде случаев локальный сервер с HTML / JS — хорошее решение.

Столкнулся с подобным с двумя звуковыми устройствами, думаю дело в аппаратном отключении-включении устройства и особенностях питания-USB. Когда начинает поступать звук, устройство физически включается, и наоборот, выключается при исчезновении звука. Не знаю, возможно ли это настроить для карт Creative.

Во-первых, Вы не скроете ничего, что передается с клиентской стороны, где бы оно ни хранилось. Такие ключи как правило публичны и не имеют риска хищения. Скажем, привязаны к домену, а для приватных операций требуют отдельной аутентификации/авторизации. Во-вторых, хранить какие-либо настройки в исходном коде в любом случае плохая идея. Все изменяемые значения должны быть вынесены в конфигурационный файл. Поскольку код должен быть распространяемым (отправляться в версии, применяться в других проектах, использоваться в иных условиях и т.д.). Если у Вас нет сборщика и не хотите усложнять кодовую базу, то как минимум в отдельный, подключаемый JS-файл.

PS Еще один момент, если речь о ключе, который получается в результате аутентификации в Google, то приложение должно позволять локальный логин пользователя, нельзя привязывать приложение к аутентификации глобально. В редких случаях при такой необходимости нужно создавать мост для серверной части, которой делегировать любые операции с закрытой частью API.

Вопрос можно удалить, он будет висеть мертвым грузом без ответа. Плата была заменена, плата была нестабильна при многих испробованных настройках. С новой платой (другой модели и другого производителя) и с тем же прочим железом никаких проблем нет.

Это удивительный вопрос! Обычно наоборот, начинающие пытаются понять, почему переменная доступна вне функции.

var a = 0; // переменная, объявленная снаружи, всегда доступна вглубь
function foo () {
  b = 1; // b объявлена как window.b и доступна везде
  var c = 2; // переменная доступна внутри функции
  let d = 3; // переменная доступна внутри блока { }, где объявлена
}
// a == 0
// b == 1
// c == undefined
// d == undefined

А вообще, читайте документацию, mdn, например.

PS Не используйте глобальные переменные. Лучше найти другое решение, связать классы, функции в единую среду выполнения.

Если правильно понял Вашу проблему, то никаких дополнительных усилий прилагать не нужно, данные каждого пользователя будут заполняться параллельно друг другу. Если, конечно, у Вас нет проблем с конфигурацией базы данных, с многопоточной работой серверного приложения и с однопоточным подключением в приложении, например. В остальном, вся сеть так работает: пользователи инициируют работу тех или иных хранилищ, те в свою очередь спокойно параллельно пишут данные. Сложнее решить как раз обратное: исключить одновременную перезапись связанных данных или не выполнять одну работу многократно. Если Вы как раз эту проблему хотите решить, чтобы многие пользователи имели доступ к одному ресурсу данных, используйте блокировки, транзакции. Ну или переосмысляйте архитектуру приложения / структуру данных. Без подробностей вряд ли что-то еще можно посоветовать.

https://docs.mongodb.com/drivers/node/fundamentals... — есть доходчивый пример, нужно запросить искомый элемент { "answers.username": "username" } (искомый элемент массива должен идентифицироваться однозначно, разумеется), но в отличие от примера использовать инкремент https://docs.mongodb.com/manual/reference/operator... — $set: { $inc: { likes: 1 } }

Вас непросто понять. Почему нужен вывод фигурными скобками? set — не функция, а класс, попробуйте вывести type(set). Когда Вы вызываете s = set() — создаете экземпляр класса набора данных, с помощью set(list()) — конвертируете список в множество. Если задание подразумевает создание типа данных, аналогичного set уникальностью значений, то оно несколько сложнее, чем то, что делаете Вы, и фигурные скобки здесь не причем. Вам нужно реализовать класс с методами, добавляющими значения с проверкой на уникальность. Причем, делается это разными способами, можно, например:

class MySet(object):
  def __init__(self):
    self.items = list()

  def add(self, item):
    try:
       self.items.index(item)
       self.items.append(item)
    except ValueError as e:
       pass

И Excel спокойно поглощает такое количество строк? Там вроде около миллиона строк, но Excel не предназначен для этого, если массив данных очень большой, то работать с ним лучше через СУБД.

Способов оптимизации много, но универсальных путей не так много, не зная бизнес-требований, структуры данных сложно сказать точнее. Из общего. Во-первых, да, брать данные порциями, например, по 10к или 50к строк. Во-вторых, не брать данные повторно, кэшировать (вряд ли у Вас меняются все данные каждый раз), сохраняя срезы Excel или денормализацией. В-третьих, оптимизировать структуру данных и / или запросы. В этом плане Doctrine или другой движок едва ли играют роль, тем более Вы используете конструктор запросов. В-четвертых, если память грузит запись в Excel, можно отказаться от движка (опять же, неизвестно, используете ли такой?), писать вручную в XML-шаблон, упаковывая в Excel опять же руками.

А в чем проблема? Разберитесь, как работать с JSON в C#, т.е. 1) распарсить в объект 2) изменить значение 3) записать обратно в JSON. https://docs.microsoft.com/ru-ru/dotnet/standard/s... или https://www.newtonsoft.com/json

А в чем загвоздка? Проблем с этим нет, если журналы грузят базу, то используйте отдельную. И даже не классическую базу, а MongoDB, например, или иные инструменты.

PS Ну а снятие копий, почему не исключить таблицы при выборке? Плюс, есть другие решения для разработчика, например, наборы тестовых данных (у Laravel есть соответствующий инструмент).

Вам нужно смотреть в сторону принципов SOLID, разобраться, почему эти подходы оправданы. Интерфейсы же выполняют несколько задач, в связи с этими принципами.

Во-первых, при разработке приложения, начиная с интерфейсов, программист больше сосредоточен на инкапсуляции, поскольку он в большей степени отвлечен и абстрагирован от конечной реализации, от способа хранения данных.

Во-вторых, интерфейс гарантирует реализацию конечным программистом определенного поведения. Это очень широко применяется. Возьмите те же PSR: тысячи библиотек реализуют одни и те же подходы, и все программисты могут использовать одинаково библиотеки, основанные на этих интерфейсах, не задумываясь о конечной реализации классов.

В-третьих, продуманный интерфейс позволяет в большей степени создавать взаимозаменяемые реализации — конечные классы. Тот, кто использует интерфейс при разработке класса обязан разработать все обязательства интерфейса.

В-четвертых, при взаимодействии программных сущностей, опираясь на интерфейсы, разработчик делает сущности еще более заменяемыми (в том числе с применением таких паттернов как внедрение зависимостей, который, впрочем, может использоваться и без интерфейсов).

Проектирование приложения на базе интерфейсов — полезная практика, хотя и не необходимая. Если пишется небольшое приложение и есть точная уверенность, что оно не будет дальше расширяться и меняться или если не предполагается командная работа, то интерфейсами можно пренебречь. Если приложение масштабно, будет разрабатываться и сопровождаться несколькими специалистами или предполагается его дальнейшее развитие — интерфейсы являются буквально необходимостью.

Добавлю, к слову, о внедрении зависимостей. Действительно, этот подход может использоваться и без интерфейсов, тот факт, что инверсия управления и внедрение зависимостей используются чаще всего с интерфейсами — своего рода совпадение. Хороший пример: фреймворк Yii 2 или библиотека Pimple, там в качестве маркеров для внедрения зависимостей часто используются произвольные (или основанные на иных соглашениях) строки. Это к тому, что DI — необязательно самый яркий пример использования интерфейсов (хотя и более ценный, чем другие варианты).