Pusti ti manj vešče uporabnike :)

Ob odprtju "edit product" v moji spletni aplikaciji želim narediti query na vaš server za kategorije. Ali pa periodično iti skozi vse artikle in pogledati, ali ima kakšen neveljavno kategorijo. Pusti ti to, se ne menjajo :) To narediš v 20 minutah, pa imava oba super feature. Pri trgovcu naredim še malo reklame za vas in je dobro za oba.

Potem je tu še query za statistiko oglasa nekega artikla (impressions, CTR...), ki bi jih lahko prikazal v spletni aplikaciji itd. To je bolj long shot. Ne vem, če take stvari še komu poleg mene padejo na pamet (po tvojem odzivu bi rekel da ne).

Ne bit kot uni mišji prdec od bolhe, 1,6mio pa 300x300px iframe pa not page s seznamom kategorij, welcome to the interwebz 2010!

jow,

upam, da bodo na voljo XML API za povezovanje s spletno trgovino? In tu ne mislim samo od nas proti vam. Tudi obratno rabimo.

Konkretno: kot prvo rabimo vaše podatke o kategorijah, tako da v form za vpisovanje artiklov lahko dam npr. dropdown seznam za izbiro diler.si kategorije (če napišem diler.si je malo manj čudno).

bujes:

A se meni samo zdi, ali pred 3 urami tu še ni bilo podatkov o podjetju?

Meni se zdi, da nas nekdo spremlja :D

Take najdeš zelo hitro, registracija danes, št. sporočil 1 :)

Zdravo,

zanima me, če ma kdo kakšno idejo, kateri je najboljši-najhitrejši način za parsanje jezikovnih datotek.

Npr. zdaj imam tako, v cookieu se prebere trenutna nastavitev in se potem includa ustrezen php language file.

Not so stringi v arrayu:

lang['product_stock'] = "Zaloga";

lang['product_info'] = "informacije o izdelku";

Razmišljam, da bi naredil tako:

lang['product_stock']['slovenian'] = "Zaloga";

lang['product_stock']['english'] = "Stock";

Tako stvar je lažje vzdrževat, kot tako kot imam v prvem primeru, ker npr. kakšenkrat pozabim dodati ali spremeniti string v vseh jezikih (vsak jezik v svoji mapi).

Zend ima menda jezikovne stringe v ini fileu.

product_stock = "Zaloga"

Dodatna slabost obeh pristopov je, da je težje narediti fallback. Npr. če enega stringa ni, se uporabi string od default jezika.

Druga slabost je pa ta, da je težje narediti spletni vmesnik za elegantno urejanje. Večina sistemov ima kar velik textbox, notri je pa vsebina celega file-a.

Zato sem mislil, da bi zadevo morda naredil v XML datotekah.

Npr:

<languagefile name="product" default="slovenian">

  <string key="product_stock">

    <value>Zaloga</value>

    <translation lang="english">Stock</translation>

  </string>

</languagefile>

Preden začnem naprej razmišljati, mislite, da bi to bilo po performancu nekje kot tisto zgoraj?

Celo dom drevo (ali več njih) bi ob začetku prebral v en 2d array, enkapsuliral v objekt in potem klical z globalno funkcijo (kot imam sedaj) v stilu <?=lang('product_stock);?> v view-u.

Meni tudi vleče asociacijo na drogo in kriminal.

Škoda, da nimajo za trgovce še narejeno, me prav zanimajo pogoji, ker bolha zna bit kar draga, 50€ na mesec...

j0w: to bi bilo, če bi živeli v angleško govoreči državi. Žal se pri nas beseda diler uporablja predvsem za razpečevalca mamil.

Tale Trac je lepa stvar, vsaj iz demota je tako videt.

Problem je v tem, da sem želel imeti to na produkcijem strežniku, ker imam tam najbolj poskrbljeno za varnost itd. :)

Bom jutri probal dati pitona na domači server, samo ne vem kako je pol z apachejem, ali ga je treba kaj posebej konfigurirati, ker za to zdaj nimam cajta.

No ja, s tema dvema je res poudarka na kodi in manj na projektnem vodenju.

Zaenkrat Mantis ostaja vseeno najbolj primeren. Čeprav tako splava po vodi že tako malo verjetna situacija, da kakšna stranka reportira bug, namesto da me kliče po telefonu in potem misli, da si bom vse zapomnil, ker pri vseh teh rešitvah za reportirat moraš biti prijavljen pa še obrazec zgleda "hud"...

In pol ljudje pravijo: "Pa zakaj sploh programiraš najdi nekaj kar že obstaja in kasiraj...."

Ja p... če ni tako kot rabim/hočem :)

Mantis sem že preiskusil, samo mi ni všeč ker lahko reportiraš samo bug, ne moreš pa npr. ustvariti taskov.

JIRA je java, pa še free ni. Bugzilla tudi ne podpira taskov, kot vidim, pa mi zgleda malo overkill za manjše ekipe :)

Zdaj gledam plačljive variante github/bitbucket ...

Zdravo,

lahko kdo priporoča kakšen preprost bugtracker, ki naj bi imel tudi roadmap in wiki, kamor bi pisal predvsem navodila za uporabnike?

Nekaj kot je retrospectiva, samo da ni na ruby-u :)

Naj bi bil free, pa naj dela na običajnem konfigu php+mysql.

Ne vem, če bi tako orodje bilo za kakšno uporabo, bi lahko enostavno tudi izpisalo tudi na kaj točno je zadeva ranljiva, nakar bi zadevo lahko popravil brez ugibanja.

Za to pa predvidevam moraš kupiti ta program :)