Új hozzászólás Aktív témák
-
btraven
őstag
válasz
sztanozs
#11498
üzenetére
Az a baj hogy elhatároztam hogy hallgatok az Android Studio warning-jaira commit előtt.
Ha iteratort használsz akkor lehet közben törölni.
Most a másik warning:
GameDB.armies.remove(Integer.valueOf(army.getId()));
mapban Integer van, de a getId() int-et ad vissza.
szerinte felesleges a valueOf
Így bízza az ember magát egy programra.
Állandóan figyelni kell. -
-
orc88
őstag
Sziasztok.
Egy Maven projectet próbálok készíteni, ahol a program eredményeit egy json fileba írom és onnan olvasom vissza a korábbiakat.
Ha az
\src\main\resources\results\mappában helyezem el a results.json-t akkor Mavennel futtatva a programot tökéletesen írja és olvassa az adatokat, bemásolja a\target\classes\results\mappába.
A probléma az, hogy egy futtatható .jar-t is készítek ez viszont nem éri el így a filet.Egy megoldás, ha nem a resources-be rakom, viszont ekkor mindkét esetben közvetlen a gyökérbe rakja a jsont, ez így annyira nem tetszik.
Hogyan tudnám pl. simán egy results mappába rakni úgy, hogy mindkét esetben hozzáférjen a program?
Remélem érthető a problémám
-
-
btraven
őstag
Android Studio (Idea) azt javasolja cseréljem le a lambdát method reference-re.
pausedActions.forEach((k, v) -> {
k.addAction(v);
vspausedActions.forEach(Actor::addAction);class Actor { public void addAction (Action action) {
nem is értem a lambdában miért van kávé? Biztos túl sokat iszom. -
Hello,
Valakinek van ötlete?
Leraktam tavaly nyáron egy textureview-et egy Android kódban. Minden mérete wrap content, meg match parent, 0-s kényszerek minden oldalon. Így teljes képernyősként jön létre, majd megfelelő arányban leméreteződik (scale-el). Kamera előnézet van rajta, szépen megy.
Mostanában leraktam ugyanabba a kódba egy imageview-et, mert akarnék rajzolni a kameraképre. Gondoltam a méretek, stb. megvannak, leskálázom ugyanúgy, mint a texture-t.
És nem.
Az az alapvető baj, hogy ugyanazokkal a méretekkel, constraint-ekkel, nem ugyanúgy teszi le az imageview-t. Ez elszáll valamelyik sarokba már a layout tervezőben. Kódban nagy nehezen lehet skálázni, már a méretét is belőttem ugyanakkorára, mint a textureview, és
nem lesz ugyanakkora.
Ugyanakkora a mérete, ugyanúgy skálázom le, és mindig eltér.Szerintem már a layoutban rossz (de mi? hát ugyanazok a paraméterek...), de alapvetően mit lehet ezzel kezdeni, hogy a két view ugyanakkora legyen?
Köszi minden öltet...
-
Zsoxx
senior tag
-
#68216320
törölt tag
válasz
#68216320
#11485
üzenetére
Nem tudom mennyire sikerült leírnom a feladatot. A lényeg, hogy idegen szerveren futtatva a programomat védeni kellene bizonyos adatokat, amik ott helyben vannak tárolva. Konfig adatok esetén fájlban vannak ezek, egyéb adatok esetén mondjuk sql-ben.
Ha valaki ránéz a szerveren ezekre az adatokra akkor simán kiolvasva őket használhatatlanok legyenek csak a program futása közben tudja használni ezeket. Vagyis valami kulccsal titkosítani kellene. De hogy hol lenne mondjuk tárolva ez a kulcs, na azt nem tudom. Tehát valami elvi megoldás kellene, hogy hogyan lehetne ezt felépíteni.Van olyan kulcs amit az adott szerver tulajdonosa (cég) ismer és azt használná a program titkosításra. (ez a jelen feladat)
És lenne olyan is, amit csak én ismerek és az valahogy fixen a programban lenne, azzal tudná a program az általam biztosított adatokat írni/olvasni. (ez egy következő feladat)
-
#68216320
törölt tag
válasz
bambano
#11483
üzenetére
De ha bekérem a kulcsot, akkor mindjárt kérhetném az adott jelszót is. Persze több jelszó esetén már kellemesebb a kulcsot megadni és azzal decrypt-álni a többit.
Viszont az alap probléma adott még. A user meg akarja változtatni a property-t kézzel, akkor hogyan tudja beírni a property-be kézzel a titkosított jelszót.
Vagyis példaként:
Egy e-mail küldő konfig fájlban lenne az smtp-host, user, pass, port. Ezeket a user kézzel állítja be a saját adatai alapján. De ugye a pass-t nem adhatja meg csak plain, mert nem biztonságos. Az email küldőt pedig egyéb osztályok hívják, szóval nincs külön indítás ahol megadhatnám a key-t, kiegészítő modul lenne.Mi van olyankor ha úgy csinálnám, hogy a program (ami hívja majd az email osztályt) minden híváskor átadja a használt key-t (mondjuk nem tudom még az honnét jönne létre). Ezzel tudja ugye decrypt-álni a jelszót az email osztály. Viszont lenne egy ellenörzés, hogy amikor plain text a konfig fájlban a jelszó (modjuk éppen szerkesztette az előbb a user), akkor először encrypt-álja és ezután az általános módon beolvassa, decrypt és használja.
Valami hasonló módon csinálja linuxon a transmission-daemon is a config fájlban.
De továbbgondolva a dolgot általános is lehetne a kérdés. Bizonyos esetekben jó lenne SQL-ben tárolt adatoknál is pár olyan értéket titkosítva tárolnom, amit a programom tud írni-olvasni, de ha a user ránéz (akinél fut a programom) ő az sql-ből nem tudja kiolvasni. Ezek olyan dolgok lennének, amikot kénytelen vagyok adni a programmal, de saját, védett adatok lennének viszont kellenek a program működéséhez és alkalmanként távolról frissíteném-bővíteném ezeket.
-
Drizzt
nagyúr
-
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
-
-
btraven
őstag
Ja hogy ezek csak tippek
Kicsit összekevertem a warning-gal, mind a kettő sárga izzó.Sikerült beállítanom a felületet eclipse-szerűre.
Köszönöm mindenkinek a tippeket.libgdx meglepően kompatibilis eddig. Desktop-on fejlesztek aztán átrakom a végén androidra egy mozdulattal.
-
Szmeby
tag
válasz
btraven
#11473
üzenetére
En ugy gondolom, hogy jelentos merteku fejfajastol kimelned meg magad, ha elobb bekonfiguralnad az IDEt ugy, ahogy neked tetszik. Minden valamire valo IDE-ben be lehet allitani, hogy mit tekintsen hibanak es mit ne, hogyan formazzon es hogyan ne. Szerintem ez is kepes ra.
Persze ha csak ventillalni szeretnel, akkor targytalan, folytasd nyugodtan.
Megjegyzem, en szeretem a zarojelet az if-nel, mert igy egyseges, konnyen attekintheto.
-
yanpec
senior tag
válasz
sztanozs
#11461
üzenetére
Nem abból tanulok. Kezdésnek a Java programozás 24 óra alatt ebookot választottam. Maga a könyv nem rossz, csak ezek szerint régi. Alapnak jó lesz szerintem, mert a változók, ciklusok, függvények stb stb, nem hiszem, hogy változtak. Hamar végig fogok érni rajta, mert más nyelveken már programoztam de már régen (tpascal, Delphi, stb.) De nagyon szívesen venném ha tudnál ajánlani egy könyvet hozzá.
Köszönöm. -
Csaby25
őstag
válasz
Drizzt
#11465
üzenetére
A maven le sem build-eli, hibat ad az application-dev.properties file-nal,
" Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources (default-resources) on project elsospring: Execution default-resources of goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources failed: newPosition < 0: (-1 < 0) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources (default-resources) on project elsospring: Execution default-resources of goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources failed: newPosition < 0: (-1 < 0)"Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-resources of goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources failed: newPosition < 0: (-1 < 0)
Caused by: java.lang.IllegalArgumentException: newPosition < 0: (-1 < 0)
-
Szmeby
tag
válasz
btraven
#11462
üzenetére
En amikor csak lehet, csak backendet keszitek javaban. A frontend meg szepen koltozzon at a bongeszobe (angular, react, vue, stb).
Ha tenyleg annyira pici a problema, hogy nem eri meg egy js frameworkkel loni ra, akkor desktopra inkabb raknek ossze egy python appot. Az is benacska, de legalabb gyorsan elkeszul. Azert python, mert szerintem sokkal konnyebb es mert mashoz nem ertek.
Ha meg nagyon ragaszkodnek valamiert a javahoz, akkor +1 a javafx-re. Az a legujabb desktop frontendje, de mar azt sem eroltetik a keszitok.
-
Drizzt
nagyúr
válasz
Csaby25
#11464
üzenetére
Meg kell mondani az alkalmazasnak inditaskor, hogy melyik profilokat hasznalja. Application.properties by default mindig beolvasasra kerul, a - dev-hez aktivalni krll a dev profile-et. Asszem ha jar-kent inditod, akkor - Dspring.profiles.active=dev a megfleelo kulcsszo, de fejbol irom, lehet rossz.
-
Csaby25
őstag
Sziasztok!
Adott két properties file:application.properties és application-dev.properties
Tudja valaki, hogy a Spring Boot miért nem tud kiolvasni a második file-bol?
@Value("${msg}")
private String message;Nem tudja kiolvasni az msg-t csak ha az első file-ba teszem, miért
?Hiba: Could not resolve placeholder 'msg' in value "${msg}"
Köszi!
-
Hello,
Androidon valaki tudja, hogy Storage Access Framework esetén hogyan lehet megkapni a sdcard (azaz a belső flash tároló) adat partíció gyökerét? Oda pakoltam le a program előző verziójában azt az egy szerencsétlen txt file-t, amibe ment, és úgy kéne megoldani, hogy ha frissít a user, akkor ugyanazt a tartalmat kapja meg.
(Vagy azt el kéne mozgatnom valahova, de előbb kéne tudni olvasni, lekérni az útvonalat stb. ) -
yanpec
senior tag
Sziasztok
Most ismerkedem a java programozással. Viszont van egy problémám. A sima programokat gond nélkül le tudom futtatni, de a mini alkalmazásokat nem jeleníti meg egy böngésző se. Mitől lehet ez?
Minialkalmazás programkódja:import java.awt.*;
public class BlanksApplet extends javax.swing.JApplet {
String parameter1;
String parameter2;
String parameter3;
public void init() {
parameter1 = getParameter("adjective1");
parameter2 = getParameter("adjective2");
parameter3 = getParameter("adjective3");
}
public void paint(Graphics screen) {
screen.drawString("The " + parameter1
+ " " + parameter2 + " fox "
+ " jumped over the "
+ parameter3 + " dog.", 5, 50);
}
}Weblap p.kódja:
<applet code="BlanksApplet.class" height=80 width=500>
<param name="adjective1" value="lachrymose">
<param name="adjective2" value="magenta">
<param name="adjective3" value="codependent">
</applet> -
-
togvau
senior tag
válasz
Lortech
#11443
üzenetére
Ez se nyert: https://pastebin.com/X4ibhvWh
Beletákolva valami httpclient függőséget már elindul, de amikor kellene csinálnia, akkor:org.springframework.web.client.HttpClientErrorException: 400 Bad Requestat org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:85)at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:707)at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:660)at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:620)at org.springframework.web.client.RestTemplate.postForEntity(RestTemplate.java:414)Az eredeti hiba a szokásos: https://pastebin.com/2RmS1DHS
-
Lortech
addikt
válasz
togvau
#11442
üzenetére
Áh, mavenes a projekt, ott a bibi, használj gradle-t, az ezt is megoldja.
Nyilván pontos válaszhoz kéne egész pontos infó, hogy a TLS handshake melyik ponton döglik, pl. openssl s_client kimenet, de ágyúval verébre megoldás itt:
https://stackoverflow.com/a/45444355 -
togvau
senior tag
helllo, adott egy java 8 (adoptopenjdk) maven springboot projekt.
Innen egy webservicet használnék (ekáer), úgy tűnik resttemplate-el. A programozás része eddig egyszerű volt, de a rendszergazda rész megint szívat, mivel köszönhetően a tetves google-nek ez is SSL...
Jön is az imádottsun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Ezen szeretnék túljutni a lehető leggyorsabban, és legegyszerűbben. Nem érdekel az úgynevezett "biztonság". Hordozhatóvá szeretném csinálni, ilyen cacertes minden gépen ahol fut létrehozós, mindent servicet amit használ letöltős dolgokat el szeretném kerülni.
Azt szeretném, hogy az intellij fejlesztőkörnyezetből, meg war-ba csomagolva és akárhol indítva is ugyanúgy működjön, mindenféle gépenként rendszergazdás tákolás nélkül.
úgy szeretném mint böngészőből, be az url azt jóvan, működik, nem cert marháskodik.Hogy érhetem el ezt? Googlen nem működő, vagy nem ide vonatkozó, vagy hiányos leírásokat találtam csak.
-
#11441
floatr
veterán
Aethelstone
#11440
floatr
veterán
válasz
Aethelstone
#11440
üzenetére
Nézd, kezdetektől fogva javazom, és család mellett sem okozott problémát a gradle, bár az ant-et szerettem a legjobban. Nyilván mindenkinek más az "egyszerű", de az XML tömöttsége eleve kevésbé áttekinthető, mint egy DSL, bármilyen jó code highlightot használsz. Karbantarthatóság szempontjából is nyilván jobb
Ami a design-t illeti, a legtöbb esetben nincsen papírforma, mindig van valami olyan körülmény, amihez alkalmazkodni kell. Amellett egy mostani CI migráció miatt jött elő, hogy a gradle build előnyben van a mavenessel szemben a deployment miatt, mivel több olyan dolgot implementáltunk benne, ami mindenhol tud futni, de a mavenes projekt ezt a CI-ra bízta. -
#11439
mobal
nagyúr
Aethelstone
#11438
válasz
Aethelstone
#11438
üzenetére
Remélem nem, most full komolyan.
-
#11437
mobal
nagyúr
Aethelstone
#11436
válasz
Aethelstone
#11436
üzenetére
Én általánosságban értettem, de bizonyos kor felett egytől egyig akivel dolgoztam nem akart változtatni a szokásain. De ez más téma.
-
#11436
Aethelstone
addikt
mobal
#11435
-
#11435
mobal
nagyúr
Aethelstone
#11434
válasz
Aethelstone
#11434
üzenetére
Persze. Erre rengeteg példát láttam az élet folyamán. Maradjunk a régi dolgoknál mert akkor nem kell nekem változtatni és ez a lényeg. Te is tudod jól, hogy töbségében ez van...
-
#11433
mobal
nagyúr
Aethelstone
#11432
válasz
Aethelstone
#11432
üzenetére
Senki nem vén szarozik, de a nagyobb problémát egy másik build toolra való átállás nekik jelenti.
-
#11432
Aethelstone
addikt
Drizzt
#11431
Aethelstone
addikt
válasz
Drizzt
#11431
üzenetére
De pont ezt mondom én is
Én egyébként cirka 2010 óta mavenezek, 3-4 éve meg van gradle projektünk is. Mindkettőt elismerem, de azt tényleg ne mondja senki (itt le lett írva), hogy a maven a vén szaroknak való és kuka és mindenre a megoldás a Groovy. Faszt, már bocsánat. Mindkettőnek kurvára megvan a helye -
#11431
Drizzt
nagyúr
Aethelstone
#11429
Drizzt
nagyúr
válasz
Aethelstone
#11429
üzenetére
Mostmar ha elorangattad, ne hatralj ki.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Erre en csak annyit akartam irni, hogy eddig olyan 5 eves maven hasznalatom alatt egyszer sem jott szembe olyan dolog, amire nem lett volna letezo plugin, ami megoldotta a problemat. Oke, vannak azert olyanok, amitol jobbat is el tudnek kepzelni, de egyutt lehet vele elni. Van amugy joval hosszabb programozoi tapasztalatom(ossz. ~15 ev), de OOP/Java az legyen inkabb 5 ev. Ezert 5 ev a maven is.
Illetve ami pl.: Gradle-re atteressel problema lenne, hogy van egy jo szazas nagysagrendu microservice, ami azert jelenleg elegge hasonlit build projektileg. De ettol fuggetlenul mindegyikben johet fejlesztesi igeny. Ha meg hirtelen a projektek egyik fele maven, a masik fele meg gradle lenne, bevinne egy szep kis extra komplexitast. -
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 -
#11428
floatr
veterán
Aethelstone
#11426
floatr
veterán
válasz
Aethelstone
#11426
üzenetére
Teljesítményben jobb, de clean coding miatt is preferálják. A mavenben nem szokványos taszkokat, ami filekelezés/deployment témában befigyelhet, csak custom osztályokkal oldhatsz meg, ami rendkívül jó kódrejtésben
A groovy mondjuk nem a kedvencem, de ha kotlinos a projekt, akkor eleve adja magát. -
#11427
mobal
nagyúr
Aethelstone
#11426
válasz
Aethelstone
#11426
üzenetére
Jó, nyilván szarul fogalmaztam de remélem átment amit akartam, hogy az xml ebben az esetben szarul nézne ki Groovy / Kotlin dsl helyett!
-
#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....
-
#11425
mobal
nagyúr
Aethelstone
#11424
válasz
Aethelstone
#11424
üzenetére
Fordítsuk meg. Olyan use case van amit csak mavennal lehet xml nélkül?
Egy use case ahol ugyan jó a maven, de:
- Spring Boot alkalmazás
- Groovy / Kotlin dsl gradle file
- Yaml konfigurációs fileok
- Java konfigokNekem ebben a körneyezetben egy XML nagyon elütne / nem illene bele. De mint fentebb is beszéltük egyéni preferencia kérdése és semmi több.
-
#11424
Aethelstone
addikt
Aethelstone
addikt
No offense, de mondjatok már egy olyan use-caset, amit csak gradle segítségével lehet megoldani....hogy kicsi visszamenjek...
-
Drizzt
nagyúr
válasz
btraven
#11422
üzenetére
De, szabad hasznalni. Viszont ha nem valamilyen factory metodusban hasznalod, akkor gyanus, hogy lenne helyette szebb, biztonsagosabb, bovithetobb OOP megoldast talalni a problemara. Nyilvan nem mindig. Akkortol jon a gond, ha tobb metodusban ugyanazon ertekkeszlet alapjan kell kulonbozo dolgokat csinalni, mert konnyen el lehet cseszni, ha bovul az ertekkeszlet.
-
Drizzt
nagyúr
válasz
floatr
#11417
üzenetére
Remek, de ezekre nincs szuksegunk. Egyszer jo lenne atterni, de joval nagyobb annak az ara, mint amit itt sugallsz. Mindenkeppen eltart egy ideig, mig egy programozo csapat atszokik egy masik build tool-ra. Nyilvan van az a helyzet, amikor a relativ koltsege az atallasnak kisebb, mint a relativ haszna. Nalunk jelenleg nem az.
-
floatr
veterán
válasz
Drizzt
#11415
üzenetére
Mi az előnye a teljesítmény mellett? Sokkal rugalmasabb: deklaratív és procedurális egyben. Ha valami nem szokványos dolgot kell megoldani, elég egy kisebb scriptet írni benne. Nem vagy kötve a CI/CD képességeihez, és lokálisan is meg tudod azt tenni, amit a CI/CD pluginekkel támogat
Azt sem tartom valós problémának, hogy annyit kéne vele bíbelődni, hiszen a fejlesztőkörnyezetek már eléggé támogatják a nulláról kezdést is, ahogy a maven esetében. Sokkal körülményesebb a maven, de igazán nem akarok téríteni, nyilván nem kötelező, ha valaki nem akarja. Végülis lehet írni SOAP-os vagy RMI-s alkalmazást is manapság, az is működhet...Off az off-ban: szoktam találkozni olyan emberekkel, akiknél megfigyelhető az a felfogás, hogy csak abba az irányba hajlandóak elmozdulni, amerre a kényszer viszi őket. Ők általában egy idő után benne ragadnak egy adott technológiai stackben, ami egy ideig fel sem tűnik nekik. 10 évvel később viszont már riasztó, amikor még mindig servletről beszél, és oracle + jdbc a DB megoldás mindenre
-
disy68
aktív tag
válasz
Taoharcos
#11414
üzenetére
meg kell nézni, hogy pontosan mit és hogyan csinál, hogyan volt használva a korábbi programból és hogyan a tiedből, ha ennyiből nem derül ki akkor utána nézel, hogyan lehet debug-olni, abból biztos kiderül, hogy mi okozza a problémát
aztán vagy máshogy használod vagy át/újra kell írni -
Drizzt
nagyúr
válasz
floatr
#11410
üzenetére
"A megfelelő build alap összerakása elhanyagolható erőforrásigényű egy átlagos projekt többi feladatához képest." Nem ertek egyet. Ez csak akkor igaz, ha az adott build rendszerhez es az azzal szembeni kovetelmeneykhez is valaki nagyon ert. Igazabol aztan utana tok mindegy, hogy pipeline-bol mavent, vagy gradle-t hivok meg.
Projektek atlagos build ideje ket perc mavennel. Intellij meg ugyis feldolgozza az egeszet belso projekt formatumra, ami sokkal gyorsabb, foleg ha szelektiven akarsz valamit futtatni. Kiprobalnam en is elesben a Gradle-t, de nem igazan varok tole semmi valos hasznot a mi use case-unkben. Ha nagyon nem lesz semmi dolgunk, akkor majd rakerul arra is a sor. A mostani maven service template-jeink tokeletesen megfelelnek az elvarasainknak, a lecserelesukben sokkal tobb lenne a potencialis risk, mint a potencialis benefit. -
Taoharcos
aktív tag
válasz
disy68
#11413
üzenetére
Ez egy régebben (10+ éve)megírt dll. Biztos nem vírusos. Eddig más programnyelvből (Delphi) lett meghívva, és ott működött jól. Talán annyi tudtam még észrevenni, hogy ha elindítom a saját programomat, és leállítom, majd újraindítom, akkor jön elő, de az bizonytalan, hogy mennyi idő múlva és hányadik újraindításnál. Elvileg a Windows újraindítása után rögtön nem csinálja.
-
disy68
aktív tag
válasz
Taoharcos
#11412
üzenetére
Mi az a dll, amit használsz? A hiba azért van, mert a dll-ben lévő kód az általa lefoglalt memórián kívül akar írni a memóriába, amit akár más process éppen használ. Ezt figyeli a runtime és lelövi. Jobb esetben bugos a dll-ben lévő kód, rosszabb esetben valami kártevő lakik benne.
-
Taoharcos
aktív tag
Van egy projektem, ami egy külső dll file-t használ egy feladat elvégzéséhez. Jna-t használok. Általában működik is, de néha teljesen váratlanul Microsoft Visual C++ Runtime Library: "Buffer overrun detected! A buffer overrun has been detected which has corrupted the program's internal state." hibát dob.
Találkozott már valaki ilyen hibával, vagy van valami ötlete mi lehet a hiba? Mivel ez túlnyúlik a Java-n és inkább csak a Java-ban vagyok otthon, ezért nem tudom hogy kéne a hibát keresni.
Java 8 , Windows 10 az oprendszer és elvileg 4.8.03752 a .NET verzió. Esetleg rossz .NET verzió lenne a probléma? -
floatr
veterán
válasz
Drizzt
#11407
üzenetére
A megfelelő build alap összerakása elhanyagolható erőforrásigényű egy átlagos projekt többi feladatához képest. Nyilván nem a legkritikusabb helyzetekben kell fejest ugrani az ismeretlenbe, de ezzel a mentalitással bele lehet ragadni technológiákba. Amúgy pont devopsos szempontból nem értem a dolgot, hiszen épp a gradle az, ami sokkal kezesebb groovy/kotlin oldalról. Compose-os projektekben befonnánk egymás haját, ha mavent kellene használni.
-
válasz
Szmeby
#11408
üzenetére
"ha valakit az alapján ítélünk meg (el?), hogy mavent vagy gradlet használ"
Én nem ítélek meg senkit ez alapján. Le is írtam az elején, hogy nem akarok ebből most keresztes háborút, és továbbá azt is, hogy fiatal vagyok xml-ek irogatásához. Amit leírtál szerintem szélsőséges, fontosnak tartom, hogy hozzuk be az új dologokat de nem kell a ló másik oldalára esni.
-
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.
-
-
Lortech
addikt
Na, ki tud nagyobbat mondani a fentieknél, szakmaiságban és megalapozottságban?
Viccet félretéve, egy okból váltanám le a mavenes projektjeinket gradle-re, ha olyan jellegű performancia problémánk lenne, amin a gradle segítene, és a probléma elérne olyan szintet, hogy megérné kidobni kb. 1 hónapot az egyébként jól működő, maintenance és problémamentes projektjeink migrációjára.
?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- ASUS notebook topic
- Milyen egeret válasszak?
- Synology NAS
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- Bestbuy játékok
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Milyen routert?
- DUNE médialejátszók topicja
- További aktív témák...
- BESZÁMÍTÁS! Asus H410M i5 10400F 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA ADATA 600W
- BESZÁMÍTÁS! MSI H510M i5 10500 32GB DDR4 960GB SSD RTX 3060 12GB Rampage SHIVA ADATA 600W
- BESZÁMÍTÁS! MSI B450M R5 3600 16GB DDR4 512GB SSD GTX 1080 8GB Rampage SHIVA ADATA 600W
- BESZÁMÍTÁS! MSI B450M R5 5600 32GB DDR4 512GB SSD RTX 3060Ti 8GB ZALMAN S3 DeepCool 850W
- BESZÁMÍTÁS! Gigabyte AORUS B550M R7 5700X 32GB DDR4 1TB SSD RX 6800 16GB Zalman i3 NEO Gigabyte 850W
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Motorola E40 64GB, Kártyafüggetlen, 1 Év Garanciával
- REFURBISHED és ÚJ - HP USB-C/A Universal Dock G2 docking station (5TW13AA) (DisplayLink)
- LG 34WR55QK-B - 34" Ívelt VA - 3440x1440 - 100Hz 5ms - FreeSync Premium - HDR 10 - USB Type-C 65W
- T Phone Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest