e-remit

Kāpēc neieliec publiski?

Vienkārši runājot, objekti netiek glabāti pašā mainīgajā, bet kaut kur dinamiskajā atmiņā un mainīgajā saglabā tikai saiti uz objektu. Piešķirot jaunam mainīgajam pirmā mainīgā vērtību, jaunajam mainīgajam netiek veidots jauns objekts, bet tiek iedota saite uz to pašu objektu. Tāpēc arī nevar masīvu pa tiešo nokopēt, bet tikai saiti uz to.

Kāpēc lai nevarētu COUNT izmantot? Idejiski: SELECT t1.id, ( SELECT COUNT(*) t2_count FROM t2 WHERE t2.t1_id = t1.id ) some_count FROM t1 ORDER BY t1.`order`

Tak tāpat tas GROUP BY ir lieks, jo no t2 un t3 pa vienam laukam tiek lasīts, līdz ar to var pa tiešo SELECT daļā ielikt šo tabulu atlasi un GROUP BY nebūs vajadzīgs.

Ātrumu varētu uzlabot, ja atmestu GROUP BY, un tās divas tabulas, kuras tu pievieno ar LEFT JOIN, atlasītu SELECT daļā kā subquery.

Nu, piemēram, "Valentina Studio" http://www.valentina-db.com/. Fīču daudzumu gan neanalizēju, jāatzīst, un no ikdienas ērtības viedokļa es arī uz Linux lietoju HeidiSQL, nevis šo.

UNION strādā, kā DISTINCT, tāpēc arī var neuztraukties par to, vienīgi jāskatās uz ierakstu skaitu, lai pareizu dabūtu. Protams, šis risinājums var izrādīties lēns, bet diez vai autora kodam draud liela noslodze.

Ir iespējams. Vienkāršākais - taisīt divus pieprasījumus, bet sarežģītāk, pēc principa: SELECT id, lauks1, lauks2, ord FROM (SELECT id, lauks1, lauks2, 0 AS ord FROM tabula WHERE lauks1 > :te_var_funkciju ORDER BY lauks1 LIMIT 10) UNION SELECT id, lauks1, lauks2, ord FROM (SELECT id, lauks1, lauks2, 1 AS ord FROM tabula ORDER BY lauks1 LIMIT 20) ORDER BY ord, lauks1 T.i. atlasi abus atsevišķi, tad ar UNION saliec kopā un skaties, kas sanāk.

Kā reizi uzskrēju Scala sludinājumam, ja kādu interesē: http://www.cvmarket.lv/view_jobad.php?job_id=151711&w=1 Tā, ka nav arī pilnīga nulle ar piedāvājumiem.

Atsaucoties uz Lokenbahu, ja tev jātaisa projekts un jāizvēlas vide, tad, ja tev ir Java programmētāji, taisi Javā, ja tev ir citas tehnoloģijas programmētāji, taisi šajā tehnoloģijā. Toties iespējas tikt uz šādām vakancēm radikāli krītas, tikko pasaki, ka nevari katru dienu strādāt ofisā, tad reti kuru interesē tavas prasmes. Tas ne tikai programmēšanas jomā, cik esmu novērojis. Vai arī mēdz būt tā, ka vairāk pelna tas, kurš jau sākumā paprasīja lielāku algu - arī tas ir novērots.

Nu jau gan āboli ar siļķēm vienā bļodā... viena lieta ir programmēšanas valodas un vides priekšrocības, pavisam cita - cik ar to var nopelnīt! Ja vajag dabūt freelance darbus, tad PHP varētu būt vienkāršāk, jo Scala tik daudz netiek prasīta. Savādāk ir, ja saņem pasūtījumu taisīt projektu no 0, jo tad var izvērsties un izvēlēties vidi, kurā uztaisīsi ātrāk un kura būs stabilāka uzturēšanas termiņā. Tāpat no svara, vai saņemsi nākamo pasūtījumu, ņemot vērā acīm redzamo rezultātu.

Ko tev dos IP adreses, ja 10 LMT klienti visi lieto vienu IP adresi, bet viens cits lietotājs ar savu planšeti vienas sesijas laikā pamanās 10 Wifi nomainīt, līdz ar to 10 IP adreses viens pats savākt?

Jā, izmanto cookies ar expire time = 0. Tad cookie dzīvos tikai tik ilgi, kamēr pārlūks atvērts. Tiesa, ja pārlūku nevērs ciet nedēļu un katru dienu apmeklēs lapu, tā būs tikai viena apmeklējuma reize.

Izslēdz visas notices un tad brīnās, ka "pareizs" kods nestrādā, kā vajag...

Vecos labos laikos lietoju Pomodairo https://code.google.com/p/pomodairo/ Tas gan uz AIR bāzēts bij, bet nu Pomodoro tehnikas softi daudz un dažādi uz dažādām platformām. Vienu brīdi pat Gnomē integrētu lietoju.

Un padot objektu, kurš satur objeku masīvu, nevar? Kā http://coenraets.org/blog/2011/12/tutorial-html-templates-with-mustache-js/ - sk. 9. un 11. piemēru! Tiešām viss pašam ar rokām jāliek kopā?

Jums PhpStorm ir legāls - pirkts?

Autors nav atbildējis uz iepriekšējiem ieteikumiem, nav neko precizējis, tātad viņš atbildi ir vai nu saņēmis, vai arī viņam tas vairs nav aktuāli. Bet tas, ka tu mani citē jau 3. reizi norāda, ka esmu uz kādu sāpīgu problēmu trāpījis. Varbūt pārstrādāšanās un izdegšanas sindroms? Iesākumā pamēģini pirms <Post> spiešanas pārlasīt sevis rakstīto un padomāt, vai esi uzrakstījis to, ko gribēji pateikt, savādāk tu bieži sāc teikumu par vienu tēmu un beidz par citu! Bet, ja es tev tālāk neatbildu, es vienkārši izvairos no troļļa barošanas.

Beidz pierakstīt pārējiem savus trūkumus! Kā tāds alkoholiķis....

vbz, tev pietrūkst komunikācijas, ka nepietiek strīdēties ar citiem un jau sāc strīdēties ar sevi?

codez nav iešāvis vienu mazo nulle septiņi, ka sācis troļļot? ;)

Diez vai tur ir "labāk" vai "sliktāk". Dažādos projektos bizness var prasīt dažādu pieeju. Tiesa, PHP gadījumā biežāk tiešām labāk varētu būt, ka definīcijas glabā sourcē, bet diez vai 100% gadījumu. Lielos projektos un to apakšprojektos tas varētu arī nebūt spēkā.

Pārāk tālu meklēt netīk, bet tikai uzmetot aci googles rezultātu pirmajai lapai, piemēram, ļauno URL saraksts: http://urlblacklist.com/?sec=download

Ar krawleri atvelc lapas no šiem linkiem, tad skaties - šajās lapās jābūt aizpildītiem meta keywords un vēl pačolēt, vai nav atbilstošs meta rating. Parasti jau šīs lapas nodarbojas ar SEO un mēģina patikt meklētājiem, tāpēc ar meta tagu analīzi vajadzētu pietikt.

LIMIT sadaļā tiešām nevar izmantot prepared statement, bet arī real escape tur arī nav jāizmanto - pietiek ar (int) vai intval(). IN sadaļā tiešām jāiet tas ceļš, kuru norādīja jurchiks, vienīgi varēja viņš to īsāk uzrakstīt, lai nebiedētu tautu ;)