1st Sample

    Victory seemed unlikely. Mount Saint Michael was two sets down, and St. Leo’s undoubtedly had the upper hand in the third set, dominating 9 points to 2. Each time St. Leo’s scored, they pounded the ground in unison, further intimidating an already shaky Claremorris team. So how, in these circumstances, did they snatch victory from the jaws of almost certain defeat?

    The first set seemed to suggest two teams who were equally matched. Michael’s fought point for point against Leo’s team, whose defense was almost impenetrable, yet Edel Nolan managed to hit home some impressive spikes. However, as the set drew close, they found themselves unable to finish the job, and St Leo’s stormed into the second set with a 25-22 win in the first set under their belt.

   This is where it all went wrong for Claremorris. Having lost the first set, their nerves took over, and their difficulty settling into the match was evident in a plethora of unforced errors, despite excellent positioning by Nikki Hanley and impact substitutions by Lisa McGreal and Jackie Prendergast. They lost the second set 25-19, and hope began to fade for their 200+ supporters.

   The third set began similarly but sensing that they now had nothing to lose – except of course the All-Ireland Title – the team lifted their game tremendously, aided by the now deafening cries of their desperate supporters, led by Lisa Brett and Chloe Hughes. Strategic use of time-outs by coach Fionnghuala King saw the girls finally settle into the match. She undoubtedly reminded them of their team mantra – no matter how badly things seem to be going, ‘don’t lose your marbles. Stephanie Mellet had a great run of serves and made a stunning save at this crucial point in the set. Aisling Croghan made unbelievable hits from the wings, and Edel Nolan shone as the driving force behind Mount St Michael’s incredible comeback. They won the third set 25-16, and St Leo’s game fell apart.

    Fear of losing now defined their play, and they frequently only used two of their three hits, eager to get the ball across the net. Meanwhile, Claremorris grew confident, scoring a resounding victory in the fourth set 25-13.

   As it finally dawned that Claremorris could win this match, the excitement and tension in the arena reached fever pitch, and the daddies on the sideline (Gerry Croghan & Con Nolan) riled up the crowd, ably assisted by vice-principal Margaret Burke. However, St Leo’s finally realized that it was still all to play for, and once again, their defense, led by Sinead Ruth, became near-impossible to break down. Edel Nolan made three excellent spikes in a row to find each, and everyone returned. Long rallies defined the 5th and final set (first to 15 points, but the team must win by 2 points), and every time Claremorris inched ahead, St Leo’s reeled them in again. Finally, however, they reached 14 – 13 and faced their first match point. Sinead Croghan, whose strength was such a defining feature of her play up to this point, unfortunately, hit the serve long, and it was back to stalemate. Two more match points followed, but Mount St Michael couldn’t seem to finish Leo’s off. At last, with two sets all and 17-16 on the scoreboard, Nikki Hanley served, raced forward to set the ball, and Edel Nolan spiked the girls to the sweetest victory of their lives. No wonder, then, she was named the Most Valuable Player of the match.

___________________________________________________________________________

The notes below apply to computer science and electrical engineering technical papers, emphasizing documents in systems and networks.

Read Strunk and White, Elements of Style. Again.

Give the paper to somebody else to read. If you can, find two people: one person familiar with the technical matter, another only generally familiar with the area.

Papers can be divided into two categories: original research papers and survey papers. Some papers combine the two elements. However, most publication venues either accept one or the other type or require the author to identify whether the paper should be evaluated as a research contribution or a survey paper. (Most research papers contain a "related work" section that can be considered a survey, but it is usually brief compared to the rest of the paper and only addresses a much narrower slice of the field.)

Research Papers

A good research paper has a clear statement of the problem the article is addressing, the proposed solution(s), and the results achieved. It describes clearly what has been done before on the issue and what is new.

The goal of a paper is to describe novel technical results. There are four types of technical results:

1. 1. An algorithm;
2. 2. A system construct: such as hardware design, software system, protocol, etc.;

One goal of the paper is to ensure that the next person who designs a system like yours doesn't make the same mistakes and takes advantage of some of your best solutions. Ensure that complex problems (and their solutions) are discussed, and the non-obvious errors (and how to avoid them) are discussed. (Craig Partridge)

1. A performance evaluation: obtained through analyses, simulation, or measurements;
2. A theory: consisting of a collection of theorems.

A paper should focus on

• describing the results insufficient details to establish their validity;
• identifying the novel aspects of the results, i.e., what new knowledge is reported and what makes it non-obvious;
• recognizing the significance of the results: what improvements and impact they suggest.

Paper Structure

A typical outline of a paper is:

• Abstract, typically not more than 100-150 words;
• Introduction (brief!): introduce the problem outline solution; the problem statement should clearly explain why the problem is significant (or interesting).
• Related Work (or before summary). Hint: In the case of a conference, make sure to cite the Work of the PC co-chairs and as many other PC members as are remotely plausible, as well as from anything relevant from the previous two proceedings. In the case of a journal or magazine, cite pertinent anything from the last 2-3 years or so volumes.
• Outline of the rest of the paper: "The remainder is organized as follows. In Section 2, we introduce... Finally, we describe future Work in Section 5." [Note that Section is capitalized. Also, vary your expression between "section" being the subject of the sentence, as in "Section 2 discusses ..." and "In Section, we discuss ...".]
• Body of paper
• problem
• approach, architecture
• results

The body should contain sufficient motivation, with at least one example scenario, preferably two, illustrating figures, followed by a crisp generic problem statement model, i.e., functionality, particularly emphasizing "new" functionality. The paper may or may not include formalisms. General evaluations of your algorithm or architecture, e.g., material proving that the algorithm is O(log N), go here, not in the evaluation section.

The architecture of the proposed system(s) to achieve this model should be more generic than your peculiar implementation. Always include at least one figure.

Realization: contains actual implementation details when implementing architecture isn't straightforward. Mention implementation language, platform, location, dependencies on other packages, and minimum resource usage briefly if pertinent.

Evaluation: How does it work in practice? Provide actual or simulated performance metrics end-user studies, mention external technology adopters, if any:

• Related Work, if not done at the beginning
• Summary and Future Work
• often repeats the main result
• Acknowledgments
• Bibliography
• Appendix (to be cut first if forced to):
• detailed protocol descriptions
• proofs with more than two lines
• other low-level but essential details

It is recommended that you write the approach and results in sections first, which go together. Then problem section, if it is separate from the introduction. Then the conclusions, then the intro. Write the intro last since it glosses the findings in one of the previous paragraphs. Finally, write the abstract. Last, give your paper a title.

Title

• Avoid all but the most readily understood abbreviations.
• Avoid common phrases like "novel," "performance evaluation," and "architecture" since almost every paper does a performance evaluation of some architecture, and it better be novel. Unless somebody wants to see 10,000 Google results, nobody searches for these types of words.

Use adjectives that describe the distinctive features of your Work, e.g., reliable, scalable, high-performance, robust, low-complexity, or low-cost. (There are exceptions, e.g., when the performance evaluation is the core of the paper. Even in that case, something more specific is preferable, as in "Delay measurements of X" or "The quality of service for FedEx deliveries.")

• If you need inspiration for a paper title, you can consult the Automatic Systems Research Topic or Paper Title Generator.