Задать вопрос
Инженер


Фокус: Python, SQL, noSQL, Web, REST, serverside


Интересы: GIS, gamedev, AI, etc
Контакты
Местоположение
Россия

Достижения

Все достижения (77)

Наибольший вклад в теги

Все теги (301)

Лучшие ответы пользователя

Все ответы (1033)
  • Как вычислить виновника из-за которого отваливается интернет с какой-то периодичностью в маленькой сети?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    Такого рода проблемы все и всегда решаются однотипно.
    1. Необходимо сформулировать критерии наличия проблемы.
    Как именно пропадает интернет, насколько часто, как надолго. Это нужно для диагностики. поиска причины и определения ушла ли проблема после принятия каких либо мер.
    2. Делить проблему на части и проверять части по отдельности.
    Самый эффективный способ делить - это пополам. Отсекаем часть сети и проверяем наличие проблемы в обеих частях (если есть возможность) или в одной из частей.
    3. Когда найден минимальный проблемный участок, который уже нельзя или бессмысленно делить - заменяем его.
    4. Помним, что чаще всего сложные проблемы - это композиция нескольких более простых. которые по отдельности могут не проявляться. В вашем случае может быть проблема, связанная с нагрузкой на роутер, например, которую создает один из услов из-за плохого контакта обжима и большого объёма биттых пакетов. Устранив одну из причин, вы, может быть, сделаете проявления проблемы реже, но не устраните её полностью. К примеру, если замените ротуер, битые пакеты будут всё равно будут нагружать вашу сеть и портить ее производительность, но это будет не так очевидно. Переобжав коннектор вы избавитесь от части нагрузки, но еслив ваш ротуер работал на переделе, то лишний вафай-клиент или тяжелый видос в сети сможет его снова нагрузить до критического снижения производительности.

    Итак, пробежимся по перечисленным пунктам сначала.
    1. Критерии. Поиск критериев - это часть решения. Обычно в этом случае нуно сорать необходимую статистику. Есть куча софта, который это умеет делать, но пинг есть всегда под рукой.
    Для этой тулзы есть две полезных опции: ключ для бесконечного пинга и размер пакета.
    В разных ОС эти ключи немного разные, поэтому ищите их отдельно, у меня нет винды под рукой, поэтому не стану на этом заострять.
    Скаж лишь, что пинговать лучше большими пакетами, жалетально превышающими размер TTL, прописанный в роутере. Тогда такой пинг будет реже проскакивать в периоды хорошей связи, то есть выловит больше пролблем.
    Пинговать нужно в отдельных окнах сразу несколько хостов:
    - ya.ru - этот хост всегда отвечает на пинги и выявит проблемы с DNS
    - 8.8.8.8 - это гугловый DNS-сервер, тоже всегда отвечает на пинги, покажет, что связь с инетом есть даже если DNS, прописанныйна компе не правильно работает.
    - 192.168.0.1 - или какой там IP у вашего роутера. Нужно. чтбы отделить проблемы с инетом от проблем с внутренней связностью до роутера
    - 192.168.0.x - ip одного из компов в сети. Я обычно пингую несколько компов, доступных через баксимальное число потенциально проблемных узлов - ethernet-розеток, свичей, вайфай-соединений... Этот пинг поможет понять где проблема, во внутрисетевой связности или в последней миле.

    Учтите, что проблемы часто бывают комбинированные и каждое сочетание симптомов будет свидетельствовать о раных проблемах.
    Да, тревожным принаком может служить не только пропадание пакетов, но и скачки в длительности их возврата, особенно если такие длительности достигают 500мс и выше. Но и скачки от 3мс до 250мс тоже будут свидетельствовать о каких-то проблемах.

    Запускать пинг на всех компах лучше одновременно и на некоторое время. Например минут на 20. Потом по статистике будет видно сколько где пакетов пропало.

    2. Если критерии наличия проблемы позволяют, то можно попробовать отрубать части сети и смотреть наличие проблемы. Это я в том смысле, что если проблема происходит в среднем раз в пару-тройку часов, то отрубать на многие часы части сети при диагностикем ожет быть неприемлемым.
    Редкеи пробемы дольше отлавливать. Но напоминаю, что критерии можно детализировать, ведь если пакеты у вас пропадат относительно редко, то скачки времени их возврата могут случаться чаще и подсвечивать проблему. Также можно сделать рамер пакета близким к максимальному, это должно тоже в некоторых случаях участить проявление проблемы.
    Иногда не мешает нагрузить сеть комированием по локалке большого файла. В линуксе можнно с помощью утилиты tc послать большой поток рандомных байт на любой сокет..
    3. Плавающие проблемы случаются из-за плохого обжима, перебитого жверью кабеля, перегрызенного UTP в плинтусе, из-за умиращих конденсаторов в блоке питания роутера (БП может не выдавать необходимого при нагрузках тока, но вольтметром такая неисправность не будет различима без нагрузки). Вообще старые (да и не только) роутеры могут страдать поплывшими электролитическими конденсаторами не только в блоках питания.
    Хорошо, когда можно подменить роутер.
    4. ну с четвертым пунктом ничего не пососветуешь, только разделать и тестировать все по отедльности и в разных сочетания и да поможет нам ктулху.

    А для тех, кто дочитал этот опус до конйа - интересная задачка. Что пингуют эти команды, как и почему?
    ping 1.1
    ping 2130706433

    Тех, кто знает, попрошу не спойлерить=)
    Пусть для кого-то будет сюрпризом этот дивный мир=)

    UPD. Простите за адское количество опечаток в тексте. Писал в спешке и с непривычной клавиатуры. Исправлю всё попозже. Не ожидал, что многим ответ придётся по душе. Вроде ж накапитанил как мог.
    Ответ написан
    5 комментариев
  • Сложный и интересный проект для новичка?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    ## Анонимный чат с темами для обсуждения деликатных офисных проблем
    Иногда хочется обсудить что-то с коллегами в офисе, но не хочется смущать их или показывать лишнюю инициативу.
    Например кто-то не смывает в туалете или слишком громко орёт и сам того не замечает. Может быть кто-то слишком интенсивно пользуется парфюмом.
    - Анонимность
    - Постоянная ссылка на чат, тему или дерево чатов
    - ссылки в виде QR-кодов
    - голосовалка
    - закрепленные посты

    ## Сайт checklist
    Веб-сервис и мобильное приложение для краудсорсинга чеклистов для всего: зарегать ИП, получить визу, что делать при ДТП, как влезть в ипотеку, как вылезть из неё, чем заняться с ребенком на выходных (N-ле

    - Коллекция чек-листов снабженных тегами, доступная для краудсорсинга.
    - Краудфандинг составления и поддержки нового листа.
    - Фильтрация чек-листов.
    - Фильтрация пунктов.
    - Тегирование пунктов.
    - Графовые алгоритм обхода чек-листа.
    - Мастер обхода чек-листа.
    - Отчет по чек-листу.
    - Вложенные чеклисты, гиперссылки между разными листами.
    - Параметризация.
    - Экспертная система, логические связи (расширенный режим).

    Примеры:
    - Что делать при ДТП
    - Открыть ИП
    - Осмотр авто при покупке (подветки для разных конкретных моделей)
    - Первая помощь при...
    - Диагностика инсульта
    - Зомби-акопалипсис: как приготовиться
    - Атомный взрыв неподалёку - что делать
    - Планетарная катастрофа - как выживать
    - Поход выходного дня - что взять
    - Подготовка авто к поездке
    - Путешествие: Алжир (виза, прививки, документы, отели, транспорт)
    - Как влезть в ипотеку
    - Как вылезть из ипотеки
    - Как быстро заработать (во все тяжкие)
    - Покупка квартиры (на что обратить внимание)
    - Самостоятельное строительство дома (общий план)
    - Чем заняться с ребёнком N-лет
    - Как отметить новый год
    - Что интересного в районе <пос. Майский>
    - Номера телефонов и документы в автомобиле

    ## Эротический краудфандинг
    Интернет ресурс, где девушки могут делать крауд-фандинговые кампании

    - Крауд-фандинговая кампания по сбору средств на проект
    - оформление проекта (доказательство личности в виде фото с сигном, некое обещание, порог недовольных результатом, целевая сумма)
    - посетители анонимно финансируют проект в биткоинах
    - если кол-во лайков среди профинансировавших (в соответствии с весами) > порогового, учредитель получает сумму за вычетом комиссии
    - если кол-во лайков не превысило порог, сумма возвращается обратно инвесторам

    ## Простой открытый сервис для обмена сообщениями
    - HTTP API, Web-sockets
    - p2p rtsp
    - опциональное end-to-end шифрование
    - хранение истории на клиентах
    - возможность использования нескольких серверов
    - возможность использования альтруистичных клиентов для проксирования трафика p2p
    - поиск узлов на основе блокчейн технологий и DHT таблиц

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

    ## Поэтический онлайн редактор
    - выбор стопа, стиля и жанра
    - шаблон с плейсхолдерами, разбивающий текст на слоги
    - облако рифм
    - подражающий автогенератор
    - многосегментный словарный банк (дифференциально-слоистая древовидная структура, своя специфика в верхнем слое, поэлементное ранжирование сегментов)
    - тезаурус
    - словарь сочаетаемости
    - N-граммы поэзии по авторам и стилям
    - корпус поэзии
    Ответ написан
    13 комментариев
  • Что это такое и как защититься?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    По двору прошелся жулик и попытался хакнуть эксплойтом для "майбаха" (условно) все тачки в вашем дворе. Майбахов не нашлось, этот жулик пошел дальше и забыл уже про ваш дворик.

    Надо ли защищаться от атаки, не релевантной вашему сетапу? Не надо.
    Надо ли делать выводы об уязвимости того или иного оборудования? Надо.
    Надо ли проверять свои конфигурации на эксплойты? Надо.
    Надо ли реагировать на всякую нерелевантную хрень в логах с ошибками порядка 400? Не надо.
    Надо ли позаботиться об оркестрации быстрого развёртывания ваших серверов на случай взломов или проблем с железом? Конечно надо!

    Вообще, если ваш сетап на виртуальных машинах в повторяемой среде и с декларативной конфигурацией вроде кубера или докера, то вы легче сможете пережить всякие такие факапы.
    Схема такая.
    Есть признаки взлома - бэкап логов, снапшот базы, бэкап стораджа, остановка сервисов (если позволяет продакшн), анализ атаки и последствий. Устраняем уязвимость по вектору атаки (гугление по логам и курение тредов), правим конфиги развёртывания и запускаем прод. Потом долго и тщательно разбираемся по логам, снапшотам и бэкапам что затронуто. Делаем тестовый чистый сетап по старой конфигурации и сравниваем пофайлово с атакованной системой, выясняем в какие места вмешались злодеи. Дифаем базу и смотрим на подозрительные различия. Делаем выводы, объявляем об утекших данных, если есть такие признаки (чтобы не подставлять пользователей), принимаем превентивные меры против похожих векторов атак.

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

    Это взгляд дилетанта по безопасности, если чего пропустил -- поправьте. Если где не прав -- расскажите.
    Ответ написан
    3 комментария
  • Как сопротивление может влиять на напряжение?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    А мне нравится другая метафора.
    Представьте, что у вас в школе есть длинный коридор (это проводник).
    Коридор полон слоняющихся в нём туда-сюда школьников (это электроны). В среднем в коридоре ток равен нулю.
    Вдруг (прозвенел звонок) и в коридор с одного конца стали ломиться новые школьники, движимые желанием идти нахрен подальще от класса (минус "батарейки"). Напор школьников - это потенциал. Он разный в начале и в конце коридора.
    Школьники давят с одного конца, а второй конц коридора открыт на улицу (плюс).

    Разница потенциалов (напоров) между началом и концом коридора - это напряжение.
    Представьте, что перед звонком в коридоре хаотично расставили стулья.
    Стулья мешают - это сопротивление. Школьники спотыкаются, ломают стулья, накаляют обстановочку (часть энергии желания школьников погулять тратится на это).
    Чем больше стульев, тем больше разница давления школьников между началом и концом коридора.

    Это был закон Ома для участка цепи.
    На примере школьников проще объяснять, чем на примере гидравлики. Так можно рассказать и про полупроводники, транзисторы, правило Кирхгофа... да что угодно.
    Ответ написан
    16 комментариев
  • В чем заключаются архитектурные ошибки моего кода?

    trapwalker
    @trapwalker Куратор тега Python
    Программист, энтузиаст
    class Calculation():
    
      def __init__(self, calculation):
        #init
        self.calculation = calculation

    Вы сделали класс `Вычисления`, чтобы проводить вычисления, пока проводятся вычисления вычислений над вычислениями, которые вычисляются как аргумент вычислений для вычисления состояния вычислений.

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

    Используйте тайпхинтинг, это позволяет не только статичесий анализ кода делать и избегать лишних ошибок, но, к тому же, это мощный инструмент документирования кода, неотрывно связанный с самим кодом. Это значит, что документация не отстанет от кода, а, напротив, будет за счет формализма и машиночитаемости помогать IDE помогать нам писать код. К тому же ряд вопросов отпадёт у тех, кто пытается читать код. Не нужно гадать на кофейной гуще что есть что.

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

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

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

    Вот тут у вас, очевидно, можно написать проще и без лишних повторений, провоцирующих ошибки:
    if i % self.inflation_indexation_period==0 and i != 0:
            if i not in range(0, self.inflation_indexation_period):
              init_indexation_inflation *= self.sales_init.inflation_indexation
            else:
              init_indexation_inflation = 1
            inflation_indexations.append(round(init_indexation_inflation, 5))
          else:
            inflation_indexations.append(round(init_indexation_inflation, 5))

    Лучше так:
    if i % self.inflation_indexation_period==0 and i != 0:
            if i in range(self.inflation_indexation_period):
              init_indexation_inflation = 1
            else:
              init_indexation_inflation *= self.sales_init.inflation_indexation
    
          inflation_indexations.append(round(init_indexation_inflation, 5))

    Функция get_inflation_indexations у вас имеет опасный побочный эффект. Она имеет префикс get_ но модифицирует контекст объекта. Это кэширование? Чем обусловлено такое поведение? Если такое делается "на всякий случай". то это плохая практика неявного внедрения побочного эффекта. Если нарочно, то такое надо документировать и корректно называть и описывать метод в докстринге.

    Опять же, get_inflation_indexations и get_value_indexations очень похожи по коду. Это повод вынести такую логику в отельную функцию, она будет проще и её будет проще тестировать!
    А у вас эти функции отличаются именами атрибутов внутри и магическими константами, которые в коде делать не хорошо, тем более без пояснений, тем более в кусках такого похожего кода.

    Перестаньте использовать i в качестве переменной для итерирования нетривиальных сущностей, отличных от протсого счетчика. i - это индекс. Используйте человеко-понятное название переменной для этого!

    Используйте декоратор итераторов enumerate. Это сделает код более прозрачным и читабельным, чем код с параллельными счетчиками. Увидев enumerate читатель кода сразу поймёт, что это простой счетчик итерируемых сущностей, что не нужно ожидать скачков этого счетчика и каких-то сложных корреляций.

    А вот здесь вообще всё плохо:
    count = 0
        revenue_list = []
        for i in total_price:
          revenue = i*total_value[count]
          revenue_list.append(revenue)
          count+=1

    count - это "количество", а вы его используете как "индекс" и никак иначе!
    i - это индекс, а вы туда суёте фактически цену!
    У вас total_price и total_value параллельные одноразмерные списки, их нужно состегнуть с помощью zip и пронумеровать с помощью enumerate (если надо, а здесь не надо!).
    Весь этот кусок понятнее, проще, короче и более питоничнее записать в такой форме:
    revenue_list = [price * value for price, value in zip(total_prices, total_values)]


    Итого вся вот эта громоздкая плохо читабельная функция:
    def get_revenue(self):
        '''Получить итоговую выручку'''
        total_price = []
        for i in self.get_inflation_indexations():
          price = self.sales_init.price*i
          total_price.append(price)
    
        total_value = []
        for i in self.get_value_indexations():
          value = self.sales_init.sales_volume*i
          total_value.append(value)
    
        count = 0
        revenue_list = []
        for i in total_price:
          revenue = i*total_value[count]
          revenue_list.append(revenue)
          count+=1
    
        return revenue_list

    Легко и читабельно для питониста заменяется на вот такую:
    def get_revenue(self):
        '''Получить итоговую выручку'''
        indexations = self.get_inflation_indexations()
    
        init_price = self.sales_init.price
        total_prices = [init_price * x for x in indexations]
    
        init_volume = self.sales_init.volume
        total_values = [init_volume * x for x in indexations]
    
        return [price * value for price, value in zip(total_prices, total_values)]


    И везде не стоит использовать параллельные счетчики, используйте итераторы, распаковку, зипы, енумервторы и функциональный стиль, ведь он сокращает код и делает его проще.

    Что это за ерунда:
    def get_interest_expenses(self):
        '''процентные расходы'''
        interest_expenses_list = []
        return interest_expenses_list


    Зачем много раз считать одно и то же целиком, чтобы взять только очередной кусочек из всего посчитанного?!
    Это вообще бред. Учитесь основам алгоритмизации и не надо программировать на питоне как не на питоне.

    Вот такое вообще жесть: self.get_revenue()[count]
    Отчего не сохранить в промежуточную переменную?!

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

    Удачи.
    Ответ написан
    3 комментария

Лучшие вопросы пользователя

Все вопросы (19)