Всем нам наверное знакомы терзания по поводу выбора той или иной альтернативы в процессе разработки. В последнее время я пришел к выводу, что правда, она не всегда одна и что не надо стараться найти самое хорошее решение, надо просто найти одного из двух-трех финалистов и дальше слушаться внутреннего голоса, а не сухого сравнения фич, выбор зачастую индивидуален в пределах человека (комманды). Поэтому то что работает для ребят из Бангалора или консльтантов из Амстердама, не всегда будет работать для Вас. Как и то что я опишу ниже.
Наличие выбора (типа демократии) - это всегда хорошо и я попытаюсь рассказать как и что мы выбирали, и главное - почему. Начнем с основного (хотя основное это наверное идея, но сейчас не об этом) - платформы/языка разработки.
На чем в современном мире пишут веб приложения - PHP, Perl, Java, .Net, Perl, Python, Ruby. Все остальное экзотика (простите если кого забыл из серьезных но вроде все тут, Flex не предлагать это не платформа а скорее утилита).
Паралельно давайте определимся с критериями, для нас они (в порядке важности)
- скорость разработки, как начальная так и общая. Это разные вещи
- мощность библиотек
- хороший templating language
- не write-only (goodbye Perl)
- чтобы от синтаксиса и возможостей языка не воротило (goodbye Java, PHP, .Net)
- развертывание на NIX системе (goodbye .Net)
- Мощный community и, как следствие, поддержка
PHP - про этот язык я знаю только то, что он простой и про то, что узнавать больше не хочу, так как нет в нем абсолютно никакой изюминки. Популярен только из-за простоты и огроменного количества библиотек (следствие первого). Особого удовольствия програмирование на нем приносить не должно, а следовательно зачем нам такое надо. Работа должна нравится, и язык тоже как часть ее.
Perl - наверное единственный нефункциональный язык, код написаный на котором я не понимаю. Для меня этого достаточно чтобы продолжать непонимать. Более того, от людей которые на нем пишут знаю, что зачастую код написаный на Perl-е, даже авторам понятен только в течении часа после того как работа над ним завершена. Библотеки хороши, с комьюнити тоже неплохо, но как можно писать на write-only языке что-либо серьезное не знаю.
Java - язык написаный консультантами для консультантов, по крайней мере его J2EE часть. Хорошая платформа для зарабатывания денег, как и .Net, но для работы в свое удовольствие не годится. К примеру, сравнивать JSP с Mako templates из Python это как сравнивать Волгу и BMW в старые советские времена, первое явно неудобно и явно устарело, хоть и ездит но МинТранс не дает добро на переработку так как сильно много людей уже на ней ездит и им будет больно/завистно что они в свое время купились на такое г-но. Лучше им просто не показывать что где-то есть BMW. Кстати позор Java еще и в том что там до сих пор нет механизма делания thumbnails из картинки, дающего результат с нормальным качеством. Одного только этого факта достаточно чтобы судить о том как эта платформа предназначена для Web. Да и язык мягко говоря за 10 лет устарел, нет в нем динамики, один геморой с рефлекшинами.
В итоге вердикт - отказать, хоть я и посвятил этой платформе 7 лет своей работы и знаю там почти все входы - выходы.
.Net - см Java + Microsoft + No NIX = отказать.
Ruby - очень хороший язык, RoR очень хорошая платформа, наверное лучшая для Web в плане начальной скорости, но - слабые библиотеки и если бы не это то писать бы нам на рельсе. В остальном - язык с точностью до синтаксиса практически идентичен Python. Чуть красивее, и в 10 раз медленнее (обещают скоро пофиксить). Я думаю у платформы большое будущее, но все же пока стремновато нарватся на задачу типа парсинга/создания excel файлов которую прийдется решать самостоятельно и почивать на лаврах автора супер-дупер библиотеки с милионами фанатов, или забить и ждать пока это не сделает кто-то другой.
Python - отличный язык (ну немного корявый синтаксис __конструкторов__ и прочего, но это терпимо и привыкаешь быстро), зато:
- отличные Mako templates, лучшее наверное из того что есть на сегодня во всех языках
- отличная читаемость кода
- Pylons - по сути перенос идей RoR, отличный веб фреймворк
- подходит для системного програмирования (замена bash) так что не надо активно использовать сразу несколько языков (например Java и Python как раньше)
- отличные библиотеки на все случаи жизни (пока что)
- удобная работа с СУБД - SQLAlchemy - отличный ORM, Elixir - отличная надстройка над ним
- очень быстрый, есть возможность JITи прочих оптимизационных наворотов
В итоге Python теперь наш выбор и, несмотря на то, что никто из нас толком на нем до этого не писал за 6 недель мы сделали столько, сколько на Java делали бы бесконечность времени. Просто потому что на Python код успевает за твоими желаниями хоть как-то, а в Java нет, в итоге, прототипировать на Java это как бежать за своей тенью, в Sonopia мы ее догнали, но за 30 лямов и поздно, да и вдвадцатером.
Вообще после 7 лет Java сейчас после 6 недель Python сложлось ощущение, что тебя злобно обманывали заставляя ходить на костылях, при том что рядом люди ходили нормально, ну может зарабатывали поменьше, но ведь и ходили ровно, и не думали каждую секунду как бы так извратиться с рефлекшином чтобы написать более менее универсальный код. Причем обманывали на очень высоком уровне, и очень много людей, и продолжают успешно обманывать. Консалтинг великая сила, что тут говорить.
Показаны сообщения с ярлыком программирование. Показать все сообщения
Показаны сообщения с ярлыком программирование. Показать все сообщения
29 Март 2008 г.
19 Март 2008 г.
Тестирование веб приложения на слабом канале
Помнится, будучи в Сонопии, я долго искал как потестировать приложение на слабом канале. Иногда от этого открываются глаза насколько разные фреймфорки которые должны делать юзерам хорошо - делают им плохо, иногда очень плохо.
Сегодня я таки нашел то что искал - Sloppy - простое кросс-платформенное Java Web Start приложение.
С его помощью я уменьшил загрузку старт пейджа (до появления контента) на 128К канале с чистым кешом до 2с (было 19 но кто ж это когда видел на http://localhost:5000)
Сделал я это просто - убрал все скрипты вниз и сделал чтобы контент не дергался пока они не загрузятся, ну и всю динамику повесил на onDomReady. В итоге пользователь за 2 сек видит страницу а через 4-5 сек она оживает. Думаю после подключения gzip для скриптов и стилей эту задержку можно будет сократить до 2-3 сек, но даже сейчас результат приемлим.
Сегодня я таки нашел то что искал - Sloppy - простое кросс-платформенное Java Web Start приложение.
С его помощью я уменьшил загрузку старт пейджа (до появления контента) на 128К канале с чистым кешом до 2с (было 19 но кто ж это когда видел на http://localhost:5000)
Сделал я это просто - убрал все скрипты вниз и сделал чтобы контент не дергался пока они не загрузятся, ну и всю динамику повесил на onDomReady. В итоге пользователь за 2 сек видит страницу а через 4-5 сек она оживает. Думаю после подключения gzip для скриптов и стилей эту задержку можно будет сократить до 2-3 сек, но даже сейчас результат приемлим.
Labels:
программирование
16 Март 2008 г.
Что значит работать с trunk-ом?
На прошлом Exception-е был некто Иван Сагалаев из Яндекса с докладом по Django, который постоянно как мантру повторял что работая с питоном и в часности с джанго вам прийдется постоянно работать с trunk-ом. То есть очень часто версия которая есть в репозиториях не содержит нужных вам фич либо имеет баги которые пофикшены но еще не оформлены как релиз.
Сегодня я убедился в этом на собственном опыте. Есть видимо какой-то коллективный разум который независимо открывет почти одновременно некоторые баги в разных частях света.
В Питоне есть замечательная либа Elixir, а в ней замечательный плагин acts_as_list(позволяет легко вводить отношение порядка на множестве/подмножестве элементов таблицы) и в нем в текущей версии есть баг при работе с postgresql (связаный с его одной особенностью), который согласно trac-у был пофикшен 5 марта.
Теперь до выхода новой версии нам прийдется работать с транк-ом elixir-а, что впрчем ненамного сложнее чем с релизом.
svn checkout http://elixir.ematia.de/svn/elixir/trunk/ elixir
cd elixir
sudo python setup.py install
вместо
sudo easy_install Elixir
Labels:
программирование
8 Март 2008 г.
Наша Инфраструктура
Мы пишем на Python используя Pylons фреймворк совмесно с Elixir/SQLAlchemy/AuthKit/FormEncode/FormBuild/PIL/Paste/Babel и еще десятком других фреймворков. Всю эту кухню никто из нас ранее глубоко не знал, но в целом по прошестии двух недель все начинает получаться и все меньше приходится гуглить. Писать на Python после Java - это как ходить без костылей. ИМХО. Посмотрим как оно будет когда проект вырастет.
Код хранили сначала в Google Code(удобно пока нет своего сервера) потом установили свой SVN.
Для тасков/багов/wiki используем Trac - могу сказать что он проще и быстрее чем JIRA и нам пока абсолютно нравится. Мы двигаемся двухнедельными майлстоунами, первый из которых будет закончем в этот понедельник.
Сборка проекта и тесты запускаются Bitten-ом, тесты впрочем пока не запускаются по неизвестным нам причинам. Поправим в следующем майлстоуне.
Все это дело (SVN, Apache, Trac, Bitten) крутится на cutting-edge серваке сделаном со старого домашнего компа Тараса, PIII, 512MB, Ubuntu Linux, и никто почти не жалутся, ну иногда бывают тормоза, но в Сонопии и джира и конфлуенс тормозили поболее. Впрочем, скоро это все переедет на виртуалку на хорошем сервере и думаю про тормоза забудем навсегда.
Также мы настроили бекап всех данных на Amazon S3, За 3 дня съело целых 5 центов с кредитки. Тулзу для бекапа исрользуем Duplicity, она вроде шлет только дифы, после тест драйва будет ясно насколько это эффективно.
Планы
- Настроить тесты
- Прикрутить Puppet, для хранения/управления конфигурациями
- Настроить lighttpd для работы с Pylons
- Перенести все на постоянную виртуалку на новом сервере
- Подготовить сервер для хостинга (решить как хостить на реальном сервере или поставить xen и жить в виртуалках)
- Перенести все на постоянную виртуалку на новом сервере
- Подготовить сервер для хостинга (решить как хостить на реальном сервере или поставить xen и жить в виртуалках)
Labels:
инфраструктура,
общее,
программирование
Подписаться на:
Сообщения (Atom)
