Blogroll

Oldalak

Archívum

Meta

Kategóriák

2014. április
H K S C P S V
« dec    
 123456
78910111213
14151617181920
21222324252627
282930  

Utolsó bejegyzések

GeoKarácsony 2014

Ismét eljött a találgatások hónapja, pár napja elindult az idei geokarácsonyfák utáni nyomozás. 2010-ben erősen rákattantam a témára – és most is van ötletem… :-)

Amit eddig megtudtunk, az néhány szám (2025, 2033, 1595, 692, 1573, 115), és a megtalálásuk körülményei (elégett irományok darabjain szabad szemmel olvashatóak). Hamar geoládászhoz méltó ötletek születtek. A legfontosabbak:

tekan 2013.12.02 18:45
Nem hiszem, hogy postai irányítószámok, azok Magyarországon mindig 4 számból állnak. Én inkább valami azonosítófélére gondolok. POI-kat, felhasználókat kizárhatnánk, mivel van olyan szám, amihez nem létezik. Így maradtak a ládák (azok sem id szerint hanem sorszám alapján). Ezek meghatározhatják város/környék szinten a helyszíneket: Székesfehérvár, Budapest, Szeben, Tevel(Pápa), Debrecen, Hegyestű (Balaton-felvidék). Kb stimmelne is, de nincs baranyai.

illetve

police107 2013.12.03 11:51
Meglehet hogy láda sorszámok,de a 1595 nagyon kilóg.Az egy erdélyi láda.Bár ki tudja miben mesterkedik a Jézuska.
2025 GCMT
2033 GCRAPA
1595 GCSZBN
692 GCVIKA
1573 GCTto
115 GCHGTU

 

Meggyőződésem, hogy az irány nagyon jó: a fákhoz (vagy a találkozópontokhoz) legközelebbi geoládákra utalnak a számok.

Geoláda sorszámok?

Viszont én inkább a geoláda azonosítókban hiszek. Van ugyan egy apró probléma: nincsen olyan 115-ös id-jű publikus geoládánk. Ám itt jönnek képbe a megtalálás körülményei: lehet, hogy csak “115″ az eleje, de utána még van számjegy, csak elégett! :-) Hogy néz ki ez a térkép?

Geoláda id-k?

Ebben az esetben a helyszínek: Sopron, Zalaegerszeg, Veszprém, Siófok, Bóly, Vác.
Számomra ez hihetőbb, mert

1. Van baranyai helyszín. :-)

2. Van somogyi helyszín.

3. Van Pest megyei helyszín.

 

Jöhetnek az újabb infó-morzsák! :-)

DevGeo 20131127

A DevGeo mostani része az API specifikációjának kidolgozása során nem mellőzhető szempontok összeszedését kísérli meg: egységes szerkezetben. (pdf, csak geocaching.hu felhasználók számára)

7. API követelmények

Ebben a szakaszban a 2. fejezetben felsorolt fő alapelvek API-ra vonatkozó részeit, illetve azokat a szempontokat szedem össze, amelyeket a specifikáció kidolgozása során nem szabadna figyelembe kívül hagyni.

7.1 A fő alapelvek API-t érintő kitételei
Az általános elvek közül főként a következők fontosak:
- A felhasználói adatok (különösen jelszó, email-cím, telefonszám, lakás/tartózkodás koordinátái) védelme.
- Átmeneti időszak biztosítása a külső fejlesztések migrálására (jelenleg a honlap aktuális megjelenése az API, amire épültek a fejlesztések – tehát addig ne változzon, amíg nem alkalmazkodtak a fejlesztők).
- Az API kialakításába a partizánok bevonása.

7.2. Az API fejlesztési elvei
- Kompatibilitás – azaz amit egyszer megcsinálunk, az ne veszítse el a funkcionalitását, egy verzióváltás ne tegye tönkre az API-ra épülő fejlesztéseket, ne kelljen gyakori és átgondolatlan migrálásokkal terhelni az API-t használó fejlesztőket.
- Közösségi modell – azaz a koncepció a lehető legtöbb érintett felhasználó (értsd: fejlesztést végző API-felhasználó) bevonásával készüljön, a tesztelési lehetőség eleve legyen betervezve a megvalósításba, készüljön el már az első programsorok kódolása közben, „több szem többet lát” alapon történjen a tesztelés majd az optimalizálás.
- Szabványosság – azaz a megvalósítás a lehető legteljesebb mértékben alkalmazkodjon a de facto internetes szabványokhoz (Request For Comments, RFC) és a bevett gyakorlathoz (best practices), például a státuszkódok, a GET/HOST/HEAD kérések, a cache-kezelés terén.
- Adatvédelem – azaz az API ne nyújtson lehetőséget a felhasználók személyes adatainak illetve az általuk közzétett tartalomnak a jogosulatlan megszerzésére, felhasználására – de legalábbis ne könnyítse meg azt.
- Gazdaságosság – azaz a céljait a rendelkezésre álló erőforrásokkal (processzoridő, tárhely, sávszélesség, programozói/rendszerfelügyeleti kapacitás) a lehető leggazdaságosabban bánva valósítsa meg.

DevGeo 20131122

A DevGeo legfrissebb része néhány fontos architekturális szempont felvetésével lassan áttér a jelen elemzéséről a jövőről való gondolkodásra: egységes szerkezetben. (pdf, csak geocaching.hu felhasználók számára)

6. Architekturális megfontolások

Az eddigiekben főként a jelenlegi helyzet, mind kiindulási állapot elemzésével foglalkoztam. A következőkben az előttünk álló feladatokkal kapcsolatos szempontokra térek rá.
6.1. Újraírás
A forráskód ismeretének híján, pusztán részinformációk birtokában csak valószínűsíteni tudok – de nem hiszem, hogy messze járok az igazságtól, amikor úgy vélem, hogy a portál motorja egy organikusan nőtt, dzsungel-szerű szövetet alkot, amelyben sok-sok év egymásra rakodó rétegei, kreatív átkötések, optimalizálások egy nehezen karbantartható, nehezen továbbfejleszthető rendszerként élnek önálló életet. Valószínűleg elkerülhetetlen egy teljes újraírás: gazdaságosabb a játék évtizedes története alatt letisztult követelmények alapján az újraalgoritmizálás és -kódolás, mint a meglevő kód összefüggéseinek kibontása és az újabb fejlesztések óvatos beillesztése.
Az újraírás – amellett, hogy komoly feladat, amely sok munkát és „némi” pénzt is igényel – egyúttal lehetőség is: lehetőség arra, hogy jól dokumentált, letisztult szerkezetű, fejleszthetőbővíthető rendszert hozzunk létre.
—————–
Most már valóban az API követelményi következnek. :-)

DevGeo 20131120

A DevGeo legújabb fejezete a jelenlegi autentikációs eljárásokat értékeli: egységes szerkezetben. (pdf, csak geocaching.hu felhasználók számára)

5. Jelenlegi autentikációs eljárások

Nagyon fontos kérdés, hogy a honlap mely adataihoz kik férhetnek hozzá. Ennek alapja a felhasználók/kliensek azonosítása, az autentikáció. Jelenleg négy autentikációs szinten lehet
hozzáférni az oldalhoz.

—————–
A következő fejezet már előretekint: az API iránt támasztott követelmények összefoglalására tesz kísérletet.

DevGeo 20131119

Újabb résszel folytatódik a DevGeo, ezúttal megkísérlem levonni az utóbbi hetek javítási, fejlesztései próbálkozásainak tanulságait: egységes szerkezetben. (pdf, csak geocaching.hu felhasználók számára).

4. Eddigi fejlesztések értékelése

A portál első szakaszára (tehát a Kumin Ferenc, Feró Viktor és Kolesár András által végzett fejlesztésekre) nem térek ki, ahogy a 2011-es sikertelen fejlesztőváltási kísérletre sem.
A vizsgált időszak kezdete a 2013. októberi 24-i elnöki bejelentés.

—————–

A következő részben az autentikáció témakörét járom majd körül – még mindig a jelenlegi helyzetet elemezve.

 

DevGeo 20131118

A fejlesztői fórumba nem tudok írni, így ebben a formában osztom meg gondolataimat a geocaching.hu fejlesztési kérdéseiről. Az eddig elkészült munkarészek itt elérhetőek (pdf, csak geocaching.hu felhasználók számára).

1. Általános helyzetelemzés

- A honlap alapvető funkcionalitása működik.

- Van néhány hiba, amely a játékosok egy kicsi (de hangos) részének bosszúságot okoz. (A turistautak.hu részen komoly funkcionális hiányosságok is vannak.)

- A honlap jelenlegi formájában nehezen fejleszthető tovább, mert

* több, nem szorosan összetartozó honlap (geocaching.hu, turistautak.hu és talán még a muemlekem.hu is) sok szálon összefonódik – a különböző fejlesztési igények, modellek, az eltérő felhasználói szokások nem kompatibilisek;

* a megjelenítés és a tartalom keveredik, nincsenek határozottan elkülönítve – bizonyos elemek „bele vannak drótozva” a kódba;

* a fejlesztés időben annyira sok éven át tartott, hogy közben a fejlesztő is fejlődött, ráadásul peer review nélkül, csak a kimeneti oldalon ellenőrizték – így a kód különböző színvonalú részeket tartalmazhat, esetleg szokatlan, egyedi megoldásokkal, a valószínű kommentek ellenére is nehezen értelmezhető részekkel.

- A fejlesztés szervezeti részletei nem tisztázottak – vagy csak szűk körben ismertek. Az üzleti és a közösségi fejlesztési modellek nyomai is felfedezhetőek: van egy, az egyesülettel valamilyen szerződéses kapcsolatban álló fejlesztő, de van egy szűkkörű – talán tíz-húszfős – fejlesztői közösség is. Egy ötfős döntéshozó szerv (elnökség) határozza meg a résztvevők személyét és az elvégzendő feladatokat, de ennek az öt főnek sem a szorosan vett szakmai kompetenciájáról, sem a stratégiai céljairól nincsen publikus adat.

- A honlap szolgáltatásaira, tartalmára, felhasználóira az elmúlt évek során készültek esetleges, nem koordinált fejlesztések (továbbiakban: partizánok). Bár nem áll mögöttük hivatalosan MGKE-támogatás, de a változtatások során nem célszerű figyelmen kívül hagyni ezeket, mert sok felhasználó számára értéket képviselnek (időmegtakarítás, kellemesebb játékélmény).

—————–

További kidolgozott részek:

2. Fő alapelvek

3. Jelenlegi alkalmazások elemzése

GCAuth

1. Mi a GCAuth?

Lényegében egy kényelmi szolgáltatás: a geocaching.hu felhasználói külső honlapon is azonosíthatják magukat a nickjükkel – akár két kattintással.

2. Kinek szól ez a leírás?

A geocaching.hu/turistautak.hu felhasználóinak többlet-szolgáltatást nyújtani szándékozó weblapok programozóinak.

3. Kinek nem szól ez a leírás?

Az imént említett szolgáltatásokat igénybe venni kívánó felhasználóknak.

4. Miért jó?

* Nem kell kiadni a jelszót egy külső lapnak.
* Nem kell újra végigcsinálni a regisztrációs procedúrát.
* A meglevő (ismert) nicket a gazdája (és csak ő) használhatja – más nem nyúlhatja le azt előle.

5. A megvalósítás

5.1. A külső honlapról a GCAuth oldalra irányítjuk a felhasználót:
http://geocaching.hu/token.geo?next={url}&scope={secrets}
* next: az url, ahová hitelesítés után visszatér a böngésző;
* scope: az adatok, amelyeket a gc szervertől szertnénk megtudni, szóközzel elválasztva (pl. “username”)
(Az url és scope paraméterek természetesen urlencoded formában legyenek.)
Pl. http://geocaching.hu/token.geo?next=http%3A%2F%2Forokseg.net%2Falappont%2Findex.php&scope=username

5.2. A gc szerver válaszában a megjelölt URL-re irányítja a böngészőt, két új paraméterrel:
{url}?id={user_id}&token={token}
* id: a geocaching.hu-s numerikus felhasználói azonosító;
* token: véletlenszerűen generált karaktersorozat hexadecimális formátumban;
Pl. http://orokseg.net/alappont/index.php?id=17615&token=06aa8ca3b88b8fd00c1be319938275cf

5.3. A külső szerver meghívja a gc szervert (pl. PHP-ban file_get_contents() függvénnyel):
http://geocaching.hu/token.geo?site={host}&action={secrets}&id={user_id}&token={token}
* site: az előző (1.) kérés “next” paraméterének host része;
* action: az előző (1.) kérés “scope” paramétere;
* id: az előző (2.) válasz “id” paramétere;
* token: az előző (2.) válasz “token” paramétere;
Pl. http://geocaching.hu/token.geo?site=orokseg.net&action=username&id=17615&token=06aa8ca3b88b8fd00c1be319938275cf

5.4. A gc szerver válasza: a kért adat vagy hibaüzenet.
* Siker esetén a kapott válaszból PHP unserialize() függvénnyel egy tömböt kapunk.
* Kudarc esetén magyar nyelvű hibaüzenet érkezik.
Karakter kódolás mindkét esetben ISO-8859-2.

6. Megjegyzések

* Ez a négy lépés csak a legelső használatnál szükséges. Ezután – a token visszavonásáig – elég a 3. és a 4. lépést végrehajtani.
* Ha a külső szerveren van lehetőség session kezelésre, cookie-k használatára, akkor elegendő csak egyszer igénybe venni a GCAuth-ot. A 4. lépés sikere esetén küldhetünk egy egyedi cookie-t a böngészőnek, amellyel legközelebb azonosítani tudja magát – így nincs szükség további kérésekre a geocaching.hu felé.

7. Hol próbálható ki?

A példákban megjelenő orokseg.net honlapon már 2011. február óta “élesben” működik.

Először publikálva:
2011. július 16., 19:48

http://turistautak.hu/wiki/GCAuth

Mennyi az annyi?

Bár már lényegében hozzászoktam, hogy bármilyen megnyilvánulásom indulatokat kelt, a mai eset mellé megpróbálok néhány észérvet felvonultatni.

A probléma
A mai napon 10:03-kor megjelent török-vári geoládámnak a Háromezredik geoláda nevet adtam. (A délután folyamán ezt először pontosítottam Háromezredik geoláda (Török-vár)-ra, majd megváltoztattam helyett 3000. geoláda: Török-vár névre.)

A kifogás
A moderáción a láda GCTV, Török-vár néven ment át – ezt nem volt jogom megváltoztatni. (Szélsőséges vélemény szerint meg is kellene szüntetni.)

A valódi ellenvetés
A július 2-án, a 2990. sorszámú A Szent Háza (Houses of the Holy) geoláda után 3000. sorszámmal megjelent GC3000 rövid névvel jelölt A 3000-es szikla szeretne a háromezredik geocaching.hu-s geoláda lenni. Így további háromezredik geoláda megjelentetése nem engedélyezett.

Egy kis “történelem”
Ahogy azt már több fórumon szóvá tettem, a most július 2-i eset nem az első sorszám-ugrásos történet volt: 2009. július 4-én 18:15-kor, 2500. sorszámmal jelent meg a Galyatető nevű láda – holott a közvetlenül előtte (11:40-kor) megjelent Metró4 láda még csak a 2484. sorszámot viselte. Ez volt az a pillanat, amikor a ládák addigi két “önkényes” és két “automatikus” azonosítója három önkényes és egy automatikus felállásra változott:
- id: automatikus, a ládaterv moderációra történő első benyújtásakor keletkezik – a tervek bejelentésének sorrendjét tükrözi;
- sorszám: korábban automatikus volt, a geoláda publikálásákor keletkezett – a ládák megjelenésének sorrendjét tükrözi;
- rövid név (útpont név): önkényes, bár a szokás alapján valamilyen kapcsolatban van a teljes névvel vagy a hellyel, témával;
- geoláda név: önkényes, bár a szokás alapján valamilyen kapcsolatban van a hellyel, a témával és önmagában értelmes kvázi-cím.

A válasz
A GC3000 rövid nevű láda nem a háromezredik geoláda – pusztán a 3000. sorszámot kapta. A háromezredik geoláda (amely mellesleg a 2999. sorszámot viseli) ma délelőtt jelent meg a Máriakéméndhez tartozó Török-vár nevű dombon. Múlt hétvégén a hazai gc közösség megünnepelte az első magyarországi geoláda megjelenésének tizedik évforduióját. Az eseményt színesítette egy, a fesztivál befejezése után is kereshető, (GC3000 rövid nevű, 3000. sorszámot kapott) láda. Ezeket a tényeket felesleges összekeverni, hiszen nem ugyanarról van szó. Jól látszik, hogy nálunk a sorszám szó mást jelent, mint máshol.
Egy szó különböző jelentései gyakran okoznak vicces helyzeteket. Ld. pl. itt:
Én vagyok én. Te vagy te. Ki a hülyébb: én vagy te?
Szerintem legjobb lenne, ha mindannyian egy jót nevetnénk. Már kezdem is: :-))))))))

Vérpallos és csattogó olló

Az este folyamán volt szerencsénk megismerni, hogy a hazai geocaching-re köszöntött szép, új világban hogyan is képzelik a fórummoderációt. Persze, egy-két ollócsattogás akár véletlen tévedés is lehetne – de ha teljes mellszélességgel mögéállnak, akkor talán csak elárul valamit a mélyben bugyogó gondolati áramlatokról.
Tehát a társalgás fő indítógondolata:

Olyan listát keresek, ahol azok a szervezetek szerepelnek akiknek lehet az 1%-ot küldeni. Tud ebben segíteni valaki.

(forrás)
Innen diego – Fairy – diego – H.Gábor vonalon csordogált a társalgás. Az utolsó hozzászólás egy utalást tartalmazott a közismert mondásra/igére: “Adjátok meg a császárnak, ami a császáré, és az Istennek, ami az Istené!”
Erre két nagyon friss regisztációval, két nem szokványos nick-en érkezett hozzászólás:
“Isten” hozzászólásai | válasz erre | 2011.03.21 20:40:23 (22040)
Köszönöm, Fiam!
[előzmény: (22039) H. Gábor, 2011.03.21 20:28:42]
Majd:
“Császár” hozzászólásai | válasz erre | 2011.03.21 20:45:48 (22041)
Én is, Fiam!
[előzmény: (22040) "Isten", 2011.03.21 20:40:23]

Lassan érkeztek a kritikai észrevételek:
Yoss, Gabe, majd feri60 is megérkezett – a “Vének Tanácsa” felvette a jól bevált Sün!- Sün!- Sün!- figurát.

Egy nem kicsit provokatív hozzászólás hatására megindult egyfajta tartalmi vita: vajon jogos volt-e a moderáció? Old Eye és zakany megjegyzéseitől (és néhány OFF-OFF hozzászólástól) kísérve eljutottunk egy közbenső konklúzióig:
“Egy szónak is száz a vége: megalapozatlannak tartom a törléseket.”

Hamarosan újabb “vén” jelent meg, Csuhás személyében, majd zárásként Attibati személyében egy elnökségi tag is megnyilvánult. Idézem:
“Most meg azt kellene észrevenned, hogy egy hozzászóló sem osztja az álláspontodat és ez mostanában nem először történik meg a gc fórumain. Le kellene vonnod a következtetést…”

No, nézzünk egy kis statisztikát, 14:55:20-tól 2011.03.22 00:44:47-ig 60 db hozzászólás született. Nickenként: Fairy- (15), Old Eye (8), Juju (5), H. Gábor (5), “Isten” (4), Gubirobi (4), zakany (4), feri60 (3), Yoss (2), diego (2), halaszkiraly (2), Csuhás (1), LionDaddy (1), Tototo (1), Gabe (1), Attibati (1), “Császár” (1), Mikulás (1).
Összesen hozzászólt: 16 fő. (LionDaddy és Tototo teljesen más témát vetett fel.)
A 16 főből MGKE-tag: 9 fő (44 hsz.), nem tag: 5 fő (10 hsz.), nem egyértelmű: 2 nick (5 hsz.).

Hát, ezek az adatok. Most próbálom levonni a következtetést…

Nem. ilyen lovat…

Nincs valami nagy szerencsém ezzel az egyesületesdivel…
1. Javasoltam a műemlékem.hu MGKE-től magánvállalkozáshoz történt átjátszásának kivizsgálását:

“Mindenestre úgy látszik, hogy nem sok esély van vizsgálóbizottságok felállítására. Március végéig szeretnénk lezárni a felelősségrevonásokat hogy utána már teljes erővel a játékkal tudjunk foglalkozni.”

2. Javasoltam a tuhu (egyesületen belüi) szervezeti autonómiáját:

“Az Elnökség nem támogatja ebben, szerintünk eddig is jó volt a viszony, mindenki elismerte a munkájukat és minden szükséges támogatást megkaptak az egyesület lehetőségein belül.”

(forrás (csak rendes tagoknak látszik))
3. Javasoltam az elnökségen belül informatikai felelős kijelölését:

“Az informatikai alelnök, mint pozíció meg szerintem tökéletesen felesleges dolog. Elégy hülyén veszi ki magát, hogy megbízunk egy embert, céget, legyen az akár András akár más és vele kvázi főállásban egy ALELNÖK foglalkozik? Normális esetben nincs is dolga, max évente kialkudni a jövő évi árat, meg továbbítani a fejlesztési igényeket. Nincs ez kicsit túlspilázva?”

Az alappontos projekt honlapterv (gc-s regisztrációval látható) vagy az alkotmánytervezet negligálásáról már nem is beszélnék…

Not found!

Could not find the requested page. Use the navigation menu to find your target, or use the search box below:

Site search