F3llony

Var iztikt arī ar kaut ko šādu. // $salt glabājams kopā ar paroli DB. Salt ir katram lietotājam unikāls. $multi = 23479.32454522499345; $salt = base_convert(mt_rand(mt_rand(1111,9999),mt_getrandmax())*$multi,10,16); $k = sha1($salt); $t = 'Manaparole'; $buffer = null; for($i=0;$i<strlen($t);) { for($ii=0;$ii<strlen($k);$ii++,$i++) { $buffer .= ($t{$i} ^ $k{$ii}) . ((int)$t{$i} ^ (int)$k{$ii}); } } $p = hash('sha256',($k.$buffer.$salt)); echo ($k.$buffer.$salt) . ' - ' .$p; Parasti, lielākā daļa defeisu kompromitē pašu datu bāzi. Šāds neliels scenārijs var palīdzēt pret defeisotām DB, kur nav zināms šifrēšanas algoritms. Bonusam, pašam algoritmam var pielietot piemēram, http://pecl.php.net/package/bcompiler

http://freemind.sourceforge.net/wiki/index.php/Main_Page Ērtai maindmapošanai http://www.modelio.org/downloads/download-modelio.html UML

Paga paga, es teicu, ka LV gov projekti nav lieli, Tu teici, ka ir. Es prasīju, lai parādi vienu un Tu man prasi lai es definēju lielizmēra projektu lai Tu to varētu man piemeklēt? Are you being serious? Nu ja jau bez tā nevar, piemeklē man LV gov projektu, kura izstrādei (loģiski, ka sīki labojumi pēc publikācijas neskaitās, tā pat, kā saskaņošana un vispārēja plānošana) līdz pašreizējam stāvokli būtu patērētas vairāk kā 30k programmētāju darba stundas. Lai rastos asociācijas, tas ir aptuveni tik daudz, cik vidēja 10 cilvēku komanda izdara 18 mēnešu laikā. Aprēķinā pieņemam, ka devi nesēž un tupa neurbina degunu, un projektā piedalās tikai staffs ar vismaz 2-5 gadu pieredzi. Jeb man vēl precīzāk Tev definēt?

Nosauc vienu, i dare You to.

Vai šo topiku, kurš in general no neauglīgas diskusijas par Py VS PHP ir pāraudzis pirksta zīšanā par globālām problēmām sētā sēdošu vecmāmiņu līmenī nebūtu laiks beigt? Nu, kaut kas labāk palika, ka izspļāvām pa pāris demagoģiskām atklāsmēm interwebā? Tika uzlabota vispārējā weba kvalitāte? Produktivitāte? Kāds beidzot ir izgudrojis kādu universālu super-code re-usability tipu? ir izstrādātas kādas labas web development vadlīnijas, kuras arī realitātē varētu piemērot? Nē? Tad par ko runājam? Šī diskusija ir bezjēdzīga. Tāpat šajā topikā atzīmējušies tikai pāris cilvēki, kas vispār saprot koda kvalitātes jēgu un kas tas tāds lielapjoma projekts vispār ir. Nē, tavs wordpress štancētais blogs pilnīgi noteikti nav nekāds lielapjoma. Un arī valsts pasūtījumi nav lielapjoma, vismaz Latvijā ne. Tad par ko galu galā ir šī diskusija, un kapēc tā vietā lai tukši routētu vakardienas kāpostu tīteņu gāzes pret vēju nekas netiek darīts lai topikā minētās problēmas atrisinātu realitātē, ne lokālo programmēšanas superstāru slapjajos sapnīšos? /thread Sēnes ta kā, bija vismaz garšīgas? Padalīsies ar recepti? Un kādā veidā tā bļ būtu valodas problēma, Grēvi? Ja es paņemšu ar cirvi sadauzītu Audi un nolikšu blakus tikko no rūpnīcas izstumtam Opelim, tad Audi būs vainīgs pie tā, ka īpašnieks ir idiots? Lūk tev samplis, mister lasāmība: while(true) { // code } un while true: fail un while true fail end ?!!!1111

EU cepumu "likums" patiesībā ir direktīva, kas Latvijā vēl tikai jānostiprina kā likums. Līdz tam brīdim, kad LV tiks apstiprināta likumu paka par EU direktīvas ieviešanu, EU direktīva par cepumiem LV kompānijām nav saistoša. Tas pats attiecas uz visām citām dalībvalstīm, kurās cookie law nav apstiptināts. Par to, vai šī direktīva netiks nostopēta dalībvalstu valdībās vēl jāskatās, tapēc nevajag strebt karstu.

1. stage - funkcionālā dokumentācija. Puses satiekas un vienojas par pilnīgu, sīkumainu funkcionālo pusi, kādas opcijas, līdz vismazākajiem sīkumiem. Pat tādiem, kas pirmajā brīdī liekas maznozīmīgi, piemēram, kāda būs lietotāju reģistrācija, ja ar sociālajiem servisiem- kādiem, kādi lauki būs kontaktu formā utt. Tas aizņems daudz laika, bet tas ir vitāli nepieciešams tev izdarīt, tevis paša drošībai. 2. stage - tad, kad panākta abpusēja vienošanās par funkcionalitāti, tiek izstrādāts dizaina koncepts - no pasūtītāja puses tiek paņemts viss nepieciešamais dizaina izveidei, logo materiāli, lapas materiāli (ja ir) utt, kaut kādas pamata idejas. 3. stage - Galējais dizaina koncepts un funkcionālā dokumentācija tiek saskaņota ar klientu, tiek uztaisīta tāme. 3a. stage - ja klients vēlas dizaina koncepta vietā redzēt gatavu dizainu, tad par to vienojas atsevišķi, lai nesanāk tā, ka klients izvazā dizaineri aiz deguna un beigās neko nesamaksā. Līgums šajā gadījumā arī ir nepieciešams, tā pat viss arī jāsaskaņo. 4. Klients parasti nekad nenosaka lapas galējo dizainu, lapas dizainu nosaka dizaineris. Klientam pirms šī stage jau ir skaidri un gaiši jāpasaka - ar dizaina izstrādi nodarbojas dizaineris, kurš zina, ko dara. Arguments par šefa meitu, kas studē dizainu un "saprot labāk" nav arguments. Ar tādiem klientiem tu pilnīgi noteikti nevēlies nemaz turpināt strādāt un tici man - galvas sāpes, nervi un laiks būs iztērēts vairāk, kā nopelnīsi. Cilvēki web studijās griežas tikai tapēc, ka paši neprot veidot kvalitatīvas mājas lapas. Klientu rekomendācijas ir jāņem vērā, bet pakaļlekšana nedrīkst būt. Princips tas pats, kas pie zobārsta - tev tiek dotas opcijas, kādu plombu likt, bet ielikšana vienalga paliek zobārsta kompetencē. Šis punkts klientam maigi un profesionāli jāieskaidro jau pašā komunikācijas sākumā. Lielākā daļa saprot un problēmas pēc tam, kad ir noskaidrots, kas ir kas nerodas. Savukārt tie, kas var radīt problēmas izpildītājam pēc šī punkta vienkārši nozudīs. Un labi vien ir. 5. Ja klients piekrīt izmaksām, tiek noslēgts līgums par pakalpojuma sniegšanu, kurā tiek norādīts uz funkcionālo dokumentāciju, dizaina konceptu (dizainu) un tāmi. Tiek norādīts, ka klients pilnībā piekrīt dokumentācijai, dizainam un tāmei. Pie tam, noteikti jānorāda, ka projekta gaitā nepieciešamās "novirzes" no sākotnējā plāna nedrīkst pārsniegt, kā nu kuram, no 10-20 darba stundām. Ja vairāk - līguma papildinājums, atsevišķa samaksa. 6. Pakalpojuma sniedzējs izpilda darbu, nodod lapu tā, kā atrakstīts dokumentācijā. Rekomendācijas no pieredzes - 1. Visa sarakste un visas vienošanās ar klientu tikai un vienīgi rakstiski, kaut vai epastā. Bez izņēmumiem. 2. Atrodi normālu juristu, kas uztaisīs tev vairāk vai mazāk universālu līgumu šim pasākumam un paskaidros, kas ir kas. Bez kaut vai nelielām juridiskām zināšanām par to, kas un kapēc jānorāda līgumā var iekūlties pamatīgos mēslos. 3. Līgumā vienmēr jānorāda, kura ir par projektu atbildīgā persona no pasūtītāja puses un ka visa projekta virzība tiek organizēta tikai ar šo cilvēku. Tu strādā tikai ar šo cilvēku, vienalga vai pēc tam uzrodas boss nr 2. vai bosa sieva. Bez izņēmumiem. 3. Nesāc darīt, pirms esi saņēmis kaut kādu naudisku iemaksu. Nopietns klients nekad neatteiksies iemaksāt kompānijai vai cilvēkam kaut kādu naudu lai bīdītu nopietnu projektu. Ir skaidri jānosaka- klients veic tādus un tādus maksājumus tādos un tādos posmos. 4. Naudas lietas - tikai ar pārskaitījumu. Ja neesi reģistrēts kā nodokļu maksātājs, tu esi duraks - get out un visu iepriekš minēto ignorē, tas uz tevi vienkārši neattiecas. 5. Izpildes termiņus nosaki plānotais laiks +20-25% rezerve. Līgumā norādi, ka plānotais izpildes laiks var atšķirties no reālā neparedzētu un neparedzamu tehnisku sarežģījumu dēļ. 6. Līgumā jāatrunā, ka izstrādātā lapa izmantos tehnoloģijas A, B, C, D. e.g. prasības serverim, uz kura tiks turēta lapa nosaka izpildītājs. Humoram, bija reāls gadījums, kad cilvēks PHP rakstītu lapu prasija pārrakstīt ASPā, jo lūk viņam esot Windows Server kaste un vēl kas tik tur ne. Ja līgumā nebūtu bijis punkts par servera prasībām, būtu baigie mēsli. Un visbeidzot, klienti nav monstri. Normāli runājot un normāli argumentējot parasti neviens pa muti nesit un naudu atpakaļ neprasa. :)

Routēšana mazliet influencēta no CI, vai ne? :) Nu mkey, rekomendācijas priekšdienām- - Kā jau biedrs codez teica, modularitāte uber allez. Turēt trīs mapes MVC un visus viewus, ctrlrs un modeļus mest vienā maisā ir dumbfckingshit, pat ar apakšdirektorijām. It īpaši tad, ja IDE'ē jākursē caur failu koku un tad "kur nu tas fails bija". Un ne tikai - moduļi ir savstarpēji vienkāršāk menedžējami. Module reusing is what you want. Pie tam, ja man vienam kontrolierim būs vairāki modeļi - katrs savam db draiverim? Ko tad? - Instalācija ir fail. Freimworkus neinstalē. No exceptions. /argument - Viena fiksēta db ir fail - ko man tagad darīt ar tavu freimu, ja es vēlos postgre? PDO? ODBC? Piekasīties piekasīšanās pēc varētu par koda stilu. Piemēram par kļūdu supresoriem - @. Izvairies no jamiem. Jo mazāk kļūdu supresijas jo labāk. Vienīgais, kas iekrita acīs ir SQLquery klase. Kuras eksistence ir bezjēdzīga. Iedvesmai aplūko DB abstrakcijas - PDO, ODBC, dbFacile. You can make use of it. Turpini. Esmu skeptisks un diez vai tev sanāks kaut kas priekš masām, bet šis varētu būt lielisks veids lai iepazītu PHP zem pārsega, e.g. zemāk par vidējo virspusējo php.lv foruma pilsoni. ;)

http://www.jcxsoftware.com/vs.php In the other news: Visi šitie, "argh" PHP nav Python sintakse un Python nav C sintakse un C nav saderīgs ar asm un un un un un un un... ir bullšit. Divām dažādām valodām nav jābūt vienai un tai pašai sintaksei. Sintaksēm nav jābūt pat līdzīgām. Arī funkcionalitātei nav jāsakrīt. Un ja tev, kas šo lasa, ir problēmas ar kādas citas valodas izpratni tajā pašā laikā izprotot kaut ko citu, tā ir tikai tava apdalītā prāta problēma. Tās ir divas dažādas valodas, ne valoda a un a valodas kopija. Get out. Leave us alone. Es izmantoju gan PHP, gan Py, gan (jā, man kauns, bet) savu reizi ASP, gan Go, gan Haxe un vēl veselu kaudzi ar valodām. Nu kapēc es nestaigāju pa šo valodu forumiem reidžojot, kapēc A ir labāks par B un kapēc A ir sliktāks par C. Tapēc, mani mazie draudziņi, ka katrai valodai ir savs mērķis. Ja tu feilo saskatīt, ka katra valoda izmantojama pie noteiktām prasībām un noteiktiem mērķiem, tu esi ļimps, tavas aplikācijas pilnīgi noteikti sūkā un pazūdi no mana interneta. Fanboji šmanboji.

Vispār jau zema līmeņa apstrāde atmaksāsies arī pie 5 ierakstiem pa 100B. Vienkārši pēc 5milj ierakstu uz vidējas "normālas" kastes, kas gan ir mans subjektīvais aprēķins, PHP kļūst tik neefektīvs, ka to vairs nav saprātīgi lietot, jo php vienkārši nav paradzēts šādiem darbiem - nepieciešamie resursi uzdevuma izpildei pārsniedz labumu, kas iegūstams no uzdevuma izpildes. Atmiņas wasteland, cpu laika lietojums un such. Pie tam grūtāk nolasīt failu pa blokiem un tādējādi taupīt atmiņu. Miljons un viens iemesls. Ja ir nevēlme ņemties ar C/c++, tik pat labi var izmantot arī mono vai vēl labāk- Go, kas ar šo darbu tiks galā vairāk kā lieliski, no paša pieredzes.

APC/Memcache/Couchbase/Xcache/Wincache. Ja 35K selects no 2 tabulām ilgst >2s, tad jādomā par 1. Dzelžu upgreidu. Steidzami. 2. Datu kešošanu. Sekundāri. 3. Indeksi salikti korekti?

Bottleneck šeit būs nevis XML bet gan 50-100k kveriji uz katru XML'u, kas ievietojams preču datu bāzē :> Batch insert vai arī PHP konversija no XML uz CSV un ielāde ar LOAD DATA INFILE. Ja XML'ā vairāk kā 5-7m ierakstu, raksti geitveju vai batchprocesoru C vai kādā citā zema līmeņa valodā. daGrēvi, Pitons par PHP "ašāks un veiklāks" bija varbūt kaut kur ap 2005. gadu :>

gay on rails

Inb4 rage, šeit manuprāt viss ir skaidri pateikts- http://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.html#more Un jautājums mazliet off-topic: nakuj visi šitie python (lai arī cik laba valoda tā nebūtu) un citu valodu gandrīz vai idiotiski reliģiska līmeņa fanāti nāk, es atvainojos, PHP.LV forumā un mēslo savu ticību augstākiem spēkiem kā argumentus minot kaut kādas mītiskas priekšrocības? Pitons ierindas web projektiem nav un nekad nebūs labāks par PHP. Punkts. Ir jābūt tērētam lai argumentētu pretējo. Django nav pretinieku? What is this? Cake, Yii, symphony? Nope? (CI nepieminu ar domu- old and valid no more. Kohana centās, bet izskatās, ka ne visai sanāk). Nemec var turpināt argumentēt ar putām uz lūpām, cik čūsks ir labs un incredible, un awesome, un magical un un un un un.. krkrrkrhhhghhghh... Hello Mr Jobs. Tikai vispirms padomā, jo kāds varētu sākt iedomāties Py un Django salīdzināt ar Go un citiem new age projektiem. Diez ko tu teiksi tādā gadījumā. Ak jā, runājot par Py, v2 un v3 - kā patīk lielā migrācija? :* Manī kaut kā bija radusies cerība, ka deveropeļeļi šeit ir izauguši pāri holy-war līmenim, par to, kura valoda labāka vai sliktāka, vai vēl kāda un beidzot sapratuši, ka katrai valodai ir savs mērķis. PHP ir ierindas aplikāciju izveide, ātrs deploy un med. size projekti. Py darbojas citos laukos. Node darbojas vēl kaut kur citur. C++ lapas vispār ir labi talu no visa šī cirka. Man the fuck up.

Es atvainojos, man ir tikai mana taisnība- manējā? Vai arī jums cienītie ir tikai sava taisnība- jūsējā? Transkriptam, un lai konkretizētu, kas šajā topikā ir nepareizi- 1. Devos uz IRC. Atradu random devu čanu, pilns ar ārzemniekiem. 2. Jautājums- vai labi veidotam, verbālam kodam nepieciešami bloku komentāri un tipu hintošana jdoc/pphpdoc formā un inline koda komentāri vai arī labāk izvēlēties ārēju izstrādātāja dokumentāciju? 3. Atbilde- atkarībā no konteksta. phpdoc/jdoc/xmldoc ir evil. Komentāri ir vēlami tikai sarežģītām struktūrām, kā grupēts regex, utml. Koda bloatošana ar bloku komentāriem ir evil. 4. Paldies par diskusiju. Kad Latvieši vienreiz iemācīsies, ka ES NERAKSTU CAPSLOCK UN NEBAUROJU BET AIZSTĀVU SAVU VIEDOKLI gaidot kādu labi argumentētu pamatojumu jo man nepatīk kapitulēt pie katra apgalvojuma bez pamatojuma kapēc mans viedoklis būtu nepareizs. Te nav nekāda strīda. You guys sometimes are everything that's wrong with this planet. /thread

Nav arguments. Ja tu nesaproti "why" pirms payload ir galvenes, tu pats saproti, ko tas nozīmē. Neskaidrībām ir dokumentācija. Vēl joprojām nepamato komentāru nepieciešamību KODĀ. >>Labāk pastāsti kāpēc kods nav jākomentē. http://eu5.memecdn.c...Logic_c_995.jpg Tu sāksi strādāt pie mana koda un sāksi to lasīt? Kapēc gan neizlasīt manuāli, referenci un paskaidrojumus? Papildus jautājums: cik no jums, augsti godātie, mācoties PHP lasīja PHP dzinēja izejas kodu :D Godīgi? :D

Tas vienalga neizskaidro komentāru jēgu. Gribētu pamatojumu "šmucei", kura tad varētu sanākt rakstot kvalitatīvu, pašpaskaidrojošu kodu ar labu metožu un mainīgo nosaukšanu ar labu atdalītu dokumentāciju.

> Kods ir jākomentē un komentāri nav jāvāc ārā. Argumenti? Bez visādiem tur "to rekomendē iso", "reliģiskā pārliecība", "lai ide programmētu manā vietā", "automātiskas dokumentācijas ģenerēšanai", "es to izlasīju kāda vadošā Web 3.0, seo, sem, gem, lem, shmem eksperta blogā" utml. brīnumiem.

Visual studio C# express un C# valodu. Jama ir izcili piemērota tādiem darbiem. Var domāt arī par Python un tml. skriptēšanas valodām.

Būtu jau labi, ja tas būtu uz C api veidots extenšens ne PHP klienta puses bibliotēka.

Wrapperus neizmanto ātrdarbības uzlabošanai. Tos lieto lai iegūtu papildus funkcionalitāti, šajā gadījumā- neatkarību no platformas aplikācijas līmenī un iespēju vienkārši distributēt saturu izmantojot dažādus servisus. Bet tas nenozīmē, ka wrapperi arī drīkst uzreiz nobloatot. Man jau FS cache ir kā dadzis acī, kuru slīpēt vien gribas.

Jau no laika gala visu kodu formatēju Whitesmiths stilā. Kaut kā vairāk iet pie sirds, ja kādam ir interese. Par komentāriem, man ir tāda šizo ideja jamos nolikvidēt pa visam un uzrakstīt normālu dokumentāciju. Piemēram, savu kodu kuru lietoju pamatā es, es vispār nekomentēju. Nepatīk man jamie. Par ceļiem piekrītu briedim, pilnie ceļi ir way to go.

Nopietni? Alfa steidžā? Kas tad tie par jaunumiem? Kopš kura laika tad spl autoload reģistrs un __autoload kļuvuši ātrāki/labāki par require? Tāpēc, ka errorus liku piektdienā pēc 22. Nu tu saproti. ^^ Būs. Edit: Eksepšani vietā, kļūdu kodi sarakstīti. Viss līdz šim minētais ieviests. Moar?

Jā, tas ir trūkums, kuru kaut kā palaidu garām. Piezīmēju, būs ar nākamo komitu. Par komentāriem- Perl stila komentāri, cik man zināms, nav deprecated. Personiski man tie patīk vairāk, kā // un /**/. Par javadoc stila komentāriem - nekad. :) Normālas ides parasti dod koda ieteikumus neatkarīgi no komentāriem, ja nu vienīgi tev nepieciešams priekšā teikt tipu un aprakstus rādīt. Ko es uzskatu par koda bloatošanu, kur kods mazāk, kā komentāri. Tas gan ir gaumes jautājums. Komentāri pagaidām paliks kā ir.

Idejas, ieteikumi? https://github.com/f3llony/x0Cache Pie reizes, varbūt kāds zina kas ar phpredis? Jams ir miris? Izskatās, ka issues vairs neviens nelabo.