Jump to content
php.lv forumi

nemec

Reģistrētie lietotāji
  • Posts

    698
  • Joined

  • Last visited

Posts posted by nemec

  1. Es, kā galveno programmētāja īpašību uzskatu laba un uzturama koda ražošanu. Un rezultāta mērķis ir strādājošs produkts.

     

    Vēl es fanoju par TDD izstrādes metodi — sākumā rakstām testus un tad tikai kodu. Protams, codez olimpiāžu ģēnijs kaut kādas koda vietas realizēs labāk par parastu programmētāju, bet galvenais, manuprāt, ir testi. Pat ja programma nebūs mega "optimizēta" (ar 5-zvaigžu meistaru), tā jebkurā gadījumā strādās korekti un mēs varēsim jebkurā laikā veikt pārtaisīšanu (refaktoring). Jo galvenais mērķis, vismaz man, ir strādājošs produkts.

     

    Otrajā vietā es liktu programmētāja pieredzi un zināšanas, jeb cik daudz softu ir apčamdījis un izpētījis. Es uzskatu, ka daudz vērtīgāk ir izpētīt linux kodolu, nekā iemācīties no galvas sortēšanas algoritmus.

     

    Un tikai 3. vietā es ieliktu perfektu algoritmu pārzināšanu.

  2. Inb4 rage, šeit manuprāt viss ir skaidri pateikts- http://blog.ircmaxel...ke-it.html#more

    Esmu šo izlasījis, skatos, ka codez`a argumenti lielākoties no tās vietas arī ir paņemti.

    Var paņemt kaut vai dažus citātus, kuriem es nu galīgi negribu piekrists:

    1)

    It's really easy to write working applications. It's really easy to create a large scale project.

    Ja large scale ir daudz koda un funkcionalitātes, tad es nepiekrītu. Ja large scale ir bit.ly (vai līdzīgas funkcionalitātes portāls), tad vispār vienalga ar ko to taisīt.

     

    2)

    I mean in the CMS market alone, PHP dominates by a long shot (Wordpress, Joomla!, Drupal, vBulletin, MODx, TYPO, etc). Pick a web market, and PHP will likely dominate it (if not just have a strong presence). The fact of the matter is simply that PHP is ridiculously easy to deploy. So easy that even a non-developer can do it.

    Joomlu man būtu kauns likt šajā maisā, nu bet lai paliek :)

    Ja ir vajadzība pēc CMS vai kāda interneta veikala, protams, tad dažreiz attaisnojas ņemt gatavu. Es pats lietoju vairākus php opensource projektus, piemēram, drupal, livestreet un citus. Bet kur te PHP priekšrocība? Vai ir daudz tādu programmētāju, kuri paņem drupal un tad būvē/pārtaisa līdz kādam nopietnam paštaisītam projektam? Ja jums vajag uztaisīt personīgo interneta veikalu, tad pielāgot kaut ko gatavu būs nu baigi sarežģīti — galvenā nodarbe būs ņemt ārā nevajadzīgas fīčas un tas pietuvinās jūs pie code monkey. Vai arī jūs ejat pie klientiem ar wordpress un stāstāt, ka šīs 80% pogas jums nav vajadzīgas, tikai šī "Add new entry"? Vai arī kādas problēmas jums sagādās pārtulkot drupal, kur būs 1000 valodas ierakstu.

     

    Rubijam arī ir labi projekti http://www.redmine.org/ , vai man pēc šī gribās visu programmēt ar ruby? Nē, taču. Es vienkārši šos projektus lietoju un pēc iespējas arī pielaboju, bet ja labošanai nepieciešams daudz laika un pārtaisīšanas, tad taisu savu. Jāizjūt tas kritiskais slieksnis. Un šo izjūtu var apgūt tikai paspaidot katru produktu no iekšpuses.

     

    Un jautājums mazliet off-topic: nakuj visi šitie python (lai arī cik laba valoda tā nebūtu) un citu valodu gandrīz vai idiotiski reliģiska līmeņa fanāti nāk, es atvainojos, PHP.LV forumā un mēslo savu ticību augstākiem spēkiem kā argumentus minot kaut kādas mītiskas priekšrocības?

    Es nāku un stāstu par savu pieredzi. Varbūt php.lv foruma biedrs saskatīs kādu django fīču baigi noderīgu un uztaisīt to uz PHP. Nevajag jau uz visu reaģēt kā mazs bērns, jo redz tava mašīnīte ir sliktāka.

     

    Pitons ierindas web projektiem nav un nekad nebūs labāks par PHP. Punkts. Ir jābūt tērētam lai argumentētu pretējo.

    Kāda ir pieredze ar django, ja apgalvo tādus "faktus"?

     

    Django nav pretinieku? What is this? Cake, Yii, symphony? Nope? (CI nepieminu ar domu- old and valid no more. Kohana centās, bet izskatās, ka ne visai sanāk).

    Atkal tiek saukti vairāki ietvari. Vai tiešām ikdienā visus 3 lieto? Paņem vienu un salīdzināsim. Python`am jau arī ir vairāki ietvari, bet nav jau kvantitātē lieta.

     

    Vai ir kaut viens ietvars, kurš piedāvā modeļus sinhronizēt ar mysql datubāzi? Vai administrācijas panelis, kas veidojas no modeļiem? Vienību testi ar mysql datubāzi? Un daudz kas cits.

     

    Nemec var turpināt argumentēt ar putām uz lūpām, cik čūsks ir labs un incredible, un awesome, un magical un un un un un.. krkrrkrhhhghhghh... Hello Mr Jobs. Tikai vispirms padomā, jo kāds varētu sākt iedomāties Py un Django salīdzināt ar Go un citiem new age projektiem. Diez ko tu teiksi tādā gadījumā. Ak jā, runājot par Py, v2 un v3 - kā patīk lielā migrācija? :*

    Es nebaidos, ja mans rīks novecos un būs nederīgs, vari droši salīdzināt, argumentēt un pamatot. Es neesmu mazs bērnus, kurš apvainojas, ja viņam pasaka "vecīt, tu programmē pēc vecām metodēm, jāiet tālāk". Un es eju tālāk vai vismaz mēģinu.

     

    Manī kaut kā bija radusies cerība, ka deveropeļeļi šeit ir izauguši pāri holy-war līmenim, par to, kura valoda labāka vai sliktāka, vai vēl kāda un beidzot sapratuši, ka katrai valodai ir savs mērķis. PHP ir ierindas aplikāciju izveide, ātrs deploy un med. size projekti. Py darbojas citos laukos. Node darbojas vēl kaut kur citur. C++ lapas vispār ir labi talu no visa šī cirka. Man the fuck up.

    Pats neesi pastāstījis pat par savu pieredzi. Kaut kādi sausi teksti - python`s neder lieliem projektiem un viss. Kur kaut viens arguments vai pamatojums? Liec savu pieredze uz galda, skatīsimies, vai biji izpratis līdz galam vai tik tiešām django bija nespējīgs.

     

    Ja cilvēks, kuram nav pieredzes ar python, saka, ka python/django nerullē, tad tāda cilvēka viedoklis automātiski tiek pielīdzināts nullei (bezvērtīgs). Lasīt svešas domas internetā nav tas pats kā pašam pamēģināt.

     

    Kā es jau teicu, tad pats izvēlos PHP mazām lapām, jo

    1) man nav jāčakarējas ar hostingu un varu samest uz jebkura BAnano PHP skriptus

    2) bieži vien klientiem ir paziņas hostingi (vai savi), kur parasti stāv tikai noklusētais LAMP un skaidrot par django/python vai ko citu ir lieka laika tērēšana

    3) tas ir gatavs šablonu dzinis un var uztaisīt ātri primitīvu lapu

    4) to sapratīs 95% web izstrādātāju

     

    Un es neņemšu PHP, ja man vajag kādu no šiem punktiem:

    1) pārklāt kodu ar vienību testiem (visu). Vai var normāli notestēt darbu ar datubāzi iekš PHP? Notestēt pieprasījumus? Iekš django testiem varu rakstīt arī selenium testus, to var darīt PHP ietvaros?

    2) versionēt kodu un datubāzi

    3) admin panelis

  3. Django nāk kopā ar bilžu apstrādes bibliotēku?

    Nē, django nenāk kopā ar bilžu apstrādi, jo bilžu rediģēšana nav vajadzīga web izstrādei.

    Jāuzstāda būs PIL, ja vēlies manipulēt ar bildēm. Kaut gan es dodu priekšroku imagemagick.

     

    Es tā saprotu, ka biji mēģinājis palaist PIL uz python3? Jāņem vērā, ka pagaidām python3 netiek aktīvi lietots.

     

    Nu un uz PHP arī vajadzēs uzlikt GD bibliotēkas http://lv.php.net/ma...equirements.php vai tad nē?

     

    PHP ir valoda Django ir Freimworks, manurpāt, nekorekti salīdzināt.

    Nav korekti, bet efektīva web izstrāde nav iedomājama bez laba ietvara (vai rīku kastes). Python`am tas ir django. Iekš PHP es nevaru atrast konkurentu, tāpēc arī salīdzināt nav īsti ar ko.

     

    Es runāju par PHP translētu uz C++ un nokompilētu vai PHP laistu uz hiphop virtuālās mašīnas.

    Baigi forši. Kur ir reāli dati? Ātrāks par 1% vai par 300%? Biju redzējis pieaugumus līdz 3x reizes, ja salīdzina ar PHP un hiphopPHP. Vēl varētu salīdzināt ar eaccelerator un APC.

     

    Jau biju prasījis par pieredzi, piemēram jāņem vērā tādas lietas https://github.com/f...inconsistencies

     

    Ja ir pieredze, tad es domāju, ka ne tikai man gribētos par to palasīt.

     

    Ja izmantosi populāros serverus Apache vai Nginx un WSGI/FastCGI, tad tā nebūs.

    Savukārt, kas attiecas un ne stateless pieprasījumiem, tad ar tiem ir daudzas problēmas:

    1)Izdomāsi kādu resursu dalīt starp pieprasījumiem, var gadīties, ka nevarēsi skeiloties uz 2 serveriem

    2)Ja pēkšņi pārtrūkst mysql konekcija, vai notiek kāda cita kļūda dalītā resursā, tad jātaisa speciāli monitorēšanas rīki, jātaisa pooli priekš resursu sadalīšanas. PHP stateless pieprasījumos tādas problēmas nav.

    Protams, jebkurā nepilnībā var atrast arī priekšrocības.

    Kas traucē 2. punktā veikt atkārtotu pieslēgšanos, ja ir runa par gone away erroru?

     

    Es arī neapgalvoju, ka python ir galīgs mēsls, patiesībā es python uzskatu par vienu no labākajām pieejamajām skriptu valodām un esmu taisījis pat vairāku projektus tajā, kā arī savam dēlam programmēšanu sāku mācīt tieši ar python, jo daudzas programmēšanas koncepcijas tajā ir ērti uzrakstāmas un viegli saprotamas, taču priekš web izstrādes es uzskatu, ka PHP tik un tā ir summāri labāks.

    Es nevienam netaisos pierādīt, ka python`s ir labāks. Paprogrammējiet gadu tajā un paši sapratīsiet.

    Es tikai varu atbildēt uz jautājumiem kā notiek izstrāde tajā un kā tiek risinātas manas problēmas.

  4. Es gan redzu. Ja, teiksim, Top hostinga kompānija Rackspace atver jaunu produktu - cloude storage un sākotnēji tās API ir tikai PHP bibliotēka, tad PHP programmētāji, var šo servisu izmantot uzreiz, kāmēr pārējiem ir jāraksta bibliotēka savā valodā.

    Nu ja Rackspace ir tik tuvredzīgi, tad jau viņi paši vainīgi. Django vari nohostēt iekš google apps engine un tas ir šodien, bet tu runā par abstraktu nākotni - kas varbūt kaut kad notiks.

     

    No pieredzes. Veidoju aplikāciju pythonā (ne web, jo webam izvēlos PHP), bija nepieciešama attēlu apstrāde. izrādījā, ka nāksies ņemt visai aplikācijai zemāku python versiju, jo PIL bibliotēka neatbalstīja tik jaunu.

    Slikta pieredze. Piemēram, lai iedarbinātu django, būs nepieciešams tikai pats python`s.

     

    PHP šādas problēmas nav, ja ir konkrēta PHP versija, tad visas biežāk izmantotās bibliotēkas tur ir iekšā (attēlu apstrāde, DOM/XML , cookies, sesijas, get, post mainīgo apstrāde, failu uploads, mysql, pasts), savukārt pythonā ta viss gandrīz vienmēr jāinstalē klāt + liela daļa no šīm funkcionalitātēm nav kā C moduļi, bet gan pašā pythonā rakstīti, tāpēc lēnāki.

    Priekš kam? Kam ir vajadzīgs kombains? Kā jau teicu, tad django ietver vajadzīgas web izstrādes lietas.

     

    Ne tikai ir, bet ir arī rīki, kas pie skeilošanās ir īpaši svarīgi, jo vari ātri samazināt serveru noslodzi vairākas reizes.

    Iedomājies, ka uz PHP aizņem kodēt mēneša garu aplikāciju par 2 dienām ilgāk. Darba devējam (ja tu saņem 700Ls/mēnesī) šīs divas dienas izmaksās nelielu virtuālu serveri pusgada garumā.

    Pirmais, kas mani interesē, tas ir ieguvums naudas izteiksmē no tādām priekšlaicīgām "optimizācijām".

     

    Es vērtēju valodu pēc šādiem principiem: sintakse (5%) un valodas iespējas (95%).

     

    Sintaksi var apgūt max 2 dienās. Tie, kas saka, ka template engine ir jauna sintakse, tad cik jūs sintakses lietojat? Es lietoju 12: python, django template (ja jau patīk to izdalīt kā atsevišķu sintaksi), html, haml, css, sass, javascript, coffee un dažreiz: less, shell, php, ruby. Vienai sintaksei vairāk, vienai mazāk, ko tas maina?

     

    Python valodas iespējas ir daudz pārākas, te var diskutēt ilgi (sākot ar OO un traits :)). Vai moduļu organizēšana mapēs - es nebaidos veidot 100 klases kaut vai ar vienādiem nosaukumiem. Vai piemēram, ja man vajag no datne.py mainīgo banana - vienkārši paņemam "from datne import banana". Kā to izdarīt PHP?

     

    Lai tas PHP arī neattīstīts, tad vēl ne mazāk man svarīgi ir izstrādes rīki - vienību testēšana, datubāzes testēšana, ORM utt. Vai ir kaut kas līdzīgs django?

     

    Par pašu django - es varu uzprogrammēt veselu mājas lapu neizejot no IDE:

    1) vienību testi - modeļiem, view`iem (url`s) un funkcionālie testi

    2) izlaist testus un uzrakstīt vajadzīgo kodu

    Tad viena komanda, kas nosinhronizēs jaunu datubāzi un es varu apskatīt jaunizcepto mājas lapu-aplikāciju.

     

    TDD man nodrošina kvalitatīvu kodu, kuru vēlāk es varu labot un neuztraukties, ka kaut kas saplīsīs. Tas pats arī ar jaunu kolēģu piesaisti, kuri bezbailīgi var labot jebkuru aplikācijas vietu.

     

    To es iegūstu, neatverot nekādus sql table buldier`us (ko es jau sen nedaru) un pārējos zvērus. Tikai IDE, nekādas pārslēgšanās. Vai to var iekš PHP darīt?

     

    Vai piemēram werkzeug debug tūlis. Komandrinda tur pat pārlūkā

    Vai ir kas tāds iekš PHP?

     

    Visi kā partizāni klusē blakus tēmā http://php.lv/f/topi...jektu-izstrade/, vienīgi python`ists pastāstīja par savu pieredzi. Pastāstiet man "kā jūs taisāt lielus projektus" :)

     

    PHP vs django ilgtermiņā varētu izskatīties šādi:

    python-vs-php.png

  5. Ja tev vajadzīgas tik komplicētas OOP fīčas, tas nozīmē, ka tu dari kaut ko nepareizi. Es daudz labāk dažādību, ko censtos panākt ar šādu komplicitāti, veidotu izmantojot Strategy paternu.

    Kā tu extend`o uzreiz no vairākām klasēm?

    Es vispār nevaru saprast kā var bez šīs fīčas iztikt. Un ja tas ir uztaisīts, tātad es neesmu vienīgais tāds programmētājs.

     

    Kas vainas Netbeans?

    Tas ir redaktors, nevis izstrādes rīks.

     

    Kur tad viņu nav. Toties ir daudz vairāk ekspertu kā citās valodās, tāpēc googlē var ļoti ātri atrast risinājumus jebkādām problēmām.

    Ok, tie 5% ekspertu ir vairāk nekā python`a 50%, bet piemēslots internets ar pārējiem 95% CS fanu traucē.

    python`ā arī atradīsi daudz informācijas.

    Pie tam man patīk, ka python`u lieto programmētāju giganti - google, yandex un citi.

     

    Šeit drīzāk prasās pēc jautājumu, kas ir tāds saistībā ar web aplikācijām, ko pythonā var izdarīt super efektīvi, ko PHP nevar?

    Tas pats traits PHP (jeb python mixins) un vēl daudz visādas interesantas un noderīgas lietas. Tādas pitoniskas lietas, kas attiecas uz valodu, nevis funkciju pieejamības skaitu kā tas ir iekš PHP. Python`a iebūvētās funkcijas http://docs.python.o.../functions.html

     

    Un arī pašam uztvere ir tāda, ka nav slinkums uzreiz apskatīties kā ir realizēta kāda konkrēta metode. Piemēram, iekš PHP pārsvarā nezinu funkcijas darbību, jūs zināt/skatāties?

     

    Redz, ar PHP nav jātaisa daudz kas. Ar PHP ir jātaisa webs, jo tieši tādam mērķim PHP ir radies, un taisīt kaut ko webam ar PHP ir čum vieglāk kā ar citām valodām.

    Es arī runāju par web aplikācijām.

     

    Kas attiecas uz atklāsmēm Simanovska lekcijās, tad tur īsti nevar vainot PHP, cik paša nezināšanu par to, kas tas ir un ko ēd.

    Ļoti vienkārši, kad klausījos lekcijas, tad tāda ORM vispār nebija iekš PHP vai nu baigi neattīstīts. PHP skrien pa aizmuguri un atpaliek, par to es arī saku.

     

    Nu, var jau lietot arī pliku C core un vajadzīgās fīčas piekodēt pats. Nu tur, piemēram, stringu apstrādi. Tā sanāk, ne? Vai kas nu tur, masīvu apmest otrādi vai sakārtot. C ir sūdīga, jo tur ir tādas funkcijas jau komplektā.

    Valoda nav funkciju klāsts, bet gan iespējas, ko var tajā izdarīt. Un jā, man nepatīk, ja man jau sākumā ir pieejamas 1000 iebūvētas funkcijas. Priekš kam?

     

    Ja izstrādātājs nav truls zābaks un raksta valodā ne pirmo dienu, tad tādas vispārīgas lietas jau nu pēc kāda laika vajadzētu bez īpašas mācīšanās zināt no galvas. Manuprāt.

    Kas varbūt stulbāks kā pielāgoties valodas bugiem/nepilnībām?

     

    Tieši tā, ja tiek taisīts webs, tad templeitu valoda bieži būs uzrakstīta 20%-50% no aplikācijas.

    Cik var malt vienu un to pašu? django template nav sliktāks.

     

    Lasāmāks kam? Ja nāc no C++, tad nav lasāmāks, ja esi dzimis ar python un ruby vai esi baigais funkcionālās programmēšanas paradigmas piekritējs, tad visdrīzāk ir.

    Jāpiekrīt, ka katram savs.

  6. 3)Patīkama sintakse

    Gaumes jautājums. Man tuvāk ir python sintakse.

     

    4)Plašs atbalsts, gan API un to bibliotēkas, kas parasti pa priekšu ir priekš PHP, gan plašs rīku klāsts.

    Kur ir tie rīki? Tikai viens liels treš http://www.phpclasses.org/

    Salīdzini ar http://djangopackages.com/

     

    5)Uzliec PHP un tev ir visas biežāk izmantotās bibliotēkas, kuras strādā, nevis kā pythonā, katrai lietai jāinstalē sava bibliotēka, pie tam vienai bibliotēkai pēkši ir atbalsts līdz vienai pythona versijai, citai līdz citai. Python bibliotēkām nav vienotas konsistences.

    Tur jau tā lieta, ka uzliec django un ir viss nepieciešamais web izstrādei. Uzliec PHP, nokačā no vienas puses, no otras puses dažādas lib`as, tad kādu atjauno un kāda daļa aplikācijas nolūzt.

     

    Uz normāla hostinga tev iedot pliku python2.7 un tālāk ar virtualenv tu pats saliec visu nepieciešamo. Tas pats arī ar izstrādes vidi. Vari saregulēt dependencies un ar vienu komandu visa aplikācija būs uzstādīta uz jebkura hostinga.

     

    6)Facebook uzbūvējis Virtuālo mašīnu, kas nozīmē, ka tagad PHP kods strādās pāris reizes ātrāk par Python, nemaz nerunājot par to, ka jau ilgu laiku ir pieejams kvalitatīvs PHP to C++ translators, kurš arī strādā, atšķirībā no python versijām, kuras visas ir 0.x stadijā.

    Liela pieredze ar konvertāciju? Translators nenozīmē, ka katru kodu varēsi tik viegli pārkonvertēt. Vajadzēs pašam pētīt, kas tur galā sanāk un iet visam PHP cauri.

     

    Par ātrumu nevarēšu diskutēt, jo pašam nebija vēl vajadzības taupīt uz katra sērkociņa. Kā saka, tad priekšlaicīga optimizācija ir ļauna.

     

    Es redzu trīs variantus, ja ir mērķis uztaisīt baigi optimizēti - rakstīt PHP un pa gabaliem konvertēt uz C++ (ar hiphopu), rakstīt uzreiz C++ vai izvēlēties citu valodu. Pirmie divi varianti nenodrošina ātru web izstrādi.

     

    "Optimizējiet, optimizējiet un optimizējiet tikai ne kodu, bet izstrādes ātrumu" (diemžēl neatceros autoru).

     

    Pirms teikt, ka python ir lēnāks, lūgums publicēt datus (saites), nevis izteikt pieņēmumus.

     

    Mēs varam runāt par visādām nereālām lietām, kā python ir skaists kods, python ir šāds un tāds, bet beigās visu izsaka tas, cik ātri mēs varam šipot produktu, mainīt produktu, likt klāt ņemt nost jaunas fīčas un beigu beigās arī skeilot, ne tikai uz serveriem, bet arī uz inženieriem.

    Tieši tā, es arī lieku pirmajā vietā izstrādes ātrumu, refactoringu un attīstīšanu.

     

    Tādā gadījumā, tavs bana class tiks importēts vienmēr, kamēr autoload gadījumā tikai gadījumos, kad aplikācijas loģika patiešām prasīs izmantot doto moduli. Šādā situācijā PHP, ja ir 20 bibliotēkas, kas var tikt izmantotas dažādos gadījumos, reāli tiek inklūdotas tikai, piemēram, 3-5.

     

    Piemērs tam būtu. Iet aplikācija, 1/10000 gadījumu notiek kļūda, kļuda ir jāielogo. PHP autoload gadījumā šī klase tiks ielādēta un inicializēta tikai pie pirmā reāla izsaukuma aplikācijas loģikā. Un tagad iztēlojies reāli HMVC aplikāciju, kur ir kontroleris iekš kontrolera, kur bez autoload tik ielādētas desmitiem liekas klases, kamēr ar autoload tikai tās, kuras izmantos.

    Nebūšu kompetents un nevarēšu atbildēt cik daudz norij resursus. Kā minēju augstāk, pagaidām tik detalizēta optimizācija nebija nepieciešama. Varu tikai piebilst, ka python`a skripti tiek ielādēti un gaida pieprasījumu, bet savukārt PHP tiek katru reizi ielādēti no jauna (un mysql konekcija tiek izveidota no jauna) - jau šajā posmā ir pamatīgs robs.

     

    Ar tādu optimizāciju mēs vispār varam nonākt strupceļā. OOP arī rij resursus, vai tas nozīmē, ka jāraksta visu ar funkcijām?

     

    Veidojot pavisam vienkāršu HMVC freimworku, tas ir pāris rindu kods, lai attiecīgās lietas nodrošinātu, kamēr python-ā ir jāraksta vesels template dzinējs, kurš pie tam tiek darbināts skirptu valoda, kas jau pēc definīcijas ir par kārtu lēnāka darbība - būvēt templeitu valodu skriptu valodā. Cits gadījums protams, ja tiek uzbūvēts C python modulis, bet šeit atkal būs daudz citas problēmas. Kamēr PHP skaisti visu rakstām PHP, gan aplikāciju, gan templeitus. Manā skatījumā tas ir liels pluss.

    Man ietvars neasociējas ar pāris rindām koda, bet gan ar kompleksu izstrādes rīku.

    Šablonos jāattēlo dati, tāpēc ar šablonu dzinējiem (iebūvēts django) nav nekādu īpašu problēmu, lai uzskatītu to par trūkumu.

     

    Tā ir elementāra loģika. Tikai pasaki, ka tu pythonā esi būvējis heštabulas, binary search tree, grafus, segmentu kokus, intervālu kokus, vispār sarežģītākas datu struktūras un algritmus, analizējis lielo O? Nu nedara tādas lietas tajās valodās, bet šādu lietu darīšana ir būtiska, lai izprastu softa ātrdarbību, efektivitāti, pareizu lietošanu. Tādas lietas dara C/C++, arī Paskālā, iespējams arī JAVĀ.

    Jāpiekrīt, ka kaujas laukā (darbā) reti man gadās tādas lietas bīdīt. Es saprotu, ka visi darbojas ar augsti apmeklētām sistēmām (vismaz twitter`s) vai taisa raķešu sistēmas. Tomēr es pētu dažādus algoritmus, patīk paspēlēties ar uzdevumiem. Un kaut kā neesmu manījis uzrakstu "warning, don't do it with python".

     

    Tās pašas top programmētāju sacensības, IOI, ACM ir C/C++.

    Kas traucē tos taisīt ar python`u? Tas ir aizliegts?

     

    Google? Nekad nav bijusi problēma atras vajadzīgo lietu PHP, izmantojot google. Parasti kādu lietu priekš PHP, ko nezinu no galvas, atrodu 10-20 sekunžu laikā izmantojot googli.

    PHP manuālis ir ērts, jāpiekrīt, bet python manuālim arī nav ne vainas - ierakstam terminālī help({}) un man tiks attēlota visa informācija par dict. To pašu help terminālī varu izmantot uz jebkuru bibliotēku, kaut vai uz paša rakstīto.

  7. Tās īsti nav alternatīvas:

    1)Piemēram PHP autoload funkcionalitāte, kas padara PHP aplikāciju struktūru un atsevišķu daļu rakstīšanu super ērtu, nav ne ruby, ne python-ā

    2)Tā kā web izstrādē bieži jāraksta templeiti, tad rakstīt tos PHP valodā ir ērti, nav jāapgūst kaut kādi papildus templeitu dzinēji, kā tas ir ruby un pythonā.

    3)Īsti koderi nāk no C++, PHP sintakse neprasa lieku piepūli, jo ir ļoti līdzīga c++ sintaksei, atšķirībā no ruby un python.

     

    Tā varētu turpināt un turpināt.

    Es piekrītu, ka var piesieties PHP dažās vietās, bet citās valodās šo trūkumu ir vairāk.

     

    Salīdzinājumā ar python

     

    1. To gan jau var implementēt, bet kā tas darbosies? Jo klases ar vienādiem nosaukumiem var atrasties dažādās vietās.

    Normālā IDE rakstot "BananaClass()" uzpiežot "alt+enter" tiek ielikts koda augšā "from app.banana import BananaClass". Pieņemsim, ka "BananaClass" atrodas vēl 5 vietās un mana IDE parādīs visus variantus.

    Varbūt es līdz galam nesaprotu lietderīgumu, bet kas traucē uzrakstīt vienkāršu funkciju get_class('BananaClass')? Mazliet citā kontekstā, bet līdzīgi daru iekš javascripta.

     

     

    2. Nodrāzta tēma. Cik var atkārtot, ka pliks PHP nenodrošina visas šablonu iespējas: extend`ošana, escape`ošana utt.

     

    3. Tas ir tāds mierinājums vai kāda reāla statistika?

     

     

    PHP man patīk, jo:

    1) Drag&drop un gatavs, nav problēmu ar hostingu

    2) Ļoti mazs ieejas koeficents - jauniņais pēc nedēļas jau varēs taisīt nelielas lapas

    3) Var lietot bez MVC kā parastu template valodu

    4) Var ātri atrast palīgu/darbinieku, jo katrs taču prot PHP

     

    nepatīk:

    1) neloģisks un nesaprotams - jārakājas pa php.net un jāmeklē strlen un līdzīgas funkcijas

    2) atpaliek no citam valodām un pie tam pamatīgi (piemēram, PHP traits)

    3) nav ērtu izstrādes rīku

    4) pilns ar lameriem

    5) nav normāla ietvara ar ORM, admin un citām iekļautām fēčām (līdzīgi django python)

     

    Pats izvēlos PHP vienkāršām statiskām lapām, tur kur tādu django darbināt ir salīdzinoši sāpīgi. Un tas tikai tāpēc, jo man nav sakārtota masveida mājas lapu likšana, jo šobrīd tas nav aktuāli.

     

    Es saprotu PHPistus, kuri saka, ka PHP ir labs un ar to daudz ko var taisīt. Tikai viena problēma, lai objektīvi novērtētu PHP vs python (vai ruby), tad sākumā jābūt PIEREDZEI, viss pārējais ir tikai svešas domas un tukša runāšana.

     

    Atceros, kā pats apmeklēju Raimonda Simanovska (ruby.lv) lekcijas un īsti neizpratu tādus vārdus kā ORM, TDD. Un tagad saprotu, ka nav jēgas ietiepīgiem programmētājiem stāstīt, cik citur ir labi. Tas ir vienkārši fakts, jums tikai jāatrod laiku un jāpamēģina.

     

    Es jau labu laiku strādāju ar python. Varētu teikt, ka mācījos programmēt no jauna, jo iekš PHP tā bija kaut kāda šablonu rakstīšana vairāk. Python ir tik spēcīgs, ka es vēl joprojām neesmu tajā visu izpratis.

  8. Vispirms lai veidotu lielus projektus ir jāizstrādā kārtīgs biznesa plāns, modulis, jāsaliek viss uz papīra jau projekta izstrādes sākumā. Šis plāns vienmēr var kalpot kā ieskats tam, vai izstrāde un veiktie projekta darbi atbilst sākumā uzstādītiem mērķiem.

    Laikam neprecīzi biju uzdevis jautājumu. Mani neinteresē kā tiek ģenerēts biezais specifikācijas plāns, bet tieši izstrāde. Vispār mēģinu izvairīties no klientiem/partneriem ar biezu plānu uz nākotni, jo esmu vairāk elastīgas izstrādes piekritējs.

     

    Ja pie manis atnāk un vēlas uztaisīt interneta veikalu ar 100 iespējām un termiņu 6 mēneši, tad es visdrīzāk atteikšos. Tajā vietā labāk uztaisīt pirmo versiju ar tikai pašām svarīgākām lietām pa nedēļu, palaist, un skatīties kādā virzienā jāattīstās. Biznesam ļoti bieži vien būs izdevīgāka pēdējā pieeja, jo:

    1) ātrāk — jau pēc nedēļas varam sākt tirgot

    2) lētāk — nedēļa darba maksās mazāk nekā n mēneši

    3) efektīvāk — jau pēc pāris nedēļām varam sākt pelnīt

     

     

    Pirms lielu projektu sākšanas, ir jāparedz pareiza naudas plūsma, izlietojums, investīcijas, utt.. jo bieži vien ir tā, ka projekts tiek izveidots, bet bieži vien vajadzīgi kaut kādi uzlabojumi, jaunas iespējas, kas nebija minētas un domātas pašā sākumā, bet reāli bieži vien daudzi aizmirst to, ka jebkurai papildus lietai, idejai ir vajadzīgi jauni, jeb papildus resursi, lai ideju spētu īstenot dzīvē.

    Par naudu un investīcijām jādomā projekta vadītājam (uzņēmuma vadītājam).

     

     

    Šis bija neliels tāds izstrādes posma apraksta sākums, jo neviens domāju par velti tev neveidos un nestāstīts "Aprakstiet visu projekta izstrādes posmu." Jeb vārdu sakot, neveidos nezināma projekta specifikāciju.

    Es jau neprasu biznesa noslēpumus, bet gan padalīties ar izmantotām tehnoloģijām, metodoloģijām un jaunumiem.

     

    Šī brīža projektā tiek izmantots Git+GitHub, testa/build Jenkins serveris ar instancēm katram izstrādātājam.

     

    Parastā izstrāde:

    Pastāv kopējais repozitārijs, kuru izstrādātāji forko. Izstrādā fīču / sataisa bugu. Parasti jaunai fīčai uzreiz arī uztaisa unit testu, retāk - selenium testu.

     

    Nokomito savā repo un Jenkins sabūvē versiju uz testa servera, palaiž testus (unittesti + selenium testi). Ja testos viss ok, tad taisa pull request, kur piemin attiecīgo ticketu un linku uz build rezultātu.

     

    Tālāk ir 2 team leadi, kas var kodu samergot ar kompānijas repo, nokomittot un attiecīgi tiek palaists build uz galvenās testa instances. Ja kaut kas pull requestā nepatīk, tad nemergo, bet pieraksta komentārus kodu.

     

     

    Jaunas versijas + patchi:

    Normāli tiek izmantots master zars, bet, liekot produkcijā versiju, tai tiek uztaisīts savs zars. Ja ir kaut kādas atsevišķas lietas, kas jāsataisa produkcijas versijā, nesavienojot ar galveno zaru, tad izstrādātāji attiecīgi strādā ar šo zaru.

    Paldies par pirmo saturīgo atbildi.

     

    Izskatās, ka pa lielam tiek lietots šis modelis http://nvie.com/post...ranching-model/

     

    Vai ir grūti/viegli saregulēt tādu sistēmu — projekta lasīšanu kopā, jenkins uzstādīšanu?

     

    TDD:

    Netiek lietots. Mans personiskais viedoklis - labiem izstrādātājiem tam nav būtiski labumu, bet, iespējams, tā saku tikai tāpēc, ka pašam nav bijusi prakse.

    Atzīšos, ka man arī maz pieredzes.

    Tā kā rakstam testus sākumā, tad pats lielākais ieguvums ir, ka viss kods tiek pārklāts ar testiem. No tā izriet, ka arī paša koda ir mazāk, jo kods rakstās tikai lai apmierinātu testus. Un parasti pat nevajag kodu skatīties, bet pietiek vien atvērt testus, lai saprastu kas tur notiek. Un protams lielāka drošība, ja vairāk testu.

     

    Jaunu izstrādātāju iesaiste:

    Darbu sāk ar forku GitHubā. Tur ir arī readme fails, kur aprakstīts, kā uzstādīt vidi pie sevis.

    Parasti pirmie uzdevumi ir kādi mazi bugi vai citi vienkārši taski. Tā kā kopējais process ir ar pull request, tad viņu kodu uzreiz var arī pārbaudīt pirms pievienot galvenajam repo.

    Kāpēc netiek ļauts jauniem speciālistiem labot arī kādas galvenās lietas? Ar to ir kāda slikta pieredze? Jo, ja tiek izmantoti daudz testu, tad it kā nevajadzētu rasties dižām problēmām :)

     

    Teoriju vari palasīt grāmatās, PHP projektu praksē ir tā, ka pirmā versija ir šausmas, otrā versija ir pirmais mēģinājums tikt pāri šausmām, trešajā versijā visi jau saprot, kas ir Framework, versiju kontrole un procesu vadība, ceturtajā versijā jau kaut kas jēdzīgs sanāk un cilvēki uz darbu iet ražot, nevis lipināt un workaroundot. Tas tā, īsumā.

     

    Liela, laba projekta pazīme ir projekta vadītājs, galvenais programmētājs, kurš nosaka toni, versiju kontroles sistēma, uzdevumu vadības sistēma, dokumentācija, iknedēļas sanāksmes.. arī īsumā. Parasti sākumposmā daudzi komponenti iztrūkst un projekts vairāk vai mazāk tiek balstīts uz veiksmes faktoru tādā ziņā, ka paveicas, ja programmētājs ar to tiek galā, bet gadās, ka gads(-i) iztērēti un rezultāts ir nekāds, procesā iesaistītie arī tikpat dumji, cik bijuši, tik palikuši.

     

    edgarsj aprakstītais variants ir tāds jau diezgan labs.

    Nepiekritīšu, ka laba projekta pazīme ir kaut kādi vadītāji vai programmētāji.

    Ir uzņēmumi, kur vispār nav nekādu vadītāju un galveno programmētāju. Visi programmētāji ir vienlīdzīgi un var taisīt jebkuru feature/bug/hotfix. Tam ir savas priekšrocības un daži mīnusi.

     

    Laba projekta pazīme ir:

    1) cik ātri spēj iekļauties jauni kolēģi (tas pats būtu, tikai otrādi — cik sāpīgi ir darbinieku aiziešana)

    2) cik ātri tiek ieviestas jaunas iespējas — produkta attīstība

    3) kā strādā paša programma — vai nav viss caurumos

    4) kā un cik ātri tiek taisīti ātruzlabojumi (hotfix)

     

    Lai šo panākt, tad ir daudz rīku un metodoloģiju. Tieši tas mani arī interesē.

     

    Pie iepriekšējā pavisam aizmirstu aprakstīt ticketing sistēmu + izmantoto scrum metodoloģiju. Ja ir interese, jautājiet.

    Vai scrum metodoloģiju lietojāt uzreiz vai pārgājāt no kādas citas?

    Ja nav noslēpums, tad kas tas par projektu?

    Vai jūs taisāt vienu projektu, vai arī tie ir vairāki?

     

    Tīri intereses pēc pāris jautājumi par Scrum un projektu .........

    Jautātās problēmas ir draugiem.lv kolektīvā? :)

  9. Pirms pāris gadiem man bija līdzīgs jautājums pašam sev. Es vēlējos bēgt no PHP un mācījos python.

    Nevajag skatīties kas ir populārs tirgū (darba), mani, piemēram, sauc arī PHPisti uz pārrunām, jo saprot, ka ar python`u varbūt varēs darīt lietas ātrāk un labāk. Galvenais būt valodas meistaram.

    Tad noteikti jāņem moderna valoda, nevis oldskūlu kaut kādu, kur vēl visa izstrāde notiek vecajās tradīcijās. Lai uzreiz ir pieejami spēcīgi rīki vienību testēšanai, UI testēšanai utt.

     

    Es ieteiktu ņemt ruby, ja vēlies taisīt TIKAI mājas lapas. Un ja vēlies ne tikai mājas lapas, bet arī kādu programmu uztaisīt, tad ieteiktu python. Python`s tāds universāls, kas der ļoti daudzām lietām.

  10. Kā notiek ilgtermiņa projektu izstrāde jūsu uzņēmumos? Piemēram, draugiem.lv projekts, kas nekad nebeigsies un to būs jātaisa, jālabo, jāattīsta utt. Aprakstiet visu projekta izstrādes posmu. Kā tiek taisīti hotfix, versijas (successfull git branch model)? Vai tiek lietots Test Driven Development? Kā tiek iesaistīti jauni programmētāji?

  11. Programmētājiem ir ļoti smags darbs. Tas ir kā fiziski strādāt mežā, bet ar galvu. Un tas krasi atšķiras no pārējiem amatiem.

    Kā piemērs, programmējot nevar domāt par sievu un bērniem, bet rokot grāvjus var droši to darīt. Ir vajadzīga pārāk liela koncentrācija. Piemēram, iedzerot pat 0,5 alus, jau nevarēsi normāli spriest algoritmus, tajā pašā laikā grāvi varēs droši rakt arī pēc 0,5 šņabja. Tas pats ar neizgulēšanos.

    Es pats, veicot kādu fizisku darbu (piedalos talkās un līdzīgos pasākumos), tikai tad saprotu cik viegli ir strādāt fiziski, kad galva ir brīva :) Pamēģiniet!

  12. Es ieteiktu aiziet pastrādāt kādā darbā, kas nav saistīts ar programmēšanu. Par programmētāju, vai nē, tas nav svarīgi. Apskaties uz dzīvi ar citām acīm. Pat krāvējs derēs :D

     

    Vispār šo variantu ieteiktu ļoti daudziem IT meistariem-bīdītājiem. Skatos kādi jauni produkti uzražojas dzīvē — todo listi, taks menedžeri un vēl 100 līdzīgu un nodrāztu produktu. Tajā pašā laikā krāvēji "varbūt" raksta visu uz papīra. Tas tā, radošuma paaugstināšanai.

  13. Es uztaisu git glabātuvi, tad izdaru (commit) izmaiņas, vēlāk palaižu tādu skriptu https://github.com/termilv/git-2-commits-difference-patch/blob/master/patch.py un tas uztaisa man datņu paku (zip) ar mainītām datnēm no pēdējām izdarībām.

     

    Vispār tam visam var izmantot kādu MakeFile (piemēram twitter bootstrap https://github.com/twitter/bootstrap/blob/master/Makefile ).

    Ja patīk python`s, tad labs ir http://docs.fabfile.org/en/1.4.0/index.html

  14. Vai man vienīgajam interesē kā codez organizē versiju kontroli + testēšanu, par kuru stāsta?

     

    2)Nē, tas ir tieši MVC ietvara uzdevums. Bet lietas būtība ir nedaudz savādāka. Vienreiz nedēļā/divās/mēnesī tiek uzpdeitota live aplikācija, viss, kas pa nedēļu pabeigts, tiek laists dzīvajā. Pēc tam, kad uz webserveriem ir iesūtīta jaunā versija, kuras kontrolieri atroda vielaikus ar vecākām versijām, tiek iedarbināts jaunās versijas palaišanas mehānisms - sākumā paši notestē, tad palaiž uz nelielu skaitu lietotāju, pēc tam, ja kļūdas netiek detektētas, jaunā versija tiek palaista uz visiem. Kāpēc tas ir MVC ietvarā? Tāpēc, programmētājs neko nezin, par versijonēšanu, viņš updeito vecos kontrolerus ar saviem uzlabojumiem, bet serverī MVC nodrošina šo versiju pakāpenisku un kontrolētu pārēju. Pie tam automātiski atceļ updeitošanu, ja jaunā versija sāk mest ietvaram detektējamas kļūdas.

     

    Kā pārējie to dara?

  15. 2)Nē, tas ir tieši MVC ietvara uzdevums. Bet lietas būtība ir nedaudz savādāka. Vienreiz nedēļā/divās/mēnesī tiek uzpdeitota live aplikācija, viss, kas pa nedēļu pabeigts, tiek laists dzīvajā. Pēc tam, kad uz webserveriem ir iesūtīta jaunā versija, kuras kontrolieri atroda vielaikus ar vecākām versijām, tiek iedarbināts jaunās versijas palaišanas mehānisms - sākumā paši notestē, tad palaiž uz nelielu skaitu lietotāju, pēc tam, ja kļūdas netiek detektētas, jaunā versija tiek palaista uz visiem. Kāpēc tas ir MVC ietvarā? Tāpēc, programmētājs neko nezin, par versijonēšanu, viņš updeito vecos kontrolerus ar saviem uzlabojumiem, bet serverī MVC nodrošina šo versiju pakāpenisku un kontrolētu pārēju. Pie tam automātiski atceļ updeitošanu, ja jaunā versija sāk mest ietvaram detektējamas kļūdas.

     

    Pastāsti sīkāk, kā tas ir realizēts pie tevis. Ja vari, tad būtu forši arī kodu redzēt (github?)

     

     

    Vēlreiz, kas attiecas uz MVC, tad tas ir boot fails, kontrolera, routera, modeļa un viewa ietvars. Tas nav nekāds kosmoss, lai to uzrakstītu dienas vai divu laikā, kas attiecas uz visām pārējām klasēm: db, memcahced, bilžu apstrādes, utt. utjp. tad tām nav tieša sakara ar MVC un tās es arī bieži izmantoju jau gatavas.

    hmm, tiešām?

    Ja programmē twitter, tad protams tev nederēs tie "lēni" kombaini. Nu bet ja pieņemam, ka programmē vidēji sarežģītas lapas. Kaut ko pa vidu, starp facebook un vizītkarti.

     

    Es saprotu, ja aug skills, tad saproti kur kādam ietvaram ir caurumainas un neloģiskas lietas. Var rīkoties visādi - uzlabot esošo, mainīt ietvaru, mainīt valodu, taisīt savu. Ja izvēle krīt uz pēdējo, tad jātērē daudz laika (tātad naudas).

    Man MVC ir

    • komandrinda, lai var manipulēt ar kodu - atjaunot datus datubāze, veidot aplikācijas utt
    • ORM
    • datubāzes versijas - mainu modeli, iekopēju produkcija, viena komanda un man ir jauna schema sql ielādēta
    • vienību testi - gan atsevišķu koda gabalu, gan pieprasījumu (web aplikācijām - get un post dati)
    • konfigurācija - vienā vietā
    • auto admin - jā, man nepatīk bakstīties phpMyAdmin vai konsolē
    • šabloni
    • formas. Labi ja var veidot pa taisno no modeļiem.
    • forši ja ir jau kaut kādi gatavi skripti, piemēram modeļa saraksta izvadīšana, paginator un pārējie labumi
    • csrf aizsardzība
    • lietotāju pārvaldība

    Noteikti vēl šo sarakstu var ilgi turpināt. Ja nevari atrast labu PHP ietvaru, tad varbūt pamēģini ruby, java, python?

     

    Vai ko tādu varēsi salasīt pa 2-3 dienām?

  16. Redz, linkus mest viegli, bet vai iedziļināties lietas būtībā?

    Nē, jo man tas nav aktuāli un mans laiks ir dārgs.

     

    Stāstīt, ka taisi kaut ko unikālu, kas nav pa spēkam pārējiem monkey arī ir viegli.

    Nopublicēt savu risinājumu, salīdzini ar citiem (ar manām saitem http://www.gaia-gis.it/spatialite/)! Dabū atsauksmes no pārējiem programmētājiem, nevis sēdi šeit forumā un pierādi ka esi ar ko labāks par citiem.

     

    Pirms tērēt mēnesi sava algoritma realizēšanai, tad es noteikti veltītu vismaz nedēļu esošo risinājumu izpētei. Vai ir veikta tāda izpēte?

     

    Izklausā pēc izaicinājuma? Tātad piedāvāju tev pierādīt savu teikto un uztaisīt to. Lai projekts būtu pārbaudāms, vajag vienu lapu, kurā augšā ir karte, kas ar ajax ielasa 50 svarīgākos ierakstus no viewporta un vajag lapojamu ajax tabulu, kurā ir visi objekti ar koordinātēm un svarīgumu.

    Galīgi jocīgs, bet tu man samaksāsi? Vai arī vēlies lai es pa velti veselu mēnesi kaut kādam iedomīgam tipam forumā kaut ko pierādu.

    Varbūt vēlies man kādu sviestu pierādīt un parisināt uzdevumus ar Slēptā Markova modeļiem (HMM)? Būs pa spēkam?

     

    Atšķirībā no tevis, es nesaku, ka tas kurš nezin HMM nav derīgs programmēšanai. Ja šim cilvēkam vajadzēs, tad viņš noteikti apgūs šo vielu.

     

    Kāds sakars gudrībai un zināšanām ar opensource? Opensource tā ir filozofija, kurai ar gudrību ir maz sakara.

    Kas attiecas uz saviem projektiem, tad kāpēc tu domā, ka šeit cilvēki neveido savus projektus? Domāju, ka daudzi veido. Piemēram, es sen jau vairs pie neviena nestrādāju, jo dzīvošanai pietiek no saviem jau esošajiem projektiem un turpinu taisīt citus savus projektus. Bet ne par to šeit tagad ir runa.

    Sakars tāds, ka es vēlos redzēt darbus, nevis pliku runāšanu.

    Visu algoritmu uzbūves pārzināšana ir tikai teorija. Kaujas laukā pavisam citi noteikumi.

  17. Tas, ka jūsu PHP atpaliek no pārējās pasaules es neesmu vainīgs. Apskaties kādi ORM manager`i sarakstīti citās valodās https://docs.djangoproject.com/en/1.3/ref/contrib/gis/ (codez`a geolokācija :)). Un ja šajā gadījumā codez taisīja savu, bet ir jau izveidots/iztestēts labāks, tad esam nonākuši pretrunā:

    Hehe, nu ja. Tikai nezkāpēc pēcāk man kādā brīdī sanāk šādi uz buj-duj sarakstītos kodus labot, jo "viss bremzē", jo izrādās, ka "putrogrammētājs" ir kādā vietā "implementējis" O(N^2) "algoritmu". Kamēr bija 10 ierakstu ("testa case") taču "viss darbojās" :D

    Paspaidīt citas valodas un citas datubāzes jau tikai monkey var iedomāties, akadēmiķis ar saviem algoritmiem kapā svaigu variantu. Tas protams nav tik slikti, vienīgi tiek zaudēts dārgais laiks.

     

    Es esmu pilnīgi pārliecināts, ka codez`a uzdevumu atrisinās jebkurš programmētājs tādā vai citā veidā. Interesanti cik smuki pats viņš ir atrisinājis šo uzdevumu. Atgādināšu, ka darba devējam tas izmaksātu ~ 2000Ls.

     

    Es jums vēlreiz prasu, ja jūs esat tik "gudri" programmētāji, tad kāpēc nepiedalāties kādā opensource vai neveidojat kādu savu projektu? Codez varētu uzlabot šo projektu http://www.gaia-gis.it/spatialite/.

    Jūsu pļurkstēšana man neko nenozīmē, rādiet savus darbus.

×
×
  • Create New...