Codebaker

rm -v !(*_large.jpg|*_thumbnail.jpg|*_large.jpeg|*_thumbnail.jpeg|*_large.png|*_thumbnail.png)

Geocoder API в ответе будет содержать Address объект. Примеры прямо там же.

Выставьте контейнеру не класс, а id, тогда:

var count = $("#container row").length;

Ну наверное потому, что вы лямбду меняете, а стоило бы некую переменную x менять и код чуть переписать на такой:

x--; // ну и соотвественно x++ в альтернативном случае
                    window.Draw(x + GetVertexArray(50, y, lambda));
                    window.Draw(x + GetVertexArraySin(50, y, lambda));

Я не знаком с реализацией Passport, но общие OAuth2 принципы везде одинаковы.
Вы аутентифицируетесь (то есть система вас узнаёт в лицо (в логин-пароль): о, да это же NNovosad !!). В ответ вам присылают access_token - на вот тебе штуку для "действия". Вы этим токеном должны заявить о намерении. То есть начинается вторая фаза - авторизации. Обычно это означает, что вы идёте на некий эндпойнт, который уже сверившись с валидностью access_token-а может подтвердить, можно вам такое действие Х выполнять или нет.

Беглый осмотр доков подсказывает, что вам необходимо реализовать провайдера, который по скоупу (scope) будет выдавать вам Bearer-токен или нет.

Пример из жизни: заходит человек на проходную завода. Его по паспорту и спискам сверяют и выдают пропуск - это аутентификация. А теперь этот человек на "территории завода" и хочет люлей бухгалтерии выписать за медленную работу. Можно ему так делать или нет? Вот если у него авторизация (scope - "управление бухгалтерией") не ниже руководителя правления завода - то конечно же может. В жизни авторизация происходит по визуальным признакам, а в цифровом мире - вот так, через токены, разрешающие действие "разнести в пух и прах"!

В гугл-продуктах, например, не требуется создавать своих провайдеров, а можно для указанных учетных записей задать роли, если такая учетка будет запрашивать действие (ну например, СкачатьГуглДок()), то в соответствии с настройками ролей, Bearer будет выдан или нет). Scope при этом указывается в виде url- для гугл-док-апи.

Надеюсь, работа OAuth2 стала яснее для Вас.

notify-send "`date`" "Hey! Do you really need lamp indicators?!"

byte b = Byte.parseByte(str, 2);

git config -l (login, remotes)
git remote -v (remote url)

пароль никак

pip install pipwin
pipwin install pyaudio

Ваш дамп - это обычный текстовый файл, откройте его, перейдите в 502 строчку и посмотрите, что не так с кавычками в ней.

'massage' : text -- массаж в API смущает

Вообще - думать и сомневаться - довольно полезно. Но.

Если это стало уже проблемой: задайте себе вопрос, а где мне это уже помогло? В предыдущем проекте? Как я там делал-то? Что и куда клал? Вызывает ли это боль сейчас? Если нет - переиспользуйте свой подход. Ок, кажется это решит проблему с вопросом что и куда класть.

Теперь с именами - назовите класс наиболее очевидно. Вот что сейчас в голову пришло? ResponseDTO? Ок, отличное начало. Назавтра поняли, что этот класс было бы лучше назвать ServerResponseDTO? Отлично! Есть такая фича: Refactoring, поддерживается почти всеми IDE, и уж точно поддерживается обыным переименованием - ну потратили вы на это пару минут, но стало же лучше? ОК, в следующем проекте подобные имена уже сами будут "всплывать", - это и будет ваш опыт.

Что-то у вас всё в кучу намешано: вы хотели бы собрать сервер на базе десктоп-процессора? Ну ок, а где вы его собираетесь располагать? Дома? Вы вероятно не знаете, что ваш домашний провайдер будет кхм... слегка против.

Как выбрать мат плату: ищите совместимую. По модели процессора (у вас там "или" написано, то есть вы сами ещё не определились, как я понял). "Чтобы порты работали и совместимость" - это даже весело.

Давайте по порядку: десктоп процессоры - они могут быть даже в чём-то помощнее серверных, но точно не умеют работать парами, например.
Задачи домашних материнок: куча портов (чтобы пользователь втыкал туда свои флешки и прочие джойстики), поддержка видеокарт (представляете - сервера так вообще не умеют?!), возможность разгона - у серверных материнок этого НЕТ. Зато есть наработка на отказ с гарантией в несколько лет и всякие фишки типа хот-свопа.

Хостинг? Ок. А опыт в поддержке у вас какой? Вам в комментариях не зря пишут про SLA. Клиентов вы своих уже знаете? А они точно к вам пойдут? А почему? А когда у вас свет выключат, вы что своим клиентам объяснять будете? А за незаконную предпринимательскую сколько у вас дают?