pbs, monopol og service
eller skulle jeg skrive mangel på samme
hos bellcom har vi efterhånden udviklet en hel del butiksløsninger, som stort set allesammen benytter sig af online kortbetaling - via pbs - selvfølgelig
pbs har i danmark monopol på online transaktioner, så hvis man ikke benytter sig af paypal, efterkrav ..oO(nåå nej, det har post.dk afskaffet), fakturabetaling eller måske endda girokort - ja så går alle transaktioner igennem pbs.
det i sig selv er der ikke noget forkert i, hvis de dog bare ville spille med åbne kort
for os er det utrolig fustrerende at få en meddelelse fra vores betalingspartner (quickpay) med følgende ordlyd:
her mandag formiddag oplever vi desværre igen driftsproblemer hos pbs.
vi får desværre ingen driftmelding fra dem, men man er velkommen til at kontakte pbs på tlf. xxxx xxxx
samtidig står der på pbs' driftstatushjemmeside at "al drift er normal"... wtf ?
hvordan vi den overfor vores kunder ? de vil jo referere til pbs' status og sige at de kan se at det hele spiller, men teknikken siger bare noget andet og deres online-transaktioner afvises og de mister ordre/penge - mens vi sidder med lorten - det er altså ufedt
så dagens råd må være
få styr på jeres services, meld ens ud og lev op til det ansvar der følger med når man er et monopol
så er det på tide at komme til københavn igen
man ved at det er på tide at komme til københavn igen når man har brugt ens sidste chili fra pusheren i studiestræde
den på billedet her er helt fantastisk i sandwich og på grillen, eller.. på noget kød på grillen er det jo
lejligheden til det er også lige om hjørnet, drupal camp 2009 står for døren og der regner vi med at være igen i år - jeg har da i hvert fald fået "fri" til det
links og artikler
til de få der kunne være interetsseret i mere seriøse links, artikerl og andre indlæg i den genre - så har jeg oprettet en ny blog til formålet.
jeg har før haft en mailingliste til det formål, men syntes det var tid til at komme ind i næste århundrede
drm vs pirater
syntes lige jeg ville dele denne.. det er jo ret sigende for teknologien og industrien...
symfony – call the expert
her lige et link til en artikelserie på symfony's blog som er ret spændende læsning - og ikke helt uinteressant hvis man har projekter der skal opgraderes fra sf 1.0 til 1.1 eller 1.2
bash.org nede
øv, havde troet at det var en midlertidig ting det med at bash.org er nede, men det trækker åbenbart ud for dem... så derfor har jeg ændret "dagens bash.org" til "dagens BOFH"
Ubiquity – en firefox extention
har lige kigget lidt på Ubiquity det er fame en extention der vil noget.. jeg kan bare ikke helt overskue sikkerheds konsekvenserne ved den
i store træk er det en extention der lader en lave mashup's mellem forskellige websites og applikationer
eks, kan du bede google maps om at generere dig et kort som du så kan sende til en af dine venner, hvis i har snakket om at mødes et sted denne ikke kender, altsammen uden at forlade din browser.
eller markere et arrangement på dit stamværtshus og tilføje den til din kalender, igen uden at gå ind i kalenderen.
well.. en ting er i hvert fald sikker, jeg skal lege meget mere med ubiguity de kommende dage...
8-8/08 08:08
det burde nok ha været en eller anden form for event eller gimmik, men et eller andet skulle der jo i hvert fald ske her den 08.08.08 08:08
[update]
ooh, havde lige et øjeblik glemt det, men i dag er faktisk også dagen for php4's officielle død, sidste patch release kom i går og så skal vi ellers ikke forvente os mere fra den kant...
php4 er død, længe leve php5
jeg glæder mig allerede til php5.3 som ser ud til at være lige om hjørnet.. der er i hvert fald mange lovende nye tiltag der.
et lille symfony hint
jeg har lige et lille hint jeg vil dele med andre der bruger symfony.
når man skal oprette eller rette "emner" så har man et par muligheder for flow.
- 2 actions executeAdd() executeEdit() - hver action laver validering (add.yml, edit.yml) og gemmer objektet
- 1 action executeAddEdit() - her skal man så selv lave validdringen, da man ikke i yml filen kan skeln mellem add og edit, hvilket ikke altid er lige heldigt.
- 2 actions executeAdd() executeEdit() til at håndtere visning og fejlhåndtering, men én executeSave() metode til at håndtere selve oprettelsen/opdateringen af objektet
her er et lille eksempel:
<?php class articleActions extends sfActions { public function executeAdd() { if ($this->getRequest()->getMethod() == sfRequest::POST) { $this->forward('article', 'save'); } // setup the form and show it. } public function executeEdit() { $article = ArticlePeer::retrieveByPk($this->getRequestParameter('id')); if (!$article instanceof Article) { // show error $this->getUser()->setFlash('message', 'No article found'); $this->redirect('@homepage'); } if ($this->getRequest()->getMethod() == sfRequest::POST) { $this->forward('article', 'save'); } // setup the form and show it. $this->article = $article; } public function executeSave() { if ($this->getRequest()->getMethod() != sfRequest::POST) { // send user some place else... $this->redirect('@homepage'); } $article = ArticlePeer::retrieveByPk($this->getRequestParameter('id')); if (!$article instanceof Article) { $article = new Article(); } $article->setTitle($this->getRequestParameter('title')); $article->setContent($this->getRequestParameter('content')); $article->setIsPublished($this->getRequestParameter('is_published')); $article->save(); $this->getUser()->setFlash('message', 'Article saved'); $this->redirect('@homepage'); } }
jeg syntes metoden her holder da den gør at man kan håndtere validering udfra om det er en add eller en edit man har gang i - og det gør metoderne mere rene