Jump to content
php.lv forumi

CI, Kohana vai Symfony


Kracker

Recommended Posts

  • Replies 46
  • Created
  • Last Reply

Top Posters In This Topic

Jā, veselu vienu nedēļu novecojusi.

 

Pieļauju ka šis projekts paņems kādus divus mēnešus. Nākošo gan taisīšu uz jaunākās versijas.

 

Gan jau par šo izvirtību priekš manis ellē netiks iekurināts speciāls katls.

Edited by qwerty
Link to comment
Share on other sites

Pašlaik migrēju pēdējo projektu uz L5. Aizņēma apmēram kādas 4h. Par laimi, dependenciji bija vai nu neatkarīgi no versijas vai arī jau bija nomigrēti uz L5.

Ir pāris projekti uz 4.2, bet tie laikam tādi arī paliks, ja vien neradīsies nopietna vajadzība kaut ko uzlabot projektam, kad arī būtu vērts migrēt...

Strādājot ar L4 man visvairāk no L5 prasījās dependency injections caur klases metodēm, nevis tikai konstruktora. Citādā ziņā ar L4 var dzīvot.

 

Kas no L5 vēl ir foršs - queue ar datubāzes atbalstu, atviegloti cronjobi (viens ik minūtes krons izsauc vajadzīgos darbus), kurus tagad var forši norādīt kodā, kad kas jāizpilda. u.c. sīkumi..

Link to comment
Share on other sites

>atviegloti cronjobi (viens ik minūtes krons izsauc vajadzīgos darbus)

Wait, what? I had that half a year ago in my own framework! Bija pārsimts ļoti līdzīgi cron jobi, uztaisīju db tabulu ar sarakstu un laikiem, un vienu PHP skriptu, kurš strādā ar to db tabulu un izpilda taskus tad, kad vajag. Elementāri.

Edited by jurchiks
Link to comment
Share on other sites

Jā, bet ar laravel tas jau ir iebūvēts, nekas nav jākodē.

$schedule->command('cache:clear')
    ->hourly()
    ->sendOutputTo($filePath)
    ->emailOutputTo('[email protected]');
$schedule->terminal('gulp task')->fridays()->when(function(){ 
    return true;
});
$schedule->call(function(){
    //.. 
})->everyThirtyMinutes();

Visu jau var sakodēt, bet patīkami, kad tas jau ir iebūvēts un katram nākošajam projektam nevajag taisīt/kopēt libus...

Link to comment
Share on other sites

->hourly()

->everyThirtyMinutes()

Vot šito gan varēja uztaisīt every('1h') / every('30m') / every('friday') utt. Būtu daudz fleksablāk un nevajadzētu tādas explicit metodes katram intervālam.

 

Bet vispār to visu tak var suportēt ar to pašu ->when(function ()

{

    return ((date('m') === '0') && (date('s') === '0')); // hourly()

    return ((date('m') / 30 === 0) && (date('s') === '0')); // everyThirtyMinutes()

    // utt.

});

Lai gan es saprotu, ka tas ir paredzēts kompleksākiem nosacījumiem.

 

Edit: es pareizi saprotu, ka tie taski nemaz db neglabājas, un ir vnk php fails, kurā ir visi tie $schedule->something()->then() un vnk izpildoties failam, visiem šiem taskiem tiek čekots then() un ja atbilst pašreizējam laikam, izpildīts something()?

 

@Kasspars - es zinu, ka nav nekas jauns, tāpēc jau arī nobrīnījos!

Edited by jurchiks
Link to comment
Share on other sites

Zbis, jaunu projektu intentionally taisīt uz vecākas versijas...

Ir FW, kur versija 1 un versija 2 atšķiras diezgan būtiski. Pat pilnīgi dažādas filozofijas. Es tā domāju, ka ja ir uztrenētas prasmes uz kāda FW v.1 un ar to var ātri ražot elegantus risinājumus, izmantojot FW priekšrocības, vai tad tas ir nepareizi? Ilgtermiņā maintainability labi kodētam v.1 (v.N) varbūt būs labāks, nekā skrienot pakaļ v.(N+1). Citiem vārdiem sakot, es neesmu pārliecināts, ka intentionally izmantot pašu jaunāko versiju ir nepareizi.

Link to comment
Share on other sites

Ir FW, kur versija 1 un versija 2 atšķiras diezgan būtiski. Pat pilnīgi dažādas filozofijas. Es tā domāju, ka ja ir uztrenētas prasmes uz kāda FW v.1 un ar to var ātri ražot elegantus risinājumus, izmantojot FW priekšrocības, vai tad tas ir nepareizi? Ilgtermiņā maintainability labi kodētam v.1 (v.N) varbūt būs labāks, nekā skrienot pakaļ v.(N+1). Citiem vārdiem sakot, es neesmu pārliecināts, ka intentionally izmantot pašu jaunāko versiju ir nepareizi.

 

Es domāju, ka jā, nav jēgas skriet uz jauno FW tikai versijas numura dēļ. Prasti jau migrē tāpēc, ka uz jaunākas versijas ir atvieglota dzīve tieši programmētājam. Ja labi ir uz vecās versijas un nav īsti iemesla kāpēc migrēt, tad nu i nafig :)

Link to comment
Share on other sites

Es domāju, ka jā, nav jēgas skriet uz jauno FW tikai versijas numura dēļ. Prasti jau migrē tāpēc, ka uz jaunākas versijas ir atvieglota dzīve tieši programmētājam. Ja labi ir uz vecās versijas un nav īsti iemesla kāpēc migrēt, tad nu i nafig :)

 

Nu atkarīgs arī, cik veca ir versija. Ja vienreizēja migrācija pēc tam pienes labumu uzturēšanā un uzlabošanā, tad var arī apsvērt. Ja tas ir kaut kāds projekts kas nav izmaiņas redzējis gadiem, tad protams.

 

Es tomēr pieturos pie continuous integration & upgrade - tikko jauna versija, apdeito visu, izlaiž caur testiem, ja kaut kas nobrūk - salabo un turpina. Tas protams ja nav jāpārraksta 90% projekta. :D

Link to comment
Share on other sites

Tas ir pie nosacījuma, ka tāda nākotne iestājas. Nevis projekts mirst dabiskā nāvē un aizmirstībā vai arī tiek uzrakstīta jauna versija. Lasīt - vislaik apdeitot vajag tikai projektiem, kas stagnē.

 

A stagnējošu projektu var arī neupdeitot. :D

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...