404

Interesanti,kur tu eļļu dabūsi kad viss jau nokurināts. Neviens škiet neteica ka Python nav lietojams. Bija pašam vajadzība pēc primitīva skripta,kas KDE4 vidē nolasa no clementine playera metadatus,noformē un iemet iekš skype. Ar Python to izdevās norealizēt pārdesmit minūtēs un nevienu brīdi neienāca prātā doma,ka to vajag darīt ar PHP un pēc tam aizstaigāt uz kādu pitonistu forumu viņiem apskaidrot,ka nahren viņiem to Python vispār nevajag. Kopš pagājuša gadsimta neesmu windows lietojis,bet nevaru nekā noskaņoties zvērīgam naidam. Ko darīt? Piekrītu. Visi profi kodē Vim'ā un neizmanto kaut kādas tur vēl IDE's Parādi lūdzu kādu forumu kurā valda vienprātība uzskatos. Tādā gadījumā pasaulē būtu 1 programmēšanas valoda,1 os un 1 autoritāte. Ideāla nākotne,uz kuru jau tagad google tiecas.

Nu pārliecība bija balstīta uz vienkāršu pieņēmumu: Ir jāielasa XML par katru cenu,tāpēc pēc internal_errors uzsetošanas exceptions kļūst nevajadzīgs jo try būs pozitīvs jebkurā gadījumā. Kļūdos?

Man gan šķita,ka šis piemērs lieliski demonstrē kā un kur viņus labāk būtu nelietot,bet ticēšu uz vārda :)

Manuprāt tā tieši ir priekšrocība,ka skripts kategoriski neizbeigsies no sevis neatkarīgu apstākļu dēļ,respektīvi šajā gadījumā dēļ līka xml,un uzdodot libxml_use_internal_errors(true) vēsā mierā to var turpināt parsēt kaut vai ar XPath un neuztraukties par nekādiem exceptioniem. Neesmu nekad mēģinājis XML lietas iekš Python,bet tāpēc jautājums tīri interesei: kas tur notiks identiskā gadījumā? Ielasam XML,izrādās ka tas ir nevalīds,noķeram exceptionu un ....? Izvadam glītu paziņojumu ka XML diemžēl nevar tikt apstrādāts un viss beidzas?

Nu konkrētais gadījums bija atkarīgs no simplexml_load_file uzvedības,un tā jau nav valodas problēma bet gan programmētāja,kā viņš nočekos rezultātu tur kur fatal error nerodas. Vai tad demagoģija nav par to,ka vajag vienu kļūdu apstrādes metodi un pitona try: except: ir kaut kas par kārtu augstāks kā try {} catch{} ?

Tu pilnā nopietnībā uzskati par trūkumu papildus iespējas izmantot to apstrādes metodi kura liekas konkrētā gadījumā ērtāka? :D Visa šī diskusija man sāk atgādināt sadzīves analoģiju: "Džips vispār nav mašīna! Rijīgs,nestabils un nesmuks!"

Omg! Tev kā programmētājam ar 562 postiem šis nav pamanāms? // check that the request comes from Fortumo server if(!in_array($_SERVER['REMOTE_ADDR'], array('81.20.151.38', '81.20.148.122', '79.125.125.1', '209.20.83.207'))) { header("HTTP/1.0 403 Forbidden"); die("Error: Unknown IP"); } Bet ja par tēmu tad viņu atbilde bija korekta. Debugo check_signature parametrus ja citādi vainu nevari atrast.

Variantos nemanīju tādu feinu linux IDE kā "Kdevelop 4" (Quanta),līdz ar to neaizpildīju,bet apsveicu ar ģeniālu topika nosaukumu :D

Vēl šādi brīnumi gadās,kad kaut kas ir aizsitis ciet 80 portu,piemēram skype vai IIS. Ja aizverot visus liekos procesus un ieliekot firewallā exception arī situācija neuzlabojas,tad,vienīgais kas nāk prātā-mēģināt palaist no komandrindas F:\wamp\bin\apache\apache2.2.22\bin\httpd.exe un skatīties vai kaut ko derīgu neizvada. Edit: Nepamanīju ka šis jau tika iepriekš pārbaudīts :)

Ja nemaldos tad ini fails parasti bija iekš xampp\php,respektīvi: C:\xampp\php\php.ini Var mēģinat atkomentēt visus extension=php_ un skatīties kas notiek slēdzot pa vienam klāt.

Var tikai minēt,cik litru alus programmētājam ir jāizdzer,lai apvainotos uz tiem,kuri ziedo savu laiku lai atrastu un norādītu uz kļūdām paša publiskotajā kodā :D

Paldies par ideju un Amadeus e-Power izskatās visai interesants. Vienīgi neizdodas atrast izcenojumus,kas rada aizdomas par lielizmēra ciparu tādas uzturēšanā :)

Iztieku bez,bet vajadzības gadījumā Yii (atzīmēts).

Un tagad pārskati visus $s2='<ul un atrodi kur tu šo $ul_id esi pielietojis :)

Principā 911 īsti neder kā marketinga instruments,jo loģistikas izmaksas klientam pārsniedz piena vērtību n skaitu reižu. Ieteiktu pieiet lietai radošāk: - Reklāmas rullītis EHR radio - Ik nedēļu uzraut Vanšu tiltā piena pudeļu kasti,un skaisti lidināt tās mazos izpletnīšos ar uzrakstu: "15. gadi biznesā!" - Mērķēt uz jaunu tirgus segmentu,piedāvājot pienu ar alus garšu (varētu būt 3 stipruma veidi katra gaumei) - Izveidot mājaslapu: guntisved.lv kurā interaktīvs balsojums noteiktu piegādes vietu un saņēmēju. - Nolīgt par reklāmas seju Māri Žigatu P.S. Kas ir pienotava: nr. 341? Kaut kas līdzīgs Area 51?

Nu kļūda jau skaidri pasaka,ka otrajam parametram ir jābūt,ja reiz pirmo reizi ir definēts. Nekas tak neaizliedz nākamajā rekursijā padot tukšu stringu: $s2.=sitemap2($row2->id, '');

Nozare ir saistīta ar tūrismu,un tur faktiski sanāk tā,ka tiešie reselleri var saslēgt līgumus ar entajām tūrisma aģentūrām,kuras tad taisa mājsalapas pēc saviem ieskatiem un tirgo gala produktu kā vien vēlas par savu %. Tur neko tehniski uzspiest nevar,un jebkāds php izsauks žēlabu,ka to nevar nodrošināt,ja tādai gala aģentūrai piemēram ir tikai statisks html ar bildīti un kontaktormu. Kā arī klienti var atnākt vienkārši uz biroju. Vienīgais,kas nāk prātā,ir kaut kāds viegli ieliekams Google Analytics tipa kods,lai vismaz redzētu statistiku,un likt visus čekoutus taisīt tikai pirmajiem reselleriem vienā centralizētā formā (varētu tikt izmantots First Data Global Gateway),un tālāk lai paši tiek galā ar aģentūrām. Kā tas notiek praksē,neko daudz neizdevās atrast dēļ komercnoslēpuma plīvura,bet,cik saprotams,tad parasti pirmais tirgotājs uztaisa savu API (kas arī ir paredzēts šajā gadījumā),caur kuru iedod datus,un daudz nerūpējas par to,kā reselleri viņus apstrādās. Varbūt kāds zin,kā tas pie mums lv tiek organizēts apdrošināšanas firmās,kas strādā ar manapolise.lv tipa brokeriem? Tehniski,ja nemaldos ir wsdl serviss,kas partneriem iedod datus par polisēm,bet kā tiek kontrolēti čekouti? Viena un tā pati maksājumu forma visiem?

Padod to id kā papildus parametru rekursijai tikai pirmo reizi: $ul_id = ' id="MenuBar1"'; function sitemap2($pid2, $ul_id)

Ir kompānija,kura tirgo pakalpojumu tiešajiem partneriem,kuri tālāk to pārdod caur savu partneru firmu tīklu (iespēja veidot savus resellerus) n līmeņos. Ir jāizveido divvirzienu XML datu apmaiņa starp "centru" un 1. līmeņa partneriem,kā arī jānokontrolē brīdis,kad gala klients nopērk pakalpojumu. Tā var būt n resellera mājsalapa,kurš to veido pēc saviem ieskatiem,un tiešas kontroles pār to nav. Problēma šobrīd ir izplānot,kā maksimāli automatizēt atgriezenisko naudas plūsmu: klients -> reselleris -> pārdevējs. Iespējamie varianti: 1. Likt izmantot visu līmeņu reselleriem 1 centralizētu apmaksas formu,kurā klients maksā nevis resellerim bet gan "pa tiešo",un pēc maksājuma redirektēt atpakaļ uz resellera mājaslapu,līdzīgi kā tas notiek PayPal gadījumā. Attiecīgi mēneša beigās reselleri saņem savas komisijas. Ja nemaldos,tad pēc līdzīga principa darbojas visi lielie affiliate tīkli. 2. Atļaut reselleriem pārdot pašiem,un slēgt līgumus,kas viņiem liek veikt ikmēneša norēķinu par saņemtajiem pakalpojumiem. Šādā gadījumā nākas likt katram resellerim vest kaut kādu savu statistiku ,vai arī pēc katra darījuma likt nosūtīt datus. Rodas virkne problēmu kā to nokontrolēt,lai nerodas situācija kad ir notirgojis entos pakalpojumus bet norēķinās tikai par pusi. Izmaksas nebūtu būtiskākais (saprāta robežās),bet interesē efektīvākie varianti kā šo apriti nodrošināt maksimāli droši. Noderētu jebkāda info (tai skaitā kā to realizē lielizmēra giganti),lai apzinātu iespējamos zemūdens akmeņus. Var arī PM vai par samērīgu atlīdzību ja kāds ir jau veiksmīgi šamo uzprojektējis kādai kompānijai un var nokonsultēt par realizāciju :)

Arī bija doma kaut ko piektdienīgu ierakstīt,bet moderēšana pārāka kā stackoverflowā :D Ar pievienojos protestam,un kamēr offtopiks nav nopludināts,tikmēr tak nav ko iespringt :)

Kritika var būt pamatota un ne tik pamatota,bet bez iemesla viņa šeit parasti nav sastopama. Šis koda fragments rosina uz vēl dažiem jautājumiem,bet lai nu paliek. Palasi ko dara mysql_real_escape_string un kāds ir stripslashes uzdevums. Ja iedziļināsies problēmā,atbildi atradīsi :)

Regulāri lasot tavas problēmas,sen jau radās viens jautājums,bet pēc šīs vēlme pajautāt kļuva neizturama.. Tu skaidri zini ka programmēšana ir tavs aicinājums?

Servera pusē tu nekā klienta progresu nenokontrolēsi,bet var izmantot kādu no šīm metodēm,kā nokontrolēt brīdi kad klients ir ielādējis failu,un ar ajax padot komandu uz skriptu,kurā izpildīt faila dzēšanu. Var arī pieglabāt iekš db servēšanas brīdi,un vienkārši dzēst "vecos" failus pēc kaut kāda laika. Kā turpināt "pārrautu" ielādi,varētu būt ideja šeit

Te varētu būt 2 iemesli: 1) Tu ciklā veido entās cURL sesijas. Tā vietā var izmantot vienu,pirms cikla sadefinējot headerus + opcijas,un tālāk mainot tikai url: function move($url) { global $ch; curl_setopt($ch, CURLOPT_URL, $url); return curl_exec ($ch); } foreach($urls as $url) { $content = move($url); } 2) Return atrodas pirms ob_end_clean(); curl_close ($curl); unset($curl); Līdz ar to beigas neizpildās,un konekcijas netiek slēgtas.

Bija samērā nesen sižets iekš raidījuma "Latvija var",kā tur viss šobrīd notiek,tā ka ieskatam var iemest aci šeit