UPD Если вы хотите работать у нас Pyhton разработчиком пишите на m@prom.ua
Всем нам наверное знакомы терзания по поводу выбора той или иной альтернативы в процессе разработки. В последнее время я пришел к выводу, что правда, она не всегда одна и что не надо стараться найти самое хорошее решение, надо просто найти одного из двух-трех финалистов и дальше слушаться внутреннего голоса, а не сухого сравнения фич, выбор зачастую индивидуален в пределах человека (комманды). Поэтому то что работает для ребят из Бангалора или консльтантов из Амстердама, не всегда будет работать для Вас. Как и то что я опишу ниже.
Наличие выбора (типа демократии) - это всегда хорошо и я попытаюсь рассказать как и что мы выбирали, и главное - почему. Начнем с основного (хотя основное это наверное идея, но сейчас не об этом) - платформы/языка разработки.
На чем в современном мире пишут веб приложения - 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 сложлось ощущение, что тебя злобно обманывали заставляя ходить на костылях, при том что рядом люди ходили нормально, ну может зарабатывали поменьше, но ведь и ходили ровно, и не думали каждую секунду как бы так извратиться с рефлекшином чтобы написать более менее универсальный код. Причем обманывали на очень высоком уровне, и очень много людей, и продолжают успешно обманывать. Консалтинг великая сила, что тут говорить.
Старый неофициальный блог компании УАПРОМ (Prom.ua (бывший UAProm.net), Tiu.ru, Deal.by, KAZProm.net, Prom.md). Если вы хотите работать у нас пишите на hr@prom.ua
суббота, 29 марта 2008 г.
четверг, 27 марта 2008 г.
Игра на чужом (хоть и своем) поле от Google
Оказывается это делает не только VMWare но и нами всеми горячо любимый Google.
Честно говоря, от них такого не ожидал. Ход в стиле M$, видимо акционеры требуют дивиденты, учитывая еще и 40% проседание акций с начала года на фоне намного более меньшего падения основных конкурентов. Может скоро do not be evil уйдет в историю?
Честно говоря, от них такого не ожидал. Ход в стиле M$, видимо акционеры требуют дивиденты, учитывая еще и 40% проседание акций с начала года на фоне намного более меньшего падения основных конкурентов. Может скоро do not be evil уйдет в историю?
воскресенье, 23 марта 2008 г.
Не совсем юмор (Найти и Потрогать)
Многие наверное помнят отличный юмор от It's Just a Bunch of Stuff That Happens Blog
Юмор просто шикарный, но не только. Не секрет, что споры по поводу UI в любом веб проект очень жаркие и дело даже не в спорах просто иногда мы забываем о том что надо пользователю, а ему оказывается надо то, найти и потрогать, а не втыкать в 200 контролов на странице.
В последнее время при принятии решений мы все чаще вспоминаем этот шарж и он действительно помогает найти интересные варианты, некоторые из них мы воплощаем сразу, некоторые записываем как идеи на будущее.
Найти и потрогать...
Потрогать и найти...
...
...
Юмор просто шикарный, но не только. Не секрет, что споры по поводу UI в любом веб проект очень жаркие и дело даже не в спорах просто иногда мы забываем о том что надо пользователю, а ему оказывается надо то, найти и потрогать, а не втыкать в 200 контролов на странице.
В последнее время при принятии решений мы все чаще вспоминаем этот шарж и он действительно помогает найти интересные варианты, некоторые из них мы воплощаем сразу, некоторые записываем как идеи на будущее.
Найти и потрогать...
Потрогать и найти...
...
...
суббота, 22 марта 2008 г.
Игра на чужом поле от VMWare
Вбил я как-то в гугле xen и увидел вот такое.
И стало мне смешно, не знаю почему. Вобщем все равно мы используем Xen.
Update: Сделал более красивый скриншот. Спасибо Тиму О'Рейли что научил как скриншотить только содержимое окна.
И стало мне смешно, не знаю почему. Вобщем все равно мы используем Xen.
Update: Сделал более красивый скриншот. Спасибо Тиму О'Рейли что научил как скриншотить только содержимое окна.
пятница, 21 марта 2008 г.
Как распределять доли в стартапе (наш вариант)
Задача:
Есть несколько людей которые:
- имеют идею как им совместно сделать проект который будет приносить деньги
- доверяют друг другу (друзья с детства, давние знакомые и т п)
- скопили денег на то чтобы некоторое время (достаточное для выполнения проекта) финансово ни от кого не зависеть
Они начинают общее дело и им нужно как-то оформить еще не приносящее прибыли предприятие. Есть вариант оформить сразу или потом, когда возникнет потребность. Раннее оформление влечет за собой кучу расходов и волокиты, кроме того, не решает проблемы распределения долей в будущем успешном (?) бизнесе. С вариантом оформить потом тоже все не просто, так как на тот момент, когда появится прибыль у участников будет разное видение размера своего вклада в продукт, что может закончитьс плачевно и для дружбы и для бизнеса. Вариант разделить доли сразу тоже плох, так как заранее неизвестен окончательный вклад в продукт каждого из участников.
Проанализировав все это, а также статью Как делить доли в стартапе мы пришли к следующей модели, которая пока работает для нас хорошо.
Решение:
- Мы не создаем юридическое лицо сейчас, к счастью нас приютили, в том числе и юридически, наши друзья.
- Доли в компании есть динамическими и зависят от вклада учасников в общее дело
- Вклады на ранней стадии более ценные, что досигается индексацией их по начальной ставке 30% годовых, то есть 1000$ вложенная сеодня будет равна 1300$ через год. Процент плавающий и меняется раз в месяц в зависимости от текущей средней температуры по палате (состояния дел). Например мы уже снизили его с 30 до 28 после того как поработали месяц и ликвиировали за это время большое количество рисков.
- Все участники получают заранее оговоренную компенсацию за работу, либо почасовая оплата либо зарплата которая может не выплачиваться (в большинстве случаев) либо выплачиваться частично. Деньги которые не выплатились становятся инвестииями участника в проект и записываются в конце месяца в Инвестиционную Ведомость
- Также в ведомость записываются все расходы на инфраструктуру и аутсорсинг и в конце месяца доли пересчитываются
- Деньги на денежные расходы вносятся добровольно но мы старемся их равномерно распределять между отцами-основателями
- Когда проект стабильно выйдет на самоокупаемость (будет покрывать затраты участников на него) будет создано АОЗТ, в котором доли будут закреплены официально и меняться не будут
- В случае прекращения сотрудничества с учасником до создания АОЗТ (впрочем и после тоже) пока мы решили что его доля остается (она плавно уменьшается так как ), но перечитав с утра Как делить доли в стартапе мне кажется что это не есть правильно и возможно стоит это доработать.
Нам эта схема очень по душе, я трачу на всю бухгалтерию 30 мин в месяц. Более того она позволила нам привлечь новых людей в проект, закрыв важные направления. И думаю привлечет еще.
Надеюсь данная схема (или ее модификация так как любая ситуация уникальна) также поможет тем кто хочет начать общее дело с друзьями.
Есть несколько людей которые:
- имеют идею как им совместно сделать проект который будет приносить деньги
- доверяют друг другу (друзья с детства, давние знакомые и т п)
- скопили денег на то чтобы некоторое время (достаточное для выполнения проекта) финансово ни от кого не зависеть
Они начинают общее дело и им нужно как-то оформить еще не приносящее прибыли предприятие. Есть вариант оформить сразу или потом, когда возникнет потребность. Раннее оформление влечет за собой кучу расходов и волокиты, кроме того, не решает проблемы распределения долей в будущем успешном (?) бизнесе. С вариантом оформить потом тоже все не просто, так как на тот момент, когда появится прибыль у участников будет разное видение размера своего вклада в продукт, что может закончитьс плачевно и для дружбы и для бизнеса. Вариант разделить доли сразу тоже плох, так как заранее неизвестен окончательный вклад в продукт каждого из участников.
Проанализировав все это, а также статью Как делить доли в стартапе мы пришли к следующей модели, которая пока работает для нас хорошо.
Решение:
- Мы не создаем юридическое лицо сейчас, к счастью нас приютили, в том числе и юридически, наши друзья.
- Доли в компании есть динамическими и зависят от вклада учасников в общее дело
- Вклады на ранней стадии более ценные, что досигается индексацией их по начальной ставке 30% годовых, то есть 1000$ вложенная сеодня будет равна 1300$ через год. Процент плавающий и меняется раз в месяц в зависимости от текущей средней температуры по палате (состояния дел). Например мы уже снизили его с 30 до 28 после того как поработали месяц и ликвиировали за это время большое количество рисков.
- Все участники получают заранее оговоренную компенсацию за работу, либо почасовая оплата либо зарплата которая может не выплачиваться (в большинстве случаев) либо выплачиваться частично. Деньги которые не выплатились становятся инвестииями участника в проект и записываются в конце месяца в Инвестиционную Ведомость
- Также в ведомость записываются все расходы на инфраструктуру и аутсорсинг и в конце месяца доли пересчитываются
- Деньги на денежные расходы вносятся добровольно но мы старемся их равномерно распределять между отцами-основателями
- Когда проект стабильно выйдет на самоокупаемость (будет покрывать затраты участников на него) будет создано АОЗТ, в котором доли будут закреплены официально и меняться не будут
- В случае прекращения сотрудничества с учасником до создания АОЗТ (впрочем и после тоже) пока мы решили что его доля остается (она плавно уменьшается так как ), но перечитав с утра Как делить доли в стартапе мне кажется что это не есть правильно и возможно стоит это доработать.
Нам эта схема очень по душе, я трачу на всю бухгалтерию 30 мин в месяц. Более того она позволила нам привлечь новых людей в проект, закрыв важные направления. И думаю привлечет еще.
Надеюсь данная схема (или ее модификация так как любая ситуация уникальна) также поможет тем кто хочет начать общее дело с друзьями.
среда, 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 сек, но даже сейчас результат приемлим.
вторник, 18 марта 2008 г.
Хостинг в Киеве (Голосуем)
Итак сервер есть, пора подумать о хостинге.
Требования:
- Collocation
- 100G/month исходящий траффик
- 2 независимых источника питани
- Хорошая маршрутизация по Украине, России и Европе
- Цена
- Надежность
- Поддержка
- Условия в серверной
Изучив предложение на рынке и почитав хороший обзор полутарогодичной давности, у нас определились финалисты, это Adamant и Colocal
Итак.
Адамант
+ Левый берег (рядом у Тараса во дворе)
+ Хорошая служба поддержки (судя по хоменету к-й мы с Тарасом юзаем)
+ Дешевый
+ Хорошая маршрутизация
- Не лучшие условия в серверной (проверим)
- Не лидер рынка
Колокол
+ Один из лидеров рнка
+ Хорошая маршрутизация
+ хорошие условия в серверной и наверное хороший суппорт
+ не такой дорогой как DG и WNet
- В 2 раза дороже
- Правый берег
На неделе хотим определиться окончательно. В принципе на хостинге экономть нельзя сильно но и переплачивать тоже не хочется. Если кто может посоветовать рассказать поболее и поновее чем описано в статье, будем признательны
Ну и голосуем рядом, не стесняемся.
Заранее спасибо
Требования:
- Collocation
- 100G/month исходящий траффик
- 2 независимых источника питани
- Хорошая маршрутизация по Украине, России и Европе
- Цена
- Надежность
- Поддержка
- Условия в серверной
Изучив предложение на рынке и почитав хороший обзор полутарогодичной давности, у нас определились финалисты, это Adamant и Colocal
Итак.
Адамант
+ Левый берег (рядом у Тараса во дворе)
+ Хорошая служба поддержки (судя по хоменету к-й мы с Тарасом юзаем)
+ Дешевый
+ Хорошая маршрутизация
- Не лучшие условия в серверной (проверим)
- Не лидер рынка
Колокол
+ Один из лидеров рнка
+ Хорошая маршрутизация
+ хорошие условия в серверной и наверное хороший суппорт
+ не такой дорогой как DG и WNet
- В 2 раза дороже
- Правый берег
На неделе хотим определиться окончательно. В принципе на хостинге экономть нельзя сильно но и переплачивать тоже не хочется. Если кто может посоветовать рассказать поболее и поновее чем описано в статье, будем признательны
Ну и голосуем рядом, не стесняемся.
Заранее спасибо
понедельник, 17 марта 2008 г.
Новый сервер (Фото)
воскресенье, 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
суббота, 15 марта 2008 г.
Блог снова работает
Приносим извинения за временную недоступность блога.
Мораль. Регитрируйте домены у топовых регистраторов, иначе в один день просто не сможете сделать ту или иную настройку.
среда, 12 марта 2008 г.
Cutting-Edge Servers (Фото)
Девелопмент сервер на PIII, если присмотреться то можно увидеть индикатор частоты. Да были такие фичи в старых корпусах, ну и куда же без Turbo режима :)
А на том что справа будет крутиться продакшен версия. Под Windows 2003 Server. Шутка, и первое и второе.
ЗЫ. В пятницу обещют привезти "реальное" железо. Будут веселые выходные так как Xen еще никто из нас не ставил.
суббота, 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:
инфраструктура,
общее,
программирование
пятница, 7 марта 2008 г.
Подписаться на:
Сообщения (Atom)