debuggable

After our previous post, we are very happy to announce our formal apology to the CakeDC and the Cake Software Foundation.

After further discussions with the CSF we have come to understand why the CSF needs to have an agreement with the venue, this is required to free the funds for making this transaction since the CSF would be legally responsible for the payment. Larry E. Masters has helped us to work out all misunderstandings in that regard, and we would also like to formally apologize to him.

Beyond that, we are also apologizing to the CakePHP community, for jumping the gun early, and having caused damage to the image of the project. This was not our intention, and we only did that, as a last resort to see the venue paid and defending our business from harm.

As previously announced, we are still planning on being valuable members to the community, releasing plugins & components as open source.

We are grateful to all those who donated, and will reimburse everybody completely once the venue has been paid in full, or in no longer than 60 days from the time of your donation, whichever comes first. We will take down the pledgie site also. Until then we will continue to pay the venue 500 EUR / month, so that any eventual delays will not be to their disadvantage. We also had a misunderstanding with the agreement Larry E. Masters had made to personally cover the 500 EUR / month while the CSF was trying to clear up the situation with the 501(c)(3) status. He also clarified, that the CSF is an independent entity from the CakeDC with its own board of directors which currently hold these positions temporarily and that a new board will be in place when all of this legal stuff is completed.

Please, do not let any of this reflect on your opinion about the framework. Every community has their difficult moments, and the CakePHP community has just shown how strong it is, and that all parties are willing to cooperate for its prosperous future without leaving any hard feelings behind.

Sincerely Yours,

Felix Geisendörfer, Director
Tim Koschützki, Director

Latest Update: The whole situation has been resolved, please read our apology to the CSF and CakeDC.

We are truly thankful. Since putting up our post last night, people have already donated 2,075.00 EUR. There were almost 30 donators, some of them donating as much 600 EUR, with others who have pledged continuing support over the next months.

We cannot thank everybody enough for this, and all the kind comments. But as a start, here is the list of people who have donated so far, we'll keep it updated. If you want your name to be linked, just email us.

• Garrett Woodworth
• Shawn Stratton
• Phillip Hile
• Aaron Forgue
• Rob Wilkerson
• Clay Loveless
• Gilles Grinfeder
• Jeff Loiselle
• Lars Schenk
• Nathan Abele
• @elventails
• @indiefan
• Yusuke Ando
• @jperras
• Jon Adams
• Jose Diaz-Gonzalez (@savant)
• Dirk Olbertz
• Mark Boas
• Charlie van de Kerkhof
• Lucian Lature
• @leomelzer
• Robert Scherer
• Guillaume Sautereau
• Daniel Hofstetter
• Arne Psczolla
• @pzwiers

Regarding the question: Did we publish this to harm the CakePHP community?

The answer is no, we are sorry if this shines a bad light on the project. We had two motivations to publish this post. For one, we wanted to reach out for help with this bill. However, we also wanted to share our story with the community, giving them the chance to push for improvements of the situation CakePHP is in.

But you don't have to take our word for it. We already have a few new plugins & components lined up for release. This project has a community of great people, and just as they have supported us in this tough moment, we plan to continue supporting them.

Again, thanks to everybody who helped, also those who are not involved with CakePHP at all!

--fg

Latest Update: The whole situation has been resolved, please read our apology to the CSF and CakeDC.

6 months ago, I posted about a great event which we helped to organize: CakeFest #3, here in our home city of Berlin. This event helped to connect developers from all over Europe, and even as far away as Australia, Tokyo and Los Angeles. There were great people, talks, and food, and everything ran extremely smoothly. By any measurement, it was a huge success.

This did not happen by accident. A number of people made a big effort to put the event on, starting with lots of planning and communication months beforehand. Debuggable helped by finding and booking the venue, researching, and coordinating logistics here on location. We didn't make money from this, and that's okay. We wanted to support the CakePHP community by hosting another awesome event.

Over 6 months later, the GLS, who provided us with first-class service and what was probably the best venue ever, has still not received payment.

Don't be mistaken, this was not due to any errors in the organization of the event. The turnout was great, and the event was well-sponsored. The Cake Software Foundation, Inc., which collected all revenues, has already reimbursed its own organizing participants, but completely neglected to pay the venue (the bulk of the conference's expense). To make matters worse, the CSF has had their accounts frozen by the IRS.

How do we know this? Unfortunately, we are in the middle of this mess. In our efforts to help organize the event, we signed the proposal for the location and catering. We did so in good faith, because we were working in cooperation with the CSF, and of course had all such details approved.

When, in early October, we discovered that the venue never received payment, we initially believed it to be a mistake, and started delivering messages between the venue and Larry E. Masters, who in the meantime had taken over the position of CSF president after Garrett Woodworth had resigned. Larry told us he would take care of it.

Weeks passed, and we talked to the GLS staff every other day, asking them for their patience, as there appeared to be "problems" with getting the payment sent. A month later, on November 10th, Larry agreed to send a token payment of USD $4500 through the CakeDC via PayPal, which we forwarded to the venue (they do not accept PayPal).

Unfortunately, this is still the latest update on the payment. Of the total invoice of EUR 7665, the first payment (after currency conversion and PayPal fees) only amounts to EUR 2807, leaving an outstanding balance of EUR 5058 (USD $6929).

The venue has been incredibly patient and understanding through this whole process, but their patience has run out, and they're considering legal action against Debuggable. We signed the proposal, so technically they're not wrong: we are responsible.

At this point it's pretty clear that the CSF has no intention of taking responsibility for this, which leaves us with some hard choices. We could argue that, by invoicing the CSF and not us, that the venue implicitly signed over the contract to the CSF. We have to admit, we briefly considered doing that. 5K is not pocket money for us, and this definitely isn't our bill.

However, that would be wrong. Not to say that us paying this bill isn't wrong, but this is a wrong we can actually right. The venue deserves to get paid. So, we decided to go ahead and set up a plan to pay back the venue over the next few months.

Since a few people who have been aware of the situation have asked us to provide a way for them to help, too, we have put up a page on pledgie.com:

Donate to the CakeFest Venue Payment

We greatly appreciate any support, as it helps ease our burden, but the venue will be paid regardless of the outcome of the pledge. Right now, the most likely outcome is that we'll have to take care of this on our own, but we're still holding onto the hope that this last-ditch effort of going public might help change Larry's mind.

What's worse is his company, the CakeDC, now has exclusive controlling interest over a project which was once driven by its community. Despite his slowness to work this out with us, he has shown no hesitation in taking full advantage of the benefits of this control. If the CSF's position changes in any way, we will certainly send out an update.

--fg

PS: There is much more to this story, the CSF shake-ups, and why the their accounts are frozen, but it goes well beyond what we can verify. In the end, it doesn't matter; this isn't about finding fault, but about taking responsibility.

Even so most stuff is fairly easy with node.js, unit testing takes a little bit of getting used to. The main difference to regular unit testing is that just because your test finishes running without an error, it doesn't mean there was no problem. But lets start with the basics.

Node.js has adopted the CommonJS assert module specification. You may also find references to mjsunit, but node no longer uses this library.

Lets have a look at how to write a basic test with node, lets call it my-test.js:

Running this test will produce the following output:

$ node my-test.js
AssertionError: true == false
    at Object. (my-test.js:7:8)
    at [object Object]. (node.js:928:23)
    at [object Object].emitSuccess (node.js:240:15)
    at [object Object]. (node.js:653:21)
    at [object Object].emitSuccess (node.js:240:15)
    at node.js:510:29
    at node.js:985:1
    at node.js:989:1

One thing to note here is that, when node dies from an exception (which a failing assertion is), the exit code will be 1:

$ echo $?
1

But lets have a look at a more interesting unit test. Let's say you are writing a "hello world" web service called hello.js:

To test this service, we can write a file called test-hello.js like this:

What's important in this test is that we are checking for two things here.

The first is the obvious assertion that the web service outputs the content we expect, nothing too exciting here.

The second is declaring the variable callbackFired and checking its value in the process 'exit' event. You could get away with not doing it for this particular test, because the test would never finish without the hello.server.close() line getting executed. For more complex tests however, it becomes incredibly important to keep in mind that a callback may never fire, something you can only catch with little helper variables like this.

If you need some more inspiration for testing different stuff with node, you should start by going over the test suite that comes with it.

Let me know if you have any questions!

-fg

Git submodules suck. They are a pain to use, difficult to explain and you cannot check out partial trees. The later is an inherent limitation of git, but I have a fix for the rest.

Meet fake submodules. The idea is simple, instead of using actual submodules, you just trick git into thinking the files belong to the main repository while having the respective sub-dirs remain independent clones. Doing that is simple:

$ cd my-project
$ git clone <subproject-url> my-subproject
$ git add my-subproject/

The important part is the "/" (slash) at the end of the last command. If you omit that, git will automatically assume you want to add 'my-subproject' as a submodule. But if you don't, git just sees the files in the sub-directory and ignores that fact that its a git-repo of its own.

The cool thing is that you can now update a fake sub-module to the latest version as simple as:

$ cd my-subproject
$ git pull

This works because when you are inside my-subproject, git uses the '.git' folder closest to it which is my-subproject/.git. If the sub project is your own, you could even push your changes to it upstream without changing projects.

Now as far as collaboration is concerned, none of your collaborators will have a clue about your fake submodules. All they will see is some code in some folder. They will not be able to go into the my-subproject folder and git pull on it. However, if they need to do that, they can just rm -rf my-subproject and replace it with a clone themselves.

To me this is a pretty perfect & easy solution. I mostly use it for CakePHP plugins & node.js modules I am working on, but it works just as great with other peoples code you want to depend on. You can even apply hacks against their code, have them in your main repository, and make sure they stay applied on top by using 'git pull --rebase' when updating the sub project.

Let me know what you think!

--fg