WebPart

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

Сейчас же вот, у нас Ганимед.

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

Весит минимальный пакет с поставкой ни много ни мало - 188 МБ. Сложно сказать, насколько это большой размер для современный интернет-соединений, если сравнивать с NetBeans, то та весит, если мне, опять же, не изменяет память, примерно 192 МБ.

Так же, возвращаясь к тому же инсталлятору, меня порадовал процесс параллельной загрузки компонент инсталлируемого пакета. Я не знаю была ли вот такая параллельность в предыдущей версии, однако я, по крайней мере, не замечал. И теперь вам не нужно отвечать на вопрос "Действительно ли вы хотите инсталлировать загруженную только что хрень?", вместо этого оно автоматически не прерывая этап загрузки начинает этап установки, и лишь по завершению оного спрашивает: "Я бы вот не прочь и перегрузить среду. Что ты на это скажешь?".

Сразу хочется высказать своё решительное "ФЕ!" относительно того, что в базовую поставку не включается поддержка SVN. Это что же за такая дискриминация SVN-щиков в пользу CVS-ников? Не понимаю...

Ну да ладно, я то не такой уж и приципиальный - переживу ручную установку SVN-коннектора, так и быть.

Продолжая о хорошом ещё понравилась относительная быстрота работы в плане поглощения оперативной памяти, потому как если посмотреть на тот же NetBeans, который хотел высосать не только всю мою оперативку, но и весь мой мозг; можно так же посмотреть на Zend Studio, которая тоже довольно плотоядная в этом плане, однажды она хотела съесть под 500 МБ мозга ОЗУ, но в случае с Zend это хоть как-то аргументировано, она там всякие контексты и семантики кушает, а вот почему NetBeans такой не понятно.


И вот немного осмотревшись в здешних "пейзажах" я решил перейти к практической части. Так скажем, если PyDev установился вполне нормально, не разу не переспросив меня о чём-либо, и не разу не фыркнув о чём-то, так как, насколько я понял, в откличии от предыдущих версий Eclipse такая чтука как Mylyn поставляется вместе с пакетами по-умолчанию, так как именно её постоянно просил PyDev раньше.
Однако теперь фыркать начал PDT, который и раньше фыркал, но теперь то ведь PyDev это делать перестал? И это учитывая, что PDT сопровождается кажется самой Eclipse Foundiation.
Он типо запрашивает какие-то пакеты WST Features Group и Equinox, я так понимаю это тоже что-то расширяющее среду.

Оказалось, что WST (это набор стандартных утилит для внедрения разных фичей для ведения Web-разработки) у меня уже присутствует, а вот этого Equinox'а (а это как раз и расширения среды типа Mylyn) у меня и не было. Сразу же хочу отметить, что этот вечно раздражающий меня эффект неработающей в процесс процесса кнопки "Отмета" всё так же осталяся незыблемым, и будет продолжать меня раздражать. Эх...


Нет, ну это просто невозможно себе вообразить, вот уже как 40 - 50 минут я тщенно пытаюсь инсталлировать в Ганимеде PDT, ну куда это годится?  Он требует какие-то расширения, при чём даже после их фактической установки. Я фигею просто, что это такое вообще за х**** ? Бррр..... Уже даже успел SVN-коннектор, и кучу прочей в целом ненужной мне дряни поставить, а вот эта вот дрянь, которая мне как раз таки в данный момент нужно - хоть головой об стену бейся....

Вообщем: "Это сон, это бред, это снится...", как моём многим уважаемая Ирина. Для того, чтобы установить это чудовище у меня ушло полтора часа, при этом сначала я тщенно пытался установить его посредствам менеджера, потом пытался установить как Archive site, и только потому оно его "поняло" как Local Site. Безумие просто, что вам сказать....

Ну вот вроде как поставил, и оно вроде как работает, хотя правда следует сначала удалить Zend Studio, которая заблокировала расширения файлов (*.php...) под себя, но это малости.

Вообщем, я хотя бы надеюсь на его пусть минимальную интеллектуальности, хотя... Собственно, я как бы уже освоился в прототипах функций, с которыми я работаю на практике, посему проработка семантики для меня стала уже не настолько принципиальным моментом, хотя я не вижу реальных причин, которые мешают им за такой большой промежуток времени всё же ввести её нормальную реализацию. Ведь PyDev, CDT  и прочие платформы под Eclipse вполне решают эту проблему, пусть даже если и взять ту же Zend Studio. Что они умнее или как ?
Хм....


Вообщем это был такой мальнький обзор и выражений своих радостей и многочисленных ФЕ!

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

Посмотрим, что из этого выйдет. Но я уже рад :) 5-я версия Оперы этой такой наглядный пример, когда ожидания оправдываются, хотя...

Я вот, опять же перебирая документы старые, взятые из офиса, вспомнил свою идею, и она мне понравилась, потому что сейчас, если бы я брался её делать, у меня было бы больше ресурсов и знаний для её воплощения. А идея, пусть немного и утопическая, но в целом довольно интересная. Посетила она меня, вероятно, когда я только устроился на ТНТ-43, и имела рабочее название "Trusted Hosts".
В общем, идея заключалась в создание глобального репозитория сайтов(для начала зоны СНГ), с целью последующего анализа их содержимого, при чём - совершенно разнопланового: изображения, семантическое значение текста, сайты, на которые данный ресурс ссылается, файлы. которые на нём размещаются.

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

Система вычисления индекса приемлемости (ИП) заключалась в 3-х шагах обработки:
1. Машинная обработка информации сайта
2. Подтверждение результатов администрацией
3. Прибавление отдельного атрибута - мнение общественности.

Первый шаг состоял из следующих подпроцедур:
1. Лексический анализ содержимого с учётом семантики русского языка. Оценка может иметь значения: "Удовлетворительно", "Спорно", "Неудовлетворительно". Так же подразумевается анализ документов типа "ТХТ", "DOC", "PDF" в рамках данного домена.
2. Анализ дерева отношений сайта, по отношению к другим сайтам. То есть, если сайт имеет прямые ссылки на сайты, которые имеют ИП в значении "Неудовлетворительно" либо "Спорно", то для данного сайта устанавливается соответствующее значение, в зависимости от контекста ссылки (характера ссылки на ресурс с неудовлетворительным либо спорным ИП).
3. Проверка безопасности файлов, которые размещены в рамках данного домена путём возможностей системы вирусной проверки - Др. Веб.
4. Анализ изображений на поиск образов, неудовлетворяющих этическим соображениям, либо содержащие элементы порнографического характера (наиболее утопических пункт).
5. В конце проверки составляется протокол проверки, и описываются все те пункты, которые система сочла как спорные либо неприемлемые, с указанием адреса, по которому они были обнаружены на целевом сайте, и адресом на кешированную версию страницы, созданную в момент анализа. К протоколу добавляются так же результаты проверки файлов антивирусной системой.

Проверка администратором была представлена следующими возможностями:
1. Проверка протокола, и подтверждение правильности результатов системы, так как возможны ошибки во время определения контекста слов, из-за неоднозначности слов неформального языка, либо ошибок определения характера ссылок на спорные либо неприемлемые ресурсы. Ну, и безусловно, подтверждение результатов системы в плане анализа изображений.
Все расхождения с системным результатом так же должны быть добавлены к протоку вычисления индекса приемлемости, и быть доступны публичному обзору.
2. Администратор обязан подписать результаты проверки и протокол своей цифровой подписью.

Ну и последний пункт заключается в следующем:
1. Добавление новых фактов, которые возможно смогут повлиять на текущее значение ИП данного сайта.
2. Добавление фактов, на основе которых вычисляется атрибут индекса доверия сайта, который невозможно вычислить путём машинной обработки - индекс доверия к сайту, основанный на фактах мошенничества, обмана пользователей, либо предоставления не соответствующих действительности фактов.

Исходя из вышеописанного, мы получаем два фактора, которые определяют индекс доверия к сайту: Индекс Приемлемости (ИП) и Индекс Доверия (ИД).
Это независимые атрибуты, при чём сайт может быть приемлемым, однако с негативным Индексом Доверия, что сообщается в отдельном порядке.

При этом, в данном схеме наиболее полезным и информативным будут является не факторы ИП и ИД, но сам протокол проводки проверки, который так же является публично доступным.

Зачем это нужно?

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

Вот-с. Думаю, я действительно буду продолжать эту идею, сейчас пока только составил небольшие проекты и UMl-модели базовых операций. Может что-то интересное и получится :)

Всем интересующимся идти сюда: http://trusted.googlecode.com, пока там ничего нет, так как создал я его сразу после того, как дописал это предложение.

Вот видите, если бы не уволился, проект бы не начал, потому как не взял бы старые забытые мной бумаги, и не прочитал бы об этой, почти забытой идее :)

Ресурс же где это в будующем будет, называется:
http://trusted.org.ua

Я даже (тогда же, когда саму идею придумал) придумал и слоган: "Trusted Hosts - clean web, clean mind !" (прям такое - со Сталинским уклоном :) ).

Однако вы можете сказать: "Такое уже есть, и примером тому может служить индекс "нехороших" ресурсов Гугла".

Я отвечу - там нет демократии, при чём довольно узкий спектр параметров учитывается, кажется только нелегальный контент, детская порнография, и террористические призывы.

Вот :)

Продаю домены :) или дарю очень хорошим людям ))

1. icook.org.ua
2. isound.org.ua
3. x-web.org.ua
4. indev.org.ua
5. flashmx.org.ua
6. iteam.org.ua
7. musiclib.org.ua
8. iteam.org.ua
9. bi2.org.ua
10. jacket.org.ua
11. landowner.org.ua
12. soldats.org.ua
13. utv.org.ua
14. invideo.org.ua
15. infopage.org.ua
16. x-side.org.ua
17. modems.org.ua
18. metals.org.ua
19. issue.org.ua
20. reviews.org.ua
21. writerity.org.ua
22. bloggster.org.ua
23. cd-store.org.ua
24. butch.org.ua
25. bookshare.org.ua
26. fapi.org.ua
27. faina.org.ua
28. i-marks.org.ua
29. gaypeople.org.ua
30. gaylife.org.ua
31. i-sql.org.ua
32. iboard.org.ua
33. ihate.org.ua
34. last.org.ua
35. linkage.org.ua
36. poems.org.ua
37. promoting.org.ua
38. tcl.org.ua
39. websell.org.ua
40. zetta.org.ua

Кому что-то нужно или есть предложения, пишем на 26один-50два-7семь1; LoRd1девять9ноль[пёс]gmail[тчк]com.

Только сейчас понял весь смысл fork() в команде разработчиков... Да, действительно - это действует на нервы.
Главное, что никакой обработки принимаемой извне информации - глухо, "моё классное" и всё, не смотря на то, что в действительности: всё запутано, непонятно для дизайнеров, неструктурировано.....

Эх...

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



Безусловно, я сейчас говорил о методиках разделения информационной системы на реализацию и представление (пользовательский интерфейс, и, собственно, ядро (kernel) системы).

Если говорить об используемых мной технологиях эдак, скажем, год назад, то это, в лучшем случае, были системы шаблонирования Smarty и тому подобное, что в каком-то плане довольно удобно и полезно, однако всё равно представляет собой ряд ограничений, так низкий уровень возможной спецификации данных дизайнерами и в целом не имеющими квалификации в программировании людьми представляло собой большую ограниченность. Другими словами, за поставку данных в формате user-friendly чаще всего целиком и полностью отвечает программист, при этом дизайнер, либо разработчик интерфейсов, выступают лишь потребителями данных, без каких-либо дополнительных возможностей, конечно, если они не владеют специальными знаниями и технологиями, такими как средства server-side (python, php, ruby, т.д.) либо client-side (js, ммм... :) ) разработки. Всё это довольно замедляло работы над проектами, в ситуации, когда необходимо было разработать довольно простой модуль, функционал которого чаще всего ограничивался визуализацией некоторых данных БД либо результатов работы некоторого интегрированного в систему пакета, с чем мог бы справится и разбирающийся в базовых понятиях структуры системы (не кода, а скорее логики функционирования) обыватель, но что было невозможным из-за обязательного участия программиста в этом процессе.

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

Я, в целом, давно знал о существовании данной технологии, и даже что-то писал на досуге, но всю несомненную полезность и flexibility оной, осознал лишь после того, как начал в корне пересматривать принцип работы разработанной в контексте одного проекта, а на сегодняшний день перешедшей в статус OpenSource, CMS платформы, которая на тот момент была довольно логично и правильно сделана в плане расширяемости, дружественности для сторонних разработчиков и, собственнно, конечных пользователей (users), поскольку в основе лежала идеология XML-обмена данными - как внутри системы, так и за её пределами - в контексте общения с внешними серверами, но это уже другая история.

Однако было в ней одно громадное "НО!", о котором мне громко в форме едкого сарказма (как умеют OpenSource разработчики, словно в поговорке: "в чужом глазу...") напомнили ребята с форума PHPClub. "НО" же это заключалось именно в том, что в системе почти не было явного разделения на "код" -> "представление", и это стало настоящей проблемой, степень важности которой не была оценена на начальных этапах проектирование, и которая в следствии стала значительным образом тормозить дальнейшее развитие системы как в плане реализации/безопасности/красивости, так и интереса к ней среди других решений в среде OpenSource-сообщества.

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

Поскольку основной задачей стало сделать так, чтобы дизайнеры не догадывались о существовании чего-то кроме XML/XSL (если конечно им этого не захочется), однако могли бы при этом спокойной получать данные в удобном для них формате, создавая пользовательские интерфейсы; при этом так же имея возможность более advanced'ного общения с системой, к примеру:

1. Возможность посредством XML-структур, входящих в файл конфигурации модуля, производить запрос данных из БД.


2. Возможность доступа к определённого рода функциям PHP, запрошенным в файле конфигурации модуля


3. Возможность быть в некоторых ситуациях полностью независимым от программииста

И вот с банкой кофе ("Nescafe Classic"), чайником и изрядным уровнем энтузиазма я закрылся на балконе-веранде, и пришёл к совершенно новому для меня подходу к разделению кода и данных.

Если возвращатся к системе CMS, упомянутой выше, то нужно (для большей степени понимания) ввести три понятия: "блок", "пакет", "модуль".

Эти базисный единины в её контексте представляли фундамент движка. Так "пакет" испключительно поставляет функционал, не принимая участия в формировании UI-представления данных, в свою очеред "модуль" наоборот является базовой единицей реализации функционала "пакета" и визуализации данных, разделяясь в свою очередь на подразделы, относительно их функций и семантики. И не относящаяся к "пакетам", но в то же время не совсем "модуль" сущность "блок" так же представляет собой элемент пользовательского интерфейса, при этом не имея всех возможностей модулей, как в структуре так и в функционале, что очевидно.

В окончательном варианте, файловая структура поставк модуля имеет следующий вид:

-- module
-- parts
-- main-part
-- actions
-- action.inc ; сервер-логика для обработки событий форм
-- xsl
-- main.xsl ; файл подключаемый в качестве XSL(T) по-умолчанию
-- ... ; список таблиц XSL, поставляемых с этим разделом
-- main.xml ; основной XML-файл реализации
-- others
-- client-logic
-- css
-- images
-- info.xml


Во время запроса пользователем некоторого модуля системы, происходит проверка текущего активного раздела, при условии отсутствия которого будет обработан `main-part`.

Процесс обработки заключается в следующих этапах:

1. Обработка XML-файла с данными для обработки на серверной стороне (запросы к БД, импорт методов, прочее).


2. Включение в результирующий массив данных результатов проводки по всем, привязанным к данному разделу некоторого модуля либо модуля в целом, обработчикам (wrappers) которые были назначены программистами.


3. Процессинг связанной с исходным XML файлом таблицей преобразований XSL.


4. Добавление данных в массив временных данных, с последующим возвратом их пользователю на последней стадии формирования контента.

Исходный информационный файл XML для настройки и определения запрашиваемых и поставляемых данных для каждого раздела модуля имеет следующую структуру:

<?xml version='1.0'?>
<input>
<transform>
<item src='${part_dir}/xsl/main-diff.xsl'/>
</transform>
<infoset>
<title></title>
<css></css>; Inline-объявление либо перечисление узлов <item>
<script></script>; Inline-объявление либо перечисление узлов <item>
<!--Некоторые дополнительные параметры страницы-->
<params>
<key>value1</key>
</params>
</infoset>

<!-- Exaple URL-parts exporting as XSL-variables -->
<var number='1' import-as='product_id' type='number'/>
<var number='2' import-as='product_title' type='string'/>
<var number='3' import-as='user_id' type='number'/>
</urlset:url>
<dbset:dataset>
<set id='1'>
<tables join='left'> ; "join" - опциональный атрибут
<item name='some_db_table1' variable='d'/> ; variable - опциональный атрибут
<item name='some_db_table2' variable='d1'/> ; опциональный атрибут
</tables>
<columns>
<item name='title' from='d' variable='product_title'/>
<item name='uid' from='d1' variable='user_id'/>
</columns>
<where>
<case type='default'>
<term object='SUMM(d1.count)*SUMM(d1.cost)'/>
<term object='SUMM(d2.salary)*SUMM(d2.salary)'/>
<action type='greater or equal'/>
</case>
<case type='or'>
<term object='(SUMM(d1.count)*SUMM(d1.cost))/SUMM(d2.salary)*SUMM(d2.salary)'/>
<term object='1.2'/>
<action type='less'/>
</case>
</where>
<order by='some_db_table1.title' way='ascend'/> ;Optional tag
<limit count='20'/> ; Optional tag
<group by='some_db_table1.uid'/> ; Optional tag
</set>
</dbset:dataset>
<!-- Разработчики могут задавать следующую структуру данных:
<dbset:dataset>
<query>INLINE DATABASE QUERY</query>
<columns>
<item name='selected-column-name' import-as='NAME IN XSL VARIABLE ENVIRONMENT'/>
</columns>
</dbset:dataset>
-->
<functions-import>
<item name='{php_environment_function}' as='{xsl_environment_name}'/>
;...
</functions-import>
<vars-import>
<item name='{php_environment_variable}' as='{xsl_environment_variable}'/>
</vars-import>
<wrappers>
<item name='{php_valid_function_or_method_name}' step='0'/>
</wrappers>
</input>


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

Стоит отдельно упомянуть такие элементы как <functions-import/>, <variables-import/> и <wrappers/>.

В теле элемента <functions-import/> перечисляются те функции среды PHP, которые должны быть импортированы в среду XSL, и соответственно <vars-import/> вложенными тегами <items/> описывает переменные среды PHP, которые будут доступны для обращения в среде XSL.

То есть это как-бы расширения стандарта XSL, подобно аналогичному - EXSLT, которое служит для увеличения уровня автономности и самобытности дизайнера (что, конечно, в любом случае не является желательным по ряду обстоятельств :) ).

Расширение стандарта поддерживается подключением в качестве пре-процессоров XSL внешних wrapper-методов, которые обспечивают предварительную подготовку и замену всех "самодельных" конструкций, на необходимые аналоги (обращение к импортированным функциям, переменным). Очевидно, что число wrapper'ов не ограничено ни чем, что, собственно, не ограничивает расширение стандарта.
При этом учтён тот факт, что некоторые такие методы следует применять в условиях последовательности, а посему введён такой параметр как `step`, которые говорит обработчику в какой последовательности применять wrapper-методы.

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

В целом ничего принципиально отличного, в сравнении с подходом реализации пользовательского интерфейса модулей не производится (если говорить блоках).

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

Я всегда был приверженцем проработки всех возможных ситуаций и вариантов, и конечно же все считал, что пользователю в определённый момент наскучит базовое оформление страницы, да и даже если не базовое - наскучит, посему всегда считал невозможным применение термина CMS к продуктам, в основе которых лежат идеи не только того, что пользователь потом "всё равно будут платить за дизайн", или "все должны будут выучить эту технологию</cite>", "..мы делаем систему для "нормальных людей", а они эту технологию почти все знаю...", не говоря уже об интернационализации и прочем.

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

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

1. Декларирование в настройках темы её структуры, в смысле активных областей для добавления блоков.


2. Специальные контейнеры для отображения стека системных сообщений некоторого типа, с применением (опционально) к ним стилевого оформления, характерного данной теме.


3. Абстрагирование от количества доступных модулей/пакетов в системе.


4. Абстрагирование от текущих интернациональных настроек системы.


5. Предоставление пользователю возможность собственноручно настраивать некоторые детали оформления, путём правки значений в файле настроек.

Так, в контексте не один раз упомянутой выше технологии XSL, системой в тему оформления портируются следующие структуры данных и методы:

Структуры:

1)

<handlers>
<set type='errors'> ; 'errors' | 'messages' | 'attempts'
<item code='error_code'>Short system error description</item>
</set>
</handlaers>

2)

<infoset>
<!--структура аналогична структуре вложенного в узел <input> элемента<infoset>, за исключением изъятия элементов <css>,<scripts>-->
</infoset>


Методы:

get_panel_content(<%идентификатор_панели%>) - получение блоков, которые относятся к данной панели, некоторой темы.
get_css_nodes() - отрисовка и возврат всех относящихся к данному документу таблиц стилей
get_scripts_nodes() - отрисовка и возврат всех относящихся документу скриптов
flush_error_handler(<%handler%>) ; handler='errors'|'messages'|'attempts'


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

А что, iPhone уже официально пришёл на рынок государства Украинского ?

Вот сегодня спускался по экскалатору, и на рекламном плакате глясящем о какой-то акции от банка... не помню, кажется от Raiffeisen, в качестве подарка указывался "супер-современный" телефон iPhone...

Откуда они их взяли? У тамжни покупают лишнее? Или всё же что-то более глобальное?

Ведь если продукт официально не продаётся на территории государства, то, что очевидно, дарить/продавать/жертвовать его просто незаконно....

Да-с...

Не могу не кричать от счастья и радости )))

По статистике уважаемого мной ресурса http://w3schools.com, в сравнительной оценке популярности веб-броузеров аудитории Интернет-пользователей первое место занимает FireFox 39.1%, а гадкие IE6 и IE7 остаются на второй и третьей позиции с 24.9% и 28.9% - соответственно.

Жаль, правда, что Opera занимает очень малую долю рынка с жалкими 1,8%... Странно как-то, мне кажется это в целом замый корректный, и самый вменяемый броузер...

Во всяком случае, радует хотя бы то, что это уродство "ословское" близится к своей логической смерти *ХА-ХА-ХА* *ЕХИДНАЯ_УЛЫБКА* :)

Читать тут: http://w3schools.com/browsers/browsers_stats.asp

Задумался: каким всё же образом рациональнее проводить рефакторинг кода, и структуры проекта - автоматизированными, собственно-ручно созданными средствами, или теми же собственно руками эти изменения внести без применения автоматизации ?
В целом временной КПД с каждым новым рефакторинговым решением колеблится, но всё же является не более чем в 2 раза более эффективным по времени нежели то же средство основанное на автоматизации.

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

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