briedis

Nu jā, citiem labāk patīk apkraut sublime ar piecdesmit šaubīgiem pluginiem, bet citiem patīk lietot rīkus, kas vienkārši strādā.

http://www.jetbrains.com/phpstorm/webhelp/using-file-watchers.html Es lietoju arī pluginu, kas ļauj importēt CSS izmaiņas konkrētajiem propertijiem/stiliem, kas tika labotas caur firebug. Teiksim, atveru firebug, pabīdu kko pa pikseļiem, pamainu fonta izmērsu utt, un IDE nospiežu podziņu - import, un vajadzīgie propertiji uzstādās attiecīgajās vietās. Principā IDĒ ir viss - VCS integrācija, ssh termināļi, db pārlūks, strādā DB tabulu suggestioni kodā, remote hosti, automātisks deployments/syncs uz izstrādes serveri, debuggeris, bāc, ir viss, ko vien varētu vēlēties :) Ir pat markdown preview turpat labojot .md failus :)

> Tāpēc, ka tu neesi vienīgais komandā un visiem nevajadzētu izmantot PHPStorm vai whatever tu tur lieto. Ye, mums tieši tā bija problēma, kad cilvēki lietoja kaut kādus "sublime", u.c. teksta redaktorsu, taisīja visādas stulbas neuzmanības kļūdas utt. Tagad visi zolīdi kodē phpstormā, jo tas ir labākais, kas ir pieejams.

Ko tu stāsti? tikko teici, ka ar drupal ņemies jau 8 gadus.

Un tiešām Tev neleca nekāds errors, kad mēģināji selektēt no neeksitējošas tabulas? Traki gan...

Reāli debīls jautājums, bet vai esi ieslēdzis error reportingu? (E_ALL)

"Tur var būt daudz knifu ,,, - testēt un debugot" Nu nez, vai tad tev kādreiz ir tā gadījies, kad kods salūzt, kaut kas vairs nestrādā, kā vajag? Man liekas, ka tur ir problēma kodā, slikti uzrakstīts. Un vispār, tajā linkā ir apakšā dots: "See also the migration guides for PHP versions 5.0.x, 5.1.x, 5.2.x, 5.4.x and 5.5.x."

Nu 5.2 gluži nav 5.3 http://php.net/manual/en/migration53.php

Interesanti, tiešām var kaut ko nopelnīt ar kaut kādiem hostingiem vēl? Ņemot vērā, kādi ir globālo spēlētāji, kādas ir cenas....

Lielais kļūdu skaits arī nozīmē, ka cilvēki to figņu lieto. Bieži vien, arī kļūdas dublējās, un beigās daudzas nemaz nav kļūdas. Es labāk lietoju projektu ar daudz kļūdām, bet lielu community, nevis 0 kļūdas un sauja cilvēku..

Taisam uz drupal, dzirdēju, ka baigi labais ir

Es īsti nesaprotu, kāds labums uzņēmumam no šī. Vai arī tu to dari tikai ārpus darba laika? Kamēr mācīes, attiecīgi, izstrādes temps diezgan palēlināts + sarežģītāk atrast aizstājēju. No firmas viedokļa liktos, ka mērķis ir izmantot pārbaudītus rīkus, ar kuru palīdzību var maksimāli ātri piegādāt strādājošu produktu. Vai arī jums tur ir tā, ka vienkārši nav ko darīt, nav termiņu, un tad var eksperimentēt ar visādām eksotiskām tehnoloģijām?

Tas tā gan jau speciāli, izvēlās kaut kādu exotiku, un pēc tam panāk to, ka ir neaizstājams, jo neatradīsi uz sitiena tādu, kas to visu varēs uzturēt :D

unittestus neraksta testētājs. Tos raksta tas, kurš ir rakstījos testējamo kodu, jo tikai vinš zina, kā iekšēji tas strādā. Kaut kādus funckionālos/integrācijas/acceptance testus gan var rakstīt testētājs, jo viņam pietiktu ar to, ka zina ārējos interfeisus. White box / black box testēšana.

Vienkāršāks, elegantāks, vairāk syntax sugar? Tāpat laravel pamatā ir syphony komponentes un izstrāde ir vienkārši fun,

Tā kā lietoju laravel, tad vienmēr sāku ar tabulas modelešanu. Modelēšana tiek veikta izmantojot migrācijas, kas atrodas versiju kontrolē. Migrācija izskatās ~ šāda: Ir UP un DOWN metodes, kas izipldās veicot migrāciju/rollback. Teiksim, ja kādam vajag replicēt lapu savā vidē, viņš noklonē repozitoriju un vienkārši palaiž visas migrācijas - tiek uzbūvēta db. Pēc tabulas izveides, tiek izveidots attiecīgais modelis (ORM). To var darīt ar roku, var arī izmantot ģenerētāju, kas pēc tabulas uzbūvē klasi. ORM/Modelis izskatās tāds: Pēc tam tiek veidots interfeiss, kas satur metodes, kas nodrošinās apiešanos ar šo modeli, labošanas, dzēšanas. Tālāk izveidoju repozitoriju, kas manto šo interfeisu. Kontrolieri sazinās tikai caur repozitoriju (kontrolieris nemaz neredz repozitoriju, viņš zina tika interfeisu), tādējādi kontrolieris nav coupled ar datubāzi. Šis, tā saucamais, repozitoriju patterns ļauj arī vieglāk testēt - mēs vienkārši mock'ojam šos repozitoriju interfeisus, un varam unittestos (un ne tikai) testēt visu nemaz neaiztiekot datubāzi.

vbz, iedzer baldriāni un bik atslābsti. Ķeršanās pie personiskiem apvainojumiem ne par ko labu neliecina!

Bļin, vbz, tu tak vari labot savu iepriekšējo ievadu, nav jāveido jauni ieraksti katram teikumam :S

ieleja, nu kamon, kam patīk skatīties uz tām sūda ūdenszīmēm? Nu nedara neviens vairs tā.. Flicrk, facebook, draugiem, utt utt, neviens neliek tās sūda ūdenszīmes. Ja kāds negrib, lai viņa bildi zog, tad, lai pats arī liek to ūdenszīmi.

Vienīgais, kā pasargāt un sabojāt prieku useriem - uzlikt ūdenszīmi. Savādāk, viss, ko redz lietotājs, ir saglabājams. Kaut vai ar print screen.

Float glabājas decimal kolonnā. Protams, varētu glabāt veselu skaitli, un dalīt php pusē, bet baigo ieguvumu es neredzu (naudu es tāpat glabāju veselos centos, bet ja vajag glabāt arī pus centu?) Testi ir pagari, jo viens tāds tests ietver veselu scenāriji no sākuma līdz galam. Pieļauju, ka, ja rakstītu true unittestus, tad tie būtu tiešām stipri īsāki. Līdz tam vēl ceru nonākt. Kad rakstu testus? Kad rakstu kaut kādu libu, parasti uzrakstu vispirms basic funkcionalitāti, un, kad jau teorētiski varētu sākt būvēt UI, testēt caur to, sāku rakstīt testu scenārijus. Jo uzrakstīt vienu testu ar konkrētu scenāriju, un pēc tam labot loģiku ir daudz patīkamāk, nekā to pašu scenāriju realizēt spaidot UI, kas ir vienkārši garlaicīgs un repetatīvs uzdevums. Šeit vēl viens tests sociālo tīklu pasēm: http://pastebin.com/SSNe318Z Tiek pārbaudīti dažādi scenāriji, brīdī, kad lietotājs ir/nav ielogojies ar savu pamatkontu, tad mēgīna pieslēgties ar soc kontu: Sākumā uzrakstīju scenārijus uz lapiņas, un mēģināju arī uzrakstīt testus. 1. Ja useris ielogojies 1.1. Soc konts nav iepriekš reģistrēts - piesaistam userim soc kontu 1.2. Soc konts ir reģistrēts sistēmā - kļūda 2. Nav ielogojies 2.1. Soc konts nav iepriekš reģistrēts - izveidojam jaunu useri, savienojam, ielogojam 2.2. Soc konts ir reģistrēts - ielogojam lietotāju Šos visus, principā pat vienkāršos, scenārijus mēģināt ar roku, vairākkārt, un katru reiz kā tiek veikts kāds labojums? Ehhh

Aicinu par testēšanu turpināt bazaru manis uzsāktajā tēmā: http://php.lv/f/topic/21971-test%C4%93%C5%A1ana/

Varu padalīties nelielā pieredzē. Vide - phpstorm, git, laravel, pie projekta strādāju viens. Projekts: http://pointsback.lv Projekta neliels aprakts: ir divi useru tipi - pircēji, pārdevēji. Pircējs iepērkas pie pārdevējiem, saņem par to punktus no pārdevēja konta savā. Pircējs var arī tērēt savus punktus. Pamatā vienkāršas punktu transakcijas, viss notiek caur API. Testos esmu galīgs iesācējs, unittestus vēl īsti nemāku rakstīt (kods pārāk līks, lai normāli testētu), bet mēģinu vismaz integrācijas testus rakstīt. Ja kāds nezina, tad integrācijas tests ir, kad testē jau kaut kādas sistēmas daļas kopumā, vai tās funkcionē pareizi, vai tās strādā korekti. Unittesta gadījumā tiek testēta kaut kāda maza vienība, pilnībā izolējot to no ārējiem apstākļiem (datubāzes, modeļiem, api, utt utt). Es parasti uzrakstu kaut kādu funckionalitāti un uzreiz mēģinu uzrakstīt arī pāris testus. Testa gaita ir apmēram šāda - palaižot testu, man katru reizi tiek uzbūvēta jauna datubāze, visas tabulas, tiek ievietoti kaut kādi pamata dati (useru grupas, permisiju tipi, whatever). Tad es uzkodēju kaut kādus scenārijus. Piemēram, 1. Ieskaitam veikala kontā 100 punktus 2. Piereģistrējam lietotāju 3. Pārskaitam no veikala konta 60 punktus 4. Pārbaudam vai lietotājam kontā ir 60 punkti 5. Pārbaudam vai veikalam kontā atlikuši 40 punkti Tādā garā ir arī visi testi. Testi mani izglābuši vairākkārt. Viens spilgs gadījums atmiņā - vajag ieviest nosacījumu, ka pārskaitot no veikala pircējam punktus, tiek ieturēta komisija. Ok, domu gaita sekojoša - papildus kolonna veikalu tabulai ar komisijas %. Attiecīgi, rodas nosacījums, ka tagad veikala konta atlikums ir jāglabā kā decimāla daļa, jo, 50% no 1 punkta ir 0.5 punkti, attiecīgi, pārskaitot no veikala pircējam punktus, veikalam paliek par 1.5 punktiem mazzāk. Turpmākās darbības galvā vienkāršas - pieliekam komisijas kolonnu, pielabojam funkciju kas pārskaita punktus (pieskaita/atņem no veikala konta), lai tiktu atrēķināta komisija. Viss it kā vienkārši, kļūdām nevajadzētu būt - laižu testus, un - kļūda! Nesakrīt summas. Rokos dziļāk, un atrodu vienā metodē, ka palicis - $shop->points = (int)$points; Ahā, notiek decimāldaļas atmešana! Pielabojam uz (float), viss rullē! Šādu kļūdu, es visdrīzāk nebūtu atradis ar roku, ja vien neuztrāpītu uz konkrētā robežgadījuma. Paietu labs laiks, kamēr saprastu, kas noticis un, kur nu vēl savest visu kārtībā - izsekot, kuram veikalam cik tagad ir pazudis, cik jāpieskaita klāt. Karoč, produkcijā viss slikti. Līdzīgi testēju arī API izsaukumus - veicu izsaukumus kontrolierim, padodu derīgus/nederīgus datus, pārbaudu rezultātu, utt utt. API tomēr ir tāda lieta, kas nedrīkst vispār mainīties (vismaz tā pēkšņi), ja to jau produkcijā lieto N cilvēki. Viena kļūda var maksāt dārgi, kaut vai programmētāja laika resursā. Piemēram, vajag API notestēt, vai strādā autorizācija: Šeit apskatāms viss test case priekš API: http://pastebin.com/b6X77uaZ Šādi ~ izskatās punktu došanas tests: Mans secinājums pēc šī projekta noteikti ir tāds, ka vismaz kaut kādus testus vajag rakstīt. Nevar salīdzināt, kā ir refactorēt ar testiem, un bez testiem. Tas ir tā, kā pieregulēt lidmašīnai aerodinamiku, un mēģināt lidot (produkcijā), nemaz nepamēģinot kā viņa uzvedas gaisa tunelī. Tiem, kas vēl neraksta testus - noteikti pamēģiniet. Vismaz uzsākot kādu jaunu projektu, jo no 0 vienmēr ir vieglāk + ar katru nākamo projektu, spējas noteikti uzlabosies. Vēlams izmantot kādu frameworku, piemēram, laravel, kas daudzkārtīgi atvieglo visu šo procesu. Testēšana ir ļoti overwhelming, kad paklausās, ko runā - unittesti, intergrācijas testi, end to end testing, model testing, functional testing, mocking, un vēl bonusā, viena komūna uzskata integrācijas testus par unittestiem, cita otrādāk. Nemaz nesākšu runāt par interfeisa testiem, selenium... To visu paklausoties rokas nolaižas, bez šaubām. Bet, kamēr nespersi pirmo soli, neuzrakstīsi savu pirmo, nepareizo testu, nekādu izgausmi negūsi... Tā kā novēlu - nevajag baidīties, vajag tikai pamēģināt. Oj, eseja sanāca :D

"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)

$("#xxx").val($("#xxx").val().replace(/,/g, '.')) Par chainošanu neesi dzirdējis? + tas, ka kods ir vienā rindā, praktiski nekad nenozīmē, ka viņš ir labāks, vieglāk lasāms.