Jump to content
php.lv forumi

Joyride

Reģistrētie lietotāji
  • Posts

    168
  • Joined

  • Last visited

Everything posted by Joyride

  1. 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. Mēģināšu runāt valodā, kādā šeit saprot :D CommentFacade::replyTo('briedis', 'Ak tad populārāko FW sākotnējās versijas nemaz nekūpēja?');
  3. 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
  4. Vistiešākais - cilvēks tā pieradis pie ietvara (šajā gadījumā ORM), ka bez tā neko nevar izdarīt.
  5. 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 :) Tieši tā.
  6. 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.
  7. 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?
  8. http://lv.xpresshd.com- The site ahead contains malware
  9. Vai atbilstošais, motivējošais un garantēti regulārais atalgojums ir būtiski uzlabojies, vai joprojām līmenī "vidējā programmētāja alga Latvijā / 2" ?
  10. 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.
  11. @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.
  12. 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.
  13. 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.
  14. 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 { //... } }
  15. 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); } }
  16. @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
  17. <?php echo iconv('utf-8', 'ascii//TRANSLIT', 'glāžšķūņrūķīši'); ?> EDIT: //IGNORE drošības pēc vari pielikt, tikai bez divnieka beigās.
  18. 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?
  19. 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]
  20. 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?
  21. 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).
  22. 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.
  23. 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!
  24. 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...