CI, Kohana vai Symfony

[jurchiks]

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

[qwerty]

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 February 20, 2015 by qwerty

[codez]

Jaunām versijām, kas tikko iznākušas, mēdz būt šādas problēmas:

1) ir vairāk bugu;

2) nav atjaunota saderība ar visiem dependancy.

[Kasspars]

Pašlaik esmu pavilcies uz Slim freimworku. Patīk asktētiskums un vienkāršība.

 

composer require slim/slim

 

Protams, ar visiem šiem vienkāršajiem freimiem problēma, tāda, ja projekts tomēr izvēršas plašāks, tad nožēlo, ka nepaņēmi Laravel :)

[briedis]

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

[jurchiks]

>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 February 22, 2015 by jurchiks

[briedis]

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

$schedule->command('cache:clear')
    ->hourly()
    ->sendOutputTo($filePath)
    ->emailOutputTo('john@doe.com');

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

[Kasspars]

Juri, tas nav nekas jauns vai unikāls! Wordpresā tāda pati sistēma ir jau N gadus

[jurchiks]

->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 February 22, 2015 by jurchiks

[Mr.Key]

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.

[briedis]

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

[F3llony]

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

[jurchiks]

Jo ilgāk krāj putekļus, jo smagāk nākotnē apgreidot.

[Kavacky]

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

[jurchiks]

Tu to tā saki, it kā vienmēr varētu zināt, vai projekts pēc mēneša nomirs vai nē.