Jump to content
php.lv forumi

Joyride

Reģistrētie lietotāji
  • Content Count

    168
  • Joined

  • Last visited

Posts posted by Joyride

  1. Veltot laiku SQL un ASM mācēšanai bez manuāļa, tiek atņemts laiks daudz kam citam, piemēram, tam, kā izveidot produktu no nulles...

     

    Es kad pievērosos programmēšanai, tad FW kā tādu vispār nebija un visu nācās apgūt no pašiem pamatiem. Līdz ar to ir ļoti dīvaini, ja "devs" nezin elementāras lietas. Vienīgais attaisnojums - indigo, kas dzimis 21. gadsimtā.

  2. Nez, cik no "bet viņš pat vienkāršu SQL nemāk uzrakstīt" nemāk uzrakstīt pat pāris rindiņas ASM, negūglējot, ko vispār nozīmē "ASM"?

     

    Kā ex Delphi programmētājs ļoti labi zinu, kas ir ASM, jo optimizācijas nolūkos nācās to savulaik izmantot. Kas tie par muļķīgiem pieņēmumiem, ka visi ir WEB devi un bez PHP neko citu nav redzējuši? Bet es pieļauju, ka Laravel devi gan to nezin :D

  3. Pirms gada ar kaudzīti iepriekšejā kantorī norotēja čupa ar tādiem "man pašam savs freims and i'm so smart.." cilvēkiem. Piedod bet tad labāk ir paņemt bulciņu cepēju ar 30 gadu pieredzi un apmācīt nekā tādu viszinošo guru.

     

    Savukārt, manā kantorī atlaida cilvēkus ar taisnvirziena domāšanu, piemēram, ex Ruby on Rails koderi, kurš pat samērā vienkāršu SQL bez manuāļa nemācēja uzrakstīt.

     

    P.S. Man nav savs freims :)

     

    Nē, atkarīgs no uzdevuma. 

     

    Tieši tā.

  4. mans piemērs vairāk no situācijas kad atnāk kandidāts, paziņo ka visu var un prot, bet kad pajautā ar kādu ietvaru strādā - izskan atbilde "es pats savu lietoju". tādus uz otro kārtu jau arī nepaaicinās

     

    Kas vainas "es pats savu lietoju"? Tas liecina, ka cilvēks ir zinošāks par vidusmēra Laravel/Symfony/Yii/whatever fanboyu, jo izprot programmas dzīves ciklu un ir savs redzējums kā lietām jābūt. Ja tā nebūtu, tad arī nebūtu tik daudz FW, visi lietotu CodeIgniter.

  5. Arī es nesagaidīju atbildi, pie kam 2x :)

     

    Padalīšos ar savu stāstu. Apmēram divus gadus atpakaļ pieteicos uz vakanci projektā Istabai.lv. Tiku uzaicināts uz interviju, likās, ka gāja labi, beigās standarta frāze "mēs ar Tevi sazināsimies".

     

    Pagāja turpat gads un pats sazinājos ar draugiem.lv. Tiku uzaicināts uz otru interviju, tas pats scenārijs.

     

    Pagāja 3 mēneši. Radās tīri sportiska interese un atkal atgādināju par sevi. Tika iedots "mājasdarbs", ko arī veiksmīgi izpildīju un beigās atnāk e-pasts, ka "esam izvēlējušies visatbilstošāko kandidātu un diemžēl Tev jāatsaka". Palika riebīga sajūta, ka esmu bezjēdzīgi iztērējis laiku un pat nezinu, kādēļ mani izbrāķēja.

     

    Vakances ir visu laiku. Neviens nav pietiekoši labs?

  6. Vajadzētu arī redzēt kontroliera uzbūvi.

     

    Lai nu kā, doma ir šāda - kad forma tiek nosūtīta, validē datus un, ja ir kļūdas, tad kļūdu paziņojumus saliec $errors masīvā, ko padod šim pašam View'am un parādi:

     

    <?php if (isset($errors)) { ?>

    <div class="errors">

        <?= implode('<br />', $errors); ?>

    </div>

    <?php } ?>

     

    Ieteikums - manuprāt, prasīt paroli ievadīt 2x ir arhaisms. Lai dotu iespēju lietotājam pārliecināties par ievadītās paroles pareizību, vari pielikt iespēju to apskatīt.

  7. @F3llony - paldies par detalizēto aprakstu.

     

    Mani arī interesētu DB versionēšana. Uz doto brīdi labākais variants, ko esmu atradis - visas DB struktūras izmaiņas tiek veidotas ar migrācijām un, laiku pa laikam, kad to paliek par daudz, tās tiek nodzēstas, un tekošais DB struktūras dumps tiek ielikts versiju kontrolē kā bāze, pārrakstot iepriekšējo.

  8. Sākums ir OK, tikai vajag vēl šīs lietas:

     

    Pie tabulas "classifieds_attributes" jauns lauks "attribute_data_type", kurš norāda datu tipu (int, string, text, bool, ...) Un "classifieds_values" lauks "attribute_value" iet ārā, tā vietā attiecīgi saliec "attribute_value_int", "attribute_value_string", ...

     

    Atkarībā no classifieds_attributes.attribute_data_type selektē vajadzīgo attribute_value_* lauku.

  9. Kontrolieri iekš DIC nav jāreģistrē, tiem tiks automātiski iebarotas dependencies, caur maģisko create() f-ju. Reģistrēt vajag tikai core klases, data mapperus un servisus.

     

    Ir jāreģistrē visas klases, kuras tiek lietotas aplikācijas ietvaros, un kurām vajag dependencies, taču izveidotas (lasi: new SomeClass) tiks tikai reāli izmantotās konkrētajā requestā. Domā par DIC konfigurāciju tāpat, kā par programmas konfigurāciju - tur tiek definēti visi iespējamie programmas konfigurācijas parametri, nevis atsevišķs fails katram requestam ar tikai tajā izmantotajām vērtībām.

  10. Kā ar gadījumu, kad vienas funkcijas ietvaros vajag kaut kādo lietot, bet ne vienmēr. Ja padod kā dependency injection, tad tas tiek inicializēts lieki.

     

    Tavā piemērā Log klase ir pietiekoši "populārs" objekts, kas noteikti tiek lietots daudz kur. Nu inicializēts tiks šeit, nevis nākamajā klasē, kur tāpat tiks lietots, kas par to?

     

    EDIT: Ja nu ļoti vajag, tad var jau padot konteineru:

    function __construct(Dic $dic)
    {
       if ($dic->db->lalala())
       {
           $dic->log->error('lalala');
       }
       else
       {
           //...
       }
    }

  11. Singletoni tie paši globāļi vien ir.

     

    DIC var papildināt, lai prot nodrošināt dependencies un nebūtu tas manuāli jādara.

     

    Sākumā atbrīvo modeļus (precīzāk - entities) no dependencies, datu atlases un saglabāšanas funkcionalitāti pārnes uz mapperiem, kaut kādas kompleksas darbības ar entities - uz servisiem. Tas nodrošinās ērtu darbu ar entities, nereizējoties par dependencies, piemēram, $user = new \User. User entity ir pilnīgi vienalga, no kurienes dati tiek ņemti, vai no datubāzes, vai no kāda webservisa.

     

    Core objektus, kā arī mapperus un servisus reģistrē iekš DIC.

     

    // Bootstrap.php
    $dic->config = $dic->share(function ($dic)
    {
    $cfg = new \Config;
    
    $cfg->loadFromFile('path/to/config.php');
    
    return $cfg;
    });
    
    // Pārējie core objekti: Request, Response, Dispatcher, Logger utt
    
    $dic->db1 = $dic->share(function ($dic)
    {
    return new \Db_Mysql($dic->config->db1);
    });
    
    $dic->db2 = $dic->share(function ($dic)
    {
    return new \Db_Pgsql($dic->config->db2);
    });
    
    $dic->user_mapper = $dic->share(function ($dic)
    {
    return new \User_Mapper($dic->db1); // Vai arī citu DB konekciju, kas ir reģistrēta iekš DIC
    });
    
    // User_Controller.php
    class User_Controller extends \Controller
    {
    private $user_mapper;
    
    public function __construct(\User_Mapper $user_mapper)
    {
     $this->user_mapper = $user_mapper;
    }
    
    public function list()
    {
     $this->view->users = $this->user_mapper->getActiveUsers();
    }
    }
    
    // Dispatch
    // "Maģija" iekš Dic::create() ir gaužām vienkārša: ar Reflection iegūst izveidojamās klases dependencies (konstruktora parametrus) un tad tos meklē pie savām reģistrētajām dependencies.
    // Ja prasītā dependency nav reģistrēta iekš DIC, tad metam exception. Kad savācam vajadzīgo, tad izveidojam prasīto objektu (hint: newInstanceArgs() f-ja).
    // Un to, protams, var lietot ne tikai kontrolieriem, bet jebkuram objektam.
    $controller = $dic->create('User_Controller');
    
    $controller->list();
    
    // Vēl viens piemērs - gribam padot otro DB konekciju (PostgreSQL) un izveidot mapperi paši + lietot config:
    class User_Controller extends \Controller
    {
    private $db;
    private $config;
    
    public function __construct(\Db $db2, \Config $config)
    {
    $this->db = $db2;
    $this->config = $config;
    }
    
    public function list()
    {
    $mapper = new \User_mapper($this->db);
    }
    }
    

  12. @v3rbo: šoreiz lapas kodējums nav pie vainas, jo tekstam tiek garum/mīkstinājumzīmes aizstātas ar līdzīgajiem ASCII jeb parastajiem angļu alfabēta burtiem.

     

    @anonīms: tā ir, ka netestē lokāli :) Kā Tu zini, kas notiek apakšā tam web servisam?

     

    Mans skripts strādā korekti, pārbaudīju vēlreiz. Iekopē savā teksta redaktorā, saglabā utf-8 kodējumā un palaid ar PHP.

     

    Ja nu dikti vajag online: http://ideone.com/sLwD9

  13. Nē, ne tā. Jau rakstīju, ka f[ast]cgi režīmā. Nginx nevis spawno PHP procesus katram pieprasījumam, bet to uztic php-fpm un šajā gadījumā APC kešs ir kopīgs tikai viena procesa ietvaros. Bet process nav tikai viens un arī viņam ir savs noteikts dzīves cikls, pēc cik pieprasījumu izpildes tas restartējas.

     

    Marrtins, kā tiec galā ar problēmu, ko mēģināju aprakstīt, lai kešs ir viens ne tikai viena procesa ietvaros, bet visu?

  14. Marrtins pareizi saka par lock problēmām, tur nav testēt, nu neder šis variants. Ir jānovērš problēma saknē, jānodrošinās pret keša bombardēšanu. Es Tev piedāvāju divus pārbaudītus un elementārus risinājumus, kuri derēs neatkarīgi no lietotāju skaita, bet Tu kā tāds pārgudrs auns.

     

    Piedevām ja ir paredzēti tik daudzi vienlaicīgi pieprasījumi (100/sec), tad jau diez vai PHP tiks laists kā Apache modulis (klasika), drīzāk būs Nginx + PHP fcgi un tad APC vispār neder.

     

    [spam enabled=1]

    Ieguvums 0.000X sekundes :D Labāk izej cauri DB un pārbaudi indeksus, smagos vaicājumus pārraksti bez JOINiem, tas būs miljons reižu noderīgāk.

     

    Skatos, nesen esi sācis apgrābstīt namespaces (Tavs šī gada x0cache projekts tās vēl nelieto), ej cauri kodam un izlabo, kur ir aizmirsies "\" pielikt funkcijām un klasēm, izdomā, ko darīsi ar vendor libiem, kuri tās nelieto - to neesi paredzējis autoloaderī. Un, vispār, namespaces ir sliktas. Tiec vaļā no globālajiem mainīgajiem, uzraksti elementāru Config klasi, nicinātajam Zend ir jauks risinājums. Kāpēc vairāki failu paplašinajumi, PHP ir tikai viens: .php. DI, laikam nav nemaz vērts pieminēt.

     

    Starp citu, kiosku lapas veidoju tikai karjeras sākumā, tāpat kā noteikti arī Tu un vairums citi, tagad manā pārziņā ir daudz nopietnāki projekti, kā piemēram šis:

    Directories: 583

    Files: 3218

    Lines of Code (LOC): 1054628

    Cyclomatic Complexity / Lines of Code: 0.09

    Comment Lines of Code (CLOC): 328815

    Non-Comment Lines of Code (NCLOC): 725813

    [/spam]

  15. Kurš ir ātrākais veids, var noskaidrot tikai ar benchmark palīdzību, citādi Tavs viedoklis ir subjektīvs. Uztaisi benchmarku katram gadījumam tieši uz sava konkrētā FW bāzes un salīdzini.

     

    Un man tik tiešām nesķiet, ka apvienot visas sava FW klases vienā failā ir kaut kas drausmīgs, jo diez vai Tev tur ir milzu pašrakstītas PDF utml klases (ala tcpdf / ezpdf apmēros). Viens require uz šo failu vienreiz pārstartējot webserveri, Tu taču lieto APC, vai ne?

  16. Es ieteiktu uztaisīt komandrindas PHP skriptu, kurš izveido classmap failu. Protams, jāatcerās to palaist katru reizi, kad nāk klāt jauna klase.

     

    // classmap.php - ģenerē skripts
    return array(
    'Mana_Klase' => 'Pilns/ceļš/līdz/libs/Mana/Klase.php',
    );
    
    // bootstrap.php
    function autoload($class_name)
    {
    static $cache = null;
    
    if($cache === null)
    {
     // Vari arī glabāt APC kešā
    	$cache = require 'classmap.php';
    }
    
    if(isset($cache[$class_name]))
    {
    	require $cache[$class_name];
    }
    else
    {
    	// Tu met exceptionu, bet es to neiesaku, jo ja nu kādreiz gribēsi tikai noskaidrot, vai klase eksistē ar class_exists()
    }
    }
    

     

    Vēl ir risinājums apvienot visas ietvara klases vienā lielā failā kā to dara Yii (ja nemaldos).

  17. DEV -> TEST -> PROD

     

    Uz DEV izstrāde + pamata testēšana, kad kāda fīča ir pabeigta, tad izmaiņas tiek uzliktas uz TEST serveriem, kur testēšanu turpina citi un tad, ja viss ir kārtībā, izmaiņas tiek publiskotas arī uz PROD serveriem.

     

    Ja nu tomēr sanāk šmuce, tad nāk talkā versiju kontrole un tiek atjaunoti vecie dati, re-deploy un tālāk problēmas novēršana.

  18. Izmēģināju, diemžēl nekas nemainās laika ziņā.

     

    Pagaidām atrisinājām problēmu, atlasot tikai pēdējos 5000 (aptuveni) galvenās tabulas ierakstus.

     

    Sākumā {ID} = MAX(id) - 5000 un tad "smagajā" vaicājumā WHERE id > {ID}.

     

    Ja ir ieslēgti atsevišķi filtri, tad šis jaunais kritērijs netiek piemērots (piem., meklēšana pēc laikiem vai kaut kādu dokumentu numuriem).

     

    Rezultātā vaicājums izpildās 0.7 sec.

     

    Nav jau perfekts risinājums, tā kā, ja kādam ir vēl kādas idejas, labprāt uzklausītu!

  19. EXPLAIN EXTENDED:

     

    id | select_type | table      | type  | possible_keys | key   | key_len | ref                   | rows | filtered | Extra
    1    SIMPLE        wppnol      index   (NULL)          PRIMARY 4         (NULL)                   50     79498.00   where; temporary; filesort
    1    SIMPLE        wpp         eq_ref  PRIMARY         PRIMARY 4         wppnol.BillID            1      100.00 	 
    1    SIMPLE        customers   eq_ref  PRIMARY         PRIMARY 4         wpp.CustID               1      100.00 	 
    1    SIMPLE        services    eq_ref  PRIMARY         PRIMARY 4         wpp.ServID               1      100.00 	 
    1    SIMPLE        employees   eq_ref  PRIMARY         PRIMARY 4         wppnol.PrintedBy         1      100.00 	 
    1    SIMPLE        wpstat      eq_ref  PRIMARY         PRIMARY 4         wpp.Status               1      100.00 	 
    1    SIMPLE        bills       eq_ref  PRIMARY         PRIMARY 4         wpp.BillID               1      100.00 	 
    1    SIMPLE        wppnol_data ref     wpn_id          wpn_id  4         wppnol.ID                1      100.00 	 
    1    SIMPLE        warehouses  eq_ref  PRIMARY         PRIMARY 4         wppnol_data.warehouse_id 1      100.00

     

    WHERE: wppnol.delby = '0'

    GROUP BY: wppnol.ID

    ORDER BY: wppnol.starttime DESC

×
×
  • Create New...