A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|ALL

  检 索： 期刊名称 ISSN         高级检索

期刊名称：DR DOBBS JOURNAL ISSN： 1044-789X 出版频率： Monthly 出版社： MILLER FREEMAN, INC, 600 HARRISON ST,, SAN FRANCISCO, CA, 94107   出版社网址： http://drdobbs.com/ 期刊网址： http://drdobbs.com/ 影响因子： 主题范畴： COMPUTER SCIENCE, SOFTWARE ENGINEERING 期刊简介(About the journal)    投稿须知(Instructions to Authors)    编辑部信息(Editorial Board)    About the journal The history of Dr. Dobb's Journal goes back to the earliest days of the microcomputer industry. In 1975, MITS created the Altair, the first real microcomputer. One of the few people who realized the significance of this event was Bob Albrecht, an ardent supporter of computer education for the masses. Albrecht had always believed that the general public should have access to computers and knew that the Altair and similar machines could make this happen. He also realized that widespread use of microcomputers was unlikely as long as the only language in which they could be programmed was assembly language. Albrecht concluded that what was needed was a public-domain version of BASIC that could be distributed to microcomputer enthusiasts everywhere. He persuaded his friend Dennis Allison, a member of the Computer Science faculty at Stanford, to write a version of BASIC that was small enough to fit within the limited memory of the new machines. Dennis and Bob originally published the design of "Tiny" BASIC in a quarterly tabloid, called "People's Computer Company" (PCC), in three parts during early 1975. PCC, which was created in the early 1970's by Bob, was devoted to computer games, BASIC programmming and computers for the masses. In December 1975, Dick Whipple and John Arnold responded to the design articles with a Tiny BASIC that required only 3K of RAM. Albrecht and Allison decided to publish Tiny BASIC as a three part document in newsletter format and "Dr. Dobb's Journal of Computer Calisthenics and Orthodontia" was born. The name "Dobb's" came from collapsing together (sort of) Allison's and Albrecht's first names. Unfortunately, the pasteup artist titling the original newsletter, thinking Allison's name was Don, combined it with Bob to produce Dobb (DOn and BoB). Jim Warren, DDJ's founding editor, gives an interesting account of this and other events of the time in the January '91 issue of DDJ (see "We, The People" in the special 15th Anniversary Section). In any case, Dr. Dobb's Journal no longer distributes Tiny BASIC to the masses and today's DDJ reader is apt to be a professional who makes his or her "bread and butter" as a software engineer. DDJ caters to this individual by providing practical solutions to real-world problems. In the magazine, you'll find descriptions of algorithms, specific language implementations, and edifying examples of solutions to more general programming concerns. You'll also find "task specific" articles that solve a specific problem or provide a unique technique. DDJ is primarily a software magazine, but that doesn't negate the importance of articles featuring hardware and hardware-related subjects. Instructions to Authors Most of the articles that appear in Dr. Dobb's Journal are written by readers just like you--programmers who have something they're interested in and would like to share it with fellow programmers. In other words, articles can be described as real solutions for real programmers, usually going well beyond the familiar "hello world" type of article. The best Dr. Dobb's articles are those that are grounded in your real-world experiences with programming tools and techniques. It is important to remember that Dr. Dobb's readers begin receiving the magazine about 5 weeks prior to the cover date. This means that articles need to be complete and in our hands at least 3 1/2 months before the cover date. Is Dr. Dobb's interested in my article? What kinds of articles does Dr. Dobb's print? How do I propose an article? How do I write an article? How do I send a completed article? Whom do I send my article to? What happens next? Dr. Dobb's Journal Editorial Calendar Is Dr. Dobb's interested in my article? If you're a programmer who has done something you think is interesting, odds are that other programmers will also think it's interesting. Writing for Dr. Dobb's will give you the chance to share your innovations and insights with other programmers who can appreciate what you've done. Dr. Dobb's articles tend to be fairly narrow in focus, looking at a single technique or problem. A magazine article is too short to discuss an entire large development effort, but it's just the right size for discussing how you solved a single, specific problem. Dr. Dobb's readers are serious programmers who look to Dr. Dobb's Journal for useful information. They read Dr. Dobb's for descriptions of algorithms, specific language implementations, and edifying examples of solutions to more general programming concerns. Many articles in Dr. Dobb's are "task specific" -- they solve a specific problem or provide a unique technique. (Keeping this point in mind helps you focus your writing.) Most articles in Dr. Dobb's have source code with them, ranging from a few dozen lines to illustrate a particular technique or language feature to tens of thousands of lines implementing a complete application. Good source code is not very useful by itself, however. A good article describes why the source code is interesting. Is this technique faster than other techniques? How does your tool compare to other similar tools? If your program is an implementation of a protocol, algorithm, or data structure, tell us about the protocol, algorithm, or data structure. Not all articles are about software, however. We publish articles on hardware issues (especially if there is a software component), as well as articles covering legal, social, and business issues of direct interest to software developers. Dr. Dobb's is both platform- and language-independent. We cover operating environments including DOS, Windows 3/95/NT, MacOS, OS/2, UNIX, Linux, and real-time operating systems. In addition to C and C++, we routinely cover Java, Tcl, Perl, Visual Basic, Python, Cobol, Delphi, Fortran, Modula-3, Basic, Smalltalk, assembler, Bob, and other familiar (and unfamiliar) programming languages. What kinds of articles does Dr. Dobb's print? Feature Articles Dr. Dobb's Journal has "themes" that tell readers what they can expect in that issue. Feature Articles are responsible for delivering on that theme. Most articles submitted by our readers are considered as possible feature articles. If you are proposing a possible feature article, you should consider what theme issue it might fit. However, our themes are quite flexible, and we'll print a good article whenever we have space, even if it doesn't precisely match that month's theme. Embedded Systems Every month, Dr. Dobb's Journal publishes an article on some aspect of embedded systems. These are computer systems which are developed for a specific task, from controlling a car engine to putting a rocket in orbit. These types of systems have some unique requirements: special hardware, new communications protocols, custom operating systems, different languages, development tools, and development methodologies. We're not afraid of block diagrams or schematics, but you should make a clear tie to the software side of embedded systems development. Articles about emulators or real-time operating systems are also appropriate here. Internet Programming Especially with the rapid growth of the Internet, software developers are very interested in all aspects of network programming, from client-server database development and distributed operating systems to Web applets and networked coffee machines. This section is your chance to talk about network protocols, systems, and development strategies. Programmer's Toolchest The Programmer's Toolchest is where Dr. Dobb's Journal looks at specific products. Unlike typical product reviews, which give a feature checklist and a "thumbs up" or "thumbs down" conclusion, we want to know what it's like to use the product. This is your chance to tell us about the tools you've used, and how they helped or hindered you in solving specific problems. Programmer's Toolchest articles vary in their approach. Some focus on a particular problem, and show how to solve that problem with different tools. Others focus on a particular, little-known aspect of a common tool and show how it can be useful. Some of our most popular Programmer's Toolchest articles show how to combine two or more tools to solve a particular problem. Often, this involves circumventing certain mis-matched features, taking advantage of different strengths of otherwise competitive products, or taking an unusual approach to a problem, one that might not have occurred to someone else. Like all of our articles, Programmer's Toolchest articles usually provide a healthy dose of code. Those who already own the products can put that code to work immediately, and those who are assessing it can use the code to take a firsthand look. Your fellow programmers are looking for your expert knowledge and experience in using a tool under real-world conditions; this is more valuable than just knowing that a tool exists. Ultimately, the reader should walk away with a sense that he or she has actually used those tools. Although you're certainly free to throw in your own recommendations, this hands-on approach should allow readers to make their own conclusions about whether that tool will work for them. Columns For the most part, individual columns are written by our contributing editors. However, three of our columns regularly feature contributed articles ¡ª "Java Q&A," "Algorithm Alley," and the "Programmer's Bookshelf." If you have the answer to a challenging Java question and are interested in writing an article describing your solution, then we'd like to hear from you. Contact us at editors@ddj.com. If you've come up with a new algorithm or refined an old one, we have someone to help you develop your idea. Contact editors@ddj.com if you have an algorithm you'd like to present in our "Algorithm Alley." If you have read a valuable programmer's book or two, contact Jonathan Erickson (jerickson@ddj.com), who will help you turn your opinions into an article. Dr. Dobb's views books as important programmer tools and treats them as such in the column. We usually like to spend no more than 750 or so words on an individual book, and prefer to cover two or three in the same issue. How do I propose an article? If you have an article idea, you should first send us an article proposal. This is a short statement (about a page) that says what your article will be about. You can mail it to our office or e-mail it to editors@ddj.com. Be sure to give us several ways to contact you (such as phone number, e-mail address, fax number, and mailing address). We'll look at your idea and get back to you, usually within a month. Although many people simply write their entire article and send it to us, there are several advantages to sending us a proposal. We can look at your idea and possibly suggest a particular slant you hadn't considered. We can also help you to organize the article. How do I write an article? Writing Style Write as if you are giving a brief, informal talk to a group of coworkers. You want to be concise and well organized because you don't want to waste their time, but you don't want to be too stuffy or formal because you know them. If there's an issue or example that's important, but slightly off topic or more difficult, consider separating that into a 300-400 word sidebar. We encourage you to describe in depth all of the algorithms your program uses. Go into as much detail as possible. Your article should provide something useful to the readers, even if they never look at the code. Ideally, your article should begin with a concrete, general perspective on how the algorithms can or have been used practically. Teach something in your article. Though Dr. Dobb's readers are, by and large, a knowledgeable lot, many of them are reading your article to learn something new. Consequently, your article should contain more than a technical description of the code. It should explain how a program works and why you made each important programming decision. Describe a few basics before jumping into a very technical discussion. Of course, you can't explain everything about your topic in a short magazine article. Nevertheless, a reader should be able to understand the basics of how your program works by reading your article. Address the issue of portability. Even if your program is very machine specific, your underlying algorithms and tricks will transfer. Say how. If applicable, provide a bibliography at the end of the article that includes a description of each of the referenced sources. It is essential that you include the full bibliographic information of all sources! This means title, publisher, date of publication, author, issue (if a periodical), place of publication, and any other information that is pertinent. Do not hype your product. An article that amounts to little more than a product description or lengthy press release will have to be rewritten. Parts of a Typical Article A typical article contains several parts: Article text Articles usually range from 2000-3500 words of text. However, you should make your article the right length for your topic. The most common problem with submitted articles is that they are too long, with a lot of details that don't really belong. Text within the main article should stand alone, rather than relying on the illustrations. For example, you should first explain a topic then refer to the illustration: "Although the Trend function is useful in some applications, a more flexible approach is to use the equation as a matrix operator, as shown in Figure A." Tables Tables are a concise way to give particular types of information. Give each table a clear, detailed caption, and refer to it in the text by number. ("As Table 1 shows, ...") Figures Illustrations and screen captures offer an opportunity to lure anyone looking through an issue into reading your article. They can also provide succinct summaries of complex ideas. Since we redraw most figures anyway, to conform to our size and style requirements, you should not worry about making your images very high quality. Many authors prefer to sketch them by hand and fax or mail them. Please provide any screen captures you think are relevant. We don't necessarily have the time or equipment to run your program and make our own screen captures. Screen captures should be in a common graphics format (such as GIF, PCX, TIFF, or BMP) Please don't embed your images in a word-processing document. Examples Short pieces of code (less than 20 lines) can be placed near the text as Examples. Like Tables or Figures, they should have clear captions and be referred to by number. ("A better approach is to use Knuth's algorithm, outlined in Example 1.") Tables, Figures, and Examples are placed at the top or bottom of the page in the magazine. Although we do try to place them near where they are needed in the text, space constraints sometimes force them onto a later page. Keep this in mind as you write. Listings Longer pieces of source code are printed at the back of the magazine or on the pages following the article. For space reasons, these should be less than about 400 lines. Often, these will be a few important excerpts from a longer piece of source code. Complete Source Code Although we can't publish the complete source code to large projects (or binaries), we do make this code available to our readers in many ways, including our FTP sites, the Web, and so on. You can (and should) refer to this code in your article, but be careful since the reader will not have the source code immediately available. Other Information Please include suggested headline (title), decks (subtitle), subheads (section titles), and a two-sentence author biography. Also, please provide short captions for all examples, figures, and tables. All should be in active voice. General Writing Guidelines Keep your writing informal and concise. Here are some concrete suggestions: Use the active voice when possible. (Avoid excessive use of forms of "to be." For example, don't say "The problem is that XXX", just say "XXX is a problem.") Don't use "we" or "our" unless there are multiple authors; use "I" instead. Similarly, refer to the reader as "you." (For example, "Although I chose a simpler approach, you might find the full algorithm necessary in some situations.") Avoid needless duplication. Read your article carefully and ask yourself whether each sentence and paragraph adds to the article or simply duplicates a point you've already made. Many writers find it useful to put their article aside for a few days after they write it, and then come back and read it again. Get a friend to read and comment on your article before you send it to us. Make sure that every Figure, Table, Example, or Listing is referred to somewhere in the article. Don't put lengthy code excerpts, tables, or figures into the text. Any piece of code longer than a few words should go into an "Example" or a "Listing" (see above.) Refer to parts of a listing by using function names or other apparent locations ("...the definition of variable cpLine..."). Do not use line numbers. If you refer to source code that isn't going to be printed in the magazine, use the name of the source file and the function or other apparent location. Take the same care in preparing your Listings that you do in polishing your article. People will be reading your source code; make sure it is clearly formatted, no more than 70 columns wide, and reasonably commented. How do I send a completed article? Once you have something you like, it's time to package it all up. Although we accept articles in a variety of formats, here are some of our preferences: Save each figure, table, example, or listing as a separate file. If you want to e-mail, build a ZIP/PKZIP archive containing the separate files, then UUENCODE or use MIME to e-mail it to us. If you want to mail it, include all of the files on a 3.5" diskette. Don't forget the complete source code for inclusion on our FTP site. Provide all listings and examples as plain text files. Provide graphics in a common graphics format (GIF, TIFF, PCX, BMP). Don't worry about making it perfect; we recreate most graphics so they look as good as possible. However, if you have screen shots or the output of a program you're demonstrating, be certain to tell us, so we won't unintentionally alter them. The article text should be provided in a plain text format, which is what we often work from. Especially if there are formulas or other special symbols, please provide a hard-copy printout as a reference. Word processor files are often useful, but don't waste much effort formatting them, and please don't embed figures in the word processor file. Remember to include your name, work and home address, work and home phone numbers, e-mail address, and any other information that might help us contact you. (We can't publish your article unless we can contact you and mail you a contract.) To include an article in a particular issue, we request that you give us the final article at least four months ahead of the cover date. It typically requires at least a month to review and edit an article, another month to typeset and prepare the magazine, and our magazine actually ships to subscribers one full month prior to the cover date. Whom do I send my article to? If you've first sent a proposal, then you should already have the name and address of an editor you're working with. You should send it directly to them. Otherwise, you can mail them to "Editors" at our office or e-mail them to editors@ddj.com. What happens next? Once we receive an article, we go through a number of steps to evaluate it and prepare it for publication: If you send us a proposal, we'll assign an editor to work with you. That editor will discuss your proposal with you and help you refine your idea. After we receive the finished article, we'll decide if we want to publish your article. If we do, we'll send you a publishing agreement. This agreement tells you that we want to publish your article; it's not a guarantee that we will publish your article. However, if we don't publish it within 12 months, the contract will expire, and you can offer it to another magazine if you wish. The publishing agreement will specify the fee you will receive for publishing the article (yes, we do pay for all articles in Dr. Dobb's), along with the rights we need to acquire. Essentially, we request the rights to publish your article and accompanying code in Dr. Dobb's magazine, include it on our annual CD-ROM, publish it on the Dr. Dobb's web site, and so on. One of our technical editors will carefully go through the entire article. They'll check that your article makes sense, and may rewrite sections of your article to make it clearer. Our technical editors are experienced software developers and writers, and our authors usually find their work is improved in this process. If an article requires more extensive changes, the editor will frequently ask the author to make the changes. Please be patient at this stage. Our technical editors are very careful; it sometimes takes a full week to edit a single article. As a result, an editor that has three or four articles to work on may not be able to give you useful feedback for a while. Our Editor-In-Chief will take the edited article and decide which issue it goes into. Notice that although the contract specified a particular issue, that was only a guess. About three months before the cover date, the article goes to our production staff. They produce a galley proof of the article and send it to the author for any final changes. They also create a mock-up of the magazine containing all of the articles. This mock-up is thoroughly edited by our entire editorial staff, which checks every article for grammar, style, punctuation, and other minor problems. Any corrections the author makes to the galley proof are incorporated at this stage. About two months before the cover date, the final magazine goes to the printers, and it is mailed to subscribers and newstands about a month before the cover date. There are times when our office is extremely busy, so we will sometimes not be able to respond to a proposal or article for several weeks. If you've not heard anything for more than a month, however, please call us. Finally, whether it be a letter to the editor describing an optimized "mouse trap" or an article on how to design your own "super widget," the articles in DDJ are often written by the readers of DDJ. If you have an idea, you can discuss it with the editors at editors@ddj.com. And, be sure to get a copy of the Author Guidelines. Editorial Board Jonathan Erickson has been DDJ's editor-in-chief since 1988. Before joining DDJ, Jon was senior west-coast editor for Byte and senior editor for Osborne/McGraw-Hill books. He is the author of ten books, ranging from graphics programming to organic gardening. Dr. Dobb's Journal 2800 Campus Drive San Mateo, CA 94403 Phone: 650-513-4578 Fax: 650-513-4618 Internet: jon@ddj.com Internet: jerickson@ddj.com