- Android alkalmazások - szoftver kibeszélő topik
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
- Karaktere biztos lesz az első Nothing fejhallgatónak
- One mobilszolgáltatások
- iPhone topik
- Honor 200 - kétszázért pont jó lenne
- Samsung Galaxy A56 - megbízható középszerűség
- Ilyen lesz a Fairphone 6
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- EarFun Air Pro 4 - a cél a csúcs
Új hozzászólás Aktív témák
-
#11073
floatr
veterán
-Faceless-
#11072
floatr
veterán
válasz
-Faceless-
#11072
üzenetére
Na most javíts ki ha rosszul értelmezem, de te egy kifejezés kiértékelőt akarsz írni? Mert az azért nem annyira triviális... bár az amőba sem
-
floatr
veterán
Nyilván... hosszú éveken át használtam Eclipse-t az összes hülyeségét nem sikerült kiismerni, mert ez is olyan, mint a Skyrim - vég nélküli kihívások. Volt már mindenféle fizetős edition a kezem alatt, egyik rémesebb volt a másiknál. Azt gondoltam, hogy az IntelliJ tényleg tud mást letenni az asztalra, de ez valahol törvényszerű, hogy minél összetettebb valami, annál nagyobb hulladék. Egyik sem érdemli meg, hogy rajongótábora legyen
-
floatr
veterán
Ne fanboikodjunk, kérem
Nekem az idea a gradle projektektől térdel le, néha azt sem tudja merre van a projekt, a debug tool katyvasz, a docker integráció meg rosszabb mint a command line, a gitet teljesen hazavágja egy merge-el, mate környezet alatt elveszti a menüjét. De legalább amióta van egy vadiúj laposom, egész gyorsan elindul. -
floatr
veterán
válasz
togvau
#10991
üzenetére
Nézd nem mondom, hogy hibátlan a framework. Tele van apróbb hiányosságokkal, dokumentálatlan sok helyen, és a dobott hibák félrevezetőek.
De ha alaposan ismered, nem csupán a tutorialokat bújod, akkor fel fogod ismerni az alapvető összefüggéseket. A fenti lazy init probléma nem bug. Így működik a JPA, és ha a @Transactional használata problémát okoz, akkor nagyon gyorsan igyekezz elsajátítani, mert mint mondtam: alap.Az iménti kódrészlettel van egy baromi nagy baj, nem is csupán a paraméterek száma miatt. A query, amit leírtál, egy JPQL SELECT. Annyiban különbözik az SQL-től, hogy objektumokat kezel (többek között). A
p.user=?1nem a táblában lévő oszlopra vonatkozik, hanem a Photo entitás user adattagjára, ami gondolom User típusú. A JPQL nem long értéket vár, hanem egy User objektumot. Helyesen így lenne:select p.id from Photo p where p.user.id = ?1
feltételezve, hogy a user azonosítója az id nevű property, így lehetne Long paraméterrel hívni. A restricteddel az a baj, hogy feltételesen csapod a query-hez a criteria API-s implementációjával. Ilyet @Query annotációval nem lehet. Ott fixen meg kell adni a JPQL-t, amit nem módosíthatsz, magyarán:select p.id from Photo p where p.user.id = ?1 and p.restricted=?2
lenne a végső JPQL (ha el nem néztem még valamit).Ne ess abba a hibába, hogy a frameworkben keresed a bugot, miközben helytelenül kódolsz.
-
floatr
veterán
válasz
togvau
#10989
üzenetére
Relatív, hogy mi a csúnya
van egy interface a Data metódusoknak, meg egy custom implementációhoz, már ha kell egyáltalán.Annyit azért nem árt fejben tartani, hogy a @Transactional alap. Nem hozunk létre tranzakciót kézzel, nem nyitunk db kapcsolatot. EntityManager-t a legvéső esetben szabad csak babrálni. Helyette érdemes a projekciókkal csinálni, amit lehet.
-
floatr
veterán
válasz
togvau
#10985
üzenetére
Namost ez egy elég hosszú téma, de röviden itt van egy példa, ami alapján tudsz hozzácsapni összetetteb dolgokat egy JPA repo-hoz. Ezt most csak egy text editorban dobtam össze, de a lényeg itt van. Van egy JPA repository-d, amit a framework majd implementál magának. Kell egy új interface, amiben a saját új metódusaid vannak. Ezt implementálod egy külön osztályban, valamint az új interface-t hozzácsapod a JPA repo-hoz az extends-ben. Innentől kezdve a PhotosRepo típust injektálod be mindenhová, mert a Spring ez alapján készít saját implementációt.
// létrehozol egy inteface-t a saját metódusaidnak
public interface PhotosRepoCustom {...}// meghagyod a Spring Data repository-dat is, de hozzácsapod a saját interface-t is
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long>, PhotosRepoCustom {...}// implementálod az új interface-t
public class PhotosRepositoryImpl implements PhotosRepoCustom {
@PersistenceContext
EntityManager em;
public List<A> findAllCustom() {
....
}
}De a @Query annotációval használhatsz JOIN FETCH-et is egy query metódusban pl.:
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long> {
...
@Query("SELECT a FROM A a INNER JOIN FETCH a.b b")
public List<A> find();
} -
floatr
veterán
válasz
togvau
#10983
üzenetére
Amikor meghívod a lekérdezést a Repository metódusban, az elkér egy aktuális sessiont az EntityManager-től. Mivel lazy, azon a ponton nem oldja fel a hivatkozást, csak egy B proxy-t kap az A objektum. Amikor visszakapod A-t, a session már ment a lecsóba, és hiába hívod meg a gettert, a proxy már nem találja a session-t.
Na többek között erre is való a @Transactional, mert megmondja az EntityManager-nek, hogy hol kezdődik a session lifecycle. Ha nincs @Transactional, akkor a Repository metódusban kéne inícializálni a lazy relációkat. -
floatr
veterán
válasz
Taoharcos
#10979
üzenetére
Nekem az egyik projektben egy ideig két Oracle 10g adatforrásom volt beállítva v7-es driverrel ahhoz hasonlóan, ahogy a második példádban írják le. Nem kellett dialektust használni, viszont mysql-es példák alapján mindig belefutok ebbe. Kezdem én is hülyének érezni magam
-
floatr
veterán
Megszokás kérdése. Sokáig eclipse-et használtam, de kotlin miatt rá kellett szokni az ideara. Újabban vs code-ot is használok. Leginkább ez a két utóbbi talán a legjobb kompromisszum. Mindegyiknek vannak hülyeségei, de talán az idea és a vs code akadályoz a legkevésbé a munkában
-
floatr
veterán
válasz
Drizzt
#10943
üzenetére
Nincsen szükséged az IDE app server pluginjeire ehhez. Eleve el kell készíteni a deployment eszközöket, van remote debug, a pimpelt IDE csiricsáré funkciói meg igazából szépek meg jók, de maximum egy tapasztalatlan fejlesztőnek nyújt igazi segítséget.
Nem vagyok annak a híve, hogy szövegszerkesztővel kommandózzon az ember, de nincsen szükség egy ultimate-re ahhoz, hogy hatékonyan tudj dolgozni. Ellenben eltávolodsz az operations jellegű feladatoktól, és hajlamossá tesz arra, hogy kihátrálj minden olyan dologból, ami nem közvetlenül implementációs feladat. -
floatr
veterán
válasz
Drizzt
#10937
üzenetére
Őszintén...?
DevOps-os szemmel nézve nem is szerencsés az IDE ilyen szintű integrációja. Ha nem oldható meg egy jól definiálható pipeline/toolchain segítségével automatizáltan még lokálisan is, akkor megette a fene az egészet.
Mondanám, hogy VS Code + gradle FTW, de a Red6 annyira elcseszett most valamit a Java bővítményen, hogy szinte használhatatlan. Addig meg Idea CE... -
floatr
veterán
-
#10900
floatr
veterán
filomena98
#10898
floatr
veterán
válasz
filomena98
#10898
üzenetére
Már nem azért, de ha van egy java IDE kéznél, ez 5 perc alatt kideríthető.
-
-
floatr
veterán
válasz
bambano
#10819
üzenetére
Az eddigi hozzáállásod alapján inkább lehetne rólad elmondani, hogy szereted a scriptelést, és bármire azt használnál. Amíg 2 sorról van szó, még hagyján, bár ha abba kell beletúrni valamiért, továbbra is tartom, hogy kevés ember lesz, aki tartani meri érte a hátát. Nem egy 12-factor konform cucc, de mókolni jó.
Az üzemeltetéssel és karbantartással kapcsolatban éppen a scriptekkel van baromira rossz tapasztalatom többek között a minőségbiztosítás teljes hiánya miatt, és hogy az általad említett sok száz komponens nagyon nem mentes a hibáktól. Nem baj kavarjuk össze lecsóba, mi bajunk lehet.Azt nem vágom, hogy pont ezeknek a szenzoros dolgoknak a kezelése eléggé ingoványos terep, de te nyugodt szívvel rábíznád egy pipe-olt scriptre a dolgot, miközben szinte mindenki kivétel nélkül baromira óvatos a témával. Amíg otthon barkácsol az ember egy arduinoval két hőmérő meg három nedvességérzékelő adataival, addig még hagyján, csak akkor tartsa is otthon a "tudást".
Az meg eleve nagyon gáz, hogy "debuggolni" úgy akarsz, hogy módosítod a kódodat. Agyrém...
-
floatr
veterán
válasz
bambano
#10816
üzenetére
Annyira ne kapaszkodj már a szavakba, mert az eredeti felvetés annyi volt, hogy parsolni szeretne. Meg akar oldani egy problémát, amire létezik megoldás, nem is egy. Amit te javasoltál neki arra jó, hogy kézzel belökjön pár tesztadatot valahová. Egyik oldalon próbálsz ragaszkodni a "leírtakhoz" a másik oldalon meg "találgatsz". Ez tök jó, ha csak a vita kedvéért csinálod, bár már rögtön az elején megmondta, hogy köszi nem.
Nyilván 3 szutyok property beolvasására nem kell még DB sem, nemhogy teljes stack, sem sed, awk, meg majdnem szabványos reguláris kifejezések, de ha egy kicsit felnézel a billentyűzetből, akkor láthatod a céljait jövőbelátás nélkül.Ha vitatkozni szeretnél csak, akkor biztosan találsz mást a környezetedben, ha meg van érdemi mondanivalód, akkor azzal kéne folytatni.
A scriptedet lehet, hogy kidobod minden egyes változtatásnál, bár leginkább az ötletet kéne kukázni, mert semmi másra nem jó, csak egy éppen aktuális állapot kezelésére, ahol ha hiba van az awk/sed kifejezésekben, ott nagyobb gondban van egy harmadik ember, mintha egy konfigot kéne módosítani - feltételezem, hogy ért hozzá az ember, amit csinál, márpedig ez awk/sed esetében elég nagy szó.
-
floatr
veterán
válasz
bambano
#10814
üzenetére
Az ELK nem új. Van mire használni, leírtam, bár láthatóan nem sikerült beazonosítani a komponenseket. A logstash elég messze van a "ballisztikus rakétádtól".
Nem fog megállni a dolog egy property->insert trafónál, ezt nem akarod látni, nem veréb a célpont. A script nem két soros lesz, azt már most garantálom, nem rugalmas, nem használható tovább, csak egy darab script, ami szerencsés együttállásnál elég lehet workaroundnak. Rendszerszemlélet zéró. -
floatr
veterán
válasz
bambano
#10808
üzenetére
Az a baj a script ninjákkal, hogy mindig arra a feladatra koncentrálnak, ami az orruk előtt van. Ezt meg lehet oldani két sor scripttel, ja várj még mókolok rajta.
Szinte minden esetben, amikor egy ilyen kérdés felmerül, jönnek az újabb ötletek, és a végén te is tudod nagyon jól, hogy nem kötélhintát szeretne az emberünk, hanem komplett vidámparkot. Aztán abban a vidámparkban találd meg az egyes scripteket, amiket jó esetben a szerzője tud értelmezni. Tele van a padlás ilyen "szakemberekkel", akik indulatból oldanak meg mindent.az elastic maga az "adatbázis"
a kibana egy dashboard, amivel megjeleníted a méréseket, nyilván nem terminálon queryzgetve akarod nézegetni
a logstash a "pumpa", amivel tetszőleges forrásból, és formátummal betolod az adatokat, ha netán bejönnek új mérésekEttől függetlenül lehet scriptekkel gányolni
-
floatr
veterán
válasz
#68216320
#10806
üzenetére
Ez a formátum YAML-ként is értelmezhető, így egy YAML parser be tudja olvasni, és akkor nem egy igénytelenül gányolt shell-ninja szutyokkal oldod meg, amit 1 év múlva a saját szerzője sem tud már támogatni.
De van rá lényegében kész megoldás is: ELK stack. Azt pont ilyenekre találták ki. Logstash illesztőkön keresztül Elastic-ba tolja a szenzorok adatait, amit később Kibanával meg tudsz jeleníteni. Ezt a shelles babrálást meg felejtsd el
-
floatr
veterán
válasz
bandi0000
#10788
üzenetére
Egy rakat technológia frameworkje, jobbára nyúlás a kurrens "alternatív" frameworkökből. Ez mondjuk nem lenne baj, legalább ad neki egy standard keretet. A fájó igazság viszont az, hogy kihalóban van, és a "jobbik eset", amikor meglévő kód supportjára keresnek embereket. Amikor kerestem melót, a kapuban fordultam vissza, amint kiderült, hogy EE. Bár ez csak az én hülyeségem...
-
floatr
veterán
válasz
Szmeby
#10709
üzenetére
Ebbe most futottam bele teljesen véletlenül
@Getter@AllArgsConstructorpublic class MinMax {Optional<String> min, max;public static MinMax of(String[] arrayOfString) {var length = comparing(String::length);return stream(arrayOfString).collect(teeing(minBy(length),maxBy(length),MinMax::new));}} -
floatr
veterán
válasz
sztanozs
#10713
üzenetére
Már rég nem a sebességről szól a dolog
De ha már fun, akkor egy kis kihívás
Adott egy film (vagy bármilyen műalkotás), írjátok meg egy jellegzetes részletét Java-banDeathStar.getInstance()
.getGarbageMashers()
.stream()
.filter(gm -> gm.getLevel().equals(Level.DETENTION))
.forEach(GarbageMasher::shutdown); -
floatr
veterán
válasz
Szmeby
#10709
üzenetére
Alakul...
A végén szét lehet szerelni komponensekre, és lehet hozzá majd YAML konfigot írniA reduce a legegyszerűbb, de akkor hadd húzzak lapot 19-re
Arrays.sort(arrayOfStrings, Comparator.comparing(String::length));
String shortest = arrayOfStrings[0];
String longest = arrayOfStrings[arrayOfStrings.length - 1]; -
floatr
veterán
válasz
Szmeby
#10707
üzenetére
Szokás enterprise körökben túltolni a legegyszerűbb dolgokat is. Ha reduce helyett egy collectort használtál volna, no meg persze factory-kat, akkor lehetne kelteni kisebbfajta pánikot a juniorok között
Amúgy az első kérdésére csak egy reduce nem fog megoldást adni, vagy két streamet használsz, vagy egy collectorral párban gyűjtöd a min/max értékeket. De akkor meg minek...
Amúgy szerintem nincsen különösebb baj a streamekkel, amíg olvashatóan és ésszerűen van szervezve. A hármas operátort sokan nem szeretik, mert rontja az olvashatóságot. Én egyedül azt a gányolást utálom, amikor mindent be akarnak szuszakolni egy sorba. Na meg az enterprisify kódot
-
floatr
veterán
válasz
hefike
#10696
üzenetére
A legegyszerűbb megoldás: van két string változód (legrövidebb, leghosszabb), végigiterálsz a tömbön, és ha az elem hosszabb, mint a "leghosszabb" változóban tárolt érték, akkor azt viszed tovább "leghosszabb"ként. Hasonlóképpen a legrövidebbel
String[] arrayOfStrings = {...};
String longest = null,
shortest = null;
for (String s : arrayOfStrings) {
if (longest == null || longest.length() < s.length())
longest = s;
if (shortest == null || shortest.length() > s.length())
shortest = s;
}; -
floatr
veterán
De most komolyan, ez az "addig nyújtózkodj..." kezdetű nem játszik?
Használtam korábban már pár IDE-t. Visual J++ (nem röhög), JBuilder, Netbeans, Eclipse alap és fizetős változatai, IDEA, és mindegyiknek megvolt a maga baromsága az erősségei mellett. Voltak ingyenes és fizetős verziók, de egy idő után nekem mindig terhessé vált a "prémium" tudás. Halál komolyan a MS eszköze volt a legkezesebb eltekintve a kézenfekvő hátrányaitól a platformot illetően.Mostanában a VS Code-dal barátkozom, és azt kell, hogy mondjam le a kalappal a készítők előtt. No meg persze azok előtt is, akik hajlandók minőségi bővítményt készíteni hozzá. A legbrutálisabb az, hogy tudsz konténerben fejleszteni. Sok éve bohóckodnak vele páran, hogy a hagyományos IDE-ket bezárjanak dockerbe, de csak a felszínt karcolgatták. Az orion meg olyan se íze se bűze. VS Code alatt meg open folder in container, és olyan környezetet dobsz fel a projektnek, amit utána minden fejlesztőnél bitre pontosan lehet reprodukálni kattintásra. pöpec nagyon.
-
floatr
veterán
-
#10556
floatr
veterán
Aethelstone
#10553
floatr
veterán
válasz
Aethelstone
#10553
üzenetére
Attól még taníthatja...
Nekem is volt egy kollégám, aki inkább oktatni ment végül. Nem gondolnám h nem jól csinálja, bár nem tudom lecsekkolni -
floatr
veterán
válasz
disy68
#10517
üzenetére
Lehet, hogy neked a kontextus neked nem konfiguráció, nekem még mindig az, kezdve a legpitiánerebb dolgokkal, amit változtatni kellene egy production környezetben adott esetben. De ez a jó, hogy különbözőek vagyunk. Amúgy nem fétis, talán észrevetted, hogy egy kombinált megoldást említettem. Szerintem a Java config a típus-fetisiszták fertője
Olvashatóság tekintetében valóban jobb lenne egy JSON vagy YAML context definíció, de amikor kódból maszatol valaki, az agyhalál.A generált kóddal kapcsolatban rettenetesen álszent a hozzáállás. A hibernate és spring által generált 60 tonnányi (cglib, asm, miegymás) kód ok, a lombok @Getter/@Setter nem, hagyjuk már. A kotlin által generált JVM kód megint ok, bár többszörösen megerőszakolja az egész rendszert, de a @NoArgsConstructor/@AllArgsConstructor az csúnyarossz... vicc. Meg lehet nézni, hogy mekkora buglistája van ezeknek a rendszereknek már csak a kódgenerálás okán is, de attól nem félünk
Egy @Builder/@Getter annotáció átláthatatlan az osztály elején, de a húszmillió sornyi extra kód nyilván karbantarthatóbb, ha valami változik... Szerintem az a veszélyes, hogy ezt valaki nem meri használni. Ugyanaz a probléma, mint amikor az 1.5-ös iterációk és enumok tartották rettegésben az említett projektet. -
floatr
veterán
válasz
disy68
#10504
üzenetére
Ezt a tiltósdi dolgot nem annyira vágom miért kell... Voltam már olyan projektben, ahol az 1.5-ös fícsöröket tiltották, mindenki menekült, semmi értelme nem volt. Lombokot szerintem alapvetően pár olyan dologra érdemes használni, ami fordításkor generál le bojlerplét kódot. Ezen az alapon semmilyen nem Java JVM nyelvet nem lenne szabad használni. Amúgy is kényszermegoldás volt, mert a JCP board impotens nyúlbéla volt hozzá, az Oracle meg pénzt akart belőle kifacsarni, nem fejleszteni.
Az XML vs Java configgal kapcsolatban az a problémám, hogy a konfiguráció karbantartásához/módosításához kódolás kell, CI pipeline. Szerintem a legszebben megfogalmazott Java config is nehezebben átlátható, mint akár az XML. Egyik megoldás sem jó tisztán, nekem leginkább az XML+annotáció az, ami leginkább kezelhető.
-
floatr
veterán
válasz
disy68
#10500
üzenetére
Használtam már XML és Java configot is, de egy jól megtervezett struktúra és lombok használata mellett nekem: annotáció > XML > Java config. Utóbbi még üzemeltetési szempontból is aggályos
A tervezési hibával kapcsolatban meg lehet, hogy igazad van, bár ezzel szerintem csak akkor lehet hatékonyan megküzdeni, ha zöldmezős cuccról van szó.
(#10501) PeachMan én mindenképpen javasolnám. Nem árt ha mögé látsz, de nem attól leszel jó (junior) fejlesztő, hogy látod a biteket suhanni.
-
floatr
veterán
válasz
#68216320
#10480
üzenetére
A népszerűbb keretrendszerek azt a felállást támogatják, hogy Model + Repository/Dao + Service. Az ID kezelését egy alp perzisztencia motor is megoldja, és a Repository/Dao dolga a Model és adatbázis közti kapcsolat funkcionalitásának megteremtése.
Ezzel szemben van a domain driven design, ami az adatokat hordozó objektumnak adja a funkcionális részt is. -
floatr
veterán
Ja hát a split az teljesen gáz erőforrások tekintetében, de kreatív megoldásnak vicces
Menet közben rájöttem, hogy ha elé- és mögé vágok egy-egy mássalhangzót, akkor tökéletesen működik az is. De ha nagyon optimalizálni kell, akkor lehet elég elborult algoritmusokat írni, ami viszont már felveti az egész hasznosságát A reguláris kifejezésekről meg csak annyit, hogy volt már olyan h bekresseltettem böngészőket egy nagyobb szöveg parsolásakor, ha lehet kerülöm
-
floatr
veterán
Olyant is csinálhatsz amúgy, hogy egy stringbe betolod az összes magánhangzót, és indexOf metódussal ránézel. Ha optimalizálni akarod, akkor sorba rendezett karakterekkel logaritmikus kereséssel is mehet
Amúgy meg:
String text = ...; // a beolvasott cucc
long vowelCount = text.toLowerCase()
.chars()
.filter(c -> "aáeéiíoóöőuúüű".indexOf((char) c) != -1)
.count();
-
#10390
floatr
veterán
E.Kaufmann
#10385
floatr
veterán
válasz
E.Kaufmann
#10385
üzenetére
Konfiguráció tárolására sokkal praktikusabb a JSON vagy a YAML. Az XML túl terjengős, nehezebben is olvasható, és a kapcsolódó libek és alkalmazásaik is nyögve nyelősek. Én az SAML-nél vágtam eret magamon.
Nyilván ha az a feladat, hogy XML-el kell dolgozni, akkor az ember befogja az orrát, nyel egy nagyot, és csinálja De ha nem muszáj, akkor ne szívassad vele se magadat, se másokat. -
#10384
floatr
veterán
E.Kaufmann
#10383
floatr
veterán
válasz
E.Kaufmann
#10383
üzenetére
Ezt az XML-es témát lassan ideje lenne elfelejteni. Hacsak nem megkötés, akkor inkább JSON
-
floatr
veterán
válasz
axioma
#10355
üzenetére
Olyan diákból sosem lesz épkézláb szakmabeli, aki ennyire nem akar megcsinálni feladatokat. Teljesen mindegy milyen jegyet kap rá, magával cseszik ki. Ebben a szakmában pont nem a jegyek számítanak, hanem a hagyományos értelemben vett agilitás. Diákként magának kéne feladatokat kitalálni, nemhogy a kiadottakat is mással megoldatni
-
#10089
floatr
veterán
Aethelstone
#10088
floatr
veterán
válasz
Aethelstone
#10088
üzenetére
A kotlin igazából pont erre jó. Vegyesen is lehet használni, java fejlesztőket könnyű ráállítani, ha valami nem stimmel, viszonylag elég könnyű visszalépni. Nem is értem az ellenérveket. A legtöbb java projektet rá lehet állítani, hogy kotlint is használjon.
Amúgy meg annyira tök új, hogy 8 éves sztori már, és alaposan felhasználják a korábbi tapasztalatokat (java, c#, scala). Nem akarok kampányolni, csak kicsit értetlenül állok a jelenség előtt. Jó persze a megszokott, ha elég, de a technológia ebben az irányban menetel tovább.
-
#10087
floatr
veterán
Aethelstone
#10081
floatr
veterán
válasz
Aethelstone
#10081
üzenetére
Az a gond legtöbbször, hogy a költségvetésbe nem kalkulálnak bele ilyen tényezőket. K+F nuku, tanfolyamok semmi, tanulóprojektek zéró.
Ezen bukik sokszor el minden, mert képtelenek sokan tartani a szintet, csak a jól ismert dolgokat merik használni.
-
#10080
floatr
veterán
Aethelstone
#10079
floatr
veterán
válasz
Aethelstone
#10079
üzenetére
Ez egy rendkívül jó érv arra, hogy sose kezdj bele semmibe, ami eltér a szokásostól.
-
#10073
floatr
veterán
Aethelstone
#10069
floatr
veterán
válasz
Aethelstone
#10069
üzenetére
Nagyjából ilyen arányban találsz zöldmezős kontra legacy fejlesztéseket feladatképpen ezeknél a cégeknél. Melyiket csinálnád szívesebben?
Én '98 óta javazok, amikor még a trend sem nagyon látszott, nemhogy a piaci igény. A koltinban bőven van már perspektíva, ideje rájönnie sokaknak, hogy érdemes továbblépni. -
floatr
veterán
Végül is xterm/vnc is van, ha remote akarsz fejleszteni
de... akkor mire van a fejlesztői gép.
Mondjuk én ezt a maces őrületet sem értem. Nyilván jobban kézre áll az első hónapban egy windowsos környezet, de kicsit erőltetett dolognak érzem akkor, amikor már lassan minden az aws/docker/k8s és tsai körül forog.
Mindegy igazából ez a része, mindenkinek megvannak a preferenciái, csak megjegyeztem, hogy távolról sem optimális -
floatr
veterán
Van persze sok olyan ember, akinek ettől lesz adrenalin. De te is általánosítasz kissé. Sokan a "nagyobb tapasztalatukkal" azért nem hajlandóak az újabb technológia irányába mozdulni, mert lusták, rugalmatlanok, nem fektetnek R&D-be, vagy kivárnak, amíg mindenki elmegy mellettük
Nyilván sokéves rendszereket nem ír újra jellemzően senki, bár több olyan ügyfelünk is van, akik már 10 éves rendszereknél nem a polírozgatáson gondolkoznak. A bedőlés emberi tényező, de nem is ez a lényeg. Nagyon elment az igény az új technológiák irányába zöldmezősök esetében, és senkit nem fog érdekelni, hogy mi a véleményed az igényekről
Nyilván ez igaz visszafelé is, ha szerinted pl. a mongo jobb lenne content managementre, elastic meg monitoringra, de az ügyfél baromira liferay/sql párti, de szerencsére ez kopik kifelé.(#10042) mobal semmi, nekem is tök jól fut rajta a shadow warrior
(#10046) mobal lényegében virtuális gépeket használsz konténerek helyett, ami eltérően viselkedhet a production környezethez képest. Mert az feltételezem, hogy nem windowsos docker a live.
Akkor inkább már VBox-ban ubuntu/debian és azon docker. -
#10039
floatr
veterán
Aethelstone
#10038
floatr
veterán
válasz
Aethelstone
#10038
üzenetére
Állami megrendelők...
ne vicceljKomoly piaci szereplők, amikor szóba kerül, hogy állami megrendelők milyen követelményekkel állnak elő, körberöhögnek. Liferay... oracle... valami kakás MVC... eszement clusterek
Spring boot + kotlin vagy node + express, docker, mongo, react/angular, cloud, mobil app... ez a minimum, ha labdába akarsz rúgni. Az összes többi múlt idő, mint a lyukkártya
BTW amikor megemlítjük, hogy néhány fejlesztőnek windows-os gépe van, akkor is van mosolygás
-
#10037
floatr
veterán
Aethelstone
#10036
floatr
veterán
válasz
Aethelstone
#10036
üzenetére
Maradjunk annyiban, hogy mindenki menekül az EE környékéről, amióta kuka lett.
-
floatr
veterán
Az megvolt már, hogy az Oracle nem engedélyezte a "Java" név használatát az általa kukázott és az EF által széttaknyolt JEE projektjeiben?
Na eddig csak ásta a sírját a java-nak, de most elkészült a fejfával is.És a support plan is volt már...? Kínomban már csak röhögök
Ez miiii? Java 9 tavasszal megszűnik? Java 10 ősszel??? A Java runtime letöltései közt elsőre meg sem találja az ember a java 9-et. Marad a 8 talán 2020-ig, aztán bedől az is, mint minden, ami a Suntól jött?
-
#9710
floatr
veterán
Aethelstone
#9709
floatr
veterán
válasz
Aethelstone
#9709
üzenetére
Azért ennyire nem vészes a dolog. Első lépésben simán át lehet térni rövid idő alatt anélkül, hogy kotlin stdlib-et meg DSL-eket használnál. Később meg jönnek maguktól a specifikus részletek
Egy apróság, amin hümmögtem valamelyik nap. Spring Boot 2 HATEOAS controllernél javasolt módszer
linkTo(methodOn(this.getClass()).findById(1L))
elhasal valószínűleg implementációs hibával, mivel a methodOn egy proxy-t gyártana, ami nem megy final típusú paraméterek, visszatérési értékek esetében sem.
EzlinkTo(this::findById.javaMethod, 1L)
viszont tökéletesen működik, és a reflection is jobb, mivel a compiler oldja meg, nem a runtime név alapján. -
#9698
floatr
veterán
Aethelstone
#9696
floatr
veterán
válasz
Aethelstone
#9696
üzenetére
Az androidnak köszönhetően már most népszerűbb, mint a scala valaha
Eleinte egyébként nekem sem volt túl szimpatikus a dolog, mert valahogy javas fejlesztőként élből elutasítok minden gyanús alternatívát, de valamiért rávettem magamat, hogy nézzek utána, és elég meggyőző. Most kerül RC1-be a kotlin DSL-re épülő spring boot, kiderül h mit ér el. Talán a korral jár, de néha már fáraszt, ahogy újabb dolgok jönnek-mennek, de némi belátással el kellett ismernem, hogy ez túl jó ahhoz, hogy elsikkadjon. Én azt látom benne, hogy a javanak kellett volna ilyenné válnia.
-
#9694
floatr
veterán
Aethelstone
#9691
floatr
veterán
válasz
Aethelstone
#9691
üzenetére
Bármi lehetséges. Ez egyelőre csak most kezdődött igazán, és nem hiszem, hogy csak én látom a trendet benne.
-
floatr
veterán
válasz
bambano
#9675
üzenetére
Úgy vettem észre, hogy a tech giant-nek mondott cégek kifejezetten menekülnek az oracle dolgai elől. Ha körbenézel IDE fronton, akkor láthatod, hogy minden az eclipse és idea variánsokról szól, de feltörekvőben van a vs code a redhat-es java pluginjével. Sajnos vagy sem, senkit nem érdekel a netbeans, kiszorulóban van.
A szerver témában sokkal árnyaltabb a dolog, de ha már leírtad, hogy nem érdekel az EE, akkor én arra szavaznék, amire a google is letette a voksát: jetty. Nagyon sok fejfájást okozott nálunk a tomcat.
MVC: elég egyértelműen adódik a spring mvc vagy épp a boot. Többek közt amiatt is, mert a megfelelően társított egyéb spring projektekkel tökéletesen együttműködik, és megfelelő frontend technológiával brutálisan gyorsan lehet eredményt elérni.
De mondok még valamit, ami az oracle bohóckodásának köszönhető. Gyakorlatilag az összes nagyobb piaci szereplő elindult Kotlin irányba, pl a spring is. Kisebb projektekben próbálkozunk már vele JVM-re, és úgy látom, hogy át tudja venni a java helyét, és nem csak amiatt, mert licencelés tekintetében meg tudnak szabadulni az oracle marhaságaitól, hanem mert elképesztően hatékony de általános célú is. Itt és itt van két példa, ami talán magyarázza, hogy miért mondom ezt, de lehet h az is elég, ha megnézed a kotlin stdlib lehetőségeit. Nem mellesleg érdemes megnézni a kapcsolódó trendeket. A java fokozatosan veszít a népszerűségűből, miközben a kotlin iránti érdeklődés exponenciálisan nő. Pláne ha az oracle által lesajnált enterspájz fejlesztők rájönnek, hogy nem csak androidhoz jó.
-
floatr
veterán
válasz
Cathfaern
#9654
üzenetére
"A sales a következő eszközöket egyeztette a klienssel..."
"A projekt alapjait lerakó indiai fejlesztők már nem dolgoznak a cégnél"
"A kickoff meetingre meghívott PM, CEO és az ügyfelet képviselő közeli ismerős a következő stacket kéri..."Én eddig még nem láttam azt a sokat emlegetett mesebeli projektkezdést, bár én a sötét oldalon vagyok már jóideje. Az inkább működött, hogy addig fényeztem egy technológiát, amíg megjött az étvágya a kliensnek is hozzá - menetközben.
-
-
floatr
veterán
Szóval JSF, JPA meg mysql... A JPA nem bloatware? Az igazi profik JSP-ből SQLeznek direkt connectionökkel. Minek ez a nagy felhajtás a frameworkökkel?!
Kissé odaver ez a vélemény minden fejlesztési metodikának. Hidd el, nem poénból találták ki őket, egyszerűen csak az a gond, hogy a szoftverfejlesztések kis százaléka szól arról, hogy van egy tetszőlegesen kis scope, azt lefejleszted, aztán felejtős. Az igények változnak, a kódbázis nő, újabb modulokra van szükség, integrálni kell más rendszerekkel... és itt jön a cost of change görbe, ami egy ilyen hozzáállással pár lépés után az egekbe szökik. Az a vicc, hogy erre már a PHP Group is régen rájött
-
floatr
veterán
A kiindulási alap egy ilyen melónál a specifikáció, amiből teszt specifikációt kell készíteni, azaz hogy milyen kritériumokat kell teljesíteni ahhoz, hogy a rendszer/alkalmazás elfogadható, "átmegy a vizsgán". Ez több szintű lehet, kezdve a felhasználói kattintós tesztekkel, amit seleniummal automatizálnal, a web service-ek input/output ellenőrzésén át (pl. JBehave + rest assured), egészen pl a JMeter által futtatott tesztesetekig, amivel performance/load teszt indítható.
Egy ilyen teszt néha nem igényel konkrét fejlesztést, de úgy kell elképzelni, hogy programozottan küldesz bemenő adatokat a teszt tárgyának, aztán ellenőrzöd a végeredményt. Ez egy REST WS esetében annyi, hogy megadott paramétereket adott URL-re adott HTTP metódussal megfelelő headerekkel elküldesz, aztán megnézed a visszakapott válasz státuszát, tartalmát, méretét, headereit, válaszidejét.
Ezek mind olyan eszközök, amiket hetekig/hónapokig tanul az ember, a mérnöki feladatkörhöz meg általában egy adott témájú szakképzésre nem ért járni. Ilyen munkakörbe én egy szakirányú végzettséggel (akár tanfolyam) rendelkező embert keresnék, vagy egy olyan juniort, akit a munka tényleges kezdése előtt jó ideig képzek.
-
-
floatr
veterán
válasz
Froclee
#9544
üzenetére
"identitás-válság"
Amúgy hogy a nyelv maga mit tud, annak a megítélése erősen szubjektív, mert annotation processinggel széthekkelheted a javat, mint ahogy az is, hogy kinek milyen haszna van abból, ha egy bizonyos dolgot egy v többféleképpen lehet megoldani, vagy hogy 1-2 sorral kevésbé terjengős a kód.
Szerintem -- ha kíváncsi vagy a véleményemre -- már rég nem az számít, hogy egy megoldásban az implementáció milyen nyelvi bravúrokat képes felvonultatni; ez csak az elméleti része az egésznek. Sokkal fontosabb, hogy milyen ökoszisztéma az, amit fel tudsz köré építeni, vagy eleve adott hozzá, és ebben a java verhetetlen. Mert amikor jön a PM/PO megkérdezni, hogy "ez meg lehet csinálni?", felsorolsz neki 6 megoldási lehetőséget költségbecsléssel, akkor senkit sem fog érdekelni, még Bill szüleit sem, hogy 3 vagy 4 sorban írtad le, ponttal, nyíllal, vagy kínai írásjelekkel tarkítva, van-e vessző a sor végén, meg egyebek. Csak az az ember lesz tőle lelki beteg, akivel megcsináltatják végül.
-
floatr
veterán
A design jó, hiszen a legjobb helyekről nyúlták
De viccet félretéve, leszámítva a Visual Basic-es feelinget, rendben van az alapelképzelés, de nem design-válságról beszélek, amiben most épp a java készül elporladni.(#9542) mobal az indokláson van a hangsúly, de kétségtelenül jobb, mintha pascaloznának. Szvsz most kotlinnal kéne indítani, amit személy szerint utálok -- már a neve is ellenérzést kelt bennem, dinoszaurusz vagyok, elismerem -- de látom a trendet.
-
#9540
floatr
veterán
Aethelstone
#9538
floatr
veterán
válasz
Aethelstone
#9538
üzenetére
Erről beszélek, bár lehet h nem jött le
(#9539) emvy a c# születése óta identitás-válságban van, és az a legborzasztóbb, hogy ezt tanítják a suliban a gyereknek, mert "ez ingyen van"...
-
floatr
veterán
válasz
Lortech
#9534
üzenetére
Így van. Én tökre örülök, hogy végre megérkezett pl a hivatalos json binding így sok-sok év után
Talán ha elég sokáig áll az ember féllábon, akkor talán valami reaktív microservice specifikáció is készül a következő 10 évben. Illetve most már talán kicsit gyorsabban, hogy az ora legalább nem lábatlankodik az érdekeltek közt.Amúgy már rég nem az EE a mérvadó, csak kullog a trendek után.
-
floatr
veterán
Mérhető, ja. Win7 -> bubi 16.04 migráció nálam is kedvezett a liferay és tsainak, pedig még csak nem is erőltettem a dolgot. Máshogy gazdálkodik az erőforrásokkal, más bloatwarek vannak, más maga a runtime implementációja. Számomra nagy kérdés az is, hogy mivel fordítják a JDK/JRE natív részét. No meg persze az sem elhanyagolható, hogy fut-e antivirus/antimalware, ami windows-on már az alap installnál ott figyel; az is csillapítja a java eszeveszett száguldozását. Persze nem akarom a vitát ezzel gerjeszteni, de csak oda jutottam én is, hogy jobban jártam vele munkához.
-
floatr
veterán
A String egy nem változtatható (immutable) típus. Nem tudsz hozzáadni, nem tudod kicserélni a betűket. Ha összefűzöl/összeadsz két String-et, akkor a JVM létrehoz egy újat a kettőből. Ha ezt a műveletet sokszor végzed el, erőforrás-pazarló és lassú lesz.
A StringBuilder egy dinamikusan növekvő karaktertömb, aminek előre megmondhatod a kezdő kapacitását, mint egy puffer, aminek a mérete nőhet. Jó esetben nem is kell növelni, ha elég nagy puffert foglaltál le neki. Az összefűzést úgy kezeli, hogy a hozzáadott karaktereket egyenként pakolja a pufferbe, aztán a a toString() metódus hívásakor készít belőle egy végleges értéket.Ha konstansokat fűzöl össze összeadással, azt a compiler kioptimalizálja, de bizonyos esetekben helyettesíti StringBuilder-rel is.
-
#9436
floatr
veterán
Aethelstone
#9435
floatr
veterán
válasz
Aethelstone
#9435
üzenetére
rudeOrionk (#9434)
Amúgy meg 201 Core Java Interview Questions, if jú parlevú inglis. Ha állásra pályázól nem árt ezekkel tisztában lenned -
#9425
floatr
veterán
Aethelstone
#9424
floatr
veterán
válasz
Aethelstone
#9424
üzenetére
ja, welcome in 2005
-
floatr
veterán
JavaDoc [link]
A metódus visszatérési értéke a kulccsal korábban tárolt érték, vagy ha az nem volt, akkor null. A cast meg azért van, mert nem generics-es a map definíciója. Helyesen így lenne:
Map<Integer, String> newmap = new HashMap<Integer, String>();
...
String prevvalue = newmap.put(3, "is great");
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- MacBook Air M2 8/256 (GARANCIÁS!!! 2026.09.18.)
- Acer Nitro AN515-57 15.6" FHD IPS i5-11400H RTX 3060 16GB DDR4 512GB NVMe gar
- HP core i5-ös fémházas Folio 9470m kifogástalan állapotban!! AkciÓÓ!
- A legolcsóbb!!! Dell Latitude 6. gen. core i5-ös notebook olcsón!!!! AkciÓÓ!
- Olcsó Laptop! Dell Latitude 7280. I5 7300U / 8GB DDR4 / 256GB SSD
- Lenovo ThinkCentre M720q/ Dell OptiPlex 3060- 3070/ Hp EliteDesk 800 mini, micro PC-Számla/garancia
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Új Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 3 Év Garanciával
- BESZÁMÍTÁS! ASROCK B650 R5 7600X 32GB DDR5 1TB SSD RTX 3070 8GB MSI MPG Gungnir 100 Enermax 750W
- ASUS TUF Gaming F15 FX506 - 15.6"FHD IPS 144Hz - i5-11400H - 8GB - 512GB - RTX 3050 Ti - 1,5 év gari
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged