404

Apburtais loks.Ir pietiekami darba devēju,kuri par projekta budžetu,vai vismaz aptuveno algas apjomu,klusē kā partizāni,jo: * Programmētāji ir iedomīgi silikongalvas,kuru vieta ir pie pc,nevis mācīt kā plānot budžetu.Nenod dievs,vēl apjās uz termiņu,kurā nekad neiekļaujas,kad jāuzkodē kāds papildu forumiņš,lietotāju profili,galerija vai sludinājumu sadaļa.Bieži atļaujas prasīt vēl piemaksas. * Draugs/rads/paziņa/tas tur kantoris tak atrada sviestmaižu koderus,un viss ir čikiniekā.Krīze taču. * Bija slikta pieredze ar iepriekšējo programmētāju.Projekts neaizgāja,un nebija par ko samaksāt.Šis apvainojās un nepabeidza. * Ir maz tādu zinošu,kam būtu vērts maksāt.Nemāk ne serveri nokonfigurēt,ne smuku dizainu uzzīmēt,ne klientus nosupportēt.Pat saturu nākas lapā pašam savadīt.Bet līgumus un naudu gan grib. Un ir programmētāji,kas tādus "darba devējus" ir pieredzējuši un: * Apskatās autora epastu,uzgoglē firmas info,izlasa prasības un mēģina izzīlēt iespējamo algas/problēmu attiecību.Ja mīnusā,tad aizmirst sludinājumu pēc 5 minūtēm.Ja tas ir noformēts nevis kā doma: "Jūs man te tagad rādat ko mākat,un tad paskatīsimies",bet ar elementāru info,kas ļautu izvērtēt savu atbilstību,riskus un iespējamo atalgojumu,tad pieteikumu būtu daudz vairāk un arī šādu tēmu nebūtu. Eh,patroļļoju,palika vieglāk :)

Nu tad jau vienkārši izvadot ziņas pietiek piemest klāt katrai [x] linku,kurā padot kaut vai ziņas pievienošanas laiku un izdzēst pēc principa WHERE addtime='.$message_addtime.' Manuprāt iespējamība ka tabulā varētu būt ziņas ar vienādu pievienošanas laiku,ir tuvu nullei.

Ja ar to ir domāta čata "veco" ziņu nevis kādas noteiktas dzēšana,tad,lai nav jāčeko kaut kāds x ziņu skaits,tad vēl ir arī variants pie katras jaunas ziņas pievienošanas vienkārši dzēst 1 pēc addtime vecāko.

Darba devēji no tādiem programmētājiem baidās kā velns no krusta,uzskatot ka koderis savās mājās strādāšanas vietā dzers alu,braukās meitās,strādās konkurentiem un sagādās vienas vienīgas problēmas.Ir,protams,daļā gadījumu, pamats arī tā uzskatīt,bet tiekot vaļā no steretotipiem,arī varētu atrast daudz spējīgu darbinieku. (Offtopic arī rullē :))

Ar to likšanu "pa taisno" var uzkāpt uz grābekļa diezgan ātri.Cik pašam tā nav bijis,ka,uzskatot,ka nekādas papildus darbības ar POST datiem vajadzīgas nebūs,tas tiek vienkārši ar visu validāciju iekš kverija iemests.Paiet laiciņš,un kodam savajagās kādus uzlabojumus,un tad "ai,nu bet tur jau nebūs vajadzības" sāk atspēlēties,kad nākas no katra kverija to post atkal ķeksēt ārā,un definēt ar visām apstrādēm jau sākumā,ko būtu varējis izdarīt jau pirmajā reizē.Otrs tāds pats grābeklis ir {} nelietošana aiz if,domājot ka tur jau ar to 1 darbību mūžam pietiks tajā vietā :)

Ideāls raksts. Paldies :)

Ir radusies vajadzība ievākt datus no lapas,kura izmanto samērā vienkāršu captcha kodu searcham,bet tā kā nav nācies agrāk saskarties ar captcha protection apiešanu,tad interesētu metodes,ar kādām iespējams šo attēlu nolasīt un apstrādāt lai izvilktu kodu.Respektīvi tas vispār ir izdarāms ar php un GD līdzekļiem? Kā to dara kaut vai tie paši spamboti? Manā gadījumā gan projekts nav saistīts ar spamu,un potenciālais pasūtītājs vienkārši vēlas ikdienas excel reportu no šī saita.Cik izdevās uz ātro atrast,tad tas tiek realizēts ar GOCR + ImageMagick novācot backgroundu,un veicot skenēšanu.Ir tam jau kādas gatavas php vai pear klases kur dabūjamas,jeb jāburas būs cauri pašai metodikai? Respektīvi vairāk interesē,cik tas vispār ir viegli izdarāms,un vai tas ir tā vērts.Būšu priecīgs arī par norādēm,kurā virzienā jārok.Nav pārāk daudz info par šiem risinājumiem,bet labprāt palasītos :)

Mazliet offtopic-kāds zina,vai Netbeans vispār ir iespējams kaut kādā veidā atslēgt to automātisko failu/projektu nepārtraukto skenēšanu? Tas bija galvenais iemesls,kāpēc pārgāju uz Komodo Edit,jo uz ne pārak svaigas kastes resursus rija bezjēgā.Bet citādi nav ne vainas.No daudzajiem savulaik mēģinātajiem,javistiem paredzētais Jedit patika.Nav gluži IDE,bet ir pamatīgi customizējams pēc vēlmēm ar kaudzi pluginu,ieskaitot koda formatēšanu un ftp.

Visu tabulu nosaukumi neglabājas iekš 'subtable' lauka.Defaultā tas ir NULL un tieši to arī prasījās pārbaudīt,vai lauks kaut ko satur.Ja jā,tad tur atrodas alternatīvā apakštabula,un džoinot no viņas.Ja nē,tad no 'sections'.Protams nav problēmu visu,kas vajadzīgs glabāt vienā 'sections',bet tad viņa sanāks kā pamatīga tabula,kurā vienā rosolā būs autorizācija,raksti,aptaujas un viss pārējais,kas vien ir zem saita kategorijām.Droši vien tas arī nav slikts variants,un lasīts arī par pieeju,kad vispār kategorijas,sekcijas,subsekcijas glabā visas 1 tabulā,kuru rekursīvi nolasa.Katrai metodei savi trūkumi.Kaut kā loģiskāk likās tomēr sagrupēt par spīti čakaram ar sasaistīšanu.Jeb tomēr jāiet uz pāris tabulu variantu un miers?

Tur jau tie joki,ka gan tabula tāda ir,gan viņas nosaukums pareizs,bet vienalga neatrod. Db struktūra šobrīd ir pēc principa kategorijas->sekcijas->subsekcijas.Pašas idejas pamatā,kāpēc gribēju šādu kveriju ir tas,ka tematiski atšķirīgas sadaļas(piemēram rakstus) lai nebūtu viss vienā putrā iekš 'sections',tad iznest ārā atsevišķās tabulās,bet masīvā joprojām ielasīt tāpat kā visas sadaļas,lai apstrādes pusē nekas nemainītos.Tad arī radās tā ideja dinamiski uzreiz kverijā izvēlēties un piedžoinot vai nu vienu vai otru.Ja tā nav iespējams,tad nāksies domāt ko citu.Viens no variantiem,kas nāk prātā-lasīt tikai kategorijas un ciklā iet cauri masīvam, taisot pieprasījumus uz apakštabulām.Tas laikam būs visai bremzīgs risinājums.Kādi vēl varētu būt varianti? Saformēt pirms kverija sql stringu varētu,ja būtu zināms,kāda apakštabula kurai kategorijai būs vajadzīga.Bet tas kļūst zināms tikai kverija laikā :D

Nu skaidrs.Bija šis tas lasīts par if/else iespēju,bet nu ir skaidrs,kāpēc tieši šādam risinājumam nekur piemērus atrast neizdevās :) Paldies par atbildēm,un pārdomāšu iespējas vai nu pirms kverija saformēt vajadzīgo sql stringu,vai savādāk organizēt tabulas.Labi ka saits tikai izstrādes stadijā.Variantus var diezgan brīvi mainīt.

Šādi varētu būt ok,bet nu ir cita kļūda: Table 'c.subtable' doesn't exist.Tagad nevaru saprast,vai kverijā netiek viņa atrasta jeb man kaut kas ar db ne tā.Cik saprotu,tad nvl iekš mysql jāraksta kā IFNULL,bet arī tā neiet.Šis piemērs uzvedināja uz vēl vienu domu.Šādu nosacījumu nav iespējams kaut kā iedabūt kverijā? FROM categories AS c LEFT JOIN IFNULL('c.subtable','sections') AS s

Tas variants derētu,ja būtu pāris kategorijas ar iepriekš zināmu apakštabulu.Bet tā kā viņu ir pietiekami,tad katrai kategorijai formēt savu sql stringu ar vajadzīgo joinu nebūs īsti prātīgi laikam.Bet ja nevarēs savādāk,tad kaut ko uz to pusi jau būs jādomā laikam :)

Šobrīd ir šāds te MySQL kverijs(saīsinātā variantā),kas ielasa saita kategoriju un sekciju datus: SELECT c.id AS c_id, c.access AS c_access, c.name AS c_name, c.subtable AS c_subtable, s.id AS s_id, s.parent_id AS s_parent_id, s.access AS s_access, s.name AS s_name FROM categories AS c LEFT JOIN sections AS s ON s.parent_id = c.id ORDER BY c.order_id,s.order_id Viss strādā,bet tā kā ir arī daļa datu,kas pieder pie kategorijas,bet neglabājas tabulā 'sections',tad kategoriju tabulas laukā ir uzdots 'subtable' kā alternatīvā tabula,no kuras lasīt datus ja tāda ir uzdota(ja lauks nav tukšs).Lai nebūtu jātaisa atsevišķs pieprasījums,tad mēģinu iedabūt kverijā if/else pārbaudi.Tas ko gribētu panākt būtu apmēram šādi: IF (c.subtable NOT NULL) LEFT JOIN c.subtable AS s ELSE LEFT JOIN sections AS s ENDIF Bet tā kā nav pieredzes ar šāda veida konstrukcijām,tad mēģinot visādi izdevās panākt vienīgi sintakses kļūdu.Kā būtu pareizi būvēt šādu nosacījumu?

Manuprāt daudz ērtāka un efektīgāka apstrāde tik mazam info daudzumam būtu glabāt to failā vai nu rindās- 1 rinda - 1 elements + \n,un tad ar file() dabūt un apstrādāt masīvu,vai arī vienkārši visu glabāt vienā rindā,un atdalīt ar kādu delimiteri.Piemēram: | Attiecīgi file_get_contents + explode,un viss notiek bez liekiem sarežģījumiem :).Vienīgi trūkums ir tas,ka mainot faila saturu(dzēšot vai mainot elementus),jāmaina arī tā apstrādes noteikumi,kas visai ātri var kļūt apgrūtinoši,un gribēsies relāciju datu bāzes iespējas.

Vēl viens variants-vienkārši neizvadīt pēdējo vārdu,un neuztraucoties kaut vai ar substr griezt.Kaut kā šādi varbūt der: $vaardi = explode(' ',$saisinatais_teksts); $pedejais = end($vaardi); unset($vaardi[key($vaardi)]); echo implode(' ',$vaardi).'...';

Var izmantot MySQL piedāvāto AVG funkciju vidējā reitinga izrēķināšanai.

Vēl jau nevienam šķiet faili nav zaudēti.Vismaz vācot prom paziņas lapu,cpanelis un PhpMyadmin šodien strādāja.

Izskatās ka curl nepatīk uzstādījumi.Man līdzīgu problēmu izdevās atrisināt izvācot CURLOPT_URL,un uzdodot hosta adresi jau uzreiz pie inicializācijas: $ch = curl_init($url); Un vēl pašam ir nācies sastapties ar tādu lietu,ka CURLOPT_USERAGENT uzstādīšana pirms CURLOPT_RETURNTRANSFER izraisa Bad Request.Pamēģini ko saka šādi: CURLOPT_HEADER, 1 CURLOPT_AUTOREFERER, 1 CURLOPT_FOLLOWLOCATION, 1 CURLOPT_TIMEOUT, 10 CURLOPT_RETURNTRANSFER, true CURLOPT_USERAGENT

Kritizē ikvienu,kas kaut ko dara,tikai tā nav tāda kritika,kā Tev liekas.Šis ir pieredzes apmaiņas forums,kurā vienmēr padalās ar zināšanām,norādot uz kļūdām,bet pašam ir kaut kas vismaz minimāli jāzin,lai viņas varētu ņemt vērā un atrisināt.Visas problēmas savulaik katrs pirmoreiz ir risinājis mācoties,lasot un neskaitāmas reizes mēģinot,kamēr sanāk.Un Tu pat nevari iedomāties,kā ir visiem apnicis ikdienā lasīt ko šādu: Un tad seko nosūtījums uz Google,vai Darba sadaļu :) Ja neviens nevēlētos palīdzēt,tad šajā topikā nebūtu 3 lappuses ar 33 komentāriem.Pats pat paspēju ko jaunu par IE niansēm iemācīties pa šo laiku,ko vispār nezināju.Tā ka viss atkarīgs no uztveres un vēlēšanās darīt :)

Nu jā-nevajadzīgi nosvētīju nabaga pārlūku :D Vaina būs citur.Uzmetu intereses pēc sourci patestēt.Objektu arī tagad izveido,bet IE diez ko nedraudzējas ar innerHTML.Šo vietu: var ajaxDisplay = document.getElementById(name); ajaxDisplay.innerHTML = ajaxRequest.responseText; pamaini uz: var ajaxDisplay = document.getElementById(name); ajaxDisplay.options[0].text = ajaxRequest.responseText; No versijas no 5.01 uz augšu šādi man strādā.Un html daļu pie reizes ar palabot prasās. Vismaz noslēdzošos tagus un disabled="true" uz disabled="disabled" :)

Savukārt manam variantam piepalīdzēs ar pamatojumu šis: http://www.fotiweb.com/2009/11/19/cross-browser-xmlhttprequest/ balstoties uz to,ka pats Microsoft savulaik rekomendēja darbinot aplikācijas nočekot kā minimums vismaz 6.0 un 3.0 xml versijas: http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx peace :)

Nu mans iepostētais nekā nerubīšanas paraugs ir stipri līdzīgs šai rekomendācijai un paša skriptos izmantots.Tā kā gāja bez problēmām,tad neredzēju pamatu apstrīdēt.Yahoo ar tas pats piegājiens: http://infinitezest.com/articles/xmlhttprequest-and-ajax-on-yahoo.aspx bet ja 2easy saka,ka viss rullē tāpat,tad jau būs vien jātic :)

IE slaidi uzspļauj jebkādiem standartiem,un ar katru versiju dara kā vēlas,attiecīgi pieprasot ActiveXObject izsaukt savādāk.Pamēģini to vietu paplašināt šādi : catch(e) { var ieXmlHttpVersions = new Array(); ieXmlHttpVersions[ieXmlHttpVersions.length] = "MSXML2.XMLHttp.7.0"; ieXmlHttpVersions[ieXmlHttpVersions.length] = "MSXML2.XMLHttp.6.0"; ieXmlHttpVersions[ieXmlHttpVersions.length] = "MSXML2.XMLHttp.5.0"; ieXmlHttpVersions[ieXmlHttpVersions.length] = "MSXML2.XMLHttp.4.0"; ieXmlHttpVersions[ieXmlHttpVersions.length] = "MSXML2.XMLHttp.3.0"; ieXmlHttpVersions[ieXmlHttpVersions.length] = "MSXML2.XMLHttp"; ieXmlHttpVersions[ieXmlHttpVersions.length] = "Microsoft.XMLHttp"; var i; for (i=0; i < ieXmlHttpVersions.length; i++) { try { var xmlhttp = new ActiveXObject(ieXmlHttpVersions[i]); break; } catch (err2) { alert(ieXmlHttpVersions[i] + " not supported."); } } }

Man arī šobrīd šī lieta ir aktuāla.Uzrakstīts ir stipri līdzīgi Grey_Wolf aprakstītajam variantam.Manuprāt ļoti ērts risinājums-valodas glabāt ne tikai katru savā 1 failā,bet atvēlēt viņām savu folderi(lv,eng,ru u.t.t),kuros glabāt vairākus txt failus ar frāzēm,kuras ir atbilstošas tekošajiem failiem.Tad tikai atliek no sesijas vai settingiem nolasīt valodas kodu,un izsaukt: if(file_exists(site_path.'/languages/'.$language.'/'.$template.'.php')) include 'languages/'.$language.'/'.$template.'.php'; Bet tas ko gribēju pie reizes uzjautāt,kā būtu labāk glabāt "lielos" sadaļu datus,kurus nebūtu prāta darbs stūķēt masīvos.Saitā jau katrai lappusei jau ir arī intro,content,un cits info,kas tiek lasīts no datubāzes.Kāds būtu optimālākais variants mysql pusē? * Taisīt katrai valodai savu tabulu ar valodu prefiksiem nosaukumā? * Glabāt tajās pašās,bet dublēt kolonnas: lv_content,eng_content u.t.t? * Katrai valodai vispār savu db? * Varbūt lielo kontentu arī pa folderiem vienkārši iemest vienā .txt failā un kā include? Kādi vēl varētu būt varianti? Realizējami būtu visi,bet negribētos uzrauties uz kaut ko neizdomātu,kas baigi varētu vēlāk iegriezt :)