Microsoft na NIE - okiem programisty

Pod wszystkimi artykułami na dobrychprogramach, które dotyczą w jakikolwiek sposób firmy Microsoft, głos wiodący należy do trolli i linuksowego betonu, który krytykuje “dla zasady” nie znając się w zupełności na technologiach i rozwiązaniach konkurencyjnych dla jedynie słusznych - otwartoźródłowych. Zabawne, że trollowi zdarza się mieć rację, choć z powodów o których nie ma zielonego pojęcia. Bedąc entuzjastą i jednocześnie zawodowym programistą technologii Microsoft postanowiłem dostarczyć mu rzeczowych argumentów i jednocześnie wyrzucić się z siebie to, co leży mi na wątrobie.

Mnogość technologii desktopowych

Przyjmijmy, że naszą pracą jest napisanie aplikacji desktopowej. Wybraliśmy platformę Microsoft Windows, gdyż jest to bardzo popularna (w niektórych krajach na Zachodzie wręcz dominująca) platforma używana w biznesowych zastosowaniach. Kolejnym krokiem jest wybór technologii w której nasz program powstanie. Wymieniając na szybko mamy możliwość tworzenia w:

• WinAPI (C)
• MFC (C++)
• Windows Forms (C++\CLI, C#, VB i pozostałych .NET*)
• Windows Presentation Foundation (C#, VB, reszta wraz z C++\CLI jest możliwa po małej gimnastyce)
• Silverlight (podobnie jak wyżej)
• WinRT \ XAML - wersja C, C++\CX
• WinRT \ XAML - wersja niby .NET
• WinRT \ HTML + JavaScript

Również przypadku systemów uniksowych mamy ogrom różnych technologii, ale przeważnie każda ma innego twórcę. Autorem zaś wszystkich powyższych bibliotek, a po części i języków (C#) czy metodologii (MVVM w XAML) jest jedna i ta sama firma - Microsoft. Człowiek instynktownie przeczuwa, że nie da się naprawdę dobrze zarządzać tak wielką ilością różnych technologii. A właśnie poziom “naprawdę dobry” to minimum co musi zostać zapewnione deweloperom, gdyż nie minie dużo czasu do odpływu użytkowników jeśli odejdą programiści.

Z drugiej strony - powyższa lista wydaje się powielać niektóre rozwiązania. Czy na pewno? Oczywiście - opanować XAML to w dużym stopniu opanować WPF, Silverlight i coś co obecnie funkcjonuje najczęściej pod szyldem XAML\C# Metro Style (nazwa beznadziejna i oby nadali jej jakąś zjadliwą nazwę). Dla programisty małe ma znaczenie jak bardzo te technologie są do siebie podobne - jeśli nie są tożsame (a nie są), to przenoszenie aplikacji pomiędzy nimi wiąże się zwykle z ogromnym nakładem pracy.

Analogicznie C++ to nie to samo co C++\CLI, podobnie jak (pojawiający się wraz z premierą Windows 8) C++\CX . Podczas gdy programiści aplikacji webowych zgrzytają zębami na myśl o podwojeniu liczby przeglądarek o którą trzeba dbać (każda licząca się pojawi się w wersji Metro), ja podobnie zastanawiam się nad .NET i WinRT. Niby inny poziom abstrakcji, niby jedno korzysta z drugiego, ale ile bibliotek napisanych dla .NET będzie bezproblemowo działać w środowisku WinRT? Odpowiedź; sporo, gdyż WinRT zapewnia dostęp do większości przestrzeni nazw biblioteki Base Class Library. Problem leży w słowach “sporo” i “większość”, które nie powinny się tu absolutnie znaleźć.

Aby nie być gołosłownym, wystarczy wspomnieć projekt Mono. Czy komuś udało się bezproblemowo przenieść aplikację bardziej skomplikowaną od kalkulatora ze standardowego CLR Microsoftu do Mono? Jedno odwołanie P\Invoke oznacza konieczność spędzenia konkretnego nakładu czasu na - często z góry skazane na niepowodzenie - dostosowywanie kodu.

Efekt? Od początku trzeba wybrać; albo piszę pod oficjalny CLR dla .NET, albo pod Mono. Czy z WinRT będzie podobnie?

“Tylko wspierane”

Jeśli programujesz rozwiązania biznesowe z użyciem narzędzia o którym nikt już nie pamięta - wiedz, że Microsoft pamięta doskonale. Chociaż gigant z Redmond nie porzuca swoich technologii (oczywiście, zdarzają się wyjątki od reguły), to zamiast tego posuwa się do tzw. “tylko wspierania”. Jak to wygląda w praktyce? Najpierw pojawia się nowa, lepsza technologia, którą zaczyna bardzo intensywnie rozwijać. Entuzjazm aktualizowania poprzednika powoli gaśnie i dochodzi do momentu w którym jedną z najważniejszych nowości jest jakiś sposób integracji z prężnie ewoluującym kontynuatorem. Następnie rozwój prawie całkowicie zamiera, dochodzą jedynie aktualizacje bezpieczeństwa i poprawki o które programiści proszą od dawna. W końcu pozostaje już tylko cieszyć się, że dana technologia w ogóle jest brana pod uwagę przy jakichkolwiek planach na przyszłość. Wsparcie zostaje, ale rozwój zamiera.

Czy tylko ja ma wrażenie, że wyżej opisany scenariusz ma miejsce w przypadku:

• Windows Forms na rzecz WPF?
• WPF na rzecz XAML/C#?
• ASP.NET Web Forms na rzecz ASP.NET MVC?
• Silverlight na rzecz “Native HTML5”?

W każdym z powyższych przypadków czytamy te same wyjaśnienie; technologie te mają “różne zastosowania” i będą wspierane “równocześnie”. Tymczasem programiści WinForms już dawno powinni zauważyć, iż mało jest realizowanych od zera projektów do których są angażowani. Najczęściej ich praca polega na utrzymywaniu już istniejącej architektury. Silverlight jako wtyczka przeglądarkowa też będzie wspierany jeszcze długi czas, ale czy ktoś łudzi się, że wyjdzie wersja 6?

Internet Explorer

Złe przeglądarki od Microsoftu skończyły się na IE8. Wersja 9 jest już zdecydowanie normalna zarówno dla użytkowników (choć brakuje jej wtyczek...) jak i dla programistów (zgodność z powszechnymi standardami).

Problem polega na tym jak Microsoft radzi sobie ze smrodem poprzedników, bo zgodnie z polityką opisaną wyżej, IE w wersjach 6, 7 i 8 nie są porzucane. I dobrze, bo stanowią platformę uruchomieniową dla ogromnej ilości aplikacji biznesowych i korporacyjnych. Z drugiej zaś strony zupełnie inaczej wyobrażam sobie “wspieranie” przeglądarki. Czy silnik renderujący i obsługujący javascript nie mogłoby być aktualizowany na biężąco? Projekt Google Chrome Frame pokazał, że nic nie jest niemożliwe. Osławiony tryb zgodności (debiutujący w IE7) powinien być tak naprawdę opcją wykorzystania oryginalnego silnika danej przeglądarki. Nie jest to rozwiązanie idealne (a tylko szybka propozycja), ale ile krwi zaoszczędziłaby zgodność starych wersji IE ze standardami współczesnego Internetu osiągalna nie poprzez instalację całkowicie nowych aplikacji, ale proste aktualizacje. Zdecydowanie bardziej zjadliwe dla klientów korporacyjnych.

Niestety - każda nowa wersja IE rozpoczyna nową epokę “optymalizacji” aplikacji pod konkretne ich wersje, a programiści dostają białej gorączki, gdy w 2012 roku stają przed wizją dopisania nowego skomplikowanego modułu do systemu dedykowanemu IE7.

Nadmiarowe wizjonerstwo - ze skrajności w skrajność

O ile Internet Explorer jest - niestety wciąż - smrodem przeszłości, o tyle inne zespoły firmy z Redmond pracują nad technologiami, które są tak do przodu w porównaniu do aktualnej epoki, że aż do niej nie pasują. Nie byłoby to może i wadą, ale czasem technologiczny świat idzie w trochę innym kierunku niż zakładali inżynierowie z Redmond. Wtedy imputuje się z nie do końca trafionych pomysłów tyle ile to możliwe do nowych rozwiązań, które bardziej odpowiadają realiom. Być może następny akapit nie pasuje do tytułu artykułu, ale należy nakreślić kontekst.

WPF, czyli Windows Presentation Foundation. Gigantyczny skok pod każdym względem w porównaniu do Windows Forms i śmiem twierdzić, że najlepsza technologia tworzenia aplikacji okienkowych dostępna na rynku. Na szybko można wymienić osobny silnik renderujący MIL rysujący za pomocą DirectX, udostępniający spore możliwości multimedialne i prostą drogę do osiągnięcia rozbudowanych efektów wizualnych małym nakładem sił. Elastyczność uzyskana poprzez język programowania interfejsu XAML i rozdzielenie warstw aplikacji trochę na wzór z aplikacji webowych w specjalnie zaprojektowanym dla WPF wzorcu MVVM. Całość ukoronowana świetnymi narzędziami deweloperskimi, za pomocą których faktycznie jesteśmy w stanie utrzymywać osobno zespół programistów (Visual Studio) jak i grafików (Expression Blend) pracujących nad tą samą aplikacją.

Brzmi wspaniale? Powiem więcej; to działa. Pojawia się jednak magiczne słówko “ale”. Otóż po pierwsze aby poprawnie i wydajnie operować technologią WPF należy poświęcić dość konkretną ilość godzin na jego naukę. I choć dużo da się wykonać “po staremu” (w tzw. “code-behind”), to jest to wręcz nieeleganckie. Tymczasem posługiwanie się XAMLem i modelem MVVM wymaga niemałej wprawy. Oprócz tego aplikacje WPF są z reguły ciężkie i wymagające sprzętowo. Efekt? Kojarzę ledwie kilka popularnych aplikacji użytkowych napisanych w WPF, np. Yahoo Messagener, czy Nero. Technologia ta znalazła swoją niszę ze względu na swoje olbrzymie możliwości i eleganckie praktyki tworzenia oprogramowania - sa to wspomniane już wielokrotnie w tym tekście zastosowania biznesowe.

A kto wie, czy gdyby rozwój konsumenckiego IT nie skręcił w kierunku mobilności i architektury ARM to Windows 8 byłby w całości napisany w WPF? Tymczasem Ósemka musi działać możliwie szybko na mało wydajnych procesorach. Tutaj zaś umiejętności operowania XAMLem i MVVM można wykorzystać programując w drugim już (po Silverlight) szczepie o ohydnej nazwie XAML/C#. A poczciwy, oryginalny WPF? Naprawdę szczerzę mu życzę, aby nie dołączył do reszty "wspieranych" technologii...

c.d.n.