Pisząc tekst i tworząc aplikacje stosować nazwy ogólne dla np. nazw użytkowników (user1), serwerów (serwer1) itp.
Omawiać przykłady od początku do końca, wskazując co i gdzie jest oraz co jest wynikiem wykonywanych operacji; Dokumentować zmiany na zrzutach i listingach
Sprawdzić zasady wydawnictwa Helion na stronie helion.pl i stosować się do nich:
ftp.helion.pl/autorzy/Zasady%20wpisywania%20tekst%F3w%20czyli%20kilka%20NIE.htm
ftp.helion.pl/autorzy/Podstawowe%20zasady%20interpunkcyjne2.doc
Zamiast pisać "stworzony" pisać "utworzony", a zamiast "opierać się o" pisać "bazować na"
Nie zostawiać wolnych/pustych linii bez potrzeby
Przypis zawsze na dole strony na której jest odwołanie do niego
Tłumaczenie np. skrótu powinno być wykonane w tekście RAZ
Rysunki powinny być narysowane przez autora (np. GIMP) - na końcu przesłać w plikach razem z pracą; Jeżeli tak nie jest to koniecznie trzeba podać źródło takiego rysunku, tabeli itp.
Kolejne wersje są przeze mnie czytane i wstawiane są komentarze lub poprawki; Pojawiają się ??? - trzy pytajniki lub puste komentarze; Pytajniki oznaczają, że czegoś nie wiem lub nie rozumiem.; Puste komentarze oznaczają, że należy ten fragment przeczytać, sformatować, poprawić, zweryfikować styl; Jeżeli autor poprawia jakiś fragment zgodnie z uwagą w komentarzu kasuje go chyba, że zostało zaznaczone inaczej w samym komentarzu lub na spotkaniu/konsultacjach; Można i należy pisać swoje komentarze do uwag
Przeczytać przed wysłaniem - NIE BĘDĘ CZYTAŁ JEŻELI BĘDZIE DUŻO LITERÓWEK, BŁĘDY ORTOGRAFICZNE LUB MERYTORYCZNE!
Po znalezieniu błędów merytorycznych odsyłam do korekty.
Starać się nie wprowadzać zdań złożonych. Pisać krótkie i "jasne" zdania.
Aplikacje (szczególnie internetowe) powinny być umieszczone/zainstalowane na serwerze zewnętrznym w celu łatwego dostępu; Tworzona alikacja powinna działać w podanym zakresie i dopiero wtedy można wysłać ją do testowania/akceptacji; Po zanalezieniu 3 błędów w działaniu aplikacja jest odsyłana do poprawki!
Stosować skróty wyjaśniając najpierw ich znaczenie np. PHP (PHP Hypertext Preprocessor) czy HTTP (Hypertext Transfer Protocol)
Stosujemy numerację listingów do zwartych bloków kodu, które ew. później są omawiane linijka po linijce. Ma to swoje uzasadnienie w czytelności takiego kodu; Listing tak jak rysunek musi mieć odwołanie wtekście pracy
Wskazujemy konkretne odwołania do rysunków, tabel lub listingów; Nie piszemy, że coś jest powyżej lub poniżej
Odwołania w tekście powinny dotyczyć informacji które już były podane, a nie tych które dopiero będą podane w dalszej części pracy
Wprowadzić automatyzację w odwołaniach do: rysunków, tabel, listingów, wzorów, bibliografii, podrozdziałów itp.
Listingi są tekstowe, z ponumerowanymi liniami a w omówieniu listingu wskazujemy elementy oraz numery linii; Najważniejsze/omawiane elementy pogrubiamy; Listingi moga być rysunkami, ale z ponumerowanymi liniami
W części teoretycznej muszą znajdować się odwołania do literatury/bibliografii
Stosować omówienia/wypunktowania/krótkie charakterystyki, a opisać używne elementy – tak aby można było na podstawie tekstu ustalić dlaczego wybrano akurat ten a nie inny wariant/element
Nie wstawiać niepotrzebnych słów i zdań "wypełniaczy"
Należy wskazywać konktetne omawiane elementy - bez uogólnień
Stosować poprawnie akapity i wcięcia tabulacją - akapit to nowy temat
POPRAWKI W PLIKACH (za każdym razem gdy odsyłam plik po swoich poprawkach to proszę): przeglądnąć całość, zaakceptować poprawki lub odrzucić, ustosunkować się do uwag, wprowadzić swoje uwagi, nadal pracować w trybie edycji, chyba, że w tekście podno inne wytyczne
