Eclipse ? (beszéljetek rá..)

Java

Hi,

A következő stack-et használom NetBeans-el úgy másfél éve.

-wicket (6.4.0)
-hibernate (4.1.3Final)
-spring (3.1)
-jetty (6.1.25)
-apache cxf (2.2.6)
-maven (3.0.1)
-svn 1.7.1

A NetBeans eléggé kézre áll nekem. Leszámítva pár hülyeséget hozza amit elvárok tőle.
A közeljövőben viszont egy Android-os projekt is kilátásban van, amire szeretnék rákészülni IDE illetve plugin-ek szempontjából is.
Itt, finoman szólva, látok némi lemaradást a NetBeans oldaláról.
Az Eclipse-el korábban már futottam egy kört, de picit megriadtam tőle, így a nb választottam inkább.
Most újra elővettem a témát, letöltöttem a juno-t és próbáltam a nb alatt meglévő dolgaimat működésre bírni. Nagyjából sikerült is, de komolyabban még nem mélyedtem bele (pl. napi szintű fejlesztés). Sok dolog szimpatikusabb az Eclipse-ben meg van ami érthető módon megszokás kérdése, de egyelőre elveszettnek érzem magam :). Két IDE-t nem akarok párhuzamosan használni :(.
Hitvitát indítok el tudom, de kíváncsi vagyok a véleményetekre.
Köszi előre is!

[update1]

Mondanátok olyan funkciókat, megoldásokat amit szerettek az Eclipse-ben ?
Ilyenekre gondolok, hogy jó nekem,mert a code editor xy shortcut-ra ezt meg ezt kitalálja nekem stb.

[update2]

Köszönöm mindenkinek a hozzászólást! Próbáltam a lényeget kiszűrni :). Ha időm engedi még nyüstölöm az Eclipse-t, de egyelőre maradok a NB-nél.
IDEA-t is megnéztem újra. Gyors, logikus, a jövőben szerintem szánunk rá némi aprópénzt.
Még 1x köszönöm!

  • 12226 megtekintés

( zsoltt | 2013. 01. 10., cs – 17:41 )

Az Eclipse egy gyűlöletes valami. Netbeans sajnos tényleg nem támogatott android oldalról, így kell kicsit tákolgatni, de szerintem megéri. Főleg ha megnézed az alternatívát...
Amúgy az android developer tools -nak a gui összekattingatós dolgai szintén nem sokat érnek, úgyis xml -ben fogsz szerksztgetni, úgyhogy nem maradsz le sokról.

Ok. Letöltöttem, kipróbáltam. Valóban elfogadhatóan néz ki minden configban állítgatás nélkül, valamint könnyen telepíthető. Kipróbáltam hogy beletöltöm egy githubon lévő projektemet, de sajnos azért nem olyan egyszerű az élet; a pom.xml fájlom nagyon nem tetszik neki. Majd még próbálkozom vele.

szerk:
Azóta sikerült. Ez a 12-es verzió elég okosnak tűnik.

A swinges felületek szerintem általában platformfüggetlenül rondák. :) Ennek két okát látom:

1. a platformfüggetlenség miatt nem igen támogatják az OS-ek natív megjelenítési lehetőségeit (már ami a szép, modern elemeket illeti). Vannak olyan Look&Feel lehetőségek, amelyek egész normálisan néznek ki, de tény, hogy mindegyik elavultan fest egy mai rendszeren. Az Eclipse-nél ezzel kapcsolatban egész jó munkát végeztek, de az nem is Swing (az SWT-s felületek általában egész jól néznek ki mindenhol).
2. mivel ad egy alap designt, és nem kell hozzá külső lib, azok a fejlesztők előszeretettel használják, akik inkább a programjaik funkcióira koncentrálnak a megjelenítés helyett. Ők pedig ráfogják, hogy "jó lesz ez így". Persze nem, de a fejlesztők már csak ilyenek. :)

Igen, és fordítva, a SWT -nek meg lehető legjobban eltávolodnia.
Más platformokon lehet hogy az Eclipse szebb, mint Netbeans, de ez kétes értékű győzelem. (nem próbáltam más platformokon Netbeanst, Eclipse -t viszont igen, windowson pl. ugyanolyan ronda mint bármi más, úgyhogy valóban jól belesimul... linuxon se sokkal jobb).

Az csak egy komponens a sok közül, de igen, az is hozzájárul. Nagyon el tudja rontani az ember munkakedvét egy-egy nem odaillő, fapados tool.
(Még mielőtt valaki félreértene: bash -t és command line toolokat szívesen használok, nem érzem egyáltalán fapadosnak, inkább praktikusnak. Nem ocsmányak. Az OSX Terminal.app -ja ráadásul kimondottan szép, nem tolakodó.)

én nem értem mi a baj a swinggel mi kéne szebb legyen egy szerencsétlen gomb vagy egy nyomorult szövegmező?? egyszerű benne megcsinálni akármilyen kis egyszerű alkalmazást és egészen komolyakat is szerintem király a swing. meg nem nézni akarom a programomat hogy nahh ez igen de szép MERt nem megyek vele semmire. Inkább szeretem használni mert az a haszna. ha rajtam mulna az awt is szép:D

Az ocsmány eléggé szubjektív, szerintem pont az NB csúnya. :) Viszont nem hiszem, hogy bármelyik is lenne annyira randa, hogy emiatt ne lehessen használni. Én is szeretem a szép alkalmazásokat, de néha van egy kompromisszum, amit meg kell kötni (tartalom vs. forma tekintetében).

A felületét sem tartom átgondolatlan összevisszaságnak, ám abban igazad van, hogy van pár dolog, amit lehetne jobban elrendezni benne.

Lassúság: az általad leírtak közül ezt tartom az egyetlen olyan tulajdonságnak, ami a "gyűlölet" érzését belőlem is ki tudja váltani (de ez minden programra igaz). :) Valóban vannak olyan műveletek, amik sokáig tartanak az Eclipse-nek, ráadásul ez néha egyáltalán nem indokolt (vagy nem tűnik annak). A napi használat során a legtöbb feladat viszont értelmes idő alatt elvégezhető. Azt pedig ne felejtsük el, hogy egy borzasztó komplex valami (nagyméretű Java-alkalmazások rákfenéje elég gyakran), de cserébe nagyon sok mindent tud, és elég jól kibővíthető mindenfélével. Ennek sajnos az az ára, hogy kell alá bizonyos méretű vas, de ez is inkább akkor, ha nagyobb alkalmazásokat fejlesztünk vele.

Az utóbbi időben a sebessége egészen szépen fejlődött, bár a Juno e tekintetben szerintem is kissé visszalépés, jó lenne ha a feature-lapátolás helyett ezzel a nyűgjével sokkal többet foglalkoznának.

Összegezve: több dolog van, amit jobban meg lehetne benne csinálni, viszont rendkívül rugalmas, és nagyon jól testre szabható.

( wachag | 2013. 01. 10., cs – 17:58 )

Én Eclipse-t használok (a NetBeans-nek elég fura hibái voltak nálam), a Juno CDT állítólag elég vacak, megmaradtam Helios-nál.
Egyébként megnöveltem az Eclipse által felhasználható maximális memóriaméretet, és így vígan elfut, pedig elég vad C++ kódokat írok rajta (a Boost érdekes ilyen szempontból :-) ).

( lx | 2013. 01. 10., cs – 19:43 )

Használj eclipse-et, különben száj- és körömfájást kap a disznótok!

( uid_4263 v | 2013. 01. 10., cs – 22:10 )

A maven -t visszakézből szántsd fel és hintsd sóval a helyét, majd próbáld ki a gradle build eszközt (hacsak nem függsz valami miatt a Maven -től. Maven -es dependency repókat a Gradle is beépítve kezeli). Elképesztően szebb, tömörebb és okosabb a Groovy -ban írható build scriptje. Mi ráadásul Ant -ról váltottunk rá, ami egy fokkal még jobb a Maven -nél.
Bocs ez off volt. :)

--
http://neurogadget.com/

Bár a Maven -t csak szükségből használtam néha, elrettentett a build fájl böszmesége. A deklaratív szintaxis miatt nem csak óriási a build fájl esetenként, hanem a "zaj" is nagy a szószátyárság miatt. Tehát a build fájl még csak nem is hasonlít valami "programhoz", amit az ember szeret nézegetni, hanem egy igen böszme XML, amiben egy okos editor / parser vagy jó gyakorlat nélkül könnyen elveszik az ember.

Ez nem a deklaratív - procedurális jelleg miatt van, de így néz ki 1 db függőség definíciója:

Maven:
http://pastebin.com/qJBvLCVs

Ant (Ivy):
http://pastebin.com/81uFxAA6

Gradle:
http://pastebin.com/PTJ7EU9Z

Tehát az Ant az én szememben azért jobb valamivel, mert procedurális "jelleggel" lehet írni, ezért jól tömöríthető. A Gradle meg ugye űrtechnológia mindkettőhöz képest.

--
http://neurogadget.com/

A verbosity-vel kapcsolatban igazad van, de ne felejtsük el, hogy azért egy Maven nem pont ugyanarra való, mint az Ant (a Gradle-t nem ismerem), emiatt is nem build fájlról beszélünk Maven alatt (így nem csoda, ha nem hasonlít egy programhoz). Viszont editor nélkül tényleg macerás karban tartani, ebben csak kicsit segítenek a template-ek, az automatikus generálás.

Ez hozzaallas kerdese. Mavenben nem build programot irsz, hanem build configot. En pl.: inkabb a sajat kodomat szeretem irni, nem a build scriptet/kodot. A build csak mukodjon es ne kelljen hozza csinalni semmit, max configolni.

Masreszt a config jelleg lehetove teszi, hogy 3rd party toolok tudjak ertelmezni a buildet. Ez egy programnal legalabb nehezebb, ha nem lehetetlen (ant).

Egyebkent miert erdekes, hogy nagy a pom.xml? Elfer. Raadasul egy tipikus projektben valszeg ugyis multilevel van, ahol egy (vagy tobb) parentbol orokli a config tulnyomo reszet egy gyerek modul es csak a kulonbsegek vannak a gyerek pom-ban. Es mar nem is hosszu.

Ez tök mellékes, mert egyrészt én nem mondtam, hogy nem támogatja, másrészt nem ez volt a hozzászólásom lényege. Hanem a különbség a build config meg a build script között. Ha neked ez jön be lelked rajta. Számomra a gradle disznó (ant+ivy) rúzzsal (mvnből vett funkciók, amiket groovy script hajt meg).

+1

Csak hogy kezdetben ne menjük messze az eredeti kérdéstől, az Intellij IDEA mindig is élen járt az új technológiák/eszközök támogatásában. Így van ez a gradle esetében is.

Mivel sok más dolog mellett kezdtem el a projektjeimben használni, menet közben csipegettem fel az éppen szükséges infókat a használatához. Nekem nem volt könnyű, de ha a maven-re és xml-jeire gondoltam, akkor mindig újult erővel tudtam folytatni :-)

( CrushTestDummy | 2013. 01. 10., cs – 22:41 )

Ha már Spring van nálad előtérben akkor az Eclipse-alapú Springsource Tool Suite szerintem kézenfekvő választás. Én a Grails-es változatát használtam, a Springsource elé jó támogatást nyújt a saját termékeihez.

Ha viszont van egy kis pénzed, az IntelliJ Idea a megoldás. Pont.

kiegészítése becses irományodhoz:
Spring Source Toolst használok jómagam. Két verziót lehet jelenleg letölteni belőle; az egyik az Eclipse Juno 4.2-re épül, a másik a Junu 3.8-ra. Gyenge gépen nálam a Juno 4.2 használhatatlanul lassú, úgyhogy ha performancia problémája lenne a topik inditójának vele, tegyen a egy próbát a 3.8-al.

( Nyosigomboc v | 2013. 01. 11., p – 01:57 )

Szerintem ne felj tobb IDE parhuzamos hasznalatatol, nem olyan nagy problema.
Az Androidos fejlesztest az Eclipse nagyon kenyelmesse tudja tenni, a Netbeanst meg hasznalhatod arra, amire eddig is. Gondolom egyszerre ugysem foglalkozol csak 1 projecttel, akkor meg a memoriat sem foglalja.

--
akkor most free tibet vagy delete tibet a jó?? - falu

( ssikiss | 2013. 01. 11., p – 08:58 )

Lenyűgöző hogyan ingadozik ebben a topic-ban a leírt információ a bullshit és a hasznos közt egy hozzászóláson belül is.

NB-t rövid ideig, kipróbálás erejéig pár napot használtam, Eclipse-t napi szinten kb. 8 éve használom. Meg kell nézni, hogy a te használati esetedre milyen környezetet lehet összehozni vele és összehasonlítani, hogy milyen különbség van hatékonyság terén a kettő közt. Ez egy-két nap alatt nem derül ki, és aktívan fel kell fedezni a környezet által nyújtott lehetőségeket. Utána el tudod dönteni, hogy mi jobb neked.

Minél többet :) Semmiképp nem elég végignyomkodni, mert az első tapasztalatból úgyis az szűrődik le, hogy nehezebb kezelni mint amit megszoktál korábban, hiszen dolgok máshol vannak, problémákat máshogy tudsz megoldani, van amit látszólag nem is lehet megcsinálni, pedig de, csak meg kell ismerned a pluginkínálatot, utánajárni hogy hogy lehet dolgokat megcsinálni, stb.

Szerintem az eclipse egyik legnagyobb baja és előnye is, hogy nem egy kész megoldást kapsz, ami mindenre jó, hanem kapsz egy nagyon moduláris valamit, amit úgy lakhatsz be ahogy akarsz. Az pedig elég nagy falatnak tűnik ha csak le akarsz ülni és fejleszteni.

Meg tobbfele plugin ugyanarra a dologra... en egyszer bongeszgettem az Eclipse pluginkinalatat, es nem igazan volt egyertelmu, hogy mit mire.

Aztan ott volt az a problema is, hogy rengeteg feloldhatatlan fuggoseg volt, ami miatt bizonyos plugineket nem tudtam felrakni, ami nelkul meg nem tudtam hasznalni a cuccot. Mindez a core repon belul. Egy hetnyi konstans szivas utan feladtam. NB repoiba legalabb minden fuggoseg a helyen van, ha nem tudnad a plugint felrakni, meg sem jelenik.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( hrgy84 | 2013. 01. 12., szo – 14:46 )

En is IntelliJ-t javaslok. A NetBeans-nel is jobb, es hidd el, hogy megeri az arat. Ha munkahoz kell, erdemes megpedzegetni a fonoknel, nem venne-e meg, egy ceg szamara annyira nem veszes az osszeg, plusz leirhassa.

En NetBeans-rol valtottam at minden projektemet IDEA-ra. Ma is megbujik a gepemen a kis kocka, neha elinditom, hogy frissen tartsam, mert van 1-2 dolog, ami miatt meg kell, de nagyon minimalis.

Szokni kell, ez teny, de a tudasa szerintem meg az Eclipse-nel is jobb. Es latszik rajta, hogy olyanok fejlesztik minden moduljat, akik hasznaljak is oket. Nagyon logikus az egesz cucc.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( asch v | 2013. 01. 13., v – 16:03 )

Eclipse

Java? Csak Javára vonatkozik, amiket írok. CDT és egyéb változatait nem használom.

Lassú? Induláskor valóban néha kicsit kell várni. Viszont munka közben pillanatok kérdése a szerkesztés teszt futtatása kör. Konfigurálás nélkül működik az is, hogy ha debuggolás közben átírsz egy metódust, akkor azonnal érvényre lép (ilyesmit lehet vele csinálni: http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-progr… ). Ezt jól használva óriási hatékonyságot lehet elérni. Az összes forráskód be van cache-elve, így név, vagy hivatkozás alapján bárhova pillanatok alatt lehet ugrálni a kódban. Majdnem 10 éve használom. Az akkori verzió az akkori gépemen is meglepően gyors volt, mai gépeken pedig szinte soha nem kell a gépre várni. Érdemes SSD-re tenni mindent, így lesz igazán villám a rendszer.

Sok memóriát eszik? Egy példány sok forráskóddal simán elfér 1GB RAM-ba. A fejlesztői gépedben ennyinek kell lenni erre a célra.

Pluginek? Nagyon régen átálltak az OSGI plugin architektúrára. Mindenképpen érdemes megismerni ennek a felépítését, mert sokat lehet tanulni belőle, hogy hogyan kell sok különböző modul együttműködését megtervezni.

Bővíthetőség? A teljes Eclipse felhasználható saját termékek készítéséhez. Nagyon sokat lehet nyerni prototípus készítésekor ezzel. Például saját template nyelv fejlesztése színezős editorral együtt kb 1 hét volt, és évek óta boldogan használjuk.

Verzió? A 4-es sorozatban még nem vagyok biztos, hogy jó irányba indult el. A 3-as sorozat utolsó kiadását érdemes használni még egy ideig szerintem.

"Sok memóriát eszik? Egy példány sok forráskóddal simán elfér 1GB RAM-ba. A fejlesztői gépedben ennyinek kell lenni erre a célra."

#define sok forraskod. Hany LOC? Probaltal megnyitni benne, mondjuk egy Glassfish, vagy egy oVirt forraskod fat? Mert nalam az jelenti a "sok" -at. Gyanitom, hogy nem egy gigat fog enni.

"Mindenképpen érdemes megismerni ennek a felépítését"
Minek? Hogy egy IDE-t hasznalhassak? Hol relevans ez, ha letoltok egy plugint, az mukodik vagy nem mukodik. Fuggetlenul attol, milyen architekturaban fejlesztettek.

"A teljes Eclipse felhasználható saját termékek készítéséhez"
Ebben nem kulonbozik a NetBeans-tol.

Nem sok ervet hoztal, ami az Eclipse mellett szolna... Ha nem lehet ugyanolyan elmenyre szamitani, mikozben tamogatott verziok kozott frissitek, hat... erosen meggondolom a hasznalatat. Ezert kezdtem el peldaul a NetBeans-nak is helyettest talalni, menet kozben tortek darabokra a Ruby tamogatast.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

15K+ sor hosszú java fájl első megnyitásánál kicsit gondolkodik, utána már nem.
Nagyobb forráskódfa is csak a workspace-be importáláskor ill. első nyitáskor várakoztat kicsit.

Egyébként nem tudom mit vártok, miért is lenne valamelyik IDE jelentősen és általánosan kiemelkedő a többihez képest? Ekkora "csodák" nincsenek. Inkább csak ez vagy az valakinek jobban kézre áll, vagy kényelmesebb eszközök vannak éppen ahhoz, amire használni szeretné. [captain obvious] Van, aki az egyik hülyeségeivel tud együtt élni, van aki meg a másikéival.

Pedig létezik olyan programozó, aki ilyen hosszú forráskódot ír egy fájlba. Tapasztalatom szerint nem is olyan kevés van ilyen, nem csak Java területen, nem csak zárt, nem csak kereskedelmi területen, és nem csak rossz/kezdő programozó által elkövetve.

Itt ragadnám meg az alkalmat az Eclipse nagyon jó outline, kereső, ugrabugra, refactoring, kódgeneráló, stb. funkciói reklámozásához. :D

Ha glassfish-t használó alkalmazást fejlesztesz, akkor nem kell a glassfish, elég csak a bináris jar, és hozzá kell include-álni a forráskód jar-okat, és ctrl+fájlnév-vel
megnyitja. Ha mégis szükséged van rá, tessék venni egy 8 gigás memória modult a gépbe, kemény 10 ezer forint.

Az eclipse plugin infrastruktúráját azért érdemes megismerni, mert könnyen lehet hozzá pl. syntax highlight-os plugint fejleszteni, amire a fent említett szerzőnek szüksége volt. Nem kötelező, nem kell a használatához, csak hasznos tud lenni, ha eclipse-re építesz saját terméket, mint ahogy sok cég teszi. Valószínűleg okkal van.

Ha pedig Ruby nyelven akarsz fejleszteni, akkor lehet, hogy számodra nem a legmegfelelőbb, de ez nem az eclipse hibája, ami alapvetően java fejlesztésre van kitalálva, és van hozzá még valamilyen szinten, általában közösségileg támogatott egyéb (python,cpp,ruby, etc.) nyelvi support is. Néhány amit találtam:

http://en.wikipedia.org/wiki/Aptana : eclipse alapú
http://en.wikipedia.org/wiki/RubyMine : idea alapú
http://en.wikipedia.org/wiki/Eric_Python_IDE : qt alapú

Nem feltetlen sorrendben reagalok:

- En mar megtalaltam az IDE-met, koszonom szepen, de nem kell tanacs.
- Nem gondolom azt, hogy az Eclipse csak Java fejlesztesre van kitalalva. Eleg altalanos IDE-nek nez ki a felepitese ahhoz, hogy tenyleg barmit meg lehessen vele csinalni. Es ugye nem szabad elfelejteni, hogy a CDT es a PDT nagyon sikeres termekek (nem szolva a PyDev-rol, ami kvazi standard a komolyabban Pythonnal foglalkozok kozt), tehat ez eroteljesen cafolja azt, hogy csak Java fejlesztesre lenne valo. Legfeljebb te arra hasznalod - viszont ez itt irrelevans.
- Az ember altalaban nem az alapjan valaszt fejlesztoi kornyezetet, hogy mit kell meg fejleszteni hozza, hogy hasznalhato legyen. A legtobbunket a munkahelyen bosegesen eleg munkaval latjak el ahhoz, hogy ne jusson ido/szandek arra, hogy akar egy syntax highlight plugint is lefejlesszen az ember. Van, aki hobbibol, a szabadidejeben ilyet csinal, mert kepes ra, de ha valaki IDE-t keres maganak, eszembe nem jutna olyat ajanlani, ami a felsorolt parametereknek nem felel meg, foleg ilyen sarkalatos kerdesben, mint a syntax highlight.
- Es csak info: nem olyan egyszeru jo syntax highlightert fejleszteni, mert a syntax highlight nem er ott veget, hogy a print kekkel lesz beszinezve, hanem ebbe igencsak oda kivankozik a kodkiegeszites, a forrasfa indexeles, meg a refaktoralas is, nem veletlen, hogy az igazan jo syntax highlight pluginok nem 1-2 nap alatt keszulnek el. Mert ha csak szines, de az IDE 80%-at nem tudom hasznalni a kodnal, akkor feleslegesen eszik akarhanyszaz megat az az IDE. Sublime-hez millio kis syntaxer van, es nem mellesleg kevesebbet eszik.

A Glassfish egyebkent csak pelda volt, arra voltam kivancsi, mekkora forraskod faval merted azt az 1GB memoriahasznalatot, mi az, amit te "nagy" -nak tartasz. Nekem van egy otmodulos Maven projektem, egy kezdo szamara hatalmas program, pedig alig all tiz fajlbol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Oké, asch a következőt írta:

"mindenképpen érdemes megismerni ennek a felépítését, mert sokat lehet tanulni belőle, hogy hogyan kell sok különböző modul együttműködését megtervezni."

Erre írtam, hogy és tényleg, ha véletlen ilyet kell csinálnia az embernek, akkor milyen jó, hogy ezt már mások kitalálták. Nem azt, hogy neked, mint XYZ fejlesztőnek
erre van szükséged.

Az eclipse nálam most 743 megát eszik, 200 megányi forráskód + könyvtárak.

Az OSGI pluginek deklaratív leírási módját, illetve a hozzá tartozó tervezési mintákat szerintem azért érdemes megismerni, mert az informatika komoly jelenlegi problémáira - komplexitás, dependency hell, újrafelhasználhatóság - megoldás javaslatot ad. A konkrét szintaxist nem, de az elveket más nyelveken is lehet és érdemes használni. Én sokat tanultam belőle, úgy érzem. Néhány nap böngészést és gondolkodást megért.

A syntax highlighterben, amit fejlesztettem pont az volt a poén, hogy a meglévő Java syntax highlighter és kódkiegészítő mellett lehet használni viszonylag kevés problémázással. Tehát ez egy kiegészítés saját igény kielégítésére, éppen annyi funkcióval, amennyi kell. A munka oroszlánrészét az Eclipse csinálja. Pont ez a jó benne.

Tehat akkor most a Java nyelvhez irtal kiegeszito highlightert, vagy uj nyelvhez?

Mert felek, hogy pl. egy vb.net highlighter kifejlesztese nem egy rovid darab lenne. Abban semmi java-szeru nincs ugyanis.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( zamek | 2013. 01. 14., h – 12:31 )

Szinte borítékolni tudtam volna, hogy vallásháború lesz a vége. Mindenki foggal körömmel védi a vélt, vagy valós igazát, ráadásul szerintem nem leszel okosabb tőle.
Jobban jártál volna, ha rászánsz néhány órát és kipróbálod, majd célzott kérdésekkel jössz.

Hogy én is mondjak valamit: ha nem tudod, hogy szükséged van rá, akkor nincs rá szükséged!
Szerintem ne divatból dönts! Ha a próba után felsorolod a pro és kontra érveket, hamarabb eredményre fogsz jutni.

A kategórikus kijelentések (x szar, csak y-t használd) - akárcsak a politikában - igen veszélyesek, érdemes fenntartással kezelni őket.

( sfeher v | 2013. 01. 15., k – 09:46 )

Köszönöm mindenkinek a hozzászólást! Próbáltam a lényeget kiszűrni :). Ha időm engedi még nyüstölöm az Eclipse-t, de egyelőre maradok a NB-nél.
IDEA-t is megnéztem újra. Gyors, logikus, a jövőben szerintem szánunk rá némi aprópénzt.
Még 1x köszönöm!