Архив рубрики: Программирование

Ага, ага

Надо запомнить этот момент дурацких волнений, потому что через N месяцев или через год будет одно из двух:

  • я столкнусь с узким местом в производительности и буду укорять себя за то, что пришлось все концептуально переделывать;

 или

  • я буду смеяться над собой, потому что проект настолько простой, что переписать его заново — сущий пустяк.

Или в performance bottleneck мы вовсе не упремся? Нет, это как-то недоамбициозно.

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

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

Защита PHP-редиректа

Как известно, открытый редирект на сайте — это нехорошо и небезопасно. Google предупреждал об этом еще в 2009 году.

Открытый редирект — это скрипт на сайте, который перенаправляет на произвольный URL, указанный в GET-параметре, например:

http://mysite.ru/redirect.php?url=http%3A%2F%2Fbadsite.ru%2F

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

Читать далее 

Chromium: пробы

Компилирую Chromium в Visual Studio Express 2012. Получится ли, пока неизвестно. Вроде бы уже больше половины.

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

Ruby on Rails: HashWithIndifferentAccess

Занятная штука в Ruby on Rails 3, которую долго раскапывал по неопытности. Когда мы в контроллере получаем params, это не хэш, а HashWithIndifferentAccess, т.е. и params[:something], и params['something'] — это одно и то же.

А вот если мы объявляем некий хэш — скажем, такой:

my_hash = { :key1 => 'val1', :key2 => 'val2' }

то обратиться к нему любым из способов уже не получится.

Чтобы создать экземпляр HashWithIndifferentAccess, можно сделать так:

my_hash = {}.with_indifferent_access

Пишут об этом классе вполне откровенно на rubyonrails.org: «This class has dubious semantics».

На ту же тему: ruby on rails: merge! ‘params’ with a hash indifferently.

Ruby on Rails: преобразование даты и времени из формата Excel (float) в DateTime

Небольшое предисловие: в начале месяца я начал искать, на чем сделать один интересный и внезапно появившийся проект, и в итоге выбрал Ruby on Rails. О выборе, кстати, ни разу не пожалел (несмотря на то, что с Ruby вообще не был знаком и многие вещи оказались сильно непривычными). Думал о Drupal, но вовремя отказался. Кто-то правильно написал, что с ним большую часть времени надо fight the functionality you don't need. Конечно, был вариант делать все просто на PHP, но тогда я слишком долго делал бы довольно простые вещи — а в RoR они уже есть.

Так что, наверное, время от времени здесь будут появляться заметки, касающиеся разработки на RoR.

Вчера понадобилось конвертировать дату и время в DateTime при импорте из Excel (использую rubyXL) — а Excel хранит дату/время (сюрприз!) в float. Делаем это так:

def excel_to_datetime(excel_float)
  return DateTime.new(1899, 12, 30) + excel_float
end

Интерфейс

Я верю в слово «интерфейс». Не важно, идет ли речь о пользовательском интерфейсе и его юзабилити, об API или о чем-то еще — в любом случае интерфейс будет отвечать на вопросы будущего. Плохой интерфейс обессмысливает великие замыслы. Хороший интерфейс решает все.

PHP, XML: изменение SimpleXMLElement с помощью XPath

Предположим, в переменной $item у нас хранится некий SimpleXMLElement, который мы хотим изменить. Самый прямолинейный способ выглядит примерно так:

$item->subitem->param->value = 'NewValue';

Однако если названия элементов содержат спецсимволы (например, двоеточие), то менять значения таким образом не получится. В таком случае можно экспортировать весь узел из SimpleXMLElement в DOMElement, затем изменить то, что нужно, с помощью XPath и импортировать назад. Пример:

$dom = new DOMDocument();
$dom_sxe = dom_import_simplexml($item);
$dom_sxe = $dom->importNode($dom_sxe, true);
$dom_sxe = $dom->appendChild($dom_sxe);
$xpath = new DOMXPath($dom);

$result = $xpath->query('Element:with:a:funky:name');
$result->item(0)->nodeValue = 'NewValue';

$item = simplexml_import_dom($dom);

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

XSL-преобразование из XML в HTML: специальные символы

Судя по Гуглу, довольно часто возникает вопрос о специальных символах — кавычках (", «, »), амперсанде (&) и других — при XSL-преобразовании из XML в HTML.

В чем суть проблемы? Предположим, у нас есть некий XML-файл, содержащий что-то вроде

<title>&amp;laquo;Доктор Хаус&amp;raquo; &amp;mdash; сколько всего сезонов снято?</title>

Здесь по обеим сторонам от доктора Хауса стоят кавычки-елочки, а после — длинное тире. Понятно, что в XML нельзя хранить знак амперсанда непосредственно, поэтому этот специальный символ кодируется в виде сущности. И вот, теперь мы хотим преобразовать это в HTML. В нашем XSL-файле есть такой фрагмент:

<xsl:value-of select="title"/>

Что мы получим? Не совсем то, что хотим: содержимое скопируется как есть, и кавычек мы не увидим. Решение в данном случае очень простое:

<xsl:value-of select="title" disable-output-escaping="yes"/>

Атрибут disable-output-escaping="yes" указывает, что специальные символы должны извлекаться «как есть», без кодирования в сущности.

Результат:

«Доктор Хаус» — сколько всего сезонов снято?

Стандартный размер шрифта, или существует ли норма DPI

Нельзя оставить в стороне и такое заболевание некоторых программистов, как вера в стандартный размер шрифта. Обычно это та порода людей, которая ставит себе 1024x768 на мониторе с разрешением 1280x1024 (тут даже соотношения сторон разные) и работает так годами, считая, что это нормально.

Откуда это берется? Обычно от сочетания двух вещей: веры в некую «норму» DPI и одновременно непонимания, что, собственно, такое DPI (а это, как известно, dots per inch — понятное дело, трудно думать о каких-то дюймах). Ко всему прочему, человек еще и не подозревает, что разрешение мониторов растет, а размер точки уменьшается. Если даже подозревает, то гонит такие мысли прочь. Купив новый монитор, он до слепоты будет программировать, не меняя святые 96 DPI.

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

Нет никакого стандарта. У пользователя может стоять и 96, и 106, и 120, и 200 DPI — ровно столько, чтобы было комфортно глазам. Если же программиста это не волнует, я бы поднимал вопрос о правильности выбора им профессии.