Java

Úgy hozta az élet, hogy mocskolnom kellene ezen a java-ban írt projekten kicsit:

https://github.com/OpenAPITools/openapi-generator

Sajnos a módosítás mértéke úgy tűnik meg kell haladja azt a szintet amit gyalog módszerrel (kate + mvn clean install + jar futtatása) érdemes végezni.

Kellene valami IDE amiben tudok normálisan debugolni illetve egy sor módosítás compile-ja (vagy aminek Javaul épp nevezik) az nem két percig tart.

Mit ajánlatok erre a célra 2024-ben?

Adott egy java alkalmazas ami csak 1.7-es javán fut, ha jól tudom a java 1.7 nem támogatja a TLS 1.3-at,
hogyan lehetne linuxon megoldani, hogy mégis elérje a https://srv-t, az alkalmazás módosítása nélkül?
pl: java alk. <--> (nginx?) proxy on localhost:443(TLS1.2 selfsigned cert) <--> https://srv.tld (TLS1.3),
vagy lenne egyszerűbb megoldás ?
Köszönöm!
 

Van néhány WAV fájlom, amik egy régi 8 bites számítógép betölthető programjait tárolják.

Továbbá van egy javascript alapú emulátorom, ami az AudioContext segítségével be is tudja tölteni ezeket.

Valamint jelenleg ehhez az emulátorhoz létezik néhány MP3 fájl is, amiben szintén a géphez tartozó programok vannak tárolva, és ezeket is be tudja tölteni az emulátor.

A feladat az lenne, hogy én is tudjak MP3 fájlt generálni a létező WAV fájlomból úgy, hogy ez az emulátor be tudja tölteni.

1 - Azt már megtapasztaltam, hogy az AudioContext objektumnak van egy 'sampleRate' paramétere. Ha ez az érték nem azonos a wav fájl sampleRate értékével, akkor az emulátor nem tudja beolvasni. Ha azonos, gond nélkül betölti.

2 - Érdekes módon, ez a 'sampleRate' paraméter az mp3 fájlok esetén nem azonos az mp3 fájlból killvasható értékkel. Az AudioCintext objektumban ez 48000, míg az mp3-nál a ffprobe parancs 44.1kHz-es értéket mutat.

A parancs, amivel jelenleg próbálok konvertálni:

lame -s 44.1 -b 96 -q 9 -m m program.wav program.mp3

Az ffprobe mind a működő mp3, mind az általam konvertált mp3 esetén ugyanazt az információt mutatja:

..., bitrate: 96 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 96 kb/s

A minta mp3 fájlt mégis gond nélkül betölti az emulátor, az enyémet meg nem.

Van ötletetek, hogyan tudnám mp3 formátumba konvertálni a wav fájljaimat, hogy továbbra is működjön a betöltés?

Böngészőben egy excel állomány tartalmát szeretném megjeleníteni . 

<input type='file' accept='.xlsx, .xls' onChange={handleFileUpload} bekéréssel,  ahol a handleFileUpload-ban egy  FileReader() -t használva, ami  egy target.files[0] tömbe tölti be a olvasandó fájl elérési útcvonalát  sikeresen meg tudom jeleníteni a kijelőlt xlsx állomány tartalmát.

Szeretném felhasználó bevonása nélkül,  programból feltölteni a  target.files[0] tomb tartalmát  de sehogy sem tudom programból megoldani.

Tudna valaki segíteni hogy hogy oldhatom ezt meg ?

Köszönöm 

Lehet, hogy nem jól értek valamit.

Van 2 alkalmazás szerver. Nincs az Entity cache szinkronban.

Amikor kiíratom az SQL-t amit optimistic lock esetén végrehajt, egy ilyesmit látok: update version=?version+1 where version=?version and id=?id; Ez alapján úgy gondolnám, hogy nem lehet 2 írás ugyanazon a rekordon. Vagy mégis? Úgy tűnik mintha ennek ellenére 2x íródna nagyon ritkán ugyanaz a rekord, nem dob Exception-t.

Még az ünnepek előtt jött valahol szembe a Vaadin (https://vaadin.com), ami első (és egyelőre sokadik) ránézésre is olyan frameworknek látszik, aminek használatát érdemes lenne fontolóra venni.

Amúgy sem szeretem a frontendet; JavaScripttől, CSS-től stb., kiráz a hideg.

De azt vettem észre, hogy kis fejlesztőcsapat lévén (van 1 db UX-es, de ő is inkább designer, mint fejlesztő, a többi lényegileg mind backend) számos belső tool-ra egyszerűen nem jut idő és energia frontendet fejleszteni, mert a Postman-nel való tutujgatás "elégségesen jó" megoldás.

Szóval első körben leginkább belső tool-ok UI fejlesztésére használnám, nem pedig a publikus oldalunkat akarnám újraírni benne.

A kérdés: használta-e valaki a Vaadin-t éles környezetben (nem példakódok otthon bizergetése), és ha igen, akkor mik voltak a tapasztalatok vele?

Mennyire egyszerű vele egy frontendet összehozni?

Mennyire bugos?

Hogyan lehet debugolni?

Milyen előnyöket/hátrányokat tapasztaltatok?

Stb. stb.

Köszi!

Még fiatalos a kinézetem. Visszajelzések szerint 5-10 évet simán letagadhatok. A modernebb technológiák vonzanak és még van bennem tudásvágy is.

A mostanában szokásos videó interjúkon (itt kevésbé látszik, hogy oldalt már őszülök) / feladatokon is átmegyek simán.

Az önéletrajzomból nem derül ki a korom, sőt ott is a 10 évvel fiatalabb jön ki egy véletlen folytán.

Ma raktam magamban össze a képet, hogy ahol modernebb technológiákat használnak, ott valószínűleg fiatalabbakat is várnak.

Azaz addig nincs semmi baj, amíg nem kérik be az adataimat. Jó ajánlatokat is kapok. 1.5 fölötti mind. Viszont amikor sejtésem szerint a beküldött adatok alapján meglátják, hogy nemrég elmúltam 50, jönnek a visszahúzódások.

Soha sem vágytam vezetői pozícióba. Mentorálni viszont mindig szerettem.

Lehet vissza kell lépnem a régebbi technológiákhoz? Azoknál nem volt gond ennyire, olyan helyekre simán felvettek volna. Igaz ott mindegyiken öreg szakikat is láttam. Több helyen GWT-t tolnak még. Volt ahol JDBC megy még. Stb. Az egyikre rákérdezve azt mondták felvettek ugyan embereket, de ha meggondolom magam szívesen látnak.
A régi munkahelyemre is visszavennének, ott JEE van. A Spring ott viszont tiltott. Pedig simán lehetne sok esetben használni.

Ez nem allasajanlat, hanem akinek van kedve reszt venni egy mar letezo kodbazis fejlesztesenek folytatasaban, az irjon nekem:

wyx@freemail.hu

reszletek online beszelgetesben kesobb..

kosz,

Már 1 napot eltöltöttem ezzel a feladattal és nem igazán látok megoldást.

SOAP: Jaxb 2.3.3 + Spring.

Kb. 400 megás fájlokat kellene XML-ben visszaadnom base64 kódolással.

Valahogy így néz ki az XSD ezen része: 

type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream"

A Java-ban így van beállítva:

.setDoc(new DataHandler(new FileDataSource(f)));

Jelenleg olyan 4G-át eszik 1db 400 megás fájlnál.

Jó lenne ha streamelné inkább mint betölti memóriába a teljes fájlt stb.
com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.class:

try {
    ByteArrayOutputStreamEx baos = new ByteArrayOutputStreamEx(1024);
    InputStream is = this.dataHandler.getDataSource().getInputStream();
    baos.readFrom(is);
    is.close();
    this.data = baos.getBuffer();
    this.dataLen = baos.size();
} catch (IOException var3) {
    this.dataLen = 0;
}

Mert a főnökség viszont szeretné, ha mindez elmenne <1G rammal. Ha lehet 512 megával.

Ahogy debugoltam úgy látom alapból betölti a teljes fájlt. Majd azon még dolgozik a base64 kódolás miatt és úgy rakja be az XML-be. Gondolom a Content-Lenght-et is így állítja be (de ez nem lenne fontos).

Van ötletetek valami megoldásra?

Egy böngésző alapú alkalmazásból javascripttel kommunikálok USB-n keresztül az xterm.js segítségével.

Mivel a soros kommunikációt csak felhasználói beavatkozásra engedi megnyitni a Chrome (Firefox még úgy sem), így jelenleg, ha a felhasználó megnyom egy gombot, akkor meg tudom nyitni az USB kapcsolatot, adatot tudok cserélni az eszközzel, és utána le tudom zárni a kapcsolatot. Minden megnyitáshoz a felhasználónak ki kell választania a soros portot. Ez működik, de nehézkes.

Szerettem volna egy megnyitás és egy lezárás gombot is készíteni, de itt kezdődött a probléma. Ha egy külön esemény nyitja meg a soros portot, akkor hiába küldök rá bármit, már nem működik.

Azaz a következő kód megy:

function on_click() {
   var sc = new SerialComm();
   sc.sendCmd( command );
   sc.close();
}

A következő pedig nem:

var sc;

function on_click_open() {
   sc = new SerialComm();
}

function on_click_send() {
   sc.sendCmd( command );
   sc.close();
}

Hibaüzenetet nem kapok, csak nem megy.

Van valakinek ötlete, mi lehet a probléma? Vagy ez valamilyen biztonsági megkötés, és így soha nem is fog menni, csak egy eseményben?

Megoldás: gond nélkül megy külön a megnyitás és a kommunikáció, nincs korlátozás. Én hibáztam a SerialComm osztályon belül. :(