Jump to content
php.lv forumi

mad182

Reģistrētie lietotāji
  • Content Count

    310
  • Joined

  • Last visited

About mad182

  • Rank
    Daudzsološais profiņš
  • Birthday 05/26/1988

Contact Methods

  • Website URL
    https://ezgif.com/

Profile Information

  • Gender
    Male
  • Location
    Rīga

Recent Profile Visitors

8302 profile views
  1. Pavisam nesen aizgāju no "9-17" daba un sāku strādāt no mājām tikai pie saviem projektiem, bet tam nav sakara ar COVID19, vienkārši sakritība laikā un jau sen to biju plānojis darīt. Bet zinu, ka vairāki no draugiem/paziņām arī ir sākuši strādāt no mājām vai pārgājuši no daļēja attālinātā darba uz pilnīgu vīrusa dēļ. Šķiet, ka tas ir diezgan plaši izplatīti.
  2. Domā ja tam arhaiskajam tabulu brīnumam apakšā būtu vēl iepīts kāds padsmitgadīgs (php 5.1) ietvars tas kaut ko padarītu labāku un visi stātos rindā tur kaut ko darīt? Pie tam, neviens jau nav teicis ka nav...
  3. Jā, bet man nav nekādu problēmu turpināt lietot un attīstīt pirms 6, 8 vai 10 gadiem iesāktu projektu. Neupdatojams ietvars te rada problēmu - vai nu iesprūsti kaut kādās vecās ietvara versijās un paradigmās, kas savukārt neļauj upgradot php un citas bibliotēkas, vai arī jāvelta ļoti daudz laika lai vēlreiz pārrakstītu to, kas ļoti labi strādā un pelna naudu tā pat, tā teikt jāizgudro riteni no jauna (teiciens ko ļoti patīk lietot ietvaru fanātiķiem pretējā kontekstā). Un es gribēju piebilst, ka neesmu principiāli pret ietvaru lietošanu, strādājot komandā tas vairumā gadījumu ir labākais risinājums, bet nu dažreiz ir vērts apsvērt gan plusus, gan mīnusus, man vienkārši nešķiet pareiza tā kategoriskā nostāja, ka vienmēr weblapai visur vajag ietvaru, orm'u, templeitu dzini un vēl miljons lietu lai izdarītu to, ko var tik pat ātri izdarīt ar iebūvētajām php metodēm, un jebkurš citāds viedoklis ir automātiski nekur nederīgs. Drusku triggeroja kā te visi Grey_Wolf metās virsū jo viņš atļāvās paziņot ka neizmanto ietvaru :D
  4. Tieši tā. Uz ietvariem būvētās lapas ir lielāka sāpe upgreidot ilgtermiņā. Piemēram cakephp 1.x, 2.x un 3.x savā starpā atšķiras tik ļoti, ka upgreids starp versijām ir līdzvērtīgs pārrakstīšanai no jauna, un vecās versijas atjauninājumus nesaņem un uz php 7.x nestrādā. Kamēr paša rakstītās lapas nekad nav bijis problēmu ugreidot, arī pirms 15 gadiem rakstīts forums perfekti strādā uz php7.4, tikai ātrāk.
  5. Man ir bijusi darīšana ar vairākām uzlauztām lapām, gan senos laikos savām, gan daudz vairāk reižu sakopjot citu nelaimes, un praktiski vienmēr, kad problēma ir bijusi kodā, tā ir nākusi no "tūkstošiem cilvēku review-ota open source" CMS/frameworka/liba nevis sava koda. Jā, varbūt arī savā custom kodā ir kāši, toties tie netiek katru dienu publiskoti un automatizēti eksploitoti no visiem, kam nav slinkums. Ietvars var palīdzēt ar izstrādes ātrumu (un arī ne vienmēr) un atvieglot darbu komandā, bet ātrdarbībai un drošībai tas nes tikai mīnusus.
  6. hetzner.de manuprāt ļoti labs "bang for buck", managed webhostingu neesmu lietojis, bet ar VPS un dedicated serveriem esmu apmierināts jau vairākus gadus.
  7. Man adsensē arī bija kaut kāds tur advancētāks suports piešķirts beigās, bet ne reizi to neizmantoju jo problēmas un jautājumi jau pa lielam bija tad, kad vēl nebija apjoma. 10+ gadus adsensi lietoju. Vēl ar čekiem uz banku senos laikos skraidiju un ja pareizi atceros pat kaut kādu viltību lietoju lai no Latvijas reģistrētos :D
  8. Mani savervēja setupad.com, tas ir vietājais latviešu projekts, bet nu resello viņi tā pat visādus lielos ārzemju tīklus - googli, rubicon, openx, appnexus utt... Sākumā ne pārāk ticēju piedāvājumam "dubultot peļņu", tādi e-pasti man bieži nāca un parasti norakstiju kā spamu un uzmetienu, bet nu šo piekritu pamēģināt un izrādijās ka tā lieta reāli strādā un nu jau gadu ienāk visi maksājumi kā paredzēts. Pluss, ka ar viņiem var ļoti ātri un vienkārši sazināties, uzraksti e-pastu latviski un pēc 10 minūtēm saņem atbildi, nevis kā adsensē, kur ja rodas kāds nestandarta jautājums vai problēma kas nav aprakstīta FAQ, ātrāk nomirsi no vecuma nekā sagaidīsi atbildi no dzīva cilvēka. Bet vispār to risinājumu ir daudz un cik saprotu visi darbojas diezgan līdzīgi, visādi ezoic, media.net un miljons citi. Ja lieto reddit, tad /r/adops ir daudz info.
  9. Mja, tādā variantā varētu būt ticami, man ir tradicionālāks modelis kur katrā lapā kādi 4-5 baneri apkārt saturam , tad tāda summa par 1000 ekspozīcijām liekas kosmoss. Kaut kādu header bidding risinājumu kas apkopo vairākus tīklus neesi mēģinājis? Man sanāk stipri vairāk, kā no plikas adsenses.
  10. Nezinu, ko Tu dari, bet laikam jau kaut ko pareizu, jo tas izklausās zvērīgi daudz priekš LV.
  11. Es neko daudz nezinu par yii ietvaru un tā popularitāti, un patiesībā arī neinteresē, tikai gribēju piebilst, ka ar google trendiem ir tā interesanti, bieži vien ar nelielām atslēgas vārdu variācijām var tikt pie ļoti atšķirīgiem rezultātiem, līdz ar to diez vai tos vienmēr var saukt par vispatiesākajiem, piemēram:
  12. mad182

    MySql backup

    Viņš locko datubāzi/tabulas? Lielākām datubāzēm tā parasti ir problēma backupojot. Es izmantoju šo: http://www.percona.com/doc/percona-xtrabackup/2.2/
  13. INNER JOIN būs ātrāks par milzīgu IN(), ja tas ir iespējams šajā gadījumā.
  14. Nu viens veids, kā to varētu izdarīt ar vienu kveriju būtu izmantot https://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html#function_group-concatun pēc tam jau ar php (piem. explode()) sadalīt to lauku un iegūt masīvu. Bet ja vien tur nav kaut kāds ļoti specifisks iemesls tā darīt, manuprāt uztaisīt vēl vienu kveriju atribūtu iegūšanai būtu loģiskāk.
×
×
  • Create New...