Блог команды ДОУ

Перезапуск Планеты ДОУ

2009-10-25T08:11:00.003+02:00

У нас на developers небольшая реорганизация.

Вместо одно большой планеты будет несколько поменьше, тематических. И называться это теперь будет "сообщества". Каждый может создавать свое собственное сообщество, пригласить туда других участников, добавлять/удалять те ленты, которые считает нужным. Выглядеть это может так:

http://www.developers.org.ua/members/c/1-Python/

Называется это "сообщества" потому что кроме собственно ленты блогов (планеты) планируется еще дополнительная функциональность. А каждое из сообществ планируется тематическим, например Python, Embedded, Стартапы и т.п.

Инструкция по переносу своей ленты блога

Мы не будем проводить автоматический импорт существующей ленты блогов в новые сообщества. Вы можете перенести свою ленту самостоятельно. Это просто.

Откываете страницу создать сообщество. Ищите в списке слева подходящее сообщество среди уже имеющихся. Если ничего не выбрали - заполняете форму создаете свое.
Если вы выбрали уже существующее —- странице сообщества нажимаете кнопку "Присоединиться"
На странице сообщества идете по ссылке "Добавить ленту" и вписываете адрес вашей RSS/Atom ленты
Ждете. Содержимое ленты появляется в планете. На странице "Управление лентами" показываются ошибки агрегации, если были. Для админа там же есть линк "Обновить СЕЙЧАС", для немедленной загрузки всех фидов.

hg rebase

2009-08-28T10:15:00.002+03:00

Как включить новые changesets в вашу копию mercurial-репозитория? Несколько равноправных вариантов:

1. hg pull ; hg update; # затем hg merge; hg commit, если необходимо
2. hg pull -u # затем hg merge; hg commit
3. hg fetch # делает hg merge/commit сам, если необходимо
4. hg pull --rebase

До недавнего времени я использовал №3, т.к. он самый "экономный" по времени. Теперь вот перехожу на №4, т.к. он не "замусоривает" историю лишними "automatic merge" ченджсетами.

Чтобы работало rebase нужен hg 1.1 и строка "hgext.rebase =" в конфиге .hgrc.

Выглядит это так:

$ hg pull --rebase
pulling from ssh://ischenko@.../
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
saving bundle to /home/max/projects/../.hg/strip-backup/b34388790a07-temp
adding branch
adding changesets
adding manifests
adding file changes
added 3 changesets with 4 changes to 4 files
rebase completed
$ hg st

Читать больше: http://mercurial.selenic.com/wiki/RebaseProject.

прогрессивная система прав для пользователей

2009-08-17T19:18:00.001+03:00

Как работает система разграничения прав пользователей в традиционной CMS, такой как Wordpress или Django?

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

Что сделали разработчики stackoverflow.com?

Они автоматизировали процесс управления правами пользователей, используя понятие "кармы" (т.е. внутренний рейтинг пользователя). Чем выше карма пользователя, тем больше действий в системе ему доступно. Очень простая концепция.

Такая система имеет два существенных преимущества перед традиционной системой прав:

Снижаются затраты на администрирование системы, т.к. она теперь по сути само-управляемая и не требует вмешательства в 95% случаев.
Поощрение пользователей к наполнению сайта (UGC). Чем больше пользователь работает с сайтом, тем выше у него карма и автоматически - выше полномочия. Пользователи любят, когда их ценят.

Главный же недостаток - она сильно сложнее в реализации.

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

Для простых сайтов такая система - явный over-engineering. Но для сайтов посложнее я бы ее обязательно попробовал.

Тупой Django ORM

2009-07-29T09:48:00.003+03:00

...не умеет Identity Map:

>>> obj = AutoService.objects.get(id=31) # select from sto_autoservice id=31
>>> obj.carwash # select from sto_carwash where parent_id= 31
>>> obj.carwash.parent # и СНОВА select from sto_autoservice id=31

В SQLAlchemy последнего запроса не было бы, благодаря Identity Map. Да и вообще мог быть всего один запрос если сконфигурировать lazy loader.

Тупой.

работа с vendor branches в mercurial

2009-07-11T13:04:00.003+03:00

Одна вещь, которой мне не хватало после перехода на Mercurial - это vendor branches.

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

Работая с Subversion мы для этих целей использовали vendor branches, благо даже инструкции для wordpress + vendor branches нашлись. У Mercurial специального решения этой проблемы нет, разработчики советуют разное.

Опишу, к чему в итоге пришел я, может кому-то пригодится. Идеи по улучшению приветствуются.

Вкратце идея такова:

Для Wordpress (и других библиотек) создается отдельный репозиторий, site-vendor, в который загружается "чистый" код библиотек.
В рабочем репозитории хранится отдельная копия этих же библиотек, но уже с нашими локальными правками.
По мере выхода новых версий, они загружаются поверх предыдущей версии в site-vendor, проставляется тег с номером новой версии.
По тегу (версии) делается diff (патч) между двумя версиями библитеки, который и применяется к копии библиотеки в рабочем репозитории.

Смысл отдельного репозитория в том, что он позволяет сделать three-way merge, который является аналогом vendor branches из svn.

Mercurial умеет делать несколько бранчей в одном репозитории (named branches), но оно неудобное в использовании и вообще считается "advanced". Отдельный репозиторий проще.

Вот так примерно это выглядит в работе:

$ cd /path/to/site-vendor
$ rm -fr wordpress/
$ tar xzf latest.tar.gz # новая версия библиотеки
$ rm latest.tar.gz
$ hg addremove
$ hg status
$ hg ci -m "wordpress 2.8.0 upgrade"
$ hg tag wordpress-2.8.0
$ hg export -a wordpress-2.8.0 > /tmp/wp28.patch
$ cd to /path/to/wc
$ hg import /tmp/wp28.patch # ждем patch FAILED
$ hg st -un # просматриваем .rej файлы и патчим вручную
$ hg ci -m "updated to wordpress 2.8"

python tip: быстрая настройка virtualenv

2009-04-28T11:31:00.003+03:00

Во всех своих Python проектах я сейчас пользуюсь замечательным инструментом virtualenv, который позволяет создавать "приватную" копию Python специально для проекта. Таким образом решаются возможные конфликты по версиями библиотек между разными проектами.

Эта функция из моего ~/.bashrc упрощает подключение приватной копии Python для выбранного проекта. Может и вам пригодится.

function py () {
for dir in . ..; do
  if [ -d $dir/py ]; then
    source $dir/py/bin/activate;
    return;
  fi
done
echo "py dir not found, configuring virtualenv here"
which virtualenv >/dev/null && virtualenv py && source py/bin/activate
}

использование "глобальных" переменных в Python

2009-04-21T11:04:00.005+03:00

Маленький пример кода из документации Pylons:

from pylons import url
print url.current() # prints /foo/bar if this is request for /foo/bar

Чем является объект url? Переменной (глобальной) в pylons/__init__.py? А может это модуль url.py у которого есть функция current? С точки зрения Питона разница небольшая - и то и то есть ключ в каком-то словаре имен (Namespaces are one honking great idea).

Так почему тогда это так "напрягает" некоторых разработчиков?

Да-да, все мы читали про Singletons are evil и глобальные переменные это тоже "плохо". Но почему? Точнее не так - в питоне вы используете кучу глобальных переменных, которые "появляются" через ключевое слово import. E.g.: import urlllib; urllib.open(). Чем же import pylons; pylons.request.environ() хуже?

Псевдоглобальные объекты, типа pylons.request, удобны тем, что они доступны через простой и понятный интерфейс, который любой программист на Python хорошо знает (import). Простота - это хорошо.

Да, для создания таких объектов приходится использовать thread-locals, ну и что? Это implementation detail.

Какая альтернатива? Если "глобальные" переменные не используются, тогда мы должны каким-то образом "доставлять" нужные объекты в нужные участки программы. Вариант один - передавать их по стеку вызовов.

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

Плохо это тем, что т.к. абстракции типа request или database нужны много где, код в итоге загромождается и усложняется из-за необходисти "носить" с собой эти объекты, которые могут понадобится на 2-3 уровня ниже по стеку.

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

И что же у меня получается? Код без использования "глобальных" переменных - "правильнее", а с ними - "удобнее". Прямо как Pascal vs. C. ;)

Может, действительно pylons.url и прочие - зло, а я - ленивый программист? Хотя лень у нас недостатком вроде и не считается...

update: в комментариях очень познавательная информация про библиотеку Contextual, которая решает проблему глобально-доступных объектов, но не использует thread locals.

доходы

2009-04-14T13:14:00.001+03:00

Если с аудиторией все просто - она спокойно себе растет процентов по 100 в год, с доходами сложнее. Доходы от рекламы, на которых существовал сайт упали сильно и резко.

Сейчас по продажам мы вернулись аж на весну 2007 года. Радует то, что дальнейшего падения пока (уже) не наблюдается. Стабильно лежим. :)

update: динамика в долларах. в гривнах все конечно не так печально, всего в 2,5 раза где-то падение.

аудитория сайта

2009-04-09T11:57:00.003+03:00

Когда я написал в Твиттере что месячная аудитория сайта в марте составила 53К уников (+125% к марту 2008) мне ответили, что мы достигли насыщения и остается работать над тем, чтобы ходили чаще.

Интересный вопрос, на самом деле, какой у нас "потолок" по аудитории? В Украине, по разным оценкам, от 20 до 40 тыс. программистов и близких к ним специалистов. Пусть даже украинский трафик у нас 60%, это уже 25К - т.е. практически все.

Тем не менее, когда я был во вторник в Циклуме и ходил по офису, многие мне отвечали что про developers.org.ua они слышат первый раз. Вот еще картинка в тему, сравнение аудиторий по счетчику Бигмира:

Я, честно говоря, ожидал пересечения процентов на 20-30, ну уж никак не в 2-3%. Это может быть косвенным свидетельством того, что аудитория от насыщения еще далека.

А кто же эти 20-35 тыс. украинских пользователей, которые приходят на наш сайт? Не знаю. Может быть студенты. Может HR, менеджмент и другие сотрудники софтверных компаний, которые не являются программистами.

Что касается размера аудитории - вопрос остается открытым.

Expires для OpenX баннеров (nginx)

2009-03-29T19:52:00.002+03:00

Спасибо piranha, что помог с таким вот хаком:


  location /images/ {
      proxy_pass http://127.0.0.1:81/;
      expires 90d;
      internal;
  }
  if ($args ~* "contenttype=(jpeg|png|gif)$") {
      rewrite ^/(.*) /images/$1 last;
  }

Фишка в том, что nginx требует, чтобы директива Expires была привязана к location. Этот хак создает специальный "виртуальный" location, на который затем можно установить expires.

Таким образом можно кешировать медиафайлы (баннеры), которые раздает система OpenX.

nginx

2009-03-24T11:45:00.003+02:00

Настроил на сервере nginx. Он обслуживает статику и работает как фронт-прокси перед Апачем и Python (WSGI cherrypy) серверами. Попробуйте его найти в списке процессов:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                           
30386 max       20   0  150m  65m 3476 S    0  3.4   4:06.20 paster                            
30362 max       20   0  149m  63m 3468 S    0  3.4   3:59.63 paster                            
30328 max       20   0  149m  63m 3480 S    0  3.3   4:09.31 paster                            
2272 mysql     20   0  111m  37m 6180 S    8  2.0 468:48.67 mysqld                            
29822 www-data  20   0 60728  28m 5448 S    1  1.5   5:37.59 apache2                           
29823 www-data  20   0 59748  28m 6168 S    0  1.5   5:40.39 apache2                           
29821 www-data  20   0 60056  27m 5604 S   10  1.5   5:48.05 apache2                           
29832 www-data  20   0 56912  24m 5540 S    1  1.3   5:58.88 apache2                           
30839 www-data  20   0 56336  24m 5632 S    0  1.3   5:38.87 apache2                           
29820 www-data  20   0 56048  24m 5540 S    2  1.3   5:41.11 apache2                           
29989 www-data  20   0 55556  23m 5636 S    6  1.2   5:34.76 apache2                           
29824 www-data  20   0 55272  23m 5744 S    0  1.2   5:51.84 apache2                           
2107 www-data  20   0 55736  23m 5084 S    0  1.2   4:27.81 apache2                           
12197 www-data  20   0 56320  23m 4272 S    8  1.2   2:10.17 apache2                           
29756 root      20   0 42772  12m 7172 S    0  0.7   0:01.03 apache2                           
...
...
21407 postfix   20   0  7928 3528 2748 S    0  0.2   0:00.01 smtpd                             
21697 max       20   0 11172 1956 1268 R    0  0.1   0:00.00 sshd                              
29829 www-data  20   0  5336 1904  768 S    0  0.1   0:18.29 nginx                             
29830 www-data  20   0  5336 1864  768 S    0  0.1   0:21.25 nginx                             
29828 www-data  20   0  5228 1828  768 S    0  0.1   0:16.01 nginx                             
29827 www-data  20   0  5232 1820  768 S    0  0.1   0:18.83 nginx

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

Проблемы с Feedburner/Google миграцией

2009-02-10T15:14:00.006+02:00

Feedburner объявил, что до 28 февраля все виды должны быть перенесены на сервера Гугл. Как по мне, не очень user friendly ход, но что делать - перенесли.

В итоге сломались обновления в главном фиде сайта, http://www.developers.org.ua/feed/.

Пробовал "Resync Now". Отвечает "Read time out". Чтение логов апача показало, что FeedBurner не докачивает фид полностью, выкачивая примерно 65-70 Кб:

74.125.44.136 - - [10/Feb/2009:14:59:36 +0200]
"GET /feed/ HTTP/1.0" 200 65831 "-" "FeedBurner/1.0 (http://www.FeedBurner.com)"

Тестовая закачка на десктоп прошла без проблем:

$ curl -A "FeedBurner" -o z.xml http://www.developers.org.ua/feed/
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                            Dload  Upload   Total   Spent    Left  Speed
100  248k    0  248k    0     0  20307      0 --:--:--  0:00:12 --:--:-- 17465

Единственное объяснение - гугл резко "прикрутил" timeout и обрывает связь например на 5 секунде.

FeedMedic молчит.

update: похоже фидбернер просто получает gzip-версию фида, поэтому и размер такой.

$ curl  --compressed -A "FeedBurner" -o z.xml http://www.developers.org.ua/feed/
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                             Dload  Upload   Total   Spent    Left  Speed
100 65849    0 65849    0     0   4447      0 --:--:--  0:00:14 --:--:-- 14999

update2: похоже дело в медленной "отдаче" фида. Я сохранил содержимое фида в статический файл и заставил фидбернер взять этот файл. Resync прошел успешно и фид обновился. Теперь бы еще понять каким образом эту проблему решить. Ограничить кол-во записей блога в фиде?

update3: дело было в тормозах Вордпресса. Генерация фида с localhost занимала 13 секунд. После того, как в админке ВП уменьшили количество записей фида с 20 до 10 время генерации уменьшилось до 6 секунд. Теперь фид нормально индексируется google.

В поисках спроса

2009-02-05T10:16:00.001+02:00

Снизили цену на лого на Главной в три раза, с 2750 грн до 850 грн.

Пытаемся найти цену, по которой сейчас покупают рекламу. Я конечно надеюсь, что 850 грн это "слишком дешево", но нужно знать точно. Потому что если ее не покупают по 850 грн значит можно больше не париться с девелоперз и искать новую работу. И плохие новости лучше узнать побыстрее, fail early.

twitter

2009-01-29T12:29:00.000+02:00

Читайте новости на твиттере, twitter.com/devua.

тизер: новые зарплатные отчеты

2008-12-22T14:18:00.002+02:00

Вот над чем я сейчас работаю:

На мой очень субъективный взгляд новые отчеты будут куда более информативны. Заценить бета-версию можно здесь.

планета developers

2008-12-16T14:28:00.003+02:00

Думаю над новой версией агрегатора блогов. Главное, что хочется сделать - какую-то классификацию по темам. Читать про флеш мне например совсем неинтересно, а кого-то не интересует питон например или записи на английском.

Вот только совсем не ясно, как такую классификацию делать. Bayesian sort? ;)

А еще у каждого участника будет ре-публикация своих фидов, примерно так.

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

Сайт "немножко лежит"?

2008-12-15T14:50:00.002+02:00

update dec 16: похоже сайт был недоступен пользователям сети Воля, причем не всем. Сейчас вроде бы проблема решилась.

Это график доступа из сети Воля.

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

Проверил через host-tracker.com -- похоже какие-то проблемы все-таки есть:

Received responses: 31 Ok 3 Fail		Average:	1.57 sec	102.08
Charlotte	Ok	164367	0.81 sec	199.35	94.76.195.6	Persian Dreams
Charlotte	Ok	164367	0.81 sec	199.35	94.76.195.6	Persian Dreams
Kiev, Ukraine	Ошибка HTTP:Http_client.No_reply		40.07 sec		94.76.195.6	HOSTED
Kiev, Ukraine	Ошибка HTTP:Http_client.No_reply		40.10 sec		94.76.195.6	HostBizUA.com
Kiev, Ukraine	Ошибка HTTP:Http_client.No_reply		40.07 sec		94.76.195.6	ProstoHosting.NET
Philadelphia, PA, US	Ok	164367	0.70 sec	229.65	94.76.195.6	Bluetreehost
Montreal, QC, Canada	Ok	164367	2.21 sec	72.53	94.76.195.6	HostIran Networks
Atlanta, GA, US	Ok	164367	0.83 sec	192.38	94.76.195.6	NetLevel Network
Houston, TX, US	Ok	164367	0.84 sec	192.12	94.76.195.6	PremiumReseller
East Lansing, MI, US	Ok	164367	2.42 sec	66.32	94.76.195.6	NIMHOST
Frankfurt, Germany	Ok	164367	0.23 sec	686.55	94.76.195.6	QBEM
Kiev	Ok	164367	0.56 sec	286.32	94.76.195.6	FES Hosting.

Непонятно только что с этой хренью делать? Может это UA-IX/Воля какая нибудь?

История одного бага

2008-12-13T17:21:00.002+02:00

Началось все несколько месяцев назад. Один из клиентов сайта сообщил, что не смог опубликовать свою вакансию в нашем разделе Вакансии. (Для клиентов я написал специальную админку, где они самостоятельно редактируют и публикуют свои вакансии).

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

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


  def publish_jobpost(self, jobpost):
      # ...
      jobpost.published_date = now
      jobpost.status = 'publish'
      jobpost.expires_on = expires_on
      client.jb_credit -= jobpost.price

Вообще-то, в коде есть еще одно место, где jobad.status меняется на 'publish'. У клиента есть возможность снять вакансию с показа. В этом случае он может затем передумать и снова "включить" ее.


  def toggle_vacancy(self, id):
      if c.vacancy.status == 'offline':
          status = 'publish'
      else:
          status = 'offline'

Проблема только в том, что поставить статус offline можно только из status=='publish'. Т.е. возвращаемся к исходной проблеме.

Я честно говоря, поломал голову и бросил. Работы хватает, а глюк этот встречался только у некоторых клиентов (где-то в 10% случаев).

Но затем глюк повторился еще раз. В следующем месяце - еще пару раз. Пришлось заняться багой снова. Леше Маслову пришла в голову светлая мысль - написать триггер, который будет проверять, что при insert/update даты установлены правильно если status='publish'.

Триггер написали и забыли. И вот наконец вчера это случилось. Триггер упал, что повлекло за собой exception, который я получил по почте, вместе с traceback'ом. И что же было в трейсбеке:


Module doupy.controllers.sc:333 in toggle_vacancy
       else:
               c.vacancy.status = status

Как всегда, случилось "невозможное"! Очевидно у записи был статус offline. Но как? И тут я вспомнил про маааленький крон-скриптик, который "снимает" с показа старые вакансии, у которых уже давно истек срок "годности". Вот скриптик:


mysql -B ... <<EOF
update jobad_posts set post_status = 'offline' \
where expires_on < date_add(now(), interval - 2 month);
EOF

И, понятно, update успешно срабатывал для черновиков, у которых expires_on == '0'. Понятно стало и почему так редко он проявлялся и не проявлялся ни разу у меня на рабочей машине - нужно было ждать, чтобы черновик был поврежден в результате крон вызова.

Раздел Планета на Главную?

2008-12-06T13:52:00.001+02:00

Как вы думаете, стоит ли перенести содержимое страницы Планета на главную? Выглядеть это может например так:

http://www.developers.org.ua/?planet=1

Python gotcha

2008-12-02T14:52:00.002+02:00

Сегодня делал второй (пятый) выпуск рассылки. Начиная с четвертого выпуска для рассылок используется свой код на Python. И вот сегодня несколько человек написали, что они не могут прочесть письмо т.к. одни кракозябры.

Я конечно тестировал код перед рассылкой и у меня в гмейл все показывалось нормально. Выяснился забавный баг. Письмо у меня собирается примерно так:


   msgText = MIMEText(html_version.encode('utf8'), 'html', 'utf8')

Здесь html_version - это unicode-строка, которую я кодирую в UTF, а последний аргумент 'utf8' указывает MIME-кодировку полученного объекта. Теперь начинается интересное. Кодировки MIME с названием "utf8" не существует, а существует "utf-8" (с дефисом). На питоне можно писать и так и эдак, разницы никакой, а вот для внешнего мира это оказалось существенно.

Непонятно, правда, почему email lib не может делать эту подстановку за пользователя. Зафайлил баг в трекер.

Делаю профили.. затягивает

2008-11-29T20:56:00.008+02:00

Наконец-то пишу функционал, которым пользуюсь сам. Это прет неподеццки.

Что уже сделано:

публичный адрес странички профиля, напр. http://www.developers.org.ua/m/max/
загрузка фоток (любого размера, при загрузке масштабируются до 200 пикселей по ширине), пример
загрузка аватарок пользователей с gravatar.com, пример
ре-публикация ленты твиттера, если пользователь указал свой twitter id, пример
публичная страничка Участники, пока правда малофункциональная
поиск участника по имени
форма "Написать пользователю" - ее реально используют, а одни хитрые друзья пытались через нее своими вакансиями спамить :)
грамотный SEO для страниц участников, пример1, пример2

Что хочу сделать:

управление емейл подписками (кнопка Отписаться)
функция "Друзья", для построения сети контактов :)
ре-публикация рсс-ленты пользователя, например личного блога, который нельзя поставить в Планету
рейтинг пользователей: раздача +/- другим участникам
мини-аватарки 24х24, как на Хабре
загрузка аваторок из гмейл, через XMPP
загрузка резюме в формате doc/html/pdf (?)
функция "Группы"
функция "ищу работу": галочка в профиле, страничка со списоком пользователей, которые ищут работу

А что хочется вам?

Разработка оживает

2008-11-11T09:46:00.005+02:00

Кризис кризисом, но разработка на developers.org.ua понемногу оживает. На этой неделе на сайте появились:

новый Календарь (без фреймов)
облако тегов в Архиве блога
новый алгоритм показа Похожие статьи в Блоге
поддержка поля Город в Вакансиях

И наконец самое главное: зачатки "социальной сети", публичные странички профилей пользователей. Вот например Сергей Волошин, А4 и я.

Спасибо Леше Маслову за активное участие в разработке. Pair programming - это оказывается увлекательное занятие.

Django, дубль два

2008-11-03T16:48:00.003+02:00

В мае вместе с Соловьевым мы пробовали сделать интеграцию с Django, тогда эти ничем хорошим не закончилось. Хочу попробовать еще раз, на этот раз подойти к проблеме с другой стороны. Хочу вклеить существующий legacy код на пилонс в новое Django приложение.

Зачем? Напишу, если интеграция будет успешной. :)

О достоверности базы зарплат

2008-11-03T10:27:00.003+02:00

Хороший вопрос:

Возможен ли вариант что группа людей (скажем человек 50), договорилась и заполнила анкеты демпинговыми данными (например сказали что они получают 100 долл и не больше, или наоборот поставили 3000). Тогда ведь актуальность информации теряется.

Можете ли вы гарантировать что накрутчики не влияют на рейтинг и он не выходит за рамки погрешности проценов в 5?

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

Сейчас все анкеты просматриваются модератором и при необходимости отклоняются. Вот последние анкеты (3 - Киев):


+-----------+-----------------+----------------+----------+----------+
| survey_id | submission_date | monthly_salary | status   | location |
+-----------+-----------------+----------------+----------+----------+
|      6160 | 2008-11-03      |           1200 | approved |        3 |
|      6159 | 2008-11-03      |           3000 |          |        3 |
|      6155 | 2008-11-02      |           1700 | approved |        3 |
|      6154 | 2008-11-02      |           2700 | approved |        3 |
|      6153 | 2008-11-02      |           2000 | approved |        3 |
|      6150 | 2008-11-01      |            700 | approved |        3 |
|      6147 | 2008-11-01      |           6000 |          |        3 |
|      6146 | 2008-11-01      |           1250 | approved |        3 |
|      6143 | 2008-11-01      |           1200 | approved |        3 |
|      6142 | 2008-11-01      |           1320 | approved |        3 |
|      6141 | 2008-11-01      |           1300 | approved |        3 |
|      6140 | 2008-11-01      |           1500 | approved |        3 |
|      6133 | 2008-11-01      |           1850 | approved |        3 |
+-----------+-----------------+----------------+----------+----------+

Плюс график динамики зарплат на главной рассчитывается по упрощенной схеме.

Но в целом, да, это проблема. Т.е. накруток (аномальных всплесков активности) пока замечено не было, но не могу гарантировать что их не было в прошлом или что мы сможем отразить такую атаку в будущем.

Но это не значит, что сделать ничего нельзя. Обещаю заняться системой анти-флуда как только запустим новую Базу Компаний. Есть несколько идей, что можно сделать, но говорить подробно не хочу. ;)

Ваши идеи и помощь с реализацией принимаются с благодарностью.

Оптимизируем продажи

2008-10-31T09:11:00.003+02:00

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

--------------------------------------------------

Уважаемые клиенты developers.org.ua,

Спасибо вам за то, что работаете с нами. У меня есть для вас хорошие новости. :)

Экономическая ситуация в стране и мире сейчас явно ухудшается. В условиях финасовой нестабильности очевидно что первыми под нож идут рекламные и маркетинговые бюджеты.

Мы хотим, чтобы и в этим условиях площадка developers.org.ua оставалась эффективной и выгодной для вас, поэтому мы пересмотрели наш прайс-лист. Некоторые позиции подешевели в разы (например лого в Вакансиях). Плюс появилась возможность покупать баннеры не на месяц, а на тысячи показов. При покупке логотипа на Главной или в Вакансиях вы получаете бесплатные текстовые вакансии.

Новые цены см. на сайте, http://www.developers.org.ua/pages/advertising/

Очень рассчитываем, что даже с урезанными/замороженными бюджетами наша площадка останется привлекательной. Ведь жизнь продолжается и "то, что нас не убивает, делает нас сильнее". Пережившие кризис получат отличную фору перед менее удачливыми/расторопными конкурентами.