Celem projektu jest ....., tak aby ..... uwzględniając, że .....

Uczyli mnie tego na jakimś pradawnym kursie, jeszcze w latach 90-ych. Miało być krótko (wraz z rozwinięciem najwyżej pół strony) i konkretnie. Główny cel, kilka celów pomocniczych, najważniejsze uwarunkowania.

Celem projektu jest budowa webowego interfejsu dla sklepu, tak aby klienci mogli efektywnie wyszukiwać i zamawiać towary przez internet, uwzględniając konieczność integracji z istniejącym systemem magazynowym.

Serdecznie dziękujemy za Pana sugestię. Informujemy, że zgłoszenie zostało przekazane do upoważnionego wydziału. Wszystkie wnioski klientów są przez nas rozważane, a usprawnianie serwisu pozostaje stale naszym celem.

Albo podobnie.

I na tym już koniec.

Bajka o programującym durniu miała być przede wszystkim o technicznych mitach. Rozpisałem się jednak o ludziach - i dzisiaj jeszcze trochę o nich. A dokładniej - o dwóch postawach przyjmowanych przy programowaniu. Nie zawsze tak skrajnych, jak opisuję niżej - ale wyrazistych.

Zacznijmy jednak od anegdotki.

W XX wieku dużo się mówiło o sztucznej inteligencji. Już, zaraz, za rogiem miały być rozumne systemy komputerowe, wykorzystywane od medycyny po zarządzanie, adaptujące się do zmiennych warunków, nawet uprawiające naukę. W literaturze i filmach komputery zyskiwały osobowość, buntowały się przeciw ludziom, prowadziły wojny - ale też potrafiły zdobywać się na uczucia wyższe.

Rzeczywistość - jak na razie - bardzo ciekawie zweryfikowała te marzenia.

W Krainie Szczęśliwych Projektów wróżka Marketingalia szepce menedżerom do ucha bajkę o cudownych narzędziach. O IDE, frameworkach, generatorach aplikacji albo językach programowania które pozwolą byle durniowi sprawnie pisać formatki, raporty czy ekrany, dopilnują, by nie robił błędów i pozwolą mu tworzyć to wszystko w deterministycznym czasie. A słuchacze - utrudzeni codzienną walką z opóźnieniami, wciąż nowymi trudnościami, chaosem w terminarzu, krnąbrnymi pracownikami - chciwie nadstawiają ucha.

Uzupełnienie artykułu o wyborach technologicznych. Tym razem nietypowe, bo wyłącznie w formie kilku cytatów, niektórych świeżych, innych wynotowanych przeze mnie już dawno temu.

Tłumaczenia moje, nie wszystkie udane (propozycje, jak je wygładzić, będą mile widziane).

Gdyby obiektywnie popatrzeć na oprogramowanie, które tworzyłem - nawet te większe, latami rozwijane przez wiele osób systemy - to napisany kod, jakkolwiek by mierzyć jego rozmiar, jest jakimś nieszczęsnym ułamkiem całej infrastruktury. Malutkim zbiorem supełków powiązanych ponad masą narzędzi wykorzystywanych do stworzenia działającej aplikacji i do jej uruchomienia.

Bazy danych. Middleware. Serwery webowe, pocztowe, telekomunikacyjne. Języki programowania z całą swą otoczką. Frameworki. Duże i małe biblioteki pomocnicze. Cała warstwa systemowa i sieciowa. I wiele wiele innych... A przecież jeszcze narzędzia developerskie, od IDE i kompilatorów po programy graficzne i wspierające pracę w grupie.

Od dwóch miesięcy próbuję się wdrażać do GTD. Używam Nozbe do ewidencjonowania rozmaitych hobbistycznych i prywatnych zadań (od przedsięwzięć domowych po tego bloga), próbuję też korzystać z samodzielnie hostowanych Tracks do rozpisania zadań zawodowych.

Czas na wstępny bilans.

Dlaczego XML odniósł sukces?

Sporo uczonych słów na ten temat napisano, najczęściej próbując dorobić różne złożone ideologie. A tymczasem, kluczem do sukcesu XML były te same dwa czynniki, które stały za sukcesem sieci WWW:

• prostota,
• łatwa amortyzacja zmian.

A przynajmniej, to o nie chodziło w zastosowaniach, którym chcę poświęcić ten artykuł: budowaniu API komunikacyjnych, procesach wymiany danych, integracji systemów.

Projekty czysto internetowe są najczęściej planowane i budowane od góry do dołu, w spójny i jednolity sposób. Informatyka biznesowa wygląda inaczej - obrazek składany jest z kilku, kilkunastu, a bywa że i kilkudziesięciu systemów, aplikacji, modułów. Interfejs webowy (albo i parę), kilka aplikacji back-office dla różnych grup pracowników, system(y) ewidencji zgłoszeń, pakiet IVR i/lub call-centre, kanał mobilny, moduł autoryzacyjny, główna baza klientów czy towarów, komponenty wymiany danych z firmami zewnętrznymi, procedury raportujące, pakiety analityczne, podsystem windykacyjny, obsługa masowych wydruków i wysyłek, system finansowo-księgowy, oprogramowanie specjalizowanych urządzeń (od robotyki przemysłowej po bankomaty), ... Wszystko to kupowane i budowane przez lata, od wielu dostawców, a potem spinane na różne sposoby.

O specyfice tego spinania może w przyszłości troszkę popiszę, ale dziś proste wspomnienie techniczne - jak sobie dwa systemy rozmawiały. Parę lat temu to było.