• Измерение времени участка кода?

    @hsc
    full stack python back-end developer
    Для таких задач придуман профайлер.
    Ответ написан
    Комментировать
  • Как изменить БД для тестов?

    @hsc
    full stack python back-end developer
    Привет. Создайте отдельный settings.py для тестов и запускайте на нем. Еще совет: используйте in-memory sqlite - быстрее в разы.
    Ответ написан
    3 комментария
  • В каком направлении IT открыть бизнес?

    @hsc
    full stack python back-end developer
    Когда я в первые встретился с серьезным инвестором он сказал мне фразу, которую я не забуду никогда: "Если нет качественного бизнес-плана с детальными и реалистичными цифрами, то это - не бизнес, это - романтика." Если у Вас нет видения бизнеса как такового - возможно вам следует дважды подумать над тем, в правильном ли направлении Вы собираетесь двигаться.

    Попросту говоря: вопрос поставлен некорректно. Ответ на него если и есть, то уже реализуется Вашими конкурентами.
    Ответ написан
    Комментировать
  • Как в Django передать данные из модели в шаблон в обход views?

    @hsc
    full stack python back-end developer
    Для начала: https://www.python.org/dev/peps/pep-0020/
    Один из пунктов там "явное лучше неявного".

    Views в django на то и придуманы чтобы передавать данные и делать это явно, но то, как это сделать всецело зависит от Вас. Вы правы, нет смысла во всех вьюхах городить огород с передачей одних и тех же данных, тем более, если они общие для большинства шаблонов, но ни custom context processor, ни тем более custom template tag Вас не выручат так, как может одна простая конструкция:

    где-нибудь в utils.py
    def base_context(request):
        return Context({
            'user': request.user,
            '...': '...',
        })


    Где-нибудь в views.py:
    def view(request):
        context = base_context(request)
        context['this view specific data'] = 'happy coding'
        return render_to_response('template.html', context)


    Таким образом Вы:
    1. Не захламляете общий request flow и сохраняете контроль над контекстом любой вьюхи. Context processors будут вызваны для любого рендера, тогда как такой подход позволит Вам всегда иметь минимум необходимых данных под рукой и полный контроль над всеми вьюхами.

    2. Передаете в контекст шаблонизатора только, что действительно должно в него попасть. Больше того, в отдельных вьюхах Вы даже можете переопределить базовые параметры, что не так удобно делать с context processors. (но лучше см. п.3)

    3. Можете расширить абстракцию как угодно, и создать хоть 2, хоть 3, хоть больше базовых контекстов под всевозожные ситуации (зависит от архитектуры).
    Ответ написан
    Комментировать
  • Какой стек приложений под высоконагруженный сервис выбрать?

    @hsc
    full stack python back-end developer
    Для сбора статистики очень логично использовать append only databases, производительность которых на запись часто играет решающую роль в выборе. Скорее всего вы, как и многие другие, не будете выдавать отчеты на лету, а будете генерировать их по запросу некоторое время, и на опережение генерировать несколько самых основных/популярных и для вас время выборки будет не самым важным критерием.

    Дисковое пространство сегодня стоит относительно не много, и overhead даже в 20% для проекта с такими нагрузками является допустимым. Тут все зависит от формата сообщений, которые вы хотите принимать и от того, как вы решите их хранить.

    В качестве БД можно смотреть на RiakLevelDB в качестве бекенда) или еще один интересный append only key-value storage по типу тарантула: sophia.
    Но на самом деле, решающим фактором тут является не столько сама БД, сколько то, как в нее попадает информация и на каких нодах она должна быть доступна. Как по мне, даже вариант с обычными файлами ОС и fsync() тоже отбрасывать не стоит.

    По поводу веб.сервера: без балансировки, скорее всего, не удасться обработать такое кол-во запросов, хотя это очень сильно зависит от сущности самих запросов. Интересно что Вы тестировали, что nginx показал вам такие цифры на одной ноде, скорее всего отдачу одной (пары) страниц, каждая из которых попала в файловый cache ОС из-за частого обращения и, соответственно, отдавалась с памяти. Вот вам и намек: чтение и запись в память происходят с приблизительно одинаковой скоростью, а nginx позволяет обрабатывать запросы c помощью Lua. А тут уже много вариантов: redis pub/sub, pipes, shared memory и т.д., может вы даже захотите написать модуль для nginx на С.

    Скорее всего вы будете принимать json самых разных вариаций, и тут возможны 2 варианта: или писать сообщения сразу на диск и потом пост-обработка, или парсить данные и потом писать результаты. Тут посоветовать не могу, вам должно быть виднее что на данном этапе логичнее. Но имейте ввиду, что каждая операция на этапе обработки запроса от клиента уменьшает ваш rps.

    Еще важный момент здесь учитывать, что 12krps с одного хоста != 12krps с 12k хостов. Каждый из коннектов nginx будет должен мультриплексировать на что тоже будет расходоваться время.
    Ответ написан
  • С чего стоит начать веб-программисту?

    @hsc
    full stack python back-end developer
    Друзья, чего Вы на парня накинулись то? Да, тостер перестал быть ресурсом geek only, но неужели из-за этого стоит вот так отписывать? @alugin: Инициатива — вот что связано с "работать продуктивно", а Вы ее отбиваете.

    По теме:
    PHP новичку изучать не советую. По сравнению с другими ЯП он сложен и часто неинтуитивен. На рынке труда пользуется популярностью в частности из-за уже существующих проектов, которые никто не хочет переписывать. Для начинающего есть более приятные варианты, например python, ruby, go. Все они активно применяются в веб-разработке, все они очень хорошо структурированы, писать код на них в приятнее и быстрее, чем на php.

    И python и ruby и go применяются на backend'е — тоесть на сервере. Для клиента (frontend) применяется js и html и тут пока без вариантов. Но, стоит сказать, что все три ЯП можно применять и не привязываясь к веб-разработке. В особенности это касается go, но он достаточно сложен по сравнению с двумя предыдущими.

    Если есть желание стать именно программистом (а не верстальщиком или скрипт-кидди) то стоит все-таки ориентироваться на backend. Там и алгоритмы и структуры данных, и базы данных и компания) Удачи в начинаниях) У тебя все получиться!
    Ответ написан
    4 комментария
  • Как можно передать ссылку на экземпляр класса в другие модули, чтобы взаимодействовать с ним?

    @hsc
    full stack python back-end developer
    Не думайте о потоках как об объектах, потому что они ими не являются. Поток — это нить выполнения, которая во время инициализации принимает функцию, которую будет выполнять. После инициализации — это отдельный мини-процесс. Вызвать метод потока невозможно: у него их попросту нет. Можно вызвать метод дескриптора (объекта, который управляет потоком) но не самого потока. Отличием потоков от процессов является то, что потоки разделяют адресное пространство с процессом, который их породил. Это значит, что каждый поток имеет доступ к данным процесса и других потоков.

    Теперь о вариантах решения. Я их вижу несколько:
    1. Перед запуском потока создать proxy-объект, экземпляр класса, который будет описывать подходящую для вас структуру данных. В зависимости от задачи, может быть полезным посмотреть на Queue, он из коробки потоко-безопасен. После этого просто передать ссылку на этот объект в конструктор потока и общаться через него. Поток пишет в этот объект - django читает из него, и наоборот. Модель очереди для таких задач подходит как нельзя лучше, потому как нельзя гарантировать то, что поток подхватит задачу сразу по ее появлению, и другая задача не затрет предыдущую. Создавать proxy-объект нужно в такой точке, из которой выполнение процесса родителя не выйдет до остановки потока, иначе Вы рискуете потерять контроль над потоком или ловить "странные" ошибки.

    2: Если есть необходимость ставить перед потоком разные задачи может быть разумно вынести их хранение во внешние службы, например redis. Он очень быстрый и существенного оверхед даже на малинке не создаст. Общаться с ним можно через этот пакет. Если хотите сэкономить на tcp-трафике - запускайте redis на unix-сокете.
    Этот вариант потенциально избавит Вас от головной боли с синхронизацией задач.

    3: Если есть возможность и памяти хватает больше чем на 1 поток - RQ. Это — легкий менеджер очереди задач для python. По сути, то, что Вы и пытаетесь реализовать.
    Ответ написан
    7 комментариев
  • Хочу быть программистом, но не выходит. Как двигаться вперед?

    @hsc
    full stack python back-end developer
    Эх, расскажу свою историю..
    Мое знакомство с программированием началось, когда мне было 5 лет. Тогда отец откуда-то достал компьютер. Среди прочих ярлычков в папке "игры" был заветный.. Марио! До этого я часто видел эту игру у друзей на приставках, но поиграть в нее вдоволь так и не мог) Можете представить как я хотел поиграть в нее.. но, не тут то было. В 3-м мире я всегда ловил (как я уже знаю) exception и недоуменно смотрел на огромное окно с красным крестиком, текстом на английском и кнопкой "ок". Как-то раз мне повезло, я смог каким-то образом ускользнуть от ошибки, и попасть на следующий уровень. Моей радости не было предела! Я с энтузиазмом приступил, но.. через пару шагов снова увидел ее, уже привычную ошибку. Это стало последней каплей. Тогда я решил, что создам свое Марио и буду играть в него, сколько захочу) Начал с того, что нарисовал в paint уровни игры. Потом из конструктора построил компьютер)) Потом как-то призабыл, но идея во мне жила. В 5-м классе сестра мне купила огромную 600 страничную книгу по Delphi и тогда и моя мечта стала ближе.

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

    К чему я? @microvolnovka, то, что ты в 9м классе значит не больше, чем то, чего ты сам хочешь и во что сам веришь. Из опыта скажу, что ты во многом прав про самообразование, но тебе стоит использовать это, ибо понимание этого — преимущество. Ты уже встал на путь самосовершенствования, иди им. Читай книги, спрашивай, ищи, снова читай, снова спрашивай и снова ищи. Ставь себе цель для того, чтобы знать к чему идешь и чтобы силы не затрачивались зря. Технология — это инструмент. Человек, который в совершенстве владеет инструментом — ремесленник, человек который в совершенстве владеет ремеслами — мастер, но и это не предел.

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

    ------
    Upd: я в университете планирую небольшие курсы. Они будут не он-лайн, и аудитория буде по старше, но пока-что ни того ни другого у меня нет, а желание и чуть-чуть возможности поделиться опытом и знаниями есть. Оставляю почту для тех, кому может пригодиться такая помощь и на растерзание spam-ботам: HaySayCheese@gmail.com
    Ответ написан
    Комментировать
  • Отрасли программирования. Кем можно стать?

    @hsc
    full stack python back-end developer
    Мне кажется, что есть смысл начинать с компилируемых ЯП. Они, как правило, более близки к железу, а это, в свою очередь, сыграет очень важную роль в понимании процесса в целом, ведь любая программа, будь то десктопное приложение, или мобильное, или какой-нибудь бэкэнд, рано или поздно превращаться в инструкции процессора, и чем быстрее этот процесс происходит и чем меньше инструкций — тем быстрее она выполниться. Раз у вас есть знания С++ - то это чудесный выбор для начала. Он покажет насколько важны оптимальные алгоритмы, научит планировать и продумывать архитектуру чтоб добиться производительности, научит экономить ресурсы и грамотно управлять ими, столкнет вас лоб в лоб с нюансами типа "битая куча", аварийное завершение приложения со стороны ОС, всевозможные переполнения и т.д. Не стоит этого бояться, в вашем случае, когда есть время, это может стать очень интересным. Кроме этого будет возможность параллельно почерпнуть знаний о строении ОС (виртуальная память, стек, дескрипторы, процессы и потоки и т.д.).

    В последствии можно будет посмотреть и на веб программирование и на моб. платформы и на серверверное программирование. Конечно, не на С++. Каждой задаче - свои инструменты. Там уже выбор ЯП будет осуществляться не по принципу "что я знаю", а по принципу "на чем быстрее и эффективнее", поскольку зная что-то типа С++ на другой ЯП можно переходить уже намного быстрее. Высокоуровневые языки типа python, ruby и т.д. очень удобны, но поверьте, знание того, что происходит в ОС будет качественно выделять вас на фоне людей, которые не могут похвастаться этими знаниями. С знаниями "низких уровней" у вас появиться больше шансов попасть на высоко-нагруженные проекты и носить гордое звание профессионала.

    Мне кажется, стоит начать с какой-нибудь амбициозной задачи, с большого и интересного проекта для себя. Пусть это будет что-то сложное, ибо чем больше сложностей возникнет — тем лучше для вас. Главное — терпение и упорство. Именно в таких условиях рождаются опыт и новые идеи. Читайте, ищите хорошие практики, стройте гипотезы и обсуждайте с другими на форумах. Также, стоит обратить внимание на английский язык.

    Поступайте только в профильный ВУЗ. Его выбор, как по мне, не очень важен. В нашей специфике самообразование — это все. ВУЗ вам предоставит, в большинстве случаев, только устаревшую лет на 3-7 дорожную карту, экзаменаторов, время и, возможно, вдохновение, если попадется достойный преподаватель.

    Успехов вам!
    Ответ написан
    8 комментариев
  • Что читать, чтобы получить знания по серверному программированию C/C++?

    @hsc
    full stack python back-end developer
    Очень многое зависит от протокола обмена данными, который вы выберете для своего приложения. Если Вам удастся подстроить поток данных под http, то, наверное, есть смысл взглянуть на технологии отличные от C/C++. Например, как вариант, можно смотреть на python. Для него реализована масса http-серверов всех мастей. Данный выбор хорош тем, что, во-первых, позволит быстрее написать прототип системы, даже если Вы не знакомы с python, ведь Вам не придется изучать основы сети, а достаточно будет воспольоваться высокоуровневыми абстракциями, а это значит, что время на изучение сети можно будет потратить на дополнительный ЯП. Во-вторых, Вы сможете куда более легче и быстрее прикрутить сторонние приложения типа redis, memcached, всевозможных БД и пр. В третьих, этот вариант хорош более легким масштабированием. Вам могут также посоветовать python и сказать, что в случае необходимости критичные к скорости участки программы можно будет переписать на С, но мой Вам совет — рассматривайте этот аргумент в последнюю очередь. Но это вариант не без минусов: скорость python куда более медленней чем С/С++. На моей практике был случай, когда python просел на вычислениях в ~50 раз. Тут очень много зависит от задач сервера. Во-вторых, потребляется побольше ресурсов. Готовьтесь к приростам в 5-10раз.

    Сам по себе http уже сможет гарантировать доставку данных и наложит некоторые правильные ограничения на их поток. Кроме того, он позволит несколько проще управлять кешированием, что тоже немаловажно.

    Если же все-таки решите писать свой протокол на основе TCP/IP или UDP взгляните на boost::asio. В мире С++ он зарекомендовал себя как достаточно быстрый и эффективный тулкит для работы с сетью. Документация у него средненькая, часто нужно будет бегать по форумах, но основные вещи описаны нормально. Есть примеры. Также, для более быстрого входа в тему программирования сети с опусканием нюансов очень низких уровней можно взглянуть на документацию по сети в Qt. Там описано много нюансов, даны очень хорошие примеры, можно подсмотреть много хороших практик проектирования сетевых подсистем.

    Напоследок скажу, что если на С/С++ выбор падает из-за возможно большей производительности, то не забывайте, что от сети зависит только часть производительности, но есть еще и управление памятью, ресурсами, задачами сервера (читай тредами) и т.д. Готовы ли Вы к этому?
    Ответ написан
    Комментировать
  • Как сохранять в БД данные о больших объектах (где-то 120-200 полей)?

    @hsc Автор вопроса
    full stack python back-end developer
    Дополню ответы информацией, которую нашел:
    Postgres: many columns or several tables?
    Ответ написан
    Комментировать
  • Как средствами C++ создать экземпляр класса, видимого из методов другого класса?

    @hsc
    full stack python back-end developer
    Строго говоря, использование глобальных переменных в С++ встречается редко. Это допустимо, но по большей мере для обеспечения совместимости с С. В С++ для передачи контекста используют другие приемы, например "передачу по указателю" (ниже). Стоит также сказать, что глобальные переменные сопряжены с кое-какими нюансами, например, могут возникнуть проблемы с последовательностью инициализации.

    Но, судя по Вашему вопросу, Вам не нужны глобальные переменные. Достаточно будет кода на подобие этого:

    /* 
     * gameinstancehandler.h 
     */
    
    class GameInstanceHandler{
    public:
        GameInstanceHandler(CGameHud *instance):
            mInstance(instance){}
    
    private:
        CGameHud *mInstance;
        // something other here
    }


    #inlucde <gameinstancehandler>
    
    int main(int argc, char **args){
        CGameHudInstance *gameHub = new CGameHud(argc, args);
        GameInstanceHandler *handler = new GameInstanceHandler(gameHub);
    
        return 0;
    }


    Здесь контекст передается по указателю. Объекты, поведение которых зависит от других, уже созданных объектов, просто получают указатели на них в конструкторе, сохраняют его "у себя" и взаимодействуют с ними через сохраненную копию указателя.

    P.S. Поскольку вопрос новичковый, позволю себе дать еще один совет: во время объявления указателя пишите звездочку перед идентификатором, а не после типа.
    int *a; // хорошо, a — это указатель.
    int* b; // плохо, но допустимо.
    int* c, d; // совсем плохо, c — указатель на int, d — просто переменная типа int.
    
    int *e, *f; // при такой же записи все понятно сразу.
    Ответ написан
    Комментировать