Ссылки о веб-разработке за ноябрь 2008

Информационная безопасность / Новая хеш-функция MD6

MD6 — алгоритм хеширования переменной разрядности, разработанный профессором Рональдом Ривестом из Массачусетского Технологического Института в сентябре 2008 года. Предназначен для создания «отпечатков» или дайджестов сообщений произвольной длины. Предлагается на смену менее совершенному MD5. По заявлению авторов, алгоритм устойчив к дифференциальному криптоанализу. MD6 не обладает достаточной стойкостью к коллизиям первого рода. Используется для проверки подлинности опубликованных сообщений, путем сравнения дайджеста сообщения с опубликованным. Эту операцию называют «проверка хеша» (hashcheck).
Читать дальше →

The Other Half of "Artists Ship"

Индуктивный пользовательский интерфейс

Цель IUI как нового способа проектирования программ — уменьшить объем размышлений
пользователей, нужных для успешного переходамежду частями продукта и использования
его функций. Слово inductive («индуктивный») происходит от глагола induce, что
означает — идти, следуя влиянию или убеждению.


Прочитал про 'Индуктивный пользовательский интерфейс'. Вот оказывается, чем руководствовались при разработке интерфейса в WinXP, в особенности "Панели Управления".

Главную ппосылку в этих "индуктивных" рассуждения, я бы сформулировал так: - "Если ты не можешь этому дать конкретное название, значит это тебе не нужно". IMHO, Эта фраза ключевая не только при разработке интерфейса, но и при проектировании иерархии объектов. Но почему-то выводы в этих двух случаях делаются прямо противоположные. В интерфейсах предлагается реализовывать все ad-hoc, а при разработке программы, неназваемая сущность (ну или называемая как IMyForm, И_ЭЛЕМЕНТЫ_СРОК, AllInOneUtilsContainer), это повод задуматься о лучшей абстракции.

PHP / Споры о шаблонизаторах: троллинг или умные мысли?

причины родились в том, что в топах посвященных обзорам конкретных шаблонизаторов спорят на обобщенную тему:
Обзор шаблонизатора Quicky: Производительность и Гибкость.
MACRO — гибкий PHP шаблонизатор, с человеческим «лицом»
раследование проведено на основе данных, полученных в топе:
HolyWar: Шаблонизаторы. Нужны ли они? состоятельны ли они? Форум.
результаты расследования под катом
Читать дальше →

Ржач месяца это, конечно, отзыв Яндексом докладчиков с Клиенттеха после перехода Рогожина в Рамблер.

JavaScript: преобразование в integer

Читая исходники плагина autocomplete для jQuery (документация описывает не всю функциональность плагина), нашёл замечательный небольшой паттерн. Обычный короткий способ преобразовать объект другого типа в число — прибавить к нему ноль или умножить на 1. Но есть способ лучше, оцените:
var extraParams = {
    timestamp: +new Date()
}
Просто добавляем знак перед объектом. Просто и изящно.
комментировать тут

Почитал все что написали про КлиентТех, спасибо всем кто высказался, для себя лично много нового и интересного извлек из текстов.

C FAIL

Встретился код в сторонней проприетарной библиотеке алгоритмов для промышленных контроллеров. Код на Си:


if (X1<X2<X3<X4<X5<X6<X7<X8<X9<X10<X11<X12<X13<X14<X15<X16)


Где X1 и т.д. - переменные типа float.

Компиляция этой строчки компиляторами gcc 3.4.6 и 3.2.2 занимает 3 минуты на 3ГГц Pentium 4.

Если увеличить количество сравниваемых переменных до 20 - компилятор выжирает всю доступную память вместо со свопом и падает от недостатка памяти.

gcc 4.1.2 на этом же коде отрабатывает без вопросов.

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

Genetic A/B Testing with JavaScript

I've long been interested in the concept of A/B testing (Also called split testing). It's a simple concept that should sit will with most mathematically-inclined types: You have a baseline interface in which you adjust a single variable, at random, for each user that visits your application. After a given amount of time you should be able to see if certain variables affect how your users behave (either negatively or positively).

A product was recently released called SnapAds which allows its users (advertisers) to permute different variations of an ad and display different versions to users, based upon how well they perform over time.

But that's not what I was interested in, specifically (even though it is a cool idea). The team that created this also created another product a while back that never saw a full release: Genetify. Genetify provides developers with a JavaScript library for doing any number of A/B tests on a site (tweaking CSS, JavaScript, or HTML elements) all trained over time using a Genetic algorithm backend.

This means that no matter how many different A/B tests you have on a page the genetic algorithm will adapt to the input (users visiting the page and hopefully achieving some pre-defined goal) and slowly show a more-optimal page layout to the user.

Genetify provides a demo on their site showing the basics of how it works along with a simple text tutorial.

To get started with Genetify you will need to include the library in the head of your page along with a couple CSS rules.

<script src="genetify.js"></script>
<style>
  .v { display: none; }
  .genetify_disabled { display: none !important; }
  .genetify_enabled { display: block !important; }
</style>

And then before the closing body tag on your site include the following:

<script>genetify.vary();</script>

Here are some examples of different ways in which a page layout can be changed using Genetify.

HTML Elements / CSS Classes

The easiest technique is one which allows you to simply toggle HTML using some inline CSS classes.

<div class="sentence">One way of saying something</div>           
<div class="sentence v anotherway">Another way of saying something</div>

The first class specified ends up becoming the name of one of the "genes" which is used to train the genetic algorithm. Thus if the user completes a specified goal while the "anotherway" element is toggled then the algorithm is trained to recognize that showing the "anotherway" element might be more desirable and will show it more over time.

A goal can be recorded by specifying a goal name and a weight for completing the goal. You'll need to call a JavaScript method that records the completion of a goal wherever in your code you think the goal was completed (such as the user signing up for something).

genetify.record.goal('signup', 100);

The next-most-common technique will likely be that of toggling CSS rules. Multiple rules are defined using a similar name but with the addition of a simple alphabetical name on the end which is used for categorization.

#navbar { color: red; }
#navbar_vA { color: green; }
#navbar_vB { color: blue; }

Note that you can have any number of rules - you aren't limited to the traditional "A/B" style of testing where there's only two options - specifying any number of rules will continue to yield results.

Finally Genetify provides the developer with the ability to toggle JavaScript variables.

highlight = function(elem){
  elem.style.borderColor = 'green';
}
highlight_vRed = function(elem){
  elem.style.borderColor = 'red';
}

I'm less excited about this particular technique - it's kind of clumsy to clutter the global namespace with variables and to expect a changed output. I think a better technique would be to toggle a property value within the genetify object and check how that's changed, instead.

Perhaps the biggest question that surrounds Genetify, right now, is over its longevity and openness. It seems like the project has taken the backburner in favor of the team's other project, SnapAds (and understandably so - since that has an obvious revenue stream). Although a recent comment by its creator, over at Hacker News has fueled speculation: He's looking for interest in the possibility of open sourcing the codebase for anyone to use.

Right now Genetify is two components:

  1. The JavaScript frontend that does the A/B rotation of site components. Currently this file is only available on the Genetify demo site as a doubly-packed file (using Dean Edwards' Packer). It wasn't too hard to un-pack it and run it through a JavaScript beautifier in order to get some sane output. Of course that doesn't make it any more "open source" - just developer-readable. You can now tweak the code to communicate with the server of your choosing, instead.
  2. The Genetify backend is unclear at this point. It appears to only exist on the Genetify servers and it's not clear if the backend will accept input from non-Genetify domains. If the intent of the team holds true then should probably see this code become available soon.

I'm already quite excited about this utility. I think it shows a lot of promise for developers who want to roll their own A/B testing solutions. I hope the team comes through and releases an Open Source solution that developers can really start to hack on it.

Сайт tuxmobil.org отметил появление 8-тысячного руководства по установке Linux на ноутбуки

Алгебра интерфейсов

Современное состояние дел в области проектирования и реализации интерфейсов пользователя чем-то напоминает
ситукцию с созданием баз данных во времена CODASYL
Куча всяческих эвристик, куча guidelines, использование избыточно мощных парадигм (OOP).
Даже работы Раскина - это не более чем набор эвристик, применимых в довольно частном случае.

Как результат - интерфейсы получаются громоздки, неудобные, тормозные, ресурсоемкие.

Все мы помним что случилось в области базостроения потом - пришли Кодд и Дейт и создали реляционную алгебру.
Сразу стало значительно понятнее, несмотря на то, что распространение полноценных, разработанных на основе этой теории языков QBE и SQL заняло десятилетия. И до сих пор достаточно популярны всякие mySQL-и, которые в полном объеме этого не умеют. Но во всяком случае, в мозгах у разработчиков некоторое прояснение наступило.

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

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

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

Очевидно, что существуют какие-то классы эквивалентности интерфейсов. Например обычное диалоговое окно с кучей контролов, tabbed dialog и wizard могут предоставлять ровно ту же самую информацию и позволять те же самые варианты принятия решений.

А вот в каких случаях удобнее то представление, а в каких - другое - никаких правил пока нет. Можно сравнить эту ситуацию, скажем с с нормальными формами в РСУБД. Там во всех учебниках написано, когда надо делать нормализацию, а когда - денормальизацию. Хотя в любой конкретной ситуации решение все равно остается за проектировщиком, но он хотя бы знает к чему приведет то или другое решение.

Our international approach to search

In previous posts in this series, you have read about the challenges of building a world-class search engine. Our goal is to make Google’s search be relevant to all people, regardless of their language or country. As my colleague Amit Singhal described, we use statistical data as the basis for making sweeping algorithmic changes. Many of these changes can be rolled out across all languages we support, but in some cases the unique characteristics of each language require some algorithmic considerations and tuning. And to make things really interesting, there are cases where the same language is different across countries. Obvious examples are "color" in the U.S. vs. "colour" in the U.K., or "camião" in Portugal vs. "caminhão" in Brazil.

My name is Daphne Dembo, and my focus is improving Google's international search. This is a tough challenge, since Google search is used in many countries and languages where our engineers have little personal knowledge. Initially, the international search improvements were done by Search Quality engineers who were passionate about their languages and countries: Lina from Sweden improved our parsing of compound words in German and Swedish; Dimitra from Greece introduced diacritical support; Ishai from Israel worked on transliteration corrections for Hebrew and Arabic; Trystan from Australia created methods for identifying local search results and ranking them together with foreign ones from the same language; Alex, a bilingual Ukrainian and Russian, introduced morphological understanding of these languages. As the importance of our international search grew, we solicited help from Googlers in all our offices. Finally, we are leveraging an international network of search specialists who help us understand search within the unique combination of their language and country.

Our first step in providing search support for a language is to train our language model on a large collection of documents in that language. This ensures that our language model is more precise and comprehensive — for example, it incorporates names, idioms, colloquial usage, and newly coined words not often found in static dictionaries. For instance, we recently started identifying Swahili, and used pages such as this one for the Parliament of Tanzania to train our system with the language's nuances. Having a trained language model helps to categorize documents during crawling and indexing of the web and to parse the user's query. Once this stage was complete, we launched Swahili search in countries such as Tanzania and Kenya, enabling local searches for the "Dar es Salaam stock exchange" [Soko la hisa dar es salaam], and "cure for Malaria" [Tiba ya malaria]. (As always, we are using square brackets to denote a search query. For example, you can search for "soccer" in Hamburg, Germany by clicking on [fußball in hamburg]).

We learn some things from our users, so as people start using our search engine, we can improve the way we rank in that language. Here are few examples:
In addition to these semantic factors, Google does even more to parse documents and queries. Understanding the details of language usage in a country is important. Notation of acronyms is different across languages: In Hebrew it is double quotes before the last (left-most) character, as in "prime minister" [רה"מ]; in Thai — a dot at the end of the word, as in police station [สน. ]; while in the U.S. — dots after each character, as in [I.B.M.]. Chinese users quote works of art with a "《", as in: [《手机》剧情], and denote dates with a "日", as in: [2006年1月13日].

Beyond the linguistic elements of a language, we consider how people enter a query. For example, some languages that do not have Latin scripts require keyboards with dual alphanumeric keys. The user can switch between language input modes by typing special keystrokes. In case the user forgets to type this sequence, the queries end up being gibberish. You can see correct handling of these mistakes in Arabic ([hgsuv] corrected to [السعر]) and ([حقثسهيثىفهشم ثممثؤفهخىس ] corrected to [presidential elections]), Hebrew ([vdrk, kuyu] corrected to [הגרלת לוטו]), and Cyrillic ([rehc ljkffhf] corrected to [курс доллара]).

Another way of avoiding the inconvenience of switching keyboard modes is by typing the phonetic sounds of the query in Latin characters. Recreating the correct query in the target language isn't trivial, since there might be many possibilities. We can see several such examples in which we suggest the same query in the intended language for Russian ([biskvitnyi rulet] to [бисквитный рулет]), "movies" in Chinese ([dianying] to [电影]), and "Bank of Attica" in Greek [trapeza attikhs] returns good results for "Τράπεζα Αττικής". Users of 8 Indic languages (such as Hindi, Gujarati, Telugu) can type the phonetic sound of the query, and choose the words in Hindi script:


Ease of typing and reading is also influenced by the language used. Since every Chinese word requires several keystrokes on a standard keyboard, we provide category browsing by Images and related searches so that people don't need to type as much. Similarly, we are now launching Google Suggest, or real-time completion of queries, in many languages.

So far I described how we improve the quality of search in a language. However, there is a strong effect of the location of the user, even if it is only approximated to the country, since in many cases local content is more relevant than global information. For example, searching for Spanish Yellow Pages [Páginas Amarillas] will result in several documents of global interest and several local results in Peru, Mexico, and Spain. Similar to that, searching for [Côte d'Or] in France will return results for that region, whereas searches in Belgium will return results about the chocolate maker.

Note that the display of information should conform to the standards in that country, so we display "," as a decimal notation for Croatian users who want to know how many millimeters are in an inch [inč u milimetrima], or for Italian users who are interested in currency exchange rates [50 euro in dollari]. Similarly, temperatures in Norway [Været i Oslo] will be displayed in Celsius, while in the U.S. — in Fahrenheit [weather Boston].

If everything else fails, we provide cross-language translations based upon Google's translation technology described in this blog post. We will translate your query to English, search English documents on the web, and translate the returned results from English back into the original query language. For example, Japanese users who are interested in viewing Halloween illustrations (Halloween is a holiday which originated in Ireland) can search for [ハロウィン イラスト]. You can then request a Japanese translation of the English pages (at the bottom of the page), which will bring up the translation page in the screenshot below. Similarly, Korean users can search for the latest on Harry Potter [해리 포터], and Arabic readers can search for the opening of the Sydney Opera house [افتتاح دار الاوبرا في سيدني]. (Click on the image to see a larger version.)



All in all, Google Search is being actively developed for more than 100 languages, in 150+ countries, with dozens of improvements launched each month. So far I've covered the basics of how international search works, but this is just the surface of all the international work we do. There are many other interesting topics that impact international markets like usability, homepage and results page layout, and connectivity. An understanding of real cultural and human factors is essential to creating a search engine that resonates with the people who use it. (Click on the image to see a larger version.)



(Update: Replaced example in the 4th bullet point.)

Posted by Daphne Dembo, Engineering Director

Tables: The Next Evolution in CSS Layout

Shared by arty
используйте display: table-row и т.п. для браузеров, а для ие всё равно придётся подсовывать отдельные стили

Today, a talented web designer must be a modern-day MacGyver—that 80s TV action hero who could turn a rubber band and three tin cans into a serviceable aircraft. Turning the average site design mockup into a living, breathing slice of HTML and CSS is a comparably delicate miracle, which must be accomplished using whatever makeshift tools happen to be lying around in current browsers.

That’s exactly why so many professional designers still choose to use HTML tables for layout. How can we expect beginners to adopt CSS for layout when it takes someone with the resourcefulness (and snappy dress sense) of MacGyver to fully understand the techniques involved?

Thanks to the imminent release of Internet Explorer 8, CSS layout is about to become something anyone can learn to do—no chewing gum or makeshift explosives required.

HTML Tables Are a 90% Solution

HTML tables produce the grid-based layouts we want to achieve with relative ease, but the price is that users with screen readers and other technologies that rely on semantic markup have a hard time making sense of the page.

As standards-conscious designers, we have convinced ourselves that the benefits of semantically meaningful markup are worth the added hassle of using CSS for layout. Not everyone shares this conviction. Whenever I write about some new CSS layout technique, at least half the feedback I get boils down to “You’re kidding yourself if you think designers will use that instead of HTML tables.”

The reason this is such a contentious issue is that tables correspond so well to the way designers tend to think of pages: a semi-flexible grid that defines rectangular areas that make up the page. If you want three columns in a row, you just put three table cell tags inside a table row tag:

<table> <tbody> <tr> <td>column 1</td> <td>column 2</td> <td>column 3</td> </tr> </tbody>
</table>

The premise of using CSS for layout is sound: replace the HTML tables with semantically meaningful markup, plus semantically invisible divs where needed:

<div id="container"> <div> <div id="menu">column 1</div> <div id="content">column 2</div> <div id="sidebar">column 3</div> </div>
</div>

The problem is the CSS code required to lay out this new markup. CSS was not initially designed to support blocks arranged horizontally across the page; consequently, we have had to get creative with the tools at our disposal. Current best practice requires the designer to master subtle interactions like overlapping floats, negative margins, and other black magic to achieve a simple multi-column layout. You don’t so much describe the layout you want as gradually build up a combination of positioning constraints that almost miraculously result in the layout you’re after. You couldn’t come up with a more convoluted way of expressing page layout if you tried!

If CSS layout code were as easy to write as HTML tables, making the leap would be a no-brainer; designers would flock to CSS willingly. Instead, we must drag them kicking and screaming, because the tools that CSS provides are not suited to the layout tasks we want to accomplish.

What if CSS provided a set of tools that applied to practical layout tasks as obviously as HTML tables do?

Bring the Tables to CSS

CSS actually includes a feature that works just like HTML tables: CSS tables. Using the CSS display property, you can instruct the browser to format any HTML element as if it were a table. For visual display purposes the element behaves like a table, but the element retains its non-table semantics for screen readers and other tools that look at the HTML markup.

In short, CSS tables let you perform table-based layout without misusing HTML tables!

The CSS to lay out our collection of divs above as a row of three table cells is very straightforward:

#container { display: table; border-collapse: collapse; table-layout: fixed;
}
#container > div { display: table-row;
}
#container > div > div { display: table-cell;
}

We can then set the widths of each of our columns, again with very straightforward code:

#menu { width: 200px;
}
#content { width: 66%;
}
#sidebar { width: 33%;
}

From this foundation, applying borders and backgrounds to these columns is trivial. Check out this sample page, and the screenshot below for a fully-rendered example. Now this is the kind of page layout code that designers can embrace with confidence!

a simple page design featuring a three-column layout

Compared with HTML tables, CSS tables have only one notable weakness: CSS does not allow for table cells to span rows or columns the way they can in HTML tables (with the rowspan and colspan attributes). As it turns out, however, this is a relatively uncommon requirement for page layouts; and in the few cases where spans are required, there are ways to fake them with CSS tables.

Can You Start Now?

So, why isn’t everyone already using CSS tables for page layout? In an all-too-familiar twist, we have Internet Explorer to blame. CSS tables are supported in every major browser except Internet Explorer. However, the good news is that Internet Explorer 8 will have full support for CSS tables upon its release, setting the stage for CSS tables to become the preferred tool for page layout on the web!

The question you must ask yourself is, “When can I start making the switch?” The answer may depend on the type of site you work on.

If you work professionally on a mainstream website, chances are you will be expected to keep your site working on Internet Explorer 6 and 7 for some time to come. Since neither of these browsers support CSS tables, it may seem on the surface that you’re out of luck. In fact, CSS tables may still make your job easier.

Because CSS tables are so much easier to work with than previous CSS layout techniques, you may find it worthwhile to implement your design first using CSS tables, and then using older CSS techniques for IE6 and IE7. You can use conditional comments to insert your IE6/IE7 style sheet, while all other browsers will only get the table-based layout. This approach does mean you have to implement your layout twice, but it saves you the considerable headache of getting the older techniques from working both in Internet Explorer and in other browsers.

While you’re at it, you may find opportunities to simplify the layout slightly in the IE6/IE7 version of the site, and save yourself a lot of work. Something like not insisting that a column’s background color extend all the way to the bottom of the page can radically simplify the code, for example.

If you work on a site with a more technical audience, or owned by a more progressively-minded organization, you might have even more wiggle room. In this case, you should explore the possibility of providing a simplified page layout for IE6 and IE7. The sample page included with this article is written this way. In the screenshots below, you can see the page displayed in IE8 (beta 2) and IE6.

A simplified, two-column layout is visible in the IE6 window.

If you find yourself having to defend this approach to a client, tell them how much of your time (and their money) will be saved by simplifying the layout a little in outdated browsers.

Even if you can’t justify working with CSS tables in your day job just yet, it’s worth finding excuses to use them where you can. When Internet Explorer 5.5 made CSS layout across browsers possible for the first time, Jeffrey Zeldman wrote To Hell With Bad Browsers, leading the call for designers to adopt CSS layout:

“For years, the goal of a Web that was accessible to all looked more like an opium dream than reality. Then, in the year 2000, Microsoft, Netscape, and Opera began delivering the goods. At last we can repay their efforts by using these standards in our sites. We encourage others to do the same.”

The response to this call to action was gradual, but effective. Initially, web designers began experimenting with CSS layout on their personal sites, before testing the waters with some of their riskier side projects. Major mainstream sites like ESPN began making the switch only a couple of years later.

With Internet Explorer 8 on the verge of release, the stage is set for another wave of change to sweep the Web, however gradually. Now is the time to ensure you’re on the leading edge, not paddling to catch up!

Everything You Know About CSS Is Wrong

Perhaps the most important benefit of CSS tables is that it finally makes page layout with CSS easy to learn. Finally, we can justifiably expect anyone designing a web site today to do it the right way, with a proper separation of content (HTML) and presentation (CSS).

In my just-released book, Everything You Know About CSS Is Wrong (available from Amazon: Everything You Know About CSS is Wrong!), Rachel Andrew of The Web Standards Project and I explore the realities of page layout with CSS tables, the new possibilities they open up, and how to work around limitations like the lack of row and column spans. A brisk read, it provides a valuable glimpse into the next evolution in CSS layout on the web.

[Q] Про Газпром-Медию и RuTube: «Собственно, сами интернетчики тут не нужны» // Интернет и телевизор

«

Мнение Владимира Вагина: Интернет и ТВ — это два абсолютно разных бизнес-стиля. Ребята, которые это создавали, ориентировались на нормы интернета. Если в RuTube приходит профессиональный телеконтент, то тут начинают работать совершенно другие принципы и нормы прибыли. Этим должны заниматься телевизионщики. У ТНТ уже есть богатая библиотека телепередач и кино, нужна лишь площадка, где они адаптируют его к интернету. Собственно, сами интернетчики тут не нужны.

Зачем «Газпром-медиа» RuTube и что он будет с ним делать, Частный корреспондент

»

А теперь мы посмотрим, как, разогнав команду успешного стартапа, наши телевизионщики будут строить российский Hulu.com поверх контента из медиатек ТНТ и НТВ. Интересно, как пойдет — с точки зрения телевидения оба канала успешны, оба как бы обладают неплохими сайтами, но стать какими-то заметными онлайн-источниками контента у них не вышло.

Ждать, что «вдруг из подворотни выйдет великан» не приходится, а новой команде придётся определиться с тем, как решать главные вопросы — реклама, пользователи, обратная связь и интеграция всего этого в стройную и непротиворечивую систему. Пока, если судить как раз по Hulu, ТВ приходится очень непросто с онлайн-рекламой за пределами видео (т.е. не в виде рекламных роликов), а увидеть вменяемые сообщества на медийных сайтах нам ещё только предстоит. Достаточно сравнить официальную ленту канала ТНТ на Рутьюбе с его почти одиннадцатью тысячами роликов, и всего лишь одного сериала «Фринж», которому от рода 8 серий, а в форуме 203 топика и 140 рецензий. (К вопросу о блеске UGC: у верхней рецензии там славный заголовок «One of the best shoes....»)

C другой стороны, понятно, что прибыль можно получить, даже если использовать Рутьюб как промо-площадку для всевозможной продукции, от новых фильмов на ТВ и дивидисков, идущих в продажу, до шарфов и носков с символикой сериалов. Или продавать мобильные версии роликов Камеди Клаб по два доллара — уже монетизация. Правда, уровень немного другой. Ларёчный.

* * *

Мне это крайне любопытно ещё и потому, что Афиша, запуская свои тв и видеопроекты, очевидно, метила в ту же нишу — но то ли ресурсов, то ли воли на полноценную реализацию телепортала не хватило, и только-только сейчас начинают появляться отголоски этого давно задуманного «интеграционного» движения, когда каждый объект становится самостоятельным сайтом, с полным досье, архивами, обсуждениями, рецензиями и клипами, независимо от того, концерт это, фильм, сериал или клуб. Поэтому, помня эти долгосрочные планы Афиши, я и наблюдаю за тем, как развивается тема поддержки телевидения в России.

 
 

Информационная безопасность / TLS/SSL изнутри, а также почему нельзя настроить HTTPS для виртуальных хостов.

TLS (что есть Transport Layer Security), он же ранее известный как SSL (Secure Sockets Layer), на данный момент является стандартом де-факто для защиты протоколов транспортного уровня от различных методов вмешательства извне. Мало кто его не использует, но не уверен что все хорошо представляют себе, как оно на самом деле работает и какими возможностями обладает, кроме банального «как же, оно ведь шифрует канал между клиентом и сервером».

Читать дальше →

Ejacs: a JavaScript interpreter for Emacs

Shared by arty
why JavaScript is a better language than Emacs Lisp
So! I have all these cool things I want to write about, but I broke my thumbnail. Can you tell that's a long story?

See, this summer I got excited about playing guitar again. I usually switch between all-guitar and all-piano every other year or so. This summer I dusted off the guitars and learned a bunch of pieces, and even composed one. I was prepping for — among other things — a

Читал — не читал средствами CSS

парсер — лох

вместо самого кода писатели на хабре начали вставлять в тексты картинки с этим самым кодом

интересно, что нам это говорит о сайте? : )

иронично, кстати, что и программистов хабра, и писателей подводит тяга к красоте

Расстановка мягких переносов

LFS: Logic File System. $ mplayer -z '/lfs/ext:mp3/genre:Disco|genre:Electro/year:<70/.ext/'*.mp3

JAVA / Перевод Sun увольняет от 15% до 18% персонала

Sun
© Yahoo! News

Sun Microsystems Inc. объявила сегодня, что вследствие кризиса увольняет от 5000 до 6000 человек.
В результате ожидается сокращение издержек от 700 до 800 миллионов долларов ежегодно.

График акций

Сама компания будет разделена на три подразделения: Application Platform Software, Systems Platforms и Cloud Computing and Developer Platforms.

How Google Docs prints

Web browsers haven't focused much on printing. The web is so much nicer on the screen than on a flake of dead trees..

Hence, web browsers are not very good at printing. For example, they have the annoying habit of splattering URLs and dates across the footer of a page. (Some versions of Opera are known to be so insistent on including a URL that they grab a random URL from a recently seen page and add it to the footer even when you print an E-mail. There is not unlikely a story about somebody becoming really, really embarassed by that bug on some blog somewhere in the universe..)

So what do you do if you write an online word processor and want your users to be able to print beautifully? Here is what Google Docs does when you click their "Print" button:

  1. Saves your document to the server
  2. Converts it on the server - on the fly - from HTML to PDF
  3. Creates a hidden Adobe Acrobat plugin instance inside the editor tab
  4. Load the newly converted PDF into the plugin
  5. Triggers the Acrobat print dialog

Wow. An impressive hack.

"Oh what a tangled web we weave, When first we practice workarounds"..

самый полезный микроформат

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

я считаю, что одно из самых часто выполняемых в интернете действий — это переход по ссылке на следующую в списке страницу. Без страниц никуда. Раньше «пейджеры» почти все были строго цифровыми, потом начали распространяться дополнительные надписи «следующая» и «предыдущая», и стало удобнее. Но можно сделать ещё лучше!

многие страницы не умещаются на один экран, и их приходится прокручивать. Мне было бы жалко потерять веру в человечество, поэтому об использовании для этой цели скроллбара даже не буду говорить. Остаётся не так много способов: колесо мыши, «pan» мышью (обычно после клика средней кнопкой), стрелки, кнопки pgup/pgdown и пробел.

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

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

наверное, пользователи оперы уже давно догадались, к чему я клоню. Да, именно в опере пробел доработан очень удобной фичей: переходом на следующую страницу при необходимости. То есть, если страница уже промотана до конца, и вы нажимаете пробел ещё раз, опера открывает следующую страницу. Но как она её находит?

для этого уже очень давно подходящей ссылке можно установить атрибут rel="next". Именно его я и считаю самым полезным микроформатом. Знатоки, вероятно, возразят, «какой же это микроформат, он есть даже в спеке html4», и будут правы. Тем не менее, чёткого определения микроформата нет, а некоторые из существующих, типа rel-tag и rel-directory очень близки герою этой заметки. Кроме того, поддержка в браузерах у него как раз на уровне микроформатов ; )

итак, берём ссылку на следующую страницу, задаём ей атрибут rel="next", и всё шоколадно. Как вариант — делаем то же самое с элементом link в head. Это работает, но есть один ньюанс: мы все знаем, сколько веб-авторов читают спецификации и следуют им. Поэтому опера не ограничивается поиском таких элементов, но ещё пытается найти ссылки со словами next/следующий/forward/→/->/=> и так далее. Получается не всегда, но довольно часто, и то хлеб.

ну а что же другие браузеры и, не побоюсь этого слова, обозреватели? В сафари я такого пока что не видел, но буду рад, если меня поправят. «Самый расширяемый браузер» тоже отчасти не у дел, и вот почему. Да, к нему есть пара плагинов NextPlease и Link Widgets. Последний притворяется Navigation Bar из оперы, показывая кнопки-ссылки next/previous/first/last/home/index. Первый решает только задачу обнаружить ссылки на предыдущую и следующую страницы, но решает хорошо, за одним исключением — не поддерживает «умный пробел».

впрочем, проблемы не страшны, если в наших шаловливых ручках user javascript! Установите простой скриптик «Smart spacebar → next page», и протестируйте его хотя бы в поиске гугла. Думаю, вам понравится : ) А user feedback может сподвигнуть меня и на более продвинутый поиск следующей страницы. Хотя, по-хорошему, поддержку этого нужно встраивать в NextPlease.

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

и да, не зажимайте пробел, чтобы быстро промотать к концу страницы ; )

Дата-центры в России: строим сами?

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

Далее

Отчет о работе ботнета STORM

шок, двойной шок!

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

The following NEW packages will be installed:
  emacsen-common libcompfaceg1 xemacs21 xemacs21-basesupport xemacs21-bin xemacs21-mule xemacs21-mulesupport xemacs21-support
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 33.1MB of archives.
After this operation, 107MB of additional disk space will be used.

для описания этого у меня нет цензурных слов. СТО СЕМЬ МЕГАБАЙТ!!! Да эклипс меньше весит, с его-то репутацией. И эти люди запрещают ковырять ругают bloatware…

но ладно, скрепя сердце, поставил этого монстра. Запустил. И понял, почему оно столько весит. Для машины времени нужна большая программа. А xemacs перенёс меня точнёхонько в 1973 год, по крайней мере, интерфейс его выглядит точно как у Xerox Alto — первого компьютера с гуём. Ребят, прошло уже тридцать пять лет, а вы так себя не уважаете. Вы ещё клавиатуру от пишмашинки к компу подключите, чтобы «классические ощущения» сохранить.

эх, разочарован : (

если что, я не знаю, сколько весит vim, но имхо его интерфейс тоже сосёт. Даже несмотря на то, что выходить из него я могу не только резетом.

update: просто emacs получше выглядит. Немного. Но скроллбар слева? А как насчёт сглаженных шрифтов?

How people really use the iPhone (SlideShare)

гламурные веб-стандарты

интересно, отсутствие флеша на ифоне уже привило каким-нибудь веб-разработчикам нелюбовь к флешу? : )

Альфа-каналы в PNG-8

Мало кто знает, но они действительно существуют.

Проблема полупрозрачных картинок медленно умирает вместе с IE5-6, но, тем не менее будет актуальна для популярных сайтов еще несколько лет. Вдобавок, дальше станет понятно, почему процентная прозрачность для PNG-8 будет важна и без ИЕ.

Чем они вообще отличаются, эти PNG?

PNG-24:
доступны все возможные цвета, доступна любая степень их прозрачности.
PNG-8 обычный:
доступны 256 цветов, прозрачность только на уровне 0 или 100%. Прозрачность в 50%, например, невозможна.
PNG-8 с альфа-каналами:
доступны 256 цветов, каждый из этих 256 цветов имеет свой показатель прозрачности от 0 до 100%. Возможна прозрачность в 42%.

Казалось бы, «Ну и что? Все равно альфа-каналы в ИЕ работать не будут, толку?».

Однако, толк в том, что полупрозрачные пикселы в PNG-8 при просмотре в ИЕ будут показаны полностью прозрачными. Все остальные броузеры честно отобразят их полупрозрачными. Более того, не будет никакого уродливого серо-белого фона, который видно при просмотре PNG-24 картинок в Интернет Эксплорере.

То есть: все пикселы с прозрачностью от 0 до 99% будут отображены IE как полностью прозрачные.

Как сохранить PNG-8 с альфа-каналами?

Это странно и дико, но сделать это в Photoshop нельзя. (возможно в CS4…?)

Зато такую картинку можно сохранить в Fireworks! Там это делается очень просто, при экспорте выбираем опции:

Опции для экспорта PNG в FireworksТрудно ошибиться, нужно выбрать формат PNG-8 и тип прозрачности «Alpha Transparency». Видно также, что в палитре все цвета имеют прозрачность кроме одного (крайнего справа)

Почему этого нет в Photoshop, загадка.

Также существуют утилиты, превращающие PNG-24 в PNG-8. Естественно, при этом качество страдает, но часто с этим можно жить.

Живой пример

Для примера, я сохранил одну и ту же картинку в трех форматах: PNG-24, PNG-8 обычный, и PNG-8 с альфа-каналами (из Fireworks). Все три поместил на узорчатый фон. Вот что вышло:

PNG картинки в FirefoxPNG картинки в Firefox

Ничего особо интересного, кроме размеров картинок. Обратите внимание на вес PNG-24 и PNG-8 файлов, при почти идентичном отображении.

А теперь, в ИЕ:

PNG картинки в IEPNG картинки в IE. Хорошо видно «серо-белое уродство» упомянутое ранее

Вуаля! То, что называется «graceful degradation»!
Сами смотрите, если не верите. ;)
За фон благодарен.

Польза

Вряд ли это знание поможет вам познакомиться с девушкой вашей мечты, или начать наконец делать зарядку по утрам. Но, некоторая польза все же есть.
Во-первых, это экономит трафик. Во-вторых, в большинстве случаев отлично деградирует в ИЕ. То есть, можно применять для всяких некритичных украшательских штучек. В IE будет отображен обычный PNG-8 (а ля GIF), а для всех остальных полупрозрачная красота.

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

Еще по теме

Эта техника, кстати, в некоторых случаях могла бы чуть-чуть упростить вот этот супер-универсальный трюк Виталия. Другие заметки по теме:

Уверен, кто-то уже это использовал. Знание это совсем не новое, но малоизвестное почему-то. Потому, был бы рад если бы вы поделились опытом по теме.

Redhat and AMD migrate VMs across CPUs

Web-разработка / Странное ограничение IE на количество внешних CSS

Shared by arty
чёрт, ещё куча неожиданных ограничений в комментах
Разрабатывая проект наткнулся на странный глюк в IE. Некоторые стили просто не применялись к странице. Т.к. проект большой и стилей много, на этапе разработки CSS был разбит на много файлов для каждого логически отдельного блока. Выясняя причину я, опытным путём, пришёл к тому, что IE подгружает максимально 31 внешний CSS файл через. Остальные файлы просто игнорируются.
Проверял на IE6 и IE7.

Естественно, когда сайт пойдёт в продакшн весь CSS будет в одном файле, но на этапе разработки этот момент подставил подножку.

тестер [почти] поневоле

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

удивительно, что интернет при всём этом работает : ) И работает очень даже неплохо. Конечно, некоторые убожества типа фконтакте отказываются служить, но тем хуже для них — ухожу без сомнений. Единственная уступка, на которую я иду для некоторых ценных сайтов типа гугла и дёрти — включаю им яваскрипт.

а теперь о плюсах, потому что минусы и так ясны. Плюса два, и они крупные. Первый: теперь интернет поставляет мне не дизайнерские изыски, а нужную информацию, причем сразу в удобном для употребления виде. Второй: он делает это быстро. Никаких счётчиков, никаких тормозов гугловой статистики, практически никакой рекламы (спасибо отключению ифреймов). Всё супер : )

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

ogg / Официальный релиз Theora 1.0

Организация Xiph.Org в понедельник представила официальный релиз свободного и бесплатного видеокодека Theora 1.0, который уже давно пророчат в качестве альтернативы проприетарным форматам и который поддерживается в Firefox 3.1 (через тег “video”, предусмотренный стандартом HTML5). В новой версии Opera тоже появится поддержка этого формата.

Как и родственный аудиокодек Vorbis, видеокодек Theora поддерживает любое качество и уровень компрессии (от размера почтовой марки до HD-видео), а на низких битрейтах вполне достойно выглядит по сравнению с конкурентами. Разумеется, его можно использовать без всяких лицензионных отчислений и роялти, при этом технология совершенно открыта для всех разработчиков и тщательно документирована (190 страниц спецификаций формата).

Существование свободного формата — критически важный элемент для того, чтобы гарантировать возможность свободно создавать и обмениваться видеофайлами и сейчас, и в будущем. Перекодировать видеофильмы в формат Theora можно с помощью инструмента ffmpeg2theora. А разработчики уже начали трудится над следующей версией кодека Theora 1.1.

Разработка / Разработка на PC и производительность — Memory Latency

Herb Sutter (автор Exceptional C++, бывший глава ISO C++ standards committee, мистер Free Lunch Is Over и прочая, и прочая) работает в Microsoft и иногда по средам читает атомные лекции.

Я наконец-то на одну такую попал, и очень радовался. На умных мужиков всегда радостно поглядеть и послушать.
Для отчета — кроме Херба, видел живого Олександреску и живого Walter Bright (который "D").

Лекция называлась «Machine Architecture: Things Your Programming Language Never Told You» (здесь можно скачать презентацию и видео) и была про конкретную часть abstraction penalty — Memory Latency.

Я попытаюсь коротко рассказать о ключевой мысли лекции. Она простая, очевидная и тысячу раз сказанная. Думаю, еще раз повторить азбуку — никогда не повредит.
Читать дальше →

REST и WS-*

Этот пост лежит у меня в черновиках уже очень давно. Все боюсь флейм нездоровый породить :-). Но все же тема мне представляется важной, и в рамках борьбы со старинными хвостами я его таки вот написал. Заранее извиняюсь, если это “и так все знают”, тема действительно уже не нова.

Также должен оговориться, что я не буду подробно описывать, что такое REST сам по себе, потому что это отдельный глубокий и труднопередаваемый вопрос. Вместо этого сошлюсь например на аналогичную этой статью классика темы Джо Грегорио “REST and WS-*“, там он про REST пишет более подробно. А эта статья — о том, почему REST и WS-* нельзя сравнивать, почему их все-таки сравнивают, и почему первое лучше второго. Да, никакой объективности от меня тут ждать не надо :-).

Предметная область

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

REST (кратко)

Representational State Transfer — это набор общих принципов построения веб-сервисов с определенными приоритетами: масштабируемость, независимость от платформы, расширяемость. Эти принципы были сформулированы Роем Филдингом, одним из разработчиков HTTP 1.1, в своей диссертации, посвященной как раз этим вопросам.

Поскольку REST — это архитектура (или точнее “архитектурный стиль”), то в природе, по идее, не может существовать таких вещей, как “протокол REST” или “библиотека REST”. Хотя библиотеки и есть, но они, на самом деле, реализуют не шарообразный REST а обычно что-то более конкретное с использованием REST-принципов. Также и с протоколом: обычно все имеют в виду самый распространенный протокол общего назначения, реализованный на REST-принципах — HTTP 1.1. Однако эти принципы можно применять и с другими протоколами, например с той же CORBA. А также эти принципы можно применять не целиком: ваша системы не обязана быть абсолютно чисто REST’овой, а может быть таковой местами.

Основной смысл REST’а, таким образом, в том, что он описывает то, в каких терминах надо думать, чтобы делать клиент-серверные системы, работающие в вебе, и не нарушающие общей экосистемы.

WS-* (кратко)

WS-* — это обобщенное название набора спецификаций, большая часть которых начинается с букв “WS” (хотя самая базовая — SOAP — с них не начинается). “WS” означает буквально “Web Services” и, надо сказать, является источником заблуждения, что веб-сервисы — это то, что построено именно на этом стеке.

Одним из приоритетов подхода, заложенного в WS-спецификации, является автоматизация публикации и доступа к объектам программных систем в виде интерфейса, доступного через HTTP. В идеале программист должен работать с чем-то на другом веб-сервисе так же прозрачно, как и с объектами в памяти его собственной программы. Пересылку данных, проверку типов и прочий сервис обеспечивает WS-*. Для достижения этого спецификации не абстрактны, а наоборот, очень конкретны и детальны, и, что важно, подразумевают не прямое программирование по описанным протоколам, а использование инструментов среды программирования, генерирующих необходимую обвязку.

Стоит добавить, что главными продвигателями WS-* являются Microsoft и IBM.

Сравнение

Из кратких описаний должно быть понятно, что впрямую сравнивать эти вещи нельзя. Во-первых, они просто разного уровня: одно — архитектурные принципы, другое — набор протоколов с реализациями. Во-вторых, они не взаимоисключающи: вполне можно делать системы на WS-* протоколах с использованием REST-принципов. У меня в голове как-то родилась аналогия, что сравнение REST и WS-* — это примерно то же, что сравнение функционального программирования и Visual Studio.

Но тем не менее… Тем не менее, сравнение все таки напрашивается, пусть даже и на эмоциональном уровне. И оно таки имеет смысл!

REST и WS-* являются ключевыми понятиями для совершенно разных подходов к созданию веб-сервисов. И неважно, что они сами находятся на разных уровнях, важно, что они подразумевают очень конкретный инструментальный стек, в рамках которого работают:

REST WS-*
Архитектура REST RPC-стиль
Транспортный протокол HTTP HTTP
Протокол описания сообщений HTTP SOAP
Сервисные протоколы (авторизация, кеширование, проксирование) HTTP WS-*
Описание форматов MIME-типы XML Schema
Глобальная система идентификации URI/URL Отсутствует
Описание интерфейсов сервисов Отсутствует WSDL
Инструментарий Низкоуровневый (парсинг XML, JSON и др.) Высокоуровневый (абстракция доступа к удаленным объектам)

Все это нуждается в разъяснениях.

Архитектура

Архитектура REST диктует, что

WS-сервис никакой конкретной архитектурой не обладает. Снаружи — это “черный ящик”, у которого есть набор специфичных методов, которые можно вызывать. Что у него внутри, известно только его разработчику. Также исключительно на совести разработчика находится масштабируемость сервиса, поскольку WS-стек тут никаких решений не подсказывает. Чаще всего поэтому WS-системы предоставляют RPC-подобный интерфейс, потому что это то, что получается само собой, если над ним особенно не задумываться.

Протоколы

Оба стека используют HTTP, но сильно по-разному.

HTTP создавался как каноническая реализация REST-принципов, и цели этой достиг. Теперь для большинства REST-ориентированных система HTTP — это все: хлеб, масло и колбаса сверху. Или более формально — и транспорт, и метаданные и сервис. А именно:

WS-* же использует HTTP фактически только как транспорт для передачи SOAP-вызовов. И, собственно говоря, заявляется, что HTTP для WS-* — только один из транспортов, и можно использовать другие. Для всего остального в стеке придуманы свои аналоги. В частности, SOAP-сообщение состоит из заголовков и тела, и именно эти заголовки, а не HTTPшные, имеют значение. Куча остальных фич реализована различными WS-протоколами, про которые я подробно распространяться не буду за незнанием, а лучше еще раз сошлюсь на источник.

Формат данных

Одно из основных положений REST’а — использование для описание форматов данных MIME-типов. Лучше всего, если сервис использует уже известный и описанный MIME-тип. Например, если вы выдаете какие-то календарные события, то желательно их выдавать в формате iCal с заголовком Content-type: text/calendar. Еще одна возможность — использование XHTML с микроформатами, потому что это тоже описанные данные, и под них есть парсеры. И если только совсем не получается найти подходящий MIME-тип, тогда только можно придумать свой собственный XML и очень тщательно его описать. Еще желательно его в IANA зарегистрировать, но это уж как получится :-).

WS-стек не имеет описания формата передаваемых данных в целом. Точнее, форматом является некий абстрактный SOAP-конверт, но он не означает ничего конкретного — это просто транспорт. Вместо этого описываются типы параметров, которые передаются внутри этого конверта. Строки, числа, даты. При передаче они сами по себе не связаны никакой семантикой, и что с ними делать, определяется тем, какой метод какого объекта вызывается с этими параметрами.

Это различие, в сочетании с универсальным интерфейсом, делает REST-сообщения самоописывающимися, а SOAP-сообщения — нет. Даже если оно содержит только известные типы данных, смысл его разный для каждого конкретного вызова каждого конкретного объекта.

Глобальные идентификаторы

В REST есть понятие глобального идентификатора, которым по сути является хорошо всем известный URL (точнее, URI, но разница несущественна). Прелесть его наличия в том, что он создает единый интерфейс ссылок на ресурсы между разными сервисами, которые друг про друга ничего не знают. Например, REST-сервис, работающий с картинками, может принимать к себе как непосредственно представления картинок с MIME-типом image/something, так и URL’ы картинок, которые могут быть расположены где угодно.

Еще один важный плюс — это то, что одними только URL’ам сервис может описывать свой собственный протокол. URL’ы, встречающиеся в выдаваемых представлениях ресурсов, как в телах, так и в заголовках — это новые ресурсы, в которые клиент может стучаться для того, чтобы делать с сервисом что-то еще. И поскольку формирование URL’ов является обязанностью сервиса, это позволяет ему свободно менять схему своих URL’ов, не боясь сломать клиентов, которые всегда работают только с готовыми URL’ами, а не составляют их по каким-то правилам.

В WS-стеке глобальных идентификаторов нет, так как нет самого понятия разных ресурсов. Все операции с сервисом делаются только через одну точку по уникальным для этого сервиса правилам.

Описание интерфейса

Для описание интерфейсов WS-сервисов есть развитый язык WSDL, который подробно описывает, какие у сервиса есть объекты, какие у них есть методы, и какие у них есть параметры. Формат сложный, с-трудом-человекочитаемый, и рассчитан на то, что он будет генерироваться средствами IDE автоматически по реально существующим объектам системы.

В REST-сервисах никакой прямой аналог WSDL не нужен, потому что все ресурсы обладают уже заранее известным интерфейсом.

Стоит заметить, что WSDL в WS-стеке играет примерно ту же роль, что наличие URL’ов в REST-системах — описывает то, что можно делать с сервисом. Хотя очевидна разница в акценте. WSDL полезен клиенту по сути только для автоматической генерации стабов, и ничего не говорит о семантике вызовов. В то время как по наличию URL’ов в REST-ресурсах, описанных в подходящих местах, можно делать конкретные выводы о том, как их использовать.

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

Инструментарий

Инструментарий — по сути главная часть WS-стека. Его задача — создать в IDE программиста клиентского приложения удобную абстракцию для доступа к серверным объектам. Соответственно, без автоматической генерации и парсинга WSDL-описаний и SOAP-сообщений тут делать нечего. Я не возьмусь судить, насколько это все выходит удобным, но то, что выглядит это все довольно Солидным и Сложным — это точно. Есть даже точка зрения, что вся эта великая концепция была как раз и рождена для создания рынка инструментария. Большой минус у этого подхода в том, что она работает только на тех платформах, которые интересно обслуживать производителям инструментов.

Для работы с REST-системами никакого одного набора инструментов нет и быть не может. Вместо этого вам предлагается пользоваться вещами, подходящими для конкретных задач. Нужно общаться с HTTP — возьмите хорошую HTTP-библотеку, коих много. Нужна более сложная авторизация — есть библиотеки для digest-авторизации, OAuth’а и т.д. Парсинг XML, JSON и прочих форматов и подформатов — тоже в библиотеках. Каждую из таких небольших библиотек вполне может написать один человек, а не целая компания.

Культурное различие

Все технические различия в подходах, акцентах и назначениях между REST и WS-* складываются в хорошо ощутимое различие культурное.

WS-стек — это инструмент для разработчиков, которым нравится работать в среде, которую для них создает большой солидный вендор, которому они сильно доверяют. Их не беспокоят мелочные вопросы типа “как работают вещи внутри”, им неважно, будет ли их сервис удобно программировать кому-то на странном маргинальном языке программирования. Им интересно, чтобы у каждой решаемой задачи уже был кем-то одобренный верный способ решения. А если он не решает задачу, то разработчик вроде как все равно не виноват — надо просто купить новую “более enterprise” версию решения, в которой это все точно уже сделано.

REST — явный любимец open source культуры. Для людей, которые не будут спать ночами, придумывая, как покрасивее описать интерфейс системы в виде stateless-ресурсов. Которым важно знать, что если им захочется написать сервис на Erlang’е, они смогут опубликовать ресурс в XML-виде, не дожидаясь, пока кто-то напишет SOAP и WSDL генераторы для Erlang’а. И которым в принципе не все равно, насколько незлым будет их сервис по отношению к другим жителям веба.

И вот поэтому я утверждаю, что:

WS-* — плохой способ делать веб-сервисы. Он решает ненужные проблемы, зато не решает нужных.

Ссылки

При написании этой статьи у меня скопилось некоторое количество ссылок по теме. Привожу их здесь в произвольном порядке:

YouTube breaches language barriers by offering auto translation of subtitles

загадка «не верь глазам своим»

как такое может произойти?

[arty@arty-home:~]$ sudo apt-get install epiphany-browser
zsh: command not found: sudo apt-get install epiphany-browser
← предыдущий месяц