edgarsj

Aicinu pievienoties vispasaules Stack Overflow saieta Rīgas versijai. Laiks nākamsestdien (28. aprīlis) 18.00, vieta atkarībā no cilvēku skaita būs kāds krogs Rīgā vai arī TechHub Rīga telpas. No sevis varu pastāstīt pozitīvo pieredzi izmantojot careers.stackoverflow.com darba atrašanai. Vai pastrīdēties par programmēšanas valodu priekšrocībām un trūkumiem :)

Un punktus, kas bija apspriežamajā rakstā, par php mīnusiem mēs neskaitam? man šķiet tur bija vairāk par 14. It īpaši pēc šīs visnotaļ neizprotamās skaitīšanas sistēmas. Labi, tas bija mans pēdējais jautājums šajā diskusijā. Apsveicu codez ar uzvaru :)

Un ko tu ar to gribēji pateikt? Ka meklēšanai Scala / Java / Lucene ir labāks par RoR? Un nepieminēt to, ka PHP kā valoda vispār pat nav apsvērta lietot Twitter. Tam nav nekāda sakara ar diskusiju par to, ka PHP būtu labāks par Python/Ruby/whatever. Kā jau biedrs swiers rakstīja, normālās valodas iebūvēts autoload mehānisms nav nepieciešams, jo to programmētājs ar tādu nepieciešamību var ar pārdesmit (vai mazāk) rindu kodu mierīgi uzrakstīt pats. Te pāris linki par to Pythonam, par Ruby jau atbildēja -http://stackoverflow.com/questions/1024455/autoload-in-python http://code.activest...recipes/473888/ Tas tikai liecina, ka PHP kā valoda ir sūdīga. Ok, tātad Python nav templeitu valoda, tas ir mīnus programmēšanas valodai, tā arī pierakstām :). Viedokļi dalās, liela daļa cilvēku uzskata, ka Python kods ir lasāmāks un īsāks. Manā uztverē tas ir liels pluss. Es neredzu būtisku PHP priekšrocību šajā ziņā, bet lai būtu. Par vienotu konsistenci salīdzinājumā ar Python ņirgājies vai kā? Rakstu lasīji? Stdlib arī Python ir. Un par versijām runājot, gribi teikt, ka PHP versiju maiņa bibliotēkas nekad nekādi neietekmē? Bet nu labi, aiz ausīm pievilkts punkts / viedoklis. PHP ir ātrāks un vieglāk pārnesas uz C++. Ok. tā arī vajag teikt, nevis rakstīt basņas par Facebook. Skeilošana uz inženieriem nav valodas īpašība. Par pārējo - absolūti neredzu PHP priekšrocību, gluži otrādi. Ar visiem šiem aiz ausīm pievilktajiem argumentiem gļuku saraksts ne tuvu nav tik liels, kā pirmajam diskusijā minētajam rakstam. Turklāt lielākā daļa neattiecas uz valodas dizainu kā tādu. Es saprotu, ka mēs viens otru nepārliecināsim, tāpēc arī netaisos vairs censties. Normāli izstrādātāji lielu daļu ne ikdienā izmantotu lietu neiekaļ, bet atceras pēc loģikas. Un ja loģikas programmēšanas valodā nav, tad nu sorry. Pilnīgs bullshit šis komentārs.

Offtopic, vienkāršām lietām var derēt Flask. Es te nedaudz ievērtēju nelielam IE buga testēšanas kodam - https://gist.github.com/2169344. Paliek tikai jautājums par ātru/standarta wsgi deploymentu.

Ja jau PHP ir tik labs, kāpēc Twitter to neizmanto un nekad nav izmantojis? Tu uzdod nepareizus jautājumus. Tas, ka ir lieli projekti, kas izmanto konkrētu valodu, nenozīmē, ka valoda ir izcila. RTFA. Joprojām gaidu Python trūkumu sarakstu. Ar uzsvaru tieši uz valodas trūkumiem un nekonsekvenci kā augstāk minētajā ierakstā par PHP.

Šis jautājums codez kungam gan joprojām aktuāls. Galu galā diskusijā iesaistījos, lai noskaidrotu, kas tad ir tās Python problēmas, kas ir lielākas par PHP problēmām :) " citās valodās šo trūkumu ir vairāk"

Atgriežoties pie valodu izvēles, atkārtošu vēlreiz - katram savs. Ja patīk C++, tad drošvien arī ar PHP problēmu nav. Ja ir vēlēšanās pēc īsta OO un valodas viengabalainuma, tad jāmeklē kas cits. Man ir paveicies, ka web izstrādes jomā varu strādāt valodā, kurā tiešām patīk strādāt.

Muļķības. PHP Facebook tiek izmantots galvenokārt vēsturisku iemeslu dēļ, gluži kā draugiem.lv. Ātri sahakoja kaut ko kopā ar php un pēc tam arī turpina. Savukārt par top izstrādātājiem pasaulē pastāv cits viedoklis - tiešām labu izstrādātāju procents ir lielāks Python/Ruby/Lisp/Groovy etc valodās nekā PHP/Java/C#. Jo sevi cienošs cilvēks ar sūdu nestrādās. Atkārtošos, par to nav runa. "LOL - jau minētajā rakstā "Do not tell me that Facebook and Wikipedia are built in PHP. I’m aware! They could also be written in Brainfuck, but as long as there are smart enough people wrangling the things, they can overcome problems with the platform."" Piekrītu, ka tas palīdz. C valodas minēšana man gan tīk daudz labāk nekā C++. Bet neuzskatu, ka tu esi koderis tikai tad, ja vismaz pāris gadus esi ikdienā C++ strādājis. Laboju, "koderis" varbūt arī esi, bet labu izstrādātāju tas nebūt nedefinē.

LOL - jau minētajā rakstā "Do not tell me that Facebook and Wikipedia are built in PHP. I’m aware! They could also be written in Brainfuck, but as long as there are smart enough people wrangling the things, they can overcome problems with the platform." Python app piemēri - http://www.reddit.com, http://instagr.am (nupat Facebook viņus nopirka par $1 000 000 000. Izstrādāts ar 6 developeriem), http://disqus.com. Un man un pāris citiem zināmiem cilvēkiem, produktivitāte lielāka ar Python, nevis PHP. Tas arī par nto fīču ātru izstrādāšanu. Un tieši no šādas prasības arī radies Django web framework. P.S. LOL 2x

Vai vari parādīt saiti uz kādu rakstu, kur Python problēmas, nekonsekvence utt, būtu izķidātas kaut uz pusi tik lielā apmērā kā http://me.veekun.com...-of-bad-design/ ? Bet vispār jau katram savs, kam PHP "čik čik, lai tik ātri kaut kas kaut kā strādā" ideoloģija ir tuva, tam būs grūti izprast Python eleganci un viendabīgumu.

Drošvien lielajā teksta blāķī bija grūti pamanīt, ka izmantojam Selenium klienta puses automātiskai testēšanai. Un Python, ne PHP ;) Un ir nianse, Selenium testus laižam uz 3 pārlūkiem - Chrome, Firefox, IE8. Visi trīs kopā aizņem ap 1200 sekundes, ir kādi 40+ testi.

Labs jautājums. Var palīdzēt triki ar testu datubāzes turēšanu atmiņā. Tāpat standarta pieeja ir visu db katrreiz no jauna taisīt (, bet var jau arī ar konkrētu test db, kur testu transakcijas reverso, kas sanāk jūtami ātrāk. Mums tagad ir ap 130 unittestu, izpildes laiks ~300 sekundes uz amazon EC2 kastes, izmantojot amazon mysql servisu (neatceros kā saucās). Noteikti var optimizēt ar lokālu mysql+ramdisku. Bet gadās visādi - pirms tam atklājās, ka ir viens performances bugs, kuru pamanīja, jo unittesti izpildījās 4x ilgāk.

Par modeli - tā arī ir, jā. Jenkins + automatizēti buildi ir vienkārši. Tāpēc fui pē visiem ar palieliem projektiem bez normāla Continuous Integration rīka. Projekta lasīšana kopā - vienkārši, bet manuāls darbs. Bieži vien gadās, ka vienam cilvēkam diena aiziet, integrējot pārējo sastrādāto. Nav tā, ka nevar ķerties pie galveno lietu labošanas. Vienkārši efektīvāk cilvēkam iemācīties, kas un kā projektā notiek, ja ir uzdevums, kur programmēšana prasa labi ja 5%, bet saprašana 95% un tas aizņem dienu vai divas, nevis mēnesi. Ātrāk var redzēt kā sanāk un palīdzēt, ja nepieciešams. Par programmētājiem taisnība, bet manā modelī ir kāds galvenais, kurš nodarbojas ar visa savilkšanu kopā un pārbaudi. Tā teikt, procesa uzturētājs, kas īstenībā nav nekāda privilēģija, jo visnotaļ garlaicīgi. Un kādam arī jābūt, kurš pieņem sākotnējos lēmumus par procesu utt. Ar pilnīgu demokrātiju ir grūti, jo ir jautājumi, par kuriem var strīdēties līdz bezgalībai un vienotu viedokli nepanāks. Izmantojām uzreiz. Patiesībā neesmu nekad bijis projektā, kurš pēkšņi ieviestu scrum. Ir parakstīts NDA. Tāds sarežģīts multitenancy SaaS web risinājums. Izmantotās tehnoloģijas - Python, Django, JQuery,MySQL, ir API mobilajai klienta aplikācijai. Viens projekts.

Piezīme, mūsu konkrētajā gadījumā visi strādā attālināti, tāpēc nav tīrs scrum un dažas lietas normālā gadījumā būtu citādāk. izstrādātāji ir 7-8 1 nedēļa, bet domāju, ka klātienē strādājot būtu 2as. 1 nedēļa palīdz labāk turēt roku uz pulsa. Relīzes uz produkcijas vidi parasti ir neatkarīgas no sprintiem. Normālā gadījumā ir aptuveni reizi mēnesī. Toties uzreiz pēc tam bieži vien nākas taisīt patch relīzes. Tāda dzīve. QA nav stiprākais. Metam iekšā. Parasti tie ir bugi, tāpēc saprotams, ka vajag. Godīgi sakot, nav liela saspringuma par to, vai sprinta laikā izdara plānoto. Saspringums parādās, ja ir mazs t.s. velocity pāris sprintus pēc kārtas. Veicam. Ja ir, kas strādā pie lielās fīčas, tad vadītājs parasti jautā, kā iet ar to fīču. Normāli ir, ja pastāsta progresu, problēmas. Gadījumā, ja kas ievelkas, uzreiz arī palūdz, lai kāds cits arī paskatās un palīdz risināt. Vienam savā nodabā jau viegli uzsēsties uz kaut ko. Ticketing sistēma - Pivotal Tracker. Ar jaunām fīčām darba process aptuveni tā: Produkta owneris (ļoti retos gadījumos kāds cits) uzraksta aptuveni vajadzīgo, ieliek Icelogā, pēc tam pats vai ar team lead palīdzību nedaudz noprecizē, pieliek label: estimate. Iknedēļas lielajā plānošanas sanāksmē (izmantojam webex) komanda kopā piešķir estimate. Pārceļ uz backlog. Product owner skatās, lai backlog secība atbilstu biznesa vajadzībām. Kad izstrādātājam nav ko darīt, tad paņem ticketu no backlog (retos gadījumos tiek sadalīti iepriekš pēc uzdevuma tipa) un sāk darbu. Ja ir jautājumu / piezīmes / etc, tad komunikācija notiek komentāros pie ticketa. Ir pieredze arī ar Scrum klātienes projektā, kur bija 2 komandas ~8 un 4 cilvēki. Tur ticketu risinājums elektroniskais bija diezgan sūdīgs, bet klātienē tas viss strādā vienkāršāk. Papildus lietojām arī lapiņu līmēšanu. Tas bija iekšējais projekts un likšana produkcijā bija visnotaļ reta. Viena lieta, kas labāka par attālināto - izstrādātāji regulāri rādīja demo sevis izstrādātajām lietām nosacīti gala klientiem. Motivējoši, jo nevienam jau negribas izgāzties, neko sakarīgu neparādot.

Runājot par Python pieprasījumu tirgū ārpus LV - man ir aizdomas, ka sevi kā remote izstrādātāju vienkāršāk varētu būt pārdot kā reizi ar Python. Tiesa, ar PHP un Java neesmu mēģinājis, bet tajā valodās vieglāk uz vietas atrast darbiniekus.

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

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

Vispār ir arī tāds ruby.lv No manas necilās ruby pieredzes (tik daudz lai laistu Redmine un Linux / Windows mašīnām) rodas jautājums, vai te tik arī nav tā problēma - "tik liku jaunāko Ruby nevis kas norādīts linkā." Respektīvi, varbūt tomēr pamēģināt izdarīt tieši tā, kā rakstīts attiecīgajā pamācībā. Ar Ruby, Rails un attiecīgajām gems versijām ir visādi.

Lūdzu gatavs produkts - http://ca.groupscript.net/products/1/. Šo letiņi taisa un tirgo, varbūt pat kāds no viņiem arī pamanīs šo topiku.

Trendsetters klients = potenciālais darba devējs. Bija arī viņa sludinājumi pa tiešo, bet firmas nosaukumu neatceros. Negāju pildīt testu, jo 1) PHP programmēšana nav mans sapņu darbs, 2) bija citi labi piedāvājumi, no kuriem izvēlēties. Vai tie 20K gadā ir domāti uz rokas, es nezinu, manas prasības bija ap 1.2K mēnesī. Un, protams, testi ir ok. Vienīgi tās 4 stundas man šķita padaudz. Piedevām vēl kaut kā jāiekļaujas to darīt Trendsetters darba laikā.

UK ir forši kontraktoru piedāvājumi ap 350-400 mārciņām dienā. Kaut kā piedāvājums neliekas saistošs.

Klients grib, lai izpilda 4 stundu testu. Man tam laika nebija.

Rekur cilvēki pacentušies norādīt algu no/līdz - http://www.cv.lv/darbs/e-global-trade-finance-group-inc/web-programmetaju-php-js-d154311.html?renew=1&old=1 Un jāsecina, ka var 1K Ls mēnesi saņemt par PHP programmēšanu.

So iMac should also be ok, right? ;)

Domāju, šai vakancei svarīga ne tikai spēja programmēt, bet arī veiksmīgi komunicēt ar citiem cilvēkiem, tai skaitā spēt pamatot savu viedokli un pārliecināt par to citus. Motivācijas vēstule kā reizi ir piemērs šādai pamatošanai. Galvenais pat nav fakti, kas tur uzrakstīti, bet gan komunikācijas paraugs kā tāds. Ir nācies saskarties ar cilvēkiem, kas varbūt nav slikti speciālisti, bet komunikācija ir drausmīga (tā, ka nepieciešams 3-4x vairāk epastu, lai saprastos) un ar tādiem tiešām nav vēlmes ikdienā sastrādāties. Labam darbiniekam nepietiek ar tikai ar spējām vienā - programmēšanas virzienā, bet arī svarīga vispārējā emocionālā inteliģence. Nespēja uzrakstīt motivācijas vēstuli kā reizi liecina par neatbilstību..