eGospodarka.pl
eGospodarka.pl poleca

PracaGrupypl.praca.dyskusjerozważania/narzekania programisty JEE na temat rozwoju.....
Ilość wypowiedzi w tym wątku: 90

  • 41. Data: 2007-09-04 11:38:43
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: v...@g...com


    > > Kyniu
    >
    > Witam
    >
    > Jakie masz argumenty za tym ,że JAVA jest największą pomyłką informatyki?
    >

    Bo z zalozenia mial byc przenosny?
    Dla mnie jako zwyklego lusera w tej sprawie, programy w Javie to
    klockowate gnioty, zajmujace znacznie wiecej zasobow komputera niz
    rownowazny program napisany w C/C++ chociazby.

    Uzywam na codzien kilku programow napisanych w Javie i bez wyjatku to
    zamulacze kompa - wolno sie uruchamiaja, wolna dzialaja, i zzeraja bez
    umiaru pamiec.
    Zreszta roznice miedzy jezykami latwo znalezc np porównując
    klasycznego klienta Bittorenta, napisanego w Pythonie,z uTorrentem
    pisanym w C++. Ten drugi jest jak rakieta ;-)))...

    Widze tez, ze wiekszosc z tych co napadli na Kyniu, to ludzie zyjacy z
    dlubania w Javie, wiec nie dziwie sie ze chca mu wydlubac oczy.


  • 42. Data: 2007-09-04 12:07:33
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: Wojciech Bańcer <p...@p...pl>

    v...@g...com napisał(a):


    >> Jakie masz argumenty za tym ,że JAVA jest największą pomyłką informatyki?

    > Bo z zalozenia mial byc przenosny?
    > Dla mnie jako zwyklego lusera w tej sprawie, programy w Javie to
    > klockowate gnioty, zajmujace znacznie wiecej zasobow komputera niz
    > rownowazny program napisany w C/C++ chociazby.

    To ile masz tych programów w C/C++ na serwerach WWW oraz komórkach?

    --
    Wojciech 'Proteus' Bańcer
    p...@p...pl


  • 43. Data: 2007-09-04 12:35:04
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: v...@g...com


    >
    > To ile masz tych programów w C/C++ na serwerach WWW oraz komórkach?
    >

    Hmm mialem na mysli raczej programy na desktopa. W powyzszych
    zastosowaniach nie neguje Javy.
    Tylko nie mozna jej traktować jako narzedzia do wszystkiego.



  • 44. Data: 2007-09-04 12:41:23
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: glosnetu <g...@p...onet.pl>

    On 4 Wrz, 14:35, v...@g...com wrote:
    > > To ile masz tych programów w C/C++ na serwerach WWW oraz komórkach?
    >
    > Hmm mialem na mysli raczej programy na desktopa. W powyzszych
    > zastosowaniach nie neguje Javy.
    > Tylko nie mozna jej traktować jako narzedzia do wszystkiego.

    a gdzie ktos napisal, ze java to narzedzie do wszystkiego?

    --

    Pozdrawiam,

    glos


  • 45. Data: 2007-09-04 13:32:33
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: Wojciech Bańcer <p...@p...pl>

    v...@g...com napisał(a):

    >> To ile masz tych programów w C/C++ na serwerach WWW oraz komórkach?

    > Hmm mialem na mysli raczej programy na desktopa. W powyzszych
    > zastosowaniach nie neguje Javy.
    > Tylko nie mozna jej traktować jako narzedzia do wszystkiego.

    Nikt tu nie pisał, że Java jest narzędziem do wszystkiego. Ale tak się
    składa, że aplikacje sieciowe i mobilne, to ostatnio bardzo mocno
    rozwijający się rynek. A J2EE poruszany w temacie wątku, to jak najbardziej
    zastosowania serwerowe, a nie desktopowe.

    --
    Wojciech 'Proteus' Bańcer
    p...@p...pl


  • 46. Data: 2007-09-04 18:15:51
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: asiaque <a...@w...hell.pl>

    Wojciech Bańcer <p...@p...pl> wrote:
    > Nikt tu nie pisał, że Java jest narzędziem do wszystkiego. Ale tak się
    > składa, że aplikacje sieciowe i mobilne, to ostatnio bardzo mocno
    > rozwijający się rynek. A J2EE poruszany w temacie wątku, to jak najbardziej
    > zastosowania serwerowe, a nie desktopowe.

    No to w takim razie z punktu widzenia osoby zajmującej się na co dzień
    utrzymaniem parunastu/parudziesięciu aplikacji J2EE w najróżniejszych
    środowiskach, darmowych i komercyjnych, pod najróżniejszymi JVM-ami:
    - są o wiele bardziej zasobożerne od ich funkcjonalnych odpowiedników
    pisanych w C/C++ (jak raz parę możliwości porównania mam, to wiem);
    - ciekną - w garbage collector uwierzę jak zobaczę ;)
    - ohydnie logują (nie wątpię, że dla programisty kilometrowe zrzuty z
    wyjątków są wybitnie przydatne, ale mówimy o systemach oddanych do
    eksplotacji); alternatywa "logować mniej/nic" nie wchodzi w grę;

    Krótko mówiąc, w utrzymaniu bywają prawdziwym bólem w dupie. Tak jakby
    były pisane dla programistów, nie dla odbiorców. Potwierdza się to zresztą
    gdy napotkasz na jakąkolwiek zagwozdkę związaną z utrzymaniem i szukasz
    pomocy w dokumentacji. "Tu sobie dopisz fooshmoo, tu sobie zrekompiluj, tu
    w tej klasie popraw to i tamto". Jestem adminem, nie wolno mi "sobie
    poprawiać", a na zasoby programistyczne dla mojej wygody utrzymania nikt
    nie zainwestuje złotówki - tymczasem to mnie rozliczają z poziomu
    dostępności usługi.

    Powiesz, że większość powyższych utrapień to wina błędu w sztuce
    programistycznej - w to uwierzyłabym gdybym miała jedną czy dwie takie
    aplikacje. A po tych paru latach wychodzi mi, że Java jest po prostu
    językiem zbyt łatwym do nauczenia się - potem siada taki miś po tygodniowym
    kursie w $danej_biedronce_informatycznej i przekonany, że już umie, tworzy
    soft, z którym potem inni latami muszą się użerać.

    I zanim mnie tu jakiś keyboard warrior zaatakuje zza węgła: nie marudzę,
    radzę sobie. Ot, trochę więcej czasu marnuję na rzeczy niepotrzebne.

    a.


  • 47. Data: 2007-09-04 19:22:20
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: "Aleksander Galicki" <t...@g...pl>

    asiaque <a...@w...hell.pl> napisał(a):

    > Wojciech Bańcer <p...@p...pl> wrote:
    > > Nikt tu nie pisał, że Java jest narzędziem do wszystkiego. Ale tak się
    > > składa, że aplikacje sieciowe i mobilne, to ostatnio bardzo mocno
    > > rozwijający się rynek. A J2EE poruszany w temacie wątku, to jak najbardziej
    > > zastosowania serwerowe, a nie desktopowe.
    >
    > No to w takim razie z punktu widzenia osoby zajmującej się na co dzień
    > utrzymaniem parunastu/parudziesięciu aplikacji J2EE w najróżniejszych
    > środowiskach, darmowych i komercyjnych, pod najróżniejszymi JVM-ami:
    > - są o wiele bardziej zasobożerne od ich funkcjonalnych odpowiedników
    > pisanych w C/C++ (jak raz parę możliwości porównania mam, to wiem);
    > - ciekną - w garbage collector uwierzę jak zobaczę ;)
    > - ohydnie logują (nie wątpię, że dla programisty kilometrowe zrzuty z
    > wyjątków są wybitnie przydatne, ale mówimy o systemach oddanych do
    > eksplotacji); alternatywa "logować mniej/nic" nie wchodzi w grę;
    >
    > Krótko mówiąc, w utrzymaniu bywają prawdziwym bólem w dupie. Tak jakby
    > były pisane dla programistów, nie dla odbiorców. Potwierdza się to zresztą
    > gdy napotkasz na jakąkolwiek zagwozdkę związaną z utrzymaniem i szukasz
    > pomocy w dokumentacji. "Tu sobie dopisz fooshmoo, tu sobie zrekompiluj, tu
    > w tej klasie popraw to i tamto".

    Tak z ciekawosci: a co z maintenance contract? Zwykle, jak sie oddaje
    aplikacje, jest zawierany rowniez paroletni maintenance contract i w przypadku
    ciekniecia (ktore konczy sie pieknym OutOfMemoryError) czy innych bledow -
    jest psim obowiazkiem odpowiedniej firmy to naprawic. Administrator nic nie
    powinien poprawiac w zadnej klasie, zwlaszcza, ze zwykle jest to nielealne.


    A.

    --
    Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/


  • 48. Data: 2007-09-04 20:06:18
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: asiaque <a...@w...hell.pl>

    Aleksander Galicki <t...@g...pl> wrote:
    > Tak z ciekawosci: a co z maintenance contract? Zwykle, jak sie oddaje
    > aplikacje, jest zawierany rowniez paroletni maintenance contract i w przypadku
    > ciekniecia (ktore konczy sie pieknym OutOfMemoryError) czy innych bledow -
    > jest psim obowiazkiem odpowiedniej firmy to naprawic. Administrator nic nie
    > powinien poprawiac w zadnej klasie, zwlaszcza, ze zwykle jest to nielealne.

    Być może w doskonałej przyrodzie tak jest. W mojej zbyt często zdarza się
    jeden z poniższych scenariuszy:

    - Supportu nie ma, bo nie. Mam jedną taką aplikację - odebrana w 2002
    chyba, dostawca rokrocznie zwiększał cenę maintenance'u, aż ktoś wywalił to
    z budżetu z argumentem "w razie czego będziemy im płacić za wykonanie
    pracy". A nikt mi takich kosztów nie chce zaakceptować ("przecież wystarczy
    zrestartować i działa"). Na szczęście akurat z tą aplikacją nie ma za wiele
    problemów.

    - Support jest, ale dostawca, traf chciał, zatrudnia (powiedzmy) 30
    programistów, a wykonuje dla nas dziesiątki superważnych projektów.
    Priorytet mojego zgłoszenia jest w związku z tym obniżany przez osoby
    decyzyjne ("przecież wystarczy zrestartować i działa").

    - Jak już się doczeka analizy - zazwyczaj rozwiązanie sprowadza się do
    "Zwiększcie pamięć kontenera/pulę połączeń" (ha, ha). Problem odsunięty o
    parę tygodni, w trakcie których ticket się zamyka, a kolejne zgłoszenie
    traktuje jak zupełnie oddzielne zdarzenie, oddzielnie liczony czas reakcji
    etc.

    - Aplikacja jest "rozwojowa", biznes nieustannie zleca tworzenie nowych
    funkcjonalności, które są dokładane po kilka/kilkanaście tygodniowo,
    terminy naglą, programiści piszą byle jak, w rezultacie na miejsce jednego
    usuniętego leaka przychodzą 3 nowe.

    Najlepsze jaja są wtedy, gdy system A jest zintegrowany z systemem B innego
    dostawcy - wtedy wszystkie problemy z A można oczywiście zrzucić na ten B.
    Dostawca B się naturalnie wypiera i jest wesoło, bo nie ma winnych, a
    downtime rośnie... :)

    Powiesz, że "cóż, nie masz kasy, to cierp" - ale moja firma chyba nie
    jest jakoś bardzo odosobniona w tym, że finansowanie wrzuca głównie w
    tworzenie nowych rozwiązań biznesowych, a coś, co już raz wdrożono, uznaje
    się za rozdział zamknięty - chyba że problem jest na tyle krytyczny, że
    wstrzymuje sprzedaż/produkcję bądź jest błędem związanym z bezpieczeństwem.
    I tak sobie lecimy na workaroundach, bo "przecież wystarczy... etc". :)

    a.


  • 49. Data: 2007-09-04 20:39:11
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: Any User <t...@t...pl>

    > Być może w doskonałej przyrodzie tak jest. W mojej zbyt często zdarza się
    > jeden z poniższych scenariuszy:

    > Powiesz, że "cóż, nie masz kasy, to cierp" - ale moja firma chyba nie
    > jest jakoś bardzo odosobniona w tym, że finansowanie wrzuca głównie w
    > tworzenie nowych rozwiązań biznesowych, a coś, co już raz wdrożono, uznaje
    > się za rozdział zamknięty - chyba że problem jest na tyle krytyczny, że
    > wstrzymuje sprzedaż/produkcję bądź jest błędem związanym z bezpieczeństwem.
    > I tak sobie lecimy na workaroundach, bo "przecież wystarczy... etc". :)

    Bo o to właśnie chodzi w biznesie, aby zarabiać kasę. A dopóki Twoje
    zmagania są dla firmy opłacalne, to nie ma sensu topić kasy w czymś
    nierozwojowym, tylko dla wygody pracownika/ów.

    Pocieszę Cię, że pracownicy większości zawodów mają znacznie gorzej.


    --
    Zobacz, jak się pracuje w Google:
    http://pracownik.blogspot.com


  • 50. Data: 2007-09-04 23:20:42
    Temat: Re: rozważania/narzekania programisty JEE na temat rozwoju.....
    Od: "Aleksander Galicki" <t...@g...pl>

    asiaque <a...@w...hell.pl> napisał(a):

    > Aleksander Galicki <t...@g...pl> wrote:
    > > Tak z ciekawosci: a co z maintenance contract? Zwykle, jak sie oddaje
    > > aplikacje, jest zawierany rowniez paroletni maintenance contract i w przypadk
    > u
    > > ciekniecia (ktore konczy sie pieknym OutOfMemoryError) czy innych bledow -
    > > jest psim obowiazkiem odpowiedniej firmy to naprawic. Administrator nic nie
    > > powinien poprawiac w zadnej klasie, zwlaszcza, ze zwykle jest to nielealne.
    >
    > Być może w doskonałej przyrodzie tak jest.

    To nie jest doskonalosc, to calkiem zwyczajna normalnosc. To co opisujesz to
    jest raczej przypadek kompletnej indolencji w zarzadzaniu (Twoja firma). Na to
    zaden jezyk programowania rady nie da.
    Choc, to ze macie problemy z memory leaks wskazuje, ze developerow tez macie
    nienajlepszych (oglednie mowiac). Ostatni raz, gdy widzialem leak w aplikacji
    javowej bylo z 6 lat temu. Ale jest istotna roznica pomiedzy memory leaks a
    niewystarczajaca iloscia zasobow dla aplikacji. Dostalas niewatpliwie
    java.lang.OutOfMemoryError z jakims komunikatem. Z ciekaowosci: jaki byl
    komunikat?

    A jak powinno byc? Mniej wiecej tak: firma, ktora potrzebuje i ktora stac na
    nascie projektow softwareowych zatrudnia zespol odpowiednich prawnikow i pare
    tzw enterprise/solution architects. Zadaniem prawnikow m.i. jest takie
    formulowanie umow z firmami programistycznymi by zapewnic interesy wlasnej
    firmy i, w razie czego, ud..nie firm, ktore sie nie wywiazuja z podpipsanych
    kontraktow. Zadaniem architekta (czesto jest to osoba, ktora spedzila z 10 lat
    po drugiej stronie i zdecydowala sie na 10 razy mniej ciekawa prace za 3 razy
    wiecej kasy) jest kontrolowanie i zatwierdzanie merytoryczne tego co robi
    wykonawca. Zwykle takie jednorazowe projekty to tzw fixed price-fixed size, co
    oznacza ze termin, koszty, deliverables i jakosc owych deliverables sa
    ustalone przy podpisywaniu kontraktu. Za dowolne poslizgi wzgledem ustalonych
    uprzednio kosztow i terminow placi wykonawca. Kary za poslizgi tez sa
    ustalone. Krytycznych bugow po releasie zwykle nie ma, bo przed releasem jest
    paromiesieczny (dla srednio malego projektu) okres testowania. Wtedy sa tez
    kilka rund tzw user acceptance testing, podczas ktorych powinny byc naprawione
    wszystkie bugi wylapane przez zewnetrzych testerow. To sie nazywa user
    acceptance testing, bo dopoki nie sa naprawione wszystkie bugi kleint moze nie
    przyjac projektu, co bedzie roznowazne z uruchomieniem zespolu prawnikow,
    ktorzy ud..pia wykonawce w razie nienaprawienia chocby jednej literowki. Mniej
    wiecej w tym samym czasie sa tez testy niefunkcjonalne: m.i. ze skalowalnosci,
    wydajnosci, bezpieczenstwa i niezawodnosci (odpowiednie oczekiwania tez
    powinny byc zawarte w kontrakcie, a architekt jest odpowiedzialny za ich
    sensownosc). Dla zwyklych aplikacji biznesowych zwykle sie wynajmuje na dwa
    tygodnie odpowiednia ilosc serwerow w np jednym z HP Solution Centers i sie
    testuje: co sie stanie z aplikacja po 1,5,10,15... latach, co bedzie jak
    przewidziana liczba uzytkownikow skoczy z X do 100*X i tak dalej. Pelna
    dokumentacje z tego testowania przekazuje sie architektom klienta do
    akceptacji. Po zaakceptowaniu tego wiekszych problemow z wydajnoscia przez
    nastepne nascie lat nie powinno byc bo to ile zasobow potrzebuje aplikacja
    jest udokumentowane. Dla odrobine wazniejszych aplikacji, procz takiego
    testowania jest tez okres, gdy aplikacje nie jest jeszcze w produkcji ale jest
    na pilot environment.

    Nie masz tak we wlasnej firmie? Zmien firme.


    A.

    --
    Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

strony : 1 ... 4 . [ 5 ] . 6 ... 9


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1