Задать вопрос
  • Игровая деятельность или нет? Вопросы по организации?

    @lesha_penguin
    Насчет движения денежных средств:

    * С поступление средств от клиентов проблем никаких нет. Клиенты просто оплачивают вам услуги доступа к вашей системе.

    * Если сумма выигрыша клиента не превосходит затраченных им средств — тоже проблем никаких! А «в среднем» именно так и будет, например, хомячок в течении месяца проиграл сначала 1500р, затем решил отыграться и продул еще 2000р, потом еще 3000р, а потом радостный, выиграл 4000р и счастлив до небес!!! Мы ему (NB: совершенно законно) просто делаем «возврат неиспользованных средств», потому что по сути так оно и есть (хомячок внес в течении месяца предоплату на общую сумму 6500р, из которых 2500р были честно истрачены на услуги, а 4000р это возврат неиспользованных средств, он просто забирает непотраченную часть предоплаты). Тут никаких проблем и вопросов нет!

    * «Скользкая ситуация» возникает только когда (а это 1-2% случаев, профи или везунчики), когда игрок выигрывает больше чем тратит. То есть, это неприятный вариант, когда Вы с какого-то перепугу платите пользователю! Вот тут вам может пригодиться помощь юриста! В принципе, чем меньше у вас будет ситуаций когда вам придется платить деньгами физлицам-тем меньше будет к вам вопросов. Так что сразу продумайте варианты (которые могут заинтересовать пользователей). Это могут быть и материальные призы (всякие телефоны, айподы, ноутбуки), и нематериальные всякие купоны, услуги фирм-партнеров и пр.

    А с технической точки зрения, сами понимаете, сервера и все такое лучше держать при этом не в этой стране.
    Ответ написан
  • Предлагаю казнить за ошибки тся/ться?

    @lesha_penguin
    Да, только не забываем, что если всех подряд за каждую орфографическую/пунктуационную/стилистическую неточность загонять в как вы говорите, «в рид-онлы», то писать статьи на Хабре будет просто некому.
    Это уже сейчас превратилось в тотальную проблему — куча толковых пользователей сидят в минусе из-за того что они пару-тройку раз выразили свое «не согласие по холиварным вопросам». Вы хотите еще за «тся/ться»?
    Ответ написан
  • Маршрутизация доменов третьего уровня во внутренние IP адреса

    @lesha_penguin
    Дополнение: Кстати, вышеуказанный метод с nginx-ом вовсе не конфликтует с указанным выше DNATом через iptables. Легко настроить dnat чтобы он пробрасывал 80 порт внутрь локальной сети на вход nginx-у.
    Ответ написан
    Комментировать
  • Маршрутизация доменов третьего уровня во внутренние IP адреса

    @lesha_penguin
    Если для Веб-приложений, то один из лучших вариантов — можно использовать nginx на шлюзе со следующей конфигурацией:
    server{
    listen 80;
    server_name app1.domain.com;
    location / {
    proxy_pass 10.0.0.1:80;
    proxy_set_header Host $http_host;
    }
    }
    server{
    listen 80;
    server_name app2.domain.com;
    location / {
    proxy_pass 10.0.0.2:80;
    proxy_set_header Host $http_host;
    }
    }
    server{
    listen 80;
    server_name app3.domain.com;
    location / {
    proxy_pass 10.0.0.3:80;
    proxy_set_header Host $http_host;
    }
    }


    Плюсы:
    + Если Вы ВДРУГ захотите перенести приложение например app1 например на хостинг, то проблем не будет, это можно будет сделать прозрачно.
    + Вы полностью отвязанны от физического размещения
    + Если вдруг одно из приложений будет слишком нагруженным, вы сможете его запускать на нескольких машинах и использовать балансировку, Кеширование, да и прочие вкусности nginxа.

    Минусы:
    — Все вышесказанное только для http
    Ответ написан
    Комментировать
  • Безопасные для глаз мониторы?

    @lesha_penguin
    Насчет утомляемости: матрица монитора это не единственный и не главный виновник утосталости. Огромный вклад в общее утомление вносит положение шеи, а с этим ноутбуки делают огромную засаду — шея вслед за взглядом наклоняется вниз и в этом положении проводит часами. Ну а как результат — это вам скажет любой мануальщик, кровеносные сосуды шеи передавливаются, кровеснабжение нарушается и возникают головные боли и увеличивается эффект утомления глаз. Что с этим делать? Я применяю следующие методы борьбы:
    * Всегда стараюсь подымать вверх монитор либо ноутбук ставя на какую нибудь подствку. После 8-9 часов работы, разница между монитором на уровне глаз и монитором на уровне стола хорошо ощущается.
    * Когда чувствую, как глаза начинают уставать, встаю, завариваю себе чай и смотрю в окно (об отдыхе для глаз, впрочем уже писали)
    * Если чувствую дискомфорт (а простой критерий дискомфорта — это когда, переходишь из состояния «просто вижу изображение на экране» к «пытаюсь разглядеть изображение на экране»), я просто тяну пальцы к ручкам яркости и контрастности. Глаза могут напрягаться как из-за недостаточно яркого либо недостаточно контрастного изображения так и слишком яркое или контрастное может бить в глаза.
    * Вкладывать деньги в ноутбук зачастую «деньги на ветер» (просто это мое мнение). Этим 30 тыс разницы можно найти более достойное применение, а именно огранизовав себе рабочее место, в которое входит нормальный монитор. Кстати, не я один. У нас на работе многие, ходят с ноутбуками (многие из них обходятся без стационарного). Прийдя на рабочее место просто подсоединяют ноутбук к нормальному монитору, стоящему на удобной подставке. Подумывать о ноутбуке с «суперэкраном», да, имеет смысл. Но только тогда когда приходиться подолгу работать в разных местах. А для большинства людей ноутбук — это всего лишь переносной компьютер, который перемещается из пункта А (работа) в пункт Б (дом). Так почему бы эти два места не обустроить чтобы вред здоровью был минимальным а удобство максимальным?

    А вообще здоровье лучше беречь, его за деньги не купишь, жаль понимать я это стал поздно.
    Ответ написан
    1 комментарий
  • Создание Garbage Collector-а

    @lesha_penguin
    Отвечая на вопрос, хочу поделиться одним хорошо себя зарекомендовавшим решением. Извиняюсь что для комментария «много букв», ибо только что хотел написать это как топик, но увы, у меня кармы пока нема…

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

    Вроде бы «задача для школьников» написал структуры данных со всеми полями для вершин и ребер графа, а дальше вроде все просто, «все как по учебнику» — выделяй для них память из кучи с помощью malloc/new и проставляй указатели.

    Проблема возникает когда мы, поработали с данным графом и он нам больше не нужен. Кажущаяся простая задача «взять и освободить память для всех объектов», т.е. для каждого объекта вызвать соответствующий free/delete причем один один и только один раз, на деле оказывается не просто сложной а в общем случае NP-сложной. Т.е. вся предыдущая работа работа с этим хитрым графом может показаться «цветочками» по сравнению с попыткой найти в каком же порядке обойти элементы чтобы никого не забыть (ибо иначе утечка памяти) и вызвать освобождение каждого элемента только один раз (ибо при двойном освобождении мы нарушим логику других потоков нашей программы).

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

    Однако давайте посмотрим в корень проблемы. Проблему сложности поэлементного освобождения как таковую порождает само поэлементное выделение обьектов из динамической памяти (кучи). Кстати, это в добавок ко всем остальным проблемам динамической памяти таким как фрагментация, замедление операций выделения/освобождения когда динамическая память представляет собой кашу из сотен тысяч фрагментов разного размера вперемешку с свободными элементами тоже разного размера (а именно такую адскую кашу представляет собой динамическая память у любителей STL).

    Решение может быть простым и изящным — аллокатор памяти без поэлементного освобождения. Звучит сложно, но реализация проста.

    Основой нашего аллокатора памяти служит чанк. Размер чанка может быть любым, главное чтобы он был больше максимального размера объекта. Идеальный вариант- зная (приблизительно) сколько нам нужно мы выбираем размер чанка. Если структура нашего графа заняла больше — ничего страшного, выделим еще один чанк.

    Сам чанк имеет следующую структуру:

    struct _alloc_pool_mem_chunk{ // чанк пула-аллокатора без поэлементного освобождения
      size_t size;  // размер данных чанка
      size_t curr;  // текущее заполнение чанка
      struct _alloc_pool_mem_chunk*next; // указатель на следующий чанк нашего пула
      uint8_t data[0]; // данные чанка
      };
    


    Выделение памяти из такого чанка элементарно:
    static void *memchunk_alloc_from_chunk(struct _alloc_pool_mem_chunk*ch,size_t s){
      if(!ch||!s){return 0;} // простая проверка
      if( (ch->size-ch->curr) < s){return 0;} // у нас в чанке свободно (ch->size-ch->curr) байт
      void *rv=&ch->data[ch->curr];
      ch->curr+=s; // сдвигаем на s байт
       return rv;
      }
    


    Если в чанке нет места для объекта, мы просто добавляем еще онин чанк:

    static struct _alloc_pool_mem_chunk *memchunk_add_chunk(struct _alloc_pool_mem_chunk **chp,size_t chunk_size){
      struct _alloc_pool_mem_chunk*ch=malloc(sizeof(struct  _alloc_pool_mem_chunk)+chunk_size);  // выделяем чанк 
      if(!ch){return 0;}
      ch->curr=0;
      ch->size=chunk_size;
      ch->next=*chp; // сцепляем чанки в связный список
      *chp=ср;
      return ch;
      }
    


    Вся процедура выделения памяти из такого аллокатора в простейшем виде:

    void *memchunk_alloc(struct _alloc_pool_mem_chunk **chp,size_t s,size_t chunk_size){
     void *rv; 
     static struct _alloc_pool_mem_chunk *ch=*chp;
     if((rv=memchunk_alloc_from_chunk(ch,s))){return rv;} // выделяем из текущего чанка
     if(!(ch=memchunk_add_chunk(chp,chunk_size))){return 0;} // не удалось добавить чанк-облом
     rv=memchunk_alloc_from_chunk(ch,s);  // выделаем из нового чанка
     return rv;
      }
    


    Функция освобождения всего пула-просто обходим все чанки:

    void memchunk_free_all(struct _alloc_pool_mem_chunk **chp){
      struct _alloc_pool_mem_chunk *ch=*chp;
      while(ch){
         struct _alloc_pool_mem_chunk *chn=ch->next;
         free(ch);
         ch=chn;
         }
      }
    


    Достоинства:
    • Чрезвычайная простота реализации. Даже школьник способен с первого раза за несколько минут написать безошибочно такой аллокатор. Кстати код выше я не копипастил а просто набрал по памяти (из ошибок могут быть очепятки).
    • Низкий overhead. всего 12/24 байта (x86/x86_64) на чанк.
    • Не фрагментирует память. Существенное достоинство, особенно когда элементов сотни тысяч.
    • Выделение элемента работает быстрее, в разы быстрее чем malloc/new. (Выделение памяти для элемента из чанка 3 строки). Освобождение элемента — вообще nop!
    • Если нам вдруг захочется threadsafe — мы легко получим всего лишь заменив запись ch->curr+=s на cmpxchg и добавив какой-нибудь легковесный примитив типа spinlockа на добавление чанка.
    • У нас свой быстрый и легковесный garbage collector с коммандой «освободи все». Пройти по (NB: небольшому) списку чанков — это не считать ссылки в миллионах объектов.
    • Да, контроль занятой памяти нашей хитрой структурой. Мы всегда можем быстро сказать, что например этот граф занимает 3.5Mb, просто пробежавшись по чанкам.
    • Проверенно лично мною на десятке highload-проектов.


    Недостатки:
    • А они бывают только в тех случаях, если этот аллокатор использовать для непредусмотренных целей:)


    P.S.: Желаю всем хабраюзерам приятных экспериментов.
    Ответ написан
    3 комментария
  • Нужна ли статья по допиливанию Transmission?

    @lesha_penguin
    Однозначно, нужна. У самого у меня руки давно чешутся поковырятся в потрохах transmissionа на тему дофичивания, но как всегда «руки не доходят». Поэтому, буду ждать…
    Ответ написан
    Комментировать