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

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


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

планета developers

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

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

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

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

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

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/Воля какая нибудь?

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

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

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

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

  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'. Понятно стало и почему так редко он проявлялся и не проявлялся ни разу у меня на рабочей машине - нужно было ждать, чтобы черновик был поврежден в результате крон вызова.

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

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

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

Python gotcha

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

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

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

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

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