nemec

Es neteiktu, ka tavs uzdevums ir mega sarežģīts. Pieņemu pat, ka tas ir kaut kādā mērā atrisināts sen pirms tevis. Un man interesē realizācija, gribu redzēt, kas tur ir tik unikāls un neatkārtojams. Varbūt vēlies padalīties?

Labi, man jau apnika diskutēt par programmētāja EGO. "Codemonkey nekad neinovēs, neradīs kaut ko jaunu" — pats daudz ko esi inovējis?

Aizmirsi pierakstīt, cik pats ilgi šo uzdevumu risināji.

Es vēlreiz atkārtoju, nolaidies uz zemes, atver savus kodus un paskaties kas tur rakstīts. Bieži raksti Markova slēptos modeļūs? Katru dienu, nē?

Gudroties visi prot, parādiet man savus darbus, kur jūsu opensource projekti, ja jūs visi tādi varen gudri?

Tavi vārdi — "iemācīties programmēt var pa diviem gadiem, tas vēl ar nosacījumu, ja esi īpaši apdāvināts". Man ir reāli draugi/paziņas, kas apgāž šo sapuvušu teoriju. Neesat jūs nekāda īpaša kategorija. Paies laiks, būs krīze arī IT nozarē, un tad skraidīsiet tā pat kā būvnieki. Pagaidām varat priecāties par lielām algām :)

Pie tam, cik esmu strādājis, tad uz pirkstiem var saskaitīt normālus programmētājus. Visi pārējie ir iedomīgi kretīni, kas vien prot gudroties pa forumiem un stāstīt par algoritmiem 1962. gada.

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

Gribi teikt, ka google man neieteiks izmantot šo algoritmu, ja pameklēšu? Cita runa, ja tu pats spētu to impelemntēt.

Nesaprotu, ko jūs man vēlaties te pierādīt. Tas, ka jūs no galvas iemācījušies 10 sortēšanas algoritmus, visu par grafiem, tad jūs esat par kaut ko labāki?

Es jau teicu, ka 90% uzņēmumiem der monkey (pēc jūsu mērīšanas).

Ja vēl tādam akadēmiķim nav prakses, tad manās acīs viņam vispār ir ļoti zema cena. Tādu indivīdu mēs varam saņemt no augstskolas (zubru).

Protams atkarīgs no uzdevuma, bet 90% būs vajadzīgs monkey`s, kurš pārzin pilnībā 2+ valodas, ir izpētījis un izspaidījis vairākus ietvarus, ātri orientējas svešos kodos, spēj veikt savu uzdevumu ātri un termiņos.

Tos savus algoritmus, codez' tu pats uzrakstītu, ja iepriekš tos nekad nebūtu redzējis?

Jūs tā runājat par šo sfēru, it kā te būtu vieni akadēmiķi salasījušies.

Protams, jūs esat tie izredzētie — 20% programmētāji, visiem taču patīk tā domāt. Es nekautrējos nosaukt sevi par code monkey. Jo es vairāk kapāju, nekā sēžu forumos vai pētu 100 gadus vecus algoritmus. Jūs projektus arī tā veidojat, balstoties uz kaut kādiem sīkumiem? Programmēšana tas ir tikai rīks.

Vakar vajadzēja sortēt pašam, šodien ir bibliotēkas. Vakar bija mysql sintakse, šodien ir ORM.

Kam jūs vajadzīgi ar tām "akadēmiskām" zināšanām? Varbūt google`am, bet es šaubos, ka te ir kādam tāds līmenis.

Nesmīdini mani ar saviem pāris gadiem, ja vēlies profesionāli braukt ar mašīnu, arī vajadzēs mazliet vairāk pabraukāt.

Nevajag pārvērtēt savu profesiju un domāt, ka esi gudrāks/krutāks par citiem.

Tur jau tā lieta, ka code monkey der lielākai daļai Latvijas uzņēmējiem. Paņemiet kaut vai mājas lapas cepējus, tur jau viss sen ir izdomāts un uztaisīts, tikai jāliek kopā.

Jā, tā ir vēl sarežģītāka, jo tas, ko lielākā daļa zīmē ir kaut kāds sviests.

Programmētājs laikam pati iedomīgākā profesija uz pasaules :)

Nevajag pārspīlēt, nav tur nekā tik sarežģīta. Ir tikai kādi 10% darba, kur vajag spēcīgas zināšanas. Pārējos 90% var veikt gandrīz vai jebkurš, ar nosacījumu, ka uzņēmumus strikti norāda darbiniekiem - kur, ko, kāpēc un kā ir jāraksta/jākodē.

Ja jūsu programmētājs nelieto šablonus, MVC, ORM un pārējos zvērus, tad tā ir uzņēmuma vaina, nevis programmētāja.

Man ir daži piemēri, kad pa pāris gadiem par labākiem programmētājiem paliek cilvēki, kuri līdz tam brīdim nekad nebija programmējuši vai izcēlušies matemātikā.

Es ieteiktu godīgi rakstīt CV, ka pieredzes nav (vismaz nav lielas), bet ir liela degsme mācīties un attīstīties. Un minot, ka algu vēlies salīdzinoši zemu sākumā (piemēram 200Ls).

Būtu ļoti jauki, ja būtu sakapāts kāds projekts, idejas ir miljons, tāpēc paķer kādu vidēji sarežģītu un uztaisi.

Pārsvarā darba devējs ir iedomīga būtne, un viņš labāk iztērēs pusgadu, meklējot profesionāli, nekā paņems jauniņo. Tāpēc nebēdājies, ja kāds no tiem pasmiesies par pieredzi apsardzē, vai par pieredzes trūkumu. Galvenais turpini meklēt un kāds labs darba devējs tevi noteikti paņems. Tas ir protams ar nosacījumu, ka patiešām ir tik liela vēlme darboties šajā sfērā :)

Varu arī pateikt, ka tā programmēšana nav nemaz tik sarežģīta, kā to zīmē programmētāji.

1. Ir trīs varianti:

1) PHP header('Content-type: text/html; charset=utf-8');

2) HTML <meta http-equiv="content-type" content="text/html; charset=utf-8" />

3) Iekš servera (nginx tādai rindiņai jābūt — charset utf-8;)

Ja ir AJAX, tad paliek vien 1. un 3. variants.

Kāpēc nevar uzlikt pie ielādes enkuru (#banana) un uzlikt listen`eri uz izmaiņām - ja tiek fiksētas izmaiņas (back poga), tad "kaut ko darām"?

Ja tik tiešām vajag, tad var veikt crossdomain get un post http://alotaiba.github.com/FlyJSONP/

Komentēt ir iespēja tikai reģistrētiem lietotājiem.

Latviešu kopiena tāda maza un intereses izkaisītas.

Latviešu IT kopiena paša izkaisīta. Izņemot PHP programmētājus (šajā forumā), es nezinu nevienu vietu, kur varētu atrasts pārējos programmētājus (java, python, ruby utt),

Personīgi es jūtu lielu bloku sevī, lai rakstītu blogu

Nevajag jau visiem rakstīt. Ja pieņemam, ka no 20 000+ IT cilvēku Latvijā, vismaz 1% rakstīs pa 1 tēmai mēnesī, tad dienā mēs iegūsim veselas 6 tēmas latviešu valodā, kas ir pilnībā pietiekoši.

Par sevi varu pateikt, ka sākumā es mēģināju rakstīt katru dienu pa vienai stundai (tā bija sava veida atslodze no ikdienas darba). Vēlāk tomēr sapratu, ka kādas tēmas drukāšana aizrauj un negribās pārtraukt iesākto darbu, tāpēc šobrīd es veltu 2-3 stundas brīvdienā, lai pilnveidot savas zināšanas un padalīties ar citiem.

vai pat programmas komentārus ne angliski.

Par komentāriem es pilnībā piekrītu, tos jāraksta angliski.

Savā laikā bija aktuāli ļerkstēt, lai iegūtu respektu vietējā tirgū, droši vien ka arī tagad tas ir aktuāli. Tas ir par garlaicīgajiem tematiem, it kā aktualitātēm. Par reāliem dzīves stāstiem - noteikti būtu interesanti.

Jebkurā gadījumā, dalīties pieredzē ir viens no veidiem kā pilnveidot savas zināšanas. Jūs pierādāt sev un citiem, ka esat tik tiešām kompetents šajā jomā.

Studenti, kas studē kādu IT saistītu profesiju, varētu ļoti viegli dalīties ar saviem referātiem. Es pats esmu students, tāpēc daži referāti pārklājas ar teit.lv tēmām (piemēram git-flow špikeris http://teit.lv/versiju-kontroles-sistemas/zarosanas-komandu-spikeris.html )

ieteiktu paskatīties uz habrahabr.ru un smelties no turienes idejas par šāda bloga izveidi

Es habrahabr.ru sekoju +/- regulāri, par kādām idejām iet runa?

Latviešu valodā ir pieejams teit.lv (kopīgs blogs), kurā gatavoju (šobrīd tikai es) dažādas tēmas, kas skar programmētājus, administratorus, dizainerus, PR speciālistus, IT vadītājus un citas ar IT saistītas profesijas.

Ja jums ir kāda tēma, par kuru vēlaties gūt jaunas zināšanas, tad varat ieteikt to tēmu ideju forumā.

Ja ir kāds prasmīgs rakstītājs un tam ir ko pastāstīt kolēģiem, tad var pievienoties mūsu pulkam ar tādām priekšrocībām: nav jādomā par bloga noformējumu (kaut vai koda gabalu izvadīšanu); mēs rūpējamies par mārketingu (twitter.com nekur.lv un citi).

Uzreiz varu pieminēt copy&&paste par ideju, tad teit.lv ir līdzīgs Krievijas habrahabr.ru

Vai varētu ieteikt kādu monitorēšanas servisu. Ir vajadzīgas ļoti minimālas iespējas, piemēram monitorēt mājas lapu (ar pieprasījumu 1 reizi 5min), ja atgriež ne 200 vai lādējas ilgāk par n sekundēm, tad atnāk epasts.

Re Grey Wolf nevēlas sadarboties ar PVN nemaksātājiem.

Vēl viens indivīds web aplikāciju izstrādes čatā arī to pašu teica, ka nevēlas sadarboties ar PVN nemaksātājiem.

Es pats arī nesaprotu motīvus. Būtu jauki, ja kāds man paskaidrotu, kur tad ir tā problēma?

un kapec doma ka gribu valstij samaksat PVP ?

respektivi, gribas shamo dabut atpakalj.

Tā pat nevaru saprast. Ja nav PVN, tad nav lieku problēmu un summa ir mazāka. Ja esi fiziska persona, tad vispār ideāli.

Jābut jur. personai un kā PVN maksātājs.

Kāpēc obligāti PVN maksātājs?

Tad ar tādu public $parent='Base'; arī tiek pārkāpts DRY princips?

Es sarakstu visādas klases, kā jau minēju - User, Gallery utt (tieši šajās klasēs varu sakešot datus). Tad varu uzrakstīt ParentController, kurš piemēram šīs klase manto (dati tiek sagatavoti iepriekšminētās klasēs). Tad varu vēl kādu Controller`i uzrakstīt, tādā veidā salasot tikai man vajadzīgos datus. Un beigu beigās pieslēdzu šablonu.

Varētu to darīt tā UserGalleryController: public $parent = 'User, Gallery'.

Scenārijs ir tāds, ir this.context UserGalleryController`am, un šis context tiek papildināts atkarībā no pieslēgtām klasēm (User, Gallery), sabāžot mainīgajā savus datus.

Ja salasīšana atkārtojas, tad var norādīt BaseController`i, kas jau salasa kaut kādus datus (extend`o User piemēram) un tālāk extend`oties no tā.

Nu ok, tik daudz es saprotu, bet vai tu saproti, ko es cenšos pateikt - teiksim tev two-columns.html šablonā ir dati {{username}}, tagad tev ir šis banana.html, kurš extendo. Bet reālā variantā būs vēl apple.html, pear.html, orange.html, pinacle.html, utt., kur visi extendos two-columns.html. Tagad teiksim ir kontroleri banana.php, apple.php, utt., katrs sagatavo datus priekš šablona un izsauc šablona renderēšanu. Tavā variantā katrā no kontroleriem ir jāsagatavo {{username}} mainīgais, kaut gan tas attiecas konkrēti uz two-columns.html šablonu. Šādā veidā tu N kontrolieros darīsi vienu un to pašu, kamēr manā variantā parent šabloniem katram ir savs kontrolieris, kurš sagatavo datus šablonam.

Un kontrolieri vajadzēja piesaukt, jo tas tieši parādīja to, ka parentu piesaiste ir jātaisa kontroleru slānī, nevis šablonu slānī, lai varētu pilnībā ievērot DRY principu un loose coupling principu.

Piemēram, ja man ir kontroleris child.ctrl un parent1.ctrl un parent2.ctrl un katram no tiem ir savs šablons ar dinamiskiem datiem. Ja man sākumā ir child.ctrl ar parentu parent1.ctrl, tad, ja es gribu nomainīt parentu un parent2.ctrl, es to arī daru un man nav nekas jāmaina datu apstrādē nevienā no kontroleriem, jo katrs no kotroleriem atbild par sava šablona datiem un child.ctrl neinteresē kādi ir konkrētā parent kontrolera dinamiskie dati, jo tos sagatavos attiecīgais parent kontroleris. Tiek skaisti ievērots loose coupling princips. Kamēr extendojot šablonu līmenī, child šablonu izsaucošajam kontrolerim jāsagatavo informācija arī priekš ekstendotā parent šablona.

Te jau drīzāk ir runa par to, kā organizēt kodu - šablonu un cotroller`i. Es redzu stipru akarību tavā piemērā.

Es daru tā, ka ir visādas neatkarīgas klases User, Gallery utt.

Savukārt Controller`is norāda, kādi dati ir nepieciešami un kādus datus vajag salasīt - User, Gallery utt.

Tad es varu norādīt base.html, ja ir nodefinēts {{ username }}, tad to izvadam (vai izvadam kaut kādu block`u), ja nē, tad neko nerādam.

Kā to realizēt ar tavu piemēru? Ja es nevelos attēlot User datus, tad $this->parent()->user = false?

2)Tu nenodemostrēji, kā tu ar plikiem šabloniem izveidosi to, lai katra parent šablona dinamiskā informācija vienmēr tiktu ielādēta un nebūtu jālādē vietā, kur tiek izsaukts child šablons. Respektīvi, ja parent šablonā ir dinamiska informācija no db, tad manā gadījumā parent šablona kontrolieris nodrošinās tās ielādi un man nebūs viņa jālādē child kontrolierī, jo pietiks tikai norādīt kurš ir parent kontrolieris un viņš automātiski tiks izpildīts. Bet kā tas notiks, ja sasaiste uz parent šablonu ir pa tiešo šablonā un child kontrolieris nezin, kurš ir parent kontrolieris un tātad lādē pats? Bet kā tad ar to, ka vienu parent šablonu manto 10 citi neatkarīgi šabloni - vai visu child šablonu kontrolieros būs jālādē parent šablona dinamiskā informācija?

Tātad ir šabloni un ir contoller`is - divas atšķirīgas lietas.

Mazliet pielabosim šablonu two-columns.html

{% extends "base.html" %}
{% block content %}
   <div id="menu">
{% block menu %}
   	    hello {{ username }}
{% endblock %}
   </div>
   <div id="column">
{% block column %}
   	saturs?
{% endblock %}
   </div>
{% endblock %}

Atstājam to pašu banana.html bez izmaiņām. Tātad pirms šis šablons tiks apstrādāts, tas izskatīsies šādi:

<html>
<body>
   <div id="content">
   	<div id="menu">
   	    hello {{ username }}
</div>
<div id="column">
   	banānu satus
</div>
   </div>
</body>
</html>

Un tieši tādā izskatā tiks padots controller`im.

Šim šablonam mainīgos pados tieši tāds pats controller`ies, kādu biji aprakstījis savā piemēra.

Nevajadzēja piesaukt controller`i, tikai vēl sarežģījām situāciju.

Tas pats - realitātē šablonus raksta tas pats, kurš raksta kontrolerus, tāpēc tas nav arguments, jo šādā gadījumā viņam kontrolerī ir pārāk liela patvaļa. Šis vairāk ir veselā saprāta un uzņēmuma iekšējās darba organizācijas un standartu jautājums, kur jautājums par patvaļu šablonos ir sniegpārsliņa uz aizberga.

Šodien raksta viens, citu dienu otrs.

Ja ir tik liela uzticība, tad var atļaut rakstīt PHP, bet tas tomēr atstās tādu nedrošības sajūtu.

Jebkurā gadījumā, ja lietot variantu ar PHP, tad ir jāreglamentē - ko tajos šablonos drīkst un ko nē, lai nenonākt spageti kodā.

Manā aprakstītā variantā es varu lasīt kopā savus šablonus neatkarīgi no controller`a. Tā pati mantošana, es to varu veikt krustam šķērsam kaut vai 10 līmeņos, paplašinot vairākus block`us, tādā veidā iegūstot sev nepieciešamo šablonu.

base.html

<html>
<body>
<div id="content">
   	{% block content %}{% endblock %}
</div>
</body>
</html>

two-columns.html

{% extends "base.html" %}
{% block content %}
   <div id="menu">
{% block menu %}
   	navigācija
{% endblock %}
   </div>
   <div id="column">
{% block column %}
   	saturs?
{% endblock %}
   </div>
{% endblock %}

banana.html

{% extends "two-columns.html" %}
{% block column %}
banānu saturs
{% endblock %}

<html>
<body>
   <div id="content">
   	<div id="menu">
   	navigācija
</div>
<div id="column">
   	banānu satus
</div>
   </div>
</body>
</html>

Vēlāk varēšu ieviest three-columns.html un tālāk extend`ot kādu jaunu šablonu, nezaudējot saikni ar base.html.

Tavā piedāvā variantā šablons ir atkarīgs no controller`a.

Ja runājam par controller`iem, tad pašam controller`am vajadzētu savstarpēji mantoties un iegūt galu galā nepieciešamos mainīgos, ko var izvadīt beigu šablonā.

Kas notiek ja ir vairāki šabloni, vai piemēram vēl kādi citi formāti (xml, json utt)?

Galvenie trūkumi PHP engine`am:

1) nav dokumentācijas - viss php.net neder

2) ilga jauna speciālista iesaistīšana, tas izriet no pirmā punkta

3) pārāk liela programmētāju patvaļa šablonos

4) escape`ošana un mantošana, šo var risināt protams, bet atkal katrs to risina pa savam un tas nav labi.

Vēlētos apskatīties kā pārēji veido savus šablonus, varētu kādus piemērus samest.

Iedvesmojoties no jūsu sarunas, esmu nolēmis nopublicēt šādu tēmu http://teit.lv/progr...lonu-dzini.html

Ja kāds vēlas diskutēt vai nopublicēt pretējo tēmu (Kāpēc neizmantot šablonu dzini iekš PHP, vai tamlīdzīgi), varu padalīties ar uzaicinājumu ([email protected]).

Un šis jau noteikti nav oldschool :)

 

Uzturēšana

 

Mājas lapas izvietošana uz mūsu ātriem resusdatoriem.

 

(info ņemts no http://smart.raccoon.../#id=calculator)

Salīdzināt divus atsevišķus pakalpojumus ir vismaz nekorekti. Šis pakalpojums nav paredzēts programmētājiem, bet gan klientiem, kuri veido mājas lapas pie mums.

Šajā pakalpojumā tiek iekļauts:

• mājas lapai ir izdalīts atsevišķs serveris
  
• saregulēts lapas ielādes ātrums un saspiešana - html, bildēm, css un js datnēm. Varat paši paspēlēties ar http://pagespeed.googlelabs.com/
  
• mēs paši pieskatām mājas lapu un tās darbību - kļūdas, trafiks un citi parametri.
  

Ja īsumā, tad klients pasūta pie mums mājas lapu un neuztraucās par tādiem vārdiem - hostings un pārējām ar to saistītām problēmām.