Hirdetés
Köszönjük a sok biztatást, támogatást! Utolsó pillanat a féláras hirdetésfeladásra, előfizetésre!
Új hozzászólás Aktív témák
-
btraven
őstag
Nem. A repo létrehozást.
Most én a github-on csinálok egy üreset.
git clone
majd ebbe az új könyvtárba másolom a libgds által generált cuccokat
és azt commit+pushmost újra csináltam, az előbb 2 branch lett, main meg master, én se tudom hogy
és mindez azért mert valaki sérelmezte a master nevet
legalább büdösnigger lett volna, akkor még érteném -
#68216320
törölt tag
Nem tudok Android appot készíteni sajnos. Szóval valami free megoldás volna jó erre. A rest már rendben lenne spring-ben, még tokenezgetni sem kellene, mert teljesen lokális hálón lenne a dolog. Szóval nem volna bonyesz.
Viszont az android oldal teljesen off nekem.
Esetleg az olvasóra volna ötleted? -
dudikpal
senior tag
Végül csak ez lett a nyerő. Szuper, mert eddig nem is tudtam, hogy létezik ilyen egyszerű módja a bonyolult queryzésnek.
Igaz volt 1 kis pitty-putty, mert 2 napig szenvedtem az EntityManager behúzásával (, és amikor sikerült, akkor jöttem rá, hogy én Mongoban vagyok, ahhoz meg nem ez kell, hanem MongoTemplate, amit csak beinjektálok, és kész.
De csak nem megy kárba a dudás, mert közben beütött a felismerés, hogy élesben meg MariaDB lesz...sose lesz kész
-
btraven
őstag
Nem tudja valaki véletlenül hogy libgdx-ben hogy lehet megadni hogy egy Stage/viewport csak a képernyő egy részét használja?
Például van egy 1920x1080-as képernyőm. Egy térképet csak a bal felső részen szeretnék megjeleníteni. Persze ez a térkép zoomolható, scrollozható. Az lenne jó ha csak egy 1500x700-as területen dolgozna, és nem rajzolgatna a többire. Most az egész képernyőt használja, akármit csinálok. Fit/Fill/Stretch/ÖsszesViewPortot próbáltam már.
lwjgl-ben olyan szépen lehet szeletelni a képernyőt. Egyik részen 3D, a másik részen 2D, tetszés szerint. -
btraven
őstag
1.9.14-gyel indult a projekt. Csak belefutottam egy hibába ami a 15-ben javítva van állítólag. Közben máshogy(jobban) sikerült kikerülni. Nincs kedvem feleslegesen upgrade-elni. Így is van bajom elég. Mindig elkezdek egy kis játékprogramot írni hogy na gyorsan összecsapom, aztán már játszhatok is vele. Aztán egy év után még mindig nincs kész a "kis" program.
-
floatr
veterán
https://docs.spring.io/spring-session/reference/http-session.html
Amúgy nem tudom, miért erőlteti a security-t ennyire. Az Acegi sosem volt praktikus, és még most sem tudták használható formába gyúrni. Erre a célra max egy cache-t használnék egy-két metódusra kötve, nagyjából ennyiben ki is merülne a "session" funkciója. Igazság szerint a session is csak egy cache, aminek a kulcsát adja-veszi a frontend és a backend
-
btraven
őstag
-
floatr
veterán
Jópofa tud lenni, de sokszor bevisz a málnásba. Pl van egy Function<Double, Double> metódus referenciád, amire - talán nem közvetlenül - a DoubleUnaryOperator-t ajánlja kicsit agresszívabban a kelleténél, mert hát ugye sokkal specifikusabb. Csakhogy annak a paramétere double, amire minek figyeljen a sonar, merthát az apróság, de streamben már használhatatlanná is vált
-
#11436
Aethelstone
addikt
mobal
#11435
-
Lortech
addikt
Nagyon beakadt ez az XML. Így pár száz maven projekt és modul (és jópár plugin megírása) után azt tudom mondani, hogy az XML-t éreztem a legkevésbé problémásnak a mavenben. Csak a felszínt karcolgatod.
Én sem szeretem az XML-t különösebben, de nem érzem problémának, mert ha mavent is használ a projekt, ez nem jelenti azt, hogy egész nap ezt kell hegeszteni az egész fejlesztő cspatnak, nem olyan fajsúlyú kérdés, mint mondjuk egy frontend template, amiben egész nap hegeszt a fél társaság. A kezdeti project setup után kb. heti rendszerességű, hogy a buildünk változik, leginkább új dependency vagy verzió update miatt, ami teljesen automatikus és fájdalommentes változtatás, bármi érdemi változás ennél ritkább.
Most megnéztem egy kisebb-közepes projektet, van kb. 20 pom.xml össz. 150KB, aminek a 90+%-a copy paste-elt <dependency>, nincs mind module submodule viszonyban, tehát nem mindenhol van öröklődés, ezért a viszonylag nagy méret.Nem XML alapján döntünk, hogy maven vagy gradle.
Saját döntési szempontok:
-mi a probléma, amit meg akarunk oldani, mit kell tudnia a buildnek és mit akarunk azon kívül kezelni.
-van-e bármi nem szokványos körülmény, amiért testre kell szabni a buildet, kell-e egyedi plugint írni hozzá, ez a néhány fajsúlyosabb probléma viszi el az idő 90%-át általában.
-hol fog futni, hova és hogyan kell illeszkednie, mivel kell integrálódnia, gondolok itt meglévő projektekre, IDE-re, teszt keretrendszerre, futtatókörnyezetre, CI/CD-re, konténerekre stb.
-karbantarthatóság, mennyire egyszerű bővíteni, vagy teljesen átalakítani
-olvashatóság, átláthatóság: pl. a konvenciók, ha ismered őket, sokat segíthetnek egy projekt megismerésében egy új résztvevő számára, míg a flexibilitás, hogy kódot tudsz írni a buildben, nem mindig előny, ha a fejlesztő csapat tényleg elkezd nagy mennyiségű kódot beleütni a buildbe.
-várható fejlesztői élmény, pl. mennyire egyszerű vele belőni a fejlesztői környezetet, milyen a tooling támogatás
-megoldás erőforrás igénye (esetleges traininggel együtt)
egyszerű használni, mennyire gyors, kiszámítható és problémamentes
-csapat meglévő kompetenciája, tanulási görbe, community, dokumentáció
-megoldás várható performanciája, ha nagyobb a projekt és számít bármit
...
...
és valahol itt egy kilométerrel lentebb van az, hogy XML-e -
#11426
Aethelstone
addikt
mobal
#11425
Aethelstone
addikt
Ha "Groovy / Kotlin dsl gradle file" ilyen van a listában, akkor ide tényleg nem jó a maven
A Spring Boot alkalmazásokra, yaml fájlokra, java konfigokra teljesen jó
De tényleg zárható, pro és kontra el lehet sokmindent mondani, egyéni preferencia kérdése. Azzal viszont tökre nem értek egyet, hogy a maven őskövület lenne....
-
Szmeby
tag
Voltam olyan projekten, ahol már már megszállottságig fajult az új dolgok megtanulása. Hetente cseréltük le a félig magunkévá tett libeket valami fancy újra, és integráltuk bele az alkalmazásba újra és újra és újra, mindig volt valami hot topic. Brr. Na de ez a másik véglet. Talán nem kell mondanom, az alkalmazás elkészülte folyamatosan csúszott. Talás sose készült el, már nem vagyok ott, hogy ezt megtapasztalhattam volna.
Nekem annyit adott az a projekt, hogy megtanultam a világ túl gyorsan változik, hogy minden újat meg akarjak tanulni - nem is lehet - és elveszi az időt az értelmes dolgokban való elmélyüléstől. Persze megértem, hogy másokat meg csak az újdonság érdekel, és nem zavarja őket az a sok zaj a fejükben, aminek a felére holnap már senki sem emlékszik amúgy, mert csak hype volt körülötte. Azt meg végképp nem tudom hova tenni, ha valakit az alapján ítélünk meg (el?), hogy mavent vagy gradlet használ, neadjisten antot. Ha neki ettől jobb, váljon egészségére.
Vagy menjen és vezesse le a feszkót maven irtással, addig sem zavarja a terméken dolgozó népeket. 
Amúgy utálom az xml-t, és szeretem a mavent. Há!
-
Drizzt
nagyúr
Alapvetoen van, de elsosorban business case-ekhez kototten. Meg igyekszunk mindig uj dolgokat behozni, ha hasznos, vagy hosszan tarto megoldast adhat. De nalunk mindenki erosen devops/automated tester/data magus is egyben, s legkevesbe izgalmas/lenyeges resz az egeszben a java build. Nyilvan a magussal tuloztam, de inkabb a szeles tudas az, ami nalunk a fokusz, nem pedig a reszletekbe meno tudas egyes alteruleteken.
-
Drizzt
nagyúr
Ha keresztbe-kasul ismersz valamit, s atlagban egy problemat 3mp megoldani neked benne, akkor nagyon nyomos erv kell ahhoz, hogy lecsereld valami masra, amiben ugyanez a folyamat a kompetenciad hianya miatt eltartana vagy 1 napig.
Nalunk minden regi es minden uj projekt is maven, szimplan azert, mert van par emberunk, aki nagyon ert hozza. Ok tenyleg kb. 5 perc alatt a legkomplexebb projekteket is atlatjak, mig Gradle-hez nincsen ilyen emberunk. A build time meg nem kritikus.
Persze lenne haszna gradle-zni, legalabb lenne eselye kialakulni benne mely kompetencianak. Ha ma kezdenek Javazni, biztos azzal kezdenek. Igy viszont, hogy teljesen otthonos terep a maven, foleg ezt hasznalom, itthon is. Volt projekt amit gradle-lel kezdtem, de semmi nem vitt ra utana, hogy a kovetkezot is azzal csinaljam. Van boven mas szakterulet, ahol tobb hasznot hoz a raforditott tanuloido.
-
Szmeby
tag
Vannak bizonyos allami projektek, ahol elvarjak, hogy az ember rendelkezzen ezzel, vagy legalabb plusz pontnak minosul.
Nekem sokat segitett abban, hogy jobban megertsem a java furcsasagait, azokat a nuansznyi jellegzetessegeket, amivel az ember vagy egyszer az eletben talalkozik, vagy ugy megszokta mar, hogy fel se tunik neki. De ehhez mondjuk nem feltetlenul adnek ki soksok penzt a vizsgara, mert megtanulni ezeket ingyen is meg lehet, ott a java tutorials weboldala vagy mi a tokom a neve, minden info ott van szepen. Fake tesztekbol is Dunat lehet rekeszteni, ha valaki teszelni kivanja magat.
Jol mutat de hat na. Sok eve mar, hogy megcsinaltam, de ha az ember nem talalkozik azokkal a problemakkal, elfelejtodik, ahogy altalaban a dolgok az eletben. Es akkor megint ott vagyunk, hogy mindenki ahhoz ert a legjobban, amivel aktualisan foglalkozik.
-
togvau
senior tag
tehát nem lehet így. Ezt én is megtalátam.
Nem értem miért nem fejlesztik a JPQL-t is, vannak minden DB-ben működő, de JPQL-ben nem létező funkciók. Ez a találat limitálás tól-ig is ilyen. Van ahol "LIMIT" van ahol "TOP", de ugyan az az implementáció elintézné...Pár hónapja egyébként ilyen hibernate hackel raktam bele a GROUP_CONCAT-ot (amit szintén szinte minden DB tud, ez esetben a H2 is, csak JPQL-ben nem volt ilyen):
public class SqlFunctionsMetadataBuilderContributor implements MetadataBuilderContributor {@Overridepublic void contribute(MetadataBuilder metadataBuilder) {metadataBuilder.applySqlFunction("group_concat", new StandardSQLFunction("group_concat", StandardBasicTypes.STRING));}}
Aztán ment pl:...dto.Photolist(p.user.id, GROUP_CONCAT(p.id)) FROM Photo p WHERE p.user.id IN ?1...Lehet itt is kipróbálom... majd munkaidőben -
Csaby25
őstag
Szia.
Ok leírom röviden. Volt rá lehetőségem, hogy elvégezzek egy gyorstalpaló tanfolyamot, 6 hónap, heti 2 óra... Java, React és .NET közül a Java-t választottam. Nem sok idő, de elég volt arra, hogy felkeltse az érdeklődésemet, szeretném tovább fejleszteni magam, egyelőre tetszik a backend, de úgy gondolom, hogy még nem rendelkezek, annyira ismerettel, hogy el tudjam dönteni, hogy mozduljak - e frontend irányba vagy sem. Sajnos csak Java SE-vel fogalkoztunk, EE csak említve volt. Egyelőre szeretném befejezni a San Franciscóból jöttem tanfolyamot, illetve a a Udemy-ről ezt: [link]
Majd szeretnék egy nagyobb projektet készíteni amit be lehet mutatni egy állásinterjún.
8 órás állás és két gyerek mellett sajnos nem tudok úgy haladni ahogy szeretnék...
Bármilyen ötletet - tanácsot elfogadok ami segíthetne ebben.
Gondolom ha frontend akkor Android, vagy ott mér inkább a Kotlin-t részesítik előnyben?Bocsi , ha egy kicsit hosszúra sikerült.
Köszi!
-
Drizzt
nagyúr
Nekem se volt még vele sose ilyen probléma. És nálam is meg van nyitva vagy 5-6 Spring microservice, 2-3 JavaEE app, meg néhány devops repo állandó jelleggel. Maven mind. Mondjuk amúgy a maven részét annyira nem szeretem az IDEA-nak, bár összehasonlítási alapom nem nagyon van, mert mást 10+ éve nem használtam(Javara).
-
floatr
veterán
Alapvetően nem lenne rossz, de...
Leszámítva az apró kis hm... sajátosságait mostanában eléggé bosszantó, hogy napi szinten 3-4 alkalommal hullik darabokra. Ilyet régebben még az eclipse sem csinált a legrosszabb pillanataiban sem.
Egyetlen dolog van az ideaban, ami tényleg tetszik, az a lambda-kezelés és a kapcsolódó code assist. Érdemes figyelni a VS Code-ra, mert nagyon jön fel, hónapról hónapra fejlesztik. -
floatr
veterán
Nem demagóg... dogmatikus
Nem tartom haszontalannak a sonart, de az esetek egy részében mondjuk úgy, hogy fals pozitívat jelez. A múltkor már csak röhögtem kínomban. Szokott olyanokat jelezni, hogy szerinte másképpen kéne megoldani valamit. Addig kavarta több lépésen keresztül, amíg a kód fordíthatatlan lett.
A DTO-val kapcsolatosan meg napi szinten tapasztalom, hogy kezelik az emberek. Semmivel nem lesz tőle biztonságosabb a kód. Egyszerűen csak kérdezd meg magadtól, hogy tényleg szükséged van-e rá. A dogmatikus válasz az, hogy mindig szükség van rá, mert meg lett mondva. A racionális válasz az, hogy pl máshogy reprezentálod az adatot API verziónként, ezért kell.
-
axioma
veterán
A szorny nem fuggvenynel volt hanem matrix-implementacional (amit aztan nem hasznalnak). A legvegen igy is, ugy is maradt raw type hozzarendeles, de azert hogy 1 helyen legyen nem 2 helyen (kb, lehet hogy 3-4), ettol bevezettek a rekurziv definiciot es ket type parametert... (hogy osszekossek a matrixtipust meg a utilities tipusat, holott a matrixtipus futas soran egyszer, config-bol olvasodik fel).
A fuggvenyre kedvenc peldam a Gauss-eliminacio. Azt szetszedve en biztos kevesbe ismernem fel, a korrektseghez 5 parameteresen lehetett volna a belso fuggvenyt kiemelni (kettot member-bol szamoltunk vegul), de nem lehet egy fel kepernyonyi (vizszintesen, meg nem mondom de biztos <50 LOC) fuggveny, mert tul bonyolult. Az hogy normalisan elnevezni a belsejet nem lehet, az nem baj. Az hogy egy csomot lassit egy azert hoztuk letre hogy jobb legyen sebessegben mint az ApacheCommons, az nem baj. Csak hogy jo alacsony legyen a bonyolultsag, es egysegsugarunak is oda lehessen adni (akik amugy per def nem is dolgozhatnak ebben a csapatban). DE ez az eset, amire azt mondom, hogy a kivetel ami erositi a szabalyt, es egy programozo tudja mar hogy mi az hogy Gauss-eliminacio. A tobbsegeben egyetertek azzal, hogy bontsuk le a hosszu fuggvenyeket.
Az mar egy masik kerdes, hogy ne ugy bontsuk le hogy veszunk 3 altalanositott szornyet, es a sajat sub-task-unkat nem is oldjuk meg csak felparameterezzuk a mar keszet, elotte-utana heavy konverziokkal, de mind1, mert az me'g egy sor csak a stream-ben... kozben picit odafigyelve a 2 oda-vissza megoldhato 1-bol (most egy Date meg Instant dologrol beszelek, az egyik kulso adottsag, a masik belso kenyszer mert kell a het napja).
De kb. egy eve talaltak olyan bottleneck-et, hogy mindenhol az ID nyersen ment tovabb, es minden egyes lepes kulon parsolta ki belole a neki kello reszt (mondjuk az se egy jo design ahol az id darabolhato, me'g ha van ilyen kulso forras is, de belul mi a feneert nem egybol lenyegitik at a kesobb hasznalt reszeire. -
axioma
veterán
En tobb dologban nem ertek egyet a sonarlint-tel, de ettol me'g orulok hogy van, mert neha egyszeru teveszteseknel felhivja a figyelmet a potencialis hibara.
A baj az amikor kotelezove teszik az osszes sonarlint hiba javitasat, es olyan szornyek keletkeznek, hogy az mar nem konnyiti hanem neheziti a megertest. Mert azt megertem hogy a sonarlint celja olyan szintre levinni a fejlesztes szinvonalat hogy egysegsugaru programozo is kovetni tudja, de ez minden csak nem hatekony, ha nem egysegsugaruakkal csinalod amugy a projektet.
Nyilvan SZVSZ. -
floatr
veterán
A legjobban az tetszik, hogy a sonar oldalán lévő leírás és javaslat is tele van agyatlan anti-patternekkel. Sajnos a sonar tele van hülyeséggel, nem véletlen, hogy meghagyták a lehetőségét annak, hogy kikapcsolj egy-egy szabályt
Ha DTO-kat gyártasz akár rétegenként, akár microservice-enként, akkor plusz konverziós lépéseket teszel a kódba potenciális hibaforrásokként. A leggyakoribb az, amikor egy fejlesztő erre rá van kényszerítve, hogy gépiesen átdobálja az adatokat, néha konvertál típusok közt. Komplexebb lesz a kód, és semmi nem teszi biztonságossá abban az irányban, amit a sonar szabályban és a linkjeiben -- leginkább csak -- sugallnak. A mintakód félrevezetően gyatra, hűen tükrözi a témakörben gyakori ultragagyi minimalista tutorialok szellemét. Nem ment semmi és senki automatikusan, ellenőrizetlenül, validáció, autentikáció és access control nélkül, pláne nem a Controllerből, ha publikus endpointról van szó. Ha microservice-eket használunk, akkor meg egyenesen hiba eltakarni egy újabb réteggel az adatokat pl az api gateway elől. Hasonló okokból teljesen feleslegesnek tartom az OpenSessionInView filterrel kapcsolatos felindulásokat.
A leggyakoribb érdemi oka annak, hogy DTO-t vagy projekciót kell használni, az szokott lenni, hogy teljesítménybeli optimalizációt kell csinálni, így bizonyos lekérdezéseket view-ra specializáltan kell implementálni, vagy mert a frontend nem tud mihez kezdeni összetett adatokkal. Esetleg az api gateway összegyúr két service-ből származó adatot, de az meg szvsz tervezési hiba, ha erre kényszerült rá valaki.
Egy esetben látom még a létjogosultságát a DTO-szerű képződményeknek, ha az Entity/Document bloated lenne egyébként. Ez meg szubjektív.
Nem kell, hogy egyetértsünk, de a dogmatikus kijelentések teszik tönkre a szakmát.
-
-
disy68
aktív tag
Csak zárójelben. Én egy junior tréning programmal kezdtem egy multinál annó, ahol volt egy gyakorló feladat, ahol kvázi excel jelleggel kellett tudni kezelni cellákat (a cellának lehetett konkrét értéke vagy más cellákra is referáló függvénye). Ekkor futottam bele, hogy java 8-as verzióval bekerült a Nashhorn nevezetű Javascript Engine a JRE-be, amivel elég egyszerűen lehetett kiértékelni az egyszerűbb műveleteket. A js engine JVM byte-kódot generál. Nem használnám production-ben, pláne, hogy a 11-es verzióval deprecated, de érdekes volt, hogy van ilyen is.
-
2017-ben kezdtem pti-t levelezőn, de az elvárás meg van, viszont tanítani kb semmit se tanítanak. Közben az élet úgy hozta, hogy 1év passzívra kellett tennem magam, ezért most a webleren keresztül webmesternek tanulok. Nem légből kapott ötlet ez, csak magamtól nem minden világos és ezért gondoltam ilyenre is.
-
axioma
veterán
Hat, reszben ertek egyet. Marmint a gondolkodasmodot onmagaban nehez egy ilyen tanfolyamon megszerezni, de az az erzesem hogy ezek a cegek pont azokat probaljak felvenni, akiknel mar van valami analitikus/algoritmikus gondolkodas, arra epitik ra a konkret programozasi tudast, processzt.
Tehat annak javasolhato a tanfolyam, akit amugy is erdekel, kozel all hozza ez a fajta munka (nem a penz miatt), van alapja (mintha csak diplomaval vagy annak kozeli multtal vennenek fel), es hajlando a tanfolyam honapjait csak erre forditani (nem csak esti muszakban tolja at a sajat melojat hogy ne utkozzon, hanem adott esetben este is nekiall kodolni). Ha ez megvan, akkor szerezhet junior szintet, bar nekem nagyon fura hogy miert fullstack-eznek, akkor feluletesebb, mindenbol kevesebb tudas/gyakorlat lesz.
Egyebkent van olyan ismeros aki elegge mas iranyu diplomaszerzes korul vegigcsinalt egy progmat felvetelit, ahhoz ugye info erettsegit (bar asszem kozepszint eleg volt neki), epp halaszt de gondolkodik egy ilyen tanfolyamba atugrasban. Es me'g ot se biztos, hogy felvennek. Szerintem - most meg plane - van annyi jelentkezo, hogy aki bejutott, arra mar igaz lehet hogy eleg valoszinuen kepes lesz junior lenni a vegen. De ez nem azt jelenti, hogy aki kitalalja hogy kiprobalna, az fel ev mulva kesz junior.
Persze tevedhetek en is, de ezzel a felteteles moddal egyutt en hihetonek tartom mar. -
OK, csináltam egy handlert, amit szépen meg tudok hívni a statikus thread-ekből, megkapja a message-t is. Merthogy a handler is static kell legyen, különben nem lehet meghívni.
De mivel static, még mindig nem lehet belőle meghívni egy toast-ot......amint leírtam, elkezdett működni. A getcontext() hiába nem tetszik az IDE-nek, működik :S
-
Két külön probléma volt.
Van egy Activity-m (Android), ami indít 2 szálat (kamerához, Bluetooth-hoz, és ezek külön classban is vannak). Egy bajom az volt, hogy nem tudtam, hogyan kell meghivatkozni a másik szálban levő metódust (azaz hogy a kamera szál által feldolgozott kép alapján adatot küldjek BT-n). Ez már megy.
Ehhez a BT szálat (is) statikussá kellett tenni. Viszont így meg nem tudom, hogyan lehetne toast-ot küldeni az UI-ra, mert az Activity nem statikus, (nem is lehet az) így aztán a RunOnUIThread nem igazán működik. De akkor hogyan lehet? :S -
Ez már megy, de köszi
Egyszerűbb volt : két static class között szépen lehet hívni (simán meg kellett hivatkozni class.metódus formában, és megy). Ott akadtam el, hogy az összes RunOnUIThread-os toast-ot ez kiüti, mert static classból a nem static MainActivity-t kéne elérni. Ezt hogy lehet áthidalni? -
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. -
Nem.
Nem igazán van rá szükség, az elkészült képeket kell feldolgozni.
Valószínű amúgy azzal van gond, hogy mintha nem várna a CountdownTimer-en kívül semmi, csak pörögne a while, vagy ilyesmi, a kamera meg nem tudna mit kezdeni a kérésekkel (nem tudom jobban megfogalmazni).Amúgy kb. ennyit kéne helyettesíteni while (feltétel); -lel. Kb. tutorialokból vadásztam össze
new CountDownTimer(96000, 6000) {public void onTick(long millisUntilFinished) {Log.d("Iterate", "seconds remaining: " + millisUntilFinished / 1000);camera.takePicture(shutterCallback, null, null, jpegCallback);}public void onFinish() {Camera.Parameters param;param = camera.getParameters();param.setAutoWhiteBalanceLock(false);camera.setParameters(param);thefirstiteration = true;}}.start(); -
walgud6
tag
Konkrétan az érdekelne, hogy melyik típusra érdemes beruházni.
Néhány szempont:
- könnyű hordozhatóság, mert sokat ingázok
- Ne csak 1-2 évig legyen elegendő az erőforrás fejlesztésre
- hosszú üzemidő (eddigi ismereteim alapján, ez nem probléma egyik modellnél sem)
- Java fejlesztésre használnám leginkább, talán local db is futna rajta
A hordozhatóság szempontjából a 13"-os modellek a nyerők, viszont itt meg is állt a tudományom. Kicsit utánaolvasva a témának, annyi lejött, hogy azért kisebb erőforrásal is hoznak olyan szintet, mint nagyobb erőforrású win-es gépek. Az viszont nem tudom, hogy Air vagy Pro, mennyi RAM-al, SSD-ből gondolom a 128-as is elég (külső HDD orvosolja a helyhiányt). Windows-os üzleti gépekkel van tapasztalatom eddig, ott a 16GB RAM szerintem elvárt, local db+ IDE + böngésző néhány tabbal + DB nézegető + egyéb apróságok.
Szóval összefoglalva, szükséges a Pro vagy az Air is elegendő, kell a 16 GB RAM vagy 8-al is vígan el lehet lenni?
Köszi a válaszokat!
-
bambano
titán
"nem tudom elképzelni mondjuk, hogy egy szerver alkalmazás szét legyen dobva 10 futtatható binárisra és egymást hívogatják": oké, legyen egy egyszerű példa: biztonsági mentés.
tegyük fel, hogy a következő lépéseket akarod végrehajtani a mentéshez:
1. mentendő fájlok listájának előállítása
2. mentendő fájlok összecsomagolása egy konténerformátumba
3. konténer tömörítése
4. konténer lemezre írása.windowson erre van egy backup utility, monolitikus, felparaméterezed, fut. unixon mindegyik feladatra van egy program, és a programokat össze tudod kötni a shellel.
1. find
2. cpio
3. bzip
4. ddtehát azt mondod, hogy (a kapcsolók nem biztos, hogy jók):
find -atime 5 / | cpio -o | bzip2 -9 | dd of=/dev/rmt/0 obs=2k
A find összeszedi neked az összes fájlt, amit kevesebb, mint 5 napja néztél meg és a fájllistát kiírja a szabvány kimenetére. A find szabvány kimenetét a shell összeköti a cpio szabvány bemenetével (valójában úgy mókol a fájldeszkriptorokkal, hogy a find kimeneti puffere a cpio bemeneti puffere lesz, tehát nem a shell másolgat soronként, hanem ez kernelszintű szolgáltatás). A cpio a szabvány bemenetéről beolvassa azon fájlok nevét, amit az archívumba bele kell tennie és az archívumot kiírja a szabvány kimenetére. Ami átkerül a tömörítő bemenetére, tömöríti és kiírja a saját kimenetére. Amit megkap a dd, összeblokkosítja olyan méretre, ami a szalagegységnek optimális, majd kiírja szalagra.
Minden darab külön van, minden darabot cserélhetsz is, ha akarsz. Minden darab egy konkrét feladatot végez el. Gyakorlatilag kapsz egy kosár téglát és ebből neked kell házat építeni. Ez az erőssége és a gyengesége is egyben. Ha tudsz kosár téglát egymásra rakni, jó rendszered lesz. Ha nem, üres konzol előtt fogsz pislogni, mint kocsonyában a béka. A másik világban pont az ellentéte van, kapsz pár 14 emeletes toronyházat, amik elvileg mindent tudnak, amiről az alkotójuk azt hitte, hogy tudniuk kell. Vagy megfelel számodra, és akkor halleluja, vagy nem, akkor bukta van. Nem változtathatsz, nem babrálhatsz bele, ez van, ezt kell szeretni.
Egyébként nagyon sok ilyen szoftver van, például az adatbáziskezelőknél is gyakori, hogy van egy nagyobb program, ami a szerverfunkciókat végzi, és vannak kis, parancssori utilityk, amikkel aktiválsz bizonyos funkciókat vagy beállításokat. ezekből rakod össze a megoldásodat.
-
bambano
titán
"Full komolyan érdekel, mikor jó a 10k soros bash a javával szemben": akkor jó, amikor egy nagyobb rendszerben történő folyamatot akarsz automatizálni, és ehhez parancssoros segédprogramokat adnak csak. fontos, hogy automatizálni akarsz, tehát nincs képernyő, grafikus interfész, klikkelés. van viszont mondjuk 200 darab bináris programod, amivel meg tudod oldani a problémád részfeladatait.
ilyenkor a jáva program nagyjából úgy nézne ki, hogy folyton parancssori paramétereket rak össze, exec()-el, eredményt olvas, stb. ehhez felesleges jáva. pont jó a szkript.
egy csomó telepítő meg karbantartó szkriptet láttam már, amik ilyenek voltak.
-
bambano
titán
"akkor linuxon mindent írjunk szerinted bash-ben": nem.
a fő különbség a két rendszer között (unix vs. windows), hogy a unixot eredetileg kis programok hatékony összekapcsolására találták ki, a windows meg nagy monolitikus rendszerek futtatására. pl. ha windowson elindítod az outlookot, a fél office-t maga alá rántja, mert ha a levélben van excel vagy html, akkor máris behúzza az excelt meg a html motort.unixon ezzel szemben az az alapvetés, hogy kis programokat csinálsz (amikor csak lehet), azok egy dolgot csinálnak, de azt hatékonyan és jól, és rábízod az oprendszerre, hogy összekösse a programjaidat.
ezért amikor elhangzott itt (nem Peachmantől), hogy a szenzor program tegye le diszkre egy fájlban az adatot és azt olvassa be jávából LINUXON, akkor azt gondoltam, hogy ezzel totálisan szívenszúrja a unixos alapfilozófiát. kevésbé udvarias megfogalmazásban ekkora f.ságot évek óta nem hallottam.
tehát itt a unixos filozófia szerinti megoldás az, hogy van egy szenzorleolvasója, van egy átalakítója meg egy adatbáziskliense, amiket a shell összeköt:
sensorread | sed ... | mysql ...
ha ezt el akarjuk rontani az itteni kérdés szintjére, akkor is az a megoldás, hogy jávában a szabvány bemenetet olvassa és azt elemzi, és csővezetékkel kerül a bemenetre az adat:
sensorread | java -jar szenzorosztalyom.jar"Cserébe nem lesz olyan lassú.": értem, tehát a bash egy pártíz-párszáz soros szenzor kimenetnél lassú lesz? kizárt. ráadásul ugye itt nem is a bash fut sokáig, mert az csak összeköti a programokat, falusiasan fogalmazva bűvészkedik a fájldeszkriptorokkal, a sok olvasást, írást egy c-ben megírt, évtizedek alatt optimalizált kód fogja csinálni a sedben. nem lesz lassú, ne aggódj, nagyjából bármit el fog verni, mint az atom. az interpretált bájtkódodat szinte biztosan rommá fogja verni.
Egyébként én csak húsz éve foglalkozom hasonló kérdésekkel, nyilván tapasztalatlan vagyok a témában, szemben pár fórumtárssal a fotelből...
-
Drizzt
nagyúr
Persze hogy nem. De az mas kerdes, hogy erdemes-e, illetve miert. Az esetek nagy tobbsegeben akkor is kell refaktoralni, ha amugy a kod jo. Pl. ha jon valami olyan uj feature, vagy meglevo modositasa, ami a refaktoralas eredmenyekeppen sokkal egyszerubb lesz, dinamikusabb, kivulrol konfiguralhato, vagy neha epp fixebb, merevebb. Nem veletlenul van tele a refaktoring katalogus olyan lepesekkel, aminek az inverze is benne van. Az egesz refaktoring az agilehoz hasonloan azert terjedt el es lett fontos modszer, mert az it ipar rajott, hogy feature stability szinte semmilyen realis szoftverfejlesztesi projektben nincs.
-
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.
-
Lortech
addikt
Az emlitett reszletek (single thread pool) nelkul nem oldja meg a problemat, a felteves az volt, hogy van ket async task, tehat a szal inditas megvolt, a kolcsonos kizaras volt a kerdes, amit az executorservice onmagaban nem old meg.
Legegyszerubb fapad megoldas elhangzott, 2-3 threadnel teljesen ok egy kozos eroforrasra lockolni. Ha nem nagyon gyors lefutasuak a szalak, ebben az esetben jobb sorbarendezni a futtatasukat. -
Drizzt
nagyúr
Ezzel az állítással alapvetően nem értek egyet. Mert az ExecutorService egy interface, ami arra van, hogy taszkokat lehessen aszinkron módon futtatni. De alapvetően arra semmilyen garancia nincs, hogy milyen sorrendben fussanak azok a taszkok le, illetve hogy melyek ne fussanak egyszerre. Ha az ember single threaded executort használ, az már valóban megoldást adhat a problémára, mint ahogy itt van rá példa. [link]
De önmagában az ExecutorService interface semmit nem mond a mutual exclusivity-ről. Épp az az interface célja, hogy a taszkok feladását ütemezés független módon engedélyezze.
-
bandi0000
nagyúr
most lehet rosszul értelmeztem a leírását, de ez nem arra van hogy csak összegyüjti a taskokat és egymás után elindítja?
Mert nekem össze vissza vannak a taskok, mêg azt meg tudom oldani, hogy belepakoljam őket, de mindenhol meg kellene hívnom az executot mert biztosra nem tudom, hogy melyiknél kell futtatnom őket
Bár lehet félreértelmeztem
-
#10639
E.Kaufmann
veterán
mobal
#10638
E.Kaufmann
veterán
Köszi! Biztos később az lesz, de addig is jó móka html generáló progit írni nulláról
, de még az se biztos, hogy a webes felület lesz a nyerő, ez csak egyike a megjelenítési formáknak, lehet, az lesz a vége, hogy egy egyszerűbb droidos felülethez kell majd egy primitív http konnektor. -
-
axioma
veterán
Nem az a bajuk, de most varjunk egy kicsit mert a comment-emre azt mondtak megoldjak.
Amugy igy nezett ki valahogy eredetileg:
interface XMatrix<M> ...
interface XMatrixUtils<M>
interface Linalg<T> ... { XMatrixUtils<T> newXMatrixUtils()...
A linalg implementacioja meg visszaadta az apachecommons-os valtozatot jelenleg, hosszutavon meg beallitasbol. Es a ...utils az ami eloallitja a nyers adatokbol a matrixosztalyokat, es utils-bol egy szamitasi folyamatban egy peldany van, szoval vedve volt ez elegge.
De igy a kodban ugy hasznaltam, hogy
XMatrixUtils mtxUtils= ...
XMatrix mtx= ...
ahol a bal oldalak meg rawtype-ok. Ami "nem jo" mert nem lesz type check...
Most valami koztes allapot van (nalam ugy hogy a sajat szamolos osztalyom es a unit test-je is generic az <M> felett, ok meg halalra generic-eltek a sajat interface-uket onmagukkal stb. de a vegen az en kodomba hard code-olva tettek hogy "csak igy lehet". Aztan ugy tunik most javitjak, ezek szerint nem csak igy lehet...
En el nem hiszem hogy ez az egesz megeri azt hogy 3 fejleszto most mar tobb mint 1 napot dob ra, sot a generikus alkalmazas fejlesztesi vezetojet is belerangattak, szerintem atlathatatlanabb es hasznalatban zavarobb lesz, mint az a szerencsetlen raw type lett volna. -
#68216320
törölt tag
Rendben. Köszi
Nem tudom, olyat lehet kérni itt a csoportban, hogy mondjuk csinálok egy nagyon alap project-et amit feltolok mondjuk a napokban gitlab-ra és megkérlek benneteket, hogy átfussátok? Tényleg alap CRUD dolgok, sima konzolos view-al.
Szoktak ilyet kérni? Vagy ezt nem illik?
Szeretném, ha helyesen rögzülnének bennem a pattern-ek.
Aztán javítgatom, mintegy példaként a későbbiekre. -
#68216320
törölt tag
Springet még hagyom, sima JDBC-t használok majd és alap funkciókat.
Viszont megkeveredtem, azt hittem DAO-t kizárólag perzisztens rétegben használunk.
Azt hiszem kellene keresnem valami megfelelő MVC alapú alap funkcionalitású (FW nélküli) kódrészletet, hogy a helyére kerüljenek a dolgok.Elnézést a bugyuta kérdésekért.
vissza a padba...Még egy gyors kérdés, akkor elvben valahogy így nézne ki?
View <- (Model) -> Service <- (DAO) -> Persistence
vissza a padba...Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Dell notebook topic
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kifelé is csukható a Z Flip7?
- Vivo X200 Pro - a kétszázát!
- GTA V
- Vezetékes FEJhallgatók
- Otthoni hálózat és internet megosztás
- Apple iPhone 13 mini - miért nem veszik elegen?
- Meggyi001: RTX 5060 - Az új népkártya?
- Telekom mobilszolgáltatások
- További aktív témák...
- Gigabyte GA-F2A88XM-D3HP Alaplap + AMD A10-7800 Radeon R7 + 2x4GB ADATA DDR3 RAM
- iPhone14 Pro Max Független , dobozában , Alza Garancia
- Eladó 2tb szerver hdd több db
- OUTLET Áron - Steelseries, Razer, Logitech, Corsair - Számlával, Garanciával, Mélyen ár alatt!
- Samsung Galaxy S25 Ultra, 12/512, ezüstkék titán
- Telefon felvásárlás!! Samsung Galaxy A20e/Samsung Galaxy A40/Samsung Galaxy A04s/Samsung Galaxy A03s
- LG 32SQ700S-W - 32" VA Smart - 3840x2160 4K UHD - 62Hz 5ms - WebOS - Wifi + BT - USB-C - Hangszórók
- Xiaomi Redmi Note 14 5G 256GB Kártyafüggetlen 1 év Garanciával
- Eladó Apple Mac Mini 2012 vége / 12 hó tótállás
- Microsoft Surface Pro 7 tablet
Állásajánlatok
Cég: FOTC
Város: Budapest