Смотрю в сторону Ruby

Спонсор поста: Интернет магазин моделей. Скучно сидеть в офисе и тупо пялится в монитор? Устройте офисные гонки на радиоуправляемых машинках tamiya - это весело и не будет злить босса, если вы и ему подарите одну из моделей tamiya.

С недавних пор заинтересовался языком программирования Ruby. Ruby – это сверх динамический интерпретируемый язык высокого уровня. Сильной стороной Ruby является в первую очередь его простота и удобство, а также лаконичность и читабельность кода.
Ruby очень похож на такие языки, как Perl, Python, Smalltalk и javaScript. Благодаря чему переход с этих языков на Ruby будет еще более быстрым и удобным.

Кроме всех достоинств самого языка Ruby, меня заставило увлечься им еще и существование такого могущественного фреймворка написанного на Ruby как Ruby-on-Rails, или просто Rails.

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

К сожалению, документации по Ruby и Rails на русском языке очень мало, это и толкнуло меня на идею создания блога с переводом изобилующих в англоязычном сегменте интернета статьями и учебниками. Мой новый блог будет посвящен не только Ruby и Rails, но и веб разработке вообще, т.е. там можно будет встретить мои мытарства в другие языки программирования, фреймворки и т.д. Как только блог будет запущен – я сразу же сообщу о нем.

Не революционные идеи.

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

1. В нашей стране сложно строить свой бизнес в сети интернет на нестандартных проектах. Кроме монетизации через рекламу сложно что-либо придумать. Мои знакомые в этом со мной согласны, они также утверждают то, что лучше создавать клоны уже известных зарубежных проектов, которые имеют маркетинговую модель и идеи касательно монетизации.

2। Страны СНГ – бедные страны. То, что могут купить пользователи интернета из США, себе никогда не позволят пользователи из Украины или России. Отсюда сложность в монетизации проекта, наши люди слишком привыкли к халяве и не привыкли к пользованию платными сервисами. Единственное во что идут деньги – это игровая индустрия, а точнее браузерные игры и приложения в соц. сетях в частности. Я не работаю с Flash и я не умею рисовать, поэтому разработка сколь-нибудь серьезных игр отпадает.

3. любые идеи, которые приходили мне в голову упирались либо в сложность монетизации, либо в свою чрезмерную схожесть с уже известными проектами. Например, одна из моих идеи – создание соц. сети «клуб по интересам» не только была очень похожа на Вконтакт+Хабрахабр, но и при дальнейшем изучении содержимого русскоязычного сегмента интернета нашло множество подобных реализаций. Если разобраться, то даже отличий от ЖЖ было не так уж много… Все это говорит либо о том, что у меня плохо с фантазией, либо придумать что-то новое очень сложно. В свою защиту я склоняюсь ко второму варианту=)

Какие выводы из всего этого стоит сделать:

1. Стоит ориентироваться на западный рынок. Там и денег больше и пользователи с ними легче расстаются.

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

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

4. Отличная идея – разработка расширений к уже имеющимся стартапам. Посмотрите, сколько создано различных сервисов использующих TwitterAPI и многие из них приносят достаточно хорошую прибыль своим владельцам притом, что разрабатывать подобные проекты куда легче, чем сам Twitter. Или же взгляните на множество приложений Вконтакте и охотность инвесторов инвестировать в подобного рода проекты.

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

Поломался телефон? И не слышно друга звон? Вам поможет ремонт мобильных телефонов производимый MTL-servis'ом. MTL-service качественно выполняет ремонт телефонов от любого производителя и любого форм-фактора.

Пример использования Django 1.1 на Google App Engine

Я являюсь постоянным читателем сайта Hacker News. Примерно раз в месяц там создаются темы, где создатели стартапов и сочувствующие ищут себе сотрудников. Отдельный раздел для вакансий на этом сайте доступен только для фирм, которые участвуют в программе инвестирования Y Combinator. Кто-то предложил создать сторонний сайт вакансий специально для остальных пользователей этого сайта. Я решил реализовать эту идею, а заодно и получить практический опыт использования фреймворка Django более-менее свежей версии на платформе Google App Engine.

Так получился сайт Jobs for hackers с открытым исходным кодом. Созданный сайт использует авторизацию на основе учетных записей Google Account, так что если вы уже пользуетесь любым сервисом гугла, то дополнительно регистрироваться вам не нужно. Если же вы захотите на основе этого кода создать свой проект, где потребуется своя система регистрации и авторизации, то советую начать с чтения вот этого поста на английском языке, там есть ссылка на исходный код такого проекта тоже на Django 1.1 поверх Google App Engine.

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

Любой разработчик, который использует в своей работе встроенное в Google App Engine хранилище Datastore, наверняка сталкивался с проблемой постраничной выборки записей. Пока что нет масштабируемого встроенного решения, а статьи гугла, где встречается неработающий код, не всегда помогают. Но поиск по гуглогруппе App Engine позволил найти довольно изящный код, немного патченая версия которого находится тут. Пришлось закомментировать место в этом кода, где используется класс db.PolyModel, если в вашем коде этот класс нужен, то дайте знать, вместе что-нибудь придумаем. Вот пример постраничной навигации из файла views на основе того кода :

from jobs.models import Job
from pager import PagerQuery
PER_PAGE = 10
bookmark = request.GET.get('bookmark')
query = PagerQuery(Job).filter('status =', 'published').order('-published_at')
# это эквивалентно jobs = Job.all().filter(...).order(...)
prev, jobs, next = query.fetch(PER_PAGE, bookmark)

Еще поначалу во время разработки я думал разделить программную часть сайта на две половины. Там, где не нужны были сложные шаблоны, я думал не использовать Django, а ограничиться более простым фреймворком webapp. Но постоянные ошибки UnacceptableVersionError, которые то появлялись, то пропадали при странных обстоятельствах после многочисленных исправлений, заставили перевести весь код под управление Django. Всё из той же гуглогруппы я узнал, что фреймворк webapp, который использует шаблоны Django версии 0.96, при загрузке выполняет код import django, перед которым нельзя вклиниться и выполнить вызов use_library. Если кому-то из вас удалось это обойти, дайте знать, может когда-то понадобиться для оптимизации. Хотя чувствую, что вся эта затея является классической преждевременной оптимизацией, поскольку никаких числовых показателей для оценки производительности я не измерял.

Не до конца еще пока решил вопрос с кешированием статических файлов. Для предпоследней версии SDK 1.3.1 в списке изменений указывалась автоматическая выдача Http кода 304 Not Modified для статических файлов. Причем в багтрекере была приписка, что такое поведение будет только на серверах App Engine, для тестового сервера из SDK, который используется при разработке, файлы будут загружаться постоянно. По факту сервера App Engine работают не так, как ожидается. Вместо кеширования на год или еще какой-то большой срок, повторной загрузки файлов на клиента удается избежать только 10 минут. Недавно вышла следующая версия SDK 1.3.2, я еще не успел посмотреть как там с загрузкой статики. Если ничего не изменилось, то придется писать свой обработчик для файлов стилей, картинок и джаваскрипта.

Приветствуется также критика перевода этого поста на английский язык.