<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Documentation&gt;SDK</title>	<link>http://tc.eserver.org/dir/Articles/Documentation/SDK</link>
	<description>A listing of the most recently indexed works about Articles and Documentation and SDK in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Documentation&gt;SDK</title>
		<link>http://tc.eserver.org/dir/Articles/Documentation/SDK</link>
	</image>
	<item>
		<title>Guidelines for Good Sample Code</title>
		<link>http://tc.eserver.org/33893.html</link>
		<guid>http://tc.eserver.org/33893.html</guid>
		<description>Sample code often provides the quickest, clearest way to learn how an SDK works. If you have software engineering experience, then you should already know many principles for writing good code. However, what you may not realize is that some of the good practices that you learned for writing good production code do not apply to writing good sample code. Some techniques, such as comments and clear variable names, apply to both production code and sample code. However, there are good reasons to use hard-coded values in sample code, which should be avoided in production code, and there are good reasons to avoid object-oriented designs when writing sample code.</description>
	</item>
	<item>
		<title>Software Development Kit (SDK) Documents in 10 Simple Steps</title>
		<link>http://tc.eserver.org/24657.html</link>
		<guid>http://tc.eserver.org/24657.html</guid>
		<description>Here are the ten simple steps to successful software development kit (SDK) documentation.</description>
	</item>
	<item>
		<title>Anything That Can Go Wrong: Lessons Learned from A Decade of Toolkit Documentation</title>
		<link>http://tc.eserver.org/24220.html</link>
		<guid>http://tc.eserver.org/24220.html</guid>
		<description>Writing software toolkit documentation for programmers is a special challenge and opportunity for technical writers.  Compared with writing software documentation for lay users, toolkit documentation is more demanding and exacting.  Checking facts and finding tiny errors is like riding a motorcycle through a swarm of gnats. However, for me at least, toolkit writing has opened doors to a larger role and greater input into product design. Engineers treat me like a peer and I get to see into their culture. I know my readers and salespeople need me.</description>
	</item>
	<item>
		<title>An Introduction to API Documentation</title>
		<link>http://tc.eserver.org/21697.html</link>
		<guid>http://tc.eserver.org/21697.html</guid>
		<description>This session will help you to: identify relevant source of information; extract information from the source; create effective API documentation; create context-sensitive help for DLLs (Dynamic Link Library).</description>
	</item>
	<item>
		<title>Creating an SDK: Writing on the Edge</title>
		<link>http://tc.eserver.org/14711.html</link>
		<guid>http://tc.eserver.org/14711.html</guid>
		<description>Sarr presents guidelines for the challenging task of creating a software development kit (SDK). The purpose of SDKs, the author writes, is to &apos;provide developers with information and coding examples to enable them to develop applications that will work with a newly developed technology.&apos;</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Documentation/SDK.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>