есть расхожая шутка, что программисты вообще-то согласны и бесплатно делать то, за что им обычно платят деньги — просто потому, что им работа в удовольствие. Как всегда, это правда только отчасти: в оплачиваемой работе обычно есть куча факторов, которые это удовольствие омрачают. Начиная от совместимости с убогими браузерами и заканчивая тем, что продукт чаще всего делается для среднестатистического Гомера Симпсона, неспособного к малейшему умственному усилию. Всё это порождает бесконечные компромиссы и костыли.
и вот недавно я понял, почему мне так нравится «собирать велосипеды на коленке», писать что-то с нуля и для себя, игнорировать существующие готовые решения. В моём хобби я свободен от требований совместимости с Гомером Симпсоном и эксплорером, и от всех прочих требований тоже. Я сам определяю, что для меня важно, что мне нужно. И, естественно, неинтересное и унылое к этому не относится. В результате я имею дело только с интересным и увлекательным. Именно это и сделало программирование моим хобби ещё в девятом классе — задолго до работы.
что касается готовых решений, они обычно пытаются делать всё и для всех, поэтому тяжелы и полны тех самых компромиссов.
задумал я хранить свои фотки не в пикасе, а в другом хранилище, исключительно с целью бекапа. Фоток у меня, как выяснилось, 18 гигабайт. Для простоты буду считать, что 20 гигов. Эти 20 гигов у гугла можно купить за 5 долларов в год, иными словами за 42 цента в месяц. Собственно, так я в прошлом году и заплатил. Дёшево, но логично, целый терабайтный диск сейчас за 130 долларов можно купить, 20 гигов от него — как раз 6 долларов однократно.
первый кандидат на альтернативу гуглу — модный амазон S3. Только вот с ценами у него как-то странно: $0.140 per GB. За 20 гиг получается 2.8 доллара в месяц вместо 42 центов. Хм? Так, а вроде гугл тоже собирался своё облако клиентам открывать… и открыл, но по 13 центов за гиг в месяц, что даёт за 20 гигов 2.6 доллара вместо 42 центов. Это уже совсем непонятно…
ладно, предположим, что эти деньги за какую-то особую надёжность и прочие издержки. Пойдём тогда поищем кого-нибудь попроще и подешевле, типа банального хостинга. Что-то все они либо места мало предлагают, либо стоят больше 5 долларов в месяц. Один только плохой памяти godaddy даёт за 4.5 доллара в месяц 150 гигов, что уже больше похоже на реальность. 20 гигов от него получаются за 60 центов, но вот купить их отдельно от остальных 130 гигабайт нельзя.
как же так выходит, что своим пользователям гугл предлагает место по цене в 6+ раз меньше, чем он сам и все его конкуренты предлагают посторонним?
когда я разбирался с этой проблемой, на одном из форумов я прочитал приблизительно такие слова: «ну это же godaddy, не может быть, чтобы у них это не работало». Так вот, у них это действительно не работает уже много лет. Сейчас расскажу, что.
первые стандарты на почту не предполагали, что в заголовках письма будут не-ascii символы. Потом стандарты доработали, и их стало можно туда включать, обычно в base64-кодировке. Но из-за этой кодировки с обёртками длина заголовков увеличивается и нередко вылезает за разрешённые 75 символов. Впрочем, это не проблема: заголовки можно переносить на следующую строку. Вот так:
вернее, нельзя. На GoDaddy нельзя. Такой у них php. Заголовок с темой не должен содержать переносов строки. Они про это знают, но ничего делать не собираются, потому что боятся что-нибудь сломать. Поэтому если вы хотите с этой площадки слать посредством php письма на русском, делайте заголовки короче 25 символов. Ну или найдите нормальный хостинг.
есть, конечно, вариант не переносить строку, но это нарушает стандарт, и чёрт его знает, кому от этого перестанет приходить почта.
у наших разработчиков есть интересная особенность оформления кода внутри модуля. Если им нужно объявить функцию внутри замыкания, они не идут простым путём, и не пишут что-то вроде
function a() {
// …
}
нет, объявление функции не для них. Вместо этого они объявляют переменную в var и присваивают ей значение, вот так:
var a = function() {
// …
};
особенно смешно это сочетается с попытками использовать JSLint, который ругается на попытки использовать не только функции, но и переменные до их объявления.
но это ещё не всё! Одна из команд, видимо по привычке, использует этот стиль, но не использует JSLint. Конечно же, когда перед тобой несколько экранов кода, легко забыть, что это всё ещё «объявление переменных», и поставить точку с запятой в конце строки. Или не поставить, тут это без разницы:
var a = 123,
b = function(){};
c = b(a),
d = c + 1;
в обоих случаях эта строчка станет последней строчкой var, и все объявленные позже переменные утекут в глобальную область имён. Гип-гип-ура!
за несколько месяцев я раз десять обнаруживал и чинил такие вот «протечки». А когда на этот код всё-таки напустили JSLint, он нашёл только забытый кем-то debugger;. Вот и получилось, что для нас JSLint создал больше проблем, чем решил
вообще, по-моему, это очень иронично: JSLint заявляет своей целью отказ от «опасных» подходов написания кода, но сам в то же время заставляет использовать другой опасный подход
open google reader я разрабатывал в том числе для того, чтобы использовать его на мобильных устройствах. Экранчики там маленькие, поэтому на кнопках лучше рисовать символы, а не писать названия. К сожалению, на обеих моих нокиях нет возможности использовать многие символы Unicode, поэтому мой любимый способ вставки иконок для них не подходит.
но я не унывал: на дворе 2011 год, торжество веб-технологий, поэтому сейчас я быстро что-нибудь изображу на SVG! Ведь ещё в 2007 году я вставлял его в веб-страничку для презентации на ClientSide. Да не тут-то было: я оказался в локальном минимуме технологий между двумя пиками.
дело в том, что inline SVG прекрасно вставляется в XHTML — спасибо XML и его namespaces. Не менее прекрасно он вставляется в HTML5-странички. Однако мой частный случай не даёт мне ни одной из этих возможностей: страницы гугла — не XHTML, и юзерскрипту этого не изменить, а мобильная опера ещё не содержит HTML5-парсера, поэтому не показывает SVG в обычном HTML.
и тут я вспомнил про старшенького недалёкого братца inline SVG: вставку картинок и прочих объектов посредством data: URI. Недалёким я его считаю потому, что он использует base64, а этот формат бинарный в том смысле, что невооружённым глазом его фиг прочитаешь. Впрочем, кто сказал, что base64 обязателен? В конце концов, эта кодировка прямо указывается в URI, так что можно попробовать её и не указывать.
долго ли, коротко ли, путь ошибок привёл меня к истине: раз это называется URI, оно должно выглядеть, как URI. То есть, всяких там пробелов, угловых скобок, двоеточий и кавычек содержать не должно. Поэтому совсем красивый код SVG таким образом в страницу не вставишь. Однако некрасивый — вставишь. Имена тегов, имена и значения атрибутов остаются почти прежними, а это для меня гораздо лучше base64.
впрочем, честно говоря, я не смог отказать себе в красоте. Раз уж я делаю веб-приложение, без яваскрипта вообще ни на что не годное, то encodeURIComponent — мой друг (и не нужно работать с битами на яваскрипте). А ещё один мой друг — The Noun Project. Там можно взять «путь» для svg-картинки и вставить его в нужную обёртку. Вот так:
