• FFmpeg - стримминг aac потока, буферизация?

    @nallion Автор вопроса
    Решено при помощь связки ffmpeg+liquidsoup butandiol.blogspot.com/2015/08/liquidsoap-rtmp-to-...
    Был еще вариант с использованием perl и этого модуля https://gist.github.com/AndyA/5587779
    По закону подлости, я обнаружил более простой вариант (второй способ) уже после того, как разобрался с liquidsoup
    Оба варианта проверены и работают. Оставляю заметку тут если кому-то понадобиться стримить пропиетарный AAC+ из под Linux.
    И третий вариант, елки-палки, ffmpeg-у не хватало параметра -content_type audio/aac !!!
    Ответ написан
    Комментировать
  • Django vs Flask?

    erm0l0v
    @erm0l0v
    Senior Python Developer
    На самом деле мене сложно понять приемущества Flask по сравнению с Django для большого приложения. Но почему-то во многих статьях и докладах выливают много негатива в сторону django. Вот одного из немногих докладов где flask не расхваливают до небес: https://www.youtube.com/watch?v=7SmWn05m1Tk

    Мое мнение с перечислением плюсов Django. Скорее всего эти минусы связанны с тем что я не до конца вкурил Flask или пытаюсь сделать из него Django.

    1) В Django нет такой любви к глобальным переменным как в Flask.

    @app.route('/login', methods=['GET', 'POST'])
    def login():
        if request.method == 'POST':
            do_the_login()
        else:
            show_the_login_form()


    Вот пример из документации. Как по мне обращение к request выглядет жутко. И соответственно рождается вопрос а что делать если мне потребуется использовать request за приделами login скажем в методе do_the_login.
    Должен ли я передавать request в параметор метода или так-же продолжать использовать глобальную переменную request. Первый вариант мне кажется правильным, так-как в противном случае зависимости метода получаются неявными. Но если придерживаться первого варианта то непонятно зачем глобальные переменные были добавленны изначально.

    В django такого нет и все параметры передаются явно.

    2) Структура проекта.
    Создается такое впечатление что количество разных способов организовать код на Flask равно количеству приложений написанных на Flask.
    Это очень неприятно так-как:
    • При разработке свой структуры легко сделать неверное решение что может привести к глобальному рефакторингу в дальнейшем.
    • Нового человека в команде придется вводить в курс дела.

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

    3) Хорошая модульная система.
    В Django модули могут нести с собой много вкусностей, скажем статические файлы админку консольные команды и все эти модули не мешают друг другу. Модули Django самодостаточны и как правило не зависят друг от друга, что является большим плюсом.
    Модули Flask включают намного меньше возможностей и часто завязаны друг от друга. Это может вызвать конфликт версий и привести к больщому рефакторингу когда вы захотите добавить новый модуль.

    4) Админка
    Вместе с django вы получите отличную админку, которую не стыдно показать клиенту. Flask Admin Не обладает таким количеством функций как админка Django + Админка django может быть очень круто расширенна огромным количеством плагинов. Например вы можете добавить плагин который быдет отслеживать все изменения в админке с удобным отображением этих изменений и возможностью откатиться на более раннию версию если что-то пошло не так.

    5) Отличная документация
    Это касается не только документации Django но и большинства популярных модулей. Если сам Flask и может заявить что обладает хорошей документацией, но вот модули, которыми вы скорее всего будете пользоваться, увы похвастаться этим не могут. Таким образом очень часто приходится выяснять какие-то моменты работы можуля в исходном коде, issue, Stack Overflow

    Часто Django ругаю за жесткую привязку к ORM или к шаблонизатору. Частично это правда:
    Вы можете отказаться от стандартной ORM но вы должны понимать что это решение лишит вас огромного количества плюшек. Мое личное мнение: в Flask абсолютно тоже самое, если вы не хотите/не можете использовать SQL Alchemy.
    По поводу шаблонизатора в Django вы можете использовать то что вам нравится, вот пример реального проекта в котором используется Mako - https://github.com/edx/edx-platform

    Часто Django ругают за то что там не нужно думать. Я считаю это скорее плюс чем минус. Я не вижу ничего плохого в том чтобы не тратить время на детали реализации а заниматься бизнес логикой (которая и без того сложная). Да иногда это может сыграть с вами злую шутку когда вы захотите сделать что-то нестандартное.

    Прошу прощения за то что в этом ответе многое возможно не к месту, просто статьи и доклады на тему Flask vs Django создают впечатление что Flask это та самая серебренная пуля которую мы все так долго ждали.
    Ответ написан
    2 комментария
  • Плагин KeePass для браузера Chrome

    @malex
    Немного не то но близко и очень рекомендую волшебный проект - https://github.com/antelle/keeweb
    Ответ написан
    2 комментария
  • Не создается загрузочная флешка из под Linux, в чём ошибка?

    @inkvizitor68sl
    Linux-сисадмин с 8 летним стажем.
    sudo add-apt-repository ppa:colingille/freshlight
    sudo apt-get update
    sudo apt-get install winusb
    Ответ написан
    4 комментария
  • Какие есть новые парадигмы программирования, я имею ввиду которые появились совсем недавно 5-6 лет назад максимум?

    @mamkaololosha
    jQuery-парадигма - умею делать всё на jQuery
    Framework-парадигма - "зачем мне ваш computer science, когда я беру фреимворк и делаю всё в 10 раз быстрее наготовом"
    "И так прокатит"-парадигма - мощностей современного железа хватает, что бы разработчик подзабыл об оптимизации
    Я ответил именно ваш вопрос касаемо новых парадигм за последние 5-6 лет, серьезно.
    Ответ написан
    2 комментария
  • Шаблоны проектирования в Python. Что думаете по поводу этой книги?

    nikolay_karelin
    @nikolay_karelin
    Ведущий разработчик, пишу на Python, Tcl, Matlab
    Немного просмотрел эту книгу. Боюсь, что книжка весьма слабенькая: автор явно пишет с позиций Java-программера, и масса примеров у него откровенно не питонические и частенько он не понимает о чем идет речь (например list/dict comprehensions или декораторы у него описаны более чем странно).

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

    По Питону я больше рекомендую книги Марка Саммерфилда, www.qtrac.eu/marksummerfield.html

    Последняя его книга, Python in Practice (ISBN 978-0321905635), как раз и посвящена во многом шаблонам - я ее рекомендовал своим коллегам, кому надо было от C++ или C# перейти на Питон.
    Ответ написан
    3 комментария
  • Как организовать струткуру приложения для избежания циклиеских импортов?

    @bromzh
    Drugs-driven development
    1) выносишь создание монги и других модулей в отдельный файл
    2) импортируешь этот файл внутри create_app и инициализируешь его
    3) в блюпринтах импортируешь по-обычному
    4) создай какой-нибудь run.py, в котором импортитшь create_app, создаёшь и запускаешь приложуху
    5) ...
    6) PROFIT

    # app.py
    def create_app():
        app = Flask(__name__)
        app.config.from_object('config')
    
        from mail import mail
        mail.init_app(app)
      
        from models import db
        db.init_app(app)
        add_blueprints(app=app)
        return app
    
    # models.py
    from flask.ext.mongoengine import MongoEngine
    db = MongoEngine()
    
    # mail.py
    from flask.ext.mail import Mail
    mail = Mail()
    
    # run.py
    from app import create_app
    app = create_app()
    if __name__ == '__main__':
        app.run()
    Ответ написан
    1 комментарий
  • Coffeescript vs. TypeScript vs. ClojureScript

    mrakolice
    @mrakolice
    Главный вопрос — это зачем Вам нужны статические типы в Вашем приложении. Я пишу на TypeScript и мне, например, очень не нравится то, что приходится на каждый чих изменения модели данных добавлять поле в модель или ставить тип any, причем указывать это явно. И даже хуже. Если какой-нибудь метод в качестве параметра принимает массив, в котором могут быть разные типы, то необходимо явно его кастовать к типу any[].
    Я соггласен, что компиляция — это хорошо. Статическая типизация — тоже хорошо. Однако мое сугубое ИМХО, что к скриптовым языкам нужно относиться со скриптовым мышлением.
    Возможно, если в том же WebStorm 7.0 значительно улучшилась поддержка TypeScript, мое негодование будет меньшим, либо сойдет на нет.
    Однако, TypeScript предлагает писать в стиле того же шарпа без такого же инструмента, как решарпер.
    Минус в сторону TypeScript и плюс в CoffeeScript — меньший объем кода, символов и тд.

    Личное мнение, основанное исключительно на ощущениях — CoffeeScript няшечка, TypeScript монструозен.
    Если писать на том же AngularJS, ИМХО TypeScript бессмысленен. Хотя при большом желании можно и это достаточно успешно делать.

    Как советовал человек выше — посмотрите livescript, на мой беглый взгляд он даже больше няша, чем Coffee. Однако сразу оговорю, что ни строчки кода на LiveScript я не писал, впечатление сугубо от внешнего вида и его возможностей.
    Ответ написан
    Комментировать
  • Посоветуете сервис для удобного запоминания английских слов?

    В lingualeo.ru есть и карточки и словари и еще много вкусного…
    Ответ написан
    5 комментариев