eo eo eo eo eo eo en eo en pt en en en eo en en en eo eo eo eo eo eo eo eo eo eo en en en eo eo eo eo eo eo en en en eo en en en eo eo eo eo eo eo eo eo eo eo en en eo eo eo eo eo en en en eo eo eo eo eo eo eo eo eo eo eo eo eo en en eo eo eo eo eo eo eo en en en eo eo eo eo eo eo eo eo en en en eo eo eo eo eo eo en en en en
teknologio, komputiko, scienco kaj aliaj studemulaj temoj
Blogo por Esperantistoj kiu temas pri teknologio, komputiko, scienco kaj aliaj temoj kiuj interesas studemulojn.
Demandu min pri iu ajn!
Cxi tiu beba bovlo de frukto aspektas kiel piktogramo de iOS 7.
Filed under ios piktogramo totally looks like opinie esperanto eo
Antaŭnoto: Mi provas ion novan pri la ligilo.  Anstataŭ ĉiam ligi al anglalingvaj artikoloj (mia denaska lingvo), mi nun ligos al la paĝo trapasigita tra google traduko en Esperanton.  Se oni volas legi la originalan, estas tre facile per unusola klako.
Mi lernis pri Stratechery (vortkombino de stategio, teĥnologio kaj “nerdery” (studemuleco) mi supozas.) de la multaj ligoj de daringfireball.net.  Mi tre ĝuas legi la artikolojn de Ben Thompson kaj trovas liajn analizojn esti profundaj kaj surcele, plejparte.
Hodiaŭ tamen, mi devas konfesi mian malkonsenton.  La alligita artikolo temas pri la iOS AppStore kaj ĉu ĝi povas ebligi “daŭrigeblajn negocojn.”  La respondo estas ke ĝi povas, jam nun, sed nur en kelkaj kategorioj, ekzemple ĉiutagaj (komparu al seriozaj) ludoj.
Unu maniero per kiu ludoj povas igi negocon “daŭrigebla” estas per enaplikaĵaj aĉetoj.  Do, li mencias ke certa ludo, Candy Crush Saga (bonbona pista epopeo), havas tre lertan sistemon.  Se la ludanto mortas kvin fojojn li aŭ devas atendi 30 minutojn antaŭ li povas ludi denove, aŭ li povas pagi 99 cendojn por havi kvin pli da vivoj. Nu, tiu certe estas maniero daŭre gajni monon de la samaj ludantoj.
Li kontrastas tiun situacion kontraŭ tre populara produkta aplikaĵo, Paper (Papero, kompreneble.)  En tiu aplikaĵo, kiu en sia baza formo estas senpaga, oni povas aĉeti virtualajn skribilojn kiuj havas malsamajn trajtojn por fari desegnojn.  La problemo, laŭ Ben Thompson, estas ke per tiu modelo unu uzanto aĉetas unu aferon unu foje, poste li povas uzi la aĉetiton senlimajn fojojn sen pagante eĉ alian dekcendon.  Rimedo por tiri pli da mono el la aktualaj uzantoj estas enkonduki alian aferon por aĉeti.  Do, ili faris ĝuste tion, ili aldonis al nova versio de la aplikaĵo eblon aĉeti kolormiksilon kontraŭ 1,99 dolaroj.  Sed, la problemo persistas, la uzantoj aĉetas tiun aferon, sed po ĉiu nur unufoje.  Memoru ke en Bonbona Pista Epopeo, oni havas eblon pagi alian 99 cendojn je ĉiuj kelkaj minutoj!!!
Mi bone komprenas tion kion li diras, mi povas vidi la matematikon.  Tamen, mi malkonsentas ke estas problemo. En la malnova mondo, en la epoĥo antaŭ komputiloj kaj softvaro, metiisto prilaborus unu aferon, eble li skulptus lignopecon.  Kiam fininta li vendus tiun skulptaĵon al unu aĉetanto.  Kaj nun li havas nenion pli por fari krom skulpti ion alian.
Nun ni havas la aŭdacon plendi ke ni ne povas daŭre suĉi monon el la samaj aĉetintoj malgraŭ ke softvaro permesas al la programisto programi unufoje kaj vendi tiom da fojoj kiom estas homoj kiuj volas aĉeti en la tuta mondo!
Li skribis: “building the Mixer was a massive engineering challenge, yet they only charged $1.99 once.” (“Konstrui la kolormiksilon estas granda inĝeniera defio, tamen, ili nur ŝarĝis 1,99$ unufoje.”)  Pardonu min, mi estas softvara disvolvanto mem, sed tiu ĉi estas misreprezento de la faktoj.  Eĉ se jes estis granda defio programi la kolormiksilon, tiu 1,99$ estis ŝarĝita ne unufoje sed po unufoje por ĉiu nuna uzanto kaj por ĉiu uzonto, sen plia laboro por ĉiu nova aĉeto.
Kial ni plendas?  Ŝajnas al mi ke la nuna situacio estas pli ol egala por kaj la aĉetantoj kaj la programistoj.
Filed under esperanto programisto AppStore iOS Opinie negoco softvaro
En la angla podkasto, the talk show, gastigulo John Gruber diskutis dum la plej fresxa epizodo, ke li antaulernis ke la nova interfaco de iOS estos “polusiga.”
Jen ligilo al la poskasto por tiuj interesitaj: http://feeds.muleradio.net/thetalkshow
Nun, tagon post la anoncaro de la cxefprelego de WWDC, mi estas leginta amason da reagoj per kaj blogaj artikoloj kaj en iliaj komentoj. Veras ke Gruber antauxsciis malmulte pri aferoj anoncotaj, tamen, lia fonto de informoj evidente estis tre prava. La reagoj al sxangxoj en iOS 7 strecxigxas trans la tuta gamo, de glora amo al malamema nauxzigxo.
Miaj opinioj situas ie meze inter la ekstremoj, sed sidas pli proksima al amo. Fakte, mi estas scivolema, kaj fine esperema ke la sxangxoj, kiam mi havos oportunon ilin provi kaj uzi, montrigxos tre pozitivaj. La piktogramoj kaj koloraro ne estas miaj plej favorataj, sed la aliaj sxangxoj al kiel la sistemo uzigxas, cxiuj miaopinie reprezentos grandajn pasxojn antauxen. Aparte mi sxatas la novan taskelektilon inter rulantaj aplikajxoj. La regila regilo (mia esperantigo de Control Centre) ankaux estas tre bonvena.
Tamen, pli gxenerale cxiuj cxi tiuj sxangxoj signalas ke Apple estas preta fari vastajn kaj balaajn plibonigojn en cxiu angulo de la operaciumo, ecx tiuj kiuj ne estas tusxitaj de la originala iPhone. Kaj cxi tiu portas grandan eksciton.
Filed under esperanto Apple ios ios 7 dizajno opinie operaciumo
Ne plu la piktogramo de mapoj montros al vi ke estas socie akceptebla stiri rekte de la ponto al la subiranta ŝoseo.  Jej!
Filed under esperanto iOS apple maps mapoj opinia
Retaplikaĵaj Problemoj, Parto 2
Mia originala artikolo pri retaplikaĵoj kaj la malfacilaĵoj rilate al tiuj diskutis kiom malfacila estas verki partojn de la interfaco por havi ĝin sentiĝi kiel indiĝena aplikaĵo. Hodiaŭ mi volas prikomenti dutri klavaro-rilatajn problemojn kaj kiel ili interagas kun la reta vido (UIWebView), kaj ankaŭ unu rilate al fizika ekstera aparato.
Ni verkas aplikaĵon kiu estas sufiĉe ampleksa, por negocoj, malgrandaj vendejoj. La interfaco estas farita tute el HTML elementoj, al kiu aplikiĝas stiloj, kaj ankaŭ estas malgranda parto verkita en Objective-C, la indiĝena lingvo de iOS, por ligi la HTML interfacon al specifaj “malmolaj” aparatoj. Ĉiu HTML elemento estas bildigita laŭ la “reta vido”. Ĉiu parto de softvara interfaco (escepte eble ludoj aŭ aliaj malkutimaj interfacoj) estas faritaj el “vidoj.” Vido estas la baza objekto kiu povas bildigi sur la ekrano kaj kiu povas akcepti enmetojn de la uzanto per fingrotuŝoj aŭ alie. Kaj la vidoj estas aranĝitaj hierarĥie, tiel ke se oni tuŝas iun vidon la defaŭlta konduto de tiu estas plusendi la mesaĝon al sia patro, kaj tiu procezo daŭras ĝis iu patra vido respondas al la mesaĝo, aŭ la mesaĝo falas de la fino de la hierarĥio kaj estas ignorita. Kutime, kompleksa interfaco estas farita el dekoj aŭ teorie centoj de tiel ingitaj vidoj. Kaj ĉiu vido povas esti sub-klasigita de la programisto por havi plenan regon super ĝia konduto. Do, ekzemple, se butono kutime moviĝas ene kaj malene kiam surklakita, oni povas ŝanĝi tiun konduton se dezirata.
Nun ni venas al la reta vido. La reta vido estas unu sola, granda, unuopa “indiĝena” vido, kiu interpretas kaj bildigas HTML kodojn interne de ĝi. Ĉi tiu procezo estas eksterordinare komplika. Do, se io okazas en ĝi rilate al kiel ĝi interpretas HTMLon, estas treege komplika, praktike malebla, ŝanĝi tiun konduton. Pli malbone, foje troviĝas cimoj. Mi volas mencii du antaŭ mi reiros al la problemo menciita en la unua paragrafo.
Okazas relative ofte ke oni havas interfacon kiu provizas panelojn kiuj enhavas tekstokampojn kaj prembutonojn, kiuj rivelas aŭ kaŝas la panelojn. Vidu la ekranbildojn jenajn:
En la unua bildo, estas longa “inventaro” butono. Kiam surklakita la dua bildo rezultas, kaj la inventara alĝustiga panelo ekaperas. Vi povas vidi en la supra panelo ke estas multaj tekstokampoj, kaj vi ankaŭ povas vidi ke iom da tiuj kampoj kuŝas rekte super (pli proksima al la uzanto) la originala inventara butono. Do, la problemo: Kiam en reta vido oni tuŝas parton de la ekrano, kaj tiu tuŝo aktivigas javaskripton kiu igas tekstokampon ekaperi sub punkto tuŝita de la fingro, tiu kampo mem ankaŭ ricevos la tuŝon. Nekredeble ĝena, kaj estas nenion (laŭ mia scio) por fari por preventi ĝin. Tuj poste la klavaro leviĝos kaj la kampo enfokusiĝos. Granda problemo por retaplikaĵaj disvolvantoj, kaj tre malfacile ĉirkaŭ-labori.
Dua problemo, permesu min ekspliki. Kiam kampo estas proksima al la malsupro de la ekrano, kiam la klavaro leviĝos, ĝi kompreneble kovros tiun ekranparton. Do, kutime, se la kodo estis indiĝena entute, la programisto devus permane ŝanĝi la rulpoziciojn kaj grandojn por movi la kampon supren tiel ke ĝi ankoraŭ videblos. La reta vido, tamen, faras multan da la laboro por vi, aŭtomate. Tiu ĉi estus bonveninda se ĝi funkcius sencime. Tamen, la vivo neniam estas tiom malavara. Okazas ofte, sed laŭ mia sperto iom hazarde, ke kiam la klavaro remalleviĝas, la rulpozicio ne ĝuste reiras al la originala pozicio. Niaaplikaĵe, la paĝo estas precize la ĝustan larĝon kaj alton por laŭmezuri la ekranon. Do, tiam kiam la cimo okazas kaj la rulpozicio ne reiras ĝuste, parto de la interfaco restas ekster la ekranaj limoj. Por repoziciigi la interfacon, necesas tuŝi tie kaj tie kaj esperi ke la reta vido movos ĝin denove. Treege ĝena.
Laste, mi promesis ke mi menciis problemon rilate al ekstera aparato. Pro tio ke nia aplikaĵo estas por negoco, estas PDV sistemo, uzinda de vendistoj, ili volas havi kapablon enskani vendotojn per la skankodo presita sur la pakaĵon. Nia aplikaĵo havas kapablon uzi la kameraon, sed ĝi ne estas la plej rapida nek plej fidinda. Do ni volas uzi “bludentan” (Bluetooth) skanilon. Preskaŭ ĉiu bludenta skanilo operacias en speciala modalo konata kiel “HID” (Human Interface Device aŭ Homa Interfaca Aparato). Tiamodale, oni ne devas subteni la aparaton specife en la aplikaĵa kodo, ĉar la aparato ŝajnigas esti klavaro! Tre lerta, ĉu ne? (* dio mia, mi ĵus ekpensis ke eble mi jam verkis artikoleton pri tiu ĉi problemo, antaŭ monatoj. Ajnakaze, mi ĵus rerenkontis la problemon hieraŭ en mia laboro do estas remenciinda.) Iu ajn tekstokampo povas akcepti enmeto de la skanilo, ĉar la skanilo sendas datumojn ĝuste kiel bludentan klavaron. Tiu ĉi havas problemojn en iOS reta vido, tamen. Estas du manieroj interkapti klavarajn datumojn, aŭ per teksto kampo enfokusita, aŭ per onKey—- eventoj de la dokumento, fenestro aŭ paĝkorpo. Mi diru unue ke la lasta maniero simple ne funkcias en iOS. Se kampo ne estas fokusita, tiuj onKey—- eventoj neniam okazos, kaj estas nenion fari por okazigi ilin. Due, kaj fine, se teksto kampo estas en fokusita, la virtuala klavaro volas esti videbla. Ha, nu, la skaniloj havas rimedon por tio, ofte bona skanilo havas butonon sur si por regi ĉu la klavaro estu supra aŭ malsupra. Perfekte! Ho, atendu, perfekte krom kiam oni estas en reta vido, ĉar la reta vido aldonas al la klavaro “helpan strion.” Ĝi estas tiu strio kiu surhavas la “Previous/Next” (Antaŭa, Sekva) butonojn. Tiu strio neniam foriras se tekstokampo estas enfokusita, sendepende de ĉu la klavaro videblas aŭ ne, kaj ĝi okupas spacon sur la ekrano kiu estu uzata de la aplikaĵo mem.
Do, fine, estas kelkaj ĝenaj, kaj preskaŭ ne cirkaŭireblaj problemoj, rilate al la klavaro, por retaplikaĵoj.
Filed under esperanto retaplikaĵo programado ios javascript apple
La Filozofio de iOS
Kiu scias ĉu ĉi tiu ŝanĝos en la venonta versio, sed ekde la komenco iOS havis filozofion kiu estis esti pli simpla ol la partneraj aplikaĵoj sur la tablosurfaco.
Prenu Notojn (Notes), ekzemple.  Ne nur estas la interfaco kiu malsamas iomete, sed ankaŭ la bazaj kapabloj.  Sur la tablosurfaco oni povas krei novajn dosierujojn (nur unu nivelo ankoraŭ.)  Sur la tablosurfaco oni povas elekti la tiparon, la tiparan fasonon kaj pezon.  Oni ankaŭ povas treni kaj faligi notojn de unu dosierujo al alia.  Ĉiuj ĉi tiuj estas plene maleblaj en la iPhone, laŭ dizajno tamen.
Notoj, por iPhone, ne povas krei dosierujon, ne povas forviŝi dosierujon, ne povas ŝanĝi la nomon de dosierujo.  Ne povas plipezigi la tiparon de iu ajn noto, ne povas ŝanĝi la tiparon de noto al noto.  Kaj ne povas movi noton de kie ĝi estas ien aliloke.  Ĉu tiu signifas ke Notoj por iPhone estas difektita?  Ĉu tiu signifas ke al la iPhone mankas multaj bazaj kapabloj?  Ĉu tiu signifas ke la iPhona versio de Notoj estas senutila?  Ne, ne kaj fine, ne.  Anstataŭ pensi ĉi tiel, oni eksciiu ke ĉi tiu estas la filozofio de iOS ĝenerale.  ESTU PLI SIMPLA.  Aparte en poŝkomputilo kiu havas malgrandan ekranon kaj ne havas klavaron nek muson.  La filozofio estas ke se oni simple akceptas ke ne eblas fari tiujn aferojn rekte de la iPhone, li baldaŭ pri tiuj forgesos.  Sed se oni povus, ekzemple, ŝanĝi tiparon, tiam li verŝajne provus, kaj la sperto estus malglata, kaj li frustriĝus kaj la tuta sperto estus efektive malpli bona ol se li ne havus la eblon entute.
Memoru, tamen, se oni manipuladas noton per la tablosurfaca versio de Notojn, li povas fari ian ajn ŝanĝon, kaj per iCloud, la formato kaj loko de la noto estos sendita al la iPhone kaj estos tie videbla.
Filed under Apple iOS esperanto Filozofio softvaro icloud
Transiro al aliaj servoj
Hodiaŭ mi oficiale fermis miajn kontojn je Google kaj Facebook.
Ĉi tiu estas parto de longa transiro for de servoj kiujn mi taksas “tro privatecorabaj” aŭ kiuj havas komercajn modelojn pri kiuj mi malŝatas.
Mi komencis per unuopa forĵeto de retmesaĝoj, kontaktoj, kalendaraj eventoj, konversacioj, kaj ĉiuj aliaj datumoj, kiel dokumentoj, de ĉiuj Google servoj. Ne gravis tro multe mi apenaŭ uzis la servojn kaj eĉ ne ĝeniĝis por konservi la datumojn aliloke, mi simple forĵetis kaj forgesis. Mi uzis Google Analytics por ĉi tiu blogo, Teknologio.net, sed mi malŝaltis tiun kapablon en la blogo antaŭ mi forviŝis la konton ĉe Google. Poste, mi forviŝis la tutan konton, tiel ke mi eĉ ne plu povas ensaluti.
Ĝis, kaj vi ne mankos al mi.
Mia Facebook konto laŭlitere havis neniom da datumoj, nek eĉ unu amiko. Mi uzis ĝin ĉefe por kontroli la interfacajn ŝanĝojn de tempo al tempo, ĉar mi estas disvolvanto, kaj foje scivolema.
Ĝis al tiu ankaŭ, certe tiu ankaŭ ne mankos al mi.
Sekve, mi uzas DropBox, kaj mi uzas YouTubon. Kion fari pri tiuj. Ili estas pli grava problemo, ĉar, vere, mi _uzas_ ilin. YouTube mi malamas ne ĉar ĝi ne havas bonajn videojn, (inter la stultaj amasoj), sed mi malŝatas ke estas Google propraĵo, kaj ke Google ĉiam uzas miajn informojn je manieroj kiujn mi sentas malaprobindaj. Do, mi kreis konton je Vimeo. Apple havas bonan integriĝon kun Vimeo por afiŝi videojn, kaj Vimeo havas bonan iOS aplikaĵon por serĉi kaj spekti filmojn.
Malgranda flankiĝo: Mi afiŝis ĉi tie antaŭ multe da monatoj kiom malmulte mi ŝatas la novan YouTuban aplikaĵon por iOS. La Apple version mi ŝatis kaj multe uzis (ankoraŭ uzas en mia iPad 1, ĉar ĝi ne subtenas iOS 6.) Sed la Google versio de YouTube aplikaĵo por iOS havas multajn ĝenegajn trajtojn. Unu, ekzemple, estas ke ĝi ne integriĝas kun la son-regiloj de la operaciumo. Do, se oni malŝaltas la ekranon, la sono (muziko, prelego, io ajn) tuj ĉesas ludi. Kaj se oni uzas la ludbutonon sur la aŭskultila drato, anstataŭ reludi la YouTuban sonon, estas la lasta aplikaĵo kiu ĝuste integriĝas en la operaciumo kiu ekludas! Google estas elsendinta kelkajn ĝisdatigojn de la aplikaĵo, sed neniu ĝustigas ĉi tiun ĝenan problemon. Mi pripensis la aferon iome, kaj mi ekkonstatis ke estas kontraŭ iliaj interesoj, ĝustigi la problemon. En iliaj okuloj ne estas problemo. Google ne volas ke vi malŝaltu la ekranon kaj aŭskultu du horan prelegon, ĉar tiu estas du horoj dum kiuj vi ne retumas kaj vidas reklamojn. Ĉi tiu ne nur timigas min rilate al Google, sed fakte naŭzigas min. Kompreneble, la Vimeo aplikaĵo integriĝas en la sonsistemon de iOS perfekte.
Do, fine, kion fari pri DropBox. Mia solvo por ĉi tiu estas multflanka. DropBox mem, mi ne havas problemon kontraŭ ili. Tamen, pli ĝenerale, mi konsentas kun Apple ke iompostioma transiro for de krudaj dosieroj en senlime nestigeblaj dosierujoj al dokumentoj kiuj estas pli forte alligitaj al la aplikaĵoj kiuj ilin uzos reprezentas la padon al la estonteco. Mi ekuzis Reminders kaj Notes, Apple aplikaĵojn kiuj havas versiojn por OS X, iPad kaj iPhone, kaj sinkronas datumojn pere de iCloud. Tamen tiuj du aplikaĵoj nur kovras partojn de miaj bezonoj. La dua solvo, mi alvenis al ĝi post aŭskulto de podkasto The Talk Show. Unu el la reklamoj de la subtenantoj estis por aparato nomita “Transporter” (transportilo). Ĉefe mi alvenis al mia ideo kiam mi lernis ke la transportilo estis inventita de la samaj personoj kiuj inventis “drobo.” Mi havas drobon ligitan al mia iMac ĉehejme. Mi amas ĝin! Do, mi decidis provi la jenan. Mi uzas Transmit FTP kliento por Makintoŝo por krei virtualan diskon sur la tablosurfaco, kiu ligas per SFTP rekte al mia komputilo kaj rekte al dosierujo en la drobo. Nun, mi transirigas dosierojn, dosierujon post dosierujo de dropbox al tiu virtuala disko. Estas kiel mia persona DropBox, sed konservita en mia domo en mia drobo, alirebla de ie ajn en la mondo, per la reto.
Sed, laste, ne estus tro sencohava se mi nur prenis krudajn dosierojn el DropBox kaj metis ilin en DropBox-an alternativon. Do, mi ankaŭ ekuzis Evernote. Evernote estas senpaga, ĝi havas belegajn klientojn por iOS kaj Makintoŝo kaj ankaŭ la reto. Ĝi organizas multajn dosiertipojn en “notlibrojn.” Kaj kompreneble ĉio estas sinkrona trans ĉiuj aparatoj. Nun estas la longa procezo transirigi miajn datumojn de DropBox al aŭ mia drobo, aŭ al Evernote.
Mi finfine komencas sentiĝi libera.
Filed under esperanto google ios opinia ĝenerale dropbox Estonteco
Mi devas klarigi al mi mem miajn pensojn kiuj okupas mian menson dum la pasintaj kelkaj tagoj.
WWDC pendas super ni, kaj la atendoj ne povus esti pli altaj.  Google ĵus gastigis disvolvantojn ĉe sia propra konferenco, Google I/O.  Kelkaj rimarkis ke Androido ne estis multe pridiskutata, kaj opiniis tion stranga.  Kaj inter la aferoj pripensataj pri Apple estas iCloud kaj kiel ili ĝustigos ĝiajn problemojn, sed ankaŭ la estonteco de multaj aferoj, la estonteco de la iPhone, de iOS, de OS X (naskita Mac OS X), la Mac Pro, la Mac mini, kaj pli.  Mi preskaŭ ne devas mencii tute novajn aferojn kiel ĝiaj paŝoj en la televidilan merkaton, aŭ la inteligentan brakhorloĝon.
Inter ĉiuj ĉi tiuj estas daŭra pensado pri kiel ili integrigos la partojn.  Ĉu OS X fariĝos pli kaj pli kiel iOS? Ĉu aplikaĵoj de iOS povos havi pli da kapablo interkomuniki, kaj al kiu fino?  Ĉu nova Apple TV kapablos ruligi aplikaĵojn elŝuteblajn de la App Store?  Se jes, kio pri la zapilo, kompreneble la nuna sub-ruĝa (IR, angle) zapilo ne sufiĉos por ludoj.  iCloud… ĉu Apple iam ajn povos havi retservon kiu funkcias bone, rapide, fidinde, kaj kiu ofertos al ni ĉion pri kio ni iam sonĝis?  Kaj laste, ni havas la plendemulojn por kiuj ĉiu paŝo en la estontecon kiun Apple povus fari estos iel malbona, ĉar ĝi malutilos al la karaj manieroj nun amataj por ni uzi niajn maŝinojn.
Do, pripensante ĉiujn ĉi tiujn, mi havas kelkajn komentojn.  Jam kelkaj en la blogosfero prikomentis ke Google ŝajnas voli “preni ĉiom da la miksitaj terpomoj.”  Kaj Apple ne estas malsaĝa.  Unu afero rimarkita pri I/O estas ke Google ne multe menciis Androidon.  Kaj, se vi memoras, Andy Rubin (de kie venas la vera vorto, “Androido”) pseŭde eksdungiĝis de Google, fakte li ne plu estas la estro de la Androida divido, sed kiu nun estas? Sundar Pichai, la estro de ChromeOS divido.  Ankaŭ, Mikrosofto vere ne plu estas la malamiko de Apple. Multmaniere, Apple venkis en tiu milito.  Tiu ne signifas ke Mikrosofto malvenkis aŭ ne plu ekzistas, sed ĝuste kiel Steve Jobs diris, por Apple sukcesi, Mikrosofto ne devas malsukcesi.  Apple “venkis,” tiamaniere ke nun ĝi havas multe da mono, grandan perceptiĝon en la mondo, kaj tiuj kiuj alie volus aĉeti makintoŝon nun almenaŭ konsideras la eblon kaj libere elektas.  Ne, nun, estas klare, Google estas la nova malamiko.  Google havas multe da mono, sed ankaŭ amasojn da talento, kaj ĝi havas deziron superi ĉion kaj ĉiun, inkluzive super Apple kiu elpuŝus ĝin kiel kaj kiom eble plej ofte.  Vidu por ekzemplo, Mapoj kaj YouTube en iOS6.  Ne povas esti duboj ke Apple faris tiujn ŝanĝojn por unusola kialo, por malpliigi la potencon de Google en la iOS medio.
Tamen, nun vidu la duan ekzemplon, ChromeBook.  Jes, jes, ĝi estas tro multekosta, kaj ĝi nur ruligas retaplikaĵojn, kaj ĝi ne havas tiun kaj tiun, bla bla bla.  Fidu min sinjoro, ChromeBook estas rekta atako sur la tereno de Apple.  Se Google havus sian vojon, ĉiu en la mondo uzus ĝiajn servojn, kaj neniu alia firmao povus interveni inter ĝi kaj ĝiaj uzantoj.  Google havas fortajn instigojn daŭrigi sian puŝegon en la terenojn de Apple, ĝi eĉ havas oportunon kaj kapablon malsidigi Mikrosofton. Ĝi estas pli juna, pli rapida, pli vorema, pli pelata venki ol Mikrosofto, kaj en kelkaj manieroj pli da ĉi tiuj eĉ ol Apple.  Sed la plej timiga parto estas ke ChromeOS estas pli “simpla” ol OS X.  OS X venas el erao kiam Vindozo estis la sola konkuranto.  Sed hodiaŭ la teĥnologia pejzaĝo tre malsimilas tiun de hieraŭ.  Apple estas fama por laborante por plisimpligi komputilojn.  Sed la OS X de hodiaŭ ne estas sufiĉe simpla, ne eĉ proksima al tiu celo.  Se ChromeOS kaj la ChromeBook fariĝos pli kaj pli bonaj dum la venontaj jaroj, same kiel Androido pli kaj pli boniĝis dum la pasintaj jaroj, Apple trovos sin alfrontantan teruran konkuranton.  Tamen, se vi estas Apple ŝatanto, kiel mi, ne ŝanceliĝu en viaj botoj.  Kiel dirite, Apple ne estas malsaĝa.  Kaj estas precize tial ke ĝi prilaboras iCloud kaj la fundamentajn ŝanĝojn de la operaciumo por radikale simpligi ĝin.
Fina komento: Miaj gepatroj po ambaŭ havas Makintoŝon, kaj samtempe Flash ĉesis funkcii ĉar ĝi postulis ke ili devas unue ĝisdatigi ĝin.  Ili ambaŭ estis haltigitaj en siaj trakoj.  Miaj gepatroj ne havas ideon, nek deziron scii kiel ĝisdatigi flaŝon.  La Makintoŝo de hodiaŭ restas tro komplika por kompreni por la averaĝa, ne teknike lerta, sed ankoraŭ bone edukita, persono.  Apple scias ĉi tion, kaj ĝi laboras longe kaj forte por ŝanĝi ĝin.  Ĉar, se ĝi ne plibonigos la sperton, Google sendube enplonĝos kaj interrompos en ĝian lokon.
Filed under Google Apple iOS ChromeOS esperanto opinia operaciumo
Antaŭ kelkaj tagoj mi afiŝis artikoleton kiu enkondukis mian tag-al-tagan laborokupon.  Mi kaj kolego fondis firmaon kiu kreas PDV sistemon por la iPado, kaj ni elektis uzi javaskripton kiel la bazo anstataŭ verkante indiĝenan iOS aplikaĵon.
Mi volas paroli iome pri la problemoj verkante “aplikaĵojn” en javaskripto.  Mi emfazas la vorton aplikaĵo ĉar ĉi-problemoj ne aplikiĝas se oni uzas javaskripton nur por skripti simplajn kondutojn en retpaĝo.  En vera aplikaĵo ni devas havi (simuli) regilojn kiuj estas kernaj partoj, senpage uzeblaj, de la indiĝena fasado.  Mi montros al vi kelkaj tiaj ekzemploj per ekranbildoj.
(Jes, nia softvaro estas multlingva, kaj ni havas esperantan tradukon, ni estas tiom mojosaj :)
Do, vi povas vidi ke ni provizas dato-elektilon en la formo de familiaraj ruligeblaj radoj.  Ili aspektas sufiĉe belaj, kaj funkcias plimalpli same kiel la indiĝenaj, sed ni perfekte.  Simpla ekzemplo, sub la Mar 11a, kaj la Maj 10a, vortoj oni povas videti blankan tekst-ombron… en la vera regilo indiĝena tiu ne videblas.  Sed estas treege malfacile poluri al tiu nivelo.  Ankaŭ, por kopii la konduton de tiuj regiloj, por ke la fingro povas uziĝi por movi ilin, ke ili povas moviĝi glate, ke vi povas movi pli ol unu (en malsamaj direktoj (!)) per pli ol unu fingro samtempe, ke ili daŭrigos sian movadon per “inercio” post la fingro lasas la ekranon, ni bezonis mem verki kelkajn interagantajn klasojn.
La multfingra tuŝsistemo sole konsistas el 4 klasoj, QPTouchBase, QPTouchProgress, QPTouchGestureMap kaj QPTouchGestureAnalyzer.  Entute preskaŭ mil linioj de tre kompleksaj algoritomoj.  Tiam ĉiu parto kiu povas sendepende moviĝi, do du listoj de datoj kaj du listoj de jaroj, estas farita el instancoj de alia klaso, QPList, kun multaj stilaj ŝanĝoj kaj kelkaj agordeblaj ebloj por ŝanĝi ĝin por esti taŭga en tiu ĉi kunteksto, tiu klaso estas aldonaj 750 linioj.  Kaj la konduto certe ne estas tiom bona kiel la indiĝena versio.  Ekzemple la niaj ne havas tiun beletan resaltan konduton kiam oni provas ruligi preter la eksteraj limoj.  Ni simple ne povis fari tiun sufiĉe glate por esti uzebla.
Kiel vi povas kompreni, programi altkvalitajn aplikaĵojn per javaskripto estas tre laborpostula, kaj estas multaj aferoj kiujn oni devas trakti kiujn oni povas komplete malatenti se li uzas Obj-C kaj CocoaTouch.
Mi esperas daŭrigi tiun ĉi malgrandan serion en estontaj artikoloj.
Filed under ios javascript apple esperanto programado
Pensante pri androidaj poŝtelefonoj
Antaŭ du semajnoj mia kunlaboranto perdis sian iPhone 4.  Ĝi estis ŝtelita de loka kafejo kie li ŝatas pasigi tempon programante.  Li havas MacBook pro, havis iPhone 4, sed uzas Guglajn servojn multe, inkluzive Chrome (anstataŭ Safari), Gugl-Mapojn (anstataŭ Apple Mapojn), uzas Gmail ne iCloud-mail, kaj tiel plu.  Do, li estas Apple uzanto, certe, se ne havas religiajn ligojn al Apple kaj ne havas ajnan problemon uzante Guglajn servojn samtempe.
Do, li envenis la laborejon la alian tagon kaj elpoŝigis grandan poŝtelefonon.  "Chris, vi aĉetis androidan telefonon! Tiu estas la malamiko!“ Mi ŝerce kriis al li.  Jes ja, fakte li aĉetis la Nexus 4, kiu estas la plej nova "referenca” modelo de Google.  Mi diras referenca ĉar ĝi certe ne estas la plej populara Androido, kiun mi pensas estas la Samsung Galaxy S3 (almenaŭ laŭ http://www.appbrain.com/stats/top-android-phones), ĝi havas proksimume 10 procentojn de la divido de Androidoj.  Tamen, ĝi estas tre bone farita aparataro, kaj la operaciumo estas, eble plej, pura, signifante ke ĝi ne havas aldonajn softvarojn tavolitajn super la baza kvintesenca androida sperto.
Mi ne volas plendi nek laŭdi, sed ŝatus doni kelkajn rapidajn observojn.  Mi ludis kun la softvaro dum plimalpli 30 minutoj, kaj mi komprenas kion signifas tiuj kiuj diras ke iOS sentiĝas malnova aŭ malfreŝa.  Tiu ne signifas ke mi entute konsentas ke iOS malfreŝas, sed mi povas nun kompreni la sentimenton.  iOS estis tre bone desegnita ekde la plej frua versio, kaj unu el tiuj desegnaj celoj estis esti tre simpla, facile komprenebla, kaj regula pri konduto.  Do, ĉio (preskaŭ, siri kaj spotlight esceptite) estas en aplikaĵo, inkluzive ĉiajn agordojn.  Tiu ja estas simpla, sed ne ĉiam estas plej konvena.  Do, en androido (versio 4.2) oni povas enviŝi de la supro malsupren por voki la avizilon.  iOS ankaŭ havas iaspecan avizilon (ideo ŝtelita de androido fakte kaj senhonte), sed de la androida versio estas piktogramo kiu se surklakita rivelos panelon de la plej ofte uzataj agordoj, Wifi, Brilo de ekrano, variaj retaj agordoj ktp.  Surklakante la butonon por ekranbrilon la cetera de la panelo malaperas, la tuta avizilo malaperas kaj malgranda agordilo restas flosante super kio ajn estis sur la ekrano antaŭe.  Oni povas agordi la brilon tiam kaj povas tuj vidi la efikon de tiu ŝanĝo–en la kunteksto de la plej lasta aplikaĵo.  iPado havas similan kapablon, sed iPhone tute ne.  En iPhone oni devas forlasi la nunan aplikaĵon, malfermi Agordojn (Settings), ruligi la paĝon, elekti “brightness & wallpaper”, kaj tiam ŝanĝi la agordilon–en la kunteksto de Agordoj sole–kaj nur poste reiri al la originala aplikaĵo por kontroli kiel la ŝanĝo aspektas en tiu kunteksto.  En tiu ĉi rilato mi estas devigata agnoski ke Androido venkas kaj superas iOS.
Mi pensas ke iOS bezonas ĝisdatigon, kaj ni ĉiuj restas esperemaj pri la anoncoj ĉe WWDC ĉi-jare ke ili enkondukos kelkajn plibonigojn.
Tamen, estas aliaj manieroj per kiu iOS ankoraŭ estas multe pli bona ol Androido, sed mi konservos tiun diskuton ĝis alia artikolo.
Filed under opinia esperanto aparataro android ios apple
Page 1 of 2
We love Tumblr & Stationery by Thijs