Bo ja :) . Zdej pripravljam update in gre gor konec tega tedna. Export podatkov bi rad bol uporabnikom prijazen naredu.

Kako bi vam bilo najboljše exportat podatke? Zdej je csv za vsako tabelo posebej, samo to ni tako uporabnikom prijazno.

Jaz imam tam "Direktor: Janko M.." tako da povsod paše, ampak vidim da je logičen tudi tvoj primer.

Vidim 2 opcije, ena je da bi za take primere uvedel spremenljivke npr. {tip-dokumenta} in jo bol zahtevni uporabniki lahko nastavijo. Ta mi je ok. Da bi imel 3 polja za to pa mi ni všeč (ker so še ponudbe).

Glede PDF-jev bom najbrž zelo kmalu šel na drug sistem ker imam pri www.invoicefox.com verziji težave z ne-ascii znaki (ker pdf ne podpira unicoda) in sem za Slo "ročno" rešil ČŠŽ, tam pa nekateri pišejo tudi v raznih arabskih/azijskih kar pa ročno nimam kej naredit.

@Tomcater - postavitev na pdf-jih zaenkrat ne bo mogoče nastavljat. V prihodnje bomo z 90% verjetnostjo popolnoma zamenjali PDF engine in takrat to bo opcija. To z newlini bo ob naslednjem updatu ja. To je res nujno.

@mprose7 - ja to je res. fonte in nekaj drugih stvari imamo deloma pripravljeno za nastavljat, samo nisem odločen ali bi to delal ali bi kar čimprej šli na nov PDF engine. Bolj sem za to drugo opcijo, samo ne morem govorit o kakih datumih.

SpinX, nene, Tomcater, Roky: ja popusti so pomembnejša stvar naslednje verzije.

Roky: predračuni so v Norm. API je samo še ni dokumentiran in temeljito stestiran. Dve firme ga uporabljajo. Z njim lahko delaš vse kar lahko delaš z aplikacijo.

komac:

1. ja, to sem mislil naredit. A ima Ajpes ima strogo določene pogoje za njihov web dostop. Uporablja jih lahko le oseba ki ročno poizveduje po podjetjih. Če hočeš pa dostop za aplikacije pa je nek cenik in več opcij ampak so vse zelo drage.

2. Tega se zavedam. Hočemo imet enotno delovanje ( ne da npr partnerja vnašaš na 2 različnih obrazcih ) zato je zaenkrat še tako, a mislim da imamo zdaj par dobrih idej kako to naredit brez neenotnosti tako da se izboljšalo.

3. O tem sem že razmišljal ja. Vsaka dodatna opcija dodatno zakomplicira uporabo programa, tako da ne želimo dodajat stvari prehitro. Če bo dovolj interesa bom dodal. Sedaj bo itak prišel nek page z nastavitvami, če bo pasalo zraven lahko dodam tudi to.

4. Za nekaj podobnega imamo "tage". Samo jih ima omogočene samo nekaj uprabnikov. Ko bo stran z nastavitvami si bo vsak lahko to vklopil.

5. to se mi zdi zelo dobra in zanimiva strategija, samo je mogoče preveč specifična da bi jo dodajal v čebelco. Čebelca deluje bol na nivoju računov/dokumentov in ne toliko samih financ.

5B. to z pošiljanjem računovodstvu je super ideja, še nisem pomislil na kaj takega. Bomo razmislili o tem. A to bi poslal kar same PDF-je računov, ali nek seznam (če v kakšnem formatu bi bilo najboljše?)

6. API je, ni pa še čisto public. V bistvu je aplikacija narejena tako da je že sama api, tako da to ni bilo težko naredit, in api omogoča vse (+ še malo več) kot sama aplikacija. uporablja ga npr. ta website www.audiobank.fm za splošno uporabo pa ga morem še mal prečesat.

Kakšne module pa bi še imel (poleg tega kar si povedal)?

Nisem opazil da ste pisali v to temo. Bom prebral in odgovoril do jutri.

lp

Tuki si tud dokazal da morjo jt geeki mal iz bajte v realnost če hočjo kej pametnega naredit / stuhtat.

vou Damir... ful zakon od ideje, ki so jo očitno takoj zagrabl, do izvedbe (in z jasnim "monetizacijskim" planom) .. kej takega se na Slo netu ne dogaja pogosto :)

google bo popravljen. se dela nova verzija in nova stran, neki v stilu http://refaktor.si/d/sao/

jst mam nekaj podobnega sedaj na eepc netbooku. Na Win7 ko si v prijavnem zaslonu dela, ko se pa prijaviš pa neha. Ženi je random ratalo da ji je delal tud noter, ne vem kako. Mam dual boot Ubuntu kjer dela BP.

Kolikor sem se jaz pogovarjal z ljudmi je EC3 dokaj drag in je primeren za pokrivat konice ali če imaš zelo variabilen obisk. Instance plačuješ na uro online (tudi če ni obremenjen) in kar nanaese. S3 za statične pa je baje zelo poceni.

Če gre za http proxy je par stvari zelo specifičnih.

Najbrž ne rabiš nobenih resnih sharanih podatkov (baze), tako da lahko vps-je zelo z lahkoto paralelno dodajaš.

To tudi pomeni da baza (ki pri večini webappov je) pri tebi sigurno ni performance problem.

Pri http proxy aplikaciji večino časa CPU čaka na podatke iz strani na katere proxijaš in jih pošilja naprej. Tako da je v osnobi popolnoma IO omejena (in zahteve trajajo več časa kot ponavadi, tkao da je v danem trenutku odprtih več kot klasično po mojem). Videl sem da proxy laufa na Apache in PHP kar je po mojem oboje zelo neprimerno za proxije.

Apache je narejen za hitro serviranje kratkih req., in je ravno zelo slab za "čakanje" za več hkratnih requestov. Slab zato ker uporablja en proces (al thread) na request kar pomeni veliko porabo RAM-a pri več hkratnih requestih.

Za to potrebuješ nekaj kar uporablja network asinhrono(event) ali pa ima neke light threade/procese. Poglej si npr primerjavo v porabi rama med apache in nginx (drugi graf):

http://blog.webfaction.com/a-little-holiday-present

Php ne vem točno kako laufa samo predstavljam si da je spet en proces na req. kar spet pomeni veliko rama. Če najdeš kakšno http proxy rešitev z nginx, node.js, erlang, ali kakršnemkoli async frameworku v pythonu, ruby, ... boš po mojem lahko na tem serverju laufal še več kot x10 prometa.

Kaj pa če kr uporabiš squid? al rabiš kakšno logiko zraven.

http://patchlog.com/general/how-to-set-up-an-anonymous-proxy-on-debian/

http://www.nineteenlabs.com/2007/08/24/high-anonymous-proxy-squid-25/