Giń konstruktorze! Giń! ;-)

Kartkuję sobie Effective Java i już pierwsza rada mi się spodobała :-) jest to rada "Rozważ użycie statycznej metody fabrykującej zamiast konstruktora".

To zdecydowanie ułatwia późniejszy refactoring, oraz poprawia naszą zdolność do samodzielnego zarządzania obiektami.

Jeżeli np. stworzenie obiektu jest kosztowne, a można go używać wielokrotnie to dzięki zastąpieniu konstruktora metodą fabrykującą będziemy w stanie utrzymywać np. pulę z obiektami i serwować je o wiele szybciej.
Także gdy nam obije i zapragniemy używać Singletona, albo np. jednej kopi obiektu na wątek [czasem się przydaje] to skorzystanie z metody fabrykującej zamiast konstruktora na pewno pomoże.

Innym aspektem jest łatwiejsza - czytaj wymagająca mniejszej ilości kodu - parametryzacja typu przy pomocy generyków [się rymło ;-)]

Np. teraz by stworzyć List<String> z ArrayList musimy zrobić to tak:
List<String> list = new ArrayList<String>();

Ale gdyby w klasie ArrayList zamiast konstruktora bezparametrowego była metoda:

 public static <E> List<E> createList() {
 return new ArrayList<E>();
}

Wtedy moglibyśmy kod taki:

List<String> strings = new ArrayList<String>();
List<Integer> integers = new ArrayList<Integer>();

zastąpić takim:

List<String> strings = ArrayList.createList();
List<Integer> integers = ArrayList.createList();

A ten drugi jest zdecydowanie ładniejszy ;-)

Ogólnie takie podejście ułatwia późniejszą pracę z kodem, bo gdy zmienia nam się koncepcja to dzięki takiemu podejściu mamy większą kontrolę nad tym co się dzieje.
Możemy nawet zacząć serwować obiekty innego typu niż nasz jeśli akurat taki mamy kaprsy ;-) [byle ten nowo serwowany typ obiektów był zgodny z starym typem ;-)].

OK, są dwie wady takiego rozwiązania. Wada pierwsza to niemożność dziedziczenia po takiej klasie [da się to obejść, ale przy dzisiejszym przekonaniu, że dziedziczenie jest złe i kłopotliwe może i nie warto ;-)]
Druga wada jest bardziej subtelna i wynika z faktu, że nie ma sposobu na odróżnienie takiego metody fabrykującej od innych metod statycznych, ale to można załatwić nazwą.

Podobne posty^beta
Konstruktory
Ile to jest 1+1 w Java'ie?
Lenistwo w działaniu, "piklujemy" Androida ;-)
Trick w Java'ie ;-) czyli double brace initialization
Malutki serwerek HTTP - dziełko, albo potworek ;-)

Metoda na idiotę, czyli sposób pokonywania autostrady we mgle

Dziś wyjawię wam wielki sekret, sekret mówiący o tym jak w nocy we mgle tak gęstej, że trudno powiedzieć jaka jest widoczność, jechać po autostradzie 130 km/h z dużym prawdopodobieństwem sukcesu [jak się zastanowić, to chodzi raczej o niskie, najlepiej zaniedbywalnie niskie, prawdopodobieństwo wjechania w jakieś inne auto].

Potrzebny jest idiota..... jak się zastanowić to dwóch, ale o tym czemu dwóch to będzie dalej.

Zatem potrzebujemy idioty. Dla opisania operacji nazwijmy naszego idiotę jeleniem.

Jeleń potrzebny jest nam do tego by dostarczał nam informacji o stanie drogi przed nami.
Mgła, a już szczególnie w nocy ma tą przypadłość, że trudno powiedzieć jak daleko widać. Przez to nie wiadomo czy za ułamek sekundy nie pojawi się przed nami jakieś auto, np. uszkodzony samochód z wyłączonymi światłami, albo taki z bardzo słabymi światłami. A problem polega na tym, że jadąc 130 km/h pokonujesz ponad 36 metrów na sekundę, a żeby zahamować potrzebujesz przy zablokowaniu kół coś koło 50 metrów, przy czasie reakcji równym 0.5 sekundy w najlepszym przypadku jesteś w stanie zareagować przy widoczności pozwalającej zobaczyć przeszkodę oddaloną od Ciebie o 70 metrów...... przy założeniu że jesteś mistrzem w reakcji.
I tutaj potrzebujemy jelenia, który będzie dostarczał nam informacji o drodze przed nami.
Musimy poczekać aż ktoś nas wyprzedzi jadąc z prędkością 130 km/h lub podobną - czyli jak już była mowa wcześniej, potrzebujemy idioty.
Pozwalamy mu oddalić się na tyle by widzieć jeszcze jego tylne światła.
To ważne! [tutaj mała uwaga, niech to będzie chociaż z 200 metrów odstępu, i tak mało ale w razie czego masz jeszcze krztynę szansy by hamować i uciec przy zmniejszonej prędkości na drugi pas, na pas zieleni lub na awaryjny]
Bo puki je widzimy póty możemy z dość dużym prawdopodobieństwem zakładać, że droga między nami a tymi światłami jest pusta.
Tada! ;-)

To jeleń bierze na siebie problem wypatrywania przeszkód, my zaś wnioskujemy z widoczności jego świateł, że między nami, a nim niczego nie ma.

Aha, na początku napisałem, że tak naprawdę trzeba dwóch idiotów.

Ten drugi to Ty, jeśli tak jedziesz ;-)

[zapewne technika ta pozwala także jeździć szybciej, ale Przemek jest przezorny i ma autko, które jest w stanie w miarę wygodnie rozpędzić się do 130 km/h, a przy wyższych już nie jest takie wygodne, gdyby miał szybciejsze to musiałby trenować swoją wolę by trzymać się przepisowych 130 km/h... a czemu 130? Bo czytał kiedyś jak są wytyczane Polskie drogi i problem polega na tym, że mamy kilka miejsc które określają jakie powinny być parametry drogi, ale są one wzajemnie sprzeczne, a z tego co czytał, to droga dopuszczona do prędkości 130 km/h powinna pozwalać na bezpieczną jazdę do chyba 180 km/h, ale u nas czasem zdarza się nadać drodze prędkość maksymalna taką jaka jest maksymalną bezpieczną prędkością....... OK, w przypadku autostrad jest chyba ciut lepiej, w przypadku zwykłych dróg za to gdzie jest te 90 km/h najlepiej jest podobno tam gdzie drogi wytyczali jeszcze Niemcy... tak btw. jak dobrze pójdzie za rok jeżdżąc do domu Przemek będzie mógł jechać prawie cały czas autostradami :D zacznie w Krakowie, a będzie zjeżdżał z autostrady w Świerklanach, albo Gorzyczkach [? bo nie wiem jak się będzie nazywał ten zjazd :-)]

Kids Do Not Try This at Home!


Podobne posty^beta
Przemyślenia autostradowe
Notki z uchodźstwa: jelenie Prezesa
"Demon" prędkości
Myślenie = Szybka jazda
Mały paskowy bezpiecznik i jego moc, część druga - Powrót bestii...

"Powszechnie znane" prawdy o wydajności to często bujdy na resorach

Trochę mnie przeraża posługiwanie się "powszechnie znanymi" prawdami gdy mowa o wydajności.

"Java jest wolna", tak w każdym bądź razie twierdzi wielu. Jak pokazały między innymi moje testy, Java jest szybka. Momentami ociera się o wydajność porównywalną z C i C++, a zwykle jej wydajność jest tego samego rzędu co w przypadku tych dwóch języków.

"Chrome jest najszybszą przeglądarką", to tez tak "powszechnie znana" prawda.
Ale ja sam na swoich komputerach mam tak, że wszędzie bardziej responsywny, a więc dla mnie i szybszy jest Firefox. JavaScript Firefoksa w pewnych zadaniach też jest szybszy od tego z Chrome.
Prawdę mówiąc pierwszym komputerem na którym mogę używać Chrome bez obawy, że dostanę cholery czekając na pokazanie strony [po przełączeniu się z innej strony] jest mój nowy laptop, ale on ma 4GB RAM! tutaj nawet IE MUSI być szybki ;-)

"Linux jest szybszy od Windowsa". To też nie do końca prawda, szczególnie gdy chodzi o przełączanie wątków, które w Linuksie jest wolniejsze. Stąd np. wydajność klientów Seti@Home czy teraz Boing'a jest zwykle niższa na Linuksie niż pod Windows na tym samym sprzęcie.

"Szybkość komputera zależy głównie od szybkości procesora".
Też nieprawda. Największy wzrost wydajność zawsze zauważałem po zwiększeniu pojemności RAMu. Bo bądźmy szczerzy pod takim Windows, jeśli nie masz odpowiednio dużo RAM [teraz 4 GB to rozsądne minimum] to procesor Twojego komputera i tak będzie marnował miliardy taktów tylko na to by czekać aż mechanizm stronicowania przerzuci do RAM z dysku potrzebny kawałek pamięci.
Inna sprawa, że nawet sama szybkość procesora, mierzona w ilości rzeczy, które jest w stanie zrobić w jednostce czasu nie zależy wcale tak bardzo od taktowania, a bardziej od jego architektury, o czym już tu kiedyś pisałem porównując procesory Intel Celeron 900 MHz z Intel Atom 1.6 GHz.

Teraz zaś przyszła nowa "powszechnie znana" prawda, która mówi "Go jest szybkie". Nie, na razie jest tylko porównywalne do C/C++ i Java'y. Ma za sobą potencjał więc jest szansa, że będzie szybkie.
Ale trzeba przyznać, że kompilator Go JEST szybki i to bardzo :-)

Podobne posty^beta
Celeron M353 900MHz vs. Intel Atom 1.6GHz, czyli o tym czemu jest remis? ;-)
O wyższości aplikacji natywnych nad tymi w HTML5 - od strony developera
Freakonomia, czy jak kto woli Freakonomics
A mnie tam jednak prosty model klimatyczny przekonuje do twierdzenia, że mamy wpływ na zmiany klimatyczne i że globalne ocieplenie może być faktem
Windows 8 - błeee, ciągle błeeee

Buffy dobra, brak chęci do działania zły ;-)

Oglądanie Buffy ma swoje minusy. Znów mnie korci żeby coś robić z BuffyPedią, ale problem polega na tym, że trudno tu wybrać dobrą strategię.
No i nie wiem czy warto. Przecież nie będę się męczył dla 30 osób, a znów w Polsce jest zbyt mało fanów żeby to jakoś popchnąć do przodu.
Ale i tak nowa wersja programu do generowania się już pisze ;-) choć to wszystko zależy do wielu czynników.
To już nie te czasy kiedy człowiekowi się chciało pisać, teraz wydaje się to być nudne.
[I tu leży prawdziwy problem ;-) się mi nie chce, to ma coś wspólnego z syndromem Maksa z Seksmisji, o którym już tu pisałem]

Inna rzecz, że zacząłem myśleć czy by jednak nie kupić sobie 8 sezonu, który wydawany jest w formie komiksów ;-)
Jajx, to już 6 lat od momentu gdy BtVS się skończyło.

Po głowie chodzi mi też xBox żeby móc zgrać w grę o Buffy ;-)

Fanowanie męczy ;-)

Jestem w połowie sezonu 7 i zbliżam się do końca, w planach na później mam obejrzenie znów 4 sezonu i może powtórkę od 5 lub od 1.


Podobne posty^beta
Brakuje mi BuffyPedii....
Złe Markety ;-)
"Zostaw, zostaw. Tamtego świata się nie da uratować." - czyli syndrom Maksa
Linux umiera?
Kto mi podmienia certyfikat do GMAILa? ;-) A bardziej - jak? ;-)

Go wolniejsze od C i JavaScript, i ciut szybsze niż Java ;-) [a jednak od Java'y też wolniejsze]

[update: 17/11/2009 0:08 - pozmieniałem trochę treść wpisu żeby oddawał rzeczywiste wyniki :-)
update: 14/11/2009 1:06 - Oszukałem się ;-) Go wcale takie szybkie nie jest, jeśli zwrócicie uwagę na program w Go i te w innych językach to zauważycie istotną różnicę, wszystkie języki poza Go używały odpowiednika math.pow() czyli potęgowania, w Go użyłem przez pomyłkę math.exp(), różnica jest znacząca, bo po użyciu math.Pow() prędkość spadła do 8.521 ms na 1 iterację.
W Java'ie program używający math.exp() zamiast math.pow() potrzebuje na wykonanie 1 iteracji tylko 1.37 ms, a JavaScript w Firefoksie tylko 0.74 ms, C++ 32 bitowy zaś 0.5 ms.
Go więc szybkie nie jest, w podanym przykładzie program w Go jest wolniejszy od Java'y]

Google wypuściło swój nowy język o nazwie Go.
Nie ma go dla Windowsa, jest na razie tylko dla Linuksa i MacOSa.
Sam język mi się nie podoba. Szczególnie bałagan z brakiem konwersji typów.
Język jest przemądrzały i wie lepiej od Ciebie czego chcesz, czyli gdy użyjesz:


f:=10.0;To zgadnie, że na pewno chcesz użyć typu float, ale gdy spróbujesz tego f użyć w miejscu gdzie Go oczekuje float64 to dostaniesz info o błędzie i tyle.

Żeby drania przechytrzyć trzeba użyć:


var f float64=10.0;co już takie czytelne nie jest.

Ale rzeczywiście Go wydaje się szybkie.

Znów napisałem w nim całkowanie numeryczne ;-), którego kod poniżej:

package main

import "fmt"
import "math"
import "time"

func calc() float {
  var sum float=0.0;
  var start=0.0;
  var stop=10000.0;
  var d float=20.0/stop;
  for i:=start; i<stop; i++ {
     var x float=d*i-10.0;
     sum=float(sum+float(math.Exp(float64(-x*x)))*(20.0/stop));
  }
  return sum;
}

func test() {
  start:=time.Nanoseconds();
  for i:=0; i<1000; i++ {
   calc();
  }
  stop:=time.Nanoseconds();
  var time = float64(stop-start)/1000/1000;
  fmt.Printf("%f\n",float64((time)/1000));
}

func main() {
 test();
 test();
 test();
 test();
 test();
 test();
 test();
 test(); 
}

Wszystko uruchamiałem na Ubuntu 9.10 w VMware Player 3.0. I zaskoczenie, wynik jest całkiem niezły bo wynosi 3.183 milisekundy na 1 iterację [przy wykonywaniu math.Exp(), jednak wszystkie inne języki były testowane z liczeniem potęgi czyli math.Pow(), wtedy czas wynosi 8.521 ms na 1 iterację]. [Z czasu wykonania kodu dla JavaScript'u mogę wnosić, że różnica w prędkości wykonania między hostem Windows a systemem w VMPlayer wynosi jakieś 1.5, co dawało by jakieś 2.1-2.2 ms na 1 iterację ;-) [a w rzeczywistości 5.5-6 ms], nieźle, ale nadal wolniej od Java'y, która wykonywana w tym samym środowisku potrzebuje 2 razy mniej czasu na wykonanie tego samego zadania. Trzeba jednak pamiętać, że kompilator Go dla 32 bitów nie produkuje chyba najszybszego kodu, bo główny development odbywa się w wersji 64 bitowej. Trzeba też przyznać, że sam kompilator jest NAPRAWDĘ szybki :-)
Jako jednemu z niewielu produktów Google nie życzę temu językowi na razie zbyt dużych sukcesów ;-) i na razie to nazwałbym ten język Błe.. ;-)


Podobne posty^beta
Język Go dla Windows :-)
Raspberry Pi to nie jest demon prędkości ;-)
Całkujący Dart ;-)
Go dla Java'owca ;-) odcinek 1 "klasy"
Plus dla Scala, minus dla Groovy ;-)

OOo2GD 1.9.0 w kierunku bezszwowości ;-)

Seamless to takie ładne słowo, oznaczające bezszwowość, a w przypadku komputerów to by wszystko odbywało się płynnie. To takie jedno słowo, które ma między innymi zawierać w sobie zasadę najmniejszego zaskoczenia.OOo2GD nie było bezszwowe, teraz zaczyna się za to zbliżać w tym kierunku ;-)W oknie konfiguracji pojawił się nowy checkbox, który pozwala na to by OOo2GD próbowało nadpisywać pobierane dokumenty. Teraz gdy pobierzesz kilka razy dokument o nazwie test.odt to pojawią Ci się pliki test.odt, test(1).odt, test(2).odt, test(3).odt i tak dalej. Od teraz zaznaczając "ptaszka" będzie można tego uniknąć.Ta zmiana wraz z kolejną powinno ułatwić updatowanie dokumentów w Google Docs.Od teraz OOo2GD będzie starał się sprawdzić czy wśród dokumentów w Google Docs nie ma takiego, którego nazwa jest podobna do nazwy aktualnego pliku, jeśli będzie to zamiast domyślnie ustawić się w trybie wysyłania nowego pliku, ustawi się w trybie updatowania tego "podejrzanie podobnego" dokumentu.Ostatnią zmianą jest to, że OOo2GD będzie próbowało wykorzystywać informacje, które już raz pobrało. Mówiąc inaczej, jeśli używasz okna importu i ściągasz listę dokumentów, po czym okno to zamykasz i otwierasz jeszcze raz to OOo2GD spróbuje wyświetlić tą wcześniej pobraną już listę dokumentów zamiast zmuszać Cię do ponownego klikania na "Pobierz listę".Zapraszam na stronę projektu oraz do pobierania.

Podobne posty^beta
Wersja 2.0.0 OOo2GD już jest :-)
OOo2GD 3.0.0 - eksportowanie do Google Docs bez konwersji :-)
Wysyłamy naszą e-bibliotekę do Google Play Books :-)
OOo2GD 2.1.1 gotowe :-)
Co umie OpenOffice.org2GoogleDocs ;-)

BLIP API rozrabia, czyli czemu Blipuś był zszedł ;-)

To, że Blipuś [czyli mój wprawkowy klient Blipa dla Androida] umarł jakiś czas temu nie jest chyba tajemnicą ;-) sam straciłem zainteresowanie Blipem, a przez to też developmentem nowszych wersji Blipusia.

Ale ciekawe jest to, że z niewyjaśnionych przyczyn w ogóle nie jestem w stanie przy pomocy BLIP API wysłać żadnego komunikatu :-)

Nic, zero, null.

Próbuję wysłać taki message:

----------------AaB03x
Content-Disposition: form-data; name="update[body]"
Content-Type: text/plain

>przemelek:To jest test

----------------AaB03x--

i nic, serwer odpowiada mi błędem 500.
A kiedyś działało ;-) Wg. dokumentacji nadal powinno działać.

Jak ktoś ciekawy to może sobie przejrzeć kawałek kodu, który tworzy tego message'a, błąd 500 wylatuje w momencie próby otwarcia "kanału zwrotnego" w linii 225.


Podobne posty^beta
Blipuś v0.3 czyli Blip na Androidzie :-)
Blipuś znów działa :-)
Linki, czemu nikt nie używa linków?
Linko skrótacze
Naprawdę uwielbiam...

"Zostaw, zostaw. Tamtego świata się nie da uratować." - czyli syndrom Maksa

Cierpię już od dłuższego czasu na syndrom Maksa z Seksmisji ;-)

W pewnym momencie, gdy Albert snuje plany by z pomocą Lamii i Emmy doprowadzić do re-introdukcji ;-) mężczyzn Maks studzi jego zapały słowami:"Zostaw, zostaw. Tamtego świata się nie da uratować."

I sam tak już od jakiegoś czasu miewam. Co prawa w innych sprawach, ale jednak ;-)

Np. ktoś się rozwodzi nad wyższością świąt Wielkiej Nocy nad świętami Bożego Narodzenia, czyli np. przekonuje, że Linux jest gorszy od Windowsa, albo Windows gorszy od Linuksa.

Człowiek chciałby się odezwać, powiedzieć coś, ale po chwili zastanowienia milczy, bo nie warto, bo tego kogoś i tak się już nie uda uratować ;-)

Przez wiele lat myślałem, że wszystkie problemy uda się załatwić dzięki rozmowie, że można porozmawiać, wymienić swoje poglądy i w najgorszym przypadku dojdzie się do protokołu niezgodności.

Ale z czasem dotarło do mnie, że się myliłem. Są ludzie, może nawet stanowią większość, z którymi nie da się rozmawiać. Nie trafiają do nich żadne argumenty.

Sam taki bywam ;-)


Podobne posty^beta
Walentynki
Buffy dobra, brak chęci do działania zły ;-)
Wernyhora mode ;-)
Nexus 7 sprzedaje się jak świeże bułeczki :-)
Przeżycie artystyczne ;-)

Nie Polak

Właśnie z ust najjaśniej nam panującego Lecha Aleksandra Kaczyńskiego spłynęły słowa które dla mnie zabrzmiały jako sugestia bym opuścił Polskę.
Chodzi o słowa:
"Nikt nie będzie w Polsce przyjmował do wiadomości, że w szkołach nie wolno wieszać krzyży, nie ma na co liczyć. Być może gdzie indziej tak, ale w Polsce nie"

Rozumiem, mam wypierdalać z Polski, bo swoją obecnością kalam świętą ziemię.

Takiego wała! Nie będzie tak łatwo. Ktoś tu poziom musi trzymać, widać wypadło między innymi na mnie. Zostaję.


Podobne posty^beta
Wesołek ;-)
Ostrzeżenie
Mentalność czy dobór materiałów?
Pośpiech, BuffyPedia i Cool and Quiet
Znów o rozwiązywaniu krzyżówki

Przeszacowany Linux, Niedoszacowany Windows i Ukryty MacOS ;-) czyli o tym na jakich systemach używa się głównie OOo2GD

No i proszę, jak na razie zbiorowa ocena 11 osób, które postanowiły wypowiedzieć się w sprawie tego jak wygląda udział systemów operacyjnych wśród użytkowników OpenOffice.org2GoogleDocs dość znacznie odbiega od wyników uzyskanych przeze mnie w trakcie "odpytywania" przez OpenOffice.org o nową wersję OOo2GD ;-)Największa różnica występuje w przypadku Linuksa."Sędziowie" znacząco przeszacowują jego udział w "rynku".W przypadku Mac OS wynik uzyskany ze zbiorowej mądrości jest niemal identyczny z rzeczywistym.Udział Windows jest za to niedoszacowany przez uczestników zabawy.Co równie ciekawe, rzeczywista kolejność udziałów wśród systemów operacyjnych jest inna niż ta, która wynika z szacunków 11 osób.Najpierw o metodologi ;-)Wyniki dla "zbiorowej mądrości" powstały przez wyciągnięcie średnich z wszystkich głosów, tych głosów było 11.Pomiar "z natury" przeprowadzony został zaś w oparciu o nagłówek userAgent przekazywany przez instancje OpenOffice.org odpytujące o to czy dostępna jest nowa wersja rozszerzenia OOo2GD [w tym celu sprawdzają zasób pod URLem http://www.przemelek.pl/gdocs.update.xml].Tutaj przykłady typowego wyglądu tego nagłówka:OpenOffice.org 3.1 (310m11(Build:9399); MacOSX; x86; BundledLanguages=sv),gzip(gfe),gzip(gfe)OpenOffice.org 3.1 (310m11(Build:9399); Windows; x86; BundledLanguages=es),gzip(gfe),gzip(gfe)Jego typowa budowa to:Wersja OO.org (oznaczenie buildu(numer buildu); System Operacyjny; architektura procesora; język)W około 0.3% przypadków zdarzały się inne nagłówki, głównie przeglądarek internetowych i parę botów, oraz 1 instalacja z MacOS X, która wysyłała w miejscu architektury dziwne ciągi.W mierzonym okresie [około 23 godzin] było łącznie 6736 odpytań [jeżeli w ciągu 2 minut ten sam adres IP pytał kilka razy to liczony był tylko raz], z czego tylko 22 nie zostały zidentyfikowane jako instancje OO.org.Po przydługim opisie "metodologii" badania przedstawmy wyniki ;-)Wyniki mądrości ludu są następujące:Windows 64.14%Linux 24.85%MacOS 9.1%Wyniki "z natury" są ciut inne ;-)Windows 88.87%Linux 1.44%MacOS 9.37%Jak widać jedynie ocena udziału MacOS była bliska rzeczywistego wyniku, w przypadku Linuksa jego udział w rynku został przeszacowany o ponad 17 razy!Wg. uczestników zabawy Linux znajduje się na 24.85% komputerów, czyli na blisko 1/4, a w rzeczywistości znajduje się tylko na mniej niż 1.5% maszyn.Z drugiej zaś strony udział Windowsa został dość mocno niedoszacowany.W tym świetle szacunki mówiące o tym, że Linuks znajduje się na mniej niż 1% maszyn biurkowych na świecie wydają się uzasadnione.Ta metoda pomiaru prawdopodobnie zawyża udziały Linuksa i MacOSa kosztem Windows, dzieje się tak ponieważ dla Windows o wiele bardziej popularnym pakietem biurowym jest chyba jednak MS Office, zaś w przypadku Linuksa i MacOS [w tym przypadku mogę się mylić] OpenOffice.org lub jego pochodne są najbardziej popularnym wyborem.Te wyniki utwierdzają mnie w przekonaniu, że Linux umiera :-(

Podobne posty^beta
OOo2GD w liczbach ;-)
Trochę liczb :-)
Paradoks Java'y - domyślny poziom widoczności jest stosowany najrzadziej ;-)
Demokracja
Po Devoxx&amp;amp;#39;ie