Mr.Key

Interesants The Guardian raksts: The secret life of a games programmer: I’ve lived my dream and it came up short. Pati rubrika The Secret Life, kuras rakstu sērijā ir šis raksts, arī interesanta.

Ja jau neuzticies tam, ka pietiek ar "if ($obj)", tad kāpēc uzticies, ka $obj būs vajadzīgā tipa?

Control structure keywords MUST have one space after them; method and function calls MUST NOT. Bet ok, sapratu, ka forumā raksti bez atstarpes, kodā to atstarpi ieliek autoformatētājs.

Skaidrs, piekrītu. Man gan liekas, ka stilistiski labāk ir likt atstarpi pirms iekavas, kas seko valodas konstrukcijai. Vieglāk acīm, kad jāatšķir no funkcijām.

Man visa tā lapa izskatās gļukaina un nepabeigta. Bet nu tas normāli. Es arī, ja klients neuzskata par vajadzīgu iespringt niansēs, tad neiespringstu. Jo nostrādāt nianses aizņem reizēm pat vairāk kā 50% laika. Piemēram, smalks pulkstenis vai rotaslieta ir 80, varbūt pat 99% tas, cik pārdomātas un noslīpētas ir detaļas, nevis tas, kādu laiku tas rāda vai kurā pirkstā var uzvilkt.

Varētu par šo sīkāk? Kāds ir tas gadījums, kad DB row objekts var tikt castots uz boolean false, ja eksistē tas ieraksts?

Reizēm vajag nevis pamanīt, bet padomāt.

No hacker news. Par to, ka on-site darbs ir labi un veselīgi prātam, ķermenim un makam. Sēdēšana mājās, protams, ir pretējais. Why Continuing to Work Is Good for a Man’s Health https://features.wearemel.com/ill-retire-when-i-m-dead-why-continuing-to-work-is-good-for-a-man-s-health-c3053052d136#.78sbrbr2t (bet tas laikam attiecas uz sakarīgu darbu) (ar sēdēšanu mājās es saprotu arī frīlansošanu no dīvāna)

if ($foo->hasSomething('boo')) { $value = $foo->getSomething('boo'[, $default]); }

Tas jau vairāk tāds filozofisks skatījums. Bija laiki, kad cilvēki diskutēja, filozofēja.

Moška čalim bija sakars ar kādu latviešu daiļavu, uzprasīja, kā saule ir latviski, utt.

Loģiskāk tā būtu, un skaistāk. Bet dzīvē kaut kā ar to ir smagi. To risina API. Arī ja viss tiek būvēts, piemēram, PHP valodā un tā ir viena sistēma, praksē vieglāk ir viņas sajūgt kopā ar API, nevis izmantojot vienu valodu un sajūdzot kopā koda līmenī. Tad vēl, viena subsistēma noprogresē uz nākamo PHP (vai citas valodas) versiju, pārējās iepaliek. utt. Ja projektā vairāki cilvēki un ir normāls budžets, kas ļauj normāli padomāt par šīm lietām, devi var izlemt, kurš ko taisīs un kā tas ies kopā, un tad katrs būvēt savu mazo pili.

Migrēšu: 1) Uzliku Zend Studio triāli (pēc tam perpetual maksa ir 89 usd = 70 EUR). Redzēs. Iepriekšējā pieredze bija laba, ceru, ka šie būs atguvušies un iespaidi būs pozitīvi. 2) Jā, domāju Laravel -> ZF2. Vai Slim. Varbūt pat ZF1 (kantainais Volvo).

Mēģinu jau ilgāku laiku. Izsakos cik protu, diplomātiski un labi saprotu, ka phpStormā ir daudz labu iespēju, kuras arī pašam patīk, bet nu šajā interfeisa sadaļā vīlos. Kāpēc tas quick doc un quick preview ir svarīgi? Paskaidrošu, kāpēc. Pirmkārt, es neesmu plain text editor fans - uzskatu par pilnīgi normālu lieto IDE, manuāli un code completion. Tāda "tikai vim / notepad" lietošana ir raksturīga iesācējiem, kas vēl nav saskārušies ar situāciju, ka tas, ko viņi iemācījās no galvas, nevienam nav vajadzīgs jau trešo reizi. Varbūt tas ir savādāk lielajos uzņēmumos, kur pietiek, ja no visas IT sistēmas var pārzināt <10% un kadrs ir "jquery guru" vai "oracle 9i spatial index guru", kuru projvads pasauc pie galda tad, kad vajag konkrēto lietu un aizdzen prom, kad vairs nevajag un tad viņš veģetē nedēļu pie kompja, gaidot nākamo vajadzību. Tātad, taisot 100% risinājumu, ir jātver plaši. Tāds "Es tagad iešu kursos mācīties Laravel" vai lasīt grāmatu jau vairs īsti neder, kad MVC ir izkosts līdz apnikumam. Tātad, tas ko es gribu sagaidīt, ir tas, ka ja nozarē valda viedoklis, ka Laravel ir labs, es sagaidu, ka tas tiešām ir labs. Tāpat kā tad, kad cilvēks ar auto uzbrauc uz šosejas, uz kuras rakstīts Rīga 100 km, viņš sagaida, ka tā būs šoseja uz Rīgu, ka tā būs pārsvarā taisna un ka pārsvarā ātrums būs 90 km/h. Labi, šajā ziņā Laravel ir daudz maz ok, vienīgi izskatās, ka te braukšana notiek pa kreiso pusi, kā Anglijā. Turklāt, tā ir privāta šoseja. Nākošais, ko es sagaidu, ir tas, ka IDE ļauj ražot kodu, un ļauj darīt to pārliecinoši. Tā darbojas gan Visual Studio, gan Eclipse, vēl citi, par ko varbūt neatceros. Eclipses un normāla FW gadījumā es, uzrakstot to Request (vai jebkuru citu klasi), uzreiz varu iepazīties ar to, ko tā dara. Eclipsē jau by default failu kokā uzreiz var izvērst klases un redzēt metodes un atribūtus. Tātad, es uzrakstu Request:: un pēc dažām minūtēm es zinu, ko es varu izdarīt un ko es nevaru izdarīt. Tāpat, atgriežoties pie nedēļu veca koda, es ar peles bīdīšanu vien varu saprast, kas ir zem izsauktajām metodēm gan dokumentācijas veidā, gan koda veidā. phpStorm izskatās, 1) daudz visādu fīču, bet arī tik pat daudz gļuku (piemēram, indentācija reizēm strādā, reizēm nestrādā un tas nav prognozējami) 2) ātrums tiek iegūts uz visādu defaultu izslēgšanu 3) diezgan agresīvs mārketings, sevišķi triks ar darcula tēmu, kura praksē ātri tiek novākta, jo cilvēki tomēr raksta ar melnu tinti uz balta papīra, bet krāsaini burtiņi uz melnas tāfeles parasti ir ēdienkarte hipsterīgās kafejnīcās. 4) Evil is in the details. Kopumā, kādēļ vajadzīgs tas, kas patīk Eclipsē, bet kā nav phpStormā(vai ir ne tik ērts)? Ātrums un precizitāte​. Piemēram, arī šo es rakstu no ergonomiskās klaviatūras. Man patīk strādāt maz. Personīgi man tā jūtamā atšķirība no šī mēģinājuma ir tāda, vai es par projektā nopelnīto naudu izdalu ar 1 mēnesi, 2 mēnešiem vai 3 mēnešiem. Ceru, ka ar šo arī noslēgšu šo tēmu. Pamēģināju, nepatīk, vienu no svētku dienām ziedošu migrēšanai. P.S. Vai no šī jāiespaidojas kādam? Absolūti nē. Tas ir tikai mans viedoklis.

Nu super. Ja vēl tajā lodziņā varētu redzēt koda preview, būtu pavisam ideāli.

Šis: Un šis - kur dabūt metodes izklāstu pirms izvēles akceptēšanas? Nebūtu jāizlaiž vakars dabā, ja lietotu šo: Un phpStormam ir jātur Ctrl pirms hoover. Eclipsē pietiek uzbraukt uz iekaviņas. Bye phpStorm. The best things in life are free.

Problēma nav risinājumā. Nospļaudījos par to, ka gribēju kā labāk, bet nācās pazaudēt laiku, lai atklātu, ka stilistiski pareiza pieeja nav izmantojama. Jo tā metode neintuitīvi apstrādā datus, nevis tikai padod. To varētu norakstīt uz phpStorm, kurš koda veidošanas brīdī nav tik ērts, kā Eclipse, kurš uzreiz piedāvā dokumentāciju un ar hoover (nekur dziļāk nestaigājot) parāda metodes source code tooltip izskatā. Vai kaut kas cits... Katrā ziņā, esmu piedzīvojis labāku kombināciju par Laravel un phpStorm, un viss strādāja diezgan labi. Piemēram, tādā gadījumā būtu bijis tā, ka jau uzsitot Request::get.. es redzētu, ka getQueryString docblock ir pateikts, ka parametri tiek pārkārtoti. Ir cilvēki, kas dalās ar sajūsmu, es dalos ar kritiku.

Nu cik reizes var skaidrot - nav nekas nepieciešams. Elementu kārtas numurs to organizētajā secībā ir pilnīgi pietiekami. Izmainot elementu kārtību visos iespējamos veidos, to kārtas numurs jaunajā secībā vienmēr būs kārtas numurs jaunajā secībā. Piemēram, rindā piektais cilvēks vienmēr būs piektais un pie kases produktus pircēji atdala kociņu pa vidu tiem, nevis numurē katru savu produktu.

Jurchiks, tehniski tas man ir skaidrs un saprotams, taču es neredzu, kāpēc struktūra, kurā elementi tiek organizēti secībā un katra elementa kārtas numurs skaitot atbilst, khmm, viņa kārtas numuram, ir jāpapildina ar kārtas numuru. Turklāt, ņem vērā, ka tos datus var bīdīt visādi un pirms datu nosūtīšanas secība var neatbilst tam i, kas tapa klonēšanas brīdī. F3llony, man patīk un sanāk strādāt tā, ka ir klients, ar kuru strādāju pa tiešo bez tīmlīdiem, produkta owneriem un citiem kukaiņiem, un kuram vajag palīdzēt atrisināt viņa biznesa vajadzības. Tas nozīmē izveidot IT risinājumu no 0, tas IT risinājums kļūst par viņa ikdienas darba sastāvdaļu. Risinājumu izstrādāju vadoties pēc tā, lai tas strādā, strādā korekti, reizēm pat strādā 10+ gadus. Darba rezultāts ir nevis tas, cik es sarežģīti izveidoju un cik daudz salieku visu ko lieku, kas citur pēc tam izpaužas kā double qoutes, unescape_escaped_string, vai lietām, kuras vienkārši nestrādā, bet tas, cik racionāli un sabalansēti es māku salikt kopā vajadzīgās tehnoloģijas. Parasti mazāk ir labāk. Es nestrādāju lielā uzņēmumā un nevaru atļauties filozofēt par to, kā būtu pareizi - vajag, daru, risinu. Bet ja ir padoms par templeitu sistēmu web appam, kas darbojas browserī uz planšetēm un kur jau pamatā doma ir datu apmaiņu laist caur AJAX/JSON, tiešām interesētu, kurš būtu labāks (angular, ember, react? skatos uz ember. gribu webisku appu, kas sesijas sākumā saņem datus, sesijas beigās nosūta gatavus pasūtījumus, pa vidu formās notiek pasūtījumu veidošana).

Par lieko parsēšanu (URL filtra gadījumā, kur selectā izvēlas vienību un multiselektā - 0, 1, ... N apakšvienības, un šo pāru skaits ir 0, 1, ... N atkarībā no lietotāja): $data = []; $i = 0; $breaks = array_keys($_GET['subitems'], '|'); foreach ($_GET['item'] as $item) { $data[] = [ 'item' => $item, 'subitems' => array_slice($_GET['subitems'], $i > 0 ? $breaks[$i - 1] : 0, $breaks[$i]) ]; $i++; } Labprāt redzēto to JS kodu, kas izseko līdzi un menedžē to i. Vai jebkādā citādā variantā.

Nav nekādas vainas JavaScriptam, viss patīk.

Viņš to varētu arī nedarīt un būtu ļoti labi. Velk uz tādu kā wordpresu, kur paši ziniet, kas notiek ar datiem.

Skaidrs, domāju, ka tie ir divi atšķirīgi principi ar saviem +/- un atkarīgs no situācijas. Taču ceru, ka izskaidroju, kādēļ tā secība ir svarīga. Jurchiks, tas parsings ir tikai pie datu saņemšanas, kad parsings šā vai tā ir nepieciešams. Turklāt, ja dati ir secīgi, tad indekss jau ir - tas ir datu elementa kārtas numurs. Neko papildus tur vairs nevajag. Tas ir tāds pats i, kā tad, ja to būvētu ar skriptu. Nav skaidrs, kādēļ Laravel un Illuminate uzbāžas ar savu iejaukšanos. /** * Normalizes a query string. * * It builds a normalized query string, where keys/value pairs are alphabetized, * have consistent escaping and unneeded delimiters are removed. * * @param string $qs Query string * * @return string A normalized query string for the Request */ public static function normalizeQueryString($qs) {} Nu malacītis, paldies! P.S. Lieki piebilst, ka ar riteni neizbraucu, jo nācās guuglēt teju vai katru soli un līst metožu definīcijās, lai saprastu, vai tur ārā nāks kolekcija, masīvs, vai būs associatīva vai objektu fetchošana, utt. Tā tā popularitāte googlē rodas...

Tas nozīmē, ja jāģenerē abās pusēs, pirmo reizi - izvadot formu, otro reizi - ar JS reaģējot uz lietotāja veiktajām izmaiņām. Manā gadījumā viss notiek bez , un jquery metodes būtība sastāv vienrindēm "$(this).closest('tr').before(clone.clone());", "$(this).closest('tr').remove();", un eventi, protams, tiek definēti ar delegate principu, kas nozīmē, ka visas podziņas strādās, izpildoties iepriekšrakstītajai clone().

Varbūt ne visu saprotu, bet kā HTMLā tiek menedžēts tas ? Vienkāršāk sakot, ja tev ir lauku grupas, kuras veido viens select un viens multiselect, kā tu iesūtītu datus? Kādi lauku nosaukumi? Ko PHP dara? 1) [select] [multiselect] ... N) [select] [multiselect]