Java

Slēpt kodu tu varētu, ja kods būtu tik vērtīgs, ka ar to varētu pelnīt kā ar biznesu! Ja tev ir drupal idejas analogas, tikai 10x sliktāks, tev nav jēgas to slēpt, jo citam programmerim vieglāk un lietderīgāk būtu iemācīties to pašu pieminēto Drupal vai kaut vai Joomla. Bet ja Tavs kods, piemēram, veido izcilu un pilnīgu rīku, kas specializēts, piemēram, kā nekustamo īpašumu izsoli, kas savukārt potenciāliem iespējamiem pircējiem lieliski prezentētu tieši Dubaijas nekustamos īpašumus, lai līdzētu tos pārdot kaut par pāris miljoniņiem dolāru vairāk, nekā tie patiesībā maksā šajos laikos, tad jau tavam kodam ir kaut kāda nebūt vērtība un tad arī varbūt ir jēgas slēpt savu kodu...

Kāds vēl "laps cms"! Drupal ir "laps cms"? Tūkstošiem (varbūt pat miljoniem) cilvēku uzskata, ka JĀ! Es uzskatu, ka nē, tāds pats "php sahakots draņķis" kā citi webā pieejamie. Un es šaubos vai "tavs freimvorks" būs kaut vai tik pat "laps" kā Drupal... Un Drupal ar visiem moduļiem ir bezmaksas. Tātad - ko tu vari piedāvāt par saviem 250 Ls pret bezmaksas risinājumu labāku? Neko! Tas ja runājam par platformisko "cms risinājumu". Ja runājam par risinājumu konkrētam projektam, tad loģiski - tu prasi naudu par savu darbu, klients tev maksā par risinājumu "tieši tā kā viņam vajag", nevis par "opensource cms skripta iemešanu" serverī.

Starp citu - nesaskatu nekādu stabilu biznesu, cepjot šitādas te vizītkaršu lapiņas visādiem knauzeriem un bijušiem cietumniekiem, kas izvēlējušies pēkšņi "nodarboties ar biznesu". Manā uztverē, programmēšana ir nedaudz taktiskāka nozare...

Nu nedēļu testēt var tikai miniprojektus... Es strādāju pie projektiem, kur izstrāde kopā ir ap gadu (ieskaitot testēšanu, sistēmarhitektūru, plānošanu utt.)

Mjā, bet esošu Webu pārcelt uz kādu jaunu freimworku ir mazliet tomēr problēmas! Pats esmu papētījis, un sapratu ka vienkāršāk vien drukāt pašam kā līdz šim viss darīts! :)

Ja projekts ir mazbudžeta (līdz 1000 Ls) un ja arī tas peļņu nenes pietiekami un tam principā nav plaukstošas nākotnes, kā arī tas nav saistīts ar datu drošību tiešā veidā (izņemot protams, piereģistrēti lietotāji, ja viņi reģistrējoties nav izpauduši personas datus), tad vispār taisot projektu, galvenais ir lētums parasti, "freimvorks" noteikti nav pats lētākais risinājums viena mazbudžeta projekta ietvaros, labāk taisīt kā vienkāršāk un lētāk. "Freimvorki" vairāk noder, ja uz vienu bāzi ir jāveido vairāki projekti un tie visi arī jāuztur, vai arī jāveido viens liels projekts, paredzot, ka tas nākotnē būs regulāri jāuztur.

Esošu webu (zinot kādi lielākā daļa "webu" no programmēšanas aspekta vispār ir...) "pārcelt" vairumā gadījumu tiešām būs problēmas... Vieglāk būs pārprogrammēt esošam webam visu loģiku priekš "freimvorka" un miers.

Es gan atkal domāju "drusku savādāk" tieši par šo aspektu runājot. Es domāju, ka jāiemācās no informācijas uztvert būtisko daļu, es pats esmu mācījies pie visādiem profesoriem utml. un labi zinu, ka viņiem patīk liet ūdeni šad tad... Dažreiz tas pat aizņem puslekciju - tas "ūdens"!

Atveram http://www.smartyjobs.net/ - vesels 1 darbs "Smarty programmētājam"! Apsveicu!

Skatoties pārējos saitus, kurus pirmajā lapā izmeta Google, ir skaidrs, ka tos Smarty pārsvarā pieprasa (ja vispār kāds pieprasa) tikai kā papildus zināšanas paralēli php, mysql, css, xhtml un tādā garā...

Kā es skatos uz Smarty:

* Sintakse, kuru var izmantot HTML redaktorā, saprotama plašākai publikai, dokumentēta speciāli templeitu kontekstā. Piemēram, to var iedot klientam, kurš pēc iepazīšanās ar to var pats veikt vienkāršas izmaiņas lapā.

Un kāda atšķirība vai iedosi klientam glītus "views", kur ir strikti ievēroti MVC principi ar php kodu iekšā, vai arī "Smarty templeitu"?

* Nodalīts templeita "scope", t.i., darbības apgabals. Darbs ar templeitiem var tikt veikts atsevišķi, no darba organizācijas viedokļa. No tehniskā viedokļa, iespēje kontrolēt, ko var un ko nevar darīt templeitos. Ne vienmēr var uzticēties tam, kurš strādās ar templeitiem, piemēram, ja templeitus maina lietotājs caur CMS sadaļu, nedrīkst atļaut tīšas vai netīšas kļūdas. Varbūt viss, ko projektā var atļaut, ir daži sintakses elementi. PHP gadījumā kā nokontrolēsi, vai templeiti saveidoti pareizi - pārbaudīsi katru? Un ja tā ir sistēma ar 1000 lietājiem?

Ar to smarty viņš arī var sataisīt "muļķības" tāpat kā ar php, bet ja viņš ir tāds, kas taisīs "injekcijas" aplikācijai iekš "views", tad viņš ir kaitnieks vai nejēga un ir jāpārskata sadarbība ar viņu.

* Plugini ļauj papildināt bāzes funkcionalitāti ar sistēmai vai CMSam specifiskām iespējām. Piemēram, CMSā var veidot rakstu ar HTML redaktoru, un raksta vidū ielikt {gallery name='lielie_nemieri_saeima'}, kas automātiski iemetīs tajā vietā dajebkādu projektam atbilstošu galerijas kodu. Un HTML editoru var papildināt ar pluginu, kas atpazīst šādu tagu un piedāvā to pievienot/rediģēt. Protams, var jau arī taisīt <?php echo $this->gallery(' ... ?>, bet nu... tas nav tīri..

Nav skaidrs, kāpēc CMSa admin pusē būtu jāliek kaut kādas "Smarty" vai "views" labošanas lietas? Pat ja to vajag, tur vienmēr būs ierobežotas iespējas un noteikumi, ko tur darīt (vismaz tā vajadzētu būt) un tāpat nāksies taisīt specifisku "parseri" šādām iespējām. Administrācijas puse jeb "back-end" pats par sevi ir ar ierobežotām iespējām, lai nesačakarētu aplikāciju un pēc tam programmētājiem nāktos labot klienta kļūdas uz klienta vai pašu programmētāju rēķina - nevienam tas nav īsti ērti veiksmīgai sadarbībai, tāpēc, vislabāk piedāvā klientam veikt izmaiņas ar ierobežotām iespējām, lai samazinātu kļūdu varbūtību.

Tāds mans praktiskais skaidrojums, droši ka ir teorija, kurā viss skaidri un gaiši pamatots.

Par to sistēmu - tas ir pats par sevi, ka lietotāja interfeisa daļai vajadzētu būt atdalītai no loģikas, tā ir arī MVC būtība. Par teoriju - nebūšu es gluži LU pasniedzējs, gan jau kāds aktīvs briļļainis paskaidros teoriju labāk! ;)

Aleksejs, domāju, ka vienkārši var laist gar ausīm lietas, kas neinteresē un, kas nesaistas tieši ar izvēlēto nākotni. Ir lietas, kur nav nepieciešams padziļināts ieskats, tikai nokārtot eksāmenu kaut vai uz 4 ballēm un miers. Vai tas nozīmē, ka slikts students bijis? Ja viņam interesējošos priekšmetos atzīmes bijušas 8 un 9? Piemēram, cilvēks izvēlējies kļūt par sistēmadminu, bet programmēšanas priekšmetus viņš nolicis uz 5 ballēm, bet Operētājsistēmas uz 9. Sliktāks speciālists tāpēc?

Bakalaurs ir 4 gadi. 2 gadi ir tikai 1. lvl prof. izglītībai.

Baigais principiālais akadēmiķis esi? Ja cilvēks spēj "ūdeni" laist gar ausīm (viennozīmīgi, daļa no universitātē barotās informācijas ir "ūdens" - tā vienkārši ir un praktiski VISUR), bet uzņemt un veikli analizēt tieši vajadzīgo informāciju, neredzu iemeslu, kāpēc nevarētu nokārtot bakalauru 2-3 gados!?

Ir jau absolvēts LU? Cik tur vispār maksā, ja iet neklātienē? Vai ir "zibensprogramma", ka bakalauru var dabūt 2 gados, ja spēj cilvēks pavilkt?

torrentz - pirms jautājuma jau brīdināju, ka tas varētu šķist nektaktisks. Man vienmēr ir interesējis, ko tad tajos LU datoriķos tieši māca! Varbūt tev ir kāds links uz lekciju sarakstu vai konspekti kaut kādi?

Kas attiecas uz "lipināšanu kopā" - "frameworka" sākotnējā izmantošana un aplikācijas konfigurēšana ar to principā arī ir tāda koda gabalu lipināšana kopā, jo pat ja tur nav kods iekšā sākumā, programmētājs paņem kaut ko jau no gataviem piemēriem. Bet ja tas tavs pasniedzējs gribēja ar to pateikt, ka mūsdienās daudzi programmētāji attiecīgi nav profesionāli vai "necērt" lietas no pašām saknēm, tad šādā kontekstā es viņam nekādi negribu piekrist!

Jo gluži vienkārši - programmētājs dara to, ko viņam pasūtītājs liek, to arī viņš veido un nav viņam jātērē mēnešiem ilgs laiks, taisīt aplikācijas pamatus, ja to jau var gatavu lejupielādēt framework formā pāris minūtēs un tad, zinot pamatprincipus - valodu, arhitektūru - izstudēt līdz spējai "varu sākt izmantot" dažu nedēļu laikā. Tas, cik programmētājs ir labs vai profesionāls, atklāsies gan tajā KĀ viņš raksta to kodu - kāda ir koda kvalitāte, loģika, tīrība, kā arī tas atklāsies, kad vajadzēs risināt nebijušas problēmas - kā viņš ar tām tiks galā un cik ātri aptvers, kur "vajag rakt", jo zinot fundamentu un esot apveltītam ar abstraktu domāšanu, to visu var izdomāt.

Manā lekcijā (LU) pagājušonedēļ pasniedzējs teica, ka mūsdienās tieši ir vairāk tā, ka programmētājs vien pārsvarā tikai saliek dažādus koda gabalus (kas nemaz nav slikti lielākoties) un paša programmētāja radītie koda gabali laika gaitā ir samazinājušies.

Tieši par šo man ir jautājums, iespējams, diezgan netaktisks:

Vai tavs pasniedzējs mēdz intensīvi pasniegt lekcijas vai ik pa laikam novirzīties no pamattēmas ar šim līdzīgiem spriedelējumiem? ;) Izklausās, ka LU (kas tomēr ir Latvijas augstākās izglītības "zieds") tomēr pasniedz arī diezgan ierobežotām zināšanām apveltīti pasniedzēji. Es, nebūdams ne maģistrs, ne profesors nevienā sfērā, varu pamatot, ka tā ir "tukša liekvārdība", ar argumentiem!

1. tas, ko programmētājs liek kopā vai neliek kopā no gataviem gabaliem, ir atkarīgs no veicamā uzdevuma specifikas - vai tas ir komerciāls projekts ar miljoniem līdzinieku, kur nekas jauns vairs nav jāizdomā (vismaz - neatmaksājas to darīt), tāpēc pietiek "salipināt" esošus gabalus kopā (gandrīz jebkurā gadījumā - tomēr pašam kaut kas jāpaprogrammē būs). Vai arī uzdevums var būt specifisks un tad, ļoti iespējams, vajadzēs programmētājam nodemonstrēt gan savas "algoritmizācijas zināšanas un arī spējas", gan valodas pamatu pamatu zināšanas.

2. ja programmētājs arī netaisa komerciālu gabalu, bet teiksim, nodarbojas ar entuziasmu (īsts programmētājs IR nodarbojies ar entuziasmu programmēšanā, jo viņam šis darbs vienmēr ir interesējis), tad viņš nemaz nav ieinteresēts "gatavu kodu lipināšanā" kaut arī šie gatavie kodi ir pieejami. Viņš tieši ir ieinteresēts algoritmizācijas problēmu risināšanā, matemātikā, informātikas fundamentu risinājumos, jaunradē utt. Un tur vairs nav nekādu "gatavu kodu lipināšana", vienīgais, ko tur interesanti ir ņemt gatavu - informāciju un fundamentālas idejas jeb studēšanas process. :)

Secinājumi jautājumu formā:

1. Iespējams neesi uztvēris vissvarīgāko sava pasniedzēja lekcijas daļu vai arī iespējams, viņš visu lekciju "dzina sviestu"?

2. Vai LU visi pasniedzēji nodarbojās ar šāda veida "mācīšanu" vai arī tās ir tikai atkāpes, lai kaut kā kompensētu 10 minūtes no 1.5 stundu ilgās lekcijas, par kurām nav īsti sagatavota viela?

Ārzemēs freimwork'i ir ļoti populāri. Man pat liekas, ka reti kur izmanto pliku PHP (vai jebko citu). PHP gan tur nav vispopulārāk izmantotais, toties ASP.NET ir visur (es šobrīd pa Lielbritāniju runāju) pieprasīts - es gan īsti nesaprotu kādēļ, jo man viņš neliekas īpaši ērts.

 

Ja skatamies darba piedāvājumus par PHP, populārākie freimwork'i ir Code Igniter un Zend. Esmu papētījis Code Igniter, taču ja ir lietots Rails, kuram viņi cenšas līdzināties, tad viņš liekas tāds nedaudz saspīlēts un ne-tik-tīrs.

Lielbritānija, lai nu ko par viņiem teiktu, ekonomiski ir augsti attīstīta valsts, protams, un tur darbojās gandrīz visas "industrijas", diemžēl, neesmu labi informēts tieši par IT un software industriju tur.

Kas attiecas uz ASP.NET - tas tomēr ir MS risinājums un patiesībā izskatās, ka Eiropas mēroga Microsoft lobijs ietekmē programmatūras izvēli tieši šādās rietumeiropas valstīs, kur ļaudis mēdz dažkārt naudu vairāk taupīt nekā šeit, bet tai pat laikā pāris simti eiro tur ir sīknauda.

Runājot par Smarty templeitiem - es arī īsti neizprotu kādēļ vajag veidot vēl savu valodu, valodā. Manuprāt nav liela starpībā ko izprast - nedaudz PHP sintakses, vai Smarty sintaksi. Tas pats vien būs.

Precīzi!

Bet nu lai vai kā nedomāju, ka php freimwork'i ir kaut kas slikts - varbūt nevajag tik ļoti censties līdzināties ekvivalentiem uz citām valodām, taču visādi citādi tas ir ērtāk kā lietot pliku php.

Tieši tā - frameworki ir profesionālu programmētāju darbarīki. Nav jāizgudro ritenis, nav jātērē laiks un nauda, jo klients vēlas maksāt pēc iespējas mazāk, bet saņemt augstu kvalitāti, jo to spēj piedāvāt konkurenti. Attiecīgi atvērtā koda ietvarrāmji (jeb "freimvorki") kļūst ļoti izdevīgi gan to izstrādātājiem, gan arī izmantotājiem - programmētājiem! Izstrādātāji iegūst stabilus "supporta" pasūtījumus, jo no frameworkiem galu galā ir atkarīgi daudzi biznesi, savukārt izstrādātāji - atvieglotus jaunu projektu izstrādes nosacījumus, līdz ar to zemākas izmaksas un konkurētspējīgākus piedāvājumus klientiem.

Bet galvenais jautājums tomēr paliek atklāts - kādi frameworki "web softu" izstrādes mērķiem ir vislabākā izvēle? Man šķiet, vajadzētu izveidot augstas klases profesionāļiem tādu organizāciju, kas nodarbojas ar salīdzināšanu - gan frameworku, gan softu un savus rezultātus viņi varētu pārdot kaut vai IT mēdijiem un mēs - par brīvu izlasīt! :)

Nesitiet pārāk stipri, bet jautājums Java'i - ko Tu vispār dari/meklē šajā forumā un kāda no tā ir jēga? Paldies.

To, ko parasti cilvēki dara forumos - diskutē, apmainās ar viedokļiem un izsaka savus viedokļus par attiecīgajām tēmām. Šī tēma ir par php frameworkiem, par to arī ir pamatā runa manos ziņojumos, kas attiecās uz šo tēmu. Jēga - uzzinu citus viedokļus, meklēju atbildes uz sev interesējošiem jautājumiem.

IT speciālistam ir plašas iespējas orientēties uz tirgu ārpus LV, tas nav nekas slikts specializēties Smarty, JS un XHTMLā.

Man jau līdz šim ir licies, ka ārzemēs (vismaz Rietumeiropā, ASV, Austrālijā, Jaunzēlandē, Kanādā, Japānā un citās attīstītās valstīs) līmenis ir augstāks. Iespējams, tieši tāpēc tur izmanto Smarty, jo ir pārspīlēta darba dalīšana un tiek meklēti tirgū "dizaineri ar smarty zināšanām".

Tavs piemērs ar Smarty ir tas, par ko jau teicu - konkrētai vajadzībai tiek pretnostatīts risinājums, kas ir domāts citu vajadzību risināšanai. Ja tavas vajadzības nav templeita valoda, nodalīts php kods un, piemēram, iespēja templeitus definēt CMSā, tad ir lieki spriedelēt par to, kāpēc dizaineriem jāapgūst php un kāpēc Smarty, kas nav domāts šādai pieejai, ir slikts ar to, ka nav tiešām nav domāts tādiem gadījumiem. Vienkārši neizmanto to. Kur problēma?

Runāju tieši par tām pašām vajadzībām. Smarty "funkcijas" lieliski veiks tas pats php un ja dizainerim nav problēmu ar smarty, tad viņš tiks tikpat labi galā arī ar php.

Ja viss labi veiksies Laiks rādīs, apsveru iespēju uzrakstīt blogu, kur apkopot savas pārdomas, bet tas tāds jautājums ar lielu varbūtības koeficientu, jo latviski kaut kā negribas rakstīt dēļ profesijas specifikas, bet angliski vēl tik labi neprotu.

 

Par minor versijām - nu es to saprotu, kā labi organizētu izstrādes darbu. Projekts attīstās. Varbūt interesanti, kā gāja ar devZone ZF updeitu no 1.0.1 uz 1.9.5. versiju: http://devzone.zend.com/article/11364-DevZone-updated-to-Zend-Framework-v1.9.5

Par ZF runājot - tieši tā - vajag rakstīt! Vajag pēc iespējas vairāk rakstīt cilvēkiem, kā viņiem iet, lietojot savu izvēlēto frameworku. Performances jautājums ir svarīgs, uz ko visi pārsvarā iespringst, bet vēl svarīgāki ir BUGI un vai viss notiek visos gadījumos tieši tā kā Framework izstrādātāji paši iecerējuši un aprakstījuši!

Nebarojiet trolli.

Atvaino, bet šajā gadījumā "trollis" esi tu pats, jo jaucies pa vidu ar "beztēmu". ;)

Runājot par ZF vēl - tur papētot visas tās bibliotēkas, pirmkārt, fakts, ka viss ir sataisīts pēc iespējas OOP un pie tam "enterprise" stilā. Bet pateikšu vēlreiz, ka php tomēr nav tāds pārāk tīrs OOP un tā stipri neoptimālā php sintakse traucē arī to loģiski un precīzi un "OOPiski" uztvert. Protams, ZendFramework būtībā ir, līdzīgi kā jau šeit v3rb0 teica, apjomīgas bibliotēkas, kas nedaudz atgādina PEAR - visai neveiksmīgs tomēr ir tas PEAR, domāju, ka vairums tam piekritīs. Bet ZF tomēr šķiet labāks par PEAR. Es teiktu tā - ZF principā atmaksātos tā nopietni pielietot (lai būtu vispār vērts aktīvi studēt) tikai web aplikācijām, nevis kā vienkāršu standarta "CMS tūli". Iemesls tam varētu būt tas, ka ZF ir jāmācās diezgan nopietni un ilgi (neatkarīgi no "pielekšanas spējām"), jo tas vienkārši ir apjomīgs frameworks un nav diža jēga izmantot visas tās bibliotēkas un klases tur, ja nezin kā tās izmantot iespējami pareizi un optimāli. Un enterprise frameworka apgūšana pat normāli spējīgiem cilvēkiem līdz līmenim "eksperts", šķiet, prasīs vismaz gadu... Jo "sāls" ir nevis izlasīt dokumentāciju, bet arī iemācīties visu praktiski pareizi pielietot. Bet tomēr, rodas iespaids, ka ZendFramework mēģina risināt problēmas, kas patiesībā ir ārpus php "lauciņa" - vajadzības, kuras prasītu gandrīz vai .NET vai Java izmantošanu... PHP tak tomēr ir un paliek web valoda dinamiskajām weblapām. Nevar tak interpretējama valoda risināt pārāk dziļi un sarežģīti problēmas, jo nenotiek nekāda koda optimizēšana un kompilēšana, tas tiek lasīts tāds, kādu programmeris uzrakstījis un tajā varbūt daudz principiālas kļūdas, kuras atļaus iebūvētais "striktais errorreportings", bet kas nav varbūt optimālākais risinājums. Lai gan "bugainu" softu var uztaisīt jebkurā valodā. Runājot par "bugiem", pārsteidz ārkārtīgi biežie ZF "subversiju izlaidumi" - vai tad tiešām bugi tiek laboti tik bieži, vai arī notiek vienkārši nepārtrauktas jaunu "fīču" izstrādes... Lai gan neapgalvoju, ka ZF nebūtu izmantojams, tāpēc jau prasīju - kādiem softiem to izmanto un kā veicas ar izstrādi kopumā - bugi, jaunu fīču izstrādes ātrums un to kvalitāte, dizainu nomaiņas, jaunu servisu pievienošanas, trešo aplikāciju datu apmaiņa, servera OS nomaiņa, webservisi, ajax...? (sevišķi lietderīgi būtu tādu cilvēku komentāri, kas ar ZF nodarbojas jau vismaz gadu...)

Runājot par Smarty - ir strādāts arī ar to. Pateikšu godīgi - Smarty izmantošana man šķiet diezgan bezjēdzīga, jo tā ir bezmazvai skriptu valoda iekš skriptu valodas. Ko tas Smarty atvieglo? Dizainerim darbu ar šabloniem un "layoutiem"? Neticu! Vajag dizainerim iemācīt php pamatu pamatus (nebūs viņam tas grūtāk kā iemācīties Smarty) un pateikt - mainot "views" ar visu, kas tur iekšā, skaties, lai saglabājas tur iebūvētā datu atrādīšanas loģika (biznesa loģikai tur nevajadzētu būt, tikai attēlošanas loģikai) un viss. Kaut kādi dīvaini "dizaineri", ja vēlas ar to strādāt, bet negrib to visu lieliski un ātri apgūt! ;) Starp citu, ir gadījies sastapt tādus pāris kadrus, kas sevi dēvēja par "smarty programmētājiem". Protams, sākumā bija interesanti paklausīties kā viņi uzskata sevi par dižiem speciālistiem, kas ir spēcīgi specializējušies uz vienu lietu - "smarty programmēšanu" un html, javascript. Pēc tam jau, protams, par to nācās tikai pasmaidīt! :) Nav tā web sfēra tik šausmīgi komplicēta, ka varētu specializēties tikai uz "smarty programmēšanu" vai jquery izpratni utt. Ja specializējas uz JavaScript, HTML un CSS piemēram, tad specializējas tādā līmenī, ka spēj uzrakstīt savu Dojo, jQuery vai TinyMCE - jā tādu specializēšanos uz šauru sfēru es saprotu - tur ir spēcīgas zināšanas par "browser scripting" apakšā, bet ne jau čaļi, kas iemācījušies izmantot jquery un smarty sauks sevi par dižiem "speciem", kas lāga neprotot ne php, ne zinot ko par serveriem, server puses programmēšanu un datubāzēm (šķita, ka viņi pat OOP kā tādu nezin un nesaprot) - nu tas arī, manuprāt, ir "ceļš uz nekurieni". Latvijas mērogā tādu īsti specializētu specu ir ļoti maz vai arī nav gandrīz vispār, jo gluži vienkārši - reti kurš var atļauties nolīgt vienas web aplikācijas izstrādei 5 cilvēku profesionāļu komandu teiksim, kur katrs atbild tikai par savu specifisko sfēru un viss. Ja var sadalīt 3 daļās kaut vai - viens serverists/admins/operētājsistēmists vienā personā, viens spēcīgs tieši OOP un bāzes programmēšanā, arī db nepieciešamajā skriptēšanā, tad viens atbild tīri par dizainu, klienta puses skriptiem, stiliem un piedalās arī server pusē moduļu izstrādē un db tabulu modificēšanā papildināšanā, tas jau ir labi! Nav kaut kā dzirdēts šeit Latvijā par spēcīgiem Javascript speciālistiem, kas uz Javascript spēj realizēt bezmaz jebko, kas korekti rādītos uz 7 populārāko pārlūku pēdējo 3 gadu laikā izlaistajām versijām. CSS neskaitiet pie programmēšanas, tur ir hakošana, bet pārsvarā tā ir "stilošana". Gari gan te atkal skaidroju, bet pamatdoma ir tāda - arī klienta skriptēšanas pusē var izmantot tos Javascript frameworkus (Dojo, jQuery utt.) un tajās lietās spēj iebraukt arī kārtīgs zvērināts server puses OOP programmētājs. Un HTML spēj iebraukt arī iesācēji - par to vispār nav pat runa - valīds html un xml nav nekāda programmēšana (nejaukt ar XSLT) - tās lietas ir jāzin jebkuram, kurš izlēmis strādā šai sfērā (jā, pat tehniskajam projektu vadītājam)... Tāpēc es nesaprotu, ar ko nodarbojas šādi "dizaineri" un "smarty programmētāji", ja viņiem neatliek laiks izlasīt PHP manuāli un iemācīties pamatlietas uz PHP (vai Python vai citu valodu, kuru viņi izmanto), lai varētu skaisti ķerties klāt "viewiem", ko sataisījuši "serveristi"? Manuprāt, nav vajadzīgi nekādi "smarty" un vispār nekādi "template dzinēji", visu view daļu var realizēt, vienkārši turot tos atsevišķos php failos (piemēram, kā ZF ir tiem .phtml paplašinājums) un tur arī tad iet kopā gan html, gan php - tīri tikai līmenī, kas vajadzīgs, lai izveidotu attēlošanas loģiku - cikls atrādot vienādas daļas, vēršanās pie metodēm, kas veic atrādīšanu, view funkcijām, helperiem utml. Tas ir kopējā "frameworka" uzdevums, nevis kaut kādas atsevišķi izveidotas skriptu valodas iekš skriptu valodas, kur galvenā atšķirība no "mātes skriptu valodas" (šai gadījumā php kā "mātes skriptu valoda" Smarty) ir nedaudz savādā sintakse un pieraksts.

Starp citu, Java arī ir visādi brīnumi, piemēram JSF - Java Server Faces, arī paredzēti "viewiem", bet tur es neredzu gandrīz neko kopīgu ar tādu "Smarty" vai template endžines pieeju... Jo pati Java nav īsti skriptu valoda, tur viss ir objekts un "sejas jeb faces" pilda "viewu" funkcijas, ko nebūtu optimāli uzticēt Javas klasēm...

Šobrīd ņemos ar Zend Framework.

 

Jo vairāk ņemos, jo vairāk tas patīk. Priekš tam gan taisu arī atbilstoša līmeņa projektu ar vīziju ilgam laikam uz priekšu.

Nu ļoti interesanti, ko tu, piemēram, tādu taisi uz to ZendFramework? Kas ir tāds, ko taisīt uz ZendFramework būtu ja ne labākais risinājums, tad vismaz viens no labākajiem? Vari to paskaidrot, protams, ar abstrakcijām, bet lai būtu tomēr kāds konkrēts pamats no reālās dzīves.

Uzskatu, ka ir ļoti muļķīgi norobežoties no freimworkiem tikai dēļ tā, ka sarežģīti, vai smagi, vai cik tur inclūdes.. katrs freimworks risina noteiktu problēmu loku, kādam Symphony būs tieši laikā, kādam vajadzēs kaut ko radikāli citu. Taču visiem piemīt īpašība, ka izplatīto problēmu risināšanai tiek piedāvāts ļoti pārdomāts risinājums, kas ir sistematizēts freimworka ietvaros. Ja plaši izplatīts freimworks nepatīk vai izsauc riebumu, tad visdrīzāk, tas nav piemērots risināmajai problēmai.

Protams, viena problēma ir tos frameworkus mācīties. Tāpēc pirms kādu frameworku apgūt, vēlams veikt rūpīgu tā izvērtējumu, diemžēl "googlējot" ir atrodamas pārāk maz nopietnas, padziļinātas, daudzpusējas "frameworku" analīzes kā jau te izteicās, nevis "linkuliste"...

Bet principā, piekrītu, ka "frameworki" ir profesionāla pieeja - izmantot to, ko sagatavojuši ir citi profesionāļi, kas savā specifiskajā lauciņā ir krietni spēcīgāki. Tāpēc tikai normāli ir, ja "web frameworku" ir radījušas veselas profesionāļu komandas, kur katrs ir padziļināties specializējies savā lauciņā un vairāki vispārīgāki "arhitekti".

Ļoti cerams, ka tas nav dēļ aizkavēšanās novecojušos stereotipos vai sīkklientiem, kuri nomoka ar mikrowebiem, vai, nedod dievs, bailēm no OOP..

Lai arī php ir objektorientēta valoda, tomēr, manā uztverē, ne īsti pilnībā. Nepatīk fakti, ka OOP pamatiespējas tur ir iekļautas tikai sākot ar 5. versiju. Nedaudz kaitina arī absolūts "type safety" trūkums un neprecīzā (case-insensitive) sintakse, ieskaitot dolāru likšanu pirms katra mainīgā. Arī "error messaging" ir tāds, manuprāt, vairāk piemērots interpretējamai skripta valodai, nevis OOP valodai. Pārāk daudz "atvieglojumu" un arī vairums integrētās bibliotēkas nav "OOP bāzētas". PHP ir daudz fanu, bet neesmu daudz redzējis tādu nopietnu un objektīvu šīs valodas analīzi, jo interesanti, ka nopietnās programmēšanas valodu salīdzinošajās analīzēs PHP bieži vien pat nav iekļauts! ;) Protams, OOP ir iekļauts php valodā, bet tas izskatās tāds "pieaudzēts klāt", nevis nostādīts kā pamatprincips visai valodai (kā tam normāli vajadzētu būt OOP valodās).

Bet saku - pagaidām nepretendēju uz izcili objektīvi konstruktīvu PHP valodas analīzi.

Freimworks paātrina izstrādes gaitu, konkrēti nosaka kur, kam ir jābūt, atvieglo programmētāju no daudz, viendabīgā, koda rakstīšanas. Par katra konkrētā freimwork'a izmantojamību jau ir cits stāsts.

Nē, "framework" nozīmē "ietvars". Reāli tas neatbild par izstrādes ātrumu vai gaitu. Tas neatbild arī par koda rakstības stilu, tas ir atkarīgs individuāli no programmētāja, tas var dot tikai ieteikumus. Koda rakstības stils paliek "valodas līmenī" un programmētāja paša "rakstības stila" līmenī, bet "freimvorks" par to tev neatbildēs. Jā, tas, ka frameworks var uzspiezt savu arhitektūru, tā ir patiesība un tas daļēji varētu būt arī freimvorka mērķis - pieprasīt, lai programmētājs veido programmu vēlamajā arhitektūrā, bet galvenokārt - tas piedāvā bibliotēkas, lai atvieglotu darbu pie vairāku veidu aplikāciju veidošanas - lai nav šīs lietas jātaisa pašam.

Bet ir tāda veca patiesība - "kas der visam, neder nekam". Katrai valodai un frameworkam ir savs uzdevums.

Bet ir vēl viena svarīga patiesība - universālai lietai jābūt vai nu perfektai vai tuvu perfektai. Un nevar censties uztaisīt "pilnīgāku, universālāku, advancētāku" (sauciet kā gribat) uz bāzes, kas nav tik "pilnīga, stabila, universāla, perfekta". Īsāk sakot, tas nozīmē, ka nav jēgas taisīt frameworkus, kas mēģina pildīt uzdevumus, kas sniedzas pāri php iespēju robežām, ja par "iespēju robežām" uzskatām "stabilas, viendabīgas un veiktspējīgas darbības kopu". Cerams, domu sapratāt.

Domāju, ka daudzi freimwork'i ir iespaidojušies no citu valodu analogiem (Django, Rails) un mēģina attēlot to darbību. Ne vienmēr tas ir viegli izdarāms, vai vispār iespējams, bet kādēļ necensties.

Kad cenšās, var arī pārcensties un beigās sanākt "bugi" un nopietnas nepilnības, kas liek rakstīt tā saucamos "hakus"! Vienam projektam šīs problēmas vēl var menedžēt, apkalpot un novērst, bet diezvai tūkstošu projektu bāzei, ja nevēlas vērā ņemamas "papildus izmaksas" gan laikā, gan naudā, gan nervos.

Runājot par frameworkiem tieši uz php, ir pamēģināts, piemēram, ZendFramework. Pateikšu godīgi - tas izskatījās nevis pēc mēģinājuma atvieglot darbu un uzlabot tā kvalitāti, bet gan pēc mēģinājuma to sarežģīt un pārtaisīt pašu php tam neatbilstošā līmenī - kaut ko uz stingra OOP pusi kā Java, C# utml. Protams, tas ir SVIESTS! Php ir vienkārša skriptu valoda personīgajām mājaslapiņām, tāpēc nedomāju, ka tur vispār nepieciešams bāzt virsū kaut kādus mistiskus "frameworkus" jo php ir "frameworks" pats par sevi - ierobežotu iespēju valoda ar iebūvētām funkcijām un bibliotēkām. Var vienkārši ieviest vienotus MVC arhitekturālus patternus, bet nafig sarežģīt interpretējamu skriptu valodu, mēģinot uzlēkt augstāk par tās iespējām! Pirmkārt, php nemaz nav īsts tīrs OOP un nevar būt, tāpēc to ir absurdi izmantot kā tīru OOP valodu.

Grandu cīņas! Pieauguša vecuma IT monstri cīnās! Tā tik turēt! :D

Ventspils augstskola, ja nelaiž gurķi, pirmajos gados bija ļoti OK. Vismaz programmēšanas, linukši un matemātika bija līmenī. Ja vēl Hiļkevičs bīda kaut kādus projektus, tad vispār ideāla vieta, kur mācīties cirst zivi ;>

Pietrūka: normālu lielo datubāzu (tik 1 kurss - mysql ievads), elementāras projektu vadības, normālu UMLu. arī modelēšana kā iekš RTU nekaitētu.

Cik es pats esmu dzirdējis, tad Ventspils Augstskolā vairākums IT studentu nezin nesaprot (prāts nespēj aptvert) HTML, kur nu vēl ko sarežģītāku?

Nē, ja man jāatbild topika autoram - Latvijā NEKUR nevar normāli iemācīties IT programmatūras izstrādi, tas viss ir jāmācās pašam! Papīru var dabūt arī veikalā - lētākais tualetes papīrs maksās mazāk kā 50 santīmus.

Un kādu skriptu diez visādi šitādi spēj uzrakstīt?

echo "Hello world!";

BĀC, TIKAI NEZODZ NO MANIS ŠITO!!! :D

Ir tāda lieta kā programmatūras dizains, kam nav nekāds sakars ar krāsām, līnijām vai triepieniem. Varbūt ir domāts tas!

Bet es pieļauju, ka šeit ir domāts CSS un lapas stila veidošana.

Bet gadījumā ja ir domāts, ka likt kaut ko zīmēt, tad jā - tas ir absolūti nepareizi, tā nav programmētāja kompetence. Tas jādara ir māksliniekiem (kaut vai uz laiku nolīgts, ja nevar/nevajag pastāvīgi)...

Vienīgais "līmenis", kurš ir "cits" java koderiem, ir iedomības līmenis.

Nu pag, lauku meitenei, kas dzīvē pārzin tikai savu novadu, lauku darbus un sadzīviskas lietas, tu ar savu php arī liksies iedomīgs!

Nu nav Java tas pats, kas php, princips ir savādāks visai izstrādei...

Pastāv milzīgi liela varbūtība, ka ja uz šo sludinājumu piesakās cilvēks, kas kaut vai perfekti pārzin php, bet nepārzin Java un viņu paņem (piemēram, samelojas intervijā), ka viņš pat neizturēs pārbaudes laiku, tā nu tas diemžēl ir... Vienkārši brīdinu.

IBM WebSphere refers to a brand of software products, although the term also popularly refers to one specific product: IBM WebSphere Application Server (WAS). WebSphere is designed to set up, operate and integrate electronic business applications across multiple computing platforms, using Java-based Web technologies.

Un vispār sludinājumā ir arī teikts:

...

# pieredze Java servlet programmēšanā

...

Tas nav nekāds php, tas ir cits līmenis (kam maz sakars ar šajā forumā novēroto). Attiecīgi - pieteikties vari, bet ja tev nav pieredze Java "enterprise" līmeņa programmēšanā, tad izredzes ir švakas (principā).

Beidzot vēl atrodas pāris saprātīgi cilvēki, kas arī uzskata, ka nodokļus ir jāmaksā. Kas māk mākslīgi izveidot savas nodokļu iemaksas (legāli) mazākas - apsveicami! Bet fakts ka nodokļi jāmaksā pastāv un iemesli šī fakta esamībai ir sekojoši:

1) Tu dzīvo valstī, kurai tu maksā nodokļus (šai gadījumā, Latvijā) - tātad tu izmanto šīs valsts infrastruktūru un pakalpojumus, kas viss tiek finansēts no nodokļu naudas.

2) Ja citi ir "urlas" (kā, piemēram, taksisti un nelegālo cigarešu tirgotāji, krutas tirgotāji utt.), tas nenozīmē, ka tev arī tādam jābūt! Protams, nav patīkami, ka tu maksā nodokļus, bet citi nē, pie tam, valsts varbūt ne līdz galam lietderīgi tos nodokļus izmanto. Bet tas nav pamatojums, lai tu šos nodokļus nemaksātu! Urlas vairojas tikai, ja ir tādi, kas uzskata, ka urlam būt ir OK.

3) Valsts ir ne tikai tās pārvalde, bet arī tās cilvēki - godīgai jābūt ne tikai valsts pārvaldei, bet arī tās cilvēkiem! Ja visi būsim saliedēti un godīgi, tad mafijai šeit nebūs augsne, kur ražot savu "netīro naudu"! Tai skaitā, protams, mafijai valsts pārvaldē...

Ko tu te strīmo, te ir programmeru forums. Atrodi man universālu ekspertu - kurš sajēdz visu IT sfērā (kaut vai tikai tehniskās/programmēšanas lietas) - parādi man tādu - tāda nav! Bija! Tad, kad veči laboja radioaparātus ar lodamāmuru un publiski pieejams bija ZX-Spectrum un varbūt vēl nedaudz izstrādājumi - tad jā - tie entuziasti varbūt arī zināja visu par tā laika "datortehniku". Mūsdienās - cilvēka galvas kapacitāte, manuprāt, nepieļauj zināt visu, ko var izdarīt un vajag darīt uz datora - sauksim to par PC, Apple, Handheld device vai kā nu patīk...