Hoplax - power user könyvjelző megoldás

Szerszám

Mindig zavart, hogy a többi konfigurációs fájlommal ellentétben, a könyvjelzőimet a böngészők nehezen kezelhető, nem szinkronizálható, bináris formátumban tárolják. Ugyanakkor nagyon jó web automatizációs megoldásnak tartottam a keyword bookmarkokat és szerettem volna őket még több funkcióval felruházni (több paraméter, automatikus kiegészítés).

Ezen igények alapján kezdtem pár hónappal ezelőtt a Hoplax fejlesztésébe.

Van online, telepítés nélkül működő verzió, felhasználói útmutató gyanánt pedig egy screencast érhető el (a remek magyar akcentsunkkal)

Minden kritikát szívesen hallunk!

( kikke | 2011. 06. 22., sze – 12:37 )

A legjobb dolog az Albert Einstein Bizottság óta.

( Foltos | 2011. 06. 22., sze – 13:21 )

Ide nekem! Ez ütősnek tűnik :)
Nem akartok hozzá google bookmark importert faragni?

( timi | 2011. 06. 22., sze – 13:23 )

Nem lehetett irc-en találni egy natív angol arcot aki felolvassa a szöveget? Hasznos eszköz, az akcentusmentes hangalámondás javítaná az image-t.
A Firefox könyvjelzőket lehet már szinkronizálni. Ez a megoldás viszont többet is tud.

( tompos v | 2011. 06. 22., sze – 16:28 )

A google group nem letezik:

"We're writing to let you know that the group you tried to contact (hoplax) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:"

( hacksagon | 2011. 06. 22., sze – 16:06 )

"Mindig zavart, hogy a többi konfigurációs fájlommal ellentétben, a könyvjelzőimet a böngészők nehezen kezelhető, nem szinkronizálható, bináris formátumban tárolják."

Jó, hogy van HTML export-import. "Csak" az összes böngésző tudja.
-----
A szoftver a számítógép azon része, melyet szidni lehet.

A githubra és ide linkelt videó-prezentáció szól erről. A HTML export általában (hibás) HTML 3 tageket tartalmaz, még csak nem is szabványos XML, nehéz parse-olni. Valamint a tageket nem tartalmazza. Tehát a firefoxban taggelt bookmarkjaid vannak (nekem régen volt ilyen, amíg FF-ot használtam), akkor ez az infó exportáláskor el is veszik.

+1

Plusz az export import messze nem ugyanaz, mintha egy program eleve egy világos struktúrájú fájlt használ.

Hogy csak egy lényeges különbséget említsek, ezzel a megvalósítással megoldhatónak tűnik a verziókezelőben való tárolás, ami másképpen körülményesebb lenne.

Hozzánk nem kell regelni és nem szolgáltatást kapsz, hanem szoftvert. Az adataidat saját magad kezelheted és minden környezetben működtetheted, nem csak az Opera által támogatottban.

Persze, ha te szolgáltatásra vágysz, akkor lehet, hogy az Opera link jobban neked való, ezesetben használd azt. Remek dolgokat csinál az Opera!

( bervi | 2011. 06. 22., sze – 22:21 )

engem az érdekelne, hogy miért van szükség github-ra ÉS google code-ra is?

Ez az információ 80 évre titkosítva van :)

Komolyabbra fordítva a szót: mivel ez egy Google 20%-os projekt, a Google Code oldalon való publikálás erősen javallott a számomra. Ugyanakkor utálom az svn-t és a mercurial-t is, ezért github...

De a kérdés teljesen jogos, engem is zavar ez a kettősség.

Nezd, en most kenytelen voltam belenezni egy projektbe ami mercurialon fut.

Fogalmam nem volt, mi tortenik.

Elotte eveken keresztul vezettem tobb cegnel, tobb csapatnal projekteket SVN-nel, teamleadkent, kesobb architektkent. Mindig tudtam ki mit csinal epp, szepen lehet kovetni egy trac-cal vagy barmivel, van egy logikus idorendje a dolgoknak, tudunk beszelni barmelyik reviziorol (sose hallottam meg embereket az ab031234def021-es revision-rol beszelni), van egy kozponti gondolat a dologban.

Egy linux meretu projektnel mar nem ilyen egyszeru a dolog, de egy kis teamben jo atlatni, mi a fene zajlik vagy kicsuszik a projekt a fenebe.

Kerdes: hogy oldod meg a kovetkezo helyzetet? Van mar egy kiadott release a szoftverbol, es eppen a v2-n dolgozik a csapat. Mikozben egy feature-t implementalsz, az egyik segedfuggvenyben talasz egy hibat, amirol latszik, hogy ez a mar kiadott szoftverben is hibat okozhat, tehat javitani kellene. Git-ben ez annyi, hogy betolod csak a bugfixet a staging area-ba, elcommitolod, aztan cherry pickkel atrakod a stabil branchbe. Ez SVN-nel hogy megy? Ott ha jol tudom eleve el sem tudsz commitolni egy fajlban egy 3 soros modositast kulon, ha magaban a fajlban mashol is van valtoztatas.

Nalunk nincs gond a gitbol, teljesen atlathato, hogy ki mit csinal (van egy halom jo GUI a githez, kezdve a gitk-val egeszen a nagyon durvan jol megcsinalt GUI-kig, mint a Tower), akarhany ember is dolgozzon egy projekten.

Ha tartod azt a szabalyt, hogy minel kisebb commitokat csinalsz (tehat egy dolog egy commit), akkor siman kovetheto marad a fejlesztes, raadasul regressziokat keresni is konnyebb (git bisect).

Megbeszeleseknel a commit valtoztatasairol beszelunk (pl.: az a commit, ami fixeli a #default_value bugot), nem a commit hash-rol vagy akar svn eseten a commit szamarol. Ha irasban megy a megbeszeles, akkor siman jo a hash is, mert svn-nel sem tudod a commitot fejbol, tehat ott is kell olyasmi, mint a git show.

Minden developernel van egy sajat repo. En eszreveszem, commitolom, attolom a stabil branchbe. Onnan felpusholhatom teszt repoba, kerhetek valakit, hogy pullolja tolem es nezze at, workflow kerdese az egesz.

Mi a csunya a kis commitokban?

Azt most ugye komolyan nem akarod itt eloadni, hogy konnyebb megjegyezni egy szamot, mint azt, hogy mi a commit? Vagy nalatok ugy megy a scrum meeting, hogy elotte commitokat magoltok? Egy nap egy fejleszto 5-20 commitot is csinal, ki fogja megjegyezgetni mindet?

Btw: azzal tisztaban vagy, hogy git-nel mi a staging area? Az egy koztes resz a working tree es a commit kozt, ahhoz adod hozza azokat a _valtoztatasokat_ (nem fajlokat!), amiket commitolni szeretnel. Igy lehet parhuzamosan tobb dolgon is dolgozni, aztan amikor parral megvagy, akkor szepen vegignezed a valtoztatasokat, csoportositod es commitolsz.

Jahogy.

Oke.

Nagyvallalati kornyezetben a staging area az a productionnel megegyezo architekturaju fizikai rendszer, ami nem ritkan dupla-buffereles szeruen valik productionne.

Ezert mondtam ra, hogy csunya, hogy egy fejleszto az osszes teszt-kornyezetet megkerulve rogton a stagingbe publikal,ahonnan akar automatikusan is mehet productionbe.

Minden fejleszto szokta latni, hogy nagyjabol hol, melyik revizional tart. Egy SVN rendszerben egy nagysagrenddel kevesebb (napi 2-3) commit tortenik fejlesztonkent, ezek konnyen kezelhetoek.

Lehet azt jatszani, hogy mindenkitol pullolom, es ugy nezem at a kodot, de en jobbszeretem ha erre nekem van egy feluletem.

"Lehet azt jatszani, hogy mindenkitol pullolom, es ugy nezem at a kodot, de en jobbszeretem ha erre nekem van egy feluletem."

Es - voila - erre mar van is felulet a git-hez. A gitorious.org egy ilyen feluletet ad, es a forrasa teljesen nyilt, igy fel tudod rakni a titkos ceges halozat megtitkosabb fejlesztoi gepere.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem kemkedunk programozo utan. A jo kapcsolat alapja a bizalom; ha commitoltal egy central repoba, akkor ezzel te elfogadtad, hogy a csapat minden tagja lathatja azt, amit csinaltal (nem szeretek a csapat barmely tagjanal lenyegesen tobb jogot gyakorolni, egyszeruen mas a munkam es ennyi)

Ezt biztos, hogy nekem cimezted?

Az volt a kerdes, hogy githez van-e olyan felulet, ahol a merge-ket meg a patcheket lehet kezelni. Erre mondtam, hogy igen, van, Gitorious a neve, a forrasa szabadon letolteto a http://gitorious.org/gitorious/mainline cimrol, felrakod, megy. Es nem kell a gitorious.org -ot hasznalni, hanem egy tok privat fejlesztoi szerverre is fel lehet rakni, free hosted megoldas. Nyilvan az aramszamla nem szamit bele.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen, ezt akartam en is irni. Ahelyett hogy leszaroznank, mert nem ismerjuk, erdemes lenne elkezdeni megismerni a distributed version control system-eket. Nekem SVN-rol Git-re egyszerubb volt migralni, reszben mert kepes dolgozni az svn repoval is, mint backenddel, valamint a komplett commit logot 1/1 importalja. Ha jol konfigolja fel az ember, akkor meg tagek es branchek is lesznek, pont olyan strukturaban, mint a svn-ben vannak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen, tenyleg nem ertem mire van ez a dvcs mania, na jo, ez nem igaz.

Ertem en.

Az, hogy legyen egy projektben kozponti narrativa, az nehany esetben fontos dolog. A dvcs-ben ezekrol nehez beszelni.

A projektek nem a verziokezelotol buknak be, hanem attol, ha hagyjuk oket szetkuszalodni. Az SVN picit kevesbe hagyja, en ennyit mondtam.

(Nyilvan mercurial-t is lehet figyelni, de nehezebb atlatni mi tortenik egy dvcs projektben.)

(Szerk: tisztazas kedveert: kozponti narrativa nem feltetlenul csak a trunkrol, stagingrol, stb kell, ezekrol nyilvan van a dvcs-ekbol is. Enteprise kornyezetben kozponti narrativa kell(ene) arrol is, mit csinalt Beluska a szamitogepen az elmult 2 hetben, mert commitot nem latunk tole, ellenben b.ottul szorit a hatarido, es multkor is kiderult, hogy elvonta a figyelmet a legujabb blizzard release. Nyilvan ez fegyelmi kerdes, de feature branchingnel is kell sokszor hogy ne csak a developer lassa, mi tortenik ott.)

Az, hogy legyen egy projektben kozponti narrativa, az nehany esetben fontos dolog. A dvcs-ben ezekrol nehez beszelni.

Van központi narratíva, legalábbis nagyon könnyen kialakítható. A különbség az, hogy normál svn esetében ez kötelezően adott és nincs is más, míg pl. mercurial esetében ha akarod van, ha akarod nincs.

Igen, es itt lesz ket ellenerdekelt fel rogton.

Ketfele jo programozo van ugyanis (egyik felosztas szerint): az egyik jo programozo, es onhajto, a masik jo programozo, csak lusta.

Ha ez utobbinal ha te nem nezel ra naponta, lehetoleg minel passzivabban, hogy mit csinal, akkor hirtelen azt veszed eszre, hogy hatarido elotti napon vagytok, es meg nincs kesz semmi.

(Ha tul aktivan nezel ra, megsertodik, elvegre jo programozo)

Sajnos a feladatok nem tomorodnek a vegtelensegig Kolmogorov bacsinak koszonhetoen, bar tenyleg igyekeznek kitolteni a rendelkezesre allo teret, mint ahogy a lustasag is :)

Erre egy SVN + trac egy alommegoldas, es mivel a munkam 80%-at a lusta, de jo programozk hajtasa, a maradekot pedig a tehetseges, de kezdo programozok finom terelese (bar nehanyan vitatkoznak, mennyire finom) teszi ki, es mindkettohoz az kell, hogy te barmelyik pillanatban ra tudj nezni az epp fejlesztett kodra, a legkor pedig azon mulik, hogy ez mennyire eszrevetlen ha epp jol csinaljak a dolgaikat, ezert nem szeretnem,ha hirtelen ehhez kervenyeket kene benyujtanom.

A helyi repojuk legyen csak szepen a szerveren, mert az backupolva van naponta, dolgok visszakergethetoek napokon,heteken keresztul, mig ha a MAV-nal fennhagyja a kocsiban a laptopjat, mi a francot csinalunk?

Erre van egy tok jo tool, kozpontositott verziokezelesnek hivjak, es ennek a zaszloshajoja az svn.

Nem kell tulragni :)

Van tervbe hogy a kov. projektem githubon fog menni nem a jol megszokott code.google.com -on, de vallalati kornyezetben en minden elosztott megoldastol fraszt kapok; tetszoleges ismert nagyvallalatban a kaosz szintje mindig a mukodeskeptelenseg hataran billeg, mindig minden hiba arra vezetheto vissza, hogy ja azt valaki nem mondta el senki masnak, csak az o gepen volt, stb; sz'al ne akarjuk elosztani :)

Eddig csak 2-3 commit volt egy mercurial alapu borzalomba, meg par sima git clone, git push, meg olvastam posztokat hogy emberek hogy gondoljak ott a branchinget, en meg... jujj... sok projektet lattam en mar bedolni es nagyon halas vagyok az svn-nek hogy segitette a munkamat, ami arrol szolt, hogy a ram bizottakat ne hagyjam.

Sz'al nekem ilyen alapszolgaltatasok kellenenek, mint:
- Csak a kommitolatlan fajloknak nincs szerveroldali masolata
- Nincs demozhato allapotu fejlesztes szerveroldali masolat nelkul
- Featurebranchek is szerveroldalon
Okok:
- A munkaallomasok nem megbizhatoak (ellophatjak, elfustolhet)
- A munkatarsak nem megbizhatoak (lustak)
- A kod nem megbizhato (lehet vacak)
- A hibaknak joval hatarido elott kell kiderulnie (elvaras a napi commit)
- A hibaknak integracio elott mar ismerteknek kell lennie, es nem az integracio elotti feloraban szabad kiderulniuk
- Az integracios problemakat mar a fejlesztes folyamataban fel kell tudni ismerni (siman commit-atnezessel)
- Kell lenni legalabb egy embernek aki pontosan tudja, mi tortenik az EGESZ projektben, es ez az informacio folyamatos (ez en lennek)

Ja, es projektutemet is figyelni kell ugye (az egy gyonyoru elkepzeles, hogy oszd fel apro reszekre, ez papiron qrva jol mukodik, az eletben nagyon nem), sz'al tudni kell, melyik feature hogy halad, es ezt csak koztes kodallapot ismereteben tudod megmondani.

Sz'al erre az SVN egy alomeszkoz; nem tudom, es nem hiszem igazan, hogy a git-et erdemes beidomitani ilyenre.

Szerintem ezzel nincs semmi baj. Csak ne kardoskodj amellett, hogy a git v. a mercurial nem alkalmas ugyanerre, mert egyrészt nem ismered, másrészt nem igaz :)
(az már egy más kérdés, hogy _bizonyos_ feladatokra nyújt-e extra előnyt vagy sem, maradjunk annyiban, hogy legalább ugyanerre alkalmas)

En azt mondtam, hogy itt lesz ket ellenerdekelt fel.

Az SVN ugyanis alkalmatlan barmi _masra_. Ez itt ficsor!

Innentol kezdve ez ugyanis nem megegyezesi, hanem technikai kerdes, amivel kevesebb visszapofazas jar. Jo az.

Neha hibernalnam magam 10 evre, amikor az Agile mar belerohadt abba, hogy intezmenyesitjuk a kaoszt meg jelszavakat kiabalunk egymasnak amiknek befolyasa a vegtermek minosegere finoman szolva infidezimalis, vagy amikor ismet rajonnek arra, hogy az elosztott rendszerek annyira megse jo dolgok.

Ezt az elosztott vs kozpontositott jatekot btw egyszer mar eljatszottuk 3-4 eve, amikor mindenki decentralizalt bluetooth meg wifihalozatot akart a mobileszkozoknek, aztan az apple pofanrohogte oket, es hirtelen be kellett hozni sok-sok elb.ott evet marhasagokra.

De mindegy... sajna az informatikaban nem moore torveny van hanem divattorveny, 20 evig majmolunk vmit, hogy 20 ev mulva johessen a kovetkezo ami a 40 evvel ezelotti tovabbmajmloasa :)

Kar hogy en a regiekkel ertek jobban egyet :) De legalabb lesz 20 jo evem 10 ev mulva.

Én már láttam jól működő agilist és jól működő dvcs-t is. Szerintem továbbra sem kellene általánosítanod 1-1 rossz tapasztalatodból, kijelenetve hogy senki másnál sem működhet, inkább meg kéne nézned, hogy mit csinálhattál rosszul és min lehetne még javítani. Ilyen mindig van, ha nincs, akkor becsapod magad.

Olyan is van ugye hogy "en ebbol meg1x nem kerek, koszi"?:)

De nyilvan; viszont az remelem vilagossa valt, hogy annak a fejlesztesi metodologianak, amit preferalok nagyvallalati kornyezetben - klasszikus, hierarchikus, stb - az SVN egy nagyon jo tool, pontosan azokkal a fogalmakkal, es eszkoztamogatassal, ami nekem kell.

Ettol meg a linux kernelt szepen elfejlesztik giten, es imadtam SCRUM-ozni a jo-helyben,igaz, akkor meg ennek nem volt neve.

Nem értek a verziókezeléshez, ezért kérdem:

Az nem megoldható, hogy van egy lokális és egy online SVN és a kettő syncel egymással?

(lassan nekem is ideje lenne megismerkednem ezekkel, és valahol itt van a gondom nekem is).

Szerk: Google segített. Megoldható.

Szerk: egyetlen fejlesztőnél miért fontos ez? Mert nem feltétlenül csak egy gépen fejleszt. A hurcolászós, "offline" gépen lehet egy local repo, míg a többi az online-t éri el.

Staging area, normalis branch kezeles, stash stb... ezek nincsenek svn-ben. Offline munkat mar irtak. Masik spec dolog, hogy nalunk a cegnel nem LAN-on van a git szerver, hanem egy VPS-en valahol az USA-ban (ha jol tudom :) ), es az SVN ugy igencsak lassu, foleg az Invitel legendasan megbizhato internetszolgatatasa miatt.

Egy szemelyes projekthez amugy is konnyebb -- szerintem -- gitet hasznalni. `git init` es keszen is van a verziokezeles. Ha majd kell masnak, akkor csinalok repot a szerveren, es kb 2 parancs kiadasa utan (git remote add, git push) mar fent is van.

( syntern | 2011. 06. 23., cs – 06:34 )

Ez miben más, miben jobb mint az xmarks?

Kipróbáltad? Megnézted a videót? Elolvastad a README-t?

A kérdés alapján nem hiszem :-)

Eleve, már a HUP cikkemet se olvastad el. Az xmarks segítségével nem tudod helyben tárolni a bookmarkjaidat, úgy, hogy az a többi konfigurációs fájloddal együtt legyen, szövegként. Valamint a keyword bookmarkokhoz sem ad bonyolultabb lehetőségeket, mint több paraméter vagy autocompletion.

Konstruktív kritika, a "Minden kritikát szívesen hallunk!" jeligére:
- hup főcím: power user könyvjelző megoldás. nem derül ki belőle semmi, hogy mit csinál a progam.
- hup első bekezdés: a felsorolt problémákból egyedül a bookmark szinkronizáció volt nekem problémás, a többit pl. bookmark search-öt a safari szépen tudja. Továbbra sincs szó arról, hogy mire szolgál az alkalmazás.
- a hoplax github oldalán nincs egymondatos összefoglaló, hogy mi ez. "Startpage on local disk with bookmarks and commands". Lövésem sincs.
- rákattintok az online verzióra, bookmarkok szembetűnnek, a click here for helpet csak most, másodjára veszem észre

Lehet hogy nem én vagyok a célközönség, de ha ennyire nincs leírva , akkor nem fogok belemerülni a részletekbe.

"Mindig zavart, hogy a többi konfigurációs fájlommal ellentétben, a könyvjelzőimet a böngészők nehezen kezelhető, nem szinkronizálható, bináris formátumban tárolják."
Nyilvan arra szolgal, hogy ezeket a problemakat megoldja.

"felhasználói útmutató gyanánt pedig egy screencast érhető el"
Eleg reszletesen elmagyarazzak ( igaz, nincs leirva :) ).

Igen, ha a safari bookmark search neked megfelel és nem tudod, hogy mik azok a keyword bookmarkok, akkor valószínűleg nem te vagy a célközönség.

Mindezzel együtt a videóban hallható szöveget valóban át kell fordítanunk a github-os README-be, csak rövid, de lényegretörő, érthető és tömör leírást is nagy munka írni és nem csupán videó subtitle. Félek, hogy aki jelenleg nem nézi meg a videót, az a nehezen összeírt README-t sem olvasná el, mert nem érdekli valószínűleg nagyon.

Azonban ha tudsz nekünk jobb egymondatos összefoglalót adni, mint a mienk, akkor szívesen vesszük a segítséget!

Köszönöm, hogy leírtad a véleményed!

"nem tudod, hogy mik azok a keyword bookmarkok, akkor valószínűleg nem te vagy a célközönség"
Ebben azert ne legyel olyan biztos. En sem tudom, mi az a keyword bookmark, de lehet, hogy valami olyasmi, amit egyebkent hasznalok, csak nem tudom, hogy ez a neve.
Probalj meg egy picit pozitivabban hozzaalni a leendo usereidhez, lecci. Jobb lesz mindenkinek, hidd el.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( pelz | 2011. 06. 25., szo – 21:28 )

Gratulálok!

Én is elkezdtem használni. Ügyesek vagytok!

( dash | 2012. 03. 04., v – 19:24 )

Mik a tapasztalatok azoknál akik anno kipróbálták? Használjátok még?