API-Blog

Wie cool ist das den eben war ich auf der Suche wie man Favicons über html einbindet als ich das hier auf wikipedia gelesen habe.

Mittlerweile existieren bereits Spiele, die komplett im Favicon des Browsers realisiert werden. Die Pionierleistung erbrachte der französische Webentwickler und Designer Mathieu Henri. Das kleine Remake des Arcadespiels Defender ist in JavaScript geschrieben.[1] Der Code erzeugt jeden Frame des Spiels in der Favicongröße (16×16 Pixel). Anschließend wird er in ein PNG konvertiert.

Ein komplettes Spiel als Favicon in einem Browser ;) ... L0L das ist ja mal cool.... spielt es einfach mal selber auf http://www.p01.org/releases/DEFENDER_of_the_favicon/

.Net error pages the nice way ... Gary shows a nice example how to get them ...

Vorraussetzungen

• http/https über mod_dav
• SSH
• direkt über das filesystem

   svn co https://mein.server.example.com/repository/calculator /mein/lokaler/pfad/calculator

Die Basics: Aktualisieren, Löschen, Hinzufügen

   cd /mein/lokaler/pfad/calculator
   svn up

   cd /mein/lokaler/pfad/calculator
   svn rm mein_Ordner
   svn rm meinedatei.txt

   svn co -m "Ein Kommentar über Änderungen" /mein/lokaler/pfad/calculator

Branchen und Mergen

Branch anlegen

  svn --username=XYZ copy -m "Erzeuge Branch " https://mein.server.example.com/repository/calculator/trunk https://mein.server.example.com/repository/calculator/branches/t_NNNN_AAAA

Branch auf den neuesten Stand aus dem HEAD bringen: (HEAD--> BRANCH)

  cd /mein/lokaler/pfad/wo/der/calculator/branch/liegt
  svn merge -r rev:HEAD https://mein.server.example.com/repository/calculator/trunk .

Branch mit HEAD mergen: (BRANCH --> HEAD)

  cd /mein/lokaler/pfad/wo/der/calculator/trunk/liegt
  svn merge -r rev:HEAD https://mein.server.example.com/repository/calculator/branches/BRANCHNAME .

Zum Schluss

If someone would ask me, how can I make sure I'm not fired in economy crisis and loose my job as a programmer. I would tell him:

Documentation

• Lie in the comments: You don't have to actively lie, just fail to keep comments as up to date with the code.

• Documentation Gotchas: Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. If you have ideas about how the code should be reorganised or rewritten, for heaven's sake, do not write them down. Remember the words of Thumper in the movie Bambi "If you can't say anything nice, don't say anything at all". What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired. An anonymous comment that says "This needs to be fixed!" can do wonders, especially if it's not clear what the comment refers to. Keep it vague, and nobody will feel personally criticised.

• Document How Not Why: Document only the details of what a program does, not what it is attempting to accomplish. That way, if there is a bug, the fixer will have no clue what the code should be doing.

Program Design

• Avoid Encapsulation: In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.

• The Magic Of Global Variables: Instead of using exceptions to handle error processing, have your error message routine set a global variable. Then make sure that every long-running loop in the system checks this global flag and terminates if an error occurs. Add another global variable to signal when a user presses the 'reset' button. Of course all the major loops in the system also have to check this second flag. Hide a few loops that don't terminate on demand.

• No Secrets: Declare every method and variable public. After all, somebody, sometime might want to use it. Once a method has been declared public, it can't very well be retracted, now can it? This makes it very difficult to later change the way anything works under the covers. It also has the delightful side effect of obscuring what a class is for. If the boss asks if you are out of your mind, tell him you are following the classic principles of transparent interfaces.

Nameing

• Use Plural Forms From Other Languages: A VMS script kept track of the "statii" returned from various "Vaxen". Esperanto , Klingon and Hobbitese qualify as languages for these purposes. For pseudo-Esperanto pluraloj, add oj. You will be doing your part toward world peace.

• Names From Other Languages: Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.

Testing

... and the best at the end ... lol!

• Never Test: Never test any code that handles the error cases, machine crashes, or OS glitches. Never check return codes from the OS. That code never gets executed anyway and slows down your test times. Besides, how can you possibly test your code to handle disk errors, file read errors, OS crashes, and all those sorts of events? Why, you would have to either an incredibly unreliable computer or a test scaffold that mimicked such a thing. Modern hardware never fails, and who wants to write code just for testing purposes? It isn't any fun. If users complain, just blame the OS or hardware. They'll never know.

• Never, Ever Do Any Performance Testing: Hey, if it isn't fast enough, just tell the customer to buy a faster machine. If you did do performance testing, you might find a bottleneck, which might lead to algorithm changes, which might lead to a complete redesign of your product. Who wants that? Besides, performance problems that crop up at the customer site mean a free trip for you to some exotic location. Just keep your shots up-to-date and your passport handy.

And if that's not enought try the following link where I took those examples from, thx to Roedy Green and Canadian Mind Products