ivka

Skaidrs, paldies par info, būs varbūt jāpamēģina. Tomēr lieta sensitīva - ieteiksi klientam un izrādīsies kaut kāds trash - te var ne tikai reputāciju sabojāt :( Ar FirstDatu un bankām jau līdz šim šādas problēmas nebija - jo nebija īpaši arī izvēles iespēju LV.

Cik es saprotu nauda pēc darījuma ir Paysera kontā, kuru pārdevējs var pārskaitīt uz savu kontu. Atšķirībā no piem. Paypal bonuss ir tāds, ka piemēram uz LV Swed tas notiek bez komisijas. Ja tas sistemātiski notiek bez ķeršanās un stresu uzdzenošām "pieturēšanām", tad jau labi :). Otra lieta - piemēram ja izmanto viņu banklinkus - maksājuma uzdevumā kā saņēmējs ir redzams kas - Paysera? Pircējiem tas nav drusku mulsinoši? Ja banklinkus taisa pa taisno ar bankām, tad jau kā saņēmēju redz tirgotāju. LV "lētās" kartes (piem. Maestro, ar kuru ārzemju e-veikalos principā neko nevar nopirkt) viņi arī normāli procesē?

Vai ir kādam reāla pieredze ar Paysera (aka mokejimai.lt)? "Uz papīra" piedāvājums ir visnotaļ sakarīgs, bet interesē pilnā bilde - uzticamība, stabilitāte, zemūdens akmeņi, "small print" utt.

Tik traki gan nav. Pirmkārt - ja notiek darbs, tad ir arī ieņēmumi (protams jo vairāk/labāki/kvalitatīvāki risinājumi, jo ieņēmumu vairāk) Otrkārt - sākotnējā lietu apgūšanas etapā nav problēmu maksāt arī par jēdzīgi pavadīto laiku, nevis par pārdoto darbu, galvenais lai ilgtermiņā ir kustība uz sevis atpelnīšanu, kā jau tas normāli ir pieņemts jebkurā konsultāciju/IT uzņēmumā, kur ieņēmumi rodas no paveiktā+pārdotā, nevis atrauti no realitātes caur investoru injekcijām vai sponsorēti no blakus biznesiem vai tml. Tāpat arī pašreiz galīgi neizskatās, ka pārskatāmā nākotnē varētu iestāties "nav ko darīt" situācija, jo darbu kaudze ir iekrājusies pamatīga, tik nav kas izdara. Ja patiešām viss tiks izdarīts un iestāsies "nav ko darīt", tad tas būs great success, arī finansiāli :)

Par uzņēmumu sevi vēl nesaukšu, bet pēdējo gadu laikā ir izveidojusies saimniecība no 5+ klientiem ar kopā 7+ web lapām, kuras visas ir vidējas sarežģītības e-komercijas aplikācijas - pārsvarā B2C/B2B internet veikali ar web back-end vai integrēti ar ERP sistēmām. Šīs saimniecības uzturēšanai un paplašināšanai nepieciešams jauns komandas biedrs ar vismaz: * vidējām-labām iemaņām Linux, MySQL vai PostgreSQL, PHP5, HTML, CSS, JavaScript * izpratni par MVC (vēlams kāda no populārākajiem PHP framework formā) * spējām kaut ko šad un tad (reti) uzzīmēt Photoshopā * bez uzkrītošiem komunikācijas trūkumiem * nobriedušu un atbildīgu personību Darba apjoms līdz pilnai slodzei pēc vienošanās (iespējams pietiekami brīvs darba grafiks). Jūsu atalgojums tieši saistīts ar ieņēmumiem projektos (pilnīgi iespējams arī krietni labāks nekā "konkurētspējīgs"). Iespējams kā darba līgums, tā arī citi sadarbības modeļi. Pieejamas klusas un mājīgas biroja telpas, ideāla vieta brain-consuming darbam, kā arī tehniskais nodrošinājums. Interesentus lūdzu rakstīt uz [email protected], īsumā norādot iepriekšējo pieredzi.

Par šīm lietām ir vērts sākt domāt tikai tad, ja projektā atbildība ir dalīta un projekts ir liels. Savādāk nevienam tas nav vajadzīgs. Pat ieviešot biznesa vadības sistēmas shēmas tiek zīmētas tā ļoti nosacīti un parasti aprobežojas ar use-case diagrammām. Normāli programmeris pats visu izdomā un uztaisa. Piesaistot relatīvi nelieliem projektiem kaut kādus sistēmanalītiķus un shēmu zīmētājus - izlietoto resursu overheads diemžēl ir stipri par lielu - viens otru nesaprot, dalās domas par metodēm un 80% laika aiziet diskusijās par virtuālo optimumu, kā rezultātā pat ja šis optimums tiek sasniegts, rezultāts ir ~10% labāks par to, kas būtu radies, ja koderis būtu strādājis viens. Par cik tehnisko dokumentāciju tāpat neviens neraksta, tad drūmā realitāte ir tāda, ka ja koderis aiziet no darba, uzņēmums zaudē klientus. Un tiešais cēlonis tam ir tas, ka vienmēr visiem visu vajag jau vakar, un mūsu nabadzīgajā valstī proj.vad. pats sevi ir gatavs apsolīt klientam verdzībā, lai tik dabūtu kārtējo pasūtījumu. Kamēr no katra kodera ir atkarīgi tikai daži klienti tikmēr OK - neviens īpaši nepārdzīvo - suņi rej, karavāna anyway kustās - tāda dzīve. Bet ja tiek veidots softs, kuru plānots pārdot 100+ kopijās, tad jau varbūt arī kāds sāk aizdomāties - "a kas būs ja notiks šitā..." un pievērst uzmanību sīkumiem, t.sk. dokumentācijām, testēšanai, performancei un tml. A par cik web projekta vai weblapas izstrāde (šis tomēr ir php forums) ir katram klientam ar kaut ko unikāls pasākums, kur budžets tipiski ir zem 1000 Ls, tad nafig palielināt izstrādei nepieciešamo resursu vairākas reizes??? Galvenais lai viss ir strādājošs un ātri gatavs. Beta-notestēs pats klients :) Pēdējo gadu laikā esmu pastrādājis kādos programmēšanas 4 uzņēmumos (visi diezgan labi pazīstami LV, viens no viņiem UK), no kuriem divos taisīju web-based projektus, otros divos kodēju risinājumus vienai grāmatvedības/ERP sistēmai - diemžēl klašu diagrammas un tml. plānošanas esmu redzējis tikai tik pat daudz cik jūs visi - respektīvi - aiz neko darīt pats mēģinājis zīmēt. Varbūt nav noveicies vienkārši... :( No softa pasūtītāja parasti par daudz prasīts ir jau tas, ka šis skaidri spēj nodefinēt savas prasības. Un no proj.vad/konsultanta/analītiķa (nu whatever - kurš uzklausa klientu) ir par daudz prasīts lai viņš kaut ko adekvāti saprastu. Un šajā atklāsmes stadijā sāk likties, ka ne waterfalls, nedz arī rapid metodoloģijas te neiet cauri - softu jāsāk rakstīt no user manuāļa :) Bet tipiski ir tā, ka klients grib kaut ko vienu, koderis uztaisa kā viņš to lietu redz, un klients, kad viņam pārgājis pirmais šoks no ieraudzītā, piekrīt uz kompromisu - t.i. - uzlabot to kas ir uztaisīts lai varētu darīt lietas kā viņš ir iedomājies, savādāk viņš pārtērēs savu budžetu reizes 3 :) Protams no tā var izvairīties, ilgstoši kopā ar klientu analizējot viņa problēmas, bet tad patiešām pati kodēšana sastāda max. 30% no visa darba, un tam šeit neviens nav gatavs morāli.

Te jau par ko bazars.. Ja nelieto begin commit, tad uz selektu rezultātiem fig var paļauties, jo cits useris pa vidam var visu nodzēst vai izUPDATēt, bet ja lieto, tad par to nav jāuztraucas.

Labi. Laikam pats visu sapratu - biju noputrojies ar persistentajām konekcijām un principā uztraukumam nav pamata. Varbūt kādam noderēs mazliet teorijas.. Katrs apache childs vienlaicīgi servē vienu rekvestu. Tas gan nenozīmē, ka vienam userim taisot vairākus rekvestus viņš visu laiku strādās ar vienu un to pašu childu!!! Citiem vārdiem - mans.php fails no sākuma līdz beigām, ieskaitot visas includes utt. atrodas viena apaches childa ietvaros un citi useri pa to laiku pie šī childa resursiem (piemēram db konekcijām) netiek. Tas, savukārt, nozīmē, ka jebkādas transakcijas, kas sāktas konkrētā skriptā, ir ekskluzīvi pieejamas šim skriptam. Ja nelieto persistentās konekcijas, tad konekcija ar datubāzi tiek aizvērta skriptam izbeidzoties. Neesmu 100% pārliecināts, bet šķiet, ka ja netaisa COMMIT, tad viņš automātiski nenotiek. Fckn slikti vārdu sakot - db konekcijas dzīvo tikai skripta izpildes laiku un ne vairāk. Persistentās nepalīdz. Nošauties... Labi ka neprogrammēju PHP ikdienā...

Par to jau jautājums :-) Ja zinātu ka var droši pages sākumā izpildīt BEGIN un beigās COMMIT, būtu baigi labi.. Bet kaut kā nav pārliecības.

Piebilde. Ja runa ietu par db tabulām ar 1000 ierakstiem un websaitu ar 10 hitiem minūtē, tad es te par to nevārītos....

Atkal jau lietus līst un atkal kaut kas manuāļos nav līdz galam uzrakstīts... Tātad - vai kādam ir sanācis ņemties ar PostgreSQL un transakcijām, izmantojot PHP par frontendu? Problemātika sekojoša: 1) PHP patīk rejūzot jau esošas atvērtas konekcijas ar datubāzi. Respektīvi, ja man viens apache childs apstrādā 7 klientus, tad visticamāk ka šamiem visiem tiks izmantota viena un tā pati konekcija ar datubāzi. 2) Transakcijas, kā zināms, darbojas pa visu db konekciju, respektīvi - ja viens useris izpilda BEGIN, tad otrs, kurš pa to laiku izpilda kaut ko citu, visticamāk trāpa iekšā iesāktajā transacijas blokā, un ja pirmajam pēkšņi notiek ROLLBACK, tad otrajam arī nekas nesanāk, jo šie sanāk ka ir lietojuši vienu transackciju. Tas viss principā ir nepieciešams, jo ir vēlme izmantot kursorus (DECLARE my CURSOR FOR SELECT.......) un sekojoši ar FETCH bīdīties pa recordiem pēc vajadzības. Gribas, lai skripta sākumā notiktos BEGIN, bet beigās COMMIT vai kaut kur pa vidu ROLLBACK. Visideālāk, protams, būtu, ja db konekciju varētu piesiet pie usera sesijas un managēt šīs konekcijas, tad varētu reāli sabūstot performanci ar šitām lietām, jo pie katra page refresha taisīt 20 selektus nav ne vēlmes ne arī principiālas nepieciešamības. Komentāri? Zinu ka pg_connect() var izsaukt ar PGSQL_CONNECT_FORCE_NEW :-) Vairāk interesē principiālā pieeja - vai kāds kaut ko tādu ir darījis un cik liels čakars bija? Vai arī vispār es te murgoju un nekad nevar sanākt tā ka viens useris trāpa otra iesāktajā transakcijā....

Nu reku tālu nemaz nebija jāmeklē: http://www.xisc.com/ No pirmā acu uzmetiena liekas tīri ok. Jāizpēta uz ko šis spējīgs ;)

Zināmā mērā ir, bet universāla pieeja request/response modelim tāpat nava. Lai gan sen nav pa tīklu bradāts - jāpameklē moš kāda pērle atrodas.

Hmm.. negribi minēt kādu piemēru, kuri ir šie "veiksmīgie projekti" šīs diskusijas (drīz jau par manu monologu taps :unsure: ) kontekstā? Kā es to redzu - populārie un veiksmīgie ir monolīti kluči aļa šī foruma software - mēģināsi iebāzt savās includēs vai integrēt savā saitā - galus atstiepsi :) Iekopēt un darbināt nav māksla, savu headeri vai CSSu uzlikt arī, bet pamēģini teiksim kaut vai no phpBB uztaisīt Delfu komentārus (kas būtībā ir tas pats) - possible? Lai gan var jau būt, ka es par maz esmu redzējis.

Tipa kāpēc es te raudu - tāpēc ka nupat ir kādu pusgadu sanācis attālināties no webu pasaules un pakodēt iekš MS Business Solutions Navision - vot tā bļin ir sistēma - protams kā jau 4GL viņai ir n-tie ierobežojumi, bet ja tu vari (ņemsim analogu no php pasaules) diskusiju forumu uzkodēt vienā stundā no nulles, tad arī klients labprāt piecietīs to, ka "kaut ko šī sistēma tomēr nesuportē". Par to viņš pretī saņems risinājumu 50x ātrāk (nepārspīlējot!) un efektīvāk gatavu nekā ja būtu iekš Visual Basic jākodē. IMHO tīra analoģija ar frameworkiem - jā, tu esi ierobežots, bet tu nebūvē velosipēdu katru reizi (jo izgudrots viņš tā kā tā jau ir sen), bet domā par to, uz kurieni tu ar viņu brauksi.