Süß, so ein d1d.li

So, heute hat man nicht nur ein Blog und einen Twitter-Account, sondern auch seinen eigenen URL-Shortener. tinyurl war früher mal DAS non-plus-ultra, aber seit twitter zu noch mehr Zeicheneinsparung zwingt, sprießen sie wie Pilze aus dem Boden, die bit.lys, digs.bys und sonstige Kurzmacher…

Naja, und dann wollt ich das auch haben – und daher gibt es jetzt http://d1d.li. Ist nicht öffentlich – und verweist von sich aus eigentlich wieder hierher, aber ich werde es für mich selbst als Link-Liste nutzen, um merkenswerte Links abzulegen.

Was? Bookmarks im Browser? Ach, quatsch… out, völlig out!!

Und das ganze läuft natürlich auf symfony (und sqlite) und war eigentlich, dank des schönen object-routings, ganz schnell erledigt.

PS: Ich dachte, die Steuersünder aus Liechtenstein zu unterstützen ist das kleinere Übel als die Terroristen in Libyen, des wegen li statt ly.

How to configure symfony unit tests to use an sqlite memory database

Since Bernard Schussecks presentation at “symfony Day Cologne”, talking about lime and using sqlite memory tables for unit tests, I was wondering HOW TO DO IT

Well, there was not much talk about the how… of course this must be known to everybody – such an easy task. (Find yourself some <irony> tags to put around this).

Well, at least I did not have a clue how to do it and did not find too much information on it in the web…

So, spending some more time with testing and some rare tutorials on it, I finally made it work!!

And for you and me and everybod else, I’ll note it down for reference…

Assumptions/Prerequisits:

  • We are using symfony and doctrine
  • In test/fixtures we have a/some yml files with test data

First, we need to set up the test connection to use sqlite:MEMORY:

In your config/database.yml add

test:
  sqlitetest:
    class: sfDoctrineDatabase
    param:
      classname: DebugPDO
      dsn: 'sqlite::memory:'

(yes, ::)

Now, lets assume (accoding to the Jobeet tutorial Day 8 ) we have a

test/bootstrap/Doctrine.php

Now, the important part is to not only LOAD the data but first create the tables:

  include(dirname(__FILE__).'/unit.php');
  $configuration = ProjectConfiguration::getApplicationConfiguration( 'frontend', 'test', true);
  new sfDatabaseManager($configuration);
  Doctrine::createTablesFromModels(dirname(__FILE__).'/../../lib/model');
  Doctrine::loadData(sfConfig::get('sf_test_dir').'/fixtures');

Now, in our test files we can simply call

include(dirname(__FILE__).'/../../bootstrap/Doctrine.php');
$t = new lime_test(4);  //change it with the number of tests you have 

everytime
Took me quite some time to figure it out – really simpe – if you know how…

Der Umstellerei nicht genug…

Posted on 2009-11-24

Von symfony 1.0 über 1.1 zu 1.2 zu 1.4 und von propel zu doctrine und von prototype zu jquery

Das ist das, was ich gerade mit meinem Karopier-Code mache. Und irgendwie hab ich das Gefühl, dass kann nicht ewig so weitergehen. Kaum hab ich was fertig, kommt was neues und ich will’s einbauen/anpassen…

Aber ich glaube, mit symfony 1.4 (stable ist ja um die Ecke), doctrine und jquery hab ich jetzt etwas, das länger halten sollte. Von daher machen die Umstellungen jetzt, so früh, glaube ich sogar noch Sinn, auch wenn ich jetzt ein paar Sachen wieder neu machen muss, die vorher schon taten…

Erst mal jobeet – vielleicht lern ich ja, wie’s noch besser geht…

Posted on 2009-10-01

Für die nächsten Tage hab ich jetzt erst mal die Entwicklungen am Karopapier2.0 eingefroren, weil:

Ich mach das jobeet-Tutorial, und zwar für das gerade-ein-paar-Tage alte symfony 1.3. Kann man auch gleich mal ein paar Bugs in der Doku finden und Tickets erstellen 😉

Und ich hoffe, dadurch noch ein paar “Best Practices” für Doctrine zu lernen, was bei der Karo2 helfen sollte…

Ich hab mir ja letzthin auch mal jobeet.de reserviert – mal schauen, was ich damit dann mache…

Nächster Plan: Karo2.0 auf Doctrine

Posted on 2009-09-25

So, der Plan für die nächste Zeit lautet:

Alles, was ich bisher in Karo2.0 gemacht habe, auf Doctrine umzubauen. Warum? Ganz einfach: Ich will ordentliche Unit Tests machen, um mit den ganzen Funktionen (insbesondere denen zum “aufräumen”) sicher zu sein. Und das macht sich am besten, wenn man nicht die “echte” sondern eine Testdatenbank benutzt.

Und da propel das nicht so gut drauf hat, mehrere Datenbanken gleichzeitig zu bedienen… werde ich wohl doch jetzt auf Doctrine umstellen – und somit nochmal “fast from scratch” neu anfanfen – aber diesmal dabei gleich die Tests schreiben.

Krasses Unterfangen, aber wir schon irgendwie gehen.

Von daher: Heut kommt der große Moment, wo ich mit die “original”-DB nochmal runterziehe und mir daraus dann ein schema erstellen lasse. So der Plan – mal schauen, wie weit ich komme, bis ich verzeifle…

Krasse Java Script Kartendarstellung

Posted on 2009-09-16

Seit gestern gibt’s mal wieder was neues bei Karopapier, das zumindest so auch mal sichtbar ist -wenn auch nur als Prototyp.

Unter Zuhilfenahme der sehr hübschen JavaScript Graphics Library wz_jsgraphics (http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm) hab ich die Karokarten bzw. die Züge der User KOMPLETT in JavaScript zeichnen können.

Die Vision, dass man dem User/Client prinzipiell nur die rohen Zugdaten liefert und er sich seine Kartenansicht selber baut, gibt’s schon länger. Denn Karten Zeichnen braucht ja doch ne gewisse Performance auf dem Webserver.

Mit dieser Library scheint es aber zumindest in gewissem Maße möglich zu sein, dies auszulagern. Einen Prototyp davon hab ich schon seit einem Jahr oder länger schimmelnd rumliegen gehabt, ihn aber gestern wieder ausgegraben und mit meinem etwas gewachsenen JS-Wissen der letzten Monate weiter ausgebaut.

Somit war es dann sogar möglich, pro Spieler eine Ebene mit den Zuglinien (Canvas) zu erzeugen, die dann natürlich auch einfach mal schnell ein- oder ausgeblendet werden können. Somit ließe sich auch ganz praktisch ein “Wo war ich schon” schnell auf der gesamten Karte anzeigen lassen.

Evtl. ließe sich damit auch ein JS-basiertes Replay (à la KaroTools, einfach genial, aber wg. SVG halt nur bedingt populär) umsetzen… aber mit dem window.setTimeout bin ich bisher noch nicht ganz warm geworden bzw. es führt mit der Library zu Problemen (this-bind-Problem)

Wie auch immer, ich hab’s mal eingebunden und als Alpha-Version verlinkt, wenn es auch bei manchen Spielen einfach mal kommentarlos abfackelt… aber is ja Alpha, nich mal Beta 😀

Criteria -> DQL

Posted on 2009-09-11

So, now I have some new classes that use doctrine to acces my DB and the move went quite smoothly.

However, I had some methods that – of course – used propel criteria to create special queries… those times are gone. What’s it like in doctrine?

But first, I had to add a Behaviour Timestampable to my schema to make sure good old updated_at and created_at still work. They have to be removed from the schema.yml, though and be replaced by

Zip:
actAs: [Timestampable]

Hope, that works…

Regarding my criteria: For example, I had the quite simple case:

$c=new Criteria();
$c->setLimit(20);
$this->zip_list = ZipPeer::doSelect($c);

Now, this obviouls needs to become a DQL something.

$q = Doctrine::getTable(‘Zip’)->createQuery(‘z’)
->limit(20);
$this->zip_list = $q->fetchArray();

Honestly, I have no clue right now what the parameter of the create is supposed to do – the documentation does not really explain it… and the fetchArray() returns an array – and all my getMethods fail… *hmpf* I thought there was object hydration?

Aaaha!

$user = new User();
$user->username = 'jwage';        // Object
$user['username'] = 'jwage';      // Array
$user->set('username', 'jwage');  // Function
$user->setUsername('jwage');      // Propel access
$user->save();

But why does “getId() fail then?

Maan, it took quite some reading through the docs to find out that the doctrine examples like the array representation and always use fetchArray, while for retrieveing the results as hydrated objects, you need to simply ->execute()

so:

$q = Doctrine::getTable(‘Zip’)->createQuery(‘z’)
->limit(20);
$this->zip_list = $q->execute();

Now, it looks quite good…

As far as standard methods go, I had to replace

$zip = ZipPeer::retrieveByPk($request->getParameter(‘id’))

by

$zip = Doctrine::getTable(‘Zip’)->findOneById($request->getParameter(‘id’)

using magic finders, which seems to be quite easy – but I remember John Wage say, that magic finders should not be used in final production environments… well, for the time being I’ll keep it…

Move from Propel to doctrine

Original Date: 2009-09-11

Big day today!

My plan is to dive into doctrine today by converting a small application. I have been using propel all the time and now it looks like I need to change something, because doctrine will be the path forward for symfony.

BTW, I’ll write this one in English, because it might help some people out there (and not only Germans…)

So, first stop:

The symfony and Doctrine Book

http://www.symfony-project.org/doctrine/1_2/en/

So I ran

./symfony configure:database --name=doctrine --class=sfDoctrineDatabase "mysql:host=localhost;dbname=dbname" user secret

to get the basic connection set up. Afterwards, I needed to clean some old Propel line removed from the database.yml

My Database is alread existing, so I can recreate the schema from the DB.

php symfony doctrine:build-schema

et voilà – I have a subfolder doctrine with the schema.yml

Hmm, first question now: Where did the _attribute: { phpname: .. } go?

Looking at the schema, the big difference between propel and doctrine seems to be: doctrine specifies a tablename for a parent element called like the table, but propel specifies a phpname for a parent that IS the table…

In my example I have a mysql table called “plz” but the phpname was “Zip”.

So, doctrine created a classname “Plz:” with tableName: plz – I try to change “Plz:” into “Zip:” … keep your fingers crossed

The doc talks about multiple connectiosn and attributes now, I’ll skip that for now, got no clue what the attributes mean and I only need one connection.

BUILD!! Thats what I want to do!!!

I don’t want to erase the table, so I only

php symfony doctrine:build-model

and YES, as hoped, it created a “Zip.class.php”. COOL!

add some

php symfony doctrine:build-forms
php symfony doctrine:build-filters
php symfony doctrine:build-sql

and now we should be fine, right?

Mein erster Symfony-[PATCH]

Original Date: 2009-09-11

Ich habe mich zum ersten mal durch die tiefen Innereien von symfony gewühlt, um herauszufinden, warum propel:data-dump bei mir einfach Spalten verschluckt hat bzw. bei manchen Tabellen nur einen (den letzten) Datensatz geliefert hat.

Dabei wollte ich doch voller Begeisterung nen Unit-Test mit eigenen Daten schreiben – und bleib an einem Bug hängen.

Jedenfalls konnte ich’s lösen und hoffe, der Patch finden seinen Weg in den offiziellen Release.

Patch siehe hier: http://trac.symfony-project.org/ticket/7126

Mein erster Unit Test

Original Date: 2009-09-08

Peinlich, oder??

Da entwickel ich seit Jahren so vor mich hin, aber heut hab ich zum ersten mal bewusst einen Unit Test für symfony mit lime geschrieben. Und das krasse: DAS MACHT SOGAR SPASS.

Es ist echt toll zu sehen, wie schön das ist, wenn ne Funktion das tut was sie soll bzw. kann auch echt hilfreich sein, um Fehler zu finden – wenn etwas nicht so is, wie’s sein sollte.

Albern, oder? Und doch so klar?

Aber ich vermute, ich bin nicht der einzige da draußen, der sich für einen tollen Programmierer hält, aber auch noch nie ordentlich was mit “richtigem” Testen gemacht hat… probieren – und wenn’s tut, tut’s… Denkste…

Wie dem auch sei, ich bin zufrieden. Hab erst mal nur eine Klasse getestet, aber is ja immer so: Erst das Prinzip verstehen, verbessern, und dann geht’s richtig los.

So, und mit dem neugeweonnenen Selbstvertrauen in meine Funktion für den Karo-Chat 2.0 hab ich den jetzt sogar auf das ECHTE Chatfile losgelassen. Und siehe da – es klappt!

Der neue Chat kann jetzt richtig schön AJAXen, neue Nachrichten faden ein, alte raus – herrlich…

Mal sehen, was als nächstes kommt. Vermutlich sollte ich mal eine ganze Ladung an statischen Testdaten für die Karo-Datenbank zusammenstellen, um da auchne zuverlässige basis für Tests zu haben?

Jaa, das sollte mal her.

Ach, nebenbei hab ich den von Quabla gemeldeten Bug gefixt: Bei Spielen “mit Checkpoints” aber keinen Checkpoints auf der Karte konnte man gleich ins Ziel – soll ja nich, geht jetzt auch nich mehr…