Албум за светско првенство има 639 сличица, а мене је занимало колико треба да купим да бих могао да га попуним, тј. колико дупликата могу да очекујем. Написао сам овај кратак програм у Пајтону баш за то:

#!/usr/bin/env python
 
from random import uniform
 
duplikati = 0
for it in range(1,10000):
    popunjene = ()
    for kupljene in range(1,300):
        broj = int(uniform(1, 640))
        if broj in popunjene:
            duplikati += 1
        else:
            popunjene += (broj,)
print duplikati/1000.0

Овај програм враћа број дупликата за купљених 300 сличица ако албум има укупно 639 сличица. Број дупликата је 60, што се уклапа са бројем мојих дупликата (62), што ће опет рећи да су сличице прилично униформне (лепа вест за оне који скупљају овај албум)

Ево и листинга колико дупликата можете да очекујете на колико купљених сличица:

Ово практично значи да је довољно да купите 639 сличица (тачно колико треба) и да добијена 234 дупликата замените за оне које Вам фале и попунили сте албум

Ето, ово је још један пример како штребери успеју да упропасте све жеље, ишчекивања, наде, размене и тапке, ма све оно лепо у скупљању сличица и убаце математику тамо где јој није место

Програми

Пошто смо од издања 2.26 на 2.28 направили стварно огроман скок са 81% на 91% преведности, били поменути као један од најбољих тимова за 2.28 и вратили српски превод Гнома на стазе старе славе, сада смо само одржавали исти ритам. Не би смело да нам се опет деси да се онако опустимо, а за ово издање смо чак и повећали преведеност на 92%. Сви главни програми су потпуно преведени, као и још много програма који нису део скупа основних модула. Још једина два непреведена модула су Орка читач за особе са посебним потребама и Анјута — интегрисано окружење за развој, тј. IDE. Дефинитивно ова два програма не спадају у приоритетне, али ћу гледати да за Гном 3.0 (пошто је следеће издање 3.0) пробам да преведем Анјуту (мада искрено не верујем да ће домаћи програмери користити тај превод, осим можда неких нових клинаца који тек упадају у програмерске воде, па ће им можда бити лакше тако). Такође, има још доста програма „са стране“ који заслужују да буду преведени пре ова два, а сад имамо времена и за њих. И наравно, највећи приоритет је дефинитивно одржавање ових постојећих превода. То је, по мени, правац у коме ће се кретати даљи развој превода за Гноме, али далеко од тога да ће бити по пароли „на западу ништа ново“ јер, већ у Гному 3.0 ће вас сачекати једна лепа промена — свако појављивање речи „умножи“ (тј. на енглеском copy, када се садржај пребацује у клипборд) ће бити замењено са de facto коришћенијим у разговору „копирај“.

Друга ствар која ме јако брине је што на преводу Гнома сада практично раде само два човека — Милош Поповић и ја. Мало је тужно и несхватљиво да једно од најкоришћенијих окружења за линукс нема више преводиоца, а да, са друге стране на Убунту преводу за српски ради мала армија. Требало би овде мало погурати, видети има ли заинтересованих људи; у првој категорији, тј. најпожељнији су они који већ користе локализовано окружење. Верујем да таквих људи има, али наравно, не по цену квантитета да изгубимо квалитет. Честитке Милошу за изгурани 2.30, урадио је лавовски посао, али већ је постало монотоно да нас двојица честитамо један другоме више, треба нам свеже крви:)

Документација

Гном 2.30 је посебан по томе што је по први пут започет рад на превођењу документације. Све то је почело овде. Дакле, после изласка 2.28 сам започео превођење Гном документације, чисто да видим куда ће ме то одвести. Сада могу да кажем да је добро испало. Гном је добио превод документације свих игара на српски језик, што му дође негде око 9% превода целе документације. Добра ствар је што се ови преводи документације не мењају често тако да неће представљати велики проблем одржавати их касније, али, са друге стране, да се не лажемо – основни, изворни текст документације (на енглеском) и није нешто претерано од помоћи (а и лош је зато што је написан једном и ретко кад се и мења). Ево како то лепо изгледа на крају на проклетим лажима:

Када добијете нови Гном 2.30, погледајте Помоћ->Садржај за неку игрицу, требало би да у свим дистрибуцијама добијете документацију на српском.

Не планирам да стајем овде, план за 3.0 ми је да одржавам ове преводе и да преведем још пар модула из истих група, а то су GNOME applets, gnome-media, а ако стигнем и gnome-utils и неко конкретно програмче (најприоритетније, типа калкулатор и сл.). То би повећало проценат преведности за још оволико, тј. до 20%, а мени би дало потребно искуство за превод највеће и најважније документације за издање после 3.0, а то је корисничка документација (наравно, не за Гном 2, него за Гном 3). Уколико се појави још неко за превођење документације, тим боље. Толико од мене за Гном 2.30.

- „Јао, види брезе, како су лепе!“, прокоментариса она пуна нескривеног одушевљења док смо пролазили колима поред неког тамо дворишта.

Нисам се ни трудио да прокоментаришем, нисам имао шта да кажем.

- „Знаш ли да се брезе увек саде у паровима, бреза и брез, никад једна сама“, наставила је она.

- „А јел схваташ ти да то нема апсолутно никаквог смисла“, рекох после кратке тишине која је уследила, морајући да се укључим у разговор.

- „Не, стварно. Бреза и брез увек морају да се саде заједно, ако посадиш једну брезу, она увене.“

- “Не, не увене. Не увене ништа више него што ће увенути, на пример…усамљени багрем или храст кад га посадиш. То је само глупа народна измишљотина.“

- „Какав си, све мораш да упропастиш. Моја тетка је имала пре пар година викендицу ту негде испод Голије, ишла сам тамо, знам да је морала да посади две брезе…“

- „Брезе су јебене дикотиледоне, не треба им неки тамо брез. Бреза…капираш, једно дрво женског рода, без преке потребе за мушким партнером.“

- „Не, не схваташ, какве диклодоне, причам ти о томе да једино могу да расту и успевају у заједници…“

- „Ма, не схваташ ти бре биологију за пети разред основне.“

Настала је мала пауза, док ме је гледала са неверицом.

- „Одвратан си“, рекла је док је излазила из кола.

• See no warnings, hear no warnings, speak no warnings – for mediocre, but it actually works;)
• When you commit something, make sure no warnings are commited – e.g. at least clear warnings from classes that will end up in patch anyway – this Eclipse plugin can help
• Be a man! Have balls and clear as much warnings as you can before you get fired!

OK, we’re interested in third solution. If you’re already going to clear as much warnings as possible, it would make sense to first clear warnings from those classes that have them most (remember patch problem). So, if you have 100 classes with 1 warning and 1 class with 100 warnings, you should choose to clear 100 warnings from one class. In ideal world, you wouldn’t mind, but in reality you will not manage to clear all the warnings (unless you really badly want to be fired). So, without further ado, I present you small Eclipse plugin that will show you count of warnings in workspace grouped by Java resource. Created in under 2 hours and then 2 more hours to put it on GitHub (well, what do you want – first time creating GitHub account) and there you have it:

http://stalker314314.github.com/groupwarnings/

You can download plugin directly here and just copy it to plugins/ directory of your Eclipse 3.5+ installation. If you’re lazy enough not to click on my super duper extra site I created on GitHub, then you can see screenshot here (actually, blog post will look much cooler if I put picture here, so I had to make up reason).

Enjoy!

First kid that catches eye is one tall boy, larger then all the other kids and obviously older then all of them. His name is C. He’s casually dressed and is always smiling cheerfully. All the other smaller kids are swirling around him and he obviously enjoys playing with them. He knows he is the coolest kid there and that he got respect from all of them, but he is not presumptuous about it. He’s fast, his moves are sharp and intelligent, he’s very agile and he likes to help other kids, knowing that they are helpless without him. Look, he just helped that kid Python to climb that tree. Python could climb that tree himself, but it would take him forever, and he asked C for help and C, smiling as always, immediately picked him up and put him on branch. He really is like older brother for all of them.

Speaking of brothers, C really have one younger brother. His name is C++. Actually, they are stepbrothers, C’s fathers had thicker beards then C++’s father, and C++’s father have less hair. You could see these two kids look alike, but C++ is little smaller and younger. C++’s father thought he could give C a little brother that will be better at handling objects at playground, but that will still looks similar to C, and although he succeeded, other kids still prefer to play with C. He’s also a bit fat for a child of that age and little slower then his older brother, but granted – he’s better at handling various objects. Reason for it’s slowness is maybe because he carries with him a lot of equipment. He got with himself a little shovel, rake and little plastic bin, and man, he even have a Swiss knife. Other kids looks in awe at C++’s tools and possibilities with it, but they also heard from elders that those tools he’s carrying are just burden and that it takes a skilled person to use all those tools properly and wisely, and that you may even cut yourself if you try to use them without any training, so that’s why they mostly like to play with his older brother.

We already mentioned Python kid. He’s one of the kids that often asks C to help him. He is fast and agile, but alas, there are some times when only C can help. He’s one small kid with shaggy hair and he enjoys doing things both nice and quick. He never stops, he’s restless, his trousers are scraped on knees from constant running, jumping and falling. In one word, he’s very dynamic. Because of his dynamic nature, he often breaks things, but he can also very quickly put them together because he always carries duct tape with him. There is one more thing he always carries with him. If you ask him to do something, he’ll get to work immediately, no matter how hard that is and when the job is finished, he likes to take out couple of batteries from his pocket and to shout childishly ”batteries included!”.

Another kid similar to Python is Ruby. They are both very similar, but interestingly, they like to compete. If one of them does something, other kid will try to do the same, but quicker and nicer, showing that it’s better. They are even dressed similar, except Ruby likes to wear red.  When they have to do something in parallel and Python is faster then Ruby, he likes to say that Ruby’s red shirt is in fact woven from green threads. If, on the other hand, Ruby wins, he can then jump all day around Python making fun of him by shouting “Global Interpreter Lock!”. Ruby’s dad is from Japan and he really likes his kid. He’s so protective, and sometimes he worries so much about security of his child, that his child can’t develop normally because of him. C is also like older brother to Ruby and helps him a lot when he’s stuck.

PHP is one of the weirdest kids out there. He’s there, loves C, but rarely hangs with him or asks for help, mostly because he never needs it. He’s smallest, but also one of the fastest, most alive and most popular kids out there. Python and Ruby want to be as popular and fast as he is, when they grow up. Also, PHP doesn’t respect anyone, he is kind of rebel and has his own ways. One time, for example, kids wanted to build sand castle. They all gathered and started to talk how to do it. They mentioned “frameworks”, “scalability”, “paradigms”, “design patterns” and all those other stuff kids talk when they build a sand castles, and suddenly, in the middle of talk, they turned and saw that PHP already built his castle. He just said “Architecture – who needs that” and built it. Ironically, his castle was better and more stable then any of the other castles.

Of course, not all the kids likes C and playing with him. There is this kid called Java. Although he is dependant of C, he think he’s better then him and doesn’t like to ask him for any help. Yes, he is respecting him, but thinks he can do everything on his own. He doesn’t like to play with other children and is very introvert. This is, because when he was younger, he was extremely fat and slow, and other kids always made fun of him. He is not accepted since then. All the kids remember when once one long bearded man, dressed like a hippie calling himself RMS, came to them one day and talked to them that they should avoid Java because he is not open to other kids and speaking on and on about trap they will fall into if they hang out with Java. This made Java grow inferiority complex. Inferiority complex soon developed into superiority complex and that explains his behavior a lot. Since then, Java tried hard to overcome that obesity problem he had and although he’s slim now, scars from bullying and wrinkled skin are still visible. Even today, he tries to be more open, but like it’s all in vain. He doesn’t even want to hear about the other kids, he created his own tools, his own toys that are not compatible with other’s kids toys, even his own part of the playground he calls open and accessible for everyone, and tries to lures other kids to join him, but other kids know that, once you enter his part of the playground, there is no returning back. Because of lack of other kids’ company, he artificially created his own kids from his special DNK called JVM and now plays with them.

There is one other kid who also thinks he’s too good to hang with C. His name is C#. He is just an ordinary kid, but he thinks that somehow, he is more mature then other kids. He wears corporate suit with pink tie and always keep his head high. He doesn’t speak with other children – they are all stupid, idiotic fools for him. He is always surrounded with his fathers, who also wears corporate suits and forbid him to play with other kids. He is very spoiled because he’s very rich and his fathers buy him everything he wants. His suit is always clean because he really doesn’t want to play very much. If, for example, he needs to climb a tree, he just calls one of his dads and order him to buy him a ladder. In fact, he thinks that money is solution to all problems. Other kids despise him because of his attitude and his fathers and even elders don’t want to have anything with him (except maybe some other similar thinking men in corporate suits).

Oh, I almost forgot one other kid. His name is Visual Basic. Unfortunately, he is retarded. He just sits all day long by the sandbox, with his head low, drooling in sand and hitting himself in head with his hand. Poor kid.

This is my take to replicate this behavior in Java:

public class WarningPasswordField extends JPasswordField {
	private static final long serialVersionUID = -4334432525061916434L;
 
	private final int verticalInsets = 5;
	private final int rightOffset = 4;
 
	private BufferedImage warning = null;
 
	public WarningPasswordField() {
		super();
		try {
			InputStream is = this.getClass()
					.getResourceAsStream("/warning.png");
			if (is != null) {
				warning = ImageIO.read(is);
			}
		} catch (IOException e) {
		}
	}
 
	@Override
	public void paint(Graphics g) {
		super.paint(g);
		if (warning == null) {
			/* image is not loaded, behave like a normal password field */
			return;
		}
		if (!this.isFocusOwner()) {
			/* don't paint warning icon if we don't have focus */
			return;
		}
 
		boolean capsLockOn = false;
		try {
			capsLockOn = Toolkit.getDefaultToolkit().getLockingKeyState(
					KeyEvent.VK_CAPS_LOCK);
		} catch (UnsupportedOperationException e) {
			/* workaround sun java bug 5100701 when using XToolkit */
		}
 
		if (capsLockOn) {
			int width = this.getWidth();
			int height = this.getHeight();
			int iconSize = height - 2 * verticalInsets;
			int dx1 = width - (iconSize + rightOffset);
			int dy1 = verticalInsets;
			/*
			 * fill white rectangle where image will be, so password stars are
			 * not visible if image is transparent
			 */
			g.setColor(Color.WHITE);
			g.fillRect(dx1, dy1, iconSize, iconSize);
			/* draw warning image */
			g.drawImage(warning, dx1, dy1, dx1 + iconSize, dy1 + iconSize, 0,
					0, warning.getWidth(), warning.getHeight(), null);
		}
	}
}

As you can see, paint method is overridden and that’s basically it.  Because warning icon’s position is dependent on used look & feel, I left two constants so you can tweak its position. If warning icon can’t be loaded, this code fails silently. I used warning icon from Gnome project, but it could (obviously) be any icon. So here is how it looks (this is nimbus L&F):

Hope you like it and hope it will integrate quickly and nicely into your code;)

Note: RTL languages are not supported, icon there should probably go to the left!

Превод је под Attribution Non-commercial Share Alike лиценцом.

Гном 2.28 је скоро изашао, превод се стишао, превели смо шта смо превели, о томе ћу неки други пут. Пред нама који преводимо Гном су се сад отвориле неке нове могућности јер смо добили више времена. Прва опција је била преводити основни скуп Гномових модула до краја. Од непреведених програма из главног скупа Гномових модула су остали само Анјута (C/C++ IDE) и Орка (читач екрана са особе са посебним потребама). Не треба рећи да су ово програми најнижег приоритета. Поред њих, има доста „великих“ непреведених програма који нису део главних модула Гнома, али се налазе на Гномовом сајту. Примери су Диа и Tracker. Трећа опција је била само поправљати постојеће преводе, а четврта превођење документације. Документацију за Гном програме немамо преведену и ту нико никад није ништа радио (осим документације за 2 програма која је рађена пре пар година и која од тад није ни дирана и практично није ни употребљива више). Расправљало се шта радити даље. Кључно питање је било: да ли је, гледано са корисничке стране, битније да имамо преведену Анјуту, Диу или документацију за нпр. Калкулатор или уређивач текста, тачније како максимизовати постојеће ресурсе које имамо, а да се то највише осети и буде од највеће користи код крајњих корисника. Милош Поповић је био за превођење додатних програма из Гном пакета, док сам ја кренуо на документацију. Наравно, ови избори нису стриктни ни искључиви, свако од нас ту ради све.

Анализа превођења документације

Ово што сам одабрао је практично посао без краја и немам никаквих сумњи да он неће бити завршен наредних пар година (нарочито ако останемо са овим бројем преводиоца). Пре искустава са превођењем Гном документације, прво бих ставио на папир све предности и мане превођења документације. Па идемо, предности су:

• Јасно су дефинисане целине и редослед превођења (кренемо од превођења документације најважнијих програма ка мање значајним).
• Много је лакше проверавати и прегледати ове преводе (своди се на превођење .po датотеке, изградњу .xml датотеке и њено покретање у `yelp`-у).
• Колико се мени чини, документационе ниске се много ређе мењају од ниски за превођење из програма (оне две горепоменуте преведене документације рађене у 2.14 и даље имају доста ниски које се нису мењале, што не верујем да би ниске из програма могле да постигну – толико да се држе), мада је ово можда и варка.
• Превођењем документације ћемо добити прилику да прођемо и кроз преводе програма и исправимо грешке које тамо нађемо).

Мане код превођења документације су:

• Документација је огроман залогај и не треба улазити у њу са жељом да се преведе све. Треба је разбити у мање целине и тако је радити; другим речима, не треба ниједног тренутка помислити да ће она икад бити готова.
• Превођење документације је тотално другачији посао од превођења програма – много је тежа, већа, мора се пазити на термине коришћене у програмима, морају се радити слике..

Ово разлагање на предности и мане сам писао за потребе образлагања на дописној листи пре него што сам започео превођење и нешто сам погодио, нешто не, видећемо касније шта је стварност, а шта сам лоше претпоставио.

У интерном договору са Милошем, ухватио сам се да радим превођење игрица, тј. Гном пакета gnome-games. Он је већ разбијен на документацију за сваку игрицу посебно, оне су релативно мале, а завршавање тога би заокружило једну целину. Кренуо сам тако да преводим игрице, једну по једну, крећући од оних са најмање ниски за превођење – Слагалицу, Клотски, Гном Исто-исто, Гном тетрис… У тренутку писања овог текста, ни пола игрица није преведено, али циљ који сам задао сам себи је да се за Гном 2.30 заврше бар игрице, ако не и још нешто. Ево шта сам притом закључио.

Искуства

Све наредно што напишем за моја искуства је везано искључиво за превођење игрица, али верујем да је ситуација иста или слична и за превођење документације и осталих програма. Прво морам да кажем – превођење документације није тако тешко као што се мени чинило пре него што сам почео. Штавише, лакше је од превођења програма. Наиме, ниске су дугачке, чине потпуне реченице и јасан је контекст у коме се јављају. Ово није случај са превођењем програма где често имате само једну реч коју треба превести, па морате да се довијате да видите где се та реч види, на ком је дијалогу, да гледате изворни код, да изградите новије издање програма да бисте схватили „шта је писац хтео да каже“… Друго, у свакој .po датотеци имате 20-30 ниски које можете да умножите/убаците одмах из других програма – то су углавном ствари везане за лиценце (ту ми је помогао превод постојеће документације где је лиценца већ била преведена), аутори програма и документације који се не преводе, брдо ствари везаних за пријављивање грешака које су увек исте, а углавном се деси и да треба само превести обичне арапске бројеве. 20-30 не делује као много, али пошто преводи за игрице имају у просеку 100-150 ниски, ово је солидан проценат, а и значи, гледано са психолошке стране.

Оно што није једноставно, а што сам ја мислио да ће бити једноставно је прегледање готових превода са `yelp`-ом. Наиме, никако нисам успео да натерам програм `po2xml` да од .po датотеке изгенерише .xml. Вероватно је до мене, да не давим, проблем сам решио користећи jhbuild који ионако имам за потребе превођења програма. Дакле, овде сам омануо, преглед превода није једноставан. Наравно, вреди наместити jhbuild јер гледање превода у `yelp`-у не може да се мери са гледањем превода у програму за превођење – одмах се виде све грешке у куцању! Био сам у праву да ће превод документације да поправи преводе програма, нашао сам на једном месту да је „Score“ преведен као „Разултат“ (и ту ниску нажалост тренутно користе све игрице на 2.28!) уместо „Резултат“ и то се видело на снимку екрана. Одмах је послат печ на проклете лажи.

Кад смо код снимака екрана, могу рећи да је то најзанимљивији део . Снимци екрана које сам до сада радио су некад захтевали снимке екрана решених игрица, па човек мора да се довија како да реши игрицу – или да научи да је игра, или да се снађе. За неке игрице сам морао да их решавам да бих добио жељени снимак (ух, како сам се у том тренутку глупо осећао , за неке сам варао, па сам ишао на „Савет“ или „Помоћ“ ). Такође, за разлику од превода, слике морају да се раде и за ћирилицу и за латиницу, јер се не могу аутоматизовано транслитерализовати, тако да је до оног ко ради снимке да уради паралелно снимке и за ћирилицу и за латиницу. Углавном, кад се превод заврши, ово му дође као неки мали одмор и шлаг на торту, завршна тачка на ваш превод. Једна ствар на коју се мора пазити при превођењу ниски које имају референце на слике (и остале референце уосталом) је да референце морају да буду у номинативу. Нпр. превод следеће ниске:

Starting <application>GNOME Tetravex</application> opens the <interface>Main window</interface>, shown in <xref linkend=”mainwindow-fig”/>.

не може да буде:

Покретањем <application>Гномове слагалице</application> се отвара <interface>Главни прозор</interface>, који је приказан на <xref linkend=”mainwindow-fig”/>.

јер би то завршило као:

Покретањем Гномове слагалице се отвара Главни прозор, који је приказан на Слика 1.

Ту или мора да се мења конструкција реченице („који приказује Слика 1“) или, што је још боље Милош предложио, а ја усвојио као најбоље решење, да такве реченице референцу имају у загради, што би на овом примеру гласило:

Покретањем Гномове слагалице се отвара Главни прозор (Слика 1).

Још неке мање битне ствари које могу да поменем су да треба пазити код превода низводно. Иако Гномов превод има једну ниску на један начин преведену, преводиоци низводно (нпр. Убунту тим) могу да је измене, па је тако Гномов тим превео игрицу „Tetravex“ као „Слагалица“, а у Убунтуу је то некако постало „Тетравекс“, тако да је то мало незгодно приликом превођења и приликом прављења снимка екрана (ако користите Убунту, наравно). Ово ми се само десило на овом примеру и ниједном више, али треба пазити дефинитивно. Такође, слање превода на проклете лажи је мало теже јер се поред .po датотека шаљу и слике. Проклете лажи имају могућност да приказују разлике превода одмах на сајту, али не и када се .po датотека и слике спакују заједно, тако да смо се договорили да се посебно шаље .po датотека, да бисмо могли да прегледамо разлике, а посебно спаковане слике јер нам за њих прегледање разлика није битно.

За крај

Дугачак текст, ако сте га целог прочитали – свака част. Пошто вероватно нећете ручно градити цео Гном да бисте видели превод документације на делу, а као награду што сте прочитали све довде (правићемо се да нико није варао и само клизао до краја текста ), ево и снимка како превод документације изгледа на делу. Уживајте!

I took that code thinking that it will be easy. Long story short, with a complete rewrite, I managed to add fade out opacity. It turned harder then I thought it will be. Principle is the same – draw start image once and then refresh lower part every 25ms to make animation effect. In every frame, we go top down and for every row, new value of offset is calculated based on sin function. Frequency is set so one complete sine period is always shown.

Interesting thing is, I also managed to slow down complete animation by factor of 5-10x. Why is that? Original example uses drawImage() function and draws row-by-row. Because I use alpha channel, I had to resolve to putImageData() function (is this can be done with drawImage()?) and use it for every pixel! Basically, if image is 250×50, original example have 50 drawings (for every row) and I have 12,500 pixel putting in image data. Needless to say, bigger images will hardly be of any value for this effect with this approach.

Once again, you can see it for yourself and look at the code here.

Guys that wrote Openfire also wrote Smack – also open-source XMPP client library, and now there is PubSub extension for Smack. It’s fairly new, but as I test it, it does a nice job;  although I didn’t test any funky scenarios, all that I tried worked and there were no surprises or hidden gotchas. You can find library here for now, but good resources for starting can also be found on theirs community forum here and here. Working with Smack’s PubSub extension is fairly easy (as with Smack in general). Before I post code, just to list some prerequisites in order to try this – you will need to have Jabber server with PubSub ability (if you don’t have one, I’d be happy to offer you to play on mine) and to create two test accounts on it – one for publishing, one for receiving. Create new project, add smack’s libraries and put this:

public class PublisherTest {
    public static void main(String[] args) throws XMPPException {
        // connect as publisher
        ConnectionConfiguration config = new ConnectionConfiguration("kokanovic.org", 5222);
        XMPPConnection connection = new XMPPConnection(config);
        connection.connect();
        connection.login("publisher", "123");
 
        // needed first time only to configure node
        ConfigureForm form = new ConfigureForm(FormType.submit);
        form.setPersistentItems(false);
        form.setDeliverPayloads(true);
        form.setAccessModel(AccessModel.open);
 
        // create node (comment second line and uncomment third to just get already created node
        PubSubManager manager = new PubSubManager(connection, "pubsub.myserver.org");
        LeafNode myNode = (LeafNode) manager.createNode("MyNode", form);
        //Node myNode = manager.getNode("MyNode");
 
        SimplePayload payload = new SimplePayload("event", "pubsub:test:event",
            "" +
            "<title>New blog post</title>" +
            "<desc>Stalker published new blog post</desc>" +
            "");
 
        // putting null for id means you let server generate id
        PayloadItem item = new PayloadItem(null, payload);
 
        // you could use publish() for asynchronous call
        myNode.send(item);
    }
}

Receiver is similar, but a bit simpler:

public class ReceiverTest {
    public static void main(String[] args) throws XMPPException {
        // connect as receiver
        ConnectionConfiguration config = new ConnectionConfiguration("kokanovic.org", 5222);
        XMPPConnection connection = new XMPPConnection(config);
        connection.connect();
        connection.login("receiver", "123");
 
        // start listening for published items
        PubSubManager manager = new PubSubManager(connection, "pubsub.myserver.org");
        Node eventNode = manager.getNode("MyNode");
        eventNode.addItemEventListener(new ItemEventListener() {
            @Override
            public void handlePublishedItems(ItemPublishEvent items) {
                for (Item item : items.getItems()) {
                    System.out.println(((PayloadItem)item).getPayload().toXML());
                }
            }
        });
 
        // you will need this first time only
        eventNode.subscribe("receiver@myserver.org");
 
        // do not die on me!
        while(true){
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {}
        }
    }
}

Future of PubSub…well, it depends, and it heavily depends now of Google Wave. Don’t get me wrong, future of XMPP is secured now Google Wave is there (in fact, it was secured with Google Talk:), but future of PubSub will depend of direction Google Wave will take, e.g. will it somehow take over PubSub responsibilities and functionalities. Truth is, PubSub is not nearly utilized as it could be, and my opinion is that it’s because no big player stands behind it, no big player stands behind any implementation – there are just no “enterprisy” component in PubSub. Google Wave aside, I have no doubt that PubSub will be more and more popular, it’s its open nature and great architecture that directs to that conclusion. Also, don’t for a moment think users will ever be aware of PubSub, just as they are not aware now of XMPP protocol while chatting in Google Talk. PubSub will be somewhere down under, happily collaborating with Jabber server, Jabber client libraries and happy developer that uses it. Just think what can be done with it – from writing bots that respond to events, to turning your toaster on and off. Possibilities are endless.