Mr.Key

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.

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ā.

Ko? 

I have no life.

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.

 

https://www.theprintful.com/how-printful-works

 

Man liekas diezgan pašrotami, ka viņi saviem drukas produktiem palīdz ar tehnisko nodrošinājumu (produkta integrēšana internetveikalā) klientiem. 

 

Beidz būt muļķis

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.

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.

Kas par muļķīgiem pieņēmumiem? Tak cilvēks ir paņēmis vienu tēzi un mēģina uz tās uzbūvēt savu mārketinga kampaņu nekam nevajadzīgu padomu tirgošanā.

Pie tam viņa tēze nav patiesa un kļūst arvien nepatiesāka, jo arvien vairāk dzīves aspektus kontrolē automātiskas sistēmas, nevis cilvēku subjektīvi emocionālie lēmumi.

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.

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.

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

http://mavericktraveler.com/why-i-left-my-programming-career-and-havent-looked-back/
 

Once the fog cleared, and I had a chance to look at things in a more objective matter, I realized that I can either spend my scarce time communicating with a lifeless computer or spend it communicating with real, breathing people. And the more time I spent telling a computer what to do, the more rusty I became when dealing with humans; by perfecting my skills of talking to a computer, I was simultaneously atrophying my skills when dealing with actual living and breathing humans.
 
Since it’s physically impossible to do both, I had to choose one. In economics, it’s called opportunity cost. Every additional minute that I debug an obscure bug is an additional minute that I’m not reaching out to perspective clients or business contacts. Every additional minute that I look up a vague function is an additional minute that I’m not seducing a cute girl at a coffee shop or at a bar.

The more I thought about it, the more I realized that it all came down to whether I wanted to interact with real, living and breathing humans or keep trying to get some device with transistors to obey my commands. In the end, I chose people.

Tas bija mans viedoklis par Laravel. Atvainojiet...

Nu bet varbūt laba iespēja priekš tiem, kam patīk Laravel.

Salvis 2.0 ...? Manuprāt mēs ļoti labi un uzskatāmi zinām, kas parasti notiek ar "galvenais ka strādā" :>

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.

Ir ieteikumi, kur meklēt?

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

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

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

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.

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.

500, wtf. Man pa komunālajiem ir ~200 mēnesī :D Es gribu +2.5k mēnesī pēc nodokļiem.

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.

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.

DRY ir kodā, datubāzes struktūrā ir normalizācija.

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ā.

Yep, 10k lines of code for what I could do with 10.

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ē.

Manuprāt, call_user_func() FTW. Un listMethods() vietā vajadzētu reflection, kurš atfiltrē metodes, kuras sākas ar handler (handlerFoo(), handlerBoo()).

Es kad pievērosos programmēšanai, tad FW kā tādu vispār nebija un visu nācās apgūt no pašiem pamatiem. Līdz ar to ir ļoti dīvaini, ja "devs" nezin elementāras lietas. Vienīgais attaisnojums - indigo, kas dzimis 21. gadsimtā.

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. :)