F3llony

Nu pie katra pieprasījuma raustīt interpretātoru tikai lai vienu reizi pārbaudītu sintaksi arī nav gluži prāta darbs...

Negribu izklausīties piekasīgs, bet pamatīgi cērtas acīs - Dubultpēdiņas Dubultpēdiņas un string->var konkatenācija Vesela kaudze ar echo. Šis noteikti ir ciklā? //Action //foreach/while if( $catfull != 'featured' ) { $buf .= '<item> <name>'.$product_type.$name.'</name> <link>'.$url.'</link> <price>'.$price.'</price> <image>'.$img.'</image> <category_full>'.$catfull.'</category_full> <category_link>'.$caturl.'</category_link> <in_stock>'.(int)$qty.'</in_stock> </item>'; } //endforeach/endwhile echo $buf;

/Klusi applaudē /Mod// Par tēmu - ūdens tas nav. Ir ne mazums letiņu un ne mazāk ārzemju itt kantori, kam ar komunikāciju pašā kantorī ir pamatīgā pakaļā - plānošana sucks, nav skaidra "chain of command" (nē, visi nevar būt vienlīdz vadoši, demokrātija nedarbojas), nemaz nerunājot par sliktu komunikāciju ar stakeholderiem (stakeholder ( == || != ) klients) kā rezultātā top sliktas specifikācijas un zūd kvalitāte. Ir labi, kad lead var objektīvi un korekti lemt par termiņiem, bet lielā daļā kompāniju lead vedas pēc "how to earn more in less amount of time", kas nozīmē pārslodzi "melnstrādniekiem". Problēma ir. Ir labi, kad kāds apzinas šīs problēmas un tās labo. Diemžēl, ne visi viņas apzinās.

A varbūt sarunājam, ka šajā topikā liekam to, kas prasīts topikā un savas nevienam nevajadzīgās dogmas par kāda konkrēta linka lietderību pārnesam uz spamu? Moder, rīkojies.

There are 5 worst practices in software development that if stopped immediately will improve your productivity...

Lapa ir puslīdz okei, ja neņem verā dažus zemas kvalitātes dizaina elementus. Zinot, ka apakšā ir, lets be honest, blogdzinējs, ir tīri okei. Oftopikā, mani reāli sāpināja cenas. :D Es tomēr labāk izvēlēšos Depo un savu instrumentu kasti...

Un jā, es zinu, ka šī iespējams nav īstā vieta, kur meklēt. Bet kazi.

Kompānija piedāvā pilna laika pozīciju uz vietas lieliskā birojā Rigas centrā darbam pie, pārsvarā, bet ne tikai, Web aplikāciju dokumentēšanas, sistēmu un arhitektūru plānošanas, "jaunrades" jau esošo projektu virzienā un citiem ar sistēmanalīzi saistītiem darbiem. Nepieciešamas lieliskas sistēmanalīzes prasmes, zināšanas par web platformas iespējām, PHP iespējām - e.g. spējas, piemēram, dokumentācijā nesarakstīt, piemēram, web nerealizējamas vai neoptimālas lietas. Lieti noderēs arī labas komunikācijas spējas (būsi klientu un programmētāju labākais draugs). :) Pieredze - obligāta. Draudzīga un zinoša komanda, un rīta kafija garantēta. Ko neproti - parādīsim, ko nezini - iemācīsim. :) Par samaksu vienosimies tikšanās laikā izvērtējot katra pretendenta individuālo potenciālu. Motivācijas vēstuli brīvā formā un CV sūti uz [email protected] kā tēmu norādot "Pieteikums sistēmanalītiķa vakancei".

daGrevii, nu pat es nedomāju, ka Tu esi TIK lēts... Cmoon

Cibiņ, vērsies pie manuāļa... Līdz kaut kam šādam vienkārši vajag prast dadomāties....

Zefīr, jā, tieši to tas nozīmē. E.g. ja man ir 100% plats layout, kas dizainēts mostly lietošanai ar 1024+ izšķirtspēju, to samazinot vai palielinot, layouts pielāgojas nezaudējot pārskatāmību. Piemēram, bloki, kas atrodas blakus tiek pārbīditi viens zem otra utt. tranformācijas.

Ir kādi ieteikumi šajā sakarā? Pamatā meklēju 960/* tipa freimu bez lieka stuff- nekādas pogas, nekāds šits man vienkārši nav vajadzīgs, tikai un vienīgi responsive grid ar vai nu 960 vai nu 100% platumu. Ir simts un viens, bet interesē, kurš tiešām kādu no viņiem lieto un kādas atsauksmes.

Kompānija piedāvā pilna laika pozīciju uz vietas lieliskā birojā Rigas centrā darbam pie PHP web aplikāciju izstrādes saskaņā ar dokumentāciju un vadības norādījumiem. Nepieciešamas labas zināšanas PHP5/HTML5/CSS/JS, PHP5 OOP, un vispārējas zināšanas web aplikāciju uzbūvē, labi attīstīta loģiskā domāšana un labas komunikācijas spējas. Draudzīga un zinoša komanda, un rīta kafija garantēta. Ko neproti - parādīsim, ko nezini - iemācīsim. :) Par samaksu vienosimies tikšanās laikā izvērtējot katra pretendenta individuālo potenciālu. Motivācijas vēstuli brīvā formā un CV sūti uz [email protected] kā tēmu norādot "Pieteikums PHP programmētāja vakancei".

Kādu bļin pamatojumu? Ka tu sēdi uz savas D, pelni naudu ar instrumentu, kas kādam maksā izstrādāt un uzturēt un eksploitē izstrādātāja labo karmu tikai tāpēc, ka principa pēc negribi samaksāt tās kapeikas? Ieskrien sienā. WTF

Ezis, tieši šāds teksts liecina par morālu kroplību.

Grēvi, vai Tu redzi mani minam ZS, Netbeans, stormu, komodo iepriekšējā posta ietvaros? Nē? Stfu. aaxc, kāpēc Tu domā tieši? Ar netieši arī ir tīri okei. DP un FP ļoti labi orientējas nix sistēmās.

Pirmais, pamazām sāk likties, ka php.lv apgrozās pašdarbnieku-mazohistu pulciņa patstāvīgie apmeklētāji. Vim, gedit, kate, sublime, bluefish, geany? Fo-real?... Kur tad leafpad? Otrais, aaxc smagi maldās par to, ka nav, kas kontrolē. Ir, un māk arī pietiekami labi. Nemaz nerunājot par to, ka izmantot instrumentu naudas pelnīšanai un par to nemaksāt ir pamatīgas morālas kroplības pazīme.

http://www.eclipse.org/webtools/jsdt/

Eclipse ar PDT, jstools, un mylyn.

Nolāpītais firstdata....

Grēvi, taču pirmajā postā teica Kādas vēl biznesa prasības, kādi galvenie dati, kādi sekundāri dati? Ir runa par modeli, kur lietotājs nereģistrējas, bet autorizējas sistēmā izmantojot API - as if aizstāj auth-reg lapā kā tādu. Nafig tu jauc cilvēkam prātu ar savu demagoģiju, no kuras viņam vienalga nekāda īpaša labuma nebūs... Biznesa prasības. Ibio. Diez tu maz zini, kas tas ir...

Viens virtuālais lietotājs uz katru atsevišķo api. Eg twittera lietotājam būs tavā esošajā lietotāju tabulā viens lietotājs, no Googles - cits lietotājs. Un avatarus kopēt nevajag - pie autorizācijas pārbaudi datus, tādējādi tev vienmēr būs links ar pēdējiem avatariem. Ja tomēr vēlies - vari lokāli kešot, būs nedaudz ātrāka ielāde, bet rēķinies arī ar to, ka būs jāglabā tie dati.

What is this I don't even...

1) Pamatā, lietotāju datiem no ārējā api būtu jābūt savās tabulās, katram api atsevišķi. Tālāk relāciju tabulas - vai api konts piesiets esošam lietotājam, vai arī nē. Atkarībā no esošās autentifikācijas sistēmas un projekta kompleksitātes ir divi varianti - pārrakstīt autorizēto lietotāju iespējas ar iespēju darboties ar "virtuāliem" lietotājiem no citiem api vai arī pie pirmās autorizācijas caur api pārbaudīt vai api tabulā esošajam lietotājam ir relācija ar "virtuālo lietotāju" jau esošo lietotāju tabulā. Ja ne - izveidojam ierakstu lietotāju tabulā, piemēram, bez paroles un katru reizi kad lietotājs autentificējas no api, atjauninām datus pret api esošajiem lietotāju tabulā un autentificējam izmantojot sesiju/citus mehānismus. 2) Ar relācijām. Skat. 1. 3) Jā, katru reizi, kad lietotājs autentificējas datus no api vajadzētu ielādēt savā ierakstā. Api lietotājus identificē pēc idiem, kuri tev būs jāpieglabā tabulās katram api. Ņem vērā to, ka nevajag visu bāzt vienā maisā - tu pilnīgi noteikti negribi milzīgu users tabulu ar 100 kolonnām un vēl sazin ko. Normalizācija ir common pasākums zema pieprasījuma ratio sistēmās, jo diez vai tev jēl kādreiz nāksies mērogot šīs tabulas un pat ja nāksies - šajā gadījumā tas būs vieglāk izdarāms ar izdalītām tabulām.

Laužu Mylyn