F3llony

Nu un? Mums tagad uzskaitīt visus, kas kaut ko ir panākuši bez augstākās? Vai arī visus, kas ir nofeilojuši ar visu augstāko?

+3.14159265359

Līmenis bija adekvāts kickstartam, kas arī bija mērķis. Es nevērtēju pēc tā, ko tu zini vai vari tajā brīdī, bet pēc tā, ko tu varēsi pēc gada. :) @yancis es šaubos vai tā prakse tur vairs tiek piekopta...

Es domāju, ka konkrētās prasības ir tik minimālas, ka izpildīt var jebkurš freimworks. Symfony, Yii, Cake, CI, Phalcon. Izvēlies, kurš pašam tīk.

Nu labi, tik truls jams arī neliekas...

Vispirms jau, nice1 neesmu es. Es neieteicu to rakstīt PHP. Un zinot nice1, es domāju, ka tas bija pārākais sarkasms. Tālāk, "nevarētu uzrakstīt PHP, JS, Javā vai C# 3-4 stundās" tieši tā arī ir domāts. Mans arguments ir, varēt jau var, bet vai vajag? Tu aicini salīdzināt vienu un to pašu darbu implementāciju N dažādās valodās - Skalā, kas ir mainline valoda un PHP, kas ir paredzēta webiem. Kaut ko var vienmēr izdarīt ar kaut ko. Nu var jau uzrakstīt to scrapperi arī visual basic. Paskalā var. For f sake, arī hardwariski gan jau to varētu izdarīt. Bet tad ņemt un salīdzināt rezultātus? Pēc kāda kritērija īsti to darīt?

Tu atkal palaid garām galveno domu visā šajā argumentā - nesalīdzināt nesalīdzināmas lietas. Normāli un adekvāti programmētāji (ne codez t.i.) izvēlas instrumentus pēc dotā uzdevuma, nevis pielāgo uzdevumu savam mīļākajam instrumentam. Problēma ar Scala vismaz man ir, ka es vēl neesmu redzējis nevienu iemeslu vai reālu argument kāpēc tā būtu tuvu vai pāraka tām valodām, ko zinu un izmantoju, izņemot jau zināmos code church reliģiskos argumentus, kur konstrukcija X ir labāka par konstrukciju Y because i believe so.

Tev par daudz šķiet. Pieņemot, ka "brēcēji" to pašu sen jau nav darījuši like 50 miles pirms tevis... Tavā pieejā nav nekā unikāla, noderīga vai inovatīva. Piedod. Ja tu man samaksāsi par iztērēto laiku, okei. :D Tīri tāpēc, lai kādam kaut ko pierādītu internetā, pff, cmoon, even I amm too old for that shit... Vot šis arguments ir lielisks. Uzrakstīsim Android spēli PHP un Skalā, un salīdzināsim instrumentus. Tu esi tik ļoti pārņemts ar kaut kā pierādīšanu, ka esi piemirsis padomāt par "vai vajag". Pusi no šī teksta es vispār nesapratu. Es pieņemu, ka līdzīgi kā dotajā Github repā kā avots simboliem šeit tika izmantots PRNG. Es varētu uzdrukāt probably 30 postus par šo vienu, bet es apšaubu, vai Tu sapratīsi. Gribi manu risinājumu tavai problēmai? Okei. Pavadi 10 minūtes ar galvu ledusskapī apsverot kādus instrumentus var izmantot šīs problēmas risinājumam, ne "OMG ES TAGAD VISU DARĪŠU SCALA" tipa reidžā. Uzstutē Noodlejs vai labākajā gadījumā, PhantomJS serveri. Mums ir infinetly skeilojams, modulārs, multipurpose risinājums web scrappingam, x100000 labāks, kā Tavs. Iztērētais laiks varbūt 20 minūtes. Uzstutē dajebkādu klienta interfeisu. Dajebkādā valodā. Two way komunikācija ar scrapperi, varbūt MQ. Rezultātus pieglabā DB. Done. Iztērētais laiks 3-4 stundas. Drink coffee. Enjoy MaxVP.

Man lēnām pamazām rodas aizdomas, ka tie drīzāk varētu būt kādi 27 gadi...

Un tas ir viss? Tādā gadījumā mans pretjautājums - ko tieši no šī visa es nevarētu uzrakstīt PHP, JS, Javā vai C# 3-4 stundās?

Imagined problems requires imagined solutions...

There is only one Sort key, and Partition key is her prophet. Akbaru Kebab.

Okei, mazināsies slodze uz bāzi, bet tai pat laikā palielināsies slodze uz web. Order by rand nav labākais risinājums, bet tas noteikti ir labāks par tevis ieteikto datu ielasi webā jo rodas overheed uz datu pārraidi, glabāšanu un sinhronizāciju jo svara parametrs šeit loģiski būtu bidirekcionāls. Tālāk, tavs keiss diez vai būs šeit vietā, jo OP'am ir konkrētas prasības - vajag atrādīt nejaušus rezultātus reallaikā kārtojot pēc svara un nejaušības. Pati prasība šeit ierobežo iespēju. Tavā gadījumā tu vari atļauties kešot kaut kādus rezultātus, šeit ir random read un update, kas nav gluži kešojams pasākums jau pēc definīcijas. Tālāk, man loģika liek domāt, ka ziedinjsh neturēs tur 10m ierakstus un nebūs viņam 1000rpm. Tādējādi vienkāršākais risinājums derēs. Risinājums kas skeilotos konkrētajai problēmai ir agregators, kas saņem datus par skatījumiem, agreģē svaru un veido rādījumu rotācijas rindu (queue) no kuras ar katru pieprasījumu izvelk vienu rezultātu un paceļ nākamo rindā augstāk (FIFO, weighted queue, sauc kā gribi). Es pašlaik strādāju ar projektu, kur fizisko serveru skaits tuvojas pusotram tūkstotim. Pie tavas pieejas, random read no datubāzes būs mazākā no problēmām jo suddenly viss RAM būs aizsists ar memcached agreģētiem un replicētiem datiem un core switchi pakārsies šķūnī jo sinhronizācijas flūds būs diezgan nenormāls (atceries - real time read/update, un konsistenti).

Tu saproti, ka PHP skripti tiek izpildīti uz katru pieprasījumu no jauna? Tātad, katru reizi kad es atveru lapu tu man atnes nevis glāzi ūdens bet 10 litrus ūdens? Kāda velna pēc? Nu labi, nokešosi memcache vai vēl kaut kur tikai lai iegrūstu to tabulu pāris reizes atmiņā. Kas no tā mainīsies? Ātrāk tas toč nepaliks. Nepiemirsti, ka keši ir arī jāvalidē un jāatjauno, un ja vien tev pa ceļam nav disk backed patstāvīga memory db, kā piemēram couchbase, tad jēga no tā keša maza, jo visu tavu kešoto tabulu nāksies turēt vai nu apcu, vai nu memcached un abos gadījumos izmantojot proxy validator. Labi, tā pat nebūtu problēma, bet kāda velna pēc tad visu vēl vilkt katra pieprasījuma procesa atmiņā es toč nesaprotu? Tad jau labāk ievelc tai memcached vai kur nu, uzliec maping keys un pieglabā daudzumu zem citas atslēgas, tad mt_rand un saņem savu rand. Tikai kā tu atrisināsi problēmu ar svaru? Nu labi, pievienojam vēl vienu cache key lai to pieglabātu. Aiziet tavs memcached pie tēviem un protams tu pazaudē svaru visiem rakstiem vai arī raksti dīvainu rutīnu svaru pieglabāt db. Un pēc tam tu paskaties uz to monstru, ko esi radījis un lūdzies apustuļiem lai atpestī tevi no grēka ar svēto rm / -rf | yes Īsāk sakot, tava optimizācija nav optimizācija. Figņa.

Леший, katru reizi... Emmm, tu taču saproti, ka PHP ir process-per-request? Tālāk, kāds labums tieši ir no tā, ka tu ielasi visus datus aplikācijā no DB un pārcel darbu no DB uz aplikāciju? Ņemot vērā overheed uz datu izlasi un padevi uz app. 1. preoptimizācija ir way worse. 2. Ja tik ļoti gribi optimizēt, RAND() * MAX(ID)

Thumbs up puisim! Grābiet ciet. :)

Tabulā pievieno kolonnu weight. Pie katra rādījuma konkrētā ieraksta weight paaugstini par 1. Tālāk select * from answers where status='1' order by weight ASC, rand() limit 1

Freimworkā?! Saglabā failu->piesaka MQ tasku->atgriež steitu aploading. MQ tālāk ir consumer, kas ar to nodarbojas.

Kāds sakars ar to, kādā valodā vai platformā? Asinhrons ir un paliek asinhrons - nemaina tas neko, vai tev prefetch un statusu callback ir realizēts PHP, Javā, Skalā, Nodē vai vienalga kādā valodā un freimworkā - tas, ka Skala ir "asinhrona", problēmu neatrisina. Un MQ netiek lietots tikai tāpēc, ka PHP nebūtu thredu vai forku. Also, C# arī ir async modelis. OMG OMG taisam visu dotnetā. Codez random words. Korelācija starp tavu komentāru un manu komentāru ir nulle. Un es neesmu vainīgs, ka tavs freimworks šmeimworks neprot ar to tikt galā by default. Man tas viss izskatās šādi (cdn gadījumā, ar visu async virtuvi): <?php if ($file->uploaded()) { $file->set_destination('fs|cdn|whatever'); $file->set_access_policy(FileStore::POLICY_PUBLIC); // vai $file->set_owner(FileStore::OWNER_CURRENT_USER); $file->set_access_policy(FileStore::POLICY_OWNER); // vai $file->set_owner(FileStore::OWNER_CURRENT_USER); $file->set_access_policy(FileStore::POLICY_OWNER_GROUP); // vai $file->set_owner(FileStore::OWNER_USER_GROUP); $file->set_access_policy(FileStore::POLICY_OWNER); // vai $file->set_access_policy('custom'); $file->store(); } Viss. Fails tur, kur vajag, vienalga, CDN, failu sistēma, velns zina kas. Katram storage punktam ir jau gatavas procedūras, ACL implementēts kodolā, viss konfigurējams kā vien ienāk prātā, $file->getUrl() atdod publisku URL, kas ir proxy, kas pārbauda permisijas, liek headerus proxy cache, paraksta redirektus uz CDN ja vajag un dara visu pārējo. Policy var būt jebkas - privāts, PUBLIC, 'custom' profils definēts konfigā. And again, vienalga, vai tā ir skala vai php, labs risinājums un slikts risinājums tipu nemaina atkarībā no platformas. Tu jauc CDN un block/file/object storage. CDN, ja esi piemirsis, ir Content Delivery/Distribution Network, kur viena no primārajām iezīmēm ir nogādāt kontentu tuvāk lietotājam izdalot saturu edge nodēs. Šajā gadījumā diez vai tie pāris simti lietotāju ir pa 10 valstīm un dublēt saturu edgē's nav nepieciešams. P.S. transcode that shit. 4000k kaķiem nav vajadzīgs. It īpaši, ja visiem tiem taviem 100 lietotājiem ir noutbuki ar 720p ekrāniem mehehehe.

Kasspars, depends no CDN. Parasti ir gan access kontroles. Piemēram, S3 visi bucketi ir privāti pēc noklusējuma. Tad cloudfront var visādus brīnumus organizēt, parakstīti url utt. Bet codez atkal maļ. CDN nav ātrāk integrēt, ja vien Tu to nedari tā, pa roku galam. Acīmredzot tā tu dari, jā. Jā, un bucketos tu lādē failus čerez ko, nepalaižamu klientside? BS arguments, nevietā. Ja es varu randomā izpildīt kaut kādus failus uz tavas kastes caur HTTP, tev jau ir problēma. Geokeši? Kas tāds? Tu domāji edge dns? Nu jā, daudz tev to vajag, ja tavam bļogam ir 5 apmeklētaji no Liepājas. Tas nu gan ir arguments. Jebkas <10TB trafikā skeilojas labi arī virtuvē zem galda. Tur nevajag CDN. ???!!! Kāda velna pēc tu "menedžē" failus CDN? Jebkuram nopietnam projektam CDN use vispār ir asinhrons process, kas sevī iesaista local upload, MQ un ielādi 1 vai vairākos CDN. Tas nav ne vienkārši, ne 3 rindas. Tas protams, ja tavs projekts nav ķep ļep sabakstīts un CDN ielāde ir prefetch. Un par tiem failiem, nekādi faili nekādās publiskajās direktorijās nedrīkst parādīties, nekādā formā. Proxy + ACL.

Nu izņemot tos, kuriem patīk, ka Ieva [jūzers] ir neapmierināta un pasta sistēma [serveri] ir pārslogota.

Case [Faili glabājas failu sistēmā]: Ieva pieprasa Jānim jaunu dildo [dati failā]. Jānis nosūta Ievai paciņā jaunu dildo [Failu sistēma/Web serveris]. Latvijas Pasts Nogādā paciņu no saņemšanas nodaļas līdz Ievas pasta nodaļai [Pārlūks]. Ieva saņem paciņu [dildo]. Case [Faili datubāzē]: Ieva pieprasa Jānim jaunu dildo [dati failā]. Jānis aizbrauc uz Lietuvu, ienāk Lietuvas pasta nodaļā, nomet dildo uz galda ar atzīmi saņemt pēc pieprasījuma. Lietuvas pasts [datubāze] iesaiņo dildo un noliek plauktā [failu sistēma]. Ieva griežas pie Lietuvas pasta ar pieprasījumu pārsūtīt dildo uz Latvijas adresi [web serveris].Lietuvas pasts nosūta paciņu uz Latvijas pasta nodaļu tuvāk ievai pa ceļam izvazājot Ievas dildo caur vismaz 2 reģionālajiem šķirosanas punktiem [datubāzes dzinis, programma [izguve no db]]. Kad paciņa nonāk pasta nodaļā [serveris] Ieva saņem paciņu [pārlūks]. Ieva nav apmierināta. Beat this...

Briedis, nemanu, kur jams teica, ko un kapec var augsupieladet.

No faila izvelkam heshu, failu saglabajam failu sistema zem hesha nosaukuma, piemeram, bilde.jpg klust par 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12, db pieglabaa originalo nosaukumu un heshu. Talak, glabajot failu sadali heshu grupaas, piemeram, 2fd4e1c67a2d28fced | 849ee1bb76e7391b93eb12 un parveido dalas direktorijaas, lidz ar to tavs cels uz failu bus /2fd4e1c67a2d28fced/849ee1bb76e7391b93eb12/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12 tadejadi tev nebus nekad vairak failu viena direktorijaa, ka speej pavilkt failu sistema. Datubazes failus pamataa nekad neglabaa, iznemot ipasus gadijumus. Golden rule = faili ir failu sisteemaa, ne db.

P.S Katrā topikā?! P.P.S Spark un Hadoop ir instrumenti, kas viens otru papildina, ne aizstāj. Also HAIl un LIAH.