Инженер
Фокус: Python, SQL, noSQL, Web, REST, serverside
Интересы: GIS, gamedev, AI, etc
Контакты
Местоположение
Россия

Достижения

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

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

Все теги (48)

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

Все ответы (79)
  • Сложный и интересный проект для новичка?

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

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

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

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

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

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

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

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

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

    trapwalker
    @trapwalker
    Программист, энтузиаст
    Давайте различать. Шифрование пароля - это не то же самое, что шифрование других данных. Пароль следует не шифровать, а хешировать. Это такое шифрование, которое нельзя расшифровать обратно. То есть имея хеш нельзя получить пароль, а имея пароль можно получить точно такой же хеш. Существуют для этого специальные хеш функции. Но хешировать пароли мало, их нужно сперва солить. Соль - это произвольный текст, присоединённый к паролю перед хешированием и размещаемый рядом с хешем в открытом виде. Нужна соль для того, чтобы нельзя было подбирать простые пароли по значению их хешей.
    Проверка пароля будет такой:
    1. Запрашиваем у пользователя логин и пароль.
    2. Достаём из БД по логину хеш солёного пароля.
    3. С этой солью хешируем введённый пользователем при авторизации пароль и сличаем хеши. Совпали -- значит пускаем.

    Шифрование других данных, очевидно, нужно уже обратимое, чтобы можно было расшифровать. И теперь есть два варианта: серверное и клиентское шифрование.

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

    Клиентское шифрование - это когда сервер не имеет возможности расшифровать данные. Они шифруются на клиенте перед отправкой ключом, который не покидает пользовательского компьютера. Потом клиент снова запросит шифрованные данные с сервера и расшифрует его тоже сам. Это иногда имеет смысл. Например если вы храните keychain с паролями на сервере, но не хотите их утечки в случае взлома сервера.

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

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

    О, чуть не забыл. Есть опасность утечки незашифрованных данных из датацентров при наличии физического доступа к жестким дискам. Чтобы обезопасить себя в этом смысле, можно применить прозрачное шифрование файловой системы. Работающая операционная система будет знать ключ для расшифровки данных, но отсоединённый диск становится без ключа бесполезным. Однако это малоэффективно, если украдут весь сервер вместе с дисками. Зато эффективно против восстановления жуликами данных, если диск сгорел, а его сисадмин выбросил не просверлив.

    Ещё один аспект - это канал передачи. Нет смысла опасаться перехвата незашифрованных данных в канале передачи даже на последней миле провайдера клиента. Об этом заботится SSL когда правильно настроен HTTPS и сертификаты не скомпрометированы, а пользователь не подмахнул левый сертификат.

    Если вы задаёте вопрос о необходимости шифрования, значит вам ничего сверх вышесказанного шифровать не нужно. Это усложнит систему, сделает её менее надёжной, более (как ни парадоксально) уязвимой и отнимет ресурсы процессора, памяти, не даст использовать или усложнит кэширование и прочие оптимизации.
    Ответ написан
  • На каком ЯП проще всего решить следующую задачу?

    trapwalker
    @trapwalker
    Программист, энтузиаст

    Однозначно Python.
    - Простой лаконичный синтаксис.
    - Читабельность и низкий порог вхождения.
    - Огромное количество готовых библиотек.
    - Кроссплатформенность.
    - Удобный менеджер установки пакетов pip и каталог библиотек PyPI
    Для вашей целей вам понадобится:
    - Встроенная библиотека urllib2 чтобы скачивать нужную страничку.
    - библиотека BeautifulSoup для удобного парсинга страничек и вытягивания из них анных.
    - xlrd для чтения excel-файла.
    - xlwt для записи того, что прочитали с помощью xlrd и новых даных в новый файл или поерх старого.

    Утилиту имеет смысл делать простую консольную. Всего пара десятков строк понятного кода и полная автоматизация.

    Ответ написан
  • Странное поведение pycharm?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    Сейчас я проясню ситуацию=).
    Текст бывает либо в какой-то кодировке (cp1251, utf-8, win866, ascii, и т.д.), тогда это байты; либо в юникоде (это, как бы, абстрактное представление символов), тогда это строки из абстрактных юникодовых символов.
    Все файлы, потоки ввода-вывода и т.д. у нас в компьютере работает с байтами, а не с абстрактными юникодовыми символами. Это значит, что перед выводом в файл или консоль должно производиться кодирование юникода в конкретную кодировку.
    Кодировка -- это способ представить байтами абстрактных символов юникода. Каждый юникодовый символ, в зависимости от кодировки, будет задаваться одним или более байтом. Некоторые абстрактные символы не поддерживаются некоторыми кодировками.

    Так, например, кодировка ascii поддерживает только стандартные 128 символов и при попытке конвертировать в неё (явно или неявно) букву "Ж", будет такая же ошибка как у вас. Надо полагать метод parse в вашем случае возвращает юникод, а оператор print делает неявное преобразование в кодировку по умолчанию (ascii, судя по сообщению об ошибке).
    Осталось выяснить в каких случаях как определяется кодировка по умолчанию.
    Артём Клименко правильно предложил в своём ответе проверить что берётся в качестве кодировки по умолчанию в том и другом случае.
    Однако решением проблемы должно быть явное преобразование текста в нужную кодировку. Я в таких случаях придерживаюсь следующих правил:
    • Всё, что приходит в программу, привожу в юникод (если это не произошло неявно в той библиотеке, посредством которой я получил данные).
    • В программе работаю с текстом только в юникоде (если речь не идёт о каких-то низкоуровневых операциях над байтами, вроде парсинга протоколов и прочего.
    • Перед выводом конвертирую текст в нужную кодировку или настраиваю потоки вывода на автоматическое преобразование.
    • Когда не понятно в какой кодировке делать вывод, руководствуюсь следующими правилами:
      • Выходной поток -- это виндовый stdout и в нём не задана кодировка (bat-файлы, консоль) -- cp866
      • Файлы, БД и прочее, что поддерживает юникод и сделано правильно -- UTF-8
      • Когда в винде не помогают пердыдущие пункты -- cp1251
      • В других операционках utf-8.


    Подчеркиваю. Если выходной поток сконфигурирован на ascii, а у нас в программе могут попасться не-ascii символы, то нужно приводить текст в какую-то кодировку (см выше)), а иначе ничего не трогаем и пишем юникод.
    Ответ написан
  • Как выполнить нормализацию адресов?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    После того, как открыли для себя сервис https://dadata.ru/, вообще перестали тратить время и деньги на собственные костыли из граблей. Сервис просто огонь.
    Для нас онлайн режим и скорость обработки не критична, поэтому мы даже уложились в бесплатный пробный тариф.
    Вроде бы у них были решения по установке их ПО в закрытом контуре, а это не что иное, как нужный вам оффлайн. Правда тут уже бесплатно не прокатит точно.

    До дадаты этот вопрос решался жутким нагромождением фильтров, регекспов с заменами и человеко-машинного совокупления.
    Общая схема годится не только для адресов, а вообще любых грязных данных:
    1. Входной датасет сохраняем в CSV и НИКОГДА не меняем.
    2. Обработка многоступенчатая. Каждая ступень состоит из фильтра и модификатора. Фильтр решает применим ли модификатор к каждой записи. Модификатор применяет свою модификацию если фильтр разрешил.
    3. Отладочный выхлоп, который показывает и позволяет быстро просмотреть полностью внесённые изменения.
    4. Каждая ступень должна делать минимальное однотипное улучшение максимально большого числа строк. Цель - каждой ступенью уменьшать разнообразие проблем, увеличивать регулярность, стандартизировать.
    5. При огромных входных датасетах можно сохранять промежуточный выхлоп, но в общем очистка должна выглядеть как пайп их последовательных ступеней обработки.
    - Очень часто бывает, что какая-то ступень незаметно ломает данные, а понимаешь это уже поздно, когда последующие ступени реализованы и отлажены, и сильно опираются на результат ломающей. Благодаря ступенчатости и иммутабельности процесса всегда можно зипнуть текущее состояние с любым предыдущим шагом и очередным фильтром заменить необходимые куски.
    - Часто бывает, что какая-то из ступеней улучшив отдельные записи убирает характерные признаки для фильтрации элемнтов для другой ступени. Благодаря такому инкрементальному процессу можно переставлять ступени местами.
    - При внесении ступенью изменения в запись. ступень должна оставлять свою сигнатуру в отдельном столбце. Удобно для поиска проблем.

    Расскажите подробнее почему не рассматривается онлайн. Заинтриговали.
    Ответ написан