victorgr

Многие разработчики активно обсуждают интересный способ сжатия JavaScript-файлов, придуманный Jacob Seidelin. Кратко, способ заключается вот в чём: JavaScript кодируется в PNG-картинку. Каждый пиксел PNG-8 может закодировать 1 байт, а PNG-24 — целых 3 байта. На целевую страницу вставляется сама картинка и небольшой скриптик, который эту картинку будет обрабатывать. С помощью элемента Canvas, этот скрипт попиксельно проходится по загруженной картинке и декодирует из неё JavaScript.

Смысл всего этого действа в том, что PNG-сжатие для картинки превосходит GZIP-сжатие, которым можно сжать .js-файлы. По крайней мере так предполагается.

Конечно, вряд ли можно считать это готовым решением, но как интересный proof of concept годится.

Однако я в этом сразу же увидел несколько иное применение: стеганография! Теперь, когда у JavaScript-а на странице есть возможность попиксельного анализа изображения, то никаких препятсвий для этого нет :).

Зачем инструмент стеганографии на веб-странице? А зачем он на локальном компьютере? Для тех же целей.

Отличный краткий путеводитель по Ruby и Rails.

http://johnwlong.com/slides/gettothepoint/slide/view/1.html

Оказывается, PHP отсасывает у Python почти по всем параметрам, кроме памяти в одном случае.


PHP вообще всему сливает.
Питон 2.5, ПХП 5.

Вот только скрипты питоновские там прекомпилированные...

Некоторое время назад узнал об одной особенности реализации языка Python, которая меня жутко огорчила — это GIL (Global Interpreter Lock).

Весь недостаток от использования GIL можно выразить очень просто: вся Python-программа выполняется в одном потоке и не будет распараллеливаться на многопроцессорных системах. Да, даже при использовании threads, предоставляемых самим языком.

Что в этом плохого? Пока вы работаете на однопроцессорной машине — ничего. Но когда у вас многопроцессорная машина, или многоядерный процессор — вот тут и всплывают все недостатки. Сколько бы у вас ни было свободных процессоров, готовых перемолоть любую программу, скрипт на Python будет выполняться только одним процессором. Хотя в нём самом могут работать много thread-ов, выполняющие долгие вычисления.

Вообще же, мы вступили в эпоху роста процессоров “вширь”. Тактовую частоту уже сложно прибавить, поэтому приходится ставить много ядер. 8 августа 2008 года Intel полностью прекратит производство одноядерных процессоров. Проявляются новые архитектуры многоядерных процессоров Cell и другие. Таким образом, совсем скоро наступит время, когда число ядер в микропроцессорах будет начинаться с двух, четырёх, восьми... А это приводит нас к необходимости создавать приложения, способные эффективно использовать все преимущества многоядерных процессоров. Приложений, которые будут хорошо распараллеливаться и задействовать каждое ядро для своих целей.

А тут вот такая неприятность с Python. При чём, GIL будет актуален ещё и в разрабатываемой версии Python 3k.

Гвидо Ван Руссо, создатель языка, на этот счёт говорит примерно следующее:

Если у вас несколько CPU и вы желаете использовать каждый из них, то создавайте столько процессов, сколько у вас процессоров. Если Вам действительно нужна “честная” многопоточность в Python, используйте Jython или IronPython; JVM и CLR имеют поддержку многопроцессорных потоков. Конечно, будьте готовы к взаимным блокировкам, livelock, race condition и всем другим “прелестям”, сопровождающим многопоточный код.

Да, действительно, используя реализацию языка на Java (Jython), мы избавляемся от недостков связанных с GIL. Поскольку там thread-ы будут честно распараллеливаться на разные ядра процессора. Однако, есть и недостатки. Во-первых, Jython пока реализует лишь Python версии 2.2 и 2.3 (и это на кануне выхода версии 2.6 и новой версии 3.0!), а второй недостаток связан с использованием JVM — это относительно долгое время старта приложения (2.4 секунды против 80 мс для обычного Python-скрипта).

Вот такие вот дела.

На сколько мне известно, язык Ruby так же подвержен недостаткам, связанным с GIL.

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

Вчера у меня получилось сходу создать маленький “Hello World”, используя QT4 и Python ну и PyQT, в качестве связки :)

( Хочу поделиться этим, дабы другим было проще в будущем :). )

Opera Mini™ 4 beta simulator — сымулятар браўзэра Opera Mini. Працуе праз Java.

Internet Explorer як заўсёды адзначыўся.

Усе браўзэры ў Windows падтрымліваюць DDE: Internet Explorer, Opera, Firefox, Netscape... Safari пакуль не глядзеў.

Вось такі код на Visual Basic

Label1.LinkTopic = “iexplore|WWW_GetWindowInfo”
Label1.LinkItem = &HFFFFFFFF
Label1.LinkMode = 2
Label1.LinkRequest

Павінен знаходзіць адкрыты браўзэр, запытваць у яго адрас адкрытай старонцы й паказваць яго ў label1. Усё выдатна працуе на браўзэрах Firefox, Opera: пераключаесься паміж вокнамі й табамі ў браўзэрах — і інфармацыя ў label1 зьмяняецца на актуальную.

У Internet Explorer усё ня так. Калі адкрыта адно вакно — праграма атрымлівае правільныя зьвесткі. Калі з гэтага вакна адкрываеш спасылкі праз “Open link in new window” і пераключаесься між імі — таксама ўсё добра.

А вось калі запускаеш яшчэ адзін браўзэр Internet Explorer — ён перахоплівае ўсе DDE-запыты на сябе й быццам бы забываецца на папярэднюю копію, пакуль ты яго не закрыеш.

Вось, як заўсёды — усе браўзэры як браўзэры, а для IE вымушаны пісаць асобны варыянт праз COM.

IE7 пакуль не спрабаваў. Будзе цікава паглядзець, як там.

7 простых правілаў паралельнага праграмаваньна ад Intel.