Jump to content
php.lv forumi

Mr.Key

Reģistrētie lietotāji
  • Posts

    1,332
  • Joined

  • Last visited

Everything posted by Mr.Key

  1. Kā dabūt to [1] un [2]? Ar javascript baigi čakarīgi, ne? Ieskatam (šis iet kā POST, nevis caur URL GET, bet vairāk doma ir par nenoteikta izmēra divdimensiju masīviem): Lapā ir viena vai vairākas šādas tabulas. Katru tabulu var pievienot vai noņemt. Tabulas pievienošana notiek ar jQuery clone noklonējot tabulu, atstājot tikai 1x1 šūnu un notīrot vērtības. Katru tabulu var pabīdīt uz augšu/leju. Katrai tabulai ir papildus dati (selekti, kuros norāda, kas tur ir tajā tabulā, komercijas gadījumā tās protams ir kaut kādas preces). Katrā tabulā var pievienot jaunas tukšas vai dzēst rindas, kolonnas. Tas notiek ar jquery clone() vai remove() un nometot vērtības. Katru rindu, kolonnu var bīdīt pa labi/kreisi, uz augšu/leju, saglabājot saturu. Tabulas rindu priekšā ir tekstiņš un lauki, kolonnu augšā ir selekti. Respektīvi, ir elementi pa Xn, Ym un elementi XnYm, kur n un m mainās. Tabulas cell ir magic fīčas, kuras šeit nav redzamas, bet kur nospiežot podziņu, šūnas izskats mainās vai arī parādās dažādi papildus elementi (tiek saģenerēti ar jquery, tad hide/show vai kaut kas tamlīdzīgs, jau vairs neatceros). Kad šī magic fīča tiek ieslēgta, protams, saglabājas iespēja visu bīdīt, pievienot vai noņemt. Lietotājs darbojas pa šīm tabuliņām, savada visu vajadzīgo, tad kaut kādā brīdī to visu saglabā. Saglabājoties, protams, dati tiek saglabāti atbilstošā secībā, tā, kā tas redzams uz ekrāna. Ar JavaScript baigais čakars tur sanāktu uzturēt indeksus. Ar iepriekš minēto principu es vienkārši detektēju, kurā brīdī ienākošajos datos mainās šūnai XY mainās X vai XY, vai ir sākusies jauna tabula. PHP neatbalsta elementus 'name[][]', jo ienākošie dati vienkārši ir html elementu secībā. Daudz kas notiek ar jQuery selektoriem $('input[name="element[]"]'), neizmantojot idus vai klases. Tad nu no tādas 1x1 tabuliņas lietotājs var saspaidīt kaut vai 100 tabulas, katru ar cik vajag šūnām. funkcionalitāti nodrošina dažpadsmit jQuery eventi. Kad viss tiek submitots, dati ienāk vienkārši attiecīgā secībā un HTTP POST gadījumā vienkārši tiek padoti breaki, kas PHP pusē strādā tā, ka cikliņš saprot, kurā brīdī mainās x, y.
  2. rindas, kurās selekti + multiselekti, kas visi tiek dinamiski pievienoti vai noņemti (lietotājs var pievienot filtra nosacījumus ar jquery clone/remove). Piemēram, ja ir selekts type un tam piesaistīts multiselekts subtypes: ?type[]=1&subtype[]=A&subtype[]=B&subtype[]=|&type[]=2&subtype[]=A&subtype[]=C&subtype[]=Z&subtype[]=|&... Ar šo secību izeju cauri un pie katra subtype[] == "|" (hidden elements aiz katra multiselekta) zinu, ka multiselekta elements beidzas un ka nākošie subtype[] ir jau nākošais multiselekta elements. Tas ļauj iztikt bez JavaScript iesaistes elementu nosaukumu veidošanā.
  3. Vajag: URL fitlrs, kur parametru secībai jābūt tieši tādai pašai, kā pieprasījumā, bet to vajag izmantot Paginātorā. Šeit ir tas, kā es to atrisināju ar Laravel: <div class="text-center"> @if ($items) @if ($filter) {!! str_replace('?page=', '?' . $_SERVER['QUERY_STRING'] . '&page=', $items->links()) !!} @else {!! $items->links() !!} @endif @endif </div> Iespējams, to varēja arī gudrāk, bet nāk vakars un es gribu izbraukt ar riteni, kamēr vēl gaišs.
  4. To jau tā nevar zināt. Ja iedziļinās tajā, ko dara šobrīd, nav laika grozīt galvu apkārt un vērot, kas notiek.
  5. Ja ir konkrēts piedāvājums, tad jau uzraksta kaut kādu tekstu, nevis vienkārši konektē. Bez konkrētas norādes ir priekš tā, lai tu redzētu taimlainā ierakstus. Vai redzētu tavus, ja nu izdomā uzrakstīt, ka "I am open to new opportunities!" Bet nu jā, tiešām jocīgi - būt vietā, kas paredzēta networkošanai, bet darīt tieši pretējo.
  6. Respektīvi, automatizēti [dažu] cilvēku subjektīvi emocionālie lēmumi. :) Bet, codez, tava ticība automatizācijai ir mazliet nepareizi ievirzīta. Tas, ko tu sagaidi rezultātā, nav tas, kas rezultātā būs. Respektīvi, tu sagaidi, ka automatizācija izskaudīs subjektīvi emocionālus lēmumus, bet es uzdrīkstēšos apgalvot, ka būs tieši pretēji - tas tikai veicinās tos. Piemēram, ja tu būtu izgudrojis internetu, tu diez vai būtu paredzējis, ka tas būs labs porno tunelis un iespēja nosist laiku sociālajos tīklos, un atvērt interneta kazīno filiāles austrumeiropā, kur lēti un bezprincipiāli koderi kodē azartspēļu sistēmas un ir priecīgi par to.
  7. Viņš, starp citu, kaut ko tamlīdzīgu ir piedzīvojis, jo nāk no Austrumeiropas. Vismaz mentāli labi apzinās tevis minēto piemēru. http://mavericktraveler.com/13-things-dont-tell-eastern-europe/ http://mavericktraveler.com/fell-love-eastern-europe-bought-one-way-ticket-indonesia-thailand/ Un arī par to, kāpēc un cik nožēlojami ir būt strādniekam (labi saprotot, ka daudziem izvēles/enerģijas īsti jau nav). Konkrēti tavs piemērs ir cilvēciņi, kas ir lētāki par automatizētu līniju, kā tas ir normāli civilizētā pasaulē. Kādu dienu uzņēmums iepirks iekārtas un atlaidīs maisu nesējus, viņu vietā pieņems citus, jo nebūs tik forši - iekārta jauna, bet darbinieki vecie. Foršāk ir jauna iekārta + jauni darbinieki.
  8. Tad es saprotu, ka forumā vairs nebūsi, codez? Jo šeit tā kā cilvēki runā (ja nu gadījumā tev likās, ka mēs esam mākslīgie intelekti)...
  9. http://mavericktraveler.com/why-i-left-my-programming-career-and-havent-looked-back/
  10. Tas bija mans viedoklis par Laravel. Atvainojiet...
  11. Nu bet varbūt laba iespēja priekš tiem, kam patīk Laravel.
  12. Precizēšu. Es neesmu pret testiem, bet ir vairākas lietas: - mikroprojektu budžets (tēlaini sakot, tu nevari nopirkt mersi pa dažiem k, bet ir, kam vajag "ejošā stāvoklī") - labāk testu nav vispār, nekā ir pseido-testi (viltus drošības sajūta) - TDD ir tikai viens no vairākiem "approach" - un vēl virkne lietu. Es katrā ziņā iesaku pieturēties pie testiem, kad tas ir uzskatāms par pareizu. "Galvenais, ka strādā" - ar to domāju nevis tjap, ljap, bet... nu, piemēram, šis: Domāju, ka galvenais bija noņemt ērci.
  13. Nav. Bet man liekas, ka tev labāk meklēt gala klientu, jo tu orientējies uz rezultātu, nevis procesu. Gala klientam vajag risinājumu, kas strādā, nevis lai tu ej katru dienu uz biroju, vai raksti līdam testus. Tas ir priekš tiem, kuri grib feisītī likt bildītes ar torti "10 gadu jubileja darbā" un "priekšnieks šodien bija labs, esmu laimīgs"...
  14. Varbūt pamēģini pa taisno dabūt klientu - kādu uzņēmumu, kuram kaut ko vajag. Tā, protams, random doma, nezinu, cik praksē tas reāli. (Reāli tas noteikti ir.)
  15. Baisi mazas naudas, 1k var nopelnīt daudz, daudz vienkāršāk - vienkārši piesakoties jebkurā darbā IT uzņēmumā, kurš visu uzliks uz paplātes un kuram nebūs stulbu jautājumu. Kurš par iebraukšanu projektos jau maksās algu un, ja tas ir starptautisks uzņēmums, nosūtīs pilnībā apmaksātā komandējumā (tiem, kuriem patīk ceļot, šis ir labs bonuss).
  16. Jāņem vērā, ka tas ir betu pasākums. Tur betas apkalpo alfas. Varbūt uzmetīs, varbūt neuzmetīs, varbūt kko atmetīs.
  17. Labs topiks vispār. Arī man bija radies iespaids, ka freelance portālos jākonkurē ar aktīvistiem, kas visu izdara jau vakar un vēl piemaksā par to. Šeit daži komentāri izskatās labi.
  18. Es to teicu par pasīvajiem. 500 eur pasīvie ienākumi ļauj urbināt degunu un domāt tālāk par nākamajiem 500. Vai 1000. Vai 5000. Un kad ir tie, tad atkal tālāk. Tāds eksponenciāls progress. Alga vienmēr būs alga, un pēc 2.5k saņemšanas tu tos varēsi tikai tērēt - paņemt labu kredītu un cerēt, ka pēc 10 gadiem nebūs tā, ka tev kredīts ir, bet alga vairs nav. :) Mani gan tas nesatrauktu, bet ja darbā 8h normāli jāstrādā, tad neatliek laika domāšanai par kaut ko citu. Vai arī tad ir jāupurē atpūta, brīvais laiks. Bet nu tā tāda sapņošana, protams.
  19. Katram savs. Man pietiktu ar 500 eur mēnesī passive income un dzīvotu kā paradīzē. Londona noteikti nav paradīze. Šobrīd nav passive inkome, tā vietā ir šādi tādi darbiņi. Esmu par slinku, lai domātu savu. Kā tajā anekdotē - vīrs pelna lielo naudu, lai aizbrauktu uz eksotisku salu baudīt to, ko vietējais bezdarbnieks izbauda katru dienu.
  20. DRY ir kodā, datubāzes struktūrā ir normalizācija.
  21. Apmēram kā jurchiks. Problēma ar custom produktu veidiem ir tipiska un jau kopš ekomercijas sākuma, kopš pirmajiem ERP. Diez vai tur kaut ko jaunu vajag izdomāt. Pameklē sources no Magento. Es pats šādu risinājumu veiksmīgi saveidoju pirms gadiem 10+, bija gan produktu veidi, gan katram veidam savi atribūti un katram atribūtam gan custom parametri, gan predefined sets, utml., respektīvi daudz iespēju un viss tas, kas te cilvēkam bija vajadzīgs viņa shop projektam. Arī toreiz paskatījos idejas citos tā brīža projektos. Ar pilnu pārliecību varu teikt, ka tā ir problēma, kurai vienkārši pietiek atrast vienu best practice un implementēt. Pēc tam ātrdarbību var risināt ar ģenerēšanu, indeksiem un vēl visādi. Mysql un relāciju shēmas gadījumā vispār ir jāņem vērā, ka pievienot vienu kolonnu tabulai ar 100k ierakstiem būs daudz sāpīgāk, nekā pievienot 100k ierakstus pārdomātā struktūrā. Ieteikums liekot mongodb, jo nav saprašanas pa relāciju db priekšrocībām ir vispār diezgan funny. Programmēt, neizprotot vispārīgus datubāžu konceptus (vnalga, vai mysql, pgsql vai random sql) - arī funny pieeja darbam. Atrada "x ms" neko neizsaka. daudz ko nosaka cache siltums, utt., baigi daudz visa kā.
  22. Tīri vispārīgi, ne par šo gadījumu (jo šeit mērķis ir pašam savu konsoli uztaisīt) - ja tā ir viena komanda un pēc tās izpildes gatavs konsoles supports, why not? Šodien taču neviens neskaita diska vietu un tā tālāk. Bet vēlreiz - protams, ja mērķis ir uztaisīt pašam savu, tad jā. Man, piemēram, tāda mērķa nav un es nedomājot ielikšu gatavu konsoli un, visai ticams, nekad neskatīšos tajās 10k rindās, jo risināšu citus uzdevumus. Kāpēc to gribu teikt. Vēlreiz un vēlreiz - apkārt viss mainās, un jāiet līdzi. Man pašam nepatīk (vai nepatika) tas composer, jo ir WTF, es varu taču uztaisīt download, unzip un iekopēt vajadzīgajā direktorijā, bez visādiem tur lock failiem, dependensijiem, utt. Pieņemsim, ka šis izdodas sekmīgi, tāpēc sāku ignorēt arī citus pavērsienus un, skat – esmu jau īpatnis ar irrelevantām zināšanām, kura projekti virzās tik lēni, ka nevienu tas neinteresē.
  23. Manuprāt, call_user_func() FTW. Un listMethods() vietā vajadzētu reflection, kurš atfiltrē metodes, kuras sākas ar handler (handlerFoo(), handlerBoo()).
  24. Jā es arī. Bet varbūt reizēm der pacelt galvu un pagrozīt kaklu, lai paskatītos, kas notiek apkārt? Starp citu, arī tu esi indigo priekš tiem, kas paši lodēja savus datorus un studēja procesoru komandas. :)
×
×
  • Create New...