Örülök, Penge, hogy mostanában ennyire aktív vagy, de most már le lehet állni. Ez egy Opera rajongói blog, ahol kritikának is helye van, de nem fikablog. Szerintem a "prestothebest" vagy a "freepresto" blog.hu név még kiadó...
@cousin333: Ez már tényleg kicsit sok lesz. Az ok, hogy leírod a véleményed kommentbe, de hogy még posztban is fikázod... Ez a kép is simán elfért volna egy kommentben.
@cousin333:
1. Ez egy független(!) Opera rajongói blog. És mint olyan, őszinte. Azt hiszem a pénzügyi cikkem is elég "polkorrektre" sikerült, nem szőttem bele semmilyen magánvéleményt, de szerintem a Esős hétfő (15.0.1147.100)-vel sem volt semmi baj, ugyanis legalább egyetlen értékelhető változást (Paste & Go billentyűparancs) be lehetett mutatni.
Sőt, Firefox átállást segítő cikket sem tervezek írni. Egyrészt mert még nekem is csak tartalékban van, ezt is Opera 12 alól írom, másrészt mert ez egy Opera blog. Majd a saját My Operás blogomon lehet, hogy írok róla, de azt is csak azért, mert érzek magamban annyi gerincet, hogy ha már éveken át tippekkel segítettem az Opera felhasználókat, amivel kihozhatták a maximumot a böngészőjükből, akkor nem hagyom cserben őket. Nem Presto fanatikus vagyok és nem a piros O betű vagy Tetzchner miatt használtam az Operát, hanem azért, mert egy jó böngésző volt. Számomra az Opera nem a piros O betűvel, vagy a norvég céggel vagy a motorral volt egyenlő, hanem a minőséggel, funkcionalitással, erőforrásigénnyel és sebességgel. Ezek összességével alkotott egy nagy egységes egészet.
2. A Presto csak EGY a sok közül. Leírtam már párszor, hogy miért. Senki nem lát bele a forráskódba, nem tudja mi igaz abból amit Operáék mondanak. Egyetlen tény van: Akármi is az igazság a hivatalos Opera álláspont mindig a saját döntéseit fogja megideologizálni.
Azt sem tudja senki, hogy a Chrome alapra fel lehet-e építeni egy Opera 12 funkcionalitású böngészőt. Egyetlen tény van: Eddig ezt még senki nem tette meg, minden fork csak halvány és nevetséges másolata az Opera 12 funkcionalitásának és egységének. Kókány hatást kelt az egész, mintha a már meglévő legnépszerűbb kiegészítőket beledrótozták volna a böngészőbe, ráadásul teljes mértékben a fejlesztők egyéni preferenciája alapján. Pl. IETab-ra mi szükség van beépítve 2013-ban?
Az irányvonallal van a legfőbb probléma, aminek nem csak a Presto a része, hanem minden más. Már régebben kifejeztem egyet nem értésemet, amikor még tervben sem volt a motorváltás. Ha jól emlékszem még rajtam kívül többen is elismerték, hogy ezek a lépések az "egyszerűsítés" jegyében nagyfokú dilettanizmusra vallanak, mert a kompatibilitás egy dolog, az meg más, hogy az átlaguser miért nem használja.
Nem tudom te mennyire emlékszel arra, hogy amikor WebKit még csak a Safari alatt röcögött, meg KHTML a Konqueror alatt, akkor mennyi oldal nem ment vele normálisan. De még a Chrome hajnalán is voltak szép számmal. A Szégyenfalra direkt oda is írtam, hogy Chrome-mal sem jó az adott oldal.
Ha a jelenlegi vezetésnek a piaci részesedés lenne a célja, nem pedig a pénz mindenek felett (ami bizonyos fokig lehet párhuzamos a piaci részesedéssel is, bizonyos fokig, akár az egész desktop részleget dobhatják, ha találnak valami jövedelmezőbb iparágat), akkor te is nagyon jól tudod, hogy nem ebbe az irányba haladtak volna.
Most mondhatod, hogy nem látok bele, de a legbelül te is tudod, hogy valami nagyon nem stimmel. Ha másból nem, akkor abból, hogy nemhogy nem az volt az első nyilatkozatuk, hogy kihangsúlyozzák, hogy mindent visszatesznek apránként és aktívan támogatják addig biztonsági javításokkal a 12.xx ágat, de nem Stash-t meg Speed Dial-t ajánlgatnak, még a Chrome-hoz képest is lebutítják, nevetséges Bookmarks kiegészítővel próbálják elnyomni a felhasználói haragot, meg third-party szarokat ajánlgatnak, mint Evernote meg LastPass.
Olyan cég nem létezik, amelyik azt mondja, hogy nem törekszik folyamatosan a javításra, fejlesztésre, hanem így, ebben a formában hagyja a termékét. Ez teljesen egyértelmű, hogy ezt mondják, az lenne a durva, ha még ezt sem mondanák. Még a Chrome is ezt mondja, aztán nézd meg a 0.2-től a 30-as verzióig. Jelenleg olyat terveznek a Canary-ban, hogy már a Google találatoknál nem lesz keresősáv sem, hanem a címsáv veszi át a helyét (emiatt a cím kimásolása is necces lesz), lásd: danwin.com/2013/03/google-chrome-to-remove-google-coms-search-bar-canary/
Ebbe az irányba halad a Web és most az Opera is beállt a sorba.
Szóval itt a hozzáállás a lényeg és ezt te is érzed és mindannyian érezzük, hogy ez a hozzáállás szöges ellentétben áll azzal, amit te, Nekomajin, Dzsini és a többiek SZERETNÉNEK HINNI, hogy valaha is szándékukban áll böngészőt fejleszteni (user)Chrome helyett és a váltás VALÓBAN azért történt meg, mert annyira bugos volt már a Presto, hogy menthetetlen, vagy azért, mert túl sok pénz ment el/pénzhiányban voltak és így TÉNYLEG a böngésző funkcióinak fejlesztésére koncentrálhatnak.
Ez mind-mind marketingfogás, nem más.
Még ha kiderülne, hogy a Chromium alap tényleg egy nagyszerű cucc és mérföldekkel jobb, mint a Presto volt és a Presto már tényleg menthetetlen is volt (amit erősen kétlek, máskülönben a Mozilla sem a Gecko-val kínlódna), az sem változtatna azon, hogy az irányvonal már akkor eldőlt, amikor még a Presto-t fejlesztették.
Szerintem nagyon LOL a cikk :D . Nekem tetszik. Pengének meg igaza van és a fricskának szerintem igenis van helye, mert szidni csak olyat lehet amit szeretünk.
Én csak annyit látok, hogy a felhasználók csak hitegetve vannak, akik reménykednek és hisznek, hogy majd az Opera megmutatja hogyan kell fork-ot építeni... PFF ez nem jött még össze senkinek! Se maxthon se yandex se senki ... és ha jobban megnézzük, akkor eddi semmi érdemes javítást nem láthattunk eddig a 15-ös Operában és szerintem ti sem, vagy ha igen akkor miért picsognak az emberek a hiányzó modulokért? Miért sírják vissza a notes, bookmarks, dragonfly, IRC, MDI, Tab stack, privátFÜL, M2, cookie kezelőt, WAND-ot meg anyámkínját még mindig?
Én nem látok innovációt az opera 15-ben... teszem hozzá nem is kellne nekem bele semmi újítás meg fis fos discover, meg gyűjtőlap. Nekem csak kellene a régi Opera úgy ahogy van, feljavított oldal kompatibilitásokkal, és ha kicsit gyorsabb működéssel és ennyi. Utána lehetett volna itt Discover amibe saját feedjeinket rakhattuk volna...
Nem volt pénze? Há mé nem reklámozták magukat. Mé nem beszéltek facebookékkal egy megállapodás keretében? Nem azt mondom hogy adjuk el zuckerberg-nek, hanem megreklámoztatjuk vele, és akkor írunk hozzá normális facebook API-t, meg kompatibilitást, meg ha nagyon vergődnek egy face chat-et és akkor van mindenünk.
Az a sanda gyanúm, hogy pont azokat rúgták ki akik értettek a Presto-hoz. Ezek meg egy sima könyvjelző eszköztárat nem tudnak megírni értelmesen.
A Synch-en lassan 1 hónapja kínlódnak!!!!!!
Továbbá én sem akarom kiadni jelszavaimat 3. félnek nem rég volt egy hasonló problémám ebből, de megoldódott egy delacc-al...
@summoner:
Ha ez ilyen egyszerűen működne, hogy miért nem reklámoztatták meg a fb-kal, akkor nem itt tartanánk.
A szinkronizálással se egy hónapja kínlódnak, mert nem tudom, hogy feltűnt-e, de az elmúlt fél évben forkoltak egy teljesen új motort, teljesen újraírták a GUI-t, az elmúlt egy hónapban meg bugfixelték a 15-öt is meg a 12-t is, és közben már a háttérben fejlesztették a 16-ot is.
Az meg, hogy a forkolás még senkinek se jött be... Hát nem tudom, a Chrome a piac harmadát birtokolja. Szerintem arra mondhatjuk, hogy bejött nekik a forkolás.
Fricskának pedig tényleg van helye. A kérdés a mérték és a stílus. Ez a kép simán elfért volna egy kommentben.
A probléma ugyanis akkor kezdődik, amikor a fricska átcsap a felhasználók megtévesztésébe. Már pedig azt el kéne dönteni, hogy objektívek akarnak maradni, vagy fikablogként akarják folytatni. Én úgy érzem, hogy az aktív szerkesztők kétharmada inkább objektív maradna, szóval jó lenne, ha a maradék egyharmad megszokna vagy megszökne.
@summoner: Dragonfly fejlesztőket keresnek és azt bevallottan fejlesztik, Cookie szerkesztő pedig van Chrome kiegészítőként. A többi viszont így van. Az MDI szerintem soha nem fog már visszajönni, mivel az nagyon mélyen gyökeredzett a régiben, IRC azért nem, mert már a Mac-es Presto-ból is kivették (a torrentklienssel, navigációs sávval és kezdősávval együtt), Tab Stacking és Privát fül még éppen lehet, ahogy Wand is.
Pénzük volt (lásd a másik postomat) nem is kevés, viszont a Facebook API-val nem mentek volna sokra. Lásd: a bedőlt RockMelt, ami szintén Chromium fork volt. A Facebook elég nagy és ismert már ahhoz, hogy azt reklámozza, aki többet fizet. Az meg a Google.
Nem kvantumfizika megérteni a mozgatórugót. Nyilván egyik cégvezető sem szeretné, hogy csődbe menjen a cége, de nagy különbség van aközött, hogy valaki alapértékeket képvisel és cserébe lemond az EXTRAprofitról, vagy egy elvtelen, gerinctelen féreg, aki kizárólag a profitmaximalizációt tartja szem előtt. Hasonló elveket vallanak azok is, akik harmadik világbéli munkásokat alkalmaznak, amire lehet mondani, hogy azért, hogy nekünk olcsóbb legyen, meg az igazságot is, hogy azért, hogy ők még magasabb árréssel dolgozhassanak.
Mikor megkapta Lars a céget, a profitot tartotta szem előtt. Költségcsökkentések, munkamorál romlása, ami miatt főleg a régi bútordarabok és a nagyon tehetségesek (akiket tárt karokkal várt a Google vagy a Mozilla) mondtak fel, az önérzeteseket pedig kirúgták.
Utána jött a második fázis: Ki foglalkozik xy projektekkel?
- x és y foglalkoztak, de az egyikük elment a másik ki lett rúgva. Mi legyen?
- Mi a legegyszerűbb és legolcsóbb?
- Hát, átszervezhetjük innen, onnan, meg amonnan, de ki is vehetjük az egészet a kódból, a statisztikák alapján...
- Ez az! Vegyük ki a kódból, úgysem használják sokan a statisztikák alapján. Meg különben is túl sok pénz fenntartani.
Így került ki a widgetmotor, a Unite és a többi.
Utána jött a harmadik fázis: Én ezt nem értem! Csökken a piaci részesedés, pedig szemmel látható, hogy sem a Chrome, sem a Firefox, sem az IE nem tud annyit, mint az Opera. Áh, csináljunk egy Chromium forkot, azzal minden idők legnagyobb kiadáscsökkentését hajthatjuk végre és lesz, ami lesz. Úgyis csökken a piaci részesedés, így viszont ha az egész projekt bukik is emiatt, lesz elég tőkénk, amit bármire fel tudunk használni.
Azt, hogy fel+ ev alatt nem voltak kepesek megoldani a Linket, az egyszeruen felfoghatatlan.
Foleg ugy, hogy az API-t ok keszitettek. Radasul a synves bealitasokknal megnezve Speddialbol 2 fele verzio is van (pontosabban a regi mar nem kapcsolhato be). opera:config#OperaSync|SyncClientStateSpeedDial2
A Regi maximum 9 es az uj korlatlan. Ez alapjan meg az otlet is kozismert, hogy hogyan lehet megoldani a problemat.
Arrol nem is beszelve, hogy a githubon van hivatalos, talan pyhton alapu, iro olvaso a kerdeses API-hoz.
@Nekomajin: "az elmúlt fél évben forkoltak egy teljesen új motort, teljesen újraírták a GUI-t, az elmúlt egy hónapban meg bugfixelték a 15-öt is meg a 12-t is, és közben már a háttérben fejlesztették a 16-ot is."
Egy dolog nem kóser nekem teljesen ezzel az idővonallal. Ugyebár a végleges 12.10 novemberben jelent meg. Utána még jött 3 biztonsági javítás 12.50-es snapshotok nélkül. Szóval november, december, január és február.
Három és fél hónapig mit csináltak? Malmoztak? Mert ugyebár ekkor jelentették be, hogy átállnak Chromium API-ra, ami "under the hood change" lesz.
Majd most, nemrég mondták, hogy akkor még ők is úgy gondolták, de a Quick mélyen be volt ágyazva a Presto-ba és nem lehetett simán kicserélni a motort.
Szóval ezek szerint a bejelentéskor, illetve előtt/után pár héttel kezdtek neki az egésznek, amiből áprilisban lett Android build és májusban desktop build.
Tehát akkor vagy már jóval előtte nekikezdtek az egésznek és kamuznak arról, hogy eredetileg a 12 alá akarták berántani az új motort, vagy tényleg igazat mondanak, akkor viszont mit csináltak az azt megelőző időszakban?
Mert ezzel az idővel nem tudnak sehogy sem elszámolni. Mert ha csak a Chromium forráskódját is tanulmányozták, akkor tudniuk kellett, hogy nem lehet csak úgy berántani a a 12 alá, szóval ez egy hazugság.
Ha viszont lövésük se volt erről, akkor valamit kellett alkotniuk ez idő alatt, ami nevezhető egy kezdetleges 12.50-nek és akár még alfát is publikálniuk kellett volna.
Egyébként mondd már meg, hogy mi a tököm téveszti meg ezen a humornak szánt képen a felhasználókat. Az, hogy ezentúl Operás kulcstartó és villogó labda helyett akár ilyen szemüveget is osztogathatna a blog?
@Cobalt:
"Azt, hogy fel+ ev alatt nem voltak kepesek megoldani a Linket, az egyszeruen felfoghatatlan."
Abban az esetben, ha nem épül rá valami másra, amit előbb meg kellett csinálni, le kellett tesztelni. Az eddigi hírek szerint nem csak egyszerűen implementálják a régi Linket, hanem fejlesztik is.
Akkor se igazán érteném ezt a "miért nem tudták ennyi idő alatt megcsinálni" dolgot, ha egy fél évet kéne várni a következő verzióra, de jövőhéten valószínűleg kijön az első 16 Next, ~1 hónap múlva meg a végleges. Tényleg megéri ez az okoskodás? Nem lehet, hogy a fejlesztők jobban tudják, hogy hogy osszák be a saját idejüket?
@penge™:
Ha novemberben jött ki a 12.10, akkor november-május az hét hónap. Közben volt egy karácsony is.
Az, hogy mikor jelentették be, hogy forkolják a Chromiumot, nem jelent semmit. A 12.1x-es fixekkel párhuzamosan már simán foglalkozhattak a Chromium kódjával. A Blink is biztos, hogy adott nekik egy kis plusz munkát. Nem gondolom, hogy komolyabban hátráltatta volna őket, de biztos, hogy volt vele némi plusz munka.
Az nekem nem derült ki az eddigi hírekből, hogy pontosan mikor jöttek rá, hogy újra kell írni a teljes GUI-t. Ez lehetett már a tervezési fázisban is. Sőt, valószínűleg akkor történt. (Itt jegyezném meg, hogy három különböző OS-re natív GUI-t írni baromira nem egyszerű feladat.)
Szóval szerintem teljesen rendben van ez a kb. fél év, ami a 12.10 óta eltelt. Azt se felejtsd el, hogy ez idő alatt nem csak bitre pontosan annyit kódoltak, amit most látsz. Valószínűleg egy csomó félkész dolog van már a háttérben, amiket majd most fognak apránként berakni a böngészőbe.
@Nekomajin: "Abban az esetben, ha nem épül rá valami másra, amit előbb meg kellett csinálni, le kellett tesztelni. Az eddigi hírek szerint nem csak egyszerűen implementálják a régi Linket, hanem fejlesztik is."
Mi a fene epulne ra?! A Link egy sima web service, ha nem voltak nagyon idiotak akkor REST alapu. Egy alap folder SD es Stash implementaciot legyartani hozza szinte trivialis. Hacsak nem voltak kepesek ezekhez fel ev alatt rendesen megirni a bongeszo oldali API reteget.
Ez esetben vagy kirugtak minden ertelmes programozni tudo eletformat vagy a Chrome egy hasznalhatatlan alap marmi fele komolyabb dologra.
Most nézem, ez a LastPass egész korrekt. Mondjuk 61 megát bezabál. De még olyan helyeken is kitölti a formot, ahol még a régi Opera sem jegyezte meg a jelszót (nemhogy a többi butaböngésző), pl. blockchain.info.
Ennek ellenére valami belső hang azt súgja, hogy ne bízzam harmadik félre a jelszavaimat, főleg ilyen kritikus helyeken, ahol pénzt tárolok...
Nincs ennek valami offline változata, ami mondjuk nem Local Storage-ban tárolja az adatokat? Ha már van FileSystems API, akkor elvileg csinálhatna egy fizikai fájlt is, még ha csak .txt is. Még az is biztonságosabb, a Linuxomat úgyse valószínű, hogy bárki felnyomná, meg még ha sikerülne se kétlem, hogy gyakori az összes HDD átfésülése és minden szövegfájl lenyúlása, még ha enkicsiponim.txt is a neve sokat mondó passwords.txt helyett. :D
Egy globális jelszótároló cégtől meg aztán nagyságrendekkel kisebb az esélye.
@Nekomajin:
TL;DR; Nagy mertekben ketelkedem, hogy kepesek lesznek tartani a havi fejelsztesi utemet 3 publikus csatornan. Az eddigi minoseg, menyiseg es sebeseg adatok alapjan. Foleg, ugy hogy ignoraljak a "low hanging fruit" tipusu featuroket, pl konyvjelzok es link.
Nem olvastam felre, de te lehet hogy igen. Egy sima HTTP kliensel (pl bongeszo) meghivhato web servicerol beszelunk, ami egesz jol meghatarozott es bovitheto APIval rendelkezik. Radasul a SD/Stack/Discover -hez hasonloan HTML+CSS+JS modon (bovitmeny) kerul leimplementalasra, a fenti 3 dolog melle 4dik fulnek. Radasul a mobil is kint van mar egy idelye.
Ebbol csak a bovitmeny reszt kellett volna megirni. 6+ honap alat.
Felmerul a kerdes, hogy egyaltalan mit kell rajta fejleszteni?! Egy sima egyszeru kobalta webservice, aminek koze sincs a Presto motorhoz. Igy a server oldalon nem kell valtoztatas. A kliens oldalon sem igenyel sokkal nagyobb gondot, mivel megvan a server es az API.
Regota vagyok mar szoftver fejleszto multinal. Az eddigi tapasztalataim alapjan ez a fejelesztesi utem amit diktalnak szanalmasan keves es meg a kifogasaik is gyengek. Palne ugye, hogy a 3 nagy innovaciojuk a hivatalos desktop teames posztjaik alapjan valojaban csak botivmenyek, igen nem nativ implementaciok.
A jelenlegi helyzetre meg azt a magyarazatot el tudom fogandi, hogy JSel sokkal macerasabb rendes minoseget produkalni, mint C/C++ -al, ha komplex kodot kell fejleszteni.
Azt, hogy kepesek lesznek-e tartani a 3 csatornat, azt majd meglatjuk. A Desktop teames komentjeik alapjan ennek a kivitelezesevel is problemak latszanak, pl auto update fronton.
Also hangon jegyeznem meg, hogy egy szervezetet atallitani evi 2 releaserol, havi releasre; 3 parhuzamos nyilvanosan is lathato branchel rendkivul maceras. Fugetlenul attol, hogy menyire os tehetsegek ulnek a fejlesztok/a technikai vezetes/uzelti oldalon.
Tudom mert sikerult tulelnem nehany ilyen jelegu atalakitast mar.
Egyenlore egyre jobban tunik buzleni a losz** amit megproblanak lenyomni a torkunkon.
Remelem vegul neked lesz igazad, en tulsagosan is ki vagyok abrandulva az univerzumbol, ha nagyvalalati szoftver fejelsztesrol van szo.
@Cobalt:
No offense. Csak én azt írtam, hogy a Link ráépülhet valamire, te meg arról kezdtél el írni, hogy ugyan mi a franc épülne rá a Linkre.
Szerintem így nem sok értelme van.
@Cobalt: "Egy sima egyszeru kobalta webservice, aminek koze sincs a Presto motorhoz."
És a fájlformátumok? INI-ből meg ADR-ből meg wand.dat-ból csinálnak majd JSON-t, meg sqlite-ot, meg tökömtudja mit?
A jelszavakat is átvette a 12-esből a végleges 15, de a hozzájuk tartozó felhasználóneveknek kb. az 5%-a maradt meg. Vannak még itt gondok, és ez lett a végleges...
@MosoMasa:
Szerintem arra gondolt, hogy ha egy találati listát akar direktlinkelni. Nekem az lenne a logikus, hogy ha már csak a címsávot használja keresésre a Google, akkor ott ne az URL jelenjen meg, hanem a kereső string.
Ugytunik, hogy komolyabb agymenesnek sikerult mint amilyennek terveztem. Elore is bocsi. A "-----" kozotti reszek a megcimzett felhaszanloknak szolnak, a tobbi csak szemelyes agymenes.
----------------- @Nekomajin: "No offense. Csak én azt írtam, hogy a Link ráépülhet valamire, te meg arról kezdtél el írni, hogy ugyan mi a franc épülne rá a Linkre."
Pontosan es utan ki is fejtetem, hogy miert nincs raepules. De legyen 3dszor is teteles listazassal.
A Link teljesen onalo, nem igenyel semmi egyebet a mukodesehez, mint HTTP uzenetek kuldese es fogadasa.
A REST es JSON miat JSbol egyszeruen megirhato a bongeszo oldali resze is.
Leaszamitva egy rendes API-t amivel hozza lehet ferni az SD/Stash/Discover-hez. Visszont mivel ezek nem native implementaciok hanem bovitmenyek.
Igy ezeknek az APIknak mar letezniuk kell, kulonben a kerdeses featurok nem mukodnenk.
Ismetlem a webservice megoldas miat es publikusan elerheto API leiras (githubos Java kod) miat, barmelyik bongeszobe bele lehetne rakni sima bovitmenykent a Linket. Az osszes konyvjelzo es jelszo syncelo bovitmeny hasonloan mukodik.
@penge™: "És a fájlformátumok? INI-ből meg ADR-ből meg wand.dat-ból csinálnak majd JSON-t, meg sqlite-ot, meg tökömtudja mit?"
Az Opera kerdes filejai a felepitese szempontjabol rekord alapuak, ezert tekintheto mind flat file alapu adatbazisnak (a wand.dat formatumat nem neztem meg).
Visszont, mivel integralva volt, igy nem kellett a Linknek ezek kezelesevel szorakoznia, mivel voltak belso APIk amiket hivogathatott.
JSON ez esetben a wireformat a kliens es a szerver kozott es nem a tenyleges tarolasi.
Radasul JS barat, azaz tokeletes extensionokhoz.
Sot OOP-ban hasznalt Objektumokat 1:1-ben lehet JSON-be es vissza konvertalni. A futo bongeszo pedig ugyis Objektumokent tarolja oket.
"A jelszavakat is átvette a 12-esből a végleges 15, de a hozzájuk tartozó felhasználóneveknek kb. az 5%-a maradt meg. Vannak még itt gondok, és ez lett a végleges..."
Ez Linktol fuggetlen, de azert nemileg ego, hogy a sajat file formatumaikkal nem boldogulnak el rendesen. Foleg ugy hogy van olyan program ami siman tudja olvasni a wand.dat-ot.
Az ilyenek visszont tovabb csokkentik a bizalmamat.
------
A programozas nem fekete magia, hanem foleg csak abstrakt gondolkodast igenyel. Ha az megvan, uttana az egesz mar szinte csak Technic LEGOzas, nemi sajat lego elem gyartassal.
A megrendeloi/felheszaloi oldal fele latszo komplexitas feltetlezett nagysaganak manipulalasaval tud egy progamozo megvezetni/hazudni. A masik oldal nem tehet mast mint elhiszi a programozonak vagy keres masikat.
Tenylegesen az irital, hogy programozok probalank atverni egy masik programozot. Radasul ugy, hogy nem is csinaljak tulsagosan jol. Foleg ugy, hogy en is elek jopar hasonlo komunikacios trukkel a masik oldal fele.
Nagyon remelem, hogy tenyeleg megepitettek azt az UIos abstrakcios reteget, amivel takarozkodva probaljak indokolni a feature hianyt, es nem csak makognak rola.
Bar a Linux verzio hianya es a Windowsos Classic tema eseten keszult kepek alapjan vannak fentartasaim ezzel kapcsolatban.
Meg jegyeznem, ha szakmai szempontbol kozelitem meg a dolgot.
Akkor UIos abstrakcios retegek rendszerint pont a feature megtartas miat irodnak. Bar a gyorsabb jovobeli fejlesztes is hiheto magyarazat. Az R16/R17 majd eldonti, hogy hazudtak-e vagy sem, illetve a Linux megjelenesi datum.
Mig el nem felejtem, jovo orientaltsag es technikai szempontokbol a Themek implementalasa ebben a fazisban, logikusabb. Ha az utan kezdenek el vele mokulni, hogy kint vannak a regibol hianyzo featurok akkor abbol megint takolas lesz.
Nem (teljesen) hulyek meg gonoszak, de a komunikaciojuk az totalisan csapnivalo. Plane ugy, hogy a kozoseg valoszinuleg megenne az osszinte es technikai reszleteket tartalamzo kialast, foleg mivel a marketinges BS ellen elege lazad.
Also hangon jegyeznem meg, hogy a Sleipnir nevezeto webkit alapunak ugytunik, hogy sikerult megoldania a problemat.
A feladat kezelo szerint 2 fele folyamatot futat es abbol jol kiveheto az 1 darabb UIert felelos.
A problema pedig, az hogyan legyunk multi motorosak annelkul, hogy a bugyuta Chrome UI-t kelljen hasznalnunk.
(Nem, egyenlore meg nem fontolgatom a Sleipnir-re migralast. Varom, hatha a 15+ valtozatokban jelentkeznek az Opera fejlesztok altal igert lehetosegek.)
@MosoMasa:
Nem, hanem az URL-t, ami az adott találati listára mutat. De ha a user csak a böngésző címsorában kereshet, akkor két opció van:
A: A címsorban nem az URL jelenik meg, hanem az a string, amit a user begépelt, hogy ha javítani/módosítani kell, akkor ne kelljen az egészet újra begépelni.
B: A Google a webes felületen nyújt erre a problémára valamilyen megoldást. Most is van "did you mean" funkció, ami alapvető elgépelések ellen jó, de ahhoz nem elég okos, hogy teljesen pótolja a manuális javíthatóságot.
@Cobalt:
Teljesen rendben van, amit írsz, csak abból indulsz ki, hogy eddig milyen volt a Link. Érted, ha szar lesz, akkor utólag is lehet ekézni. De azt nem értem, hogy előre minek kell, mert semmit se tudunk arról, hogy pontosan mit akarnak kiadni.
@Nekomajin: A linkelt képen ott van a címsorban a link.
Ez már csak ilyen kínlódás, hogy mibe lehet belekötni, és hogyan lehet okosabbnak lenni a fejlesztőknél, mert azok nyilván alapértelmezetten hlyék, nem értenek semmihez, és alapvetően gonoszak is ... direkte rosszat akarnak a felhasználóknak.
nem tudom ilyen mentalitással miért nem kez valaki egy egyéni, saját böngésző megírásához, ha az annyira semmi dolgog!?
@Nekomajin: "Teljesen rendben van, amit írsz, csak abból indulsz ki, hogy eddig milyen volt a Link. Érted, ha szar lesz, akkor utólag is lehet ekézni. De azt nem értem, hogy előre minek kell, mert semmit se tudunk arról, hogy pontosan mit akarnak kiadni."
A technologiai reszen nem nagyon tudnak valtoztatni. Kell egy web service (vagy szerver) es azt hivagatni a bongeszbol. Ezen a ha meggebednek akkor sem fognak tudni valtozatatni.
Radasul a web service mar megvan, igy annak az ujrairasa ertelmetlen. A beintegracio meg kvazi trivialis.
Ki beszelt itt arrol, hogy jo vagy rossz lesz. Itt arrol van szo, hogy egy szinte teljesen kesz featuret keptelenek atemelni 6+ honap alat. Plane ugy hogy nem kell neki native UI.
A fentiek voltak a tenyek, a kovetkzo csak spekulalas.
A dolgok jelenlegi alapotaban azon sem lepodenek, meg ha fognak a jelenlegi menu opciot es beraknak Discover melle sima IFrames weboldalkent. Majd megprobaljak azt mondani, hogy nesztek itt a bongeszok kozti szinkronizalas.
@penge™: "Mondjuk az is csak olyan 90-95%-os, mert néhol csak 1-est meg 0-t ír jelszónak, vagy olyanokat, hogy [pwd]."
3rd Party megoldashoz kepest szvsz egesz jo eredmeny, foleg ha a hivatalos sem teljesit tul jol.
@MosoMasa: Milyen címben, milyen link? Én a címsorban lévő Google keresési címet szeretném kimásolni, a query-vel együtt.
@Nekomajin: Persze, hogy változhat, de ettől még jól példázza a trendet, hogy milyen irányba akarja terelni a birkákat a Google. A komplett ellehetetlenítés irányába, amikor LEHETŐSÉGED SINCS belelátni a dolgok mélyébe, a dolgok működésébe.
Ez már régen nem arról szól, hogy "segítsünk az átlagusereknek". Akkor szólt arról, amikor volt advanced GUI meg simple GUI. Meg volt advanced kapcsoló a GUI-n, amivel előhozhattad a beállításokat.
A Linuxon sem kell kernelt fordítanod, ha nem akarsz. Még .conf fájlokat sem. De ha akarsz, akkor akár még ezt is megteheted. A legmélyebb részhez is hozzá tudsz férni és bele tudsz nyúlni.
Még a Windows is valahol átmenetet képez, mert van Registry, meg GPO, de ami ott nincs az olyan, mintha nem létezne. Várhatod a patchet. Ami több szempontból is necces a zárt forráskód miatt.
Az OSX, amit előszeretettel hirdetnek úgy, mint Unix őstől (Darwin) származó rendszer, pedig még kevésbé konfigurálható rendszer és még olyan alapvető dolgok is hiányoznak belőle, mint Copy & Merge
Mikor fogják már fel az emberek, hogy nem attól lesz valami felhasználóbarát, hogy lebutítják és ELLEHETETLENÍTIK, illetve MEGSZÜNTETIK a konfigurálhatóságot, hanem attól, ha ezt elrejtik úgy, hogy az átlaguser nem fér hozzá, viszon jól dokumentált formában lehetőséget adnak, hogy ha mégis szükséged van rá, igényt érzel erre, akkor megtehesd.
A bejegyzés trackback címe:
Kommentek:
A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben és az adatvédelmi tájékoztatóban.
cousin333 · http://magyaropera.blog.hu 2013.07.06. 11:52:13
ZeGa 2013.07.06. 13:00:26
ZeGa 2013.07.06. 13:01:44
penge™ · http://www.thevenusproject.com/ 2013.07.06. 13:25:20
1. Ez egy független(!) Opera rajongói blog. És mint olyan, őszinte. Azt hiszem a pénzügyi cikkem is elég "polkorrektre" sikerült, nem szőttem bele semmilyen magánvéleményt, de szerintem a Esős hétfő (15.0.1147.100)-vel sem volt semmi baj, ugyanis legalább egyetlen értékelhető változást (Paste & Go billentyűparancs) be lehetett mutatni.
Sőt, Firefox átállást segítő cikket sem tervezek írni. Egyrészt mert még nekem is csak tartalékban van, ezt is Opera 12 alól írom, másrészt mert ez egy Opera blog. Majd a saját My Operás blogomon lehet, hogy írok róla, de azt is csak azért, mert érzek magamban annyi gerincet, hogy ha már éveken át tippekkel segítettem az Opera felhasználókat, amivel kihozhatták a maximumot a böngészőjükből, akkor nem hagyom cserben őket. Nem Presto fanatikus vagyok és nem a piros O betű vagy Tetzchner miatt használtam az Operát, hanem azért, mert egy jó böngésző volt. Számomra az Opera nem a piros O betűvel, vagy a norvég céggel vagy a motorral volt egyenlő, hanem a minőséggel, funkcionalitással, erőforrásigénnyel és sebességgel. Ezek összességével alkotott egy nagy egységes egészet.
2. A Presto csak EGY a sok közül. Leírtam már párszor, hogy miért. Senki nem lát bele a forráskódba, nem tudja mi igaz abból amit Operáék mondanak. Egyetlen tény van: Akármi is az igazság a hivatalos Opera álláspont mindig a saját döntéseit fogja megideologizálni.
Azt sem tudja senki, hogy a Chrome alapra fel lehet-e építeni egy Opera 12 funkcionalitású böngészőt. Egyetlen tény van: Eddig ezt még senki nem tette meg, minden fork csak halvány és nevetséges másolata az Opera 12 funkcionalitásának és egységének. Kókány hatást kelt az egész, mintha a már meglévő legnépszerűbb kiegészítőket beledrótozták volna a böngészőbe, ráadásul teljes mértékben a fejlesztők egyéni preferenciája alapján. Pl. IETab-ra mi szükség van beépítve 2013-ban?
Az irányvonallal van a legfőbb probléma, aminek nem csak a Presto a része, hanem minden más. Már régebben kifejeztem egyet nem értésemet, amikor még tervben sem volt a motorváltás. Ha jól emlékszem még rajtam kívül többen is elismerték, hogy ezek a lépések az "egyszerűsítés" jegyében nagyfokú dilettanizmusra vallanak, mert a kompatibilitás egy dolog, az meg más, hogy az átlaguser miért nem használja.
Nem tudom te mennyire emlékszel arra, hogy amikor WebKit még csak a Safari alatt röcögött, meg KHTML a Konqueror alatt, akkor mennyi oldal nem ment vele normálisan. De még a Chrome hajnalán is voltak szép számmal. A Szégyenfalra direkt oda is írtam, hogy Chrome-mal sem jó az adott oldal.
Ha a jelenlegi vezetésnek a piaci részesedés lenne a célja, nem pedig a pénz mindenek felett (ami bizonyos fokig lehet párhuzamos a piaci részesedéssel is, bizonyos fokig, akár az egész desktop részleget dobhatják, ha találnak valami jövedelmezőbb iparágat), akkor te is nagyon jól tudod, hogy nem ebbe az irányba haladtak volna.
Most mondhatod, hogy nem látok bele, de a legbelül te is tudod, hogy valami nagyon nem stimmel. Ha másból nem, akkor abból, hogy nemhogy nem az volt az első nyilatkozatuk, hogy kihangsúlyozzák, hogy mindent visszatesznek apránként és aktívan támogatják addig biztonsági javításokkal a 12.xx ágat, de nem Stash-t meg Speed Dial-t ajánlgatnak, még a Chrome-hoz képest is lebutítják, nevetséges Bookmarks kiegészítővel próbálják elnyomni a felhasználói haragot, meg third-party szarokat ajánlgatnak, mint Evernote meg LastPass.
Olyan cég nem létezik, amelyik azt mondja, hogy nem törekszik folyamatosan a javításra, fejlesztésre, hanem így, ebben a formában hagyja a termékét. Ez teljesen egyértelmű, hogy ezt mondják, az lenne a durva, ha még ezt sem mondanák. Még a Chrome is ezt mondja, aztán nézd meg a 0.2-től a 30-as verzióig. Jelenleg olyat terveznek a Canary-ban, hogy már a Google találatoknál nem lesz keresősáv sem, hanem a címsáv veszi át a helyét (emiatt a cím kimásolása is necces lesz), lásd: danwin.com/2013/03/google-chrome-to-remove-google-coms-search-bar-canary/
Ebbe az irányba halad a Web és most az Opera is beállt a sorba.
Szóval itt a hozzáállás a lényeg és ezt te is érzed és mindannyian érezzük, hogy ez a hozzáállás szöges ellentétben áll azzal, amit te, Nekomajin, Dzsini és a többiek SZERETNÉNEK HINNI, hogy valaha is szándékukban áll böngészőt fejleszteni (user)Chrome helyett és a váltás VALÓBAN azért történt meg, mert annyira bugos volt már a Presto, hogy menthetetlen, vagy azért, mert túl sok pénz ment el/pénzhiányban voltak és így TÉNYLEG a böngésző funkcióinak fejlesztésére koncentrálhatnak.
Ez mind-mind marketingfogás, nem más.
Még ha kiderülne, hogy a Chromium alap tényleg egy nagyszerű cucc és mérföldekkel jobb, mint a Presto volt és a Presto már tényleg menthetetlen is volt (amit erősen kétlek, máskülönben a Mozilla sem a Gecko-val kínlódna), az sem változtatna azon, hogy az irányvonal már akkor eldőlt, amikor még a Presto-t fejlesztették.
Nekomajin · http://nekomajin.wordpress.com 2013.07.06. 13:53:08
Én azt nem nevezném pollkorrektnek, ha a postjaiból süt az irónia, de az tény, hogy sokkal visszafogottabbak lettek, mint a kommentjeid.
summoner · http://my.opera.com/summoner1/blog/ 2013.07.06. 14:13:19
Én csak annyit látok, hogy a felhasználók csak hitegetve vannak, akik reménykednek és hisznek, hogy majd az Opera megmutatja hogyan kell fork-ot építeni... PFF ez nem jött még össze senkinek! Se maxthon se yandex se senki ... és ha jobban megnézzük, akkor eddi semmi érdemes javítást nem láthattunk eddig a 15-ös Operában és szerintem ti sem, vagy ha igen akkor miért picsognak az emberek a hiányzó modulokért? Miért sírják vissza a notes, bookmarks, dragonfly, IRC, MDI, Tab stack, privátFÜL, M2, cookie kezelőt, WAND-ot meg anyámkínját még mindig?
Én nem látok innovációt az opera 15-ben... teszem hozzá nem is kellne nekem bele semmi újítás meg fis fos discover, meg gyűjtőlap. Nekem csak kellene a régi Opera úgy ahogy van, feljavított oldal kompatibilitásokkal, és ha kicsit gyorsabb működéssel és ennyi. Utána lehetett volna itt Discover amibe saját feedjeinket rakhattuk volna...
Nem volt pénze? Há mé nem reklámozták magukat. Mé nem beszéltek facebookékkal egy megállapodás keretében? Nem azt mondom hogy adjuk el zuckerberg-nek, hanem megreklámoztatjuk vele, és akkor írunk hozzá normális facebook API-t, meg kompatibilitást, meg ha nagyon vergődnek egy face chat-et és akkor van mindenünk.
Az a sanda gyanúm, hogy pont azokat rúgták ki akik értettek a Presto-hoz. Ezek meg egy sima könyvjelző eszköztárat nem tudnak megírni értelmesen.
A Synch-en lassan 1 hónapja kínlódnak!!!!!!
Továbbá én sem akarom kiadni jelszavaimat 3. félnek nem rég volt egy hasonló problémám ebből, de megoldódott egy delacc-al...
Nekomajin · http://nekomajin.wordpress.com 2013.07.06. 14:34:02
Ha ez ilyen egyszerűen működne, hogy miért nem reklámoztatták meg a fb-kal, akkor nem itt tartanánk.
A szinkronizálással se egy hónapja kínlódnak, mert nem tudom, hogy feltűnt-e, de az elmúlt fél évben forkoltak egy teljesen új motort, teljesen újraírták a GUI-t, az elmúlt egy hónapban meg bugfixelték a 15-öt is meg a 12-t is, és közben már a háttérben fejlesztették a 16-ot is.
Az meg, hogy a forkolás még senkinek se jött be... Hát nem tudom, a Chrome a piac harmadát birtokolja. Szerintem arra mondhatjuk, hogy bejött nekik a forkolás.
Fricskának pedig tényleg van helye. A kérdés a mérték és a stílus. Ez a kép simán elfért volna egy kommentben.
A probléma ugyanis akkor kezdődik, amikor a fricska átcsap a felhasználók megtévesztésébe. Már pedig azt el kéne dönteni, hogy objektívek akarnak maradni, vagy fikablogként akarják folytatni. Én úgy érzem, hogy az aktív szerkesztők kétharmada inkább objektív maradna, szóval jó lenne, ha a maradék egyharmad megszokna vagy megszökne.
penge™ · http://www.thevenusproject.com/ 2013.07.06. 14:56:11
Pénzük volt (lásd a másik postomat) nem is kevés, viszont a Facebook API-val nem mentek volna sokra. Lásd: a bedőlt RockMelt, ami szintén Chromium fork volt. A Facebook elég nagy és ismert már ahhoz, hogy azt reklámozza, aki többet fizet. Az meg a Google.
Nem kvantumfizika megérteni a mozgatórugót. Nyilván egyik cégvezető sem szeretné, hogy csődbe menjen a cége, de nagy különbség van aközött, hogy valaki alapértékeket képvisel és cserébe lemond az EXTRAprofitról, vagy egy elvtelen, gerinctelen féreg, aki kizárólag a profitmaximalizációt tartja szem előtt. Hasonló elveket vallanak azok is, akik harmadik világbéli munkásokat alkalmaznak, amire lehet mondani, hogy azért, hogy nekünk olcsóbb legyen, meg az igazságot is, hogy azért, hogy ők még magasabb árréssel dolgozhassanak.
Mikor megkapta Lars a céget, a profitot tartotta szem előtt. Költségcsökkentések, munkamorál romlása, ami miatt főleg a régi bútordarabok és a nagyon tehetségesek (akiket tárt karokkal várt a Google vagy a Mozilla) mondtak fel, az önérzeteseket pedig kirúgták.
Utána jött a második fázis: Ki foglalkozik xy projektekkel?
- x és y foglalkoztak, de az egyikük elment a másik ki lett rúgva. Mi legyen?
- Mi a legegyszerűbb és legolcsóbb?
- Hát, átszervezhetjük innen, onnan, meg amonnan, de ki is vehetjük az egészet a kódból, a statisztikák alapján...
- Ez az! Vegyük ki a kódból, úgysem használják sokan a statisztikák alapján. Meg különben is túl sok pénz fenntartani.
Így került ki a widgetmotor, a Unite és a többi.
Utána jött a harmadik fázis: Én ezt nem értem! Csökken a piaci részesedés, pedig szemmel látható, hogy sem a Chrome, sem a Firefox, sem az IE nem tud annyit, mint az Opera. Áh, csináljunk egy Chromium forkot, azzal minden idők legnagyobb kiadáscsökkentését hajthatjuk végre és lesz, ami lesz. Úgyis csökken a piaci részesedés, így viszont ha az egész projekt bukik is emiatt, lesz elég tőkénk, amit bármire fel tudunk használni.
Cobalt 2013.07.06. 15:00:06
Foleg ugy, hogy az API-t ok keszitettek. Radasul a synves bealitasokknal megnezve Speddialbol 2 fele verzio is van (pontosabban a regi mar nem kapcsolhato be). opera:config#OperaSync|SyncClientStateSpeedDial2
A Regi maximum 9 es az uj korlatlan. Ez alapjan meg az otlet is kozismert, hogy hogyan lehet megoldani a problemat.
Arrol nem is beszelve, hogy a githubon van hivatalos, talan pyhton alapu, iro olvaso a kerdeses API-hoz.
penge™ · http://www.thevenusproject.com/ 2013.07.06. 15:11:14
Egy dolog nem kóser nekem teljesen ezzel az idővonallal. Ugyebár a végleges 12.10 novemberben jelent meg. Utána még jött 3 biztonsági javítás 12.50-es snapshotok nélkül. Szóval november, december, január és február.
Három és fél hónapig mit csináltak? Malmoztak? Mert ugyebár ekkor jelentették be, hogy átállnak Chromium API-ra, ami "under the hood change" lesz.
Majd most, nemrég mondták, hogy akkor még ők is úgy gondolták, de a Quick mélyen be volt ágyazva a Presto-ba és nem lehetett simán kicserélni a motort.
Szóval ezek szerint a bejelentéskor, illetve előtt/után pár héttel kezdtek neki az egésznek, amiből áprilisban lett Android build és májusban desktop build.
Tehát akkor vagy már jóval előtte nekikezdtek az egésznek és kamuznak arról, hogy eredetileg a 12 alá akarták berántani az új motort, vagy tényleg igazat mondanak, akkor viszont mit csináltak az azt megelőző időszakban?
Mert ezzel az idővel nem tudnak sehogy sem elszámolni. Mert ha csak a Chromium forráskódját is tanulmányozták, akkor tudniuk kellett, hogy nem lehet csak úgy berántani a a 12 alá, szóval ez egy hazugság.
Ha viszont lövésük se volt erről, akkor valamit kellett alkotniuk ez idő alatt, ami nevezhető egy kezdetleges 12.50-nek és akár még alfát is publikálniuk kellett volna.
Egyébként mondd már meg, hogy mi a tököm téveszti meg ezen a humornak szánt képen a felhasználókat. Az, hogy ezentúl Operás kulcstartó és villogó labda helyett akár ilyen szemüveget is osztogathatna a blog?
Nekomajin · http://nekomajin.wordpress.com 2013.07.06. 15:15:02
"Azt, hogy fel+ ev alatt nem voltak kepesek megoldani a Linket, az egyszeruen felfoghatatlan."
Abban az esetben, ha nem épül rá valami másra, amit előbb meg kellett csinálni, le kellett tesztelni. Az eddigi hírek szerint nem csak egyszerűen implementálják a régi Linket, hanem fejlesztik is.
Akkor se igazán érteném ezt a "miért nem tudták ennyi idő alatt megcsinálni" dolgot, ha egy fél évet kéne várni a következő verzióra, de jövőhéten valószínűleg kijön az első 16 Next, ~1 hónap múlva meg a végleges. Tényleg megéri ez az okoskodás? Nem lehet, hogy a fejlesztők jobban tudják, hogy hogy osszák be a saját idejüket?
Nekomajin · http://nekomajin.wordpress.com 2013.07.06. 15:29:15
Ha novemberben jött ki a 12.10, akkor november-május az hét hónap. Közben volt egy karácsony is.
Az, hogy mikor jelentették be, hogy forkolják a Chromiumot, nem jelent semmit. A 12.1x-es fixekkel párhuzamosan már simán foglalkozhattak a Chromium kódjával. A Blink is biztos, hogy adott nekik egy kis plusz munkát. Nem gondolom, hogy komolyabban hátráltatta volna őket, de biztos, hogy volt vele némi plusz munka.
Az nekem nem derült ki az eddigi hírekből, hogy pontosan mikor jöttek rá, hogy újra kell írni a teljes GUI-t. Ez lehetett már a tervezési fázisban is. Sőt, valószínűleg akkor történt. (Itt jegyezném meg, hogy három különböző OS-re natív GUI-t írni baromira nem egyszerű feladat.)
Szóval szerintem teljesen rendben van ez a kb. fél év, ami a 12.10 óta eltelt. Azt se felejtsd el, hogy ez idő alatt nem csak bitre pontosan annyit kódoltak, amit most látsz. Valószínűleg egy csomó félkész dolog van már a háttérben, amiket majd most fognak apránként berakni a böngészőbe.
Cobalt 2013.07.06. 15:39:43
Mi a fene epulne ra?! A Link egy sima web service, ha nem voltak nagyon idiotak akkor REST alapu. Egy alap folder SD es Stash implementaciot legyartani hozza szinte trivialis. Hacsak nem voltak kepesek ezekhez fel ev alatt rendesen megirni a bongeszo oldali API reteget.
Ez esetben vagy kirugtak minden ertelmes programozni tudo eletformat vagy a Chrome egy hasznalhatatlan alap marmi fele komolyabb dologra.
Na megneztem a forrast. Mint az varhato volt igazam volt, sima REST es OAUTH alapu web service.
github.com/operasoftware/JavaOperaLinkClient.git
Cobalt 2013.07.06. 15:50:37
Ezt ugy kell erteni, hogy ha a sajat maguk altal irt extra feturokhoz sem engedi a rendszer a bongeszobeli sajat API gyartast.
penge™ · http://www.thevenusproject.com/ 2013.07.06. 17:08:38
Ennek ellenére valami belső hang azt súgja, hogy ne bízzam harmadik félre a jelszavaimat, főleg ilyen kritikus helyeken, ahol pénzt tárolok...
Nincs ennek valami offline változata, ami mondjuk nem Local Storage-ban tárolja az adatokat? Ha már van FileSystems API, akkor elvileg csinálhatna egy fizikai fájlt is, még ha csak .txt is. Még az is biztonságosabb, a Linuxomat úgyse valószínű, hogy bárki felnyomná, meg még ha sikerülne se kétlem, hogy gyakori az összes HDD átfésülése és minden szövegfájl lenyúlása, még ha enkicsiponim.txt is a neve sokat mondó passwords.txt helyett. :D
Egy globális jelszótároló cégtől meg aztán nagyságrendekkel kisebb az esélye.
Nekomajin · http://nekomajin.wordpress.com 2013.07.06. 20:11:44
Fussunk neki ennek mégegyszer úgy, hogy nem olvasod félre, amit írtam.
ZeGa 2013.07.06. 20:13:45
kepkezelo.com/images/jqkwiyns2yqujaisd.png
Cobalt 2013.07.06. 23:30:37
TL;DR; Nagy mertekben ketelkedem, hogy kepesek lesznek tartani a havi fejelsztesi utemet 3 publikus csatornan. Az eddigi minoseg, menyiseg es sebeseg adatok alapjan. Foleg, ugy hogy ignoraljak a "low hanging fruit" tipusu featuroket, pl konyvjelzok es link.
Nem olvastam felre, de te lehet hogy igen. Egy sima HTTP kliensel (pl bongeszo) meghivhato web servicerol beszelunk, ami egesz jol meghatarozott es bovitheto APIval rendelkezik. Radasul a SD/Stack/Discover -hez hasonloan HTML+CSS+JS modon (bovitmeny) kerul leimplementalasra, a fenti 3 dolog melle 4dik fulnek. Radasul a mobil is kint van mar egy idelye.
Ebbol csak a bovitmeny reszt kellett volna megirni. 6+ honap alat.
Felmerul a kerdes, hogy egyaltalan mit kell rajta fejleszteni?! Egy sima egyszeru kobalta webservice, aminek koze sincs a Presto motorhoz. Igy a server oldalon nem kell valtoztatas. A kliens oldalon sem igenyel sokkal nagyobb gondot, mivel megvan a server es az API.
Regota vagyok mar szoftver fejleszto multinal. Az eddigi tapasztalataim alapjan ez a fejelesztesi utem amit diktalnak szanalmasan keves es meg a kifogasaik is gyengek. Palne ugye, hogy a 3 nagy innovaciojuk a hivatalos desktop teames posztjaik alapjan valojaban csak botivmenyek, igen nem nativ implementaciok.
A jelenlegi helyzetre meg azt a magyarazatot el tudom fogandi, hogy JSel sokkal macerasabb rendes minoseget produkalni, mint C/C++ -al, ha komplex kodot kell fejleszteni.
Azt, hogy kepesek lesznek-e tartani a 3 csatornat, azt majd meglatjuk. A Desktop teames komentjeik alapjan ennek a kivitelezesevel is problemak latszanak, pl auto update fronton.
Also hangon jegyeznem meg, hogy egy szervezetet atallitani evi 2 releaserol, havi releasre; 3 parhuzamos nyilvanosan is lathato branchel rendkivul maceras. Fugetlenul attol, hogy menyire os tehetsegek ulnek a fejlesztok/a technikai vezetes/uzelti oldalon.
Tudom mert sikerult tulelnem nehany ilyen jelegu atalakitast mar.
Egyenlore egyre jobban tunik buzleni a losz** amit megproblanak lenyomni a torkunkon.
Remelem vegul neked lesz igazad, en tulsagosan is ki vagyok abrandulva az univerzumbol, ha nagyvalalati szoftver fejelsztesrol van szo.
Nekomajin · http://nekomajin.wordpress.com 2013.07.06. 23:53:14
Megkérhetnélek, hogy legközelebb csak akkor reagálj a kommentemre, ha rendesen el is olvasod?
Cobalt 2013.07.07. 00:11:06
Nekomajin · http://nekomajin.wordpress.com 2013.07.07. 00:22:49
No offense. Csak én azt írtam, hogy a Link ráépülhet valamire, te meg arról kezdtél el írni, hogy ugyan mi a franc épülne rá a Linkre.
Szerintem így nem sok értelme van.
penge™ · http://www.thevenusproject.com/ 2013.07.07. 02:02:03
És a fájlformátumok? INI-ből meg ADR-ből meg wand.dat-ból csinálnak majd JSON-t, meg sqlite-ot, meg tökömtudja mit?
A jelszavakat is átvette a 12-esből a végleges 15, de a hozzájuk tartozó felhasználóneveknek kb. az 5%-a maradt meg. Vannak még itt gondok, és ez lett a végleges...
MosoMasa 2013.07.07. 09:39:47
Milyen cím kimásolása? O.o
Nekomajin · http://nekomajin.wordpress.com 2013.07.07. 12:44:27
Szerintem arra gondolt, hogy ha egy találati listát akar direktlinkelni. Nekem az lenne a logikus, hogy ha már csak a címsávot használja keresésre a Google, akkor ott ne az URL jelenjen meg, hanem a kereső string.
MosoMasa 2013.07.07. 13:00:03
Cobalt 2013.07.07. 13:14:52
-----------------
@Nekomajin: "No offense. Csak én azt írtam, hogy a Link ráépülhet valamire, te meg arról kezdtél el írni, hogy ugyan mi a franc épülne rá a Linkre."
Pontosan es utan ki is fejtetem, hogy miert nincs raepules. De legyen 3dszor is teteles listazassal.
A Link teljesen onalo, nem igenyel semmi egyebet a mukodesehez, mint HTTP uzenetek kuldese es fogadasa.
A REST es JSON miat JSbol egyszeruen megirhato a bongeszo oldali resze is.
Leaszamitva egy rendes API-t amivel hozza lehet ferni az SD/Stash/Discover-hez. Visszont mivel ezek nem native implementaciok hanem bovitmenyek.
Igy ezeknek az APIknak mar letezniuk kell, kulonben a kerdeses featurok nem mukodnenk.
Ismetlem a webservice megoldas miat es publikusan elerheto API leiras (githubos Java kod) miat, barmelyik bongeszobe bele lehetne rakni sima bovitmenykent a Linket. Az osszes konyvjelzo es jelszo syncelo bovitmeny hasonloan mukodik.
@penge™: "És a fájlformátumok? INI-ből meg ADR-ből meg wand.dat-ból csinálnak majd JSON-t, meg sqlite-ot, meg tökömtudja mit?"
Az Opera kerdes filejai a felepitese szempontjabol rekord alapuak, ezert tekintheto mind flat file alapu adatbazisnak (a wand.dat formatumat nem neztem meg).
Visszont, mivel integralva volt, igy nem kellett a Linknek ezek kezelesevel szorakoznia, mivel voltak belso APIk amiket hivogathatott.
JSON ez esetben a wireformat a kliens es a szerver kozott es nem a tenyleges tarolasi.
Radasul JS barat, azaz tokeletes extensionokhoz.
Sot OOP-ban hasznalt Objektumokat 1:1-ben lehet JSON-be es vissza konvertalni. A futo bongeszo pedig ugyis Objektumokent tarolja oket.
"A jelszavakat is átvette a 12-esből a végleges 15, de a hozzájuk tartozó felhasználóneveknek kb. az 5%-a maradt meg. Vannak még itt gondok, és ez lett a végleges..."
Ez Linktol fuggetlen, de azert nemileg ego, hogy a sajat file formatumaikkal nem boldogulnak el rendesen. Foleg ugy hogy van olyan program ami siman tudja olvasni a wand.dat-ot.
Az ilyenek visszont tovabb csokkentik a bizalmamat.
------
A programozas nem fekete magia, hanem foleg csak abstrakt gondolkodast igenyel. Ha az megvan, uttana az egesz mar szinte csak Technic LEGOzas, nemi sajat lego elem gyartassal.
A megrendeloi/felheszaloi oldal fele latszo komplexitas feltetlezett nagysaganak manipulalasaval tud egy progamozo megvezetni/hazudni. A masik oldal nem tehet mast mint elhiszi a programozonak vagy keres masikat.
Tenylegesen az irital, hogy programozok probalank atverni egy masik programozot. Radasul ugy, hogy nem is csinaljak tulsagosan jol. Foleg ugy, hogy en is elek jopar hasonlo komunikacios trukkel a masik oldal fele.
Nagyon remelem, hogy tenyeleg megepitettek azt az UIos abstrakcios reteget, amivel takarozkodva probaljak indokolni a feature hianyt, es nem csak makognak rola.
Bar a Linux verzio hianya es a Windowsos Classic tema eseten keszult kepek alapjan vannak fentartasaim ezzel kapcsolatban.
Meg jegyeznem, ha szakmai szempontbol kozelitem meg a dolgot.
Akkor UIos abstrakcios retegek rendszerint pont a feature megtartas miat irodnak. Bar a gyorsabb jovobeli fejlesztes is hiheto magyarazat. Az R16/R17 majd eldonti, hogy hazudtak-e vagy sem, illetve a Linux megjelenesi datum.
Mig el nem felejtem, jovo orientaltsag es technikai szempontokbol a Themek implementalasa ebben a fazisban, logikusabb. Ha az utan kezdenek el vele mokulni, hogy kint vannak a regibol hianyzo featurok akkor abbol megint takolas lesz.
Nem (teljesen) hulyek meg gonoszak, de a komunikaciojuk az totalisan csapnivalo. Plane ugy, hogy a kozoseg valoszinuleg megenne az osszinte es technikai reszleteket tartalamzo kialast, foleg mivel a marketinges BS ellen elege lazad.
Also hangon jegyeznem meg, hogy a Sleipnir nevezeto webkit alapunak ugytunik, hogy sikerult megoldania a problemat.
A feladat kezelo szerint 2 fele folyamatot futat es abbol jol kiveheto az 1 darabb UIert felelos.
A problema pedig, az hogyan legyunk multi motorosak annelkul, hogy a bugyuta Chrome UI-t kelljen hasznalnunk.
(Nem, egyenlore meg nem fontolgatom a Sleipnir-re migralast. Varom, hatha a 15+ valtozatokban jelentkeznek az Opera fejlesztok altal igert lehetosegek.)
Nekomajin · http://nekomajin.wordpress.com 2013.07.07. 15:09:33
Nem, hanem az URL-t, ami az adott találati listára mutat. De ha a user csak a böngésző címsorában kereshet, akkor két opció van:
A: A címsorban nem az URL jelenik meg, hanem az a string, amit a user begépelt, hogy ha javítani/módosítani kell, akkor ne kelljen az egészet újra begépelni.
B: A Google a webes felületen nyújt erre a problémára valamilyen megoldást. Most is van "did you mean" funkció, ami alapvető elgépelések ellen jó, de ahhoz nem elég okos, hogy teljesen pótolja a manuális javíthatóságot.
@Cobalt:
Teljesen rendben van, amit írsz, csak abból indulsz ki, hogy eddig milyen volt a Link. Érted, ha szar lesz, akkor utólag is lehet ekézni. De azt nem értem, hogy előre minek kell, mert semmit se tudunk arról, hogy pontosan mit akarnak kiadni.
penge™ · http://www.thevenusproject.com/ 2013.07.07. 17:15:40
MosoMasa 2013.07.07. 17:16:23
Ez már csak ilyen kínlódás, hogy mibe lehet belekötni, és hogyan lehet okosabbnak lenni a fejlesztőknél, mert azok nyilván alapértelmezetten hlyék, nem értenek semmihez, és alapvetően gonoszak is ... direkte rosszat akarnak a felhasználóknak.
nem tudom ilyen mentalitással miért nem kez valaki egy egyéni, saját böngésző megírásához, ha az annyira semmi dolgog!?
penge™ · http://www.thevenusproject.com/ 2013.07.07. 17:21:53
Mondjuk az is csak olyan 90-95%-os, mert néhol csak 1-est meg 0-t ír jelszónak, vagy olyanokat, hogy [pwd].
MosoMasa 2013.07.07. 17:26:40
Cobalt 2013.07.07. 18:18:08
A technologiai reszen nem nagyon tudnak valtoztatni. Kell egy web service (vagy szerver) es azt hivagatni a bongeszbol. Ezen a ha meggebednek akkor sem fognak tudni valtozatatni.
Radasul a web service mar megvan, igy annak az ujrairasa ertelmetlen. A beintegracio meg kvazi trivialis.
Ki beszelt itt arrol, hogy jo vagy rossz lesz. Itt arrol van szo, hogy egy szinte teljesen kesz featuret keptelenek atemelni 6+ honap alat. Plane ugy hogy nem kell neki native UI.
A fentiek voltak a tenyek, a kovetkzo csak spekulalas.
A dolgok jelenlegi alapotaban azon sem lepodenek, meg ha fognak a jelenlegi menu opciot es beraknak Discover melle sima IFrames weboldalkent. Majd megprobaljak azt mondani, hogy nesztek itt a bongeszok kozti szinkronizalas.
@penge™: "Mondjuk az is csak olyan 90-95%-os, mert néhol csak 1-est meg 0-t ír jelszónak, vagy olyanokat, hogy [pwd]."
3rd Party megoldashoz kepest szvsz egesz jo eredmeny, foleg ha a hivatalos sem teljesit tul jol.
Nekomajin · http://nekomajin.wordpress.com 2013.07.07. 19:06:24
Megnéztem a képet, mikor először linkelted, de mivel ez egy fejlesztői előzetes, ez még változhat.
@MosoMasa:
A linkelt képen pont a kereső string van a címsorban. Bele van írva a címsorba, hogy "google chrome canary".
penge™ · http://www.thevenusproject.com/ 2013.07.07. 19:22:48
@Nekomajin: Persze, hogy változhat, de ettől még jól példázza a trendet, hogy milyen irányba akarja terelni a birkákat a Google. A komplett ellehetetlenítés irányába, amikor LEHETŐSÉGED SINCS belelátni a dolgok mélyébe, a dolgok működésébe.
Ez már régen nem arról szól, hogy "segítsünk az átlagusereknek". Akkor szólt arról, amikor volt advanced GUI meg simple GUI. Meg volt advanced kapcsoló a GUI-n, amivel előhozhattad a beállításokat.
A Linuxon sem kell kernelt fordítanod, ha nem akarsz. Még .conf fájlokat sem. De ha akarsz, akkor akár még ezt is megteheted. A legmélyebb részhez is hozzá tudsz férni és bele tudsz nyúlni.
Még a Windows is valahol átmenetet képez, mert van Registry, meg GPO, de ami ott nincs az olyan, mintha nem létezne. Várhatod a patchet. Ami több szempontból is necces a zárt forráskód miatt.
Az OSX, amit előszeretettel hirdetnek úgy, mint Unix őstől (Darwin) származó rendszer, pedig még kevésbé konfigurálható rendszer és még olyan alapvető dolgok is hiányoznak belőle, mint Copy & Merge
Mikor fogják már fel az emberek, hogy nem attól lesz valami felhasználóbarát, hogy lebutítják és ELLEHETETLENÍTIK, illetve MEGSZÜNTETIK a konfigurálhatóságot, hanem attól, ha ezt elrejtik úgy, hogy az átlaguser nem fér hozzá, viszon jól dokumentált formában lehetőséget adnak, hogy ha mégis szükséged van rá, igényt érzel erre, akkor megtehesd.