Kasspars

Viss atkarīgs no tā, KĀ gribēsi meklēt Ja vienkārši pēc keywordiem, tad Natural. Svarīgi zināt, ka ja vārds ir sastopams vairāk par 50% no teksta, tad tas netiek ņemts vērā Ja pēc loģikas - piemēram, "atrod ierakstus ar vārdu 'kaķis', bet bez vāda 'suns'", tad būs jāņem BOOLEAN. Šeit 50% noteikums netiek ņemts vērā

Parādi kā uztaisīt kvadrātu, tad to kvadrātu pārtaisi par kubu, tad liec kubam griezties. Ja vēl fonā ieliksi, lai skan frozen dziesma sīkajiem acis būs kubā!

Tobiš beta, lai arī kā censtos vienmēr būs otrais?

Vai nu tavi skili ir par vāju priekš viņiem, vai arī pārāk augsti :D

Codez, te vienīgais reāli domājošais! Esat kādreiz aizdomājušies, ka ministrijas ir tās, kas veido budžetu. Ja ministrijas rīkles prasa 100 miljonus, tad valdība tos iedod. Un tā ir visa mūsu nodokļu maksātāju nauda. Ministrijās strādā cilvēki ar izkropļoto realitātes sajūtu, jo viņiem nevajag domāt, kā nopelnīt naudu, viņiem tā nauda vienkārši tiek iedota. Un viņi notralina to naudu bez jebkādiem sirdsapziņas pāmetumiem. Savukārt uzņēmējam ir jādomā, kā nopelnīt, viņam ir jāstrādā 18h dienā, lai dabūtu to naudu. Kamēr ministriju dīkdieņi piektdienās taisa saīsinātās dienas, jo afigena nostrādājušies.

vai tad nebija kaut kāds ierobežojumus, ka MUN vairāki kā 80%(?) ienākumi nevar būt no viena klienta?

Frontend pie mums vēl ir nenovērtēts. Vispār pie mums daudz kas ir savādi. Kā nekā esam dziļi lauki

3 gadus vēl varēsi likt galdā kartupeļus un gaļu, pēc tam gan vajadzēs sākt barot birokrātisko aparātu :)

Mikrouzņēmumu nodokļa likumā ir paredzēts pārejas periods nozaru ierobežojuma piemērošanai. Ja mikrouzņēmums mikrouzņēmumu nodokļa maksātāja statusu ieguvis līdz 2015. gada 30. aprīlim un veic saimniecisko darbību nozarē, kurā nav tiesības piemērot mikrouzņēmumu nodokļa maksātāja režīmu, mikrouzņēmumu nodokļa maksātāja statusu piemēro 2016., 2017. un 2018. gadā. Ja mikrouzņēmums mikrouzņēmumu nodokļa maksātāja statusu ieguvis no 2015. gada 1. maija līdz 2015. gada 31. decembrim un veic saimniecisko darbību nozarē, kurā nav tiesības piemērot mikrouzņēmumu nodokļa maksātāja režīmu, mikrouzņēmumu nodokļa maksātāja statusu piemēro tikai 2016. gadā. http://m.lvportals.lv/visi/preses-relizes?id=273862

No 20 req 5 nevarēja nolasīt DB_USERNAME

Tev varbūt applikācija netaisa daudzus secīgus ajax pieprasījumus, tāpēc arī šī problēma neuzpeld Pamēģini uztaisīt kādus 20 ajax req vienu pēc otra, kurā tiek nolasīta sesijas vērtība. Vismaz vienam no pieprasījumiem būtu jānofeilo - tobiš neatgriezīs sesijas vērtību <script> for (var i = 0; i < 20; i++) { $.get('/testsessionvariable', function(r){console.log(r)}) } </script>

Virtuālā mašīna palīdz, bet gribās atrast risinājumu win mašīnai Briedi, tu nelasi?! 1) funkcija getenv vienā mirklī neatgriež vērtību. 2) getenv netagriež vērtību, tātad netiek nolasīts pareizais config parametrs, piemēram, DB_USER 3) netiek nolasīts DB_USER, nevar pieslēgties pie DB 4) rezultātā pieprasījums beidzas ar neko neizsakošo "Whoops something went wrong". Log failā, protams, kļūda ir, ka nevar pieslēgties pie db Man tas izpaužas šādi 1) Ielādējas lapa 2) Lapa uztaisa 4 ajax requestus 3) viens no šiem request beidzas ar klūdu (nevar pieslēgties pie db) 4) Tas notiek pilnīgā randomā. Ja refreshot lapu, tad kādā 5. reizē būs error (nevar pieslēgties pie db) Te viens links. Ir arī patchi, bet man vairāk interesē ko pašam windows izdarīt, lai negļuko http://stackoverflow.com/questions/31295126/laravel-5-losing-sessions-and-env-configuration-values-in-ajax-intensive-applic

Cik es izdebugoju, tad problēma ir php funkcijā getenv nevis laravel Topiks par laravel, jo to izmanto daudzi un neticu, ka tikai man tāda problēma. Varbūt kāds arī saskāries un var ko ieteikt

Presē lasīju viņa nesmukos izteicienus par tiem, kas izmanto MUN :)

Ir problēma ar laravel uz windows. Ja ir daudz secīgu pieprasījumu, tad vienā mirklī nenolasās config no .env un attiecīgi errors. Tas notiek pilnīgā randomā Pats izdebugoju līdz Dotenv bilbliotēkai un sapratu, ka pats php/windows gļuko. Precīzāk funkcija getenv vienā mirklī neatgriež vērtību. Kaut kāds fakaps Internetā arī visi vaimanā par šo, bet normāls risinājums nav. Produkcijā, protams, ir linux un tur šādi gļuki nav novērtoti Ir kādam kāds ieteikums?

Mozello īpašnieks iedomīgs krāns. Ta jau labāk http://froont.com/

Wordpress + Digitalocean. Izmaksas būs tikai hostings. Vai arī paņem wordpress.com, tur pat par hostingu nebūs jādomā. Mājas lapa ir ļoti plašs jēdziens. Viss lielāko izmaksu daļu veido dizains un user interface fīčas (animācijas, galerijas, formas utt) Lai pateiktu cenu ir jāmāk nolasīt tavas domas, bet to neviens nemāk. Tāpēc uzraksti kādas funkcijas vēlies redzēt lapā un tad kāds arī iedos cenu piedāvājumu

jurchik tu esi reality warping speciālists! Es zinu, kas ir ūdens bet nezināju, ka tas ir slapjšs. Kaut kā tā

Iemet kādu primitīvu skici, kā gribi redzēt blogu. Tā būs uzreiz vieglāk uzlēk uz viena viļņa ar tavu domu.

Mēs šodien gaļas mašīnu projektēšanas nodaļā iesmējām par vienu klientu, kurš pasūtīja custom gaļas mašīnu pa 20 ļimoniem

Wordpress + Woocommerce + Digitalocean

Viņiem bija savs veidots CMS, kuram lepni footerī bija ierakstīts "Created with love at Efumo". Lieki piebilsts, ka CMS bija nenormāli sūdīgs, gan no koda viedokļa, gan no UX viedokļa

Uz katru lauku indeksus neliks. Indeksu pieskaņos vajadzīgajā atskaitēm Un kā ir ar šādu situāciju, tas var radīt kaut kādas problēmas? indekss1 (lauks1, lauks2, lauks3) indekss2 (lauks2, lauks3, lauks4) Tu dažas ļoti labas nianses izstāstīji

Protams, ierobežojumi ir abos gadījumos. Es arī neesmu saskāries ar 500 laukiem tabulā, bet ticu, ka īpašos gadījumos ir vajadzība, tāpēc arī uzsvēru, ka nevajag balstīties uz iedomātie ierobežojumiem. Kāpēc selektējot pēc vairāk par 5 laukiem query būs lēnaks? Slinkums tagad lasīt to linku

objekta_id | propertija_nosaukums | propertija_vertiba Ja ir šis modelis, tad selektēšana pēc vairākiem propertijiem ar AND arī ir čakarīga. Papildus jāskatās vai visi pieprasītie propertiji ir atlasījušies, nevis tikai viens.