Well, Ludum Dare 27 is less than one week away, but my preparations are still far from done. But that's OK - it's part of the challenge after all.
If you haven't head of it, Ludum Dare is a rapid-prototyping game development challenge, where the participants (usually around 1000; Ludum Dare 26, which took place this April, has over 2000 participants!) have 48 hours at their disposal to develop a game from scratch, based on a given theme. Well, "from scratch", in this case refers to the content itself. You're not allowed to use any pre-existing content, be it a public domain image or sound sample. It's just against the rules. However, as far as frameworks, engines and libraries are concerned, there are basically no restrictions, and people use everything from their little C++ frameworks and Flash, to libgdx (which is what I use), Unity 3D, Construct, XNA and other large frameworks and tool sets. And by the way, the name is pronounced Loo-Doom Dah-Reh, since it comes from Latin and essentially means "To give a game". Some people just pronounce it Loo-Doom Dare (dare, as in challenge), which is also pretty cool.
You'd think it's a no-brainer to choose the framework to use - just pick a really well-documented one a few weeks in advance, mess around with it, and use it during Ludum Dare. Duh! But it's just not that easy. It's sometimes easy to create a toy app in a framework and immediately convince yourself that you know how to use it, only for Ludum Dare to start and you to find yourself stuck trying to change some of the framework's behavior to make some small detail in your game work. BAM! - several valuable hours down the hatch.