gurkjis

Par SQL versionēšanu, es metu acis uz šo te: http://www.liquibase.org/ - bet vēl nav sanācis lietot. Izskatās, ka ir pieejami vēl citi, līdzīgi risinājumi. Šis open source.

Nu lai raksta kā grib.... ja vien nav kaut kāds ļoti nopietns iemesls, kāpēc vajag validāciju. ja vajag izdalīt vārds/uzvārds, tad 2 atsevišķi lauki.

nē! Man vajag vismaz 1000 postus dabūt, tāpēc rakstīšu whatever kas ienāk prātā!

Mācību procesā tas var būt vertīgi, zināt low-level lietas, lai programmētājam veidotos plašāks skatījums uz lietām. Bet no produktivitātes viedokļa, ir izdevīgi sēdēt pēc iespējas augstāk. Man personīgi neinteresē, ka mašīna mazliet lēnāk darbosies, kad darbinās kodu no 10k source. Kad ātruma problēmas duras acīs ,tad sāku domāt. Tas ir no sērijas - premature optimization is root of all evil.

ok par mysql_ vs mysqli_ tas tā, vairāk domāju plain queryju vietā ORM izmantot, lai ir abstraktēts pāri un tādējādi vienkāršāk lietojams.

Ja taisi no 0 , tad labāk neizmantot vecā stila mysql_* funkcijas. Labāk PHP frameworks + ORM. Bet laikam jau par vēlu, ja darbs ir iesākts...

Pagremošu to visu kādu laiku.

Tātad tas ir izdevīgi paralēlajai programmēšanai. Ja es rakstu algoritmu tikai 1 threadam, tad vai immutable pieeja ir tikpat noderīga ? Pastudēšu. no wiki: "If an object is known to be immutable, it can be copied simply by making a copy of a reference to it instead of copying the entire object. Because a reference (typically only the size of a pointer) is usually much smaller than the object itself, this results in memory savings and a potential boost in execution speed." - šeit teikts, ka immutable objektus nav obligāti jākopē, bet var arī uztvert kā references. Tas nomierina. Tad immutable state attiecīgi nodrošina valoda, ar vai bez references lietošanas.

Man liekas absurdi dažus megabaitus lielus objektus padot funkcijai kā value. Milzīgs, nevajadzīgs performance overheads. Visdrīzāk, ka pagaidām nesapratu daGrevis domu. Pameklēju pēc "immutable function parameters" - tiešu skaidrojumu neatradu, taču liekas, ka šur tur immutable ir kā opcija uz atsevišķiem mainīgiem vai pielietojuma gadījumiem. Varbūt vari iemest linku uz info vai google keywords ? edit: Piemērs: man sistēmā ir objekts A, bet ir kaut kāds process citur, kas ņem A un izsauc tā metodes. Kā gan es bez references to izdarīšu ? To nevar izdarīt. Ja padosi kopiju, tad izmaiņas aizies uz kopiju, nevis tieši A instanci.

1. indeksi ? visur, kur ir kondīciju matchs un ierakstu sets, no kura izlasīt, ir paliels: 1.1 "....posts t2 on (t1.tid = t2.topic_id)" - t2.topic_id ir indekss? 1.2 "....comments t3 on (t1.tid = t3.link)" - t3.link ir indekss ? 1.3 "...where t1.forum_id" - t1.forum_id ? ja palaidīsi kveriju ar EXPLAIN keywordu priekšā, tad iegūsi precīzāku info, kas tiek darīts, varbūt vari iemest te forumā rezultātu no šī kverija.

man liekas, ka NodeJS ir labs variants, jo tas Javascripts tāpat JIT mehānismā tiek kompilēts uz mašīnkodu, tāpēc ņemt C būtu izstrādes overheads. Ja ļoti gribas, tad labāk Haxe, kas kompilē uz C source un nav jāuztraucas par manuālu memory menedžmentu un citiem low-level niķiem. Lēnākais posms drīzāk būs tīkls vai datubāze. DB es izvēlētos MongoDB.

Reizēm ir ļoti veselīgi ielikt savus neironus citos kontekstos, sporta pēc. Tā rodas jauni skatījumi uz ierasto.

Klientiem parasti neinteresē, kas par tehnoloģijām ir tur apakšā.

jā, tad paliek htaccess variants (nepatīk, man ka ar mulsinošiem skaitļiem jāņemās, nevis konstantiem) vai iekš php koda: ini_set('error_reporting', E_ALL & ~E_NOTICE);

iekš php.ini: error_reporting = E_ALL & ~E_NOTICE

Lai labāk saprastu lietas, CMS veidošana palīdz. Protams, ne jau no biznesa viedokļa tas ir labi. Izprast un hakot esošu CMS arī nav slikta ideja, tikai tas būtu mazliet savādāk, kaut gan tomēr ieteicamākais ceļš. Tikai baigi svarīgi, kuru CMS... nezinu ko ieteikt.

Abstrakciju spēks ir tajā, ka tās paņem grupu ar apakšentitijiem un nogrupē vienā jaukā kopā, tādējādi kopskats ir vienkāršots. Tāpēc, vbz, to, ko Tu vēlies pateikt mums - varbūt pamēģini abstraktēt (t.i. novienkāršot), lai varam normāli, pakāpeniski uztvert. Pa lielam, pavisam abstraktā galā līdzīgi saskatu risinājumu lietderīgumu (izlasot pirmo teikumu - "viss balstās uz layeriem, un abstraktu entītiju, vienalga kādu"). Bet nu šo "paradigmu" var daudz kur realizēt. Tavā tekstā abstraktas lietas jaucas ar detaļām. Piemēram, esmu vienkāršs Tava produkta potenciālais lietotājs. Kā lai zinu, ka tas ir kruts produkts ? Manā skatījumā, kruts = vienkārši lietojams, kas apakšā dara powerful lietas.

Nav tā, ka es testus ienīstu, bet man ir tikai priekšstats izveidojies par tiem, kā arī neesmu vēl praksē tos izmantojis reālā projektā, kas jāuztur. Visam savs laiks. Kad izjutīšu šo "sāpi", ka man tagad lielāks projekts brūk pie izmaiņām, tad arī ķeršos klāt.

- vari sadzīvot / izdzīvot / tikt sveikā cauri bez ciešanām ? Tad ir ok. Galvenais, lai gan Tu, gan arī apkārtējie (klienti, kolēģi) būtu apmierināti dēļ Tava darba.

- diskusijas augstāk to tā iekrāsoja, taču definēsim a) "melnu" un b) "baltu": a) domā tikai par to, lai ārējais rezultāts ir labs, bet nepadomā par to,vai nebūs pēc tam baigais murgs projektu tālāk attīstīt b) domā tikai par koda kvalitāti, aizmirstot, kas pasaulei ārēji ir vajadzīgs tagad iedomājies skalu A.............B, kur A = 0 un B = 1.0 un piešķir sev vērtējumu, kurā punktā atrodies ja esi intervālā no 0.25 līdz 0.75 , tad es neteiktu, ka esi tikai melns vai balts. Kā arī, šo forumu lasa vairāki cilvēki, es nerakstu konkrētām personām, bet ideju sēklas, ko apgremot, varu pa ceļam aizņemties.

Nu ja, nevar lietas iedalīt tikai melnā un baltā. Māksla arī tad rodas, kad Tu primāri bliez projektu "pa rupjo" un ātri, bet tai pat laikā kods ir kvalitatīvs, taču tas nāk tikai ar laiku. Tāpēc, ja nesanāk apmierinošu vidusceļu izpildīt, tad variē ar taktiku - vienā gadījumā cērt pa ātro, citā spied uz kvalitāti (nu, piem. saviem hobij projektiem). Un tad ar laiku šīs abas taktikas apvieno. Un tā tas arī citur dzīvē, ņem praktizē galu A, tad B un pēc tam jau varēsi pa vidu šiem turēties, jeb var teikt, ka pratīsi abas lietas reizē. Par testiem - nu es arī pagaidām kā Jurchiks, pret tiem atņirdzu savus zobus, jo man liekas, ka tas ir pārāk sarežģīti (apjomīgi), tāpēc man to negribas darīt. Visur, kur ir apjoma darbs, es domāju kā to apiet, lai man nebūtu kā robotam tās lietas jāknabā pa vienai. Vienkāršāk būtu tā: man ir aplikācija, kurai ir koka struktūra no aktivitātēm, kas veidojas, staigājot pa UI (t.i. simulējot lietotāja visus iespējamos ceļus,ko tas varētu izstaigāt). Dažādi user-generated events (piem. keyboard entry). Attiecīgi viss kods tiktu izpildīts no paša augstākā abstrakcijas slāņa (nevis individuālas metodes testējot). Un tā kā tas notiek no pašas augšas, tad jau testu apjoms vairs nav tik liels :) Otrs tas,ka tiktu testēts tikai un vienīgi tas,kas aplikācijai tiešām nepieciešams. Ķeram exceptions un log messages. Testus palaižu ar 1 pogas spiedienu, vai periodiski, vai uz dažādiem datu setiem, utt. Tur, protams, ir vēl "brīvie gali", kas vēl nav skaidri, kā to visu ideju nosiet, tā lai praksē strādātu.

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.

Grasījos paskatīties AS2 daļu un varbūt pārrakstīt uz Haxe. Bet tur ir parasta input forma Flashā bez nekādām fancy lietām izmantota. To var lieliski realizēt ar HTML + PHP. Esi pārliecināts, ka Tev vajag tieši Flashā ?

Ja testē to AS2 daļu, tad skaties, cik tālu tiec, kas strādā, kas nē, kāds errors metas, utt. Bet vispār, ja mācies Flash virzienā, tad labāk izvēlēties Haxe valodu, ko kombinācijā ar OpenFL API, varēsi aplikāciju papildus vēl kompilēt uz mobilajiem telefoniem un desktop vidēm. Saka, ka "Flash is dead", un ja tas kļūs pavisam nepopulārs, tad varēsi tusēt pa pārējām platformām, izmantojot esošās zināšanas par valodu un API.

par 1) un 2) risinājumiem biju apzinājies. Bet interesanti par ReactJS.