Jump to content
php.lv forumi

Wuu

Reģistrētie lietotāji
  • Posts

    984
  • Joined

  • Last visited

Posts posted by Wuu

  1. select u.id,
    st_distance_sphere(
                    ST_GeomFromText(concat('POINT(',u.longitude,' ',u.latitude,')'), 4326),
                    ST_GeomFromText(concat('POINT(22.286756 56.624693)'), 4326)
    ) as closeness
    from users u
    where u.longitude is not null and u.latitude is not null
    order by closeness

    Kā man iekš kverija ielikti pārbaudi uz distanci? closeness <= 50000

     

    Where nevar ielikt imho "ERROR:  column "closeness" does not exist" alias nestrādā. 

  2. Ir kāds labs veids, kā lielu teksta blāķi saspiest, pēc iespējas unikālākā [a-z] simbolu virknē?

     

    Pagaidām ir ideja, katru burtu pār-konvertēt uz ascii. Sasummēt, un rezultātu pa vienam ciparam atpakaļ ascii + sāli (a.k. kopējais teksta garums)

    const result = String([...text.replace(/\s/, '')].reduce((all, val) => all / 2 + val.charCodeAt(), '')).replace(/\./, '').split('')
    .map(val => String.fromCharCode(97 + Number(val)))
    .join('')
    

    Pagaidu variantā tiek izmantoti tikai 10 simboli.

     

    Vēl viens variants, ar gatavu ascii tabulu, no kuras paņemt vajadzīgo simbolu virkni.

    const ascii = [45, 95, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122]
    
    const result = `${[...text].reduce((all, val) => all / 2 + val.charCodeAt(), 0)}${text.length}`
    	.match(/(1\d{1,2})|(\d{1,2})/g)
    	.map(val => ascii.indexOf(val) === -1 ? String.fromCharCode(ascii[val % ascii.length]) : String.fromCharCode(val))
    	.join('')
    
  3. Protams, jo JavaScripts ir OOP. Bet tik un tā, tu vari mierīgi beigt mutēt rezultātu un padod datus no funkcijas uz funkciju, funkcionāli. Piemēram map ir funkcija, kāda starpība kur viņa atrodas? Kaut piesaistīta pie HTML diva.

     

    Ideja ir ļoti vienkārša, dati kustās no funkcijas uz funkciju un ārējie parametri funkcijas rezultātu neietekmē. Nevaru sagaidīt ka JavaScripta parādīsies daudz kodolu mapi utt..

  4.  

    Tad esmu novērojis, ka javascriptā jaunu kodu rakstu ātrāk, taču tajā praktiski vienmēr ir kļūdas, kuras izķeru tikai testēšanas laikā

     

    Sākumā testi, pēc tam kods. Un jāraksta ir funkcionālā stilā - ES6 baybe. Bez mutācijām. immutable.js neskaitās, ka tu uzreiz raksti bez mutācijām.

    Tās bija manas lielākās kļūdas ar JavaScriptu. Kodam kurā nav for, while, let, var un citi OOP sūdi, ir cita atdeve. Tanī brīdī kā sāc lietot var i = 0, vai let = temp, vai ja uz brīdi aizdomājies, kā nosaukt mainīgo, tā jau ir mīnusi. Jo ja mainīgajam ir nozīme aizpildīt caurumu dizaina, tad problēma ir citur. LEAN :>

  5. Njā, piekāšu šitādas datubāzes. Izrādījās, ka pie vainas poolsize, mēģināju palielināt, bet efekts bija tikai minimāli ātrāks. Aizdiršās pools un serveris, sēž gaida, kad būs brīva vieta rindā.

     

    Tik un tā priecē fakts, ka parast qurey neizpildās pienācīgā laikā.

    select * from users where email = '[email protected]'   izpildās ~50ms / tb pings līdz serverim ir ap 45-55ms.

    Bet kā lieto prepare select * from users where email = $1, ['[email protected]'] izplidās ~100ms, līdz pat ~150ms, nopietni? 

    Kas par čerņu? Kas tā pa miskastes datubāzi, kas find one nevar izpildīt bez aizķeršanās. Es pat uzliku uz digitalocena jaunu serveri, un uzstādīju tīru nekonfigurētu jaunāko PostgreSQL versiju. Un tas pats!

     

    Vai arī tas ir normāli? Varbūt es ar mongo pārāk salīdzinu. 

     

    Testu veicu ar ~1000 pieprasījumiem pēc kārtas. ~50 paralēli.  Labprāt uzklausītu viedokli par līkajām rokā, ar norādi, kur varētu būt problēma. 

     

    Papildinājums

    Ar prepere nodefinētu ātrums ir ok, vienīga problemā, ka nevar prepare nodefinēt vissam poolam uzreiz. Nācās loopot katram savienojumam cauri un nosūtīt prepare, līdz brīdim kad tas atkal atslēgsies, tad atkal. 

  6. Man par nelaimi jālieto SQL. Interesē, kā no PostgreSQL 9.3 izspiest visu maksimālo. Par indeksiem neiet runa.

     

    Cik saprotu, https://www.postgresql.org/docs/9.3/static/sql-prepare.htmlir jēdzīgs variants, kas aizsargā arī no SQL injekcijas un panāk maksimālo jaudu no prastiem/bieži lietojamajiem pieprasījumiem.

    Man tikai ļoti nepatīk, ka funkcijas glabājas sesijās . Kas pie velna notiek ar sesiju, ja piemēram ir disconects uz pāris sekundēm vai reconnekts?

    Nevar šos prepare saglabāt piemēram uz tabulas, kā funkciju?

     

    Problēma ir, kā ORM ir drausmīgi lēns. Jo normāla variantā nodarbojas ar ko jocīgi.

     

    Pat raw query `select from users where email = '[email protected]'` ir standarta 2x ātrāks, par ORM.

     

    Piemēram Mongoosse var ielikt lean(), lai neatgriež objectu. Šim nekādu tādu ekstru nav un atgriežas tikai datus. Sails.js

  7. Bet Wuu "neaizsargā" c parametru ("whatever it means") - kāds var ierakstīt f("foo","bar")

     

    Ideja ir ļoti vienkārša, nedot pieeju parametriem un iekšējām funkcijām kurām nav jābūt pieejas no ārpasaules.  

  8. Kaut kas starp woo un codez sanāca
    const f = (n, c) => Array(c).fill().map((v,k)=>Array(c-k).fill(n).join('')).join('\n')
    console.log(f('foo', 4))

    Nē, tev tur rekursīvi strādā, shorthand pārbaudes un mutācijas.

    codez atkal neaizsargā b parametru, kas nav pareizi. Imho, kāds to b var ierakstīt. console.log(f("foo",3, 7)). Papildus ir nevajadzīgs newline beigās. Tikai bez stresa.

     

     

  9. Uz kā balstīts Tavs viedoklis. Uz Tavas neizmērāmās pieradzes un zināšanām? Vai pliku diršanu?

     

    Tas ir jautājums, nevis viedoklis. Laba, vai viduvēja? Tu man liekas Spānijā dzīvo. Cik izmaksā 3-4 istabu dzīvoklis. 2 istabu neinteresē. Apmēram 15-20 minūtes no Madrides centra. 1h stundu vilcienā pavadīt katru dienu arī neizklausās diezko spīdoši. Kā ar valodas barjeru un attieksmi pret iebraucējiem?

×
×
  • Create New...