Товарищи программисты! А как в насквозь интернационализированном  django получить локализованное название месяца (strftime(”%b”)) в соответствии с текущей настройкой LANGUAGE_CODE?

У меня сложилось впечатление, что там setlocale не вызывается никогда, поэтому strftime всегда выдаёт английские месяцы. Может, там есть какй-то специальный способ? Или я чего-то не заметил?

Upd: таки да, не заметил. Оказывается, django проверяет язык в следующем порядке: django_language в сессии, кука, http-заголовок Accept-Language, и только в последнюю очередь LANGUAGE_CODE. Поскольку Firefox выдаёт Accept-Language, то он и срабатывал. А из языков там, естественно, по умолчанию были только en и en-us. После добавления ru django мгновенно русифицировался.

А для получения месяца можно использовать django.utils.dateformat.format(”b”) или “M”. Не знаю, насколько это идеологически верно, потому что сам  dateformat - это реализация php’шного date(), но работает.

Вдруг кто-нибудь из читателей этот вопрос уже проходил?

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

При запуске можно указать количество тредов на блок и блоков на грид, причем это количество может быть не только скаляром, а ещё и 2- или 3-мерным вектором.

Физически треды выполняются на thread processor’ах, блоки - на мультипроцессорах (каждый мультипроцессор обычно содержит 8 thread processor’ов, один блок вычислений с плавающей точкой с двойной точностью и быструю общую память, доступную только изнутри этого мультипроцессора).

А грид выполняется на всём GPU, содержащем N мультипроцессоров (например, 10).

Собственно вопрос: если задача по сути линейная (скажем, тупой перебор ключей шифрования), и тредам вообще не нужна синхронизация и обмен данными между собой, то какими следует выбирать размеры блока и грида для достижения максимального быстродействия?

Или где про это можно почитать?

Upd: на первый взгляд логично тредов делать ровно столько, сколько может физически одновременно выполнить GPU: размер блока сделать равным количеству thread processor’ов в мультипроцессоре, а размер грида равным количеству мультипроцессоров.

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

А есть где-нибудь tutorial по программированию для CUDA?
На официальный сайт не посылайте, я там уже был, там есть отличный reference manual, programming guide и best practices guide, я их почитал, и понял, что мне для погружения нужно не это, а пошаговый вводный курс с примерами. Типа “нейрохирургия для чайников за 10 дней”. А подробности я потом изучу.

Есть такое в природе? Говорят, был курс на сайте Иллинойсского университета http://courses.ece.illinois.edu/ece498/al1/, но там уже нет. Update: оно там таки есть, спасибо alextutubalin за ссылку.

И второе. Есть ли хорошая библиотечка для парсинга TLV (tag-length-value) с несколькими уровнями вложенности для C и/или питона? Хорошая в моём понимании - это которая на кривых данных не вылетает и не выдаёт фигню, а разумно сообщает о найденных ошибках и выдаёт максимально возможное количество корректно извлечённых данных.

Читаю книжку про Django. Встретил там один интересный пример. Вопрос к профессионалам: есть ли в таком способе решения _данной конкретной задачи_ глубокий смысл, которого я не вижу, или это чисто понты для демонстрации возможностей питона? Подробности под катом, не-программистам будет неинтересно. Read the rest of this entry »

В процессе обсуждения в предыдущем посте вспомнилось мне, что под конец школы, когда я решал вопрос “кем быть” и посещал дни открытых дверей в многочисленных институтах, я задавал там казавшийся мне тогда умным и важным вопрос “А какие языки программирования у вас преподают?”

Обычно просто перечисляли пять-десять наиболее распространенных тогда языков. Но однажды (кажется, в МЭИ) мне ответили,  что конкретные языки не важны. Важно овладеть общими принципами, которым в институте и учат, а потом подстроиться под любой язык будет достаточно просто.

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

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

Кто-нибудь в курсе, чтО сейчас преподают из области языков программирования на околокомпьютерных специальностях?

Поскольку оба перловых milter-модуля  оказались непригодными к употреблению, пришлось поставить python-milter и осваивать питон. В целом он мне нравится - очень читабельный код. Из синтаксиса больше раздражает отсутствие явного обозначения  концов блоков, чем само оформление блоков отступами.

А вот отсутствие типизированных объявлений сыграло со мной злую шутку.  Написал маленький фрагмент:

  def body(self,chunk):
    self.log("body chunk")
    self.body += chunk
    return Milter.CONTINUE

и потом три часа пытался понять, почему во время выполнения оно вылетает с exception’ом “str is not callable”.

Это для веб-девелоперов, остальным неинтересно будет.

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

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

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

Вопрос: а что мешает веб-приложению, работающему в “режиме обычного пользователя” и в “режиме администратора сайта” подключаться к базе от имени разных пользователей, которым назначены разные привилегии - первому поменьше, второму побольше? Чтобы хакер, работающий с приложением в первом режиме, в принципе не имел возможности поменять “системные” данные.

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

Понятно, что это не панацея, но как дополнительная мера защиты покатит. Но я ни в одном распространенном движке для веб-приложений такого не видел. Кто-нибудь такие знает?

P.S. Про Windows Integrated Authentication в IIS я в курсе, но у него область применения довольно узкая. Если его включить, то придётся всех пользователей заводить на уровне ОС. Для публичных веб-приложений с большим количеством пользователей это неприемлемо.