Prototype JS е страхотна библиотека за работа с JavaScript, документирана перфектно и с богата селекция от ефекти, благодарение на script.aculo.us.

За един от проектите си имах нужда от layout manager, който да разполага обекти в определено пространство с възможно най-малка загуба на място. Търсейки такова решение разбрах две неща: първо, читав layout manager за Prototype JS няма и , второ, има готово решение на търсения от мен алгоритъм в лицето на отличния jQuery Masonry на David DeSandro.

Проблемът в моя случай беше, че за този проект ползвах Prototype и jQuery-плъгина не ме устройваше. Решението беше да си отделя един ден и да port-на jQuery Masonry към Prototype framework. Еквивалент на първото демо от сайта на David можете да намерите на Masonry Prototype страницата. От нея можете и да свалите и plugin-а, в случай че ви трябва.

Prototype версията напълно покрива basic демото, както и това с блога, за Infinite Scroll Example-a пича ползва third-party jQuery plugin, затова не съм го тествал…

Всички, които следим малко по-внимателно web-а през последните няколко месеца, нямаше как да не забележим нарастващата вълна от Drupal-базирани сайтове. За добро или лошо, бизнесът с open source, особено извън татковината, винаги е имал нужда от солидна доза аргументация.

Със сигурност една от най-важните причини Drupal да започне такава сериозна експанзия, че чак Microsoft да започнат кампания против него в Google AdWords е http://www.whitehouse.gov/. От това по-добра реклама – здраве му кажи.

За самият Drupal са ми малко думите – страхотен, повтарям страхотен Content Management System, който е в състояние да сложи в малкия си джоб дузина комерсиални конкуренти. С изчерпателната си документация, и огромната общност от разработчици зад гърба си, Drupal със сигурност е в пъти по-добро решение от всякаквите самоделки, налични като “решения” в повечето от родните ни web компании.

Всъщност, сега се сещам за една молба към web разработчиците: ако имате задачка пред себе си и не сте с много умения в писането на PHP код, дайте един шанс на Drupal, ще спестите адски много време на хората, които ще fix-ват грешките ви по-късно. В случай, че имате опит и още не сте преминали на утвърдени практики като MVC (Zend Framework, CodeIgniter или Symphony) – направете го, няма да съжалявате.

Не е истина какво прави конкуренцията – след като Microsoft добутаха H264/AAC в Silverlight 3, както и smooth streaming, пуснаха и някакъв 3D support, и в един момент Adobe започнаха да изглеждат леко смешни с 10-тата версия на Flash Player, която (спорно) май остана само с по-добрия рендеринг на шрифтовете и междуплатформената си поддръжка. И, според мен, ако е имало нещо, което отново да върне Adobe там, където им е мястото, то това е само и единствено Flex-платформата. Ясно е, че в областта на дизайна Adobe са ненадминати. Също толкова ясно е, че Microsoft са напред в областта на development-a.

За да надделее, някой от двата “претендента” трябва да стъпи в областта на популярност на другия. Аз лично, освен че съм супер пристрастен по ред причини, с чиста съвест ще заложа на Adobe. Първо, защото MS така и не успяха да направят читав дизайнерски инструмент вече повече от 20 години и с всеки наченат и захвърлен експеримент в тази насока търпят само критики. Второ, защото Adobe знаят как да поддържат общност, и се опитват да се вслушват в гласа на потребителската си база. От години следя http://labs.adobe.com не само заради интересните неща там, но и заради възможността да видиш зараждането на технология и дискусиите по оформянето й.

Преди около година и нещо, когато започнаха първите дискусии по Flex 4 имаше сериозна дискусия накъде да се фокусира следващата версия. Контроли вече имаше (за разлика от Silverlight), имаше и горе-долу ясна концепция за типа RIA които ще бъдат разработвани и тогавашният модел работеше някак си. Не мога да кажа успешно, но поне беше форма на development която вършеше работа за поставянето на основата. После се появи някакъв чешит, който бил бачкал в Microsoft и даде идеята да се напише инструмент, който да помогне на дизайнерите да влязат по-надълбоко във Flex. Последиците от това днес са налични като версия beta на продукта Adobe Flash Catalyst. Базиран на Eclipse, Flash Catalyst поне от видеото, налично на сайта на Adobe ме кара да мисля за напълно нов подход към Flash разработката. А факта, че нещото, което преди носеше името Flash Builder вече се казва Adobe Flash Builder само потвърждава мнението ми.

Излиза, че Adobe са стъпили на солидна среда за разработка, каквато е Eclipse и с типичната си находчивост изглежда ще успеят отново да бутнат Flash технологията с една стъпка напред, Което е екстра, аз лично, колкото и да мразя банерите се кефя неистово на нещата в The FWA.

Последният месец при мен мина изцяло в разработка на сайта, който можете да видите, щраквайки върху линка по-горе. По-доволен няма как да съм, понеже това е първият PHP проект, в който не ползвам собствените си модули за администрация на съдържание, а вместо тях се спрях на един проект с отворен код, който ме интересува от известно време насам – Drupal

Всъщност, това, което е по-интересно е, че реално проблемите с разработката на сайта бяха доста по-малко от колкото очаквах. Единствената реална трудност беше мигрирането на съдържанието от стария блог на клиента (базиран на WordPress) към собствената блог-система на Dupal, но наличният модул за импорт на съдържанието от WP работи отлично.

Дребни проблеми можете да имате само, ако import-вате огромно количество съдържание, и те са свързани не толкова с Drupal, колкото с time limit ограничението за изпълнение на PHP скриптове в Apache. Иначе CMS-ът е с отлична документация и архитектура и съм сигурен, че Mandate няма да са единственият случай, в който работя с него. Писането на custom модули е максимално улеснено и не помня кога за последно съм се радвал като малко дете на резултатите от работа с тривиални операции.

Освен това имах и малко време да помисля над система за заместване на шрфитове, подобна на sIFR, но с по-малко баласт, и резултата определено ме обнадеждава – с малко помощ от jQuery системата използва един 14k .swf файл за всички заглавия и подзаглавия в сайта.

Иначе обичайните благодарности за всички замесени са задължителни, а резултатът, поне на мен, ми харесва доста.

За един от проектите наскоро имахме интересен казус – част от upload-натите файлове в Media Library-то на Sitecore трябваше да са достъпни за сваляне само от регистрирани потребители. Неприятното беше, че всъщност съдържанието на всеки от Item-ите в Media Library вече е достъпно чрез proxy, и едно от решенията беше писане на разширение за pipeline обектите. Другото решение беше написване на собствено proxy, което със сигурност ми харесва повече.

Подчертавам дебело, че това е първият ми ASP.NET модул изобщо, така че бъдете снизходителни. Решението (с махнати подробностите по проверка на достъпа) изглежда така:

Response.Clear();
Sitecore.Data.Database database =
Sitecore.Configuration.Factory.GetDatabase("master");
Sitecore.Data.Items.MediaItem MediaFile = 
database.GetItem(ItemID);
 
Stream fileStream = MediaFile.GetMediaStream();
 
Response.ContentType = MediaFile.MimeType;
Response.AppendHeader("Content-Length", 
fileStream.Length.ToString());
Response.AppendHeader("Content-Disposition", 
"attachment; filename="+MediaFile.Name+"."+MediaFile.Extension);
 
byte[] fileContent = BufferStream(fileStream,0);
Response.BinaryWrite(fileContent);

BufferSream е собствен метод, който load-ва съдържанието на MediaStream-а преди да го представи на потребителя. Ето и какво представлява, всъщност:

public static byte[] BufferStream(Stream stream,int initialLength)
{
  if (initialLength < 1) { initialLength = 32768; }
  byte[] buffer = new byte[initialLength];
  int read=0;
  int chunk;
  while ((chunk = stream.Read(buffer,read,buffer.Length-read))>0)
  {
    read += chunk;
    if (read == buffer.Length)
    {
      int nextByte = stream.ReadByte();
      if (nextByte==-1) { return buffer; }
      byte[] newBuffer = new byte[buffer.Length*2];
      Array.Copy(buffer, newBuffer, buffer.Length);
      newBuffer[read]=(byte)nextByte;
      buffer = newBuffer;
      read++;
    }
  }
  byte[] ret = new byte[read];
  Array.Copy(buffer, ret, read);
  return ret;
}

Е, време беше и аз да се включа в модата с преправянето на сайтове за мобилни телефони, и в този ред на мисли едва ли щях да имам по-добро опитно поле от блога си. В крайна сметка редизайна, заедно с имплементацията, отне по-малко от ден, а тестовете успешно минаха мобилната версия на Internet Explorer, webkit-базираният Iris и, разбира се, Opera Mobile. Търси се тестер с iPhone, който само да потвърди дали сайта изглежда като на screenshot-ите.

Иначе да взема да похваля поне веднъж Microsoft – мобилната им версия на Windows е доста по-обмислена от desktop еквивалента си и с малко GNU софтуер почти става за ползване. Естествено, има и мизерии – за да спра приложение трябва да цъкам през 5 менюта, ама Task Manager-и за Windows Mobile дал господ…

При писането на мобилната версия на сайта гледах максимално да се придържам до стандартния й еквивалент като цветова схема, изхвърлих ненужни неща като архивите по месеци, запазих линковете към архивите по категории и добавих опция за преход към стандартната версия (за тези, който ползват Opera Mobile). Разстоянието между заглавията на отделните постове нарочно е оставено по-голямо – открих, че така по-малко се объркваш при целене на линковете с пръсти вместо със stylus-a.

Надявам се цялото упражнение да се окаже ползено. За предложения или критики – използвайте коментарите…

Вчера, точно на 3 годишнината от създаването си, проекта jQuery официално обяви появата на новата версия на популярната си JavaScript библиотека. Вероятно изобщо нямаше да съм толкова въодушевен, ако все още ползвах комбинацията Prototype + Scriptaculous и бях прочел тези Release Notes – подобрение на производителността в почти всяка област на цената на 18k (minified).

Не че Prototype е лоша библиотека – дори напротив, но 126k са си тежест при първоначално зареждане. Освен това съм забелязал, че с jQuery дори custom скриптовете и plugin-ите се получават по-компактни като код. Единственият проблем досега беше липсата на event delegation, но с появата на 1.3 и този проблем отпадна. И като капак на всичко – изцяло новата система за селектиране, Sizzle, освен малка (само 3k, minified) е и уникално бърза.

Хубавинките не свършват дотук и от jQuery твърдят:

Right now we’re working with Prototype, Dojo, Yahoo UI, MochiKit, and TinyMCE (and many others) on Sizzle, honing it to perfection.

Това, при положение че не остане само на хартия, означава, че на разработчиците няма да им се налага да се нагаждат към всяко API, поне по отношение на селекторите.

Разбира се, като при всяка нова версия ще трябва да измине малко време преди по-сериозните plugin-и да излязат с официална поддръжка на 1.3, но поне от това което тествах в офиса, миграцията няма да е толкова трудна. Пък и пренаписването на разни неща с цел подобряване на производителността винаги си е струвало усилията

P. S.: Можете да link-вате директно 1.3 версията от Google-сървърите за да свалите още повече времето за зареждане. Намира се тук:

http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js

Пичовете в Mozilla Labs изглежда вършат доста работа в последните месеци и резултатите не закъсняват. Ubiquity for Firefox е убийствено як plug-in, с помощта на който престоят в Internet се превръща в още по-приятно изживяване. Ако още не сте гледали видеото над този текст – направете го, няма да съжалявате.

Хубавото на цялата далаверка е, че е разширяема, а пък и всеки с малко познания по CSS може да създаде нов или да преправи някой от съществуващите skin-ове. Комадите използват чист AJAX за връзка със сайтовете и, ако developer-ите са толкова въодушевени от Ubiquity колкото съм и аз, е въпрос на време да видим команди за интеграция с Facebook, или още по-интензивно използване на Yahoo Pipes, например.

Съществуващите команди дори сега ми спестяват огромно количество време при проверка на детайлите по разни API-та, така че за мен този инструмент върши повече от чудесна работа. Блогвам го, защото не вярвам да има developer, който да не иска документацията на PHP, Rails или jQuery да му е “на един select разстояние”…

Продължавам на вълна Sitecore. За един от проектите си имам нужда от flash replacement за някои от заглавията в страниците. За да не се получи объркване от използването на sIFR, решихме да използваме custom система за замяна на текста. За embedding на flash се спрях на SWFObject 2 – много лека и полезна библиотека, доста по-елегантна от метода на Adobe.

Проблемът дойде от комуникацията между Flash и приложението – знаем, че flashVars използва формат, подобен на query string в браузърите – всяка двойка променлива-стойност е разделена със знак амперсанд. SWFObject 2 позволява известна гъвкавост, позволявайки да кодирате flashVars като JavaScript object, но в процеса на embed-ване на flash-клипчето въпросния обект се кодира до познатия ни query string формат, което прави проблемно използването на амперсанд като част от стойността на дадена променлива – например ако искаме да предадем string от сорта на Terms & Conditions с flashVars ще трябва да кодираме амперсанд-а в URI формат, където ще изглежда като Terms %26 Conditions.

За да направя това директно в rendering-a, използвах custom XSL template. Ето как изглежда той, мисля че ще е полезен на всеки, който се сблъсква с подобен проблем:

<xsl:template match="*" mode="main">
  <xsl:variable name="flashEscapedTitle">
    <xsl:call-template name="flashEscape">
      <xsl:with-param name="text" select="sc:fld('title',.)" />
    </xsl:call-template>
  </xsl:variable>
  <xsl:value-of select="$flashEscapedTitle" />
</xsl:template>
 
<xsl:template name="flashEscape">
  <xsl:param name="text" select="."/>
  <xsl:choose>
    <xsl:when test="contains($text, '&#38;')">
      <xsl:value-of
      select="substring-before($text, '&#38;')"/><!--
      -->%26<xsl:call-template name="flashEscape">
      <xsl:with-param name="text"
      select="substring-after($text,'&#38;')"/>
      </xsl:call-template>
    </xsl:when>
    <xsl:otherwise>
      <xsl:value-of select="$text"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

Някъде в средата на август имах възможност да посетя Лондон – град за който бях чувал все хубави неща. Вярно, престоят ми беше прекалено кратък – само 4 дни, при това служебно – но не съжалявам за нито един момент прекаран там. Този пост, обаче, не е за Лондон, а за причината да бъда там всъщност – трябваше да посетя курс за сертифициране като Sitecore Developer (Level 1). Та да се похваля – от близо 2 месеца съм сертифициран Sitecore Developer

Sitecore e .NET базирано enterprise CMS решение от което всеки developer има какво да научи. За съжаление 2-та дена (толкова трае курса, заедно с изпита след това), макар и интензивно наситени с лекции и практически упражнения могат да дадат на всеки начинаещ само повърхностен поглед върху системата. Преди въпросния курс бях писал съвсем малко C# и се чувствах като тотален новак. Слава богу, основната част от работата с CMS-a се състои в работа с XSL като основен език за Rendering-ите и малко ASP.NET за Layout-a и се учи бързо.

Вчера се сблъсках с един дребен проблем, част от всеки динамичен сайт – странирането на резултатите. Решението реших да прехвърля върху XSL, вместо да пиша Extension, и изглежда не съм сбъркал, понеже не губя почти нищо от гледна точка на производителност. Да, Extension-a ще е по-бърз, най-малкото защото ще е компилиран до .dll, но така или иначе XSL сравняването с position() се случва при кеширан XML и е достатъчно оптимизирано в parser-а.

В .aspx файла сложих следното:

<script type="cs" runat="server">
void Page_Load(object sender, System.EventArgs e) 
{
  int Page = 0;
  if (Request["page"] != null && Request["page"].Length != 0)
  {
    bool success = 
    Int32.TryParse(Request["page"].ToString(), out Page);
    if (success != true)
    {
      Page = 0;
    }
  }
  ArticlesPagination.Parameters="page="+Page.ToString();
} 
</script>

Rendering-a за pagination-a изглежда така в .aspx Layout-а:

<div class="paging">
    <sc:XslFile runat="server"
    renderingid="{the-rendering-id}"
    path="/xsl/ArticlesPagination.xslt" id="ArticlesPagination">
    </sc:XslFile>
</div>

ArticlesPagination.xsl съдържа следното (пропуснал съм служебните декларации за namespace, както и някои променливи, които нямат отношение към странирането):

<xsl:template match="*" mode="main">
<xsl:variable name="total"
select="count($sc_currentitem/item[@template='article'])-1" />
<xsl:variable name="per_page" select="3" />
<xsl:variable name="pages"
select="ceiling($total div $per_page)"/>
<xsl:variable name="start" select="($page * $per_page)+1" />
<xsl:variable name="end" select="($start + $per_page)+1" />
<xsl:variable name="path" select="sc:path(.)" />
<xsl:choose>
  <xsl:when test="number($page)-1 &gt;= 0">
    <a class="prev" href="{$path}?page={number($page)-1}">
    Previous</a>
  </xsl:when>
  <xsl:otherwise>
    <!-- display something else -->
  </xsl:otherwise>
</xsl:choose>
<xsl:choose>
  <xsl:when test="number($pages) = 1">
    <span>Page&#160;<strong>
    <xsl:value-of select="number($page)+1"/>&#160;of&#160;
    <xsl:value-of select="number($pages)"/></strong></span>
  </xsl:when>
  <xsl:otherwise>
    <xsl:call-template name="loopPages">
      <xsl:with-param name="goUntil" select="$pages"/>
      <xsl:with-param name="currentPage"
      select="number($page)+1"/>
      <xsl:with-param name="startAt" select="1"/>
      <xsl:with-param name="path" select="$path"/>
    </xsl:call-template>
  </xsl:otherwise>
</xsl:choose>
<xsl:choose>
  <xsl:when test="number($page)+1 &lt; number($pages)">
    <a class="next" href="{$path}?page={number($page)+1}">
    Next</a>
  </xsl:when>
  <xsl:otherwise>
    <!-- display something else -->
  </xsl:otherwise>
</xsl:choose>
</xsl:template>
 
<xsl:template name="loopPages">
  <xsl:param name="startAt" select="0" />
  <xsl:param name="goUntil" select="0" />
  <xsl:param name="currentPage" select="0" />
  <xsl:param name="path" />
 
  <xsl:if test="number($startAt) &lt; number($goUntil)+1">
    <xsl:choose>
      <xsl:when test="number($startAt) = number($currentPage)">
        <a class="current-page"
        href="{$path}?page={number($currentPage)-1}">
        <xsl:value-of select="$startAt"/></a>
      </xsl:when>
      <xsl:otherwise>
        <a href="{$path}?page={number($startAt)-1}">
        <xsl:value-of select="$startAt"/></a>
      </xsl:otherwise>
    </xsl:choose>
    <xsl:call-template name="loopPages">
      <xsl:with-param name="startAt" select="$startAt + 1"/>
      <xsl:with-param name="goUntil" select="$goUntil"/>
      <xsl:with-param name="currentPage" select="$currentPage"/>
      <xsl:with-param name="path" select="$path"/>
    </xsl:call-template>
  </xsl:if>
</xsl:template>

Нека обаче вземем за пример следната табилца:

mysql> DESCRIBE posts;
+------------+--------------+------+-----+---------+-------------+
| Field      | Type         | Null | Key | Default | Extra       |
+------------+--------------+------+-----+---------+-------------+
| id         | int(11)      | NO   | PRI | NULL    | auto_inc... |
| title      | varchar(255) | YES  |     | NULL    |             |
| body       | text         | YES  |     | NULL    |             |
| published  | tinyint(1)   | YES  |     | NULL    |             |
| created_at | datetime     | YES  |     | NULL    |             |
| updated_at | datetime     | YES  |     | NULL    |             |
+------------+--------------+------+-----+---------+-------------+
6 rows in set (0.00 sec)

Стандартно форматът за търсене на първият запис в таблицата Posts, който има заглавие, съвпадащо с “rails” би трябвало да изглежда по този начин:

@condition = "rails"
@post = Post.find (:first,
        :conditions=>["title LIKE ?", "%#{@condition}%"]
)

Това е перфектен вариант когато търсите срещане за даден стринг само в определена колона от БД. Ако обаче искате да намерите първият записи в таблицата Posts, който съдържа “rails” и в заглавието и в тялото си, ще трябва да модифицирате горният пример по следния начин:

@condition = "rails"
@post = Post.find (:first,
        :conditions=>["title LIKE ? AND body LIKE ?",
        "%#{@condition}%", "%#{@condition}%"]
)

Работещо, но грозно решение, което ме накара да поровя малко из документацията. В крайна сметка стигнах до следното, поне според мен, много по-красиво и практично справяне с проблема:

@condition = "rails"
@post = Post.find (:first,
        :conditions=>["title LIKE :what AND body LIKE :what",
        {:what=>"%#{@condition}%"}]
)

Sends the file by streaming it 4096 bytes at a time. This way the whole file doesn‘t need to be read into memory at once. This makes it feasible to send even large files

Да, ама не. Ако ползвате mongrel (което правят 90% от rails developer-ите), файлът изобщо не се разбива на парчета от по 4096 bytes, а се качва целия в паметта.

Алтернтивен вариант е да използвате опцията send_data, но пък тя изисква buffer с данни, за да изпълни нормално работата си. Ето пример как можете да изпратите файл с помощта на send_data:

def download
  send_data IO.read('path/to.file'), :filename=>'somename.ext'
end

Третият, и поне според мен най-чист, метод е да оставите цялата работа по връщането на файловете на web-сървъра, който ползвате като frontend.

В случай, че ползвате Apache или Lighttpd, методът за изпращане на файл до потребителя ще трябва да изглежда така:

def download
  response.headers['X-Sendfile'] = 'path/to.file';
  render :nothing => true
end

Ако изборът ви е паднал върху Nginx – ето вариант на метода, с който ще постигнете същото:

def download
  response.headers['X-Accel-Redirect'] = 'path/to.file';
  render :nothing => true
end

При мен download URL-a не работеше по подразбиране, връщайки ActiveRecord::RecordNotFound, защото контролера който ползвах отразяваше REST ресурс. За да го накарам да работи във файла /config/routes.rb се наложи да заменя следния ред:

map.resources :download_demo

със следното:

map.resources :download_demo, :collection => {:download => :get}

С появата на Flex 3, потребителите на GNU/Linux се докоснаха до света на RIA, поне според начина по който виждат нещата хората от Adobe. Една досадна подробност беше отсъствието на AIR (Adobe Integrated Runtime), което ограничаваше Flex-потребителите само до web-базирани разработки. Макар и alpha версия, AIR вече е наличен от сайта labs.adobe.com и за Linux, след като преди месец дебютира на платформите Windows и Mac OS.

Въпреки, че е все още alpha стадий, runtime-а предлага доста добри възможности, лесна инсталация и солидна документация, а липсващата функционалност ще бъде добавена в следващите няколко месеца. Приложения, написани за AIR вече се намират на много места из мрежата, а възможността освен Flex за създаване на приложения да се използва и HTML/JavaScript дава на framework-a отлична гъвкавост.

Изглежда, битката с Microsoft е накарала мениджмънта на Adobe да вземе някои доста интересни решения. Редом с обявяването на alpha-та, от press release-а на фирмата обявиха присъединяване към Linux Foundation, а като капак на всичко части от продукта LifeCycle бяха пуснати като Open Source под името BlazeDS. Междувременно Flex Builder за Linux стигна до версия Alpha 3, осигурявайки поддръжка на AIR, a според главния софтуерен архитект на Cold Fusion, продукта ще последва съдбата на Flex, отваряйки кода си.

Хубаво нещо е конкуренцията, особено когато от цялата работа печеливш се оказва крайният потребител

Встрани от подробностите около патентите, Adobe са свършили повече от чудесна работа по SDK-то и, както изглежда, хвърлят големи усилия за налагането му на пазара. Алтернативи, разбира се, има и като най-сериозен конкурент на Flex се очертава технологията Silverlight на Microsoft, която, благодарение на Windows Update вече е част от доста клиентски PC-та. Flash Player (на който е базирано SDK-то), обаче, е утвърден от години, има солидна база потребители и като технология намира все повече поддръжници от страна на дизайнерите, а благодарение на Flex – и от страна на разработчиците.

Новостите са много, повечето от тях са добре дошли и като цяло платформата започва да придобива зрялост, а с интегрирането на технологията Adobe® AIR™ се очаква Flex да намери място и сред средите за разработка на standalone приложения. Като че ли един от най-сериозните проблеми на Flash Player беше липсата на синхронизацията между адресното пространство на Flash Player и това на web-браузърите – т.е. можехте да заредите цял Flash-базиран сайт, но нямаше възможност да bookmark-нете точно определена част от сайта (поне не без допълнителни библиотеки). От версия 3, Flex вече предлага опция, наречена Deep Linking, благодарение на която този проблем може да бъде решен. Макар за момента да липсва добра интеграция с Opera, въпрос на време е разработчиците на браузъра да ликвидират проблема.

От технологична гледна точка, Persistent Framework Caching е може би най-ценната новост във Flex 3 и благодарение на поддръжката на runtime-shared-libraries вече е възможно сериозно намаляване на размера на приложенията. Освен това сред новостите има и “жива” поддръжка на локализации, интеграция с JavaScript/AJAX, дребни допълнения към компонентите и бог знае още колко неща, които не са видими от пръв поглед.

Дано framework-a намери подобаващ прием, Google вече заложиха на него за някои компоненти в Analytics, а в showcase-a на Flex.org могат да се намерят интересни решения, които, поне според мен, обещават интересно развитие на web-a в бъдеще…

В никакъв случай 696-те грешки при валидиране на началната страница (в момента на писане на постинга) не са основният критерий за оформяне на мнението ми. Сайтът е сред фаворитите ми, “минавам” през него поне вднъж дневно и го използвам като източник на доста полезна информация, така че предполагам реакцията ми следва да се приема по-скоро като фенска, отколкото професионална.

Въпреки това очевадните грешки няма как да минат незабелязано. Комбинацията сиво/бяло/зелено може и да е сполучлива, но резултатът в случая е нагледен пример как, залагайки на успешна формула, можеш да получиш кофти резултат. Като цяло от несполучливия дизайн единствената “полза” е, че шарените банери се натрапват отвратително много за сметка на съдържанието. Не че и в предишния дизайн нямаше недомислици, но загубата на място определено беше в пъти по-малка. В новият дизайн вероятно дизайнерите са имали предвид типографските правила за whitespace, но добрата идея няма нищо общо с крайния резултат.

Нямам нищо против иновациите, но смяната на визията с лош заместител по правило е един от най-бързите начини да загубиш потребителска база. За съжаление нямам достъп до старият му вариант, иначе съм любопитен да разбера дали и колко точно трафик е спестен, благодарение на нововъведенията. И за да не излезе поста много хейтърски – в цялото начинание все пак има и нещо позитивно – използването на изцяло CSS-базиран layout винаги е добра идея и с повечко писане някои от недостатъците могат да бъдат премахнати, без да се налага пипане по кода.

Надявам се само да не съм единствения, който не е доволен от новият дизайн, иначе ще трябва да започна да се притеснявам…