Xploit

Zostań autorem magazynu Xploit !

Jeśli jesteś zainteresowany(-a) napisaniem dla nas artykułu z dziedziny bezpieczeństwa IT, gorąco zachęcamy do kontaktu. Odpowiemy na wszelkie pytania i wątpliwości.

redakcja@xploit.pl

Zasady, na których opiera się nasza współpraca z autorami artykułów są bardzo proste:

- Przelewu na Państwa konto dokonujemy 7 dni po ukazaniu się czasopisma na rynku (połowa miesiąca),

- Przewidywaną ilość stron tekstu ustalamy przed rozpoczęciem formalnej współpracy,

- Autor jest informowany o numerze pisma, w którym ukaże się jego artykuł.

Artykuły powinny być przesyłane w formacie plików ASCII. Sposób kodowania polskich znaków nie ma dla nas znaczenia - poradzimy sobie z każdym z nich.

Dla przyspieszenia procesu przygotowania tekstów do druku, Redakcja stosuje zestaw prostych znaczników (tagów) formatujących. Dzięki temu praca działu DTP przebiega sprawniej, a skład poszczególnych części tekstu nie budzi wątpliwości i jest zgodny z intencjami autora. Oto wykaz stosowanych znaczników.

Elementy logiczne artykułu takie jak tytuły, śródtytuły i właściwy tekst są rozdzielane przy pomocy specjalnych znaczników (tagów). Znaczniki są zawsze zapisywane w następującym formacie @XX:. Nasze teksty zawsze składają się z następujących elementów logicznych:

• Krótki opis tematu artykułu (nadtytuł) (@D:)
• Tytuł właściwy (@T:)
• Wprowadzenie, tzw. lead czyli tekst pod tytułem (@V:)
• Właściwy tekst (@L:)
• Śródtytuły (@ZT:)
• Ramka z informacjami o autorze wraz z krótkim c.v. (@IT:)

Znaczniki mają charakter otwarty (inaczej niż w HTML-u, gdzie są zawsze zamykane), tzn. formatowanie włączone znacznikiem jest stosowane do momentu nie napotkania innego znacznika. Zatem znacznik wstawiamy tylko wtedy, gdy zmienia się format tekstu. Wyjątkiem są paragrafy, ich początek oznacza się znacznikiem @L:. Jeśli chcesz zaznaczyć początek kolejnego paragrafu, użyj ponownie znacznika @L: na początku wiersza.

Artykuły nigdy nie składają się tylko z tekstu. Obrazki, rysunki oraz inne elementy (ramki czy diagramy) pozytywnie wpływają na wygląd artykułu. Któż zresztą byłby zainteresowany czytaniem artykułów bez ciekawych zrzutek, rysunków czy listingów. Pamiętaj, że obrazki, tabele i ramki są elementami ruchomymi i nie możesz po prostu odwoływać się do nich w tekście słowami. Zamiast tego odwołuj się do rysunków po numerze, np. Rysunek X.

Ludzie łatwiej przyswajają informację wizualną niż werbalną. Rysunki i obrazki powinny ułatwić Czytelnikom zrozuminie trudnej tematyki technicznej. Pisząc artykuł powinieneś o tym pamiętać.

Pytanie o to, jaki format plików należy stosować do przygotowania rysunków i schematów jest trudne. Dobrym wyborem jest program Xfig, przynajmniej jeśli chodzi o diagramy, wykresy, szkice. Format plików Xfig jest łatwy do przetwarzania (nasi redaktorzy pracują oczywiście w Linuksie) i łatwo jest go przekonwertować do wysokiej jakości Postscript-u. Jeśli chcesz użyć innego formatu, zawsze dołączaj zarówno plik w formacie źródłowym, jak i pliki wynikowe PS, EPS lub PDF. Nasz dział DTP często zamienia czcionki i kolory używane w rysunkach i schematach po to żeby zachować spójność z ogólnym projektem Linux Magazine. W przypadku zdjęć, najlepiej wykorzystywać formaty JPEG i TIFF. W razie wątpliwości, po prostu zapytaj Redakcję.

Najlepszymi formatami plików dla zrzutek są PNG i GIF, zdecydowanie nie polecamy JPEG. Kiedy przygotowujesz zrzutkę upewnij się, że zawiera ona jedynie potrzebny obszar ekranu, unikaj pokazywania pustych miejsc. Kolorystyka powinna być stonowana i estetyczna, unikaj pstrokatych barw, to nigdy nie wygląda dobrze w druku. Pamiętaj także, żeby czcionki zwłaszcza te pokazywane w menu, nie używały krojów dekoracyjnych, najlepiej wybierać standardowe czcionki. Rozmiar zrzutek nie pownienien przekraczać generalnie rozmiaru 800x600 pikseli.

Rysunki są wskazywane w następujący sposób:

@Bi:fig1.png
@B:Rysunek 1: Jasio po raz pierwszy uruchamia kompilację jądra.
Zwróćcie uwagę na to jaki jest podekscytowany wykonując polecenie make.

Opis do rysunku czy zdjęcia powinien dokładnie wskazywać, co ważnego można tam zobaczyć. Oto przykład podpisu do zdjęcia:

@L:Rysunek 1 pokazuje Jasia w czasie kompilacji jądra.

lub:

@L:.....Jasio w czasie kompilacji jądra (Rysunek 1)

Właściwy tekst wskazujemy znacznikiem @L:. Znacznik ten powinien być stosowany dla wyróżnienia całego paragrafu. Dwie gwiazdki oznaczają spację, która nie może być podzielona między wiersze (np. Red**Hat). Ma to podobne działanie do znaczników   w HTML.

Wyróżnienia tekstu takie jak pogrubienie, tekst pochyły itp. są wskazywane znacznikami w trójkątnych nawiasach, prosimy pamiętać, że w przeciwieństwie do HTML-a nie są one zamykane znakiem /. Krótkie polecenia, takie jak np. rm -rf * lub nazwa pliku czy katalogu, powinny być umieszczane w samym tekście w następujący sposób <C>rm -f *<C>. Dzięki czemu w tekście będą one widoczne w następujący sposób: rm -rf *. Inne dopuszczalne wyróżnienia to <I>tekst pochyły<I> i w rzadkich przypadkach <B>pogrubienie<B>. W treści tekstu możesz również wyróżniać adresy URL używając znacznika <U>, np.:

<U>http://www.world.wide.wait.net/index.html<U>

Listing zawierający jedynie jedną czy dwie linie kodu oznaczamy znacznikiem @LI: w każdej z linii listingu. Listingi są drukowane czcionką Courier o gęstości około 40 znaków w każdym wierszu. Jeśli linia kodu jest dłuższa, podziel kod używają znacznika przełamania linii §§, aby wskazać, że jest to jedna liniia logiczna. Przykładowo:

@LI:
./configure --with-idea --prefix=/usr --with-rsa

to zbyt długie, lepiej zrobić tak:

@LI:
./configure --with-idea --prefix=/usr §§
  --with-rsa

Dłuższe listingi należy zamieszczać w ramkach oznaczonych jako "Listing". Listingi mogą być dostarczone osobno - poza samym artykułem. Prosimy o dostarczanie kompletnych listingów i kodu źrdółowego, ponieważ będą one dostępne dla Czytelników na naszym serwerze FTP.

Zbyt wiele linii kodu w tekście artykułu czyni go trudnym do czytania. Powinieneś zamiast tego umieścić kod w osobnych ramkach. Oczywiście nie zawsze jest to możliwe, ale doradzamy ten sposób, jako najbardziej czytelny.

Ramki zawsze mają swój własny tytuł wskazywany znacznikiem(@KT:). Normalny tekst w ramce oznaczamy znacznikiem (@KL:), natomiast listingi w ramkach poprzedzamy znacznikiem @LI::

@KT:Listing 1: xy.c
@LI:
#include <stdio.h>

...

Oprócz kodu, ramki mogą zawierać dodatkowe informacje, takie jak np. słowniczek, wywiad albo po prostu kilka zdań rozwijających jakiś pomysł czy opisujących krótko jakąś technologię.

Tabele są podobne do zwykłych ramek, ale zaczynamy je od znacznika @TT:. Poszczególne wiersze tabeli muszą zajmować po jednym wierszu tektu źródłowego; kolumny rodzielamy po prostu pojedyńczym tabulatorem:

@TT:Tabela 1. Porównanie technologii A i B.
@TL:Kolumna1     Kolumna2

Zaoszczędzisz wiele czasu naszemu działowi DTP, jeśli dostarczysz tabele w postaci arkusza kalkulacyjego (Open Office, Star Office, Excel, Applix ...), w ostateczności możesz użyć formatu (.csv. Po prostu w przypadku bardziej skomplikowanych tabel można łatwo pomylić kolumny czy wiersze.

Sekcja Info zawiera odesłania do literatury i adresy URL do interesujących stron WWW. Sekcja "Info" jest po prostu ramką oznaczaną poprzez znacznik @IT:Info. Poszczególne adresy i opisy umieszczamy oddzielając je znacznikiem @IL::

@IT:Info
@IL:
[1] Podręcznik hodowcy pingwinów:
<U>http://www.penguin.org/handbook<U>

[2] Carl Corner: The Kernel -- Compiling Made Easy,
Linux Magazine numer 22, str. 45

Używaj nawiasów kwadratowych [1] w tekście, jeśli chcesz odwołać się do przypisu w sekcji Info.

Ramka "Autor" jest podobna do ramki "Info" i zapisuje się ją następująco:

@IT:Autor
@IL:Jan Nikt zajmuje się administracją...

• używanie zbyt dużej ilości akronimów (np. PLN, SVG)
• nadużywanie formy biernej (np. powinno się to w następujący sposób)
• zbyt częsta zmiana perspektywy, z której prowadzona jest narracja (np. zalecane jest, powinieneś, zalecam, powinniście)
• zbyt mało rysunków i zrzutek, mało opisowe podpisy do rysunków, zrzutek i zdjęć
• brak śródtytułów dzielących tekst pod względem logicznym
• używanie formatów plików innych niż ASCII (np. HTML, Latex, Open Office lub Word)