Дисклеймер от автора (автор — девушка): Я не разрабатываю движки баз данных. Я создаю веб-приложения. Я участвую в 4-6 разных проектах каждый год, то есть создаю много веб-приложений. Я вижу много приложений с различными требованиями и различными потребностями хранения данных. Я разворачивала большинство хранилищ, о которых вы слышали, и несколько, о которых даже не подозреваете.

Несколько раз я делала неправильный выбор СУБД. Эта история об одном таком выборе — почему мы сделали такой выбор, как бы узнали что выбор был неверен и как мы с этим боролись.Это все произошло на проекте с открытым исходным кодом, называемым Diaspora.

Если вы еще не в курсе: JavaScript победил. На сегодняшний день это самый кроссплатформенный язык, доступный для любых устройств. На нем можно создавать веб-приложения (клиент и сервер), в том числе с оффлайн-режимом работы, десктопные приложения (для Windows 8), приложения для смартфонов и планшетов (PhoneGap), расширения для Microsoft Office, SharePoint и Dynamics. Код на JavaScript работает в СУБД, таких как MongoDB и даже Hadoop в Windows Azure (BigData однако).

На Javascript уже написаны Doom и эмулятор Linux. Фактически решая любую задачу, кроме написания модуля ядра ОС, вы встретитесь с JavaScript. Если вы еще не знаете JavaScript, то вам следует срочно начать его изучать.

Если вы любитель игры «Caesar III», то наверняка замечали то, с каким старанием и вниманием к мелочам сделаны карты кампании, да и свободного режима тоже. Природные пейзажи, на которых игрок возводит «новый Рим», выглядят вполне реалистично (в рамках игры): ручейки впадают в реки и озера, реки текут через всю карту, а в лесах бродят «бессмертные» овцы, иногда забредая на луга и мешая строить фермы, чайки кружат над местами скопления рыбы, а иногда по реке проплывает неудачливый моряк на останках корабля. Скальные массивы окружены деревьями, а земля покрыта ковром сочной зеленой травы. У всей этой чудной картинки есть недостаток, размер карты не превышает 160х160 тайлов, в статье я расскажу как сделал генерацию карт больших размеров.

И вот не прошло и полтора года как я добрался собрать третичную структуру тРНК. Напомню, что ранее писал статью на эту тему на хабре «Развитие RNAInSpace, алгоритм CRA, проблемы кода на Linux и прочие». Надо сказать, что около года я этим не занимался, но за это время вышла вторая моя научная статья на эту тему «Применение теории игр для задачи сворачивания рибонуклеиновых кислот» (это для тех, кто захочет поговорить об этом профессионально). Но вот недавно я можно сказать получил третичную структуру тРНК и сверил её с образцом, имеющимся в базе данных (PDB), который получен биологическими методами (кристалография).

Под катом рисунки 3D-структуры тРНК, пояснения и планы на будущее.

По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
Дядюшка Боб

В последнее время меня стали очень утомлять оживлённые дебаты о том, нужно ли комментировать код. Как правило, по одну сторону баррикад — самоуверенные джуниоры, имеющие непререкаемую позицию вида «А как же его не комментировать, ведь без комментариев непонятно будет!». По другую — умудрённые опытом сеньоры. Они понимают, что если возможно обойтись без комментариев, то «Лучше бы, чёрт возьми, так и сделать!». Наверное, у многих жажда комментировать идёт со студенческой скамьи, когда товарищи преподаватели заставляли комментировать каждую строчку, «чтобы студент лучше разобрался». В реальном проекте не должно быть кучи комментариев, которые только и делают, что засоряют код. Впрочем, я не агитирую вообще не писать комментарии, но если вам удалось написать такой код, который не требует пояснений, то расценивайте это, как свою маленькую победу. Сразу хотелось бы сослаться на нескольких очень умных книжек, на основе которых формировалась моя позиция. Я люблю и уважаю авторов этих работ, полностью разделяя их мнение.

• С. Макконнелл, «Совершенный код. Мастер-класс»
• Р. Мартин, «Чистый код. Создание, анализ и рефакторинг»
• Д. Босуэлл, Т. Фаучер, «Читаемый код, или Программирование как искусство»

Этой публикацией мы начинаем серию статей, посвященных решению задач в разных областях при помощи геймификации. Цель статьи – дать теоретическую информацию и общий алгоритм решения. Первая задача: как сделать работающий интернет проект с контентом, который должны генерировать пользователи при помощи геймификации. Приступим!

Постановка задачи

Дано:

Итак, есть интернет проект. Большая часть его контента, если не весь, должен генерироваться самими пользователями, он может быть разных типов.

Найти:

Сами участники должны публиковать контент, оценивать и модерировать контент, выложенный другими пользователями.

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

Как вообще можно сделать игру, в которой два персонажа не имеют преимуществ перед одним?

В разрабатываемой мной игре «Кибер развитие» это реализовано, может еще не окончательно, но в значительной мере. А тем кому действительно интересен ответ — читаем дальше…

В статье рассказывается о определенном, можно сказать новом жанре игр. Задуматься об этом меня заставило интервью с Николаем Дыбовским из компании Ice-Pick Lodge, интернет-статьи пользователя под ником Orgota, мой опыт игр в игры жанра «Песочница» и сравнительно небольшой опыт создания игры «Кибер развитие».

Что такое «Инверсная кинематика»?

Задачей инверсной кинематики является поиск такого набора конфигураций сочленений, который обеспечил бы максимально мягкое, быстрое и точное движение к заданным точкам. Однако, множество существующих ныне методов страдают от таких недостатков как высокая вычислительная сложность и неестественность результирующих поз. В этой статье описан новый (вероятно, на момент написания статьи — 2010 г.) эвристический метод под названием «Метод прямого и обратного следования» ( Forward and Backward Reaching Inverse Kinematics, далее просто FABRIK),
FABRIK избегает использования вращений и матриц в пользу непосредственного получения точки на прямой. Благораря этому, дело обходится всего несколькими итерациями, имеет низкую стоимость вычислений и визуально естественную позу в результате. FABRIK так-же без проблем справляется с наложением ограничений а так-же использованием нескольких цепей и/или конечных точек. Именно об этом методе этот пост.

В развязке фильма «Бегущий по лезвию» герой Рутгера Хауэра говорит, что видел многое, что люди не могут себе даже представить — космические битвы, пылающие боевые корабли — но разве так уж трудно вообразить всё это современному человеку, избалованному компьютерной графикой? В то же время, нас окружает множество вещей, которые мы никогда не сможем рассмотреть в деталях, в силу фундаментальных физических ограничений. Более того — мы и сами состоим из таких вещей. Впрочем, хорошая новость в том, что эти объекты можно смоделировать и визуализировать, используя развитый в настоящее время 3D-инструментарий. А если собрать команду, в которой будут не только трехмерные моделлеры, визуализаторы и дизайнеры, но и ученые, можно максимально приблизить результат к реальности.

Под катом первая часть рассказа о нашем опыте создания научно достверных моделей вирусов.

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

Играть можно тут



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

Всем привет,

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

Наш опыт будет полезен как тем, кто пробует делать видео самостоятельно, так и тем, кто собирается аутсорсить создание видеоролика для своей игры.

Итак, чтобы сделать видео для игры, надо пройти следующий путь:

Выбор типа ролика

Первое, о чем мы спрашиваем клиента — “зачем вам видеоролик?” В зависимости от ответа предлагаем один из типов видео:

- Ролик-тизер. Не показывает геймплей, не говорит ничего конкретного про игру, но создает интерес к игре, дразнит зрителя.

Тизер для мрачной и чертовски захватывающей игрушки Darklings 2 от Mildmania:

В данном посте я хочу описать простую методику пиксельного искажения изображения на «чистом» javascript в 2D-Canvas без использования специальных библиотек и шейдеров, путём прямого доступа к пикселям изображения. Надеюсь, это будет интересно и полезно как для общего развития, так и для решения каких-то задач.

В этой статье я попробую сам разобраться в себе и в своих аргументах. Для начала попробую оппонировать автору статьи, перевод которой нашел на хабре Где наша бизнес-логика, сынок?. Её писал такой же идеалист, которым я был еще лет 10 назад. Поэтому по сути в этой статье я буду спорить сам с собой. Дело в том, что чем больше приложений я разрабатываю тем больше красивые теории перестают вписываться в идеальные схемы. Идеальные схемы хороши тем, что они просты. Вас спрашивают где бизнес слой? И ты легко можешь сказать на стороне клиента или на стороне сервера. Если смешенно многозначительно крутят носом и говорят «гавно-код». С этим я не согласен. Реальный мир не вкладывается в идеалистические концепции, точнее его можно туда запихнуть, но мы от этого скорее потеряем. Поэтому вначале подсознательно я понимал, что есть разные случаи. А теперь все более пытаюсь сформулировать, что влияет на то или иное решение по размещению бизнес логики. Здесь мы оставим красивые теории без аргументации молодым утопистам желающим простых решений.

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

Отдельное спасибо автору, за разрешение отдельной публикации.

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

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

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

Для тех, кто активно пользуется MySQL, не секрет, что начиная с версии 5.1, MySQL поддерживает события (events). Если вам нужно выполнять запросы или отдельные процедуры по расписанию, а перейти с запуска консоли на встроенный функционал MySQL было лень не было времени,

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

Этот алгоритм является улучшенным алгоритмом поиска пути A*. JPS ускоряет поиск пути, “перепрыгивая” многие места, которые должны быть просмотрены.  В отличие от подобных алгоритмов JPS не требует предварительной обработки и дополнительных затрат памяти. Данный алгоритм представлен в 2011 году, а в 2012 получил высокие отклики. Что из себя представляет данный алгоритм и его реализацию можно прочитать дальше в статье.