Для 8 летнего лучше всего начинать знакомство с программированием со scratch.mit.edu
Если зайдет (вероятность 80%), то можно продолжить на платформе progkids.com
На которой наши отечественные разработчики скрестили блочное программирование и даже Python с Minecraft 1.12
Лучшие книги по Scratch: www.labirint.ru/books/552457 www.labirint.ru/books/705204
Детский онлайн курс по Scratch и по программированию в Minecraft есть на платформе codim.online
Ну а если ребенок предпочитает только планшет, то остается ScratchJR для начинающих, он гораздо проще чем Swift Playgrounds
Не забывайте, что irq affinity можно навешивать не только на сетевухи, но и на storage девайсы
Новые сетевухи умеют `adaptive-rx`/`adaptive-tx`, совсем новые `rx-usecs-high`
NUMA лучше не interleave'ить, а использовать по назначению. Запустите N инстансов приложения. Каждое на своей ноде. Каждой свой CPU и память, а так же сетевуху (NUMA ноду для irq affinity через можно определить от /sys/class/net/eth*/device/numa_node) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост
Для файлсерверов очень опасна/proc/sys/vm/zone_reclaim_mode — важно, чтобы оно было выставленно в ноль
Уже не совсем в тему оптимизации производительности, а скорее ускореения пользователей — стоит поиграться с TCP congestion алгоритмами (Netflix написали свой оптимизированый для видео и их склиентов: cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)
Если бы у вас были интерактивные штуки, а не видео, то было бы интересно поиграться с buffer bloat (sch_fq, tsq, bql, etc).
1. ТЗ это инструмент для налаживания взаимопонимания, идеально когда оно отвечает на вопрос:
— что надо сделать?
— на вопрос КАК надо сделать ТЗ отвечает не всегда, т.к. не всегда это понятно и есть много вариантов.
2. ТЗ должно быть понятно и заказчику и исполнителю
3. Читать должны заказчик и исполнитель.
— хорошо когда ТЗ из маленьких блоков, которые легко превращаются в задачи в таск-менеджере
— я люблю когда один блок — одна демонстрация, чем раньше начать демонстрацию готовых кусков по ТЗ заказчику — тем лучше, тем меньше переделок, тем меньше непонимания
4. Вместе! Работа совместная, иначе ад
5. Хорошо бы иметь опыт уже реализованных похожих проектов
6. Критерий качества: заказчик и исполнитель готовы расписаться, что понимают что нужно сделать
7. Я предпочитаю
— писать ТЗ на маленькие этапы, в них изменения либо некритичные, либо приводят к отмене всего этапа и пересмотру всего контракта
— я предпочитаю предложить доделать этап и к нему написать новое ТЗ на изменение
* иначе все вязнет
8. Аналитик — отвечает за выстраивание отношений с заказчиком и разработчиком. Он занимается челночной дипломатией, помогает достичь договоренностей. Чтобы с одной стороны заказчик получил именно то, о чем мечтал, с другой стороны чтобы это что-то было понятным и реализуемым.
Аналитик помогает заказчику сформулировать задачи, а разработчикам сформулировать ограничения.
9. ТЗ помогает помнить договоренности и по возможности не уходить от них далеко. Судебный процесс — дело на годы, если взаимонепонимание зашло так далеко, то в суде ТЗ не особо кого спасет.
10. ТЗ — это план для будущего user manual, но не его содержание.
Резюмируя:
ТЗ отвечает на вопрос: «Что нужно сделать?»
Проектная документация отвечает на вопрос: «Как это сделать?»
Мануал отвечает на вопрос: «Как это эксплуатировать?»
Аналитик помогает сформулировать задачи с одной стороны и ограничения по реализуемости с другой стороны
Что есть ТЗ? Одна задача «Поменять надпись на кнопке» — это ТЗ?
Есть формализованное представление ТЗ. есть рекомендации к формулировке:
Атомарность требования.
Система должна формировать отчет Х. форма отчета см приложение № (правильно)
Система должна формировать отчет Y. форма отчета см приложение № (правильно)
Система должна формировать отчеты. (не правильно)
Проверямость требования.
Система должна обеспечить время формирования отчета не более чем за ### при нагрузке в ### запросов. (это правильно)
Система сохранять отчет. (это НЕ правильно)
Непротиворечивость требований.
Система должна работать на микропроцессорах с системой комманд MIPS под операционной системой Windows 10 Pro
Кто должен писать ТЗ, заказчик или исполнитель со слов заказчика?
Это СОГЛАШЕНИЕ двух сторон, которе после закрепляется юридически. значит требуется участие двух сторон.
Какие возможны критерии качества ТЗ, чтобы определить хорошее оно или плохое? И насколько эти критерии разнятся между заказчиком и исполнителем? Можно ли одним ТЗ удовлетворить обе стороны?
Есть формализованные трбования:
Юридические
технологические. см страндарты ISO
Кому предназначается ТЗ? Кто те люди (роли), кто должны его читать?
Читают все участники проекта — это ПУБЛИЧНЫЙ документ :)
Со стороны Подрядчика — согласно требуемых ролей в проекте (Hr, менеджеры, юристы, UI/UX спецы, архитекторы, разработчики для связанных задач, QA, развертывание, сопровождение ...)
Каков процесс изменения ТЗ? Ведь, если мы начали работу по уже написанному ТЗ, то любое его изменение вероятнее всего повлияет на оценку проекта. Почти всегда отклонение оценки будет не в пользу исполнителя (нужно больше усилий, времени, денег).
Стандартная процедура Change Management. Так и есть. каскадные изменения.
Не является ли ТЗ (как увесистый документ), чаще всего лишь, не совсем удачным способом описания юридической ответственности сторон? И по сути, обеспечивает процесс продажи и заключения сделки, а не исполнения проекта?
Нет. Не является. Если подрядчик идиот, то ему просто выстявят неустойку за неисполнение проекта, плюс упущенную прибыль :) Про репутацию лучше и не заикаться :)
Почему считается, что БИЗНЕС-аналитики должны писать ТЕХНИЧЕСКОЕ задание? Каков должен быть вклад бизнес-аналитика в ТЗ?
Это не являтся обязательным. Но если специфическая область (банки, таможня, здравохранение и т.д.) то владение терминологией значительно упрощает и ускоряет написание ТЗ, заодно устраняет явные косяки при его написании. Если стороны не владеют в полной мере нюансами предметной области, его могут отдать на резензирование третьей стороне на условиях NDA.
Может ли документация (user manual) на готовый проект, считаться его ТЗ? Насколько тесно связаны документация и ТЗ
Может ли йогурт считаться молоком? Мануал — это результат исполения ТЗ. При корректном процессе исполнения, ТЗ будет являться «оглавлением» мануала :)
Чип 8188 неправильно выбран для «исследований уязвимостей сетей».
Лучше было бы из этого списка:
https://www.aircrack-ng.org/doku.php?id=compatibility_drivers#which_is_the_best_card_to_buy
Драйверы устр-ва (zip c картинкой PDF) не грузятся с оф. сайта!
Простите, я думал у вас чуть лучше понимание терминологии. Моя вина.
Я как-то начинал писать статью «бухгалтерия для программиста», с основами терминологии, но всё время не найду поправить ее красоту.
Попробую здесь кратко:
1 — основа бухгалтерии это двойная запись. Любая проводка (экзотику оставим за скобками) состоит из трех основных полей: номер счета который дебетуем, номер счета который кредетуем и сумма. Т.е. у нас ВСЕГДА меняется два счета на одну сумму.
2 — термины «дебет и кредит» не являются синонимами слов «приход и расход». В половине случаев они меняются местами.
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
4 — Дебет у нас увеличивает активный счет, и уменьшает пассивный, кредит же наоборот уменьшает активный и увеличивает пассивный. Такая слегка запутывающая схема придумана для того, чтобы у нас сохранялся баланс и при этом у нас наша универсальная операция работала бы как при операциях между активным и пассивным счетом, так и между двумя активными или двумя пассивными…
5 — список наших счетов с их свойствами (актив/пассив) называется «план счетов»
6 — данная схема удобна не только для бухгалтерии где планы счетов регламентированны, но и для управленческого учета, где ты делаешь что хочешь, под свои задачи. Это важно. 1С-бухгалтерия это именно бухгалтерия…
Краткий (очень краткий) пример:
В начале у нас всё по нулям.
Первой операцией у нас будет квитанция от вебмани о поступлении денег в пользу клиента «Иван».
Мы создаем документ «пополнение», со всеми реквизитами, и параллельно делаем следующие проводки:
Дебет активного счета «Средства на вебмани», Кредит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», сумма == 100руб.
Следующим документом мы покупаем у ДЦ «Розочка» ресселерский акк, у которого рессурсов хватит на два таких клиента. Оплачиваем вебмани.
Проводки:
Дебит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», Кредит активного «Средства вебмани», сумма 50 руб.
Ну и третий документ — покупка клиентом хостинга на месяц и списание за него денег (Клиенту стоит 50руб). Проводки такие:
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», Кредит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», сумма 25 руб.
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», кредит пассивного «Нераспределенная прибыль», сумма 25руб.
Баланс на выходе:
Активы:
Деньги на вебманях = 50руб.
Оплаченные хостинги = 25руб.
Пассивы:
«Доходы будущих периодов», субсчет «Счет клиента Иван» = 50руб.
«Нераспределенная прибыль» = 25руб.
Такая схема дает больше возможностей, при этом проще.
У нас всего три сущности было: Счет, Проводка и Документ.
Да, Документы бывают разных типов, но уже бизнеслогика, а скелет можно разместить в абстрактном классе.
Для Украины посмотрите в сторону www.pesoto.com/ — 12 баксов кг. В средне доставка две недели занимает. В регионы с Киева отправляют Новой Почтой. Уже раз пять пользовался, пока все нравится.
Это отличный ультрабук, но я крайне не рекомендую вам его покупать.
Его сейчас очень сложно найти в продаже, а всё потому, что для Asus это оказалась очень проблеманя модель.
Основная проблема — экран. На моем через месяц появились битые пиксели. По словам сервисного центра, они дважды заказывали матрицу на замену и обе приходили также с битыми пикселями. Плюс разрешение 1080 на 13" экране — очень некомфортно, на экране по кругу засветы.
Также узким местом является шарнир крепления экрана, он очень быстро разбалтывается.
Ну и вдовесок: клавиатура прогибается, крышки (верхняя и нижняя) очень тонкие и тоже гнутся, дисковая подсистема медленная (SSD там очень тормозной и в качестве системного диска не дает особого выигрыша), сам ноутбук ощутимо греется, батарея живет недолго.
Хотя ноутбук по характеристикам очень «вкусный».
Через 45 дней «ремонта» я забрал деньги и купил макбук. Не пожалел ни на секунду — по качеству «небо и земля», хотя я всегда с уважением относился к Asus.
Он прав. Эта штука от грозы слабо поможет — импульс пройдёт насквозь. Или даже пробьёт изоляцию (витая пара всего 500-1000 Вольт держит). Нужно, как минимум, на внешней обмотке поставить мощный двуполярный защитный стабилитрон. Кроме того, не поверите, но практически во всех Ethernet-адаптерах уже стоят развязывающие трансформаторы.
Отсюда мораль — минимальная правильная защита выглядит так (что и собрано в большинстве промышленных защитных устройств):
1) Никакого трансформатора.
2) Двунапрвленный защитный стабилитрон в корпусе не менее SMBJ на напряжение 5 Вольт между проводниками каждой пары.
3) Разрядник на 120 Вольт между одним проводом каждой пары и землёй.
4) Опционально — разрядник 120 Вольт между проводами каждой пары (в быту как правило не нужен).
4) Резистор 1 МОм от одного провода каждой пары на землю. Резистор должен быть мощностью не менее 0,25 Ватт (чтобы не пробило через него в обход разрядника). Нужен для выравнивания потенциалов, чтобы стекало статическое электричество.
Вот это спасёт практически от чего угодно.
Защищаются все пары, входящие в защищаемое устройство (т.е. если используются только две пары, то остальные входящие пары сажаем на землю и на защищаемое устройство не передаём).
Несколько лет уже верстаю с некоторыми идеями БЭМ. Имхо тот БЭМ, которые предлагается сейчас, оправдан только для больших проектов, в которых производятся постоянные изменения. Яндекс например =) У них же практически все сервисы на одинаковых блоках — для них это реально ускорение разработки и поддержки. Для мелких и средних проектов разработка в строгом в соответствии с БЭМ — только увеличение сроков, а пользы гораздо меньше. В таких проектах нет смысла везде использовать, например, абсолютно независимые блоки.
В своей верстке использую следующие правила:
1) именование только классами.
2) блоки, задающие структуру страницы, именовать с префиксом l- (деление на колонки к примеру)
3) логически выделенные блоки (например, меню, список новостей, пагинация и тп) именовать классом с префиксом b-, а внутри этих блоков именовать как угодно
4) блоки, которые могут использоваться внутри других блоков, делать абсолютно независимыми (к примеру вывод какой-н. информации, который используется в различных блоках)
5) Модификаторы класса указываю через дефис (поэтому для названия блока использую стиль camelCase).
В таком случае не теряется скорость верстки из-за оч. длинных классов и их увелечения, но при этом мы получаем лёгкую поддержку верстки и безпроблемное написание новых блоков.
Это задает строку, по которой сервер сообщений будет отличать одно приложение от другого, если их станет несколько. Вместо «anything» можно написать что угодно, только чтобы потом не запутаться.
Это где это вы такое узрели? Это «защита» от того чтобы никто кроме приложения не мог постить в каналы.
«Защита» потому что этот самый токен будет передаваться всем вместе с сообщением. Чтобы этого не было нужно этот токен в ServerAuth#incoming удалять из сообщения перед отправкой подписчикам. Еще неплохо этот токен создавать динамически и периодически менять.
Далее, никто не мешает клиенту подписаться на все каналы ('/*') и получать то, что ему не предназначено. Лечится это дополнительной проверкой в ServerAuth#incoming примерно так:
Следующий момент: т.к. faye-сервер у вас запущен по адресу moesuperprilozhenie.ru:9292, то имеем CORS. Чтобы Rack правильно его обрабатывал, нужно поставить гем rack-cors и прописать в конфиге faye:
require 'rack/cors'
use Rack::Cors do
allow do
origins '*'
resource '/faye', :headers => :any, :methods => [:get, :post, :options]
end
end
(Как вариант это можно решить через прокси на front-end)
Эту «опцию» у PayPal еще постараться найти надо, глубоко запрятали:
Профиль -> Мои средства -> В пункте «Мои предварительно утвержденные платежи» нажимаем «Обновить» -> Там будет табличка со ссылкой «Задайте доступные источники финансирования» в правом верхнем углу, жмем ее -> Попадаем в «Управление источниками финансирования», там табличка со списком всех привязанных карт, напротив нужной нажимаем «Варианты конвертирования» -> Выбираем пункт «Прошу выставлять мне счета в валюте, указанной в фактуре продавца».
Это же можно делать каждый раз во время платежа, но, по-моему, один раз настроить удобнее.
Ну и пример для виртуальных карт от QIWI (числа приблизительные, за прошлую неделю). Конвертация PayPal была около 32,5 рублей за доллар, конвертация QIWI — около 30 (то есть даже меньше, чем у ЦБ). Выгода налицо.
Если зайдет (вероятность 80%), то можно продолжить на платформе progkids.com
На которой наши отечественные разработчики скрестили блочное программирование и даже Python с Minecraft 1.12
Лучшие книги по Scratch:
www.labirint.ru/books/552457
www.labirint.ru/books/705204
Детский онлайн курс по Scratch и по программированию в Minecraft есть на платформе
codim.online
Ну а если ребенок предпочитает только планшет, то остается ScratchJR для начинающих, он гораздо проще чем Swift Playgrounds
/sys/class/net/eth*/device/numa_node) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост/proc/sys/vm/zone_reclaim_mode— важно, чтобы оно было выставленно в нольethtool -k(tso, lro,[rt]xcsum, etc) и почти всегда надо задирать ring buffer'а вethtool -glspci -t -vvv(особо важно для 40G+)cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)— что надо сделать?
— на вопрос КАК надо сделать ТЗ отвечает не всегда, т.к. не всегда это понятно и есть много вариантов.
2. ТЗ должно быть понятно и заказчику и исполнителю
3. Читать должны заказчик и исполнитель.
— хорошо когда ТЗ из маленьких блоков, которые легко превращаются в задачи в таск-менеджере
— я люблю когда один блок — одна демонстрация, чем раньше начать демонстрацию готовых кусков по ТЗ заказчику — тем лучше, тем меньше переделок, тем меньше непонимания
4. Вместе! Работа совместная, иначе ад
5. Хорошо бы иметь опыт уже реализованных похожих проектов
6. Критерий качества: заказчик и исполнитель готовы расписаться, что понимают что нужно сделать
7. Я предпочитаю
— писать ТЗ на маленькие этапы, в них изменения либо некритичные, либо приводят к отмене всего этапа и пересмотру всего контракта
— я предпочитаю предложить доделать этап и к нему написать новое ТЗ на изменение
* иначе все вязнет
8. Аналитик — отвечает за выстраивание отношений с заказчиком и разработчиком. Он занимается челночной дипломатией, помогает достичь договоренностей. Чтобы с одной стороны заказчик получил именно то, о чем мечтал, с другой стороны чтобы это что-то было понятным и реализуемым.
Аналитик помогает заказчику сформулировать задачи, а разработчикам сформулировать ограничения.
9. ТЗ помогает помнить договоренности и по возможности не уходить от них далеко. Судебный процесс — дело на годы, если взаимонепонимание зашло так далеко, то в суде ТЗ не особо кого спасет.
10. ТЗ — это план для будущего user manual, но не его содержание.
Резюмируя:
ТЗ отвечает на вопрос: «Что нужно сделать?»
Проектная документация отвечает на вопрос: «Как это сделать?»
Мануал отвечает на вопрос: «Как это эксплуатировать?»
Аналитик помогает сформулировать задачи с одной стороны и ограничения по реализуемости с другой стороны
Есть формализованное представление ТЗ. есть рекомендации к формулировке:
Это СОГЛАШЕНИЕ двух сторон, которе после закрепляется юридически. значит требуется участие двух сторон.
Есть формализованные трбования:
Читают все участники проекта — это ПУБЛИЧНЫЙ документ :)
Со стороны Подрядчика — согласно требуемых ролей в проекте (Hr, менеджеры, юристы, UI/UX спецы, архитекторы, разработчики для связанных задач, QA, развертывание, сопровождение ...)
Стандартная процедура Change Management. Так и есть. каскадные изменения.
Нет. Не является. Если подрядчик идиот, то ему просто выстявят неустойку за неисполнение проекта, плюс упущенную прибыль :) Про репутацию лучше и не заикаться :)
Это не являтся обязательным. Но если специфическая область (банки, таможня, здравохранение и т.д.) то владение терминологией значительно упрощает и ускоряет написание ТЗ, заодно устраняет явные косяки при его написании. Если стороны не владеют в полной мере нюансами предметной области, его могут отдать на резензирование третьей стороне на условиях NDA.
Может ли йогурт считаться молоком? Мануал — это результат исполения ТЗ. При корректном процессе исполнения, ТЗ будет являться «оглавлением» мануала :)
Лучше было бы из этого списка:
https://www.aircrack-ng.org/doku.php?id=compatibility_drivers#which_is_the_best_card_to_buy
Драйверы устр-ва (zip c картинкой PDF) не грузятся с оф. сайта!
Я как-то начинал писать статью «бухгалтерия для программиста», с основами терминологии, но всё время не найду поправить ее красоту.
Попробую здесь кратко:
1 — основа бухгалтерии это двойная запись. Любая проводка (экзотику оставим за скобками) состоит из трех основных полей: номер счета который дебетуем, номер счета который кредетуем и сумма. Т.е. у нас ВСЕГДА меняется два счета на одну сумму.
2 — термины «дебет и кредит» не являются синонимами слов «приход и расход». В половине случаев они меняются местами.
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
4 — Дебет у нас увеличивает активный счет, и уменьшает пассивный, кредит же наоборот уменьшает активный и увеличивает пассивный. Такая слегка запутывающая схема придумана для того, чтобы у нас сохранялся баланс и при этом у нас наша универсальная операция работала бы как при операциях между активным и пассивным счетом, так и между двумя активными или двумя пассивными…
5 — список наших счетов с их свойствами (актив/пассив) называется «план счетов»
6 — данная схема удобна не только для бухгалтерии где планы счетов регламентированны, но и для управленческого учета, где ты делаешь что хочешь, под свои задачи. Это важно. 1С-бухгалтерия это именно бухгалтерия…
Краткий (очень краткий) пример:
В начале у нас всё по нулям.
Первой операцией у нас будет квитанция от вебмани о поступлении денег в пользу клиента «Иван».
Мы создаем документ «пополнение», со всеми реквизитами, и параллельно делаем следующие проводки:
Дебет активного счета «Средства на вебмани», Кредит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», сумма == 100руб.
Следующим документом мы покупаем у ДЦ «Розочка» ресселерский акк, у которого рессурсов хватит на два таких клиента. Оплачиваем вебмани.
Проводки:
Дебит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», Кредит активного «Средства вебмани», сумма 50 руб.
Ну и третий документ — покупка клиентом хостинга на месяц и списание за него денег (Клиенту стоит 50руб). Проводки такие:
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», Кредит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», сумма 25 руб.
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», кредит пассивного «Нераспределенная прибыль», сумма 25руб.
Баланс на выходе:
Активы:
Деньги на вебманях = 50руб.
Оплаченные хостинги = 25руб.
Пассивы:
«Доходы будущих периодов», субсчет «Счет клиента Иван» = 50руб.
«Нераспределенная прибыль» = 25руб.
Такая схема дает больше возможностей, при этом проще.
У нас всего три сущности было: Счет, Проводка и Документ.
Да, Документы бывают разных типов, но уже бизнеслогика, а скелет можно разместить в абстрактном классе.
github.com/elasticsearch/kibana/issues/1628
Example for nginx:
Включаем ssl при подключении к elastic в кибана:
kibana/config.js:
— elasticsearch: «http://»+window.location.hostname+":9200",
+ elasticsearch: «https://»+window.location.hostname/,
example.org.conf for nginx:
server {
listen *:443 ssl;
server_name example.org
ssl on;
…
location / {
proxy_pass 127.0.0.1:9292;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/.*/_mapping {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/.*/_search$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/_aliases$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/_nodes$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/kibana-int/dashboard/.*$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/kibana-int/temp.*$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ ^/.*/_aliases$ {
proxy_pass 127.0.0.1:9200;
proxy_read_timeout 90;
proxy_connect_timeout 90;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
И обсуждение сервиса на их форуме: forum.shopfans.ru/viewtopic.php?f=3&t=610
Тарифы на главной найдете :)
Его сейчас очень сложно найти в продаже, а всё потому, что для Asus это оказалась очень проблеманя модель.
Основная проблема — экран. На моем через месяц появились битые пиксели. По словам сервисного центра, они дважды заказывали матрицу на замену и обе приходили также с битыми пикселями. Плюс разрешение 1080 на 13" экране — очень некомфортно, на экране по кругу засветы.
Также узким местом является шарнир крепления экрана, он очень быстро разбалтывается.
Ну и вдовесок: клавиатура прогибается, крышки (верхняя и нижняя) очень тонкие и тоже гнутся, дисковая подсистема медленная (SSD там очень тормозной и в качестве системного диска не дает особого выигрыша), сам ноутбук ощутимо греется, батарея живет недолго.
Хотя ноутбук по характеристикам очень «вкусный».
Через 45 дней «ремонта» я забрал деньги и купил макбук. Не пожалел ни на секунду — по качеству «небо и земля», хотя я всегда с уважением относился к Asus.
Хотя… если у вас была цель по программировать, то да, тоже вариант.
Отсюда мораль — минимальная правильная защита выглядит так (что и собрано в большинстве промышленных защитных устройств):
1) Никакого трансформатора.
2) Двунапрвленный защитный стабилитрон в корпусе не менее SMBJ на напряжение 5 Вольт между проводниками каждой пары.
3) Разрядник на 120 Вольт между одним проводом каждой пары и землёй.
4) Опционально — разрядник 120 Вольт между проводами каждой пары (в быту как правило не нужен).
4) Резистор 1 МОм от одного провода каждой пары на землю. Резистор должен быть мощностью не менее 0,25 Ватт (чтобы не пробило через него в обход разрядника). Нужен для выравнивания потенциалов, чтобы стекало статическое электричество.
Вот это спасёт практически от чего угодно.
Защищаются все пары, входящие в защищаемое устройство (т.е. если используются только две пары, то остальные входящие пары сажаем на землю и на защищаемое устройство не передаём).
В своей верстке использую следующие правила:
1) именование только классами.
2) блоки, задающие структуру страницы, именовать с префиксом l- (деление на колонки к примеру)
3) логически выделенные блоки (например, меню, список новостей, пагинация и тп) именовать классом с префиксом b-, а внутри этих блоков именовать как угодно
4) блоки, которые могут использоваться внутри других блоков, делать абсолютно независимыми (к примеру вывод какой-н. информации, который используется в различных блоках)
5) Модификаторы класса указываю через дефис (поэтому для названия блока использую стиль camelCase).
В таком случае не теряется скорость верстки из-за оч. длинных классов и их увелечения, но при этом мы получаем лёгкую поддержку верстки и безпроблемное написание новых блоков.
Впрочем я накатил классический hiren's boot cd и решил свои задачи с ним.
«Защита» потому что этот самый токен будет передаваться всем вместе с сообщением. Чтобы этого не было нужно этот токен в ServerAuth#incoming удалять из сообщения перед отправкой подписчикам. Еще неплохо этот токен создавать динамически и периодически менять.
Далее, никто не мешает клиенту подписаться на все каналы ('/*') и получать то, что ему не предназначено. Лечится это дополнительной проверкой в ServerAuth#incoming примерно так:
Следующий момент: т.к. faye-сервер у вас запущен по адресу moesuperprilozhenie.ru:9292, то имеем CORS. Чтобы Rack правильно его обрабатывал, нужно поставить гем rack-cors и прописать в конфиге faye:
(Как вариант это можно решить через прокси на front-end)
Профиль -> Мои средства -> В пункте «Мои предварительно утвержденные платежи» нажимаем «Обновить» -> Там будет табличка со ссылкой «Задайте доступные источники финансирования» в правом верхнем углу, жмем ее -> Попадаем в «Управление источниками финансирования», там табличка со списком всех привязанных карт, напротив нужной нажимаем «Варианты конвертирования» -> Выбираем пункт «Прошу выставлять мне счета в валюте, указанной в фактуре продавца».
Это же можно делать каждый раз во время платежа, но, по-моему, один раз настроить удобнее.
Ну и пример для виртуальных карт от QIWI (числа приблизительные, за прошлую неделю). Конвертация PayPal была около 32,5 рублей за доллар, конвертация QIWI — около 30 (то есть даже меньше, чем у ЦБ). Выгода налицо.