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

 http://dev-4-web.ru/3d-tagcloud-carousel-with-jquery

 http://www.linkexchanger.su/2008/65.html

Вместо того, чтобы загружать ее в отдельном окне, можно ее так просмотреть.

Прикольно же.

Менюшки там всякие интересные, хотя меню лучше конечно средствами css делать, но из-за кривости браузерв это не всегда получается

> Иногда бывает полезно что-нибудь хранить на локальном компе. Мало ли.
Например, промежуточные результаты вычислений - скажем, собирая панорамку совершенно не обязательно промежуточные элементы картинки весящие десятки мегов, захуячивать куда-то на сервер, забивая этим сетку. Или например документацию - нахуй не сдалось ожидать томительные секунды обработки транзакции на сервере что бы увидеть подсказку по нажатию F1 например. А то и кеш серверного набора данных может оказаться нелишним положить локально - для ускорения инициализации или обеспечения возможности автономной работы в случае обрыва соединения.

Только они зачем-то унаследовали от Дельфей проблемы с Юникодом. Наступать на грабли, по которым бродил Борланд много лет тому назад, в наши дни уже как-то даже не смешно.

> Ну тогда на qt надо писать, раз требования, и опять приходим к C++.
Можно ещё на этом, на моно писать. Наверное дешевле выйдет.

> И все-таки, а на чем обычно пишется серверная часть в таких системах?
В каких "таких"? Серверных частей может быть много и они могут быть реализованы каждая по-своему и на своей платформе. Где-то уместна джава, где-то бинарники, где-то вообще проприетарные сервера вращаются, всё это объединяется в единое целое интерфейсами, которые тоже могут представлять из себя серверные процессы, служащие лишь для организации обмена сообщениями между разными частями системы. К тому же загляни в /etc - там чуть ли не каждый файл представляет собой свой собственный оригинальный язык описания конфигурации. Т.е. если ты освоил язык конфигурирования сквида, это не значит, что ты сможешь настроить Самбу. Зоопарк короче.

Да и программист, не понимающий до конца С++, но пишущий на Qt, ничем не лучше дельфекодера, который не отличает рекурсию от итерации. Через какое-то время он обязательно налепит костыль от непонимания, который потом всплывёт, и будет очень обидно и неприятно.

скажу честно -- хз, /me линуксом занимается, и к разрабатываемому ПО отношения не имет. особо этим не интересовался:)

>Также мну не понимает раз система клиен-серверная, то нафиг писать клиентскую часть на делфи, если можно ее сделать браузерной js, jQuery и все такое, она хоть кроссплатформенной в этом случае будет.

хотели сделать, да вот как-то не срослось.

>Но с другой стороны, если система клиент-серверная, то нафиг широкий доступ к файлам на машине-клиенте?
Иногда бывает полезно что-нибудь хранить на локальном компе. Мало ли.

>И все-таки, а на чем обычно пишется серверная часть в таких системах?
На чём угодно. Серверная часть менее ограничена, в отличие от клиентской (где разные ОС, компы и прочее). Какие кодеры сидят, на том и пишут.

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

>и о невозможности непосредственного доступа к ФС.
Блин, а об этом как-то не подумал. Но с другой стороны, если система клиент-серверная, то нафиг широкий доступ к файлам на машине-клиенте?

>Кроме того к клиентской части выдвигаются требования по скорости реакции интерфейса на действия пользователя
Ну тогда на qt надо писать, раз требования, и опять приходим к C++.

И все-таки, а на чем обычно пишется серверная часть в таких системах?

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

Также мну не понимает раз система клиен-серверная, то нафиг писать клиентскую часть на делфи, если можно ее сделать браузерной js, jQuery и все такое, она хоть кроссплатформенной в этом случае будет.

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

>например Делфи
Так он же виндузятный, нах он нужен, каким бы хорошим он не был. Если паскаль еще кроссплатформенный, то покажи мне хоть одну прогу на делфи, которая бы была под линукс или мас. Я слышал под линукс был какой-то проект, но он благополучно приказал долго жить. А под мак я вообще не знаю. Вот плюсы только и остаются, тем более когда с java пошли такие нехорошие движухи.

не только, у сишников тоже такое есть:)

>Вот почему я категорический противник преподавания паскаля в школах и универах.

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

Как отмечают аналитики, Oracle и Sun имеют очень разные взгляды по поводу использования их технологий и интеллектуальной собственности, и, видимо, это стало причиной иска. Корпорация Google активно использует Java в комплекте средств разработки ОС Android. Программное обеспечение для Android также пишется на языке Java, который затем транслируется в байт-код, который работает в виртуальной машине Dalvik. И даже несмотря на то, что код для платформы написан на Java, Google имеет собственную реализацию этой технологии и собственный компилятор для неё.

В качестве претензии называются следующие патенты на ПО:

* 6125447 - Доменная защита для обеспечения безопасности компьютерной системы; * 6192476 - Контроль доступа к ресурсам; * 5966702 - Методика и реализация предварительной обработки и упаковки файлов с классами; * 7426720 - Способ динамической предварительной загрузки классов через клонирование областей памяти из основного рабочего процесса; * RE38104 - Методика и реализация способа определения ссылок на данные в сгенерированном коде; * 6910205 - Задействование гибрида виртуальных и машинных инструкций при интерпретации кода функций; * 6061520 - Способ выполнения статической инициализации;

Oracle также обвиняет Google в нарушении авторских прав (copyright). Официальных комментариев пока не поступало, но некоторые эксперты высказывают предположения, что иск является следствием давнего конфликта Sun и Google в отношении лицензирования технологий Java ME. Намерения Google сводились к созданию свободной для всех системы, в то время как Sun имела намерение, в случае поставки Java ME, стать посредником между Google и OEM-производителями.

При открытии кода Java лицензия GPLv2 для OpenJDK была выбрана с учетом необходимости дополнительного лицензирования технологий Java в случае их использования OEM-производителями в закрытых проектах. Google не согласилась с таким положением дел и создала собственный аналог Java ME, распространяемый к тому же под лицензией Apache 2.0, несовместимой с GPLv2. Более того, компания Google создала собственную виртуальную машину Dalvik, не совместимую на уровне байт-кода с JVM и требующую использования специального транслятора для преобразования Java-кода в Dalvik-код. При этом право на свободное использование Java-патентов распространяется только на открытый под лицензией GPL код OpenJDK.

Этого оказалось достаточным, чтобы признать невыполненными требования, при соблюдении которых компания Oracle делегирует создателям производных продуктов право на использование запатентованных технологий Java. В частности, в требованиях упоминается необходимость сохранения полного соответствия спецификации с сохранением всех описанных в ней интерфейсов и возможностей, обеспечение прохождения тестового набора Technology Compatibility Kit и неизменность каких-либо компонентов, попадающих в область Licensor Name Space.

Дополнение: Джеймс Гослинг (James Gosling), создатель языка Java, недавно покинувший компанию Oracle, опубликовал в своем блоге комментарий, в котором говорится, что подобный шаг не вызывает удивление, в процессе поглощения Sun юристы Oracle сразу обратили внимание на напряженные отношения с Google и если Sun была всегда против манипуляций с патентами, то у представителей Oracle сразу загорелись глаза. Интересно, что в одном из фигурирующих в иске патентов (RE38104) в качестве автора фигурирует Джеймс Гослинг.

сорри, я и имел ввиду кресты:(