Symfony Day was amazing!!!

I love the community and it was great fun to see all the guys I already met during the last years and this year’s Symfony Live in Paris.

Again, a big THANK YOU to all organisers and of course all the people that make Symfony2 happen!

I just wanted to quickly paste my (sparse) notes that I took for myself – in case they help out someone else as well.

Basically, they are just some reminders for me of stuff that I wanted to check out.

Silex

• Silex routes can use value() and assert() to be enhanced
• Silex needs cookbook contributions
• Silex can easily be functional tested (and require “” can have a return value!)

SPL

A shame, I never really looked at it before!? So take a closer look at http://php.net/manual/de/spl.exceptions.php and SPL in general

Links to follow/read

Pragmatic Programmer: http://pragprog.com/the-pragmatic-programmer/extracts/tips

Sonata

Check out www.Sonata-project.org - adminbundle

See, if it’s really that complicated as the talk made it seem

I did not note so much else, either because I already knew it, wanted to take a look at the presentations later, or player #sfdayjeopardy (thanks to Jeremy “Rick Astley” Mikola for that)

There’s one more thing

Actually, there were two things: Fabpot is a visionary! And his vision, of looking at Symfony2 not (only) as a framework but as a collection of several, individual and powerful components is great. MAYBE not for the developer looking for “a thing that does all the magik™” but for the more experienced one that can pick the best of a wide variety of components. Like some other PHP projects do now…

AND: Me, being a big fan of Propel, was happy to see all the momentum propulsion it got recently, including development support from inside sensio.

Hope to see you all again in June(?) in Paris and in November(?) in Berlin?

Symfony Day was amazing!!! I love the community and it was great fun to see all the guys I already met during the last years and this year's Symfony Live in Paris. Again, a big THANK YOU to all organisers and of course all the people that make Symfony2 happen! I just wanted to quickly paste my (sparse) notes that I took for myself - in case they help out someone else as well. Basically, they are just some reminders for me of stuff that I wanted to check out. Silex Silex routes can use value() and assert() to be enhanced Silex needs cookbook contributions Silex can easily be functional tested (and require "" can have a return value!) SPL A shame, I never really looked at it before!? So take a closer look at http://php.net/manual/de/spl.exceptions.php and SPL in general Links to follow/read Pragmatic Programmer: http://pragprog.com/the-pragmatic-programmer/extracts/tips Sonata Check out www.Sonata-project.org - adminbundle See, if it's really that complicated as the talk made it seem I did not note so much else, either because I already knew it, wanted to take a look at the presentations later, or player #sfdayjeopardy (thanks to Jeremy "Rick Astley" Mikola for that) There's one more thing Actually, there were two things: Fabpot is a visionary! And his vision, of looking at Symfony2 not (only) as a framework but as a collection of several, individual and powerful components is great. MAYBE not for the developer looking for "a thing that does all the magik™" but for the more experienced one that can pick the best of a wide variety of components. Like some other PHP projects do now... AND: Me, being a big fan of Propel, was happy to see all the momentum propulsion it got recently, including development support from inside sensio. Hope to see you all again in June(?) in Paris and in November(?) in Berlin?

I’m getting old and I’m old fashioned.

I’m still using mysql, not mongoDB.

I’m using php and apache, not node.js, ruby, python or lighttpd, nginx or ….

And I’m using propel again (1.5), not doctrine. AND I’M LOVING IT!!

After #sfdaycng 2009, the presentations and talks there, I forced myself to giving Doctrine a try and really liked it then. A lot of reading through documentation in the beginning if you are new to it, but hey, that’s normal. However, today, even when writing a simple query, I still have to consult the docs. Why? The syntax seems not to be “my style” somehow, it won’t fit into my type of writing code.

But there is such a HUGE difference between Doctrine and Propel and Doctrine is SO MUCH BETTER

Is it? Do I care what’s inside if I’m only querying a database without using all possibilities? Remember sfLive 2010?

“Is Doctrine re-inventing propel” Hahaha LOL ROFL LMAO

At this years big symfony conference #sflive2010, in a Q&A session about Doctrine2, a poor guy obviously asked the question, that made it into a big running gag: “Are you trying to re-invent propel?”

I have to admit and regret that I was not there, but if you followed the #sflive2010 hashtag on twitter, it was not very long until this got tweeted over and over again. And everybody was making fun of it…

Sure, it is kind of funny to ask @jwage, (lead) developer of Doctrine that question… But hey? What’s really so funny about it?

While everybody in the audience laughed, it really would have been interesting to

a) see how many were trying to smirk, wondering whats so funny about that

b) know how many would have been able to give a good reply on that?

And with “good reply” I mean, explain the difference.

And with “difference” I mean, explain it beyond

• “doctrine has the schema.yml and the model classes in a subfolder”
• “propel uses two classes User and UserPeer, doctrine has User and UserTable”
• “propel has a criteria object, doctrine a query object”

If you started with symfony 1.0 as a developer that did not work with frameworks like symfony before (like I did), everthing is “symfony” – may it be propel, phing, creole, PDO, … and getting into these differences was not really worth it in the first place if you wanted to get started with writing your first applications.

What I’m trying to say: I guess that a lot of symfony developers out there don’t know or care about “Doctrine” vs “Propel” – they use the default. And they call it “symfony”, thinking that it belongs to it. If they started with symfony <1.2, they’ll use propel, now they use doctrine – because it’s the default. You learn it, you use it, you stick to it.

And I sticked to propel throughout 1.2. And it was quite save for me getting along ignoring Doctrine. Just then, when I started using Doctrine after #sfdaycgn I found new things, new approaches, things I liked, things I had to learn and a lot of stuff I could not get the hang of.

So now, with propel 1.5 and the new Query objects, I gave it a try and was so excited, I decided to come back to Propel. Just because it “feels like home” and fits my personal style of thinking/coding.

And of course both ORMs have their features and behaviours and at #sfdaycng Doctrine had more of them and so on… But I also assume that a lot of those features are beyond most everyday developer’s needs

But Propel is dead

Oh no, it’s not!!!

With the new 1.5 it REALLY got amazingly easy to write your code, extend your Query Model and easy query creation. 1.6 is on it’s way and 2.0 was just recently announced to be based on Doctrine2, as a layer on top, providing the usability features… that’s something we will have to wait for, but I does sound very good.

But Benchmarks show that…

So what? I couldn’t care less. Why should I? I am not running sites that have gazillions of users with quadrubillions of tables and hexafoobarillions of rows – I don’t care if grabbing all posts with a certain topic and tag for a given user takes 111 ms or 132 ms. But I do care if I have to consult the docs for writing that query because I couldn’t remember the syntax or – on the other hand – my IDE (yeah, right, eclipse, I’m REALLY old fashioned) nearly automagically creates the query for me.

But what are you actually trying to say?

• Most developers don’t need benchmarks to find their ORM – it’s about own style and preference (or customer specs, but thats another story)
• Some symfony developers might not even have thought about giving “the other one” a try.
• Personally, I get along with propel 1.5 better
• I’m getting old

So, if you know Doctrine, give Propel 1.5 a try.

If you only use Propel, give Doctrine a try.

And if you still use Propel 1.4 – MAN!!! Get the 1.5!!!

Any comments appreciated, I really like to see what I’m missing

PS: I’m even more old fashioned: I’m using vi – not vim, but eclipse with the vi plugin. Why? REAL code completion! A wonderful thing with propel 1.5!

I'm getting old and I'm old fashioned. I'm still using mysql, not mongoDB. I'm using php and apache, not node.js, ruby, python or lighttpd, nginx or .... And I'm using propel again (1.5), not doctrine. AND I'M LOVING IT!! After #sfdaycng 2009, the presentations and talks there, I forced myself to giving Doctrine a try and really liked it then. A lot of reading through documentation in the beginning if you are new to it, but hey, that's normal. However, today, even when writing a simple query, I still have to consult the docs. Why? The syntax seems not to be "my style" somehow, it won't fit into my type of writing code. But there is such a HUGE difference between Doctrine and Propel and Doctrine is SO MUCH BETTER Is it? Do I care what's inside if I'm only querying a database without using all possibilities? Remember sfLive 2010? "Is Doctrine re-inventing propel" Hahaha LOL ROFL LMAO At this years big symfony conference #sflive2010, in a Q&amp;A session about Doctrine2, a poor guy obviously asked the question, that made it into a big running gag: "Are you trying to re-invent propel?" I have to admit and regret that I was not there, but if you followed the #sflive2010 hashtag on twitter, it was not very long until this got tweeted over and over again. And everybody was making fun of it... Sure, it is kind of funny to ask @jwage, (lead) developer of Doctrine that question... But hey? What's really so funny about it? While everybody in the audience laughed, it really would have been interesting to a) see how many were trying to smirk, wondering whats so funny about that b) know how many would have been able to give a good reply on that? And with "good reply" I mean, explain the difference. And with "difference" I mean, explain it beyond "doctrine has the schema.yml and the model classes in a subfolder" "propel uses two classes User and UserPeer, doctrine has User and UserTable" "propel has a criteria object, doctrine a query object" If you started with symfony 1.0 as a developer that did not work with frameworks like symfony before (like I did), everthing is "symfony" - may it be propel, phing, creole, PDO, ... and getting into these differences was not really worth it in the first place if you wanted to get started with writing your first applications. What I'm trying to say: I guess that a lot of symfony developers out there don't know or care about "Doctrine" vs "Propel" - they use the default. And they call it "symfony", thinking that it belongs to it. If they started with symfony &lt;1.2, they'll use propel, now they use doctrine - because it's the default. You learn it, you use it, you stick to it. And I sticked to propel throughout 1.2. And it was quite save for me getting along ignoring Doctrine. Just then, when I started using Doctrine after #sfdaycgn I found new things, new approaches, things I liked, things I had to learn and a lot of stuff I could not get the hang of. So now, with propel 1.5 and the new Query objects, I gave it a try and was so excited, I decided to come back to Propel. Just because it "feels like home" and fits my personal style of thinking/coding. And of course both ORMs have their features and behaviours and at #sfdaycng Doctrine had more of them and so on... But I also assume that a lot of those features are beyond most everyday developer's needs But Propel is dead Oh no, it's not!!! With the new 1.5 it REALLY got amazingly easy to write your code, extend your Query Model and easy query creation. 1.6 is on it's way and 2.0 was just recently announced to be based on Doctrine2, as a layer on top, providing the usability features... that's something we will have to wait for, but I does sound very good. But Benchmarks show that... So what? I couldn't care less. Why should I? I am not running sites that have gazillions of users with quadrubillions of tables and hexafoobarillions of rows - I don't care if grabbing all posts with a certain topic and tag for a given user takes 111 ms or 132 ms. But I do care if I have to consult the docs for writing that query because I couldn't remember the syntax or - on the other hand - my IDE (yeah, right, eclipse, I'm REALLY old fashioned) nearly automagically creates the query for me. But what are you actually trying to say? Most developers don't need benchmarks to find their ORM - it's about own style and preference (or customer specs, but thats another story) Some symfony developers might not even have thought about giving "the other one" a try. Personally, I get along with propel 1.5 better I'm getting old So, if you know Doctrine, give Propel 1.5 a try. If you only use Propel, give Doctrine a try. And if you still use Propel 1.4 - MAN!!! Get the 1.5!!! Any comments appreciated, I really like to see what I'm missing PS: I'm even more old fashioned: I'm using vi - not vim, but eclipse with the vi plugin. Why? REAL code completion! A wonderful thing with propel 1.5!

During the last months, I started paying more attention to unit testing and writing tests in my symfony apps. But not until this awesome post from Bernhard Schussek, I really understood how you can make your testing life easier and get tests done better, faster and be more efficient.

It also helped me to understand, to which granularity you can and should break down your tests as well as your methods in the lib classes.

So this really is a BIG FAT recommendation on reading the article!!

What I learned from it and what I am doing ad enjoying right now, when creating new functionality:

• If I have a complex method to write, I break it down into the smaller parts that need to be done step by step. For this, I write the logic with methods that are not even exisiting yet.
• Next, I write the unit TESTS for these non-exisiting methods, filled with test cases that make sense in the current context of the problem and help to make sure the method works
• Next, create an empty stub of the new method, so you can start running the test without a crash – but of course it will fail
• Add functionality to the method to make sure you finally pass all tests.

This really makes the whole process a lot of fun because it really is rewarding to see the “All tests successful.” or “# Looks like everything went fine.” at the end.

And you can continue with your next part of the more complex functions with a good feeling of confidence, that in the end it will all work fine

During the last months, I started paying more attention to unit testing and writing tests in my symfony apps. But not until this awesome post from Bernhard Schussek, I really understood how you can make your testing life easier and get tests done better, faster and be more efficient. It also helped me to understand, to which granularity you can and should break down your tests as well as your methods in the lib classes. So this really is a BIG FAT recommendation on reading the article!! What I learned from it and what I am doing ad enjoying right now, when creating new functionality: If I have a complex method to write, I break it down into the smaller parts that need to be done step by step. For this, I write the logic with methods that are not even exisiting yet. Next, I write the unit TESTS for these non-exisiting methods, filled with test cases that make sense in the current context of the problem and help to make sure the method works Next, create an empty stub of the new method, so you can start running the test without a crash - but of course it will fail Add functionality to the method to make sure you finally pass all tests. This really makes the whole process a lot of fun because it really is rewarding to see the "All tests successful." or "# Looks like everything went fine." at the end. And you can continue with your next part of the more complex functions with a good feeling of confidence, that in the end it will all work fine :-D

Planning, planning, planning…
Last night I read some stuff about RESTful applications… and of course, quickly, the following plan came to my mind: I need it! Somewhere!
And of course, as always, the best baby for testing and applying new techniques is www.karopapier.de
So I decided I need a KaroAPI, using RESTful approaches.

Digging through it, the next question came: Should I use XML or JSON for the output? Or both?

JSON has the advantage to be shorter, I like it better AND: It could be used in a new JavaScript based frontend. Imagine to simply to a AJAX/JSON request for the details of a game and nicely format the data in a Browser.

XML, older, more widely spread, is more commonly used and maybe can be parsed with some clients more easily – and applying XLS/XLST it could also be readable and nicely formatted for humans.

Next thought was: “Well – offer both” – creating an object with PHP and then either apply a json_encode or XML_Serialize should not be a big deal, right?
Well, we would see…

And not enough of all the big plans, I thought I could give symf Symfony2 a try.

Sooooo:
Big plan, draft 0.3:

• KaroAPI
• JSON and XML representation of data (for bots, clients and other KaroTools)
• use Symfony2 for the implementation

Added to the todo list… the big problem – already so much on this list. And I never manage to do it one by one, but get distracted by so many other interesting things…
Like, lately, when I introduced APE into the chat. But, Hey, I did not even blog on that yet…

Planning, planning, planning... Last night I read some stuff about RESTful applications... and of course, quickly, the following plan came to my mind: I need it! Somewhere! And of course, as always, the best baby for testing and applying new techniques is www.karopapier.de So I decided I need a KaroAPI, using RESTful approaches. Digging through it, the next question came: Should I use XML or JSON for the output? Or both? JSON has the advantage to be shorter, I like it better AND: It could be used in a new JavaScript based frontend. Imagine to simply to a AJAX/JSON request for the details of a game and nicely format the data in a Browser. XML, older, more widely spread, is more commonly used and maybe can be parsed with some clients more easily - and applying XLS/XLST it could also be readable and nicely formatted for humans. Next thought was: "Well - offer both" - creating an object with PHP and then either apply a json_encode or XML_Serialize should not be a big deal, right? Well, we would see... And not enough of all the big plans, I thought I could give symf Symfony2 a try. Sooooo: Big plan, draft 0.3: KaroAPI JSON and XML representation of data (for bots, clients and other KaroTools) use Symfony2 for the implementation Added to the todo list... the big problem - already so much on this list. And I never manage to do it one by one, but get distracted by so many other interesting things... Like, lately, when I introduced APE into the chat. But, Hey, I did not even blog on that yet...

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.

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.

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…

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 &lt;irony&gt; 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: [php] 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'); [/php] 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...

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…

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...

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…

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...

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

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

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…

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...