Joyride

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ā.

Tāpēc, ka ir redzēt padaudz "savi freimworki", kuri izskatās pēc kūpošas sūdu čupas, viss krustām šķersām, nekas nav nodalīts jēdzīgi.

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?');

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

By the way kāds sakars ror ar sql?

Vistiešākais - cilvēks tā pieradis pie ietvara (šajā gadījumā ORM), ka bez tā neko nevar izdarīt.

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ā.

Ja gribās jokus, tad uz šejieni.

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.

http://lv.xpresshd.com- The site ahead contains malware

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" ?

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.

@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.

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.

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
   {
       //...
   }
}

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);
}
}

@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

<?php

echo iconv('utf-8', 'ascii//TRANSLIT', 'glāžšķūņrūķīši');

?>

EDIT: //IGNORE drošības pēc vari pielikt, tikai bez divnieka beigās.

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?

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]

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?

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).

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.

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!

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