Tavs Ajax ielādes ātrūms.

[Wuu]

Cik ir minimālais ielādēs laiks ko varētu sasniegt no brīža kad tiek nosūtīts JSON caur ajax un tiek saņemta atbilde. Vai 200ms ir ok? Gribētos ātrāk. Mēru ar Firebug. Ja tā vispār ir pareizais veids mērīt. Vienkārši tiek lietota pusjēla Windows mašīna (Nav mana izvēle). Kādā ir kolēģu pieredze šajā jautājumā?  Ja 200ms ir stipri par lēnu, varētu papēti šo jautājumu.

[daGrevis]

Oh, un iečekoju — mana versija par to, kas ir optimizācija, ir tā versija, ar ko programmētāji arī saprot vārdu “optimizācija“.

 

https://en.wikipedia.org/wiki/Program_optimization

[jurchiks]

Nu tad es sevi uzskatu par ko vairāk, kā programmētāju.

[codez]

Par ko tu sevi uzskati?

[Kavacky]

P.S. tiem, kam baigās pretenzijas pret optimizēšanu - debagojot kodu un to optimizējot, var ļoti daudz ko iemācīties, un tas, ko iemācies, ātri vien pārvēršas pieradumā, turpinot programmēt, tu tās optimizācijas iekorporē kodā pat nedomājot.

Es to saucu par programmēšanu.

 

 

Par ko tu sevi uzskati?

Koderis, LOL. :D

[jurchiks]

Are you having fun yet?

[gurkjis]

Es arī agrāk aizrāvos ar optimizācijām. Sākumā tas likās pareizi (oldschool domāšana no seniem laikiem, kad datori bija lēni). Tas bija reāls iemesls, lai to darītu - tagad nē - dators tagad ir gana varens.

Līdz vēlāk sāku just, ka šis ieradums mani "velk uz leju" un novērš fokusu no projekta roadmapa. 

 

Tāpēc dodu priekšroku tādam kā "iteratīvajam izstrādes ciklam". Paņem pirmo kārtu pa rupjo uzrakstam. Algoritmus visvienkāršākos, kas vistuvāk aiztiek real-world problēmu, nevis optimizāciju (ļoti konkrēti šīs detaļas var izdalīt). Es pats varu saputroties, ja uzreiz ņemu "super optimizēto variantu", un tā varu izlaist detaļas, kas attiecas uz patieso problēmu. 

Nofinišojam projektu, vai dabūjam līdz kaut kādam milestone. Nevienam citam, izņemot programmētājus, neinteresē, kas tur apakšā ir. Visi parasti redz tikai UI un datus, nu un tad no šāda viedokļa jābūt visam kārtībā.

 

Vēlāk, kad projekts palaists, ja resursi un laiks ir tad, var arī optimizēt. Vai ja ir konkrētas sūdzības par lēnību. Ņemam vērā acīm redzamos slowdowns, nevis acīm nemanāmās milisekundes.

 

Piekrītu, ka rodas kaut kāds programmētāja kaifs, rakstot optimizācijas, bet, ja gribi no puikas par īstu veci izaugt, un virzīties uz priekšu, tad sevi kaut kā japiebremzē uz šīm baudām. 

Edited September 18, 2014 by gurkjis

[daGrevis]

Labi teikts! Āmen.

[codez]

Pilnībā piekrītu gurķis teiktajam. Lai arī vienkārša, bet tā ir vērta gudrība, kas būtu jāņem vērā katram jaunajam, jo šipot produktu ātri, ir ļoti svarīga biznesa sastāvdaļa.
Lūk, ko Gajs Kavasaki saka par lietām, ko iemācījās no Stīva Džobsa:

 

 

Real CEOs ship.

For all his perfectionism, Steve could ship. Maybe the product wasn’t perfect every time, but it was almost always great enough to go. The lesson is that Steve wasn’t tinkering for the sake of tinkering—he had a goal: shipping and achieving worldwide domination of existing markets or creation of new markets. Apple is an engineering-centric company, not a research-centric one. Which would you rather be: Apple or Xerox PARC?

 

http://blog.guykawasaki.com/2011/10/what-i-learned-from-steve-jobs.html

[Kasspars]

Codez, tas raksts ko ieliki ir baigi labs! Izdrukāšu un palikšu zem spilvena, kad iešu processēt dienas laikā uzņemot informāciju

[codez]

Tam rakstam ir arī atbilstošs video ar pašu Kavasaki:

https://www.youtube.com/watch?v=DR_wX0EwOMM

[Wuu]

Es arī agrāk aizrāvos..

 

Tieši tāpēc android markets un widows platforma ir pārpludināta ar pusfabrikātiem, kas labākajā gadījumā strādā. Bet tāda pieeja darbojas no biznesa skata punkta, jo cilvēki kas saņem tavu produktu nezin, kā programmai būtu jāstrādā un cik ātri. Lielākā daļa pasaules joprojām tic, ka programmēšana ir maģija.    

Edited September 18, 2014 by Wuu

[daGrevis]

> Lielākā daļa pasaules joprojām tic, ka programmēšana ir maģija.

 

Es esmu redzējis lietas. Programmēšana ir maģija un mēs esam burvji.

[jurchiks]

@gurkjis - piekrītu, ka sākotnēji optimizēt nevajag. Es arī papriekš uztaisu pamata versiju un tad, ja ir kaut kas, par ko es jūtu, ka tas nav īsti kārtīgi uzrakstīts vai jau rakstot esmu paredzējis kaut kādas problēmas, bet tajā brīdī tas nebija svarīgi (parasti tad piemetu klāt TODO), tad es to koda gabalu uzlaboju līdz tādam līmenim, ka viss liekas kārtībā.

Es tā īsti nemāku to paskaidrot, bet pārsvarā, lasot kādu koda gabalu (šeit tiek pieņemts LASĀMS koda gabals), vienkārši var just, vai kods ir pietiekami kvalitatīvs vai tomēr kaut kas nav kārtībā.

 

@codez - "šipot produktu ātri ir ļoti svarīga biznesa sastāvdaļa."

Quality over speed. Always. Steigties māk visi, bet uztaisīt kvalitatīvu produktu...

 

@Wuu - so true. Man pašam uz mobilā tagad ir ļoti jocīgs bags visprastākajai piezīmju aplikācijai - on-screen widgetā flipojot no vienas piezīmes uz otru, pa vidu vienmēr ir 4 tukšas piezīmes, vienalga, kurā virzienā flipo. Atverot piezīmju aplikāciju, uzrādās divas piezīmes un nekas cits, bet, widgetā flipojot, ir šāds gļuks. Vienkārši smiekli nāk par tādu līkrocību.

 

@daGrevis - žēl tikai, ka vairums burvju ir iesācēji, it sevišķi web developmenta kategorijā.

[briedis]

"parasti tad piemetu klāt TODO" - Technical debt

 

"Quality over speed. Always." - Ja taisi jaunas lietas, eksperimentē, nav jēgas, jo 90% gadījumu tāpat projekts nekad neaiziet. Izniekots resurss. (protams, nevajag ieslīgt galējībās)

[jurchiks]

Es tos TODO parasti tajā vai nākamajā dienā arī uztaisu.

 

Par otro punktu - vai tu gribi teikt, ka labāk rakstīt knapi pieņemamu kodu un uzlabot to tikai tad, kad absolūti nepieciešams?