Aplikāciju izstrāde

[KrKa]

Sveiki!

Lieta tāda, ka jau laiciņu domāju par konkrētas aplikācijas izstrādi viedtālruņiem, tik vien, ka pašam ir maz sajēgas par aplikāciju izstrādes pamatiem (biznesa pasaule kā tāda nav sveša lieta, cita lieta ir programēšana), iespējams mani jautājumi šķitīs smieklīgi (ja ir vēlme ko pārmest vai pasmieties, droši varat to izlaist un šo manu tekstu nekomentēt), bet būtu patīkami, ja kāds varētu iesācējam paskaidrot tādas lietas kā:

1. Kādi speciālisti ir nepieciešami aplikācijas izstrādei un tālākai uzturēšanai? Saprotu, ka pašam izstrādes procesam protams jāpiesaista spējīgi programmētāji, tomēr, kas notiek pēc tam, kad aplikācija ir vairāk vai mazāk pabeigta un palaista apgrozībā, pieņemu, ka tās uzturēšana, kontrole u.t.t. netiek veikta no dārgu programmētāju puses (no sērijas - nealgosi šefpavāru apkopēja darbam). Piemēram ir lasīts, ka gandrīz visos samērā nopietnajos aplikāciju sociālajos tīklos, uz konkrētā mēroga fona darbojas samērā mazs speciālistu skaits, piemēram instagram ir tikai 13 darbinieki. 

2. Kur aiziet visu šo projektu milzīgās investīcijas? Lasu, ka tur investīcijās piesaistīti tik simti tūkstošu, tur tik miljoni u.t.t. Kādas izmaksas ar šīm investīcijām tiek nosegtas, darba algas, serveru uzturēšana (pieņemu, ka šī ir vissāpīgākā daļa), kas vēl?

It kā jautājumi vienkārši, bet būtu jauki, ja kāds spētu apgaismot kā applikāciju izstrādes pasaule funkcionē.

 

[Bomaars/C12]

domājams ka programmētāji tik un tā pēc izstrādes nepieciešami, lai labotu kļudas un attīstītu aplikāciju

[Eric]

1. Ir nepieciešama komanda, nevis atsevišķi cilvēki. Komanda nozīmē, ka tajā ir dizaina, ux, programmēšanas, testēšanas, izstrādes u.c speciālisti, kas prot kopā strādāt un sasniegt rezultātu ātri un nesāpīgi. Te arī vietā piemērs par Instagram, ka 13 cilvēku komanda var paveikt lielas lietas. Atsevišķiem 13 indivīdiem šāda spēja nebūs. Izstrādes komandas izveidošana un vadīšana ir sarežģīts uzdevums.

Ar labu aplikāciju var būt tā pat kā ar Rīgu - tā nekad nav gatava, tādēļ izstrādātāji ir nepieciešami visu laiku. Protams, slodze var mainīties, bet teikt, ka pēc palaišanas varēs iztikt ar 1 lētu programmētāju nevar. Varbūt arī var, bet tas nozīmē, ka aplikācija neattīstīsies.

 

2. Serveri noteikti nav dārgākā lieta, vismaz līdz brīdim, kad neesi Instragram vai Twitter līmenī. Arī izstrādātāji nepārtiek no zelta. Dārgākā lieta ir klientu piesaiste. Piemēram, Tev ir jānoalgo bariņš ar smukām meitenēm, kas braukā pa konferencēm un tur stāsta cik lieliska ir Tava aplikācija. Foršākās konferences notiek tajā pusē okeānam, dalības maksa + ceļš + dzīvošana maksā naudu. Turklāt, tas ir jādara gadu vai vairāk, kamēr aplikācija sāk nest kaut kādu naudu.

 

Ja vēlies uzzināt vairāk, PM

 

Vēl piebilde: svarīgi, lai izstrādātāji spētu piedāvāt piemērotākos risinājumus. No tā izmaksas un rezultāts var mainīties 10 kārtīgi.

Labots Aprīlis 30, 2014 - Eric

[Svekris]

Hm, vismaz jau pirmā reize. 

 

Vari palasītiest šo:
http://en.wikipedia.org/wiki/Scrum_(software_development) 

[Tasteris]

Jā, tā analoģija ar šefpavāru te ir nepareiza. Atteikties no programmētājiem pēc relīzes būtu tā kā atlaist šefpavāru pēc restorāna atvēršanas, jo ēdienkarte taču jau izstrādāta, tālāk apkopēja var gatavot pēc sastādītām receptēm.
Minimāli būtu vajadzīgs dizainieris, programmētājs un cilvēks, kurš nodarbosies ar mārketingu, lai citi zinātu, ka tev ir labs produkts. Protams, ka tas ir atkarīgs no projekta, citam vajadzēs matemātikas, dzelžu speciālistu vai, teiksim, komponistu.
Lielākas izmaksas ir tieši algas, nevis serveri. Kamēr projekts nav populārs, serveru izmaksas būs niecīgas. Tagad ir daudz piedāvājumu īrēt serveru resursus par nelielu naudu (amazon, microsoft u.c. mākoņi).
Kā veidojas investīcijas? Piemēram, vienkāršajā gadījumā paņem programmētāju un dizainieri, alga EUR 1500 uz rokām tev maksās Eur 2700. Ja viņi strādās pusgadu, tad tie ir Eur 32000. Biroja vietā techhub par Eur 2000. Vēl, iespējams, ka šie divi nevarēs veikt kādus darbus (teiksim, vajadzēs grāmatveža konsultāciju), to varēsi pasūtīt kur citur. Arī samaksāsi par reklāmām, konferencēm vai citām PR aktivitātēm. Tā ļoti prasti, bez testētājiem vai adminiem esi iztērējis 50 tūkst. eiro par pusgadu, bet produkts, piemēram, tev vēl nav gatavs.

[KrKa]

Paldies par informāciju, sāk ķļūt mazliet skaidrāka tā bilde.

Un kā Jūs skatāties uz trešo pušu izstrādātājiem? Cik prātīgi ir ielaisties šādā avantūrā un tālākā attīstības posmā nolīgt speciālistus, kas uztur gatavo produktu? Vai tomēr katram savs dārziņš labāk pārzināms un citam var rasties problēmas ar gatavā produkta pārvaldīšanu?

[usver]

Aplikācijas updeiti atkarīgi no aplikācijas sarežģītības. Ja aplikācija ir elementāra un nekādas attīstības tajā nebūs, tad arī nevajag baigi updeitus - BalticTaxi un ManasLēcas aplikācijas no Amberphone ir updeitotas pēdējo reizi pagājšvasar. Jo nekas jau tur nemainās. Un visi dzīvo laimīgi.

 

 

Bet tiklīdz tur ir integrācija ar 3. puses tīkliem (bija feisbuka autorizācija, vajag Twitter, pēc tam izdomājām, ka vajag VKontakte, draugiem.lv ..), jaunas fīčas un notiek kaut kāda produkta attīstība, tā visu laiku arī jāuztur - aplikācijām ir riebīga sadrumstalotība, kad vajag testēt uz dažādām iekārtām. Un 1 programmētājs nemaz TIK daudz nevar izdarīt kvalitatīvi 1 mēneša laikā. Un jā, daudz ir cilvēku, kas "gribētu pamēģināt izstrādi". Ja apmierina tas, ka cilvēks mācīsies pusgadu, un tikmēr būs nopietni gļuki, ko nepārtraukti labos, tad aiziet. Tas tā, ka nevar tomēr paņemt jebkuru "programmētāju" no ielas izstrādei, ka tikai lētāk, ir jābūt portfolio un labai pieredzei.

 

 

Otrā lieta - aplikācijas galu galā neies vienas un tās pašas gan uz Android, gan iPhone.

Facebook ir katrai platformai sava versija, draugiem.lv arī, Instagram arī .. ja ir gana nopietna aplikācija, tad ir 2 dažādas platformas. Jā, ir PhoneGap, ir citi rīki, kas ļauj rakstīt abām platformām uzreiz, bet tas der tām lietām, kas attīstīsies maz. Rezultātā, ja ir idejas par daudzām fīčām, var sanākt 2 paralēli programmētāji.

 

 

Trešā lieta - ja vien tā nav prasta spēlīte, tad kādam būs arī servera puse jātaisa - ielogošanās dati, kategorijas, citu cilvēku komentāri utt utjpr. Nav tā, ka draugiem.lv tagad izlaidām mobilās aplikācijas un viss - serverpusi var mest miskastē. Nē, aplikācija bieži vien ir tikai smukāk uztaisīts front-ends, līdzīgi kā www portāls, ko mēs veram vaļā pārlūkā, un bez servera puses aplikācija varēs tikai pati savā nodabā darboties, bet nevarēs apmainīties ar komentāriem, bildēm utt utjpr. Tātad jāuzskicē, vai tiešām tikai mobilās lietas būs jāizstrādā. Un ja būs arī serverpuse, tad var sanākt 3 dažādi programmētāji.

 

Dizaineris ir vajadzīgs sākumā pēc tam, kad ir izdomāts, kas par sadaļām un laukiem. būs.

Bet pēc tam dizaineris var tikt piesaistīts epizodiski - nesēdēs jau viņš visu gadu uz vietas un nekrās putekļus.

Trešo pušu izstrādātāji (lasi - ārzemēs nolīgt) ir OK, ja funkcionalitāte ir gana vienkārša un dažos mēnešos max var izstrāde iekļauties un nav plānota tālāka attīstība. Visādi rentacoder un elance - tur sēž daudz vairāk cilvēku nekā Latvijā vispār var atrast - Latvija ir ļoti maziņa valsts, kur tiešām pieredzējušu specu nav nemaz tik daudz. Jā, Latvijā ir pārāk maz mobilo izstrādātāju un jā, zinošie izmaksās vairāk nekā cilvēki no Ukrainas, Ķīnas vai Indijas. Laimes spēle, bet esmu dzirdējis arī pozitīvus stāstus, kur vienkāršām lietām pasūtīšana ir bijusi veiksmīga.

Latvijā vienkāršām lietām ir tas pats Amberphone. Tipveida projektiem viņiem jau sagataves ir - paskaties uz viņu darbiem, ļoti mīl viņi taisīt Phonegap (lasi - ies uz iPhone+Android). Paskaties uz viņu darbiem kaut vai lai nodefinētu, kam līdzīgu gribi.

[KrKa]

Paldies par detalizēto izklāstu.

Projekts kopumā nebūtu ārkārtīgi sarežģits, tomēr paredzēts iekļaut iespēju komunicēt ar citiem lietotājiem, apmainīties ar saturu un sekot līdzi citu gaitām, kas to visu padara laikietilpīgāku un sarežģītāku.

[usver]

draugiem.lv/feisbuka klons, nu.

• web portāls
• iPhone aplikācija
• Android aplikācija (vai lētajā variantā - tizls mobilais vebs, par kuru lietotāji spļaudīsies un visu laiku skandēs "kur ir aplikācija???") 
• servera/aplikācijas datu apmaiņa ar XML/JSON servisu (ielogošanās, reģistrācija, sesiju uzturēšana, izlogošanās, datu iegūšana, failu upload, sava "wall" refrešošana, ziņojumu lasīšana/nosūtīšana, staigāšana pa citu profiliem, ziņojumu sūtīšana/lasīšana/atzīmēšana kā lasītu/nelasītu, failu upload (vēlams, ar retry mehānismu, ja 3G noraustās), GCM/push notifikācijas (kā Facebook vai draugiem ziņo par jaunumiem), to nosūtīšana servera pusē, youtube integrācija, logins ar feisbuku - gadījumos, kad ir instalēta FB aplikācija un gadījumos, kad tās nav - attiecīgi webview vai natīvā ielogošanās ). To visu var prasti caur HTTP sesijām un var caur OAuth2 realizēt (ja domā, ka izaugs sistēma Facebook/draugiem līmenī, kad integrēsies citas sistēmas tajā).

Viss process:

1. Iesākumā analītiķis (gudrs cilvēks, datoriķis) sēž un raksta aptuveni šitos pašus punktus ko uzskaitīju.
2. Pēc tam katru punktu apraksta smalkāk un sadala visu pa mailstouniem ( nu nevar gribēt uz 1. versiju pilnīgi visu - tas nav reāli, jāsadala pa prioritātēm ). Un nosauc to par prasību specifikāciju (jeb speceni).
3. Tad pēc vajadzīgās funkcionalitātes saraksta webservisa izsaukumus - ar kādiem izsaukumiem (un parametriem) mobilās aplikācijas sazināsies ar serveri.
4. Tad zīmē dizainu vispirms portālam, pēc tam mobilajām aplikācijām, paralēli bakstot dizainerim ar pirkstu, kur kādas pogas jāparedz un izklāstot savas idejas un vīziju, kā kam jābūt, bet dizaineris uzzīmēs to smuki (ēniņas, gradienti, utt utjpr).
5. Paralēli ar zīmēšanu servera pusē var sākties izstrāde, taisot pašu portālu, kāds tas būs, lai rodas sajūta, ka kaut kas strādā. Un drīz vien arī portālam tiek realizēti tie paši webservisa izsaukumi - vismaz pamatlietas, lai var sākt mobilie vismaz pievienoties.
6. Kad ir mobilo aplikāciju dizaini (katras sadaļas bildes, kā tieši vajag), var sākties mobilo iekārtu programmēšana, dabūjot no dizainera visas vajadzīgās ikoniņas un bildītes.
7. Tiklīdz ir gatavs kaut kas no webservisiem, tā var kaut ko piedarbināt mobilajās iekārtās, lai tās var ielogoties un kaut ko izdarīt. Regulāri nāks klāt webservisos jauni izsaukumi (kad sapratīs, ko tieši vajag), tāpēc tas būs pakāpenisks process.
8. Tad kādu laiku visi programmējas un ik pa laikam apspriežas, ko var vienkāršot, lai neievilktos process līdz bezgalībai. Programmētāji saliek mobilajās aplikācijās Crashlytics pluginu (lai piefiksētu un varētu izlabot krašus) un Google Analytics (lai redzētu un novērtētu, no kurienes un kāda tauta nāk)
9. Pēc tam, kad ir kaut kas sataisīts un strādā tās lietas, ko vajag uz 1. relīzi un ir notestēts uz dažādām iekārtām, var sākt dot intervijas dažādiem portāliem, ka "tūlīt būs tasuntas" un slēgt līgumus par reklāmu izvietošanu.
10. Pēc tam notiek relīze, kad ieliek iekš Google Play/AppStore aplikāciju, ieliek to linkus mājaslapā un lepni atver visiem durvis un ar pompu izziņo un gaida tautas masu pieplūdumu portālā/aplikācijās.
11. Programmētāji sāk sekot līdzi Crashlytics ziņojumiem, kam kas nokrašojis un kur, sāk gatavot labojumus un plānot nākamo aplikācijas relīzi.
12. Vadība sāk domāt, kādas jaunas fīčas likt nākamajā relīzē, programmētāji ar tiem vienojas, izejot no darbietilpības un prioritātēm un Crashlytics atrasto bugu nopietnības, kas arī jāsalabo. Tad programmē to visu un taisa nākamo relīzi.

11. un 12. punkts atkārtojas, kamēr vien produkts ir dzīvs un ir finansējums.

 

been there, done that. Cerams, ka šis palīdzēs saprast, kā tas viss notiek un ka "lai tur cilvēki varētu čatoties un pievienot bildes" nav 3 rindiņas vai "uzinstalēt kādu pluginu". Ja tas nebaida, tad aptuveni tā arī aiziet finansējums - darbaspēkā. Un nevis vienā vienīgā darbiniekā, jo tad viss šausmīgi ievelkas vai sanāk ļoti lētā izpildījumā.

[KrKa]

Nē, tik traki nav.

Kā jau minēju, biznesa pasaule nav svešs termins, vairāk šajā gadījumā ir runa par vizīti svešā teritorijā.

Paldies Usver. 

Facebook, Draugiem.lv mērogu aplikācija tā nebūtu (nav vajadzības pēc tik plaša un daudzveidīga satura), kā arī par youtube sasaisti šaubos (neredzu lielu vajadzību pēc smagām funkcijām bez lielas pievienotās vērtības, esmu par vienkāršību un vieglu pārskatāmību). Neesmu 100% pārliecināts arī par web portāla nepieciešamību, ideja dzimusi vairāk tieši kā mobilā aplikācija (lai gan web portāls atvieglotu aplikācijas satura veidošanu), sava veida sociālais tīkls konkrētai mērķa grupai, kurai šis produkts ir saistošs galvenokārt tikai mobilajās ierīcēs. 

Varbūt traks jautājums, jo zinu, ka tas ir ļoti atkarīgs no produkta specifikas, bet cik aptuveni, plašās robežās skatoties, tāda atvieglota un vienkāršotāka draugiem.lv stila aplikācijas pirmās versijas izveide Android un iOS ierīcēm varētu izmaksāt? 10 000 - 20 000€? Vairāk, mazāk?

[nevertell]

Komentēšu ne pa tēmu, a bet vajag. Acīmredzot tev nav ne mazākās idejas par programmatūras industriju kā tādu, ja domā, ka varēsi noalgot praktikantu, lai tas apkopj (maintains) applikāciju, ko kādi indiešu specguru uzrakstīja tavām vajadzībām par kapeikām no kāda frīlansošanas vebsaita. Applikācija nav bārs vai rūpnīca, par kuru visa nauda aiziet sākumā un pēc tam nāk tīra peļņa.

 

Cik maksātu pirmās versijas izstrāde  ? Tu domā pirmo versiju, kas darbojas ?

Atkarīgs no lietām, bet jāzin, vai serverus uzturēsi pats, īrēsi servertelpu vai īrēsi serveri. Cik liels būs gala lietotāju daudzums, ko gribi apkalpot. Tev budžets ir jādala 4 daļās- serverpuse, web priekšpuse, iOS priekšpuse un Android priekšpuse. Ja tev ir 2-3 cilvēki pie katras projekta daļas, tad projekta izstrāde var ilgt sākot no 3 mēnešiem līdz gadam.  Nu tad rēķini aparatūras izmaksas, kur tu turēsi gala produktu (serveri) un mēnešalgas 12 cilvēkiem, aparatūru lai rakstītu šo visu (dators un planšete un telefons no ābola un androīda). Un algas lūdzu pieklājīgas, nevis 2 minimālās mēnešalgas. Var jau protams ņemt studentus, studentiem tas par labu nāks, bet nedrīkst gaidīt, ka cilvēks uz praksi nāks gatavs darbam.

[Inspektors Caps]

 

 

servera/aplikācijas datu apmaiņa ar XML/JSON

Projekts taču sākas no nulles, nevis ir kaut kas esošs, kur "gemors" pārtaisīt. Tad kādēļ tiek ieteikts jau pamatos ielikt līkus marazmus?

 

Par "biznesu".. Redz, ja autors būtu tiešām ieinteresēts tajā projektā, tad viņš jau sen viens vai ar draugiem sēdētu un taisītu to, nevis kaltu te dižos IT biznesa plānus. Bet, tā kā viņš tāds nav, tad viņam būs jāalgo vesela varza cilvēku, kuri būs vēl mazāk ieinteresēti tajā projektā, un starp kuriem lielākā daļa būs visādi dedicated sistēmanalītiķi, testētāji, mārketinga speciālisti un citi diletanti, kuri patiesībā vispār nejēdz neko. Tā rezultātā beigās tiks radīts nepārdomāts, jēls, lēns, enerģiju lopā rijošs un gļukains frankenšeteins, bet cilvēkiem ar nespējnieku self-esteem zombēšanu tiks iegalvots, ka viņi esot baigie vērtīgie speciālisti. Būs radīta vēl viena kārtējā firma, kas sastāv no melnā darbaspēka nejēgu varzas un rada līkus produktus - parastais ierindas scenārijs!

[zeds]

Inspektors Caps: kā Tu piedāvā strādāt  ?

[usver]

atkal panesās pārgudrības par superrisinājumiem stāstot, cik visi ir stulbi, bet "odna ja umnaja".

 

Caps piedāvā runāt, nevis strādāt. Gribas parunāt - nu dodies pie draugiem.lv, feisbuka un stāsti, cik viņi visi stulbi. Kņigu ņe čital, bet zinu, ka visi ir muļķi. Paldies, Cap, mēs jau to esam dzirdējuši no tevis jau ne pirmo gadu.

[KrKa]

Nevertell, neizteikšos labāk pat par muļķībām sakarā ar rūpnīcām un bāriem, tik minēšu, ka uzņēmumā kuri izveidojuši vadošo konkrētās kategorijas aplikāciju (ap vienu miljonu lietotāju) strādā četri darbinieki.

Nav man varbūt pieredzes programmēšanā, tomēr par muļķi man arī nevajag uzskatīt.

[usver]

mūsējā uzņēmumā ir visai neliela izstrādes nodaļa - vidēji 1..2 cilvēki katram no novirzieniem ( frontend, backend, iOS, Android ). Lietotāji - pāri 100 miljoniem reģistrēto, aktīvie mobilo aplikāciju lietotāji - ap 4 miljoniem katrai platformai. Nu nav vajadzīgi padsmit programmētāji, jo sevišķi sākumposmā, pietiek ar 1..2 katrai daļai. Nu un projvada interesēs, protams, ir atlasīt zinošākos, ar pieredzi ne mazākos projektos.

 

 

Kad projekts sāk paplašināties un tiešām daudzmiljonu auditorija veidojas un projekts sasniegs gaidīto, tad varēs uzlabot serveru arhitektūru, klāsterus, blablabla, pārveidot uz skeilojamāku sistēmu - no interpretējamas valodas uz Java, piemēram (iztiksim bez stulbiem komentāriem no puritānistiem-teorētiķiem), kas ir ilgāks process. Jo būs naudiņa un būs iespēja piesaistīt top speciālistus ar daudzmiljonu auditorijas pieredzi, kas jau zinās nianses. Diez vai tādi mētājas katrā stūrī.

 

Bet ka katrs, kam ir vēlme palaist projektu, tagad sēdēs un asemblerā kodēs savu ūbercustomserveri, lai tikai nesanāktu "enerģiju lopā rijošs" risinājums - piedodiet, tie ir tīņu slapjie sapņi, kam nav nekāda sakara ar realitāti.

[Inspektors Caps]

Nē, es piedāvāju reāli strādāt, nevis bīdīt lielo biznesa demagoģiju. Kļūt par speciālistu vienā vai dažās vēlams saistītās jomās un sākt tajās reāli kaut ko darīt. Viens, ar sabiedrotajiem, ar investoriem vai komandējot citus - nav būtiski. Bet jomā, kurā esi speciālists! Nevis izmācīties tā saucamo ekonomiku un domāt, ka nu tik būs dižais pisnesmenis visās jomās. Ja galvenais neko nerubī, tad arī padotie tiks pieņemti tādi paši lameri un tur nepalīdzēs nekādas personāla atlases kompānijas un citi diletanti.

 

 

 

sēdēs un asemblerā kodēs savu ūbercustomserveri, lai tikai nesanāktu "enerģiju lopā rijošs" risinājums - piedodiet, tie ir tīņu slapjie sapņi, kam nav nekāda sakara ar realitāti.

Tīņu slapjie sapņi ir tie, ka "viss, ko es nejēdzu, ir kaut kas ūbermegasarežģīts, darbietilpīgs un jākodē asamblerā". Tieši kā teici - kņigu ņe čital, bet zinu, ka asamblerā! Un vispār runa bija par datu apmaiņas protokoliem... Bez bezsatura demagoģijas vari pateikt kādēļ būtu jāizvēlas neefektīvākais, nedrošākais un citādi līkākais, ko var atrast?

[nevertell]

KrKa, nu bet muļķis tu patiesi esi, ja domā, ka tas, ko viņi dara, ir vienkārši. Domā visus izdevušos softus ir rakstījuši pāris draugi mammas dzīvoklī ?

Man vienkārši aizdomas, ka te atkal ir cilvēks, kas grib smagi nopelnīt būdams īpašnieks, līdzīgi kā šeit http://www.boot.lv/forums/index.php?/topic/158638-darba-dev%C4%93ja-stabilit%C4%81te/#entry1703573

Jā, ir aplikācijas, kuras raksta 4 cilvēki. Bet tad tie 4 cilvēki katrs prasīs 2-3 režu lielāku algu, kādu esi gatavs maksāt.

 

Nu labi, start-up'ā cilvēku būs mazāk, bet tā pat ar to visu jārēķinās. Un jā, pilnīgi tev taisnība, no sākuma visu var kaut uz viena servera turēt, ja vien bekapi ir droši. Bet tā pat vajadzēs php cilvēku, html/css/js cilvēku, androīd-cilvēku, dizainer-cilvēku un objective-c cilvēku. Ja bizņesmeņš gribētu vienkāršu applikāciju,varētu iztikt bez backenda un web-frontenda cilvēka, bet no tām reti kad ir jēgas, un reti kad biznesmeņi iedomājas un izprot, kā varētu realizēt, applikāciju, kas būtu populāra,bet būtu pilnībā lokāla.

 

 

Ja vēlies draugiem.lv klonu, tev patiesībā ir 2 iespējas. Ir jau gatavi +/- open source projekti, par kuriem jāmaksā, un viss, kas tev ir jānodrošina, ir interfeisa noformējums, vai arī ej pie kāda latvju programmētāju kantora un saki ko vēlies un prasi ceņiku.

Labots Maijs 1, 2014 - nevertell

[usver]

Bez bezsatura demagoģijas vari pateikt kādēļ būtu jāizvēlas neefektīvākais, nedrošākais un citādi līkākais, ko var atrast?

 

 

JSON ir pietiekami labs formāts - tas spēj nodrošināt to aptuveni 8 miljonu mobilo lietotāju vajadzības. Kad paliks par īsu, tiks nomainīts uz msgpack vai citu formātu, taču pagaidām pietiek un debugošanai ļoti labi der, tiek atbalstīts visdažādākajās vidēs. Pie cik miljoniem tev paliek par īsu ar to? Un cik bieži tev JSON pazūd, ja reiz sauc to par nedrošu? Un cik bieži tev nepienāk paziņojumi, ja reiz sauc to par neefektīvāko? 

 

Man liekas, ka Tev vienkārši patīk nodarboties ar matu skaldīšanu un sīku detaļu žļembāšanu. Ja no visa trafika labi ja 1% sastāda datu apmaiņa, bet 90%+ aizņem bildes, video, animētie GIFi, kurus sūta turpu-šurpu un Tu iespringsti par to, ka oi, drausmas, kā jūs varat izmantot tādu datu formātu, tur taču lieki baiti aiziet, jūs visi rīt mirsiet, stulbeņi - piedod, man liekas, ka Tev nav bijis saskares ar realitāti tajā tēmā, par ko ir runa. Piemēram, tajā pašā androīdā prioritātēs JSON vai ne-JSON kā datu formāts ir pēdējā vietā. Pirmajās ir to pašu Bitmap objektu žonglēšana atmiņā pie ierobežotiem resursiem, tīkla lietas ar retry handleriem (jo mobilajiem risinājumiem vadu nav, bet wifi mēdz "aizmigt" un ne vienmēr reaģēt momentāni), GUI diriģēšana ar tiem pašiem fragmentiem. Un dažādu telefonu/OS versiju dažāda uzvedība un spēja VM līmenī menedžēt savu atmiņu pie viena un tā paša koda. Un kur tad nu bez problēmām un krašiem sadarbības partneru (reklāmdevēju) SDK. Tās ir reālās dzīves problēmas. Bet tu par kaut kādām niansēm satraucies un streso, ko var dažu stundu laikā visā infrastruktūrā nomainīt, ja vajadzēs - baitus, redz, lieki patērē. Piedod, bet tā ir matu skaldīšana, kam tiešām nekāda sakara ar realitāti nav.

 

 

Par asembleru - tieši tādu iespaidu tu ar nekonkrētu spriedelēšanu jau iepriekš esi sev radījis. Viss saks, java saks, viss sūds, jo tuvāk mašīnas līmenim, jo labāk, visi pārējie mirs kā jau stulbeņi, nekas nekam neder, viss slikti. Es tiešām neatceros, kad tu būtu normāli ienācis un padalījies pieredzē, pastāstot lietas, ko citiem vajadzētu zināt konkrēta līmeņa projektos. Tā vietā dzirdu tekstus "vajadzētu kaut kā foršāk, es vienīgais zinu kā tieši, bet jūs nefiga nejēdzat un muļķi esat". Varbūt laiks mainīt komunikācijas veidu, lai izpaliktu pārpratumi?

Labots Maijs 1, 2014 - usver

[Inspektors Caps]

 

 

no visa trafika labi ja 1% sastāda datu apmaiņa, bet 90%+ aizņem bildes, video, animētie GIFi

Ārpus sociālajiem tīkliem un bildīšweba domāt vispār spēj?

 

 

 

Un cik bieži tev nepienāk paziņojumi, ja reiz sauc to par neefektīvāko?

Tas ir vienīgais, ko Tu spēj aptvert kā efektivitātes aspektu? n-tās reizes vairāk datu esot nieks. n-tās reizes vairāk rij RAM, jo tas viss trulajā formātā kaut kur ir jātura un jāapstrādā. n-tās reizes vairāk rij CPU, jo tos padebilos cilvēkorientētos formātus parsēt ir reāls darbs, nevis kā normāliem formātiem, kur pat mazam procesoram nav problēmu. Un, kā Tev liekas, datu pārraides iekārtas (tīkla kartes u.c). un CPU no zila gaisa darbojas vai tomēr no elektrības? Tagad pastāstīsi cik bezgalīga ir mobilo iekārtu akumulatora ietilpība? Tu ar savu līko risinājumu iekārtas lietošanas laiku samazini n-tās reizes!

 

 

 

Un cik bieži tev JSON pazūd, ja reiz sauc to par nedrošu?

Par SQL injekcijām esi dzirdējis? Nu lūk, šeit ir tas pats! Bet Tu jau noteikti piemetīsi vēl debilu "eskeipošanu" un teksta ierobežojumus lietotājam, lai CPU būtu vēl ko pamalt bezjēgā, jo ar iepriekš minēto jau nepietiek...

 

 

 

Pie cik miljoniem tev paliek par īsu ar to?

Kas šis par vienpusējās šaurās domāšanas stulbumu? Pie vieniem un tiem pašiem X miljoniem vienā gadījumā vajadzēs serveru parku, bet citā pietiks ar vienu nelielu serverīti. Un esi parēķinājis cik Tu nodari zaudējumus klientam? Cik mazāk darba viņš izdara dēļ tā, ka Tavi lēnie protokoli lēnāk pārraidās, parsējās, lietotājs uz to gaida un cik vēl maksā ar bezjēdzīgu akumulatora sēdināšanu. Cik KLIENTA darba laika Tu apēd dēļ savas haltūrēšanas? Un tagad pareizini to klienta laiku, elektrību un gala beigās naudu ar to klientu skaitu X miljonos. Nu, kauna nemaz nav?

 

 

 

normāli ienācis un padalījies pieredzē, pastāstot lietas

Bet redz, Tu jau pat pats zini MsgPack, bet tāpat neizmanto, jo tāda reliģija - kultivēt kaut kādu "bet XML labāk atbilst manam pašapmierinājumam", nevis vadīties pēc objektīviem un tehniskiem argumentiem. Nu, padalīšos ar zināšanām, ka ir vēl ProtoBuf, čupa citu gatavu protokolu un vienā setā, papētot gatavos, var arī izveidot savu, ja vajag. Tak nekas nemainīsies, jo Tu (un citi) vienalga slimīgi vadīsies pēc "man augstskolā iezombēja, ka vajag visur akli bāzt XML un domāt pašam ar savu galvu ir slikti"!

 

 

 

Varbūt laiks mainīt komunikācijas veidu, lai izpaliktu pārpratumi?

Es nomainīšu tad, kad tiks nomainīta šī absurdā loģika:

 

 

pietiekami labs

"Pietiekami labs", lai ko? Eksistētu? Eksistēt var arī bez tās programmas, bez iekārtas, bez pāris pirkstiem, bez auto, bez apgērba, bez mājas un vispār sēdēt banānkokā un bļaut "uga, uga"! Es vēl saprotu, ja ir kādas situācijas, kur ir jāizvēlas starp kompromisiem, bet šie protokoli un formāti ir tā vieta, kur ir win-win-win-win-win-win situācija (dati-RAM-CPU-enerģija-iespējas-uzticamība).

[Mezavecis]

Caps, diemžēl tu atkal šoreiz ielīdi laukā, kur ne vella nejēdz. Ja sāc gānīt JSON vai XML, tad točna programmējis esi kaut ko oldscool un apstājies attīstībā n gadus atpakaļ. Reālitāte ir tāda, ka pilnīgi visos modernajos projektos ir XML datu apmaiņa. Beidz dzīvot alā un gvelzt muļķības. Mēs saprotam, ka tukšmuldēšana par kosmosa kuģiem tev padodas, bet tas interesē tikai šauram cilvēku lokam.

 

P.S. Binārais datu apmaiņas formāts ir miris. 

 

Arī no šī te neko nejēdz. Pēc izteikumiem ir skaidrs, ka par CRM/ERP/DMS sistēmām gūglē izlasīji un izdarīji ģeniālus secinājumus, ka visur ir līki softi un tūkstošiem uzņēmumu ar miljardu budžetiem lieto sūdus.  

 

 

Par "biznesu".

 

[Inspektors Caps]

@@Mezavecis, Tev ļoti objektīvi argumenti! Es pagriezīšu tieši otrādi, tikai ar reāliem faktiem.

 

pilnīgi visos modernajos projektos

Pats parādīji, ka visa Tava domāšana apstājusies datubāze+weblapa noliktavu un grāmatvedības sistēmās. Tu tur esi iestrēdzis un nespēj padomāt vairs ārpus tās savas kastes! Tagad jauni iekārtu formāti, iekārtas un pielietojumi aug kā sēnes pēc lietus, bet Tu to nespēj pat pilnvērtīgi aptvert, ja neskaita aprobežotu "ā, te es arī varētu palaist savu to pašu veco weblapeli".

 

Binārais datu apmaiņas formāts ir miris.

Tas vienkārši principiāli nav iespējams kamēr vien dators ir binārs. Tev tur Tavā ierobežotajā pasaulītē, kur šodien viens web koderis ir izdomājis vienu perversiju, ko rīt nomainīs jau nākošā vēl perversākā, varbūt arī dēļ tādiem domāt nespējīgiem ir miris, bet, ja vien Tu spētu redzēt ārpus savas smilšu kastes...

 

Pēc izteikumiem ir skaidrs

Nu ja, nu ja. Tas, ka apkārt redzu visur iestādēs un uzņēmumos pilnu ar tādām diletantu izstrādātām totāli līkām sistēmām, jau nu galīgi nav arguments... Šodien pat aptaustīju Lattelecom iekšējās lietošanas dažus Web+Java mēslus. Tur pat nav ko komentēt - izstrādātāji ir vienkārši jāsūta uz Rīgas Miesnieku kā gaļa! Bet izstrādājuši to ir tieši tādi lameri tieši šādu tirliņu "biznesmeņu" vadībā.

 

visur ir līki softi un tūkstošiem uzņēmumu ar miljardu budžetiem lieto sūdus

Mums visiem apkārt pa visu pasauli ir viens perfekts piemērs - globālais Webs. Tur līks ir viss, izņemot IP protokolu un attēlu/skaņas/video kompresijas formātus. Bet, ak vai, tie ir bināri!

Labots Maijs 1, 2014 - Inspektors Caps

[Mezavecis]

Inspektors Caps

Tavi argumenti ir vēl "objektīvāki". Neko jaunu par līko webu neesi izdomājis. Ja tu runā tikai par šauras jomas risinājumiem, tad es to sistēmu redzu kompleksi. Tev liekas, ka iekārtas aug kā sēnes un pasaule griežas ap tām. Pakustini smadzenes un padomā, cik daudz procesi nepieciešami, lai ieejot veikalā, norēķinoties ar maksājuma karti, nauda aiziet no tava konta uz veikala kontam. Nu nav tur 1 brīnumkastīte, kas dara visu. Web ir visur, kas sniedzas ārpus 1 būceņa robežām, lai cik tev to negribētos atzīt.

 

Ja reiz ir tik daudz modernu formāti, tad padalies ar mums, tikai izbeidz šo teorētisko muldēšanu. Te daudzi ķipa programmisti nākuši un lējuši ūdeni, kā pareizi jābūvē sistēmas, lai gan paši neko nav uztaisījuši. Un pie reizes pasaki šo formātu ieviešanas un uzturēšanas izmaksas.

 

Ja kāds domā, ka viņš ir gudrs un pārējie idioti, tad diemžēl patiesība ir tāda, ka viņš pats ir tāds pats idiots kā citi. Tādi ģēniji ir nākuši un gājuši. Jebkurš mūsdienu risinājums ir kompleksa sistēma nevis viena ģēnija roku darbs.

 

Nu ja, nu ja. Tas, ka apkārt redzu visur iestādēs un uzņēmumos pilnu ar tādām diletantu izstrādātām totāli līkām sistēmām

 

Protams, ka dators ir binārs, bet datu apmaiņas formāti starp datoriem kļūst aizvien mazāk bināri, jo tam ir loģisks pamatojums  - dārga uzturēšana. Kompresija ir cits stāsts, jo tas taču arī bezjēdzīgi tērē resursus. Tas, ka tu kaut ko uztaisi un domā, ka strādās pēc 10 gadiem ir apsveicami. Diemžēl dažu ģēniju dēļ ar superātriem algoritmiem sistēmu pēc 10 gadiem jānolaiž podā, jo nav savienojama ar mūsdienu prasībām. Nav jādomā, kādas ir izmaksas salīdzinot ar līku sistēmu, kur var kaut kā pielāgot. Normāli uztaisīts web serviss dzīvos ļoti ilgi. 

 

dators ir binārs

[usver]

Pie vieniem un tiem pašiem X miljoniem vienā gadījumā vajadzēs serveru parku, bet citā pietiks ar vienu nelielu serverīti

 

sarunāsim tā - tu parādīsi savu paštaisīto 100+ miljonu risinājumu uz 1 serverīša, kur notiek bilžu+video upload/download, video strīmošana, paralēla miljonu rekvestu apstrāde un API izsaukumu apstrāde mobilajām iekārtām, bet es uzmanīgi to izpētīšu un pārņemšu pieredzi, sarunāts? Līdz tam attiekšos pret šādām fantāzijām kā pret tīņu slapjajiem sapņiem.

 

 

 

Par SQL injekcijām esi dzirdējis? Nu lūk, šeit ir tas pats! Bet Tu jau noteikti piemetīsi vēl debilu "eskeipošanu"

 

okei, web programmēšanu, acīmredzot, arī neesi realitātē taustījis, bet kaut ko pa ausu galam dzirdējis un tagad kladzini klišejas.

 

 

 

kultivēt kaut kādu "bet XML labāk atbilst manam pašapmierinājumam", nevis vadīties pēc objektīviem un tehniskiem argumentiem

.. 

jo Tu (un citi) vienalga slimīgi vadīsies pēc "man augstskolā iezombēja, ka vajag visur akli bāzt XML un domāt pašam ar savu galvu ir slikti"!

 

Tev augstākās nav, ja? Savādāk nevaru izskaidrot tādu iespringšanu par to. Turklāt XML neizmantoju datu pārsūtīšanai. Laimīgs tagad? 

 

 

 

"Pietiekami labs", lai ko? Eksistētu? Eksistēt var arī bez tās programmas, bez iekārtas, bez pāris pirkstiem, bez auto, bez apgērba, bez mājas un vispār sēdēt banānkokā un bļaut "uga, uga"!

Pietiekami labs, lai minēto 100+ miljonu sistēmu darbinātu. Ir vēl jautājumi? Vai arī turpināsies tieši tas pats scenārijs, ko jau aprakstīju - "nezinu, ko tieši un kā jūs darat, bet jūs esat stulbi un es varētu 100x labāk, ja vien gribētu, tikai negribu - gribu tikai pakulstīt mēli, cik jūs debīli esat pēc definīcijas, ka vispār programmējat kaut ko tādu". Redz, web un soctīkli - tas esot marazms pēc definīcijas, tātad a priori nekā laba tur nevar būt un viss ir nolemts, izdzīvos tikai izredzētie, kas tādas problēmas nav risinājuši principā.

 

Man rodas sajūta, ka tieši saistībā ar apspriesto tēmu vienīgais, ko tu spēj parādīt, ir tas banānkoks un uga, uga bļaušana - "jūs kā neiesvaidītie sūkājat, tāpēc es te pa*irsīšu par tēmu, cik jūs esat stulbi un neko nesaprotat". viss pārējais ir gaisa pilis un kaut kādas iedomātas pretenzijas uz visziņa, visdara titulu. Aprakstīju tev, kādas ir problēmas un apstākļi, kas jārisina vispirms reālā sistēmā. Visa smalktūnēšana - tā ir matu skaldīšana, un kad pirmo reizi aptaustīsi tāda tipa reālu sistēmu, tad sapratīsi, par ko ir runa. Goda vārds - ja uzņēmumā atnāktu kāds tirliņš, apsēstos un sāktu kā lecīgs tīnis mācīt, ka, lūk, "šito var miljonkārt optimizēt, lai ietu uz 1 servera", tad ilgāk par 10 min tur nenosēdētu - tādam palūgtu aizvākties. Jo ja kādam tas nav pielecis, ir milzīgs darba apjoms veicams tieši funkcionalitātē, bet atkārtoju, ka tādi sīkumi, kas dod minimālu efektu, ir tiešām sīkumi, kas ir elementāri labojami un uz kopējo sistēmas stabilitāti iespaidu atstāj tikai uz papīra un procentiem. Tu vienkārši aiz 3 kokiem neredzi mežu un iedomājies, ka nomainot protokolu pēkšņi būs paradīze un viss cits 99% darāmais darba apjoms pēkšņi atkritīs. Rodas iespaids, ka tieši tu esi piemērs paša aprakstītajam scenārijam - "pabeidzu augstākās izglītības mācību iestādi un tagad visus teorētiski mācu, nespējot to sasaistīt ar reālu izstrādes procesu". Protokola maiņa, protams, ir ārpus meinstrīma un ļoti "alternatīvi" un stilīgi un ļauj pacelt savu ego, bet tā ir niecīga daļa no problēmām, un reālās problēmas stāv ārpus šī posma.

 

 

 

Šodien pat aptaustīju Lattelecom iekšējās lietošanas dažus Web+Java mēslus

 

No tavas mutes jau esam dzirdējuši, ka web un java ir mēsli pēc definīcijas, priekš kam runāt tautoloģijās?

Un ja reiz esi tik gudrs, kāpēc neesi visiem pārtaisījis sistēmas "pa savam" - fiksi, uz 1 serverīša, un nepeldies tagad miljardos?

 

 

 

 

ir pat mobilā versija

 

mobilais webs, cik man zināms, nenodrošina notifikācijas un natīvos smukumus, kā arī ne tik forši pielāgojas ekrāna izmēram, kā arī darbojas pārāk lēni - jo sevišķi tas ir jūtams uz vecajām iekārtām un lēniem pieslēgumiem. Kā pagaidu risinājums, protams, mobilais vebs ir labāk nekā nekas. Natīvas mobilās aplikācijas - tas parasti ir woow no lietotāju viedokļa, jo sevišķi jauniešiem, tā ka nopietna projekta gadījumā tāda tiks pieprasīta no lietotāju puses jau tiklīdz sāksies aktīva portāla izmantošana.

 -- 

varbūt kāds no moderatoriem var iznest visu šito protokolkasīšanos piemērotākā topikā? Man liekas, ka tādiem sviestiem te nav jābūt.

Labots Maijs 2, 2014 - usver

[Inspektors Caps]

Mežavecis, kad stāsti kā norēķinu sistēma strādā uz cilvēklasāmajiem formātiem, neaizmirsti, ka visus tos Tavus samurgotos pēdējā augšējā slāņa formātus tālāk dažādās sistēmās transportē dažādi bināri protokoli. Un Webs ir tikai Webā un biznesa vadības IS sistēmās, kas parasti arī ar to saistītas - tās ir tikai divas jomas. Viss pārējais dzīvē apkārt ir binārs! No tiem pašiem TCP, IP, Ethernet, Wi-Fi, Bluetooth, DVB, pat RC-5 TV IR pultij sadzīvē, līdz CAN, Ethernet u.c. Tavā auto, vilcienos, kuģos un lidmašīnās. Tas viss darbojas ar bināriem protokoliem! Savukārt Tu no tā visa spēj saprast tikai vienu biļetes nopirkšanas sistēmu, kas pēc tehnoloģiskā realizācijas līmeņa ir pati mazsvarīgākā.

 

Ja reiz ir tik daudz modernu formāti, tad padalies ar mums, tikai izbeidz šo teorētisko muldēšanu.

Izlasi rakstīto un redzēsi, ka usver jau pieminēja MessagePack, es pieminēju Protocol Buffers un varu vēl piemest piemēram BSON. Un kam Tev vajag daudzumu? Mērīsi lietderību protokolu daudzumos?

 

kļūst aizvien mazāk bināri, jo tam ir loģisks pamatojums - dārga uzturēšana

Ļoti "loģisks" pamatojums. Performance uzlabojas, izststrāde tāda pati, ja arī ne mazāka, bet nezin kādēļ kļūst dārgāks... Izklāsti lūdzu šo dižo loģiku! Piemēra pēc pastāsti kādā veidā iepriekš minētie būs dārgāki par XML/JSON brīnumiem.

 

nav savienojama ar mūsdienu prasībām

Kādām tieši? Ar prasību rīt lopā resursus un ierobežot lietotāja ievadāmo teksta datu saturu?

 

līku sistēmu, kur var kaut kā pielāgot

No kurienes tāds marazmātisks pieņēmums, ka binārs formāts it kaut kā mazāk pielāgojams par cilvēklasāmu? Tādēļ, ka Tu to nespēj saprast?

 

Normāli uztaisīts web serviss dzīvos ļoti ilgi.

Un binārs vēl daudz ilgāk. Esi dzirdējis par tādu Ethernet, kas palaists 1980. gadā, kad vēl Tavi webmurgi nemaz nebija samurgoti? Kopš tā laika tas ir pielāgots n-tās reizes, dzīvo vēl šobaltdien 34 gadus vēlāk, tā popularitāte tikai aug un uz to tiek balstīts ar vien vairāk nākotnes tehnikas.

 

sarunāsim tā - tu parādīsi savu paštaisīto 100+ miljonu risinājumu uz 1 serverīša

Tu izliecies vai tiešām esi tik aprobežots, ka neizproti pat tik fundamentālu lietu kā proporcijas principu? Es teicu, ka VISU var uztaisīt uz viena serverīša? Nē - es teicu X miljonus. Es teicu, ka tehniku var samazināt n-reiz, nevis jebko reducēt uz vienu eksemplāru. Dļa osobih - piemēram, ja n izrādās 4, tad serveru skaitu var samazināt no 80 uz 20 utt. Varbūt tagad pielec?

 

Tev augstākās nav, ja? Savādāk nevaru izskaidrot tādu iespringšanu par to. Turklāt XML neizmantoju datu pārsūtīšanai. Laimīgs tagad?

Laimīgs izmanto JSON un domā, ka esi diži progresējis? Ja patīsim filmu atpakaļ, tad tieši tādi kā Tu pirms gadiem stāstīja, ka XML ir tas megasupervislabākais formāts, kas aizstās visu, bet jau pēc pāris gadiem paši web koderi izdomāja JSON, kas ir tas pats XML sūds, tikai mazāk ož. Un jā, esmu LU datoriķu maģistrs, tikai ar to atšķirību no lielākās daļas, ka saglabāju savu saprātu, paņēmu no turienes visu labo un neļāvos nozombēties trulumam. Atceros kā bakalauru aizstāvēšanā manā dienā bija viens čalis, kuram darbs bija par XML datu bāzēm, kas datus arī glabā XMLā. Darbā un prezentācijā viņš protams izstāstīja cik ūberkruta tas ir un "nu tik būs". Pēc tam Bičevskis (bakalauru programmas vadītājs) un laikam Borzovs (programmētāju programmas vadītājs) žūrijā no viņa vairākas reizes mēģināja izvilināt vai tad tādām datu bāzēm nav nekādu mīnusu (domājot pirmkārt izmēru un performanci), uz ko čalis vienīgo spēja izdvest, ka tās vēl neesot populāras. Pilnīga smadzeņu atrofija!

 

okei, web programmēšanu, acīmredzot, arī neesi realitātē taustījis, bet kaut ko pa ausu galam dzirdējis un tagad kladzini klišejas.

Pat te Tu kļūdies - esmu, un tieši tas ir vēl viens liels iemesls strādāt citās jomās, kur marazms nav tik augstā pakāpē un vispārizplatīts.

 

milzīgs darba apjoms veicams tieši funkcionalitātē

tā ir niecīga daļa no problēmām, un reālās problēmas stāv ārpus šī posma

Kā tas izslēdz normālu protokola izvēli? Nekā!

 

tādi sīkumi, kas dod minimālu efektu, ir tiešām sīkumi, kas ir elementāri labojami un uz kopējo sistēmas stabilitāti iespaidu atstāj tikai uz papīra un procentiem

Tjipa darījis neesmu, bet zinu. Ja viss ir realizēts adekvāti, iespaids ir graujošs - tāds, ka pat mērījumi nav vajadzīgi un viss ir acīmredzams. Elementāri labojams arī tas nav, jo tad daudzi to darītu. Elementāri var tikai nomainīt atsevišķus posmus, uzliekot galos "konvertorus", bet no tā jēga ir tiešām gandrīz nulle. Tas arī ir iemesls kādēļ Tu tā domā, jo neesi izveidojis sistēmu, kas būtu viendabīgi pārdomāta visos posmos.

 

Tu vienkārši aiz 3 kokiem neredzi mežu un iedomājies, ka nomainot protokolu pēkšņi būs paradīze un viss cits 99% darāmais darba apjoms pēkšņi atkritīs.

Jā, šāda fantazēšana un apmelošana ir tas, uz ko balstās Tava argumentācija. Tāda pati arī attieksme pret formātiem - piedomājam neesošas īpašības un bļaustāmies ar "oldskūl, nerulz, jē".

 

mobilais webs, cik man zināms, nenodrošina notifikācijas un natīvos smukumus, kā arī ne tik forši pielāgojas ekrāna izmēram, kā arī darbojas pārāk lēni

Windows 95 logu sistēma gan to visu mācēja jau 20 gadus atpakaļ. Atšķirību izstrādātāju smadzeņu spējās un redzesloka plašumā redzi, vai pašam tas ir par šauru, lai redzētu?

 

Bet, ja atmetam to fantazēšanas demagoģiju, lai diskusijai ir arī produktīvā daļa, Tu varētu konkrēti pamatot šādus marazmātiskos pieņēmumus:

• Cilvēklasāma formāta ieviešana esot parasta ikdiena, bet bināra ir "smalktūnēšana". Īpaši, ņemot vērā, ka visiem ir pieejamas arī visdažādākās gatavās bibliotēkas.
• Ja es saku, ka vajag optimālu protokolu, tad tam tiek pielīmēts "pārējais nav svarīgi", ko es NEESMU teicis! Pamatojums un mērķis? Novērst diskusijas objektivitāti, lai varētu izvērsties bezsatura demagoģijā par stilīgu un modīgu nevis korektu kodu?

Labots Maijs 2, 2014 - Inspektors Caps

[nevertell]

Inspektor, kā ar MongoDB, kas ir noSql kaķu bāze, glabā ekskluzīvi JSON datus un strādā n reizes ātrāk par sql kaķu bāzēm ?

[Inspektors Caps]

@@nevertell, NoSQL jau kā reizi ir atkāpe no SQL, kas ir cilvēklasāms, un tādēļ var būt ātrāks. Un MongoDB ir BSON nevis JSON - tikai apstiprina bināro pārākumu.

Labots Maijs 2, 2014 - Inspektors Caps

[usver]

Ja patīsim filmu atpakaļ, tad tieši tādi kā Tu pirms gadiem stāstīja, ka XML ir tas megasupervislabākais formāts

 

Es nesaprotu - vispirms klārē, ka 

 

"man augstskolā iezombēja, ka vajag visur akli bāzt XML un domāt pašam ar savu galvu ir slikti"

Pēc tam stāsti, ka augstskolas mācībspēki šķībi skatās uz eksotiku no XMLiem. Kur ir loģika? 

 

"mobilais webs, cik man zināms, nenodrošina notifikācijas un natīvos smukumus, kā arī ne tik forši pielāgojas ekrāna izmēram, kā arī darbojas pārāk lēni"

 

 

Windows 95 logu sistēma gan to visu mācēja jau 20 gadus atpakaļ. Atšķirību izstrādātāju smadzeņu spējās un redzesloka plašumā redzi, vai pašam tas ir par šauru, lai redzētu?

 

johaidī, win95 pirms 20 gadiem spēja darboties uz *NIX, uz visdažādākajiem procesoriem? varbūt to izmantosi kā argumentu lai salīdzinātu izstrādātājus? Turklāt win95 logu sistēma bija tieši tāda pati rastrveidīga kā vebi tagad, balstoties uz pikseļiem. Aizej, izvēlies sistēmas fonta izmēru - stāv fiksētie izmēri, kas mūsdienās aizstāti ar "100%/125%/150% utt". Androīdos, piemēram, var panākt, ka aplikācija izskatās identiska uz planšetes un uz maza-mazītiņa mobilā 320x240px displeja, neko baigi netūnējot - fonti proporcionāli, bloki, ikonas.. Windows kā ūbersistēma, es pieņemu, jau gadus 20 atpakaļ to realizēja, ka uz 4k displeja redzēs to pašu, ko uz 480x640, ne?

 

 

 

Ja es saku, ka vajag optimālu protokolu, tad tam tiek pielīmēts "pārējais nav svarīgi", ko es NEESMU teicis!

Malacis! I ne 2 dienas un 5 manas atbildes nepagāja, kad sāc saprast, ka tūnēšana nav prioritāšu augšgalā, un to var darīt tad, kad nav steidzamāku funkcionalitātes vai stabilitātes vai bugfiksu darbu   Turpini tādā pašā garā, un pēc kāda laika arī aptversi, ko nozīmē

JSON ir pietiekami labs formāts - tas spēj nodrošināt to aptuveni 8 miljonu mobilo lietotāju vajadzības. Kad paliks par īsu, tiks nomainīts uz msgpack vai citu formātu, taču pagaidām pietiek un debugošanai ļoti labi der

 

 

 

 

ieviešana esot parasta ikdiena, bet bināra ir "smalktūnēšana"

Ja piefiksēji, tad runa ir par 100+ miljonu sistēmu. Kurā JAU ir JSON. Jaunā sistēmā bāz vienalga ko, par ko esi 100% pārliecinājies jau citos projektos, bet esošā - jā, protokola aizvietošana ir smalktūnēšana. Kas tur nesaprotams? Ir 101 smalktūnēšanas darbs, ko var darīt, bet vicināties ar 1 un no tā izvērst veselu flame war, paralēli apspriežot apkārtējo intelektu - nu piedodiet, bet tā ir matu skaldīšana, ko esmu jau vairākas reizes atkārtojis šajā topikā. Tas sāk pielekt?

Labots Maijs 2, 2014 - usver

[Inspektors Caps]

augstskolas mācībspēki šķībi skatās uz eksotiku no XMLiem

Aha, sametam visus pasniedzējus vienā maisā... Un neienāk prātā, ka kāds var izmantot to pašu XML kaut cik saprātīgi un reizē vēl arī apzināties tā mīnusus un vietas, kur to pielietot ir absurds? Tev tie laikam liekas savstarpēji izslēdzoši jēdzieni - tas, ka kāds izmanto XML, un reizē ir spējīgs arī saprast, ka kaut kam "tik perfektam" kā XML ir arī pamatīgi un milzīgi mīnusi.

 

johaidī, win95 pirms 20 gadiem spēja darboties uz *NIX, uz visdažādākajiem procesoriem?

OK, Windows NT ir tāda pati logu sistēma.

Supported platforms: IA-32, x86-64, DEC Alpha, MIPS, PowerPC, ARM, Itanium

Tāpat varam ņemt klāt Unix, Linux, BSD - uz cik dažādiem procesoriem tie darbojas?

Un... Windows darboties uz *NIX? Tā ir Tava izpratne par datoriem un programmatūru? Vai Tu vēl tajos laikos, kad Windows 3.x darbojās uz DOS?

 

aplikācija izskatās identiska uz planšetes un uz maza-mazītiņa mobilā 320x240px displeja

Un tātad tā ir truli neefektīva uz planšetes vai vispār nelietojama uz mobilā, jo nav viena proporcionāli identiska interfeisa ekrāniem, kam pikseļu skaits atšķiras n-tās reizes. Papildus resaizošanai, dinamiska satura un izvietojuma maiņa ir tas, kā piemērotību realizē labos produktos.

 

es pieņemu, jau gadus 20 atpakaļ to realizēja, ka uz 4k displeja redzēs to pašu, ko uz 480x640, ne?

Pareizi pieņem! Windows logu sistēmai nav nekādu problēmu ar proporcionālu resaizošanu. Vienīgā problēma ir tāda, ka visādi līkroči masveidā ir sataisījuši līksoftus, kuros tas vienkārši nav ņemts vērā.

 

Malacis! I ne 2 dienas un 5 manas atbildes nepagāja, kad sāc saprast, ka tūnēšana

Tevi gan nevaru paslavēt, jo Tu vēl ar vien neesi sapratis, ka es nerunāju par tūnēšanu bet par vienkārši parastu pirmreizējo implementēšanu, kas laika ziņā ir aptuveni vienāda, izmantojot jebkuru protokolu.

 

Ja piefiksēji, tad runa ir par 100+ miljonu sistēmu. Kurā JAU ir JSON.

Tavi 100+ miljoni sākumā bija 8 miljoni, bet tas tā. Īstenībā izlasi topika nosaukumu un autora tekstus, lai saprastu par ko vispār ir runa.

 

apspriežot apkārtējo intelektu

To te dara Mežavecis, kladzinot "nejēdz, oldschool, miris", bet nepasakot pilnīgi neko konkrētu un tehniski objektīvu.

Labots Maijs 2, 2014 - Inspektors Caps

[zeds]

Jums cilvēks pajautāja kā notiek aplikācijas izstrāde un uzturēšana , bet jūs sākat krāniem un protokoliem mērīties un viens otru zākāt. Pašiem nav kauns ?

[Mezavecis]

Aizvācu bezjēdzīgos citātu palagus. Biedri, diskutējam par lietu un paturam prātā, kas rakstīts pirmajā postā. Nu nebūs te audiofīlu vai citu ticību karu. 

[Inspektors Caps]

Tātad bez palagiem un konkrēti...

 

 

datu apmaiņa ar XML/JSON

Tiek ieteikti jau saknē līki protokola formāti. Tie ir cilvēklasāmi (human-readable) formāti, kas, salīdzinot ar bināriem:

1. Aizņem vairāk datu pārraidē.
2. Aizņem vairāk RAM gan klientam, gan serverim.
3. Tērē vairāk CPU gan klientam, gan serverim.
4. Tērē vairāk enerģijas un samazina iekārtas darbības laiku no akumulatora.
5. Ierobežo lietotāja ievadāmo teksta datu saturu - ir neatļautie simboli.
6. Ir nedrošs dēļ iespējamām datu injekcijām.
7. Var paņemt vairāk izstrādes laika dēļ tā, ka jāievieš arī teksta datu pārbaudes un "eskeipošanas".
8. Vairāk koda bez jēgas gandrīz vienmēr nozīmē arī vairāk vietas potenciālām nepilnībām, kļūdām un caurumiem.

Kā gatavus bināru protokolu formātu piemērus var minēt MessagePack, Protocol Buffers, BSON, Thrift, Avro, BERT un, ja pameklē, noteikti ir vēl diezgan. Retākos gadījumos var būt, ka labāk ir izstrādāt specializētu protokolu, bet, lai to izstrādātu pārdomātu, tāpat ir jāizpēta jau esošie un to principi. Par šādiem protokoliem un to izstrādi var iesākumam palasīt piemēram šeit:

https://github.com/blog/531-introducing-bert-and-bert-rpc

[AndrisBB]

nu tad vajadzeja iekopet tos izdzestot ierakstus jauna temaa ar nosaukumu JSON vs Binarie

[usver]

Ja aplikācija izrādīsies veiksmīga un aizies vairāk kā dažu tūkstošu auditorijai, tad bez jaunu fīču izstrādes uzturēšanā ietilps galvenokārt izdabāšana novecojušiem modeļiem, un tādu tālruņu lietošanā ir ļoti daudz.

 

Šim klientu segmentam absolūti pajāt par to, vai milzu stringa dekodēšana (viss wall) aizņems par 100KB vairāk vai mazāk atmiņas, nekādus reālus krašus neizraisīs. Stringu apstrāde problēmas neizraisa.

1000kārt aktuālāk būs tas, ka krašus izraisīs bildes - jo lielākas un vairāk to un jo Android vecāks, jo lielāks risks nokrašot.

VM atmiņa ir ierobežota, turklāt uz Android 2.x ir vairāki šķēršļi efektīvai atmiņas izmantošanai (lasi - tiek kūtri atbrīvota, nav direktīvu prasīgu aplikāciju papildus atmiņas izmantošanai). Rezultātā tieši Android 2.x iekārtas pie lielāku bilžu dekodēšanas vai resaizošanas pirms sūtīšanas uz serveri ņems un nokrašos (lietotājs gribēs pievienot savu 3000x3000px bildi no spoguļkameras, kuras pārsūtīšana pa GPRS aizņemtu vairākas minūtes), un 90%+ krašu būs saistīti tieši ar šo problēmu - VM atteiksies dekodēt lielāku bildīti (kas pat zem 500x500px var aizņemt atmiņā 4..8MB, piemēram), jo tai pietrūks atmiņas, kas būs aizsista ar citiem Bitmap objektiem, kam arī jārādās tajā pašā lapā. Būs nepieciešams uzticams kešošanas un atmiņas pārvaldības mehānisms, kas spētu gan parādīt visas prasītās bildes, gan spētu tikt galā ar atmiņas ierobežojumiem.

 

 

Jaunākajām iekārtām, investoriem, gīkiem un citiem cilvēkiem ar spīdīgiem, jauniem tālruņiem viss sākumā ies, taču būs noteikta daļa lietotāju, kam tās pašas lielbildes būs potenciāls risks nokrašošanai, kā rezultātā atsauksmes iekš Google Play papildināsies ar "sūc, fui, slikta aplikācija", kas arī ietekmēs kopējo tēlu.

Nemūžam neesmu redzējis atsauksmi, ka "Aplikācija slikta, jo mans tālrunis 5min ātrāk jāliek lādēt, kopš uzliku šo aplikāciju".

Toties "Aplikācija slikta, jo ik pa laikam nokrašo" - tādu ir gana daudz, un tieši veco tālruņu segmentā, kas nav mazāksvarīga lietotāju grupa.

 

 

Būs vai nu jāpatērē laiks tūnēšanai, samazinot krašus pie lielām bilžu operācijām vai jāsamierinās ar kādas lietotāju grupas atmešanu (<= 2.3, piemēram), kas arī tēlam par labu nenāk - man personīgi iestājas "WTF??", ja aplikācija ir marķēta kā "Android 4.0+ only".

 

Nākamais - būs mākslīgi jāliek klāt tīkla atkārtotie pieprasījumi. Piemēram - lietotājs sēž patālāk no sava Wifi rūtera vai lieto mobilos datus. Atsevišķi rekvesti neaizies un ķersies tādos apstākļos, lietotājam rādīsies "waiting" un viņš valkās to "refresh, refresh", gaidot rezultātu, pie tam Android noklusētā HTTP klienta UN pat vairāku http libu paredzētais retry mehānisms http savienojumiem nenostrādā kā nākas, ja pazūd tīkls. Rezultātā būs daļa klientu, kam bilžu ielāde/augšupielāde raustīsies, kas arī būs iemesls neapmierinātībai.

 

 

Nākamais - responsivitāte. Jo vairāk dažādu ekrānu, ko var atvērt vienu virs otra, jo lēnāk viss notiek. Turklāt tas nozīmē dažādu ekrānu turēšanu atmiņā, kas vecajiem tālruņiem liek iespringt. Foršāk ir taisīt ar fragmentiem - tad viskautkas tiek turēts paralēli atmiņā, taču netiek taisītas jaunas ekrānu instances vai tml, kur tas nav vajadzīgs. Un fragmenti ir pieejami Android 2.x tikai ar compatibility bibiotēkas palīdzību - tāda humānā palīdzība/servispaka no Google, mēģinot nodrošināt daļu no jaunāko versiju funkcionalitātes, izmantojot citas klases, kas nozīmē papildu riskus.

 

Nākamais - partneru SDK. Piemēram, vai esat ievērojuši, ka iekš Instagram, pievienojoties ar Facebook, netiek izmantoti natīvie dialogi permisiju pieprasījumam, bet rādās vebisks dialogs? Atveriet Astro failu menedžeri un pamēģiniet salinkot ar savu FB kontu - izleks natīvs(androīdisks) permisiju pieprasījums, kuru saņemot iziesiet pēc tējas, bet atnākot atpakaļ ekrāns būs izslēdzies (rets scenārijs, bet mēdz būt). Ieslēgsiet un pamēģināsiet apstiprināt to - un .. Bingo! Liela iespēja, ka to nevarēsiet, jo FB natīvais permisiju pieprasījuma dialogs būs uzkāries. Lūk arī atbilde, kādēļ Instagram forsē vebisko versiju, lai gan pēc priekšrakstiem un loģikas labāk būtu izmantot FB-integrētā natīvā. Un tas nav vienīgais gadījums, kad jāsaskaras ar sviestiem.

 

Nākamais - NDK (jeb C/C++ koda ielāde androīdā kritisko operāciju paātrināšanai). Ar to arī ir jautri un ir savi bugi uz Android 4.x versijām ( https://groups.google.com/forum/#!topic/android-ndk/N8FLjvM81pg ).

 

Vārdu sakot, ir vesela rinda lietu, ko nāksies uzturēšanas gaitā attīstīt/uzlabot un pēc tam vēl pietūnēt, lai panāktu labu, smuku un stabilu darbību dažādos neierastos scenārijos, jo sevišķi pie klienta vecākas Android versijas vai uz gļukainām versijām ( https://code.google.com/p/android/issues/detail?id=58043 ) vai gļukainiem dzinējiem (KitKat 4.4 bleeding-edge Chrome dzinējs - nejaukt ar regulāri updeitot chrome pārlūku - ir ar nopietniem bagiem, bet reti kurš to udpeitos ).

 

 

kā mēs redzam, aplikācijas uzturēšana ir dažādu problēmu risināšana, lai, pirmkārt, visiem viss ietu stabili - pat tiem, kam ir aizvēsturiskas un mazjaudīgas iekārtas. Un iOS nav izņēmums - tajā ik pa laikam aplikācijās atsakās no 3.x vai 4.x vai 5.x versiju suporta, tādējādi atvieglojot jaunāko versiju uzturēšanu. Tūnēšana, izmantojot jaunākos video kodekus tām versijām, kas to atbalsta un pēc iespējas savietojamākus, lai visiem viss ietu; izmantojot videokarti priekš bilžu ātrākas resaizošanas un blablabla un blablabla - tas viss ir tikai pēc tam, kad visiem viss iet stabili un nekrašo (bet līdz tam vēl garš ceļš ejams). Tas tā - kripata reālās dzīves.

Labots Maijs 3, 2014 - usver

[elxnis]

 

 

man personīgi iestājas "WTF??", ja aplikācija ir marķēta kā "Android 4.0+ only".

Man gan liekas, ka 4.0 priekš pirmās versijas ir tīri OK, ņemot vērā, ka tā tika izlaista 2011. gadā un 4.0+ lieto 80%+ lietotāju.

Kā pats teici, tad to visu uzturēt ir ļoti sarežģīti un tas pie šāda izmēra projekta noteikti neatmaksājas. Par to var domāt, kad produkts attīstās un ir pieprasījums pēc atbalsta vecākām ierīcēm.

[usver]

Nu ja kādam ir vēlme atmest pilnībā 20% auditorijas, tad uz priekšu, bet pagaidām ne FB, ne Twitter, ne Instagram, ne BBC News, ne citie lielākie uzņēmumi to nav sadūšojušies darīt.

IMVHO kients, kam reizi dienā nokrašo aplikācija (bet lieto un iesaka draugiem), ir labāks par dusmīgu klientu, kam vispār nav pieejas konkrētajai aplikācijai (nelieto un draugiem neiesaka). Vecie zina, ka kraši viņiem mēdz būt dažādās aplikācijās un ka telefons tomēr ir vecs un neuztver to TIK traki. 

 

Turklāt ne jau tikai 2.x ir kraši - ir vesela rinda "apgraizītu", vecu 4.0 iekārtu (15..16%), kam arī mēdz būt līdzīgas problēmas - stabilākie Android sākas no 4.2+. Atmetot 20% visvecāko klientu, problēmu nepaliks par 20% mazāk.

[Inspektors Caps]

@@usver, bez ņirgāšanās... Noteikti varētu arī pats izpētīt, bet, tā kā Tu esi tajā visā iekšā, tad gan jau Tev atbildes būs pie rokas.

 

 

 

pat zem 500x500px var aizņemt atmiņā 4..8MB

512px * 512px * (24b / 8b) = 768 KB

Kas, kur, kā apēd pārējo RAM? Kāds šajā ziņā ir iOS?

[usver]

tās ir java konstrukcijas.

iOS pilnīgi pajāt - viņam nav jādzīvo iekš JVM un viņš var noēst cik vien grib, neiekļaujoties tajos 12..24..40MB Heap'ā, iekš kā bieži vien ir iesprostota Android aplikācija. Turklāt tas ir pats par sevi ObjectiveC, kam vieglāk darboties ar daudziem objektiem.
 
http://stackoverflow.com/questions/2067955/fast-bitmap-blur-for-android-sdk
 

For reference, using Yahel's Java function, it took 10 seconds to blur my 480x532 pixels image with a blur radius of 10. But it took 250ms using the native C version. And I'm pretty sure it can still be further optimized... I just did a dumb conversion of the java code, there's probably some manipulations that can be shortened, didn't want to spend too much time refactoring the whole thing.

Gribam ātrumu pie milzīga objektu skaita - lietojam JNI (C/C++ iekš Java), kam nav jāatskaitās par katru soli pārējiem objektiem. Vienreizējām lietām tas nav TIK izteikti.

 

4..8MB nav precīzi dati, bet nu ideja tāda ir - jau iepriekš esmu teicis, ka iOS var nežagojoties iebāzt 2MB lielu attēla failu fonā ne par ko nedomājot, bet Android tā nevar.

olimpiādes tipa darbus programmējot, esmu pats arī taisījis 2 dažādos variantos - 1) ar ArrayList 2) ar int[] masīvu

jo prastāki objekti figurē, jo ātrāk inicializācijas notiek.

 

 

512px * 512px * (24b / 8b) = 768 KB

 

 

Drīzāk 512px * 512px * 4bytes == 1MB

http://developer.android.com/reference/android/graphics/Bitmap.Config.html - atkarīgs no tā, ar cik baitiem kodē pikseli. Normālam izskatam vajag tos 4, mazāk izskatās drausmīgi. Iespējams, ka pats ImageView, kas tiek izmantots, dubulto nepieciešamās atmiņas apjomu. Jo ne tikai atmiņā vien tiek glabāts - tiek zīmēts arī kaut kur. Rezultātā paņem un uzzīmē bildīti - nepieciešamā atmiņa izaug divkārt. Precīzus mērījumus neesmu veicis, bet katrā ziņā 100KB bildītes nolasīšana un izmantošana noteikti nebūs 100KB atmiņā.

Labots Maijs 3, 2014 - usver

[nevertell]

Cik man saskarsme ar Androīda atmiņas ierobežojumiem, visu panākt ir ļoti vienkārši. Pirmkārt, ja bildes lādē no servera, obļegāti kešo tās uz diska, un obligāti lieto bitmapu kešu. Protams, vietu uz diska vajag rezervēt, un tur sākās stulbi hack'i un twerkaraundi, bet krešo daudz mazāk. 

 

Un inspektor, varbūt uz windofs 95 tāda lieta vēl nebija, bet visi modernie bitmap'i satur sevī informāciju par caurspīdību, lai dažādus attēlus var krāmēt viens otram virsū. Bet protams, nach tas vispār vajadzīgs.