• Как начать уважать свой труд?

    sim3x
    @sim3x
    Стоит сьехать от родителей в сьемную квартиру и завести требовательную девушку

    И начни общаться с людьми, у которих дневная сумма на мелочи указана в толщине пачки с долларами
    Ответ написан
    1 комментарий
  • Как вы обмениваетесь сообщениями между сайтом и консолькой?

    newross
    @newross
    Product owner
    Такая архитектура чревата множеством проблем, связанных как с жизненным циклом сайта в IIS, так и с правами пользователя, от которого будет запускаться консольное приложение. Рекомендую от отказаться от этого подхода.
    Ответ написан
    2 комментария
  • Как дать Visual Studio леща и заставить изменить своё мнение о проекте?

    @mamkaololosha
    Она ищет его везде, а не там где тебе хочется-кажется. Это тебе нужно леща дать, что уроки прогуливаешь.
    Ответ написан
    1 комментарий
  • Как с помощью рефлексии получить перегруженный метод, где один из параметров ref или out?

    aush
    @aush
    MethodInfo mi1 = typeof(Double).GetMethod("TryParse",
                  BindingFlags.Static | BindingFlags.Public,
                  null,
                  new Type[] { typeof(string), typeof(Double).MakeByRefType() },
                  null);
    Ответ написан
    3 комментария
  • Как написать реал-тайм онлайн игру? Методология, паттерны, статьи?

    @kazmiruk
    Вы задаете более-менее правильные вопросы, но на них нет правильных ответов. Каждый случай очень индивидуальный и кратким ответом тут не обойтись, тут нужны лекции с тоннами теории. Я в свое время писал игры: php (api) + flash (клиент) + C++ (сервер) + mysql (база данных) + memcache (кеш), php (api) + python gevent (сервер) + mongodb (база данных) + redis (кеш) + html5 (клиент), nodejs (сервер) + html5 (клиент) + redis (кеш) + postgresql (база данных). Все они были довольно проивзодительными. Такое разнообразие технологий отчасти обуславливалось моим любопытством (проект на nodejs писал для себя).
    В целом пытаясь ответить на Ваши вопросы:
    1. Не совсем понятно что Вы имеете ввиду. Уточните вопрос.
    2. Лучше всего передавать на сервер все действия клиента и обсчет производить на сервере для невозможности подделывания результатов действий, но это приводит к возрастанию нагрузки на сервер. Протокол - мне нравится bson с готовыми библиотеками, понятным форматом и небольшим размером. Но опять же его я использовал только во втором проекте, в остальных местах я создавал свои велосипеды, которые для конкретных случаев были наиболее эффективны (в моем представлении)
    3. В базе хранить все, что не должно пропадать между играми (условно говоря после выключения сервера ;)), в оперативной памяти дублировать все в идеале (для избавления от операций чтения с диска).
    4. Зависит от потребностей. Postgresql\mysql - более традиционны. Mongodb - модная ) Если Вы понимаете, что в Вашей игре вы можете пережить ограничения mongodb (к примеру отсутствие транзакций) - юзайте его, очень удобен для хранения игровых состояний. Если не уверены - используйте традиционные реляционки.
    5. Кеширование по сути и есть перемещение данных из БД в оперативную память. Причем перемещается таким образом, что скорость выборки из оперативной памяти не зависит от количества данных. Это так называемые хэш-таблицы.

    В общем, без обид, но судя по Вашим вопросам Вам надо очень серьезно подтянуть теорию, прежде чем браться за серьезную игру. Писать серверную часть на С++ - круто, если Вы его знаете на отлично. В целом большого профита Вы не получите, так как скорость С++ проявляется в числодробилках. А игровой сервер - в основном операции чтения\записи, которые будут одинаково выполняться на практически любом современном языке и их скорость больше зависит от построенной архитектуры.
    Мои рекомендации: читать про блокирующие\неблокирующие сокеты, многопточность, структуры данных, паттерны проектирования, оптимизация запросов (включая нормализацию и денормализацию данных), кеширование. Параллельно с этим можно делать простенький чатик постепенно улучшая и оптимизируя его. Таким образом Вы приобретете и теорию, и практику. После этого можно сделать какую-нибудь простенькую игру.
    Ответ написан
    4 комментария
  • NHibernate или Entity Framework?

    @Raimon
    Раньше (года 2 назад) я бы однозначно рекомендовал NHibernate, но сейчас EF очень подтянулся по функционалу (наконец-то научился мепить enum:). Несомненным плюсом также считаю, что в EF порог вхождения гораздо ниже и присутствует интегрированная (и очень удобная) возможность делать миграции.
    Ответ написан
    Комментировать
  • Стоит ли учить Swift Obj-c developer'y?

    @Philippov
    Мне кажется, obj-c разработчик не станет задавать таких вопросов.
    Ответ написан
    Комментировать
  • C#: построение тяжелых графиков в реальном времени

    @stringer
    Хороший обзор средств построения графиков был тут. Согласен с Sumor относительно того, что не надо перерисовывать на каждый чих.
    Ответ написан
    3 комментария
  • C#: построение тяжелых графиков в реальном времени

    @Sumor
    ComponentOne
    DevExpress

    NB: Если точки поступают с частотой 50 Гц, то это не означает, что нужно обновлять графики с той же частотой. Достаточно накапливать данные и дорисовывать графики с частотой 1-5 Гц.
    Ответ написан
    1 комментарий
  • Как правильно использовать паттерны проектирования?

    Привет, автор. Вот мои мысли по этому поводу:
    1. Понимание паттернов программирования приходит только с опытом. Чтение одной лишь книги, без практики, практически ничего вам не даст. Материал быстро забудется. Лично я прочитал примерно половину книги, после чего пришлось её на время отложить. Как я и говорил - без тренировки на примерах материал быстро забылся. Вновь вспоминаться он стал при чтении книги "Принципы, паттерны и методики гибкой разработки на языке c#". В книге достаточно много подробных примеров, и именно после их выполнения я стал осознавать суть некоторых паттернов.
    Разумеется нельзя считать, что паттерн - это какое-либо строгое правило. Часть паттернов мы реализуем сами ещё до прочтения каких-либо книг. Паттерн - это возможное и удобное решение, которое можно применить для решения какой-либо задачи. Не надо пытаться заучить паттерны или вставлять их везде, где можно. Нужно просто писать как можно больше кода, тогда уже автоматически начинаешь видеть ситуации, где можно применить паттерн.
    2. По-поводу слабой связанности. Во всех книгах, разумеется, пишут, что слабая связанность - это хорошо. Но на самом деле такая архитектура не всегда оправдана, и специалисты в области разработки ПО об этом периодически напоминают. На практике это означает то, что не нужно везде применять интерфейсы только потому, что можно это делать. Если вы уверены, что ваши классы вряд ли будут когда-либо заменены другими, то лично я считаю, что они могут быть смело использованы друг-другом без принципа инверсии зависимостей. Ну и вопрос к модульному тестированию. Разумеется сильная связанность мешает модульному тестированию, но если вы не планируете его проводить, то быть может и не стоит строить избыточные абстракции.
    Лично я также считаю, что вышесказанной в меньшей степени справедливо для прикладных и вэб-приложений (где действительно важна модульность и тестировании), и в большей степени справедливо для игровых приложений. Лично я вообще с трудом представляю игру, в которой каждый игровой объект (танк, самолёт например) будет реализовывать интерфейс, чтобы теоретически когда-нибудь мы заменили танк на био-робота. Но это так, лирика.
    3. По-поводу повторного использования. Один мой товарищ - senior developer, работавший в серьёзных организациях, говорит, что повторное использование кода - это миф. Лично я повторно использовал разве что какие-нибудь вспомогательные функции. Ну или в лучшем случае несколько классов и интерфейсов для поддержки модульности. На мой взгляд, говорить о том, что можно взять и перенести из проекта в проект всю архитектуру особо не приходится.
    4. По-поводу контроллеров. Насколько я понимаю (опыт в разработке небольшой) основной смысл делать контроллеры зависимыми от интерфейсов только в том, чтобы тестировать эти контроллеры (хотя я не совсем понимаю зачем). Контроллер - это действительно такая вещь, которая с большой вероятностью будет использоваться только на конкретном сайте. Также этот контроллер будет завязан на какой-то интерфейс, предоставляющий бизнес-логику. Опять же вероятность, что один класс бизнес-логики будет заменён другим классом с такими же методами - стремится к нулю, особенно если учитывать то, что класс бизнес-логики зависит от интерфейса, который предоставляет методы получения данных. (если вы хотите изменить способ получения данных - вы изменяете, К примеру, класс репозитория, бизнес логика остаётся той же). В связи с этим я вижу пока только одну причину завязывать контроллеры на интерфейсы, а не конкретные классы бизнес-логики - это тестирование. Вы стабите интерфейс бизнес-логики и тестируете контроллер независимо от всех остальных модулей. Если не прав, поправьте, конечно.
    Ответ написан
    5 комментариев
  • Как разработать сайт для неинициативного заказчика?

    mindnomind
    @mindnomind
    К сожалению, на фрилансе 80% заказчиков страдают этой болезнью. Обычно внимательно выслушиваю абстрактный поток желаний клиента, кое-как пытаюсь систематизировать эту информацию. Предлагаю заполнить бриф - 90%, естественно, ничего не заполняют. В итоге набрасываю мини-тз с максимально точными формулировками заданий. Показываю - согласен, угу, работаем. Если что не так ссылаюсь на его письменное согласие с тз. Если тз не устраивает - будь добр сам допиши. Не хочешь - надо говорить "нет", ибо время и нервы дороже денег.

    Контент недостающий беру из аналогичных сайтов или вообще вставляю абракадабру. Естественно информирую о том, что контент неуникальный и после сдачи проекта нужно наполнить своим. Само собой перед этим надо научить клиента пользоваться админкой.
    Ответ написан
    Комментировать
  • GameDev - что нужно знать и какую технологию выбрать?

    Если вы любите игры - это не означает что вам понравится их делать, скорее наоборот, начав работать в геймдеве вы их перестанете любить.

    Но, это так, к слову. Вам для начала нужно определиться с тем в какой области вы хотите работать: мобильные игры, десктопные или социальные. Как определитесь ищите вакансии по направлению и смотрите требования к кандидатам.

    А начать, как мне кажется, можно с Unity3D (движок хороший и востребован сейчас ), тем более, что С# для вас родной. Ну и познакомьтесь с шейдрами, лишним точно не будет.

    А вообще подумайте 10 (а лучше 20) раз нужно ли оно вам. Область сложная и трудоустроитья не так уж просто.
    Ответ написан
    2 комментария
  • Entity Framework - как обновить только одну сущность?

    chydaya
    @chydaya
    Необходимо как-то обновить только 1 сущность (то есть 1 таблицу заполнить данными из базы). Например, изменили что-то в базе вне программы и только в одной таблице, как мне обновить только 1 таблицу

    не знаю как работает Entity, но по опыту работы в более адекватных ORM, если что-то изменили в базе, то при обращении к сущности, которая описывает таблицу, данные будут актуальные и без пересоздания ..
    Ответ написан
    1 комментарий
  • Как улучшить практические знания по C#?

    @AlexP11223
    Чтобы "улучшить практические знания" нужно — (!) внезапно — практиковаться.
    Свои проекты придумать, или open source что-нибудь интересное вам найти и участвовать и т.д.
    Ответ написан
    Комментировать
  • Как быстро стартовать в asp net mvc?

    @quizzer
    В дополнение к вышесказанному могу добавить следующие источники: онлайн-книги Изучаем ASP.NET MVC 4 и Руководство по ASP.NET MVC 5

    Из бумажных - ASP.NET MVC 4 с примерами на C# 5.0 Фримена и ASP.NET MVC 4. Разработка реальны... (обе книги издательство Вильямс)
    Ответ написан
    Комментировать
  • Где найти примеры готовых ios приложений?

    Headmast
    @Headmast
    Вот подборки из реальных выложенных в магазин приложений.
    Очень хорошая подборка приложений выложенных в маркет:
    maniacdev.com/2010/06/35-open-source-iphone-app-st...
    Вот подборка из приложений с исходным кодом, правда немного устаревшая:
    ntt.cc/2010/09/05/50-open-source-iphone-apps-for-i...
    Тоже подборка устаревшая, но свежие исходиники найти можно:
    www.edumobile.org/iphone/iphone-programming-tutori...
    Ответ написан
    Комментировать
  • ASP.NET MVC4. Как выполнять задачу в фоне?

    @Kokcuk
    Лучше делать это с помощью отдельного windows service, а к нему уже обращаться из веб приложения.
    Можно конечно реализовать фоновую задачу внутри mvc приложения, но это не очень хорошо, iis например любит завершать задачи и перезапускать их по своему усмотрению.
    Ответ написан
    2 комментария
  • Как проектируются такие приложения как игры? А именно, откуда берутся расчеты баланса и т.п.?

    @zlumer
    По моему опыту используются 5 основных видов балансировки цифр (сюда входит опыт, требуемый для левелапа, количество монстров на миссии, всякие характеристики персонажа в РПГ и т.п. - что угодно, что можно выразить в числовом виде):

    1. Клонирование.
    Берётся популярная игра похожего жанра (или совершенно другого), и цифры воруются с неё. За неимением профессионального дизайнера-балансировщика в команде этот метод часто даёт приемлемые результаты (см. многие социальные игры на российском рынке, склонированные с западных аналогов).
    Плюсы:
    * Не нужно толком ничего считать.
    * Отлично подходит для первой итерации баланса (в комбинации с другими методами на последующих итерациях).
    Минусы:
    * Все недостатки копируются вместе с достоинствами. Возможно, в исходной игре есть фундаментальные проблемы, которые не заметны на поверхности.
    * При изменении баланса трудно предсказать, в каком месте игра может сломаться. Самое маленькое изменение, типа добавления коэффициента на дамаг героя, может поломать весь баланс.
    * Непонятно, какие проблемы решали дизайнеры исходной игры. "Почему коэффициент повреждений умножается на 1.1?" "Почему формула кубическая а не квадратичная?" и т.п.

    2. Интуиция.
    Берутся значения наугад, на основе опыта гейм-дизайнера. Если это уже пятая по счёту ММО, в которой принимал участие геймдиз, то он может в блокноте накидать несколько формул с учётом многих будущих проблем.
    Плюсы:
    * Результат есть очень быстро, после нескольких расчётов.
    * Отлично подходит для первой итерации баланса, после которой можно переходить к п.3 - экспериментам.
    Минусы:
    * Нужен очень компетентный гейм-дизайнер, прежде разработавший не один похожий проект.
    * Даже очень опытные люди могут грубо ошибиться.

    3. Эксперименты.
    В игру забиваются первые попавшиеся значения (либо на основе п.1 - берутся из любой игры, либо на основе п.2 - интуитивно подбираются), затем гейм-дизайнер садится за игру (либо сам, либо просит товарищей по команде/друзей/фокус-тестировщиков), начинает играть и изучает, где в балансе дыры - какие уровни проходятся слишком долго, какие заклинания слишком слабые и т.п.
    Эксперименты нужно использовать в каждом проекте, чтобы отловить поверхностные проблемы. Некоторые разработчики модов к играм балансируют так весь игровой экспириенс: поиграл, покрутил цифры, поиграл ещё.
    Плюсы:
    * Все поверхностные проблемы сразу видны.
    * Не нужно никакой теоретической подготовки и расчётов, достаточно просто запустить игру и посмотреть.
    * Проверять работу всё равно нужно будет, можно сделать это на этапе начального баланса.
    Минусы:
    * Проверки занимают очень много времени.
    * Игроки зачастую проводят в игре больше времени, чем может себе позволить геймдиз (касается ММО и прочих больших игр), поэтому некоторые области не удастся проверить.
    * Персональные ощущения - это хорошо, но всегда стоит помнить, что стиль игры у разных людей отличается, и игрок может пойти по другому пути, чем дизайнер.

    4. Расчёты.
    Самый теоретический метод: задаётся некая величина, в которой оценивается балансировка (время, некий коэффициент сложности и проч.), а потом все цифры к ней подводятся.
    Пример 1: мы хотим, чтобы игрок получал левел-ап каждые 3 минуты. На каждом уровне просчитывается средняя скорость набора экспы, например 10 единиц в секунду на 5 уровне и 11 единиц в секунду на 6 уровне. 10*60*3 = 1800 опыта нужно с 5 по 6; 11*60*3 = 1980 опыта нужно с 6 по 7.
    Пример 2: мы делаем казуальную match-3 игру и чередуем сложные уровни с лёгкими. Сложным считается уровень с вероятностью победить около 50%, лёгким - с вероятностью победить около 95%. Мы рассчитываем вероятность победы в каждом из уровней (на основе исходных позиций шариков, например), и размещаем их в желаемом порядке.
    Плюсы:
    * Можно заранее запланировать экспириенс игрока, даже на очень высоких уровнях.
    * Легко вносить значительные изменения в баланс - просчитанные таблицы сразу покажут, где возникают проблемы.
    * Таблица может просто лежать на столе и напоминать, какие математические ограничения следует учитывать.
    Минусы:
    * Нужен человек, разбирающийся в математике. Хотя бы уметь рисовать параболы.
    * Много работы в Excel, тысячи цифр (на одном проекте у меня был документ с где-то 30 таблицами, в которых было по 10-25 столбцов и сотни строк - помнить их все и поддерживать в актуальном состоянии было очень затратно по времени).
    * Игра может быть просчитана очень хорошо, но играть в неё при этом будет не интересно - удовольствие от игры гораздо легче нащупать п. 3 - экспериментами.

    5. Статистика.
    Измеряются статистические показатели игроков: какой уровень они получают в первые 10 минут игры, какие миссии проходят, сколько шагов туториала смотрят, прежде чем отменить его. На основе этих данных делаются выводы.
    Например, если квест №7 выполняет 97% игроков, квест №8 - 45% игроков, а квест №9 - 95% игроков (считается процент от тех, кто дошёл до этого квеста), то сразу видно, что квест №8 чем-то сильно игроков смущает, надо проверить текст миссии, условия выполнения и прочее.
    Плюсы:
    * Реальные данные от тысяч игроков, сразу видны проблемы.
    Минусы:
    * Надо знать, что считать. Выбор метрик определяет эффективность этого метода.
    * Для этого способа подходят не все игровые платформы: нужно соединение с интернетом и желательна возможность быстрого обновления игры (например, в соц.сетях можно иметь очень кривой баланс, но в первые дни после релиза собирать статистику и крутить его до приемлемого).
    Ответ написан
    Комментировать
  • Какую выбрать БД для данных реального времени?

    afiskon
    @afiskon
    Riak посмотрите eax.me/riak
    Ответ написан
    Комментировать