Не мало было историй о том, как небольшие группы разработчиков добивались успеха. И ещё больше о том, как эти разработки проваливались. Но здесь я хочу рассказать именно об эволюции процесса разработки онлайн игры, опираясь на свой опыт. Оговорюсь заранее: это первый мой опыт разработки массовой онлайн игры.
Всё началось весьма интригующе. Я имел неаккуратность поспорить со знакомой web-программисткой о том, кто быстрее и качественнее из нас сделает web-проект. Чтобы не сильно распыляться и не тратить много времени, решили, что нам будет дана всего одна неделя, а разрабатывать мы будем многопользовательскую игру!

По истечению этого срока проекты были сданы «оценочной комиссии», которой являлись наши общие друзья. И… Мой проект не выиграл. А самым обидным на тот момент казалось то, что, по условиям спора, я должен был выделить ещё одну неделю рабочего времени, чтобы помочь своей оппонентке в развитии её игры. Но спор есть спор!

Команда разработчиков Google Wave приняла решение запустить open source проект на базе Google Wave, кроме тех 200k строк кода, которые уже открыты (см. waveprotocol.org). Новый проект — более чётко скомпонованное решение, фактически, уже готовая система.

Проект называется Wave in a Box и включает в себя следующее:

* пакет приложений, включая сервер и клиенты с поддержкой структурированных коммуникаций в реальном времени по образцу системы Google Wave;
* быстрая и полнофункциональная wave-панель для веб-клиента с полной поддержкой тредовых чатов;
* стабильное хранилище данных и реализация поиска для сервера (сделано на стороннем коде для внедрения MongoDB)
* усовершенствованные клиент-серверные протоколы;
* поддержка API для гаджетов, роботов и данных;
* поддержка импорта wave-данных с wave.google.com;
* возможность объединения различных инстансов Wave in a Box, с некоторой дополнительной конфигурацией.

Любой программист хоть раз заглядывавший в отладчик знаком с понятием точки останова (aka бряк, breakpoint). Казалось бы нет ничего проще, чем поставить точку останова пара кликов мышкой в графическом интерфейсе или команда в консоли отладчика, но не всегда жизнь системного программиста столь проста и иногда возникает необходимость выставлять точки останова автоматически — изнутри самой программы.

Открываем

Открыть вкладку можно тремя разными способами, самый простой и интуитивный :tabnew в нормальном режиме, он откроет новую вкладку с пустым буфером. Можно сразу открыть вкладку с файлом, передав его имя как параметр

:tabnew futuri.co

Вкладки можно также открыть сразу после запуска, если добавить ключ -p перед списком имен файлов — для каждого откроется своя вкладка.

vim -p habra.sh habr.py

Написал небольшой мануал по настройке и масштабированию PostgreSQL. Сподвигло меня на это то, что материала по этой теме мало, он устарел или его просто нет.

Скачать можно здесь:
http://github.com/le0pard/postgresql_book/raw/master/postgresql.pdf
Исходники:
http://github.com/le0pard/postgresql_book/

Страница:
http://postgresql.leopard.in.ua/

Позволю себе поднять упавшее знамя, оставшееся после предыдущих ораторов и продолжить благое дело продвижения zsh в массы. Надеюсь, после прочтения топика вы тоже смените старый добрый, но, как по мне, так застрявший в прошлом, bash на более удобный и продвинутый zsh.
Чтобы не быть голословным, попробуем рассмотреть это дело в контексте абсолютно субъективного и предвзятого сравнения bash vs. zsh.

Статья раскрывает смысл термина «64 бита». В статье кратко рассмотрена история развития 64-битных систем, описаны наиболее распространенные на данный момент 64-битные процессоры архитектуры Intel 64 и 64-битная операционная система Windows.

Это продолжение статьи ХХ полезных советов для пользователей Git среднего уровня

Про reset, незапланированно снова про альясы, про замечательный filter-branch, про мерджи и разрешение конфликтов с помощью rerere, про rebase (интерактивный и не очень) и, в завершение, про обслуживание своей гитницы.

Вообще-то изначально я планировал перевести статью Энди Джеффриса (Andy Jeffries) 25 Tips for Intermediate Git Users, но в процессе я отбросил бестолковые, общеизвестные или самые простые советы вроде «настройте первым делом user.name и user.email», которые явно не подходят людям, уже более-менее плотно знакомым с Git.
Взамен я дополню статью моментами из личной практики («Своя практика»! Звучит здорово, будто я частный врач или адвокат! :-] )

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

Совершенствование кода и его оптимизация порой отнимает больше времени, чем заняло написание первой версии. Вы часто встречали новый для вас код или интересную реализацию, и говорили себе: «Оказывается, это можно сделать стандартными средствами, а я изобретал велосипед»? Лично я — да. Поэтому в этой статье я собрал свою коллекцию «велосипедов», и рассказал, как от них можно избавиться.

Методы массивов

Простой пример — допустим, у вас имеется массив объектов класса User. У них есть свойство activated, которое выставляется на 1, если юзер активировал свою учетную запись. Вам нужно проверить, все ли юзеры из массива активированы. Не берем во внимание ActiveRecord (там можно и по-другому сделать), моя цель — показать работу с массивами.

Способ первый, самый примитивный:

1. @users = User.find(:all)
2. activated_users = 0
3. foreach user in @users
4.   activated_users += 1 if user.activated == 1
5. end
6.  
7. # если количество совпадает, значит все юзеры активированы
8. activated_users == @users.size

В декабре на Хабре была хорошая статья, о полиморфных связях в Рельсах. Вот она. Перед тем как читать дальше, пожалуйста ознакомьтесь с ней.
Однако, у автора статьи осталось несколько неотвеченных вопросов. Вот на них то мы сегодня и найдем ответы.

Иногда требуется создать форму, данные которой связаны с несколькими таблицами. К примеру, у вас имеется две модели: Owner и Car. При добавлении нового Owner'a хотелось бы, чтобы была возможность сразу добавить машину. С появлением Rails 2.3 это стало проще.

# Старый вариант (приблизительный)
def create
  @owner = Owner.new(params[:owner])
  ...
  if @owner.save
    @car = Car.new(params[:car])
    if @car.save
    ...
end

# Новый вариант, Rails 2.3+
def create
  @owner = Owner.new(params[:owner])
  ...
end

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

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

у нас есть модели Статьи, Фотографии и События. А еще есть модель Комментарии. А еще очень хочется все комментарии (комментарии статей, фотографий и событий) хранить в одной таблице.

Статей по этой проблеме в интернете очень много, но бывают и случаи «наоборот». Далеко ходить не нужно, давайте попробуем разработать функционал постов Хабрахабра!

Беспрецедентные объемы данных заставляют разработчиков и бизнес приглядываться к альтернативам реляционных баз данных, используемым вот уже более тридцати лет. В совокупности все эти технологии известны как «NoSQL базы данных».


Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах). Есть три конкретные проблемных области:

• горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
• производительность каждого отдельного сервера
• не гибкий дизайн логической структуры.

Сколько раз я уже перечитывал статьи Пола Грэма, столько раз я удивлялся его потрясающему умению открывать глаза на вроде бы обычные вещи. И потрясающей способности интересно описывать окружающий нас мир.

Да, это он в 1998 году продал свою компанию Viaweb интернет-гиганту Yahoo, которая впоследствии назвала этот продукт Yahoo Store. Да, это он основал венчурный фонд Y Combinator. Да, это его журнал BusinessWeek включил в список 25 наиболее влиятельных людей в Сети за 2008.

Хотите читать по-настоящему интересные аналитические статьи? Вам однозначно к Полу. Я настоятельно рекомендую прочитать его заметки. Особенно если вы it-шник. Особенно если вы собираетесь открывать свой бизнес.

Создать эту сборную солянку меня частично сподвиг вчерашний пост про кубика Рубика. Думаю, для развития темы и продвижения в массы пойдет…



Я не понимаю, что сподвигает людей на ТАКИЕ действа — может быть излишки свободного времени, или желание выделиться из серой толпы, или… но в любом случае, смотрится это действительно крайне впечатляюще!!!

Протестировать свежую версию любимого фреймоврка. Запустить приложение со специфичным набором библиотек. Установить необходимые библиотеки по списку зависимостей. Как решить все эти задачи не затронув системные файлы? В этой статье речь пойдет об утилитах virutalenv и pip.

Представляю вашему вниманию подборку интересных домашних офисов

Год назад мы с командой решили перейти с SVN на Git. Зачем это было надо — писать не буду, т.к. на эту тему уже и так много написано. А хочу я описать типичные алгоритмы работы, понятные человеку, который долгое время пользовался SVN. Ниже — памятка, написанная для команды год назад, чтобы легче было мигрировать. Надеюсь, кому-нибудь пригодится.

Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

В конце каждой главы Мистер Томпкинс подводит итоги и записывает свои мысли, которые, по сути, являются аксиомами и постулатами управления проектами по ДеМарко и Листеру. Разумеется, лучше будет прочесть всю книгу в целом — иначе не понять, как эти принципы применяются в «реальной» жизни. Но если времени нет (или же просто хочется освежить память), то вашему вниманию предагается…