Задать вопрос
Пользователь пока ничего не рассказал о себе

Достижения

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

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

Все теги (16)

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

Все ответы (12)
  • Хочу быть программистом, но не выходит. Как двигаться вперед?

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

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

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

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

    ------
    Upd: я в университете планирую небольшие курсы. Они будут не он-лайн, и аудитория буде по старше, но пока-что ни того ни другого у меня нет, а желание и чуть-чуть возможности поделиться опытом и знаниями есть. Оставляю почту для тех, кому может пригодиться такая помощь и на растерзание spam-ботам: HaySayCheese@gmail.com
    Ответ написан
    Комментировать
  • Как в 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, хоть больше базовых контекстов под всевозожные ситуации (зависит от архитектуры).
    Ответ написан
    Комментировать
  • Как средствами 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; // при такой же записи все понятно сразу.
    Ответ написан
    Комментировать
  • Как можно передать ссылку на экземпляр класса в другие модули, чтобы взаимодействовать с ним?

    @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
    Для сбора статистики очень логично использовать 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 будет должен мультриплексировать на что тоже будет расходоваться время.
    Ответ написан

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

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