Opis ebooka: UNIX. Sztuka programowania
UNIX to nie tylko system operacyjny, to także społeczność i kultura
- Obszerne omówienie niezliczonych problemów związanych z programowaniem w systemie Unix
- Niekonwencjonalne przedstawienie kulturotwórczych aspektów programowania
- Wszechstronny opis sprawdzonych reguł i wzorców projektowych
- Wnioski wypływające z historii Uniksa i jego porównanie z innymi systemami operacyjnymi
- Liczne "studia przypadków" (case studies) przedstawiające komponenty systemu Unix w kontekście programistycznym
- Omówienie problematyki przenośności i wieloplatformowości oprogramowania
Unix to nie tylko system operacyjny; to także kultura i tradycja. Grzechem wielu programistów są programy spełniające wprawdzie swe funkcje, lecz zaprojektowane w pośpiechu, niedbale, a przez to trudne w utrzymaniu i rozwoju, oporne przy przenoszeniu na inną platformę i (z biegiem czasu) nieczytelne nawet dla swych autorów. Na temat dobrego programowania napisano już bardzo wiele; z tej książki dowiesz się nie tylko tego, jakie rozwiązania programistyczne warto poznać i naśladować, lecz także -- dlaczego warto to robić.
Ta książka zawiera sporą dawkę wiedzy, lecz jej treść koncentruje się przede wszystkim na doświadczeniu programistycznym. Programowanie przestaje być tylko dyscypliną techniczną, a staje się zagadnieniem o charakterze kulturotwórczym. Doceniając należycie ten fakt, autor nie ogranicza się do technicznego wykładu. Prezentuje poszczególne aspekty profesjonalnego projektowania i implementacji programów w kontekście filozofii i historii Uniksa z jednej strony, a społecznymi uwarunkowaniami kultury uniksowej z drugiej.
Warto przeczytać tę książkę także z tej przyczyny, że mało który podręcznik dla programistów dostarcza tyle historii, folkloru i dygresji -- elementów co prawda niekoniecznych z punktu widzenia meritum (choć i nad tą kwestią można by długo dyskutować), lecz znakomicie uprzyjemniających lekturę i być może ułatwiających zrozumienie tego, co w "suchym", technicznym tekście może nieraz wydawać się zagadkowe.
Jeżeli więc jesteś programistą (niekoniecznie w systemie Unix) albo tylko interesują Cię zagadnienia związane z programowaniem, niniejsza książka z pewnością będzie stanowić interesującą lekturę, a być może również skłoni Cię do spojrzenia w inny sposób na swą codzienną pracę.
- Koncepcja oprogramowania open source
- Zagadnienia przenośności i wieloplatformowości programów
- Podstawy filozofii uniksowej
- Geneza oraz historia Uniksa, Linuksa i oprogramowania open source
- Zalety modularności i przezroczystości projektu
- Metody optymalizacji programów
- Narzędzia programistyczne: edytory, makrogeneratory, debuggery, systemy kontroli wersji, programy dokumentujące itp.
- Zagadnienia związane z licencjonowaniem programów
- Podstawowe cechy Uniksa w kontekście innych popularnych systemów operacyjnych
- Możliwości Uniksa i stojące przed nim zagrożenia
O autorze:
Eric S. Raymond zajmuje się programowaniem w systemie Unix od 1982 roku, jest rzecznikiem oprogramowania open source i ambasadorem "społeczności open source".
[więcej...]
Wybrane bestsellery
-
Open source provides the competitive advantage in the Internet Age. According to the August Forrester Report, 56 percent of IT managers interviewed at Global 2,500 companies are already using some type of open source software in their infrastructure and another 6 percent will install it in th...
The Cathedral & the Bazaar. Musings on Linux and Open Source by an Accidental Revolutionary The Cathedral & the Bazaar. Musings on Linux and Open Source by an Accidental Revolutionary
(80.73 zł najniższa cena z 30 dni)80.73 zł
94.99 zł(-15%) -
Ta książka pomoże Ci się przygotować do pracy na stanowisku testera oprogramowania, a także zapewni wsparcie podczas wykonywania nowych zadań. Znajdziesz tu dokładne omówienie podstaw testowania, jego różnych rodzajów i poziomów w odniesieniu do zastosowania na różnych etapach pracy nad projektem...
Tester samouk. Praktyczny przewodnik po testowaniu oprogramowania na bazie gotowego projektu Tester samouk. Praktyczny przewodnik po testowaniu oprogramowania na bazie gotowego projektu
(47.20 zł najniższa cena z 30 dni)35.40 zł
59.00 zł(-40%) -
Czym jest inżynieria wymagań? To systematyczne podejście do pozyskiwania i dokumentowania wymagań, a także zarządzania nimi. Polega na zrozumieniu potrzeb i oczekiwań interesariuszy, a następnie opisaniu, za pomocą wymagań, systemu, który je spełnia.
Certyfikowany inżynier wymagań. Na podstawie IREB CPRE. Poziom podstawowy Certyfikowany inżynier wymagań. Na podstawie IREB CPRE. Poziom podstawowy
(55.20 zł najniższa cena z 30 dni)41.40 zł
69.00 zł(-40%) -
Firmy z branży IT prześcigają się w tworzeniu rozwiązań zwiększających wydajność pracy, jak również podnoszących poziom specjalizacji pracowników w określonych dziedzinach. Od kilku już lat pozycja full stack developera, który wykonywał wszystkie prace programistyczne, jest wielką rzadkością. Obe...
Postman i SQL. Kurs video. Metody testowania REST API i przeszukiwania baz danych Postman i SQL. Kurs video. Metody testowania REST API i przeszukiwania baz danych
(63.60 zł najniższa cena z 30 dni)39.90 zł
159.00 zł(-75%) -
To drugie, zaktualizowane wydanie przewodnika po systemie Prometheus. Znajdziesz w nim wyczerpujące wprowadzenie do tego oprogramowania, a także wskazówki dotyczące monitorowania aplikacji i infrastruktury, tworzenia wykresów, przekazywania ostrzeżeń, bezpośredniej instrumentacji kodu i pobierani...
Prometheus w pełnej gotowości. Jak monitorować pracę infrastruktury i wydajność działania aplikacji. Wydanie II Prometheus w pełnej gotowości. Jak monitorować pracę infrastruktury i wydajność działania aplikacji. Wydanie II
(57.85 zł najniższa cena z 30 dni)53.40 zł
89.00 zł(-40%) -
Power Apps to platforma stworzona przez Microsoft, umożliwiająca łatwe projektowanie, tworzenie i dostosowywanie aplikacji bez konieczności posiadania głębokiej wiedzy programistycznej. Z użyciem Power Apps można budować niestandardowe aplikacje, które efektywnie wspierają i automatyzują różne pr...
Power Apps. Kurs video. Tworzenie biznesowych aplikacji no-code Power Apps. Kurs video. Tworzenie biznesowych aplikacji no-code
(69.65 zł najniższa cena z 30 dni)39.90 zł
199.00 zł(-80%) -
Ta książka będzie świetnym uzupełnieniem wiedzy o Flutterze i Darcie, sprawdzi się również jako wsparcie podczas rozwiązywania konkretnych problemów. Znalazło się tu ponad sto receptur, dzięki którym poznasz tajniki pisania efektywnego kodu, korzystania z narzędzi udostępnianych przez framework F...
Flutter i Dart. Receptury. Tworzenie chmurowych aplikacji full stack Flutter i Dart. Receptury. Tworzenie chmurowych aplikacji full stack
(44.85 zł najniższa cena z 30 dni)41.40 zł
69.00 zł(-40%) -
Sterownik PLC (ang. programmable logic controller) to jedno z najważniejszych urządzeń stosowanych w automatyce przemysłowej. Zawiera układ mikroprocesorowy pozwalający sterować pracą maszyn, linii produkcyjnych, oświetlenia i innych urządzeń elektrycznych w przemyśle, ale nie tylko. Tego typu st...
Języki programowania sterowników PLC: LAD, FBD, SCL, STL. Ćwiczenia dla początkujących Języki programowania sterowników PLC: LAD, FBD, SCL, STL. Ćwiczenia dla początkujących
(29.18 zł najniższa cena z 30 dni)26.94 zł
44.90 zł(-40%) -
Czy chcesz szybko i skutecznie opanować podstawy Microsoft Azure, zrozumieć jego architekturę i możliwości? W takim razie to książka dla Ciebie! Czy chcesz nauczyć się, jak wdrażać, zarządzać i skalować aplikacje w chmurze Azure, nie tracąc przy tym cennego czasu? W takim razie to książka dla C...
Azure w 1 dzień. Microsoft Azure od podstaw po zaawansowane techniki Azure w 1 dzień. Microsoft Azure od podstaw po zaawansowane techniki
-
Zigi to postać fikcyjna - warta poznania! Autor książki, sam będący od wielu lat testerem, wyposażył swojego bohatera we własne doświadczenia. Dołożył do nich trochę „case’ów”, które widział, o których słyszał lub czytał, ubrał je w przystępne słowa i sfabularyzował dla podkręce...(38.35 zł najniższa cena z 30 dni)
35.40 zł
59.00 zł(-40%)
Ebooka "UNIX. Sztuka programowania" przeczytasz na:
-
czytnikach Inkbook, Kindle, Pocketbook, Onyx Boox i innych
-
systemach Windows, MacOS i innych
-
systemach Windows, Android, iOS, HarmonyOS
-
na dowolnych urządzeniach i aplikacjach obsługujących formaty: PDF, EPub, Mobi
Masz pytania? Zajrzyj do zakładki Pomoc »
Audiobooka "UNIX. Sztuka programowania" posłuchasz:
-
w aplikacji Ebookpoint na Android, iOS, HarmonyOs
-
na systemach Windows, MacOS i innych
-
na dowolnych urządzeniach i aplikacjach obsługujących format MP3 (pliki spakowane w ZIP)
Masz pytania? Zajrzyj do zakładki Pomoc »
Kurs Video "UNIX. Sztuka programowania" zobaczysz:
-
w aplikacjach Ebookpoint i Videopoint na Android, iOS, HarmonyOs
-
na systemach Windows, MacOS i innych z dostępem do najnowszej wersji Twojej przeglądarki internetowej
Recenzje ebooka: UNIX. Sztuka programowania (1) Poniższe recenzje mogły powstać po przekazaniu recenzentowi darmowego egzemplarza poszczególnych utworów bądź innej zachęty do jej napisania np. zapłaty.
-
Recenzja: Dziennik Łódzki N; 19 maja 2004Recenzja dotyczy produktu: ksiązka drukowanaCzy recenzja była pomocna:
Nie unikaj Uniksa
Widniejący na okładce dwaj skośnoocy – mędrzec i jego uczeń, mogą sugerować, że będziemy mieli do czynienia z jakąś komputerową chińszczyzną. Tymczasem książka „Unix. Sztuka programowania” to klarowny, choć nie pozbawiony bardzo licznych dygresji, wykład na zawarty w tytule temat. Liczne dygresje wynikają z faktu, iż według Erica S. Raymonda techniczny wykład nie spełniłby swojej roli, ,gdyby nie był wsparty wiedzą na temat filozofii i historii Uniksa
Dobrze jest studiować ów wydany przez Helion przewodnik przy konsoli systemu uniksowego z uruchomioną przeglądarką WWW, ponieważ autor, dla uzupełnienia poruszającego wątku, często zaprasza do przeglądania sieci i eksperymentowania na bieżąco.
Szczegóły ebooka
- Tytuł oryginału:
- The Art of UNIX Programming
- Tłumaczenie:
- Grzegorz Werner (wstęp, rozdz. 1 - 10), Wojciech Moch (rozdz. 11 - 20, dod. A - D)
- ISBN Książki drukowanej:
- 83-736-1419-2, 8373614192
- Data wydania książki drukowanej:
- 2004-04-13
- Format:
- B5
- Numer z katalogu:
- 2368
- druk na żądanie!
- dnż
- Pobierz przykładowy rozdział PDF
Spis treści ebooka
- 1.1. Kultura? Jaka kultura? (21)
- 1.2. Trwałość Uniksa (22)
- 1.3. Argumenty przeciwko nauce kultury uniksowej (23)
- 1.4. Co w Uniksie jest złe? (24)
- 1.5. Co w Uniksie jest dobre? (25)
- 1.5.1. Oprogramowanie o otwartych źródłach (25)
- 1.5.2. Międzyplatformowa przenośność i otwarte standardy (25)
- 1.5.3. Internet i World Wide Web (26)
- 1.5.4. Społeczność Open Source (26)
- 1.5.5. Prawdziwa elastyczność (27)
- 1.5.6. Programowanie Uniksa jest przyjemne (27)
- 1.5.7. Doświadczenie zdobyte w Uniksie można zastosować gdzie indziej (28)
- 1.6. Podstawy filozofii uniksowej (29)
- 1.6.1. Reguła modularności: pisz proste części połączone przejrzystymi interfejsami (31)
- 1.6.2. Reguła przejrzystości: przejrzystość jest lepsza niż spryt (32)
- 1.6.3. Reguła kompozycji: projektuj programy tak, aby dało się je łączyć z innymi (32)
- 1.6.4. Reguła oddzielania: oddzielaj politykę od mechanizmu; oddzielaj interfejsy od głównej części programu (33)
- 1.6.5. Reguła prostoty: projektuj pod kątem prostoty; uciekaj się do złożoności tylko tam, gdzie to konieczne (34)
- 1.6.6. Reguła powściągliwości: pisz duży program tylko wtedy, gdy zostanie jasno udowodnione, że nie da się inaczej (35)
- 1.6.7. Reguła przezroczystości: dbaj o zrozumiałość kodu, aby ułatwić badanie i debugowanie programów (35)
- 1.6.8. Reguła odporności: odporność jest pochodną przezroczystości i prostoty (36)
- 1.6.9. Reguła reprezentacji: przełóż wiedzę na dane, aby logika programu mogła być prosta i odporna (37)
- 1.6.10. Reguła najmniejszego zaskoczenia: projektując interfejs, zawsze postępuj w najmniej zaskakujący sposób (37)
- 1.6.11. Reguła milczenia: kiedy program nie ma nic nieoczekiwanego do powiedzenia, nie powinien mówić nic (38)
- 1.6.12. Reguła naprawy: naprawiaj, co się da, ale jeśli program musi zawieść, niech zawiedzie z hukiem i jak najszybciej (38)
- 1.6.13. Reguła ekonomii: czas programisty jest drogi; oszczędzaj go zamiast czasu komputera (39)
- 1.6.14. Reguła generacji: unikaj programowania ręcznego; jeśli to możliwe, pisz programy piszące programy (40)
- 1.6.15. Reguła optymalizacji: napisz prototyp, zanim zaczniesz dopracowywać program. Sprawdź, czy działa, zanim zaczniesz go optymalizować (40)
- 1.6.16. Reguła różnorodności: nie ufaj żadnym deklaracjom o "jedynym słusznym sposobie" (42)
- 1.6.17. Reguła rozszerzalności: projektuj programy z myślą o przyszłości, bo nadejdzie ona wcześniej, niż się spodziewasz (42)
- 1.7. Filozofia uniksowa w jednej lekcji (43)
- 1.8. Stosowanie filozofii uniksowej (43)
- 1.9. Liczy się też nastawienie (44)
- 2.1. Pochodzenie i historia Uniksa, lata 1969 - 1995 (45)
- 2.1.1. Geneza, lata 1969 - 1971 (46)
- 2.1.2. Exodus, lata 1971 - 1980 (48)
- 2.1.3. TCP/IP i Wojny Uniksowe, lata 1980 - 1990 (50)
- 2.1.4. Uderzenia w Imperium, lata 1991 - 1995 (56)
- 2.2. Pochodzenie i historia hakerów, lata 1961 - 1995 (58)
- 2.2.1. Zabawa w gajach Akademii, lata 1961 - 1980 (58)
- 2.2.2. Fuzja internetowa i ruch wolnego oprogramowania, lata 1981 - 1991 (60)
- 2.2.3. Linux i reakcja pragmatyków, lata 1991 - 1998 (62)
- 2.3. Ruch Open Source, od roku 1998 do chwili obecnej (64)
- 2.4. Lekcje płynące z historii Uniksa (66)
- 3.1. Elementy stylu systemu operacyjnego (67)
- 3.1.1. Jaka jest idea unifikująca system operacyjny? (68)
- 3.1.2. Wielozadaniowość (68)
- 3.1.3. Współpracujące procesy (69)
- 3.1.4. Granice wewnętrzne (70)
- 3.1.5. Atrybuty plików i struktury rekordów (71)
- 3.1.6. Binarne formaty plików (72)
- 3.1.7. Preferowany styl interfejsu użytkownika (72)
- 3.1.8. Zamierzone grono odbiorców (73)
- 3.1.9. Bariera oddzielająca użytkownika od programisty (73)
- 3.2. Porównanie systemów operacyjnych (74)
- 3.2.1. VMS (76)
- 3.2.2. MacOS (77)
- 3.2.3. OS/2 (78)
- 3.2.4. Windows NT (80)
- 3.2.5. BeOS (83)
- 3.2.6. MVS (85)
- 3.2.7. VM/CMS (87)
- 3.2.8. Linux (89)
- 3.3. Co odchodzi, to wraca (90)
- 4.1. Hermetyzacja i optymalny rozmiar modułu (97)
- 4.2. Zwartość i ortogonalność (98)
- 4.2.1. Zwartość (99)
- 4.2.2. Ortogonalność (100)
- 4.2.3. Reguła SPOT (102)
- 4.2.4. Zwartość i jedno silne centrum (103)
- 4.2.5. Zalety niezaangażowania (105)
- 4.3. Oprogramowanie ma wiele warstw (105)
- 4.3.1. Od góry w dół czy od dołu w górę? (106)
- 4.3.2. Warstwy spajające (108)
- 4.3.3. Studium przypadku: język C jako cienka warstwa kleju (108)
- 4.4. Biblioteki (110)
- 4.4.1. Studium przypadku: wtyczki programu GIMP (111)
- 4.5. Unix i języki obiektowe (112)
- 4.6. Kodowanie z myślą o modularności (114)
- 5.1. Dlaczego tekstowość jest ważna? (117)
- 5.1.1. Studium przypadku: format uniksowego pliku haseł (118)
- 5.1.2. Studium przypadku: format pliku .newsrc (120)
- 5.1.3. Studium przypadku: format pliku graficznego PNG (121)
- 5.2. Metaformaty plików danych (122)
- 5.2.1. Styl DSV (122)
- 5.2.2. Format RFC 822 (123)
- 5.2.3. Format "słoika ciasteczek" (124)
- 5.2.4. Format "słoika rekordów" (125)
- 5.2.5. XML (126)
- 5.2.6. Format plików INI systemu Windows (128)
- 5.2.7. Uniksowe konwencje dotyczące formatu plików tekstowych (129)
- 5.2.8. Zalety i wady kompresji plików (130)
- 5.3. Projektowanie protokołów aplikacyjnych (131)
- 5.3.1. Studium przypadku: SMTP, protokół transferu poczty (132)
- 5.3.2. Studium przypadku: POP3, protokół skrzynki pocztowej (133)
- 5.3.3. Studium przypadku: IMAP, internetowy protokół dostępu do poczty (134)
- 5.4. Metaformaty protokołów aplikacyjnych (135)
- 5.4.1. Klasyczny internetowy metaprotokół aplikacyjny (136)
- 5.4.2. HTTP jako uniwersalny protokół aplikacyjny (136)
- 5.4.3. BEEP: Blocks Extensible Exchange Protocol (138)
- 5.4.4. XML-RPC, SOAP i Jabber (139)
- 6.1. Studia przypadków (143)
- 6.1.1. Studium przypadku: audacity (143)
- 6.1.2. Studium przypadku: opcja -v programu fetchmail (144)
- 6.1.3. Studium przypadku: GCC (146)
- 6.1.4. Studium przypadku: kmail (147)
- 6.1.5. Studium przypadku: SNG (148)
- 6.1.6. Studium przypadku: baza danych terminfo (150)
- 6.1.7. Studium przypadku: pliki danych gry Freeciv (153)
- 6.2. Projektowanie pod kątem przezroczystości i odkrywalności (154)
- 6.2.1. Zen przezroczystości (155)
- 6.2.2. Kodowanie pod kątem przezroczystości i odkrywalności (156)
- 6.2.3. Przezroczystość i unikanie nadopiekuńczości (157)
- 6.2.4. Przezroczystość i edytowalne reprezentacje (158)
- 6.2.5. Przezroczystość, diagnozowanie błędów i usuwanie skutków błędu (159)
- 6.3. Projektowanie pod kątem konserwowalności (160)
- 7.1. Oddzielanie kontroli złożoności od dostrajania wydajności (165)
- 7.2. Taksonomia uniksowych metod IPC (166)
- 7.2.1. Przydzielanie zadań wyspecjalizowanym programom (166)
- 7.2.2. Potoki, przekierowania i filtry (167)
- 7.2.3. Nakładki (171)
- 7.2.4. Nakładki zabezpieczające i łączenie Bernsteina (172)
- 7.2.5. Procesy podrzędne (174)
- 7.2.6. Równorzędna komunikacja międzyprocesowa (174)
- 7.3. Problemy i metody, których należy unikać (181)
- 7.3.1. Przestarzałe uniksowe metody IPC (182)
- 7.3.2. Zdalne wywołania procedur (183)
- 7.3.3. Wątki - groźba czy niebezpieczeństwo? (185)
- 7.4. Dzielenie procesów na poziomie projektu (186)
- 8.1. Taksonomia języków (191)
- 8.2. Stosowanie minijęzyków (193)
- 8.2.1. Studium przypadku: sng (193)
- 8.2.2. Studium przypadku: wyrażenia regularne (193)
- 8.2.3. Studium przypadku: Glade (196)
- 8.2.4. Studium przypadku: m4 (198)
- 8.2.5. Studium przypadku: XSLT (198)
- 8.2.6. Studium przypadku: warsztat dokumentatora (199)
- 8.2.7. Studium przypadku: składnia pliku kontrolnego programu fetchmail (204)
- 8.2.8. Studium przypadku: awk (205)
- 8.2.9. Studium przypadku: PostScript (206)
- 8.2.10. Studium przypadku: bc i dc (207)
- 8.2.11. Studium przypadku: Emacs Lisp (209)
- 8.2.12. Studium przypadku: JavaScript (209)
- 8.3. Projektowanie minijęzyków (210)
- 8.3.1. Wybór odpowiedniego poziomu złożoności (210)
- 8.3.2. Rozszerzanie i osadzanie języków (212)
- 8.3.3. Pisanie własnej gramatyki (213)
- 8.3.4. Makra - strzeż się! (214)
- 8.3.5. Język czy protokół aplikacyjny? (215)
- 9.1. Programowanie sterowane danymi (218)
- 9.1.1. Studium przypadku: ascii (219)
- 9.1.2. Studium przypadku: statystyczne filtrowanie spamu (220)
- 9.1.3. Studium przypadku: modyfikowanie metaklas w programie fetchmailconf (221)
- 9.2. Doraźna generacja kodu (226)
- 9.2.1. Studium przypadku: generowanie kodu wyświetlającego tabelę znaków w programie ascii (226)
- 9.2.2. Studium przypadku: generowanie kodu HTML na podstawie listy tabelarycznej (228)
- 10.1. Co powinno być konfigurowalne? (231)
- 10.2. Gdzie znajdują się dane konfiguracyjne? (233)
- 10.3. Pliki kontrolne (234)
- 10.3.1. Studium przypadku: plik .netrc (236)
- 10.3.2. Przenoszenie do innych systemów operacyjnych (237)
- 10.4. Zmienne środowiskowe (237)
- 10.4.1. Systemowe zmienne środowiskowe (238)
- 10.4.2. Zmienne środowiskowe definiowane przez użytkownika (239)
- 10.4.3. Kiedy używać zmiennych środowiskowych? (240)
- 10.4.4. Przenoszenie do innych systemów operacyjnych (241)
- 10.5. Opcje wiersza polecenia (241)
- 10.5.1. Opcje wiersza polecenia od -a do -z (242)
- 10.5.2. Przenoszenie do innych systemów operacyjnych (247)
- 10.6. Którą metodę wybrać? (247)
- 10.6.1. Studium przypadku: fetchmail (248)
- 10.6.2. Studium przypadku: serwer XFree86 (249)
- 10.7. O naruszaniu tych reguł (251)
- 11.1. Stosowanie Reguły Najmniejszego Zaskoczenia (254)
- 11.2. Historia projektowania interfejsów w systemie Unix (256)
- 11.3. Ocena projektów interfejsów (257)
- 11.4. Różnice między CLI a interfejsami wizualnymi (259)
- 11.4.1. Studium: dwa sposoby pisania programu kalkulatora (263)
- 11.5. Przezroczystość, wyrazistość i konfigurowalność (264)
- 11.6. Uniksowe wzorce projektowe interfejsów (266)
- 11.6.1. Wzorzec filtra (266)
- 11.6.2. Wzorzec cantrip (268)
- 11.6.3. Wzorzec źródła (source) (269)
- 11.6.4. Wzorzec drenu (sink) (269)
- 11.6.5. Wzorzec kompilatora (269)
- 11.6.6. Wzorzec ed (270)
- 11.6.7. Wzorzec roguelike (271)
- 11.6.8. Wzorzec "rozdzielenia mechanizmu od interfejsu" (273)
- 11.6.9. Wzorzec serwera CLI (278)
- 11.6.10. Wzorce interfejsów oparte na językach (279)
- 11.7. Stosowanie uniksowych wzorców projektowania interfejsów (280)
- 11.7.1. Wzorzec programu poliwalencyjnego (wielowartościowego) (281)
- 11.8. Przeglądarka internetowa i uniwersalny Front End (282)
- 11.9. Milczenie jest złotem (284)
- 12.1. Jeżeli masz zrobić cokolwiek, lepiej nie rób nic (287)
- 12.2. Zmierz przed optymalizacją (288)
- 12.3. Nielokalność bywa szkodliwa (290)
- 12.4. Przepustowość i opóźnienia (291)
- 12.4.1. Grupowanie operacji (292)
- 12.4.2. Nakładające się operacje (293)
- 12.4.3. Buforowanie wyników operacji (293)
- 13.1. Mówiąc o złożoności (295)
- 13.1.1. Trzy źródła złożoności (296)
- 13.1.2. Wybór między złożonością interfejsu a złożonością implementacji (298)
- 13.1.3. Złożoność niezbędna, opcjonalna i przypadkowa (299)
- 13.1.4. Mapowanie złożoności (300)
- 13.1.5. Gdy prostota nie wystarcza (301)
- 13.2. Opowieść o pięciu edytorach (302)
- 13.2.1. ed (303)
- 13.2.2. vi (304)
- 13.2.3. Sam (305)
- 13.2.4. Emacs (306)
- 13.2.5. Wily (307)
- 13.3. Właściwy rozmiar edytora (308)
- 13.3.1. Identyfikowanie problemów ze złożonością (308)
- 13.3.2. Nici z kompromisu (312)
- 13.3.3. Czy Emacs jest argumentem przeciwko tradycji Uniksa? (313)
- 13.4. Właściwy rozmiar programu (315)
- 14.1. Uniksowy róg obfitości języków (319)
- 14.2. Dlaczego nie C? (320)
- 14.3. Języki interpretowane i strategie mieszane (322)
- 14.4. Ocena języków (323)
- 14.4.1. C (323)
- 14.4.2. C++ (325)
- 14.4.3. Powłoka (327)
- 14.4.4. Perl (330)
- 14.4.5. Tcl (332)
- 14.4.6. Python (334)
- 14.4.7. Java (338)
- 14.4.8. Emacs Lisp (341)
- 14.5. Trendy na przyszłość (342)
- 14.6. Wybór biblioteki systemu X (344)
- 15.1. System operacyjny przyjazny dla programisty (347)
- 15.2. Wybór edytora (348)
- 15.2.1. Co należy wiedzieć o vi (349)
- 15.2.2. Co należy wiedzieć o Emacsie (349)
- 15.2.3. Wybór przeciw religii: używaj obu (350)
- 15.3. Generatory kodu do zadań specjalnych (351)
- 15.3.1. yacc i lex (351)
- 15.3.2. Studium: Glade (354)
- 15.4. make: automatyzacja przepisów (355)
- 15.4.1. Podstawowa teoria make (355)
- 15.4.2. Make w językach innych niż C i C++ (357)
- 15.4.3. Produkcje użytkowe (357)
- 15.4.4. Generowanie plików makefile (359)
- 15.5. Systemy kontroli wersji (362)
- 15.5.1. Po co kontrolować wersje? (362)
- 15.5.2. Ręczna kontrola wersji (363)
- 15.5.3. Automatyczna kontrola wersji (363)
- 15.5.4. Uniksowe narzędzia kontroli wersji (364)
- 15.6. Debugowanie w czasie działania programu (367)
- 15.7. Profilowanie (368)
- 15.8. Łączenie narzędzi z Emacsem (368)
- 15.8.1. Emacs i make (369)
- 15.8.2. Emacs i debugowanie w czasie działania programu (369)
- 15.8.3. Emacs i kontrola wersji (370)
- 15.8.4. Emacs i profilowanie (370)
- 15.8.5. Jak IDE, ale lepsze (371)
- 16.1. Opowieść o Janie Nowicjuszu (374)
- 16.2. Przezroczystość jako klucz do ponownego użycia kodu (377)
- 16.3. Od ponownego wykorzystania do otwartych źródeł (378)
- 16.4. Najlepsze rzeczy w życiu są otwarte (380)
- 16.5. Gdzie szukać? (382)
- 16.6. Kwestie związane z używaniem otwartego oprogramowania (383)
- 16.7. Licencje (384)
- 16.7.1. Co można uznać za otwarte oprogramowanie (385)
- 16.7.2. Standardowe licencje otwartego oprogramowania (386)
- 16.7.3. Kiedy potrzebny jest prawnik? (388)
- 17.1. Ewolucja języka C (394)
- 17.1.1. Wczesna historia języka C (395)
- 17.1.2. Standardy języka C (396)
- 17.2. Standardy Uniksa (398)
- 17.2.1. Standardy i Wojny Uniksów (398)
- 17.2.2. Duch na uczcie zwycięstwa (401)
- 17.2.3. Standardy Uniksa w świecie otwartych źródeł (402)
- 17.3. IETF i Proces Standaryzacji RFC (403)
- 17.4. Specyfikacja to DNA, kod to RNA (406)
- 17.5. Programowanie ukierunkowane na przenośność (408)
- 17.5.1. Przenośność i wybór języka (409)
- 17.5.2. Omijanie zależności od systemu (412)
- 17.5.3. Narzędzia umożliwiające przenośność (413)
- 17.6. Internacjonalizacja (413)
- 17.7. Przenośność, otwarte standardy i otwarte źródła (414)
- 18.1. Koncepcje dokumentacji (418)
- 18.2. Styl Uniksa (420)
- 18.2.1. Skłonność do wielkich dokumentów (420)
- 18.2.2. Styl kulturowy (421)
- 18.3. Zwierzyniec uniksowych formatów dokumentacji (422)
- 18.3.1. troff i narzędzia z Warsztatu Dokumentatora (422)
- 18.3.2. TEX (424)
- 18.3.3. Texinfo (425)
- 18.3.4. POD (425)
- 18.3.5. HTML (425)
- 18.3.6. DocBook (426)
- 18.4. Istniejący chaos i możliwe rozwiązania (426)
- 18.5. DocBook (427)
- 18.5.1. Definicje typu dokumentu (427)
- 18.5.2. Inne definicje DTD (428)
- 18.5.3. Łańcuch narzędzi DocBook (429)
- 18.5.4. Narzędzia do migracji (431)
- 18.5.5. Narzędzia do edycji (432)
- 18.5.6. Pokrewne standardy i praktyki (432)
- 18.5.7. SGML (433)
- 18.5.8. Bibliografia formatu XML-DocBook (433)
- 18.6. Najlepsze praktyki pisania dokumentacji uniksowej (434)
- 19.1. Unix i otwarte źródła (438)
- 19.2. Najlepsze metody pracy z twórcami otwartego oprogramowania (440)
- 19.2.1. Dobre praktyki korygowania programów (440)
- 19.2.2. Dobre praktyki nazywania projektów i archiwów (444)
- 19.2.3. Dobre praktyki rozwoju projektu (447)
- 19.2.4. Dobre praktyki tworzenia dystrybucji (450)
- 19.2.5. Dobre praktyki komunikacji (454)
- 19.3. Logika licencji: jak wybrać (456)
- 19.4. Dlaczego należy stosować standardowe licencje (457)
- 19.5. Zróżnicowanie licencji otwartego źródła (457)
- 19.5.1. Licencja MIT lub X Consortium (457)
- 19.5.2. Klasyczna licencja BSD (458)
- 19.5.3. Licencja Artistic (458)
- 19.5.4. Licencja GPL (458)
- 19.5.5. Licencja Mozilla Public License (459)
- 20.1. Zasadność i przypadki w tradycji Uniksa (461)
- 20.2. Plan 9: tak wyglądała przyszłość (464)
- 20.3. Problemy w konstrukcji Uniksa (466)
- 20.3.1. Plik w Uniksie jest tylko wielkim workiem bajtów (466)
- 20.3.2. Unix słabo obsługuje graficzne interfejsy użytkownika (468)
- 20.3.3. Plik usunięty na zawsze (469)
- 20.3.4. Unix zakłada istnienie statycznego systemu plików (469)
- 20.3.5. Projekt kontroli zadań jest zupełnym nieporozumieniem (469)
- 20.3.6. API Uniksa nie stosuje wyjątków (470)
- 20.3.7. Za wywołania ioctl(2) i fcntl(2) należy się wstydzić (471)
- 20.3.8. Model bezpieczeństwa w Uniksie może być zbyt prosty (472)
- 20.3.9. W Uniksie jest zbyt wiele różnych rodzajów nazw (472)
- 20.3.10. Systemy plików można by uznać za szkodliwe (472)
- 20.3.11. W kierunku Globalnej Przestrzeni Adresowej Internetu (473)
- 20.4. Problemy w środowisku Uniksa (473)
- 20.5. Problemy w kulturze Uniksa (475)
- 20.6. Źródła nadziei (478)
Przedmowa (13)
Część I Kontekst (19)
Rozdział 1. Filozofia: filozofia ma znaczenie (21)
Rozdział 2. Historia: opowieść o dwóch kulturach (45)
Rozdział 3. Kontrasty: porównanie filozofii uniksowej z innymi (67)
Część II Projekt (93)
Rozdział 4. Modularność: czystość i prostota (95)
Rozdział 5. Tekstowość: dobre protokoły to dobra praktyka (115)
Rozdział 6. Przezroczystość: niech stanie się światłość (141)
Rozdział 7. Wieloprogramowość: wyodrębnianie procesów w celu oddzielenia funkcji (163)
Rozdział 8. Minijęzyki: jak znaleźć notację, która śpiewa (189)
Rozdział 9. Generacja: podwyższanie poziomu specyfikacji (217)
Rozdział 10. Konfiguracja: jak zacząć od właściwej nogi (231)
Rozdział 11. Interfejsy: wzorce projektowe interfejsu użytkownika w środowisku uniksowym (253)
Rozdział 12. Optymalizacja (287)
Rozdział 13. Złożoność: tak prosto, jak tylko można, ale nie prościej (295)
Część III Implementacja (317)
Rozdział 14. Języki: w C albo nie w C? (319)
Rozdział 15. Narzędzia: taktyki rozwoju (347)
Rozdział 16. Ponowne wykorzystanie: nie wyważajmy otwartych drzwi (373)
Część IV Społeczność (391)
Rozdział 17. Przenośność: przenośność oprogramowania i utrzymywanie standardów (393)
Rozdział 18. Dokumentacja: objaśnianie kodu w świecie WWW (417)
Rozdział 19. Otwarte źródła: programowanie w nowej społeczności Uniksa (437)
Rozdział 20. Przyszłość: zagrożenia i możliwości (461)
Dodatki (479)
Dodatek A Słownik skrótów (481)
Dodatek B Bibliografia (485)
Dodatek C Współpracownicy (495)
Dodatek D Korzeń bez korzenia: uniksowe koany Mistrza Foo (497)
Skorowidz (505)
Oceny i opinie klientów: UNIX. Sztuka programowania Eric S. Raymond (10) Weryfikacja opinii następuję na podstawie historii zamówień na koncie Użytkownika umieszczającego opinię. Użytkownik mógł otrzymać punkty za opublikowanie opinii uprawniające do uzyskania rabatu w ramach Programu Punktowego.
(10)
(0)
(0)
(0)
(0)
(0)
więcej opinii