DicasEscritaLeopoldo < Protected

Protected > ComoEscreverUmArtigo > DicasEscritaLeopoldo

TWiki webs: Main | TWiki | Sandbox Hello TWiki Admin Group!

Escrever com Top Down em mente (intuição e problemas mais gerais sendo afunilados e detalhados depois)
- Iterativo e incremental
Evitar futuro e Voz Passiva sempre que possível
Uniformizar termos e conceitos. Evitar o uso de diversos nomes para o mesmo conceito (Core, Base)
Remover detalhes irrelevantes que não agregam
- terminações de arquivos: .aj e .java.
- imports de uma classe java
- uso de /, como no exemplo "design/implementation issues"
Deixar claro os problemas e sua intuição, para não dar outra impressão ao leitor (problema inventado ou causado por detalhes de implementação)
Fazer link entre seções e parágrafos do texto, pra não ficarem pedaços de texto desconexos
Deixar generalizações e extrapolações da ideia básica para depois, quando a ideia básica já está consolidada.
- ex.: "este CK funciona não apenas com código, mas também com requisitos" - o cara nem entendeu o que é CK direito ainda
Evitar frases "aportuguesadas"
- problem of safe composition --> safe composition problem
- codification to propositional logic --> propositional logic codification
- duplication of the code --> code duplication

O título do trabalho deve conter uma explanação geral do mesmo.
- "Reporting problems when dealing with different binding times in product lines"; o título deste trabalho não estava casando com o conteúdo, dado que não somente o problema estava sendo mostrado, mas também uma possível solução.
- Assim, pode-se remover o "Reporting problems" do título.
Deixar o escopo muito claro no início do trabalho para não criar falsas expectativas no leitor.
- "... variabilities found in Motorola test cases ..."
  - Vago demais; as variabilidades estão no código? Em requisitos? E esses test cases? Que tipo de teste foi explorado no trabalho? Todos?
- "... variabilities implemented by using if-else statements found in Motorola integration test cases ..."
  - Agora o leitor tem noção do escopo; se o texto acima ainda permanecer vago, um exemplo é bem-vindo.
- Naturalmente, esse escopo deve permanecer o mesmo durante todo o trabalho. No final (seção de discussão ou conclusão, por exemplo), o escopo pode ser aumentado para dar noções de onde o trabalho pode ser também aplicado.
  - "Although we discussed throughout this work that our approach targets if-else statements, we can also apply our model to variabilities implemented with conditional compilation due to ..."
Não entrar em muitos detalhes na introdução. Tentar passar a idéia do problema, da solução bem como dos resultados gerais sem entrar em detalhes que possam causar dúvidas ao leitor.
- "... we observed problems when using the Edicts idiom such as code duplication and scattering: the aspects for binding time flexibility (dynamic and static) cause duplication of advice bodies, except for the if statement of the dynamic binding time ..."
Sempre que possível utilizar exemplos reais para o problema e solução. Evitar exemplos com "x", "y" e afins.
Não usar a terminologia do trabalho relacionado!
- Durante todo o trabalho, falou-se em variabilities e técnicas de implementação...
- ... mas o trabalho relacionado fala em domain engineering e application engineering
- Não escrever o related work usando domain e application, mas sim continuar com a mesma terminologia usada durante o trabalho: variabilities e técnicas de implementação.
Não usar figuras somente como decoração. Referenciá-las no texto e utilizá-las como base para a explicação.
Utilizar a abordagem contexto-problema-solução-avaliação para escrever o abstract do artigo (Ver dicas do Kent Beck em ComoEscreverUmArtigo).
Não utilizar conceitos ou siglas que ainda não foram explicados anteriormente no texto.
De preferência, escrever um Motivating Example, em que o problema a ser resolvido é mostrado de forma clara e direta
Chegar ao problema de forma rápida na introdução, não deixar o leitor muito tempo na expectativa
Utilizar footnotes para observações como o site do estudo de caso
Sumarizar em tabelas ou gráficos informações que são melhores entendidas de forma separada e comparativa. Ex: explicação das métricas utilizadas na avaliação
Disponibilizar em algum site informações necessárias para que outra pessoa alcance os mesmos resultados obtidos no trabalho. Ex: disponibilizar código dos estudos de caso, métodos para avaliação, fórmulas para cálculos de métricas...
Quando devo usar vírgula após "therefore"? Chicago Manual of Style 5.69: "When [transitional adverbs] are used in such a way that there is no real break in continuity and no call for any pause in reading, commas should be omitted." Chicago gives four examples: (1) The storehouse was indeed empty; (2) I therefore urge you all to remain loyal; (3) Wilcox was perhaps a bit too hasty in his judgment; (4) Palmerson was in fact the chairman of the committee. If you've written yourself into this kind of quagmire, the best editorial solution is to delete the introductory material. If you're brave enough to do that, you won't have any trouble deleting the comma.

-- LeopoldoTeixeira - 16 Dec 2011 -- LaisNeves - 16 Nov 2010 -- LaisNeves - 09 Nov 2010 -- MarcioRibeiro - 05 Oct 2010 -- LeopoldoTeixeira - 21 Sep 2010

Parents: ComoEscreverUmArtigo