- One mobilszolgáltatások
- Fotók, videók mobillal
- Samsung Galaxy S25 - végre van kicsi!
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 17 - még mindig tart
- Google Pixel topik
- Huawei Watch Fit 5 Pro - jó forma
- A Sony bemutatta eddigi legjobb és legdrágább zajszűrős fejhallgatóját
- Szívós, szép és kitartó az új OnePlus óra
Új hozzászólás Aktív témák
-
Ah, annyira rühellem, hogy harapófogóval kell kihúzni belőled mindent.
Tisztázzuk, olyan Java kód nincs, ami a megakadályozza, hogy kihúzzák a pendrive-ot. Azt tudod csinálni, ahogy korábban is mondtam, hogy az /mnt/pendrive könyvtárat csekkolod...ha már nem létezik, akkor le van választva.... -
WonderCSabo
félisten
Nem az objektumok számáról van szó, hanem arról, hogy ezek mikor, milyen intenzitással gc-ződnek. Ezért is vetettem fel, hogy mekkora is az a heap méret. Te csak egyetlen felvetésembe kötöttél bele, ami jogos is lehet, de mi van a többivel? Vagy említhetném az esetleges os szintű problémákat is. Nem egymással van vitánk, a problémát próbáljuk megoldani, nem?
Semmi vitám nincs veled, csak csodálkoztam, hogy mire gondolsz, és azért kötöttem bele mert érdekel ez az "altéma".
A bytebuffer tömböt tényleg ki lehetne szedni, az úgyis mindig felülíródik, felesleges mindig létrehozni.
A finally is teljesen jogos, de itt valszeg nem ez lesz a probléma, mindenesetre érdemes ezt a konvenciót követni. Vagy ha van Java 7-re lehetőség, akkor még jobb a try-with-resources blokk.Nem tudom mennyi fájlról van szó és mekkora méretről, érdemes kipróbálni másik OS-n is, egyébként érdekes a probléma, mert kvázi triviális dologról van szó, ami ráadásul rohadtul gyakori művelet is.
Ami még most eszembe jutott, hogy meg kéne próbálni NIO2 fájlmásolással, lehet, hogy segít rajta, és a kód is rohadtul leegyszerűsödik. Persze ez is csak Java 7-el.
-
WonderCSabo
félisten
-
WonderCSabo
félisten
-
WonderCSabo
félisten
-
WonderCSabo
félisten
-
kemkriszt98
tag
-
kemkriszt98
tag
-
-
Idézek a saját hozzászólásomból:
Nyilvánvalóan nem hiba az ArrayList<?> deklaráció, de a statikus típus interfészként deklarálása good practice. Az implementáció egyszerű változtathatósága miatt. Nem is az osztályváltozókban van komolyabb jelentősége, hanem a getter/setter metódusoknál.
És még valami. Amíg magadnak vagy egy kvázi zárt csapatban dolgozol, addig nincs ezzel gond. Amint pl. API-t kezdesz írni, akkor csak interface. És a doksiban kell leírni a runtime típust.
-
WonderCSabo
félisten
-
WonderCSabo
félisten
-
Tehát. Itt ez a remek kód.
try {
rs.moveToInsertRow();
rs.updateInt("ID", newID);
rs.updateString("First_Name", first);
rs.updateString("Last_Name", last);
rs.updateString("Job_Title", job);
rs.insertRow();
stmt.close();
rs.close();
stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCUR_UPDATABLE);
String sql = "SELECT * FROM Workers";
rs = stmt.executeQuery(sql);Ehelyett inkább: (nem teljes és nem is ismerem a táblastruktúrát)
String insertSql = "INSERT INTO Workers(id,firstname) VALUES("+newID+","'"+firs+"'");
stmt.executeUpdate(insertSql); -
Tehát vegyük át még egyszer. URL NEM tartalmazhat space-t. A paraméterek nevei NEM tartalmazhatnak space-t, a paraméterek értékei igen, encode-olva. Ha pár apróságot figyelembe veszel, könnyebb lesz az életed.
Természetesen a szabványoktól el lehet térni, csak nem érdemes.
Igen, éppen ezért akartam formázni. Nem véletlen hogy stringben volt
De erre láthatóan nincs automata megoldás, csak a replace. replace(" ", "%20"); -
Ez viszont vicces: az URL osztály nem kódolja rendesen URL-é a beadott a stringet. Openstreamnél simán elküldi a spacet pedig valami %20-al kéne helyettesítenie, aztán a szerver dobja is 400-as hibát rá.... Nagyon jó, még egy replace(" ","%20") gányolás....
http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URLEncoder.html
-
A metódus elé tegyél egy annotációt:
@SuppressWarnings("unchecked")
public String toXml() {
StringBuilder xml = new StringBuilder();
if ( this.emp!=null && !this.emp.isEmpty() ) {
for (Employee employee: this.emp) {
// employee to xml, ahogy tetszik.
// TransformerFactory tf = TransformerFactory.newInstance();
// Transformer t = tf.newTransformer();
// DOMSource source = new DOMSource(doc);
// StreamResult result = new StreamResult(new File("xmldoc.xml"));
// t.transform(source, result);
// return result.toString();
xml.append(employee.toXml());
}
}
return xml.toString();
} -
Nekem is tetszik, bár nem kedvelem az ötletet, hogy a GUI-t programkódban állítsuk elő, a deklaratív, JSF-es megoldás nekem jobban tetszik ebből a szempontból.
Van deklaratív lehetőség is a GWT-ben
UIBinder.Egyeébként ha GWT, akkor csak a sztenderd GWT...minden keretrendszer drámaian rontja a teljesítményt, ráadásul mindegyik bevezeti a saját kis megoldásait, amitől már teljes az inkompatibilitás.
-
Egyetértek.
Ezért hanyagolom én speciel a JSF-et többek között. DOM fa nagyság és third party library-k
Richfacessel voltak nagyon rossz tapasztalatok...aztán lett GWT és JSP..ahogy éppen az adott feladat megkívánja.Persze, a GWT-ről lehetne komoly vitát nyitni, de okosan kell használni és akkor nincs gond
-
Szóval a JSF hátránya nem a nagy DOM fa
Minden weboldal hátrány a nagy DOM fa. Alapvetően egyetértek a leírtakkal, de a nagy DOM-tól a hidegrázás szokott kerülgetni. Saját CSS, satöbbi miatt.
A nagy DOM sajnos a kódgenerálás hátulütője, de szerintem nem akkora probléma. Egy üzleti alkalmazásnál sokkal fontosabb a funkcionalitás és a konzisztens "look-and-feel". Pixeltologatás kevésbé. Mennyit lehetne nyerni vele, ha kézzel állítaná össze valaki a html kódot, az eredeti DOM 30%-a lenne elhagyható? A böngészők gyorsak, a szerverek gyorsak, a hálózati forgalom GZip tömörítéssel megy, a renderelésben pár ms-et nyer vele az ember.
A probéma akkor van, amikor generált layoutba bele kell nyúlni saját CSS-sel, ahogy mondtad. Pl. icefaces minden köré <span> taget generál, így sokszor az xhtml-be tett style vagy styleClass elem nem azt a DOM elemet fogja változtatni, amire számítok, szóval ja, ebben igazat adok. Csak azt mondom, hogy ez nem a legfőbb probléma. -- bár annak, aki csak ezt csinálja lehet, hogy az
Egyébként pedig szerintem, ha egy egyedi megjelenésű oldalt kell készíteni, akkor csak az alap <h:> tagek és sima xhtml kód jöhet szóba a faceletben. Ennek egyébként megvan az az előnye is, hogy nem kell fogni a fejünket, amikor fejlesztés közepén derül ki, hogy bugos egy 3rd party komponens library egyik eleme
-
Ezt próbáld meg!
TransformerFactory tf = TransformerFactory.newInstance();
Transformer t = tf.newTransformer();
DOMSource source = new DOMSource(doc);
Writer outWriter = new StringWriter();
StreamResult result = new StreamResult( outWriter );
t.transform(source, result);
StringBuffer sb = outWriter .getBuffer();
return sb.toString(); -
Hmm. Azért dob java.lang.UnsupportedOperationException: Not supported yet. hibát, mert a toXml() metódusod ezt tartalmazza:
Object toXml() {
throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
}Tehát qrva jól működik.
DE!! Ez csak egy generált kód..neked ezt kell tartalommal feltöltened!
Valami ilyesmivel:public String toXml() {
String startElement="<element>";
String endElement="</element>";
String startNameElement = " <name>";
String endNameElement = " </name>";
return startElement+"\n"+startNameElement+this.name+endNameElement+"\n"+endElement;
}Persze, nem ilyen primitív módszerekkel, hanem pl. Sax,DOM...akármi...
Ilyen toXml metodus hianyzott az Employee osztalybol?
https://gist.github.com/anonymous/5453407
mar latom at kell meg irni.... a return statement
es a public string toXml -t
vagy marathat így ezzel a public void toXML(){ es ilyenkor nincs public statement,....
de a xml.append(employee.toXml()); meg mindig piros felkiatojel
-
orej - array akart lenni ( angolul ejtve)
http://i.imgur.com/9qXHBwL.jpg sajna nalam ez jott elo
alt+enter -el azt a tippet adta hogy keszit egy bikeshop.emloyee ben egy toXml metodust... ramentem es eltunt a hiba.
ez a metodus keszit egy xml-t... ha meghivom a mainben?
orej.toXml(); így?
-
Gyakorlatilag a Java fejlesztésnek az egyik alapja, hogy addig nem kell semmit megírni, amíg meg nem győződsz róla, hogy nem írta-e meg valaki más már
Szerintem olyat alapból nem lehet. Az ArrayList egy konténer, ami különféle objektumokat tárol. Az objektumokhoz lehet XML parsert/marshallert/serializert/ahogy tetszik írni, ami végigmegy az ArrayList elemein és azokat egy XML-be írja bele. Mondjuk ha az ArrayList-ben String-ek vannak:
<element>
<value>egy</value>
</element>
<element>
<value>ketto</value>
</element>
<element>
<value>harom</value>
</element>
<element>
<value>negy</value>
</element>Ahol is az <element></element> reprezentál 1 darab ArrayList elemet. Azt, hogy miként rakod XML-be, a saját XML makered szabályozza.
Melyik osztalyba kell megirni az xml makertt?
ehhez az osztalyhoz van kapcsolva az ArrayList:
https://gist.github.com/anonymous/5452699Ez pedig az arraylistes:
https://gist.github.com/anonymous/5452091
De viszont arraylisthez hogyan kell osszekapcsolni az xml maker,...meg szamotse fogadott el nekem csak szoveget.
-
Szóval, az, hogy a Netbeans-ben hogy kell csinálni, nagyon rossz irány. Netbeans-tól függetlenül is működne kell az ilyen dolgoknak.
Ha van SQL scripted, akkor az egyik irány lehet, hogy felparseolod, mondjuk ';' delimiterrel, majd egyesével szépen lefuttatod az SQL parancsokat, amik benne vannak.
Pl:
CREATE DATABASE test;
CREATE TABLE table1(id int, name varchar(12));Ez konkrétan két utasítást fog egymás után végrehajtani. Nyilvánvalóan adatbázisszervertől függ a pontos szintaktika.
Aztán ha megvan, akkor lehet mindenféle Java-s okosságokat csinálni.
Itt van példakód is: [link]
-
Nem kötelező. A pom.xml-ben lévő összes függőség letöltődik, feltéve ha elérhető a repókban. Viszont ha eltérő verziókat használsz mondjuk fejlesztői és produktív módban, akkor érhetnek meglepetések, szóval érdemes egységesíteni.
Oks, köszi.
Egy másik kérdés, mindenkinek:
Melyik webes frameworkot ajánlanátok kisebb weboldalak létrehozására? Eredetileg ezért választottam a Grails-t, és esetleg gyors tanulási lehetőséggel bír, vagy sokan használják.
Spring-et ide túlnagynak érzem. (Pl.: egyszerű blog oldal) Vagy inkább sima JavaEE-t használjon az ember? -
Ez a diagram azt is mutathajta, hogy sok helyen keresnek EE fejlesztőt, de nem találnak, mert lassan mindenki átmegy Springre. Sokkal jobban mutatna egy olyan grafikon, hogy hány helyen használnak Springet aktívan és hány helyen EE-t
Ha már flame, legyen kövér
Lehet, hogy igazad van. Arra viszont jól emlékszem, hogy a Spring developerek, akikkel eddig találkoztam, mind melegek voltak. EGYTŐL-EGYIG!
-
Struts2 vs Spring? Nem összehasonlíthatóak
Szerintem a Spring lassan platform lesz
Ez a lényeges mondat. Annyi módosítással, hogy szerintem már az!
Miért Spring? Azért, mert nem kell hozzá applikációs szerver. Egy sima Tomcat/Jetty-vel is simán elszalad, ami egy EE alkalmazásról nem mondható el. Sőt, egy jól megírt Spring alkalmazás fut servlet konténerben és applikációs szerverben is. Mindamellett ugyanazt a funkcionalitást nyújtja, mint egy EE konténer (jó, dinamikus kontext nincs, de embert nem láttam még, aki használta volna)
Nem akarok flame-t nyitni!!
Pedig kihúzod a gyufát!
Az a baj, hogy nem tudom megítélni, hogy helyes-e az alábbi diagram, ami azt mutatja, hogy a Java EE-re a kereslet nagyobb mértékben nőtt, mint Springre, vagyis fejlesztőre.
http://www.indeed.com/jobtrends?q=%22Spring+framework%22%2C+%22Java+EE%22&l=&relative=1
(De igazából nem tudom eldönteni, hogy mennyire hiteles ez a diagram)
DE. A Spring egy jó framework, máskülönben nem használnák, és szerintem innovatívabb is, mint a Java EE, gyorsabban mozog az új technológiák felé. Mindkét keretrendszert nagyon sok helyen használják. De az eredeti kérdéshez visszatérve, ha konkrétan tudja valaki, hogy Springgel kell/akar foglalkozni, akkor azt tanulja előbb, és ne a Java EE-t
-
Az EE egyre inkább háttérbe szorul a Springgel szemben.
A Springgel érdemes kezdeni szvsz, mert aki ismeri a Springet, az nagyon könnyen tud átnyergelni EE-re, de csak EE ismerettel a Spring a vérhugyozás kategóriája.
Itt a 3-as Springről beszélek. Az előző változatok az XML tengere....bottal nem nyúlnék hozzá. Spring is támogat JSF,JSP techonlógiákat.
A Spring is egyébként egy qrva nagy framework/tool/solution halmaz.
Van Spring MVC, Sping JS, Spring Webflow, Spring Security.....sorolhatnám napestig. Ezekből a Spring Security és az MVC már de facto szabvány.
Hm, nem tudom, én már 1 éve nézegetek Java-s állásokat (szerencsére Isten nem szeret
) és ha Spring-et kértek volna akkor azt külön jelezték, vagy még a Strut2-t láttam népszerűnek.Java EE kiselőadást kellett tartanom és hát, amikor nézegettem a fórumokat elég nagy vita van ebből a Java EE vs Spring dologból, én nem is mennék bele
. De én sosem dolgoztam bennek, csak tanulgattam őket, így nem tudok bővebbet mondani .
Bár a Spring elég dinamikusan nő és nagyon megy a fejlesztés is ezerrel. Lehet tényleg érdemes a Spring-gel kezdeni, mert ahogy olvastam a Java EE7-hez még a cache api sem lesz benne, amit már nagyon vártak... (valami Jcache).Mivel foglalkoztam ASP.NET-tel nekem nem volt nehéz megérteni a Java EE alapjait
mástól nem hallottam vissza ezügyben semmit.Szerintem a Spring lassan platform lesz
(tényleg rengeteg eszköze van) -
FileOutputStream helyett ByteArrayOutputStream-et használj!
A someFile.getName() helyett notificationBean.getAttachmentFileName(),
a someFile helyett pedig a ByteArrayOutputSream megfelelő metódusát.MimeMessageHelper helper = new MimeMessageHelper(message, true);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
baos.write(notificationBean.getFileAttachment());
helper.addAttachment(notificationBean.getAttachmentFileName(), ????)addAttachment második paramétere lehet File, InputStreamSource, DataSource. Tehát ezek valamelyikére kellene konvertálni a ByteArrayOutputStream-et, aminél nem találtam megfelelő metódust egyelőre.
-
Peter Kiss
őstag
Nyilván az nem derült ki, hogy a kolléga mire akarja használni. És igenis, lehet az, hogy csak az egyiket írom felül. Ha egy listába rakom és csak a contains() metódust hivogatom rá, akkor bőven elég az equals() metódust felüldefiniálni.
Nem véletlenül írtam, hogy alternatív megoldás és nem az üdvözítő.
-
Peter Kiss
őstag
Superhun megoldása teljesen jó.
Viszont ha már saját osztályt használsz felüldefiniált metódusokkal, akkor szerintem elég az equals felüldefiniálni úgy, hogy a String és az int egyezőség esetén adjon vissza TRUE-t és akkor egy "sima" ArrayList-be is teheted. Persze attól is függ, hogy mennyi elemed lesz, mert nagyon sok elem esetén az ArrayList nem túl gazdaságos. Nem mondom, hogy Superhun vagy az én megoldásom a jobb, az enyém egy alternatív, de valamivel egyszerűbb megoldás, mert csak 1 metódus felüldefiniálását kell megcsinálni, de mint írtam, sok elemnél nem feltétlenül gazdaságos.
-
nekem ez nem tartott sokáig, főleg úgy, hogy eclipse megvolt nyitva
véleményem szerint ha vki programozással szeretne kezdeni, akkor ne ugorjon neki azonnal az OOP-nek
érdemes sima C -vel kezdeni, egyrészt azért, hogy pl. tisztában legyen a ? : kifejezéssel
persze nekem is van még sok mindent tanulnom
-
WonderCSabo
félisten
-
WonderCSabo
félisten
-
Bár ilyen egyszerű lenne, ügyfélnél 1.5-ös verzió van
Mondjuk azt én sem értem hogy még miért... alkalmazkodnunk kell, ez van, többször is javasoltuk már a frissítést.
Még annyi problémám van, hogy így az ant scripttel történő generálás (wsimport) nem megy. 1.6/1.7jdk-val minden ok. -
(aminek a többségéről nem is tudok mindent),
Aham, tehát a Java a szar...
Egyre jobban értem azt akik ócsárolják a java-t tele van, lehetetlen dolgokkal, olyan triviális apróságokkal kell szenvedni vele hogy az hihetetlen.
Nem kötelező használni....tudod, Kun Béla egyszer azt mondta, hogy ha a kupleráj nem megy, akkor nem a bútorokat kell kicserélni, hanem a kurvákat....azok ócsárolják, akik Hozzád hasonlóan nem hajlandóak tanulni, fejlődni...új dolgokat megismerni.
Aki valóban meg akar oldani egy problémát, az nem a kifogásokat keresi, hanem a megoldást. A SAX parser kiváló megoldás lehetett volna, de dolgozni kell vele..igen. Az élet kemény.
csakhogy mint utána olvastam, ez nem is annyira kupleráj
ennek a kötelezően lezárós formátumnak canonical xml a neve, és ez is egy szabvány. -
Akkor a fájlbaírást kellene kicsit átnézni
Javaslom egyébként a sax parser használatát a DOM helyett....nézegethetem, nem lehet vele mit tenni. A transformer egyben adja ki az egészet, 1 stringbe megy. És a java mint írtam megbolondul egy bizonyos stringhossz után (sorok elejét lehagyja, randomban eltologatja a tageket, stb).
a sax nagyon dzsunkának néz ki, kb olyan mintha binárisba kódolnék programot És biztos hogy a végeredmény is ugyan ez lenne. -
Peter Kiss
őstag
-
Nem elég részletes a workaround. Belenyúlt a gyári osztályba vagy csak egy @Override-t használt?
Szerk:
http://developer.classpath.org/doc/javax/swing/ProgressMonitorInputStream-source.html
Elvileg egy extend elég lenne, csak a ProgessMonitor ugyancsak int-et vár és nem long-ot.
76-93Szóval azt is extendálni kellene...
-
Peter Kiss
őstag
-
WonderCSabo
félisten
-
Peter Kiss
őstag
-
WonderCSabo
félisten
Az egész koncepció szerintem téves. Alapból a Car osztály Tyres collectionjához semmilyen módon nem kellene biztosítani hozzáférést. addTye(Tyre t), removeTyre(Tyre t), stb. metódusokon keresztül kellene csak engedni az elérést, különben az eredeti problémához hasonló eredmények születnek....én kapásból a setTyres(List<Tyre> tires) metódust nem is implementálnám...
-
Az egész koncepció szerintem téves. Alapból a Car osztály Tyres collectionjához semmilyen módon nem kellene biztosítani hozzáférést. addTye(Tyre t), removeTyre(Tyre t), stb. metódusokon keresztül kellene csak engedni az elérést, különben az eredeti problémához hasonló eredmények születnek....én kapásból a setTyres(List<Tyre> tires) metódust nem is implementálnám...
-
Az egészet nem értem egyébként.
Car car = new Car();
car.addTire(new Tyre(10));
car.addTire(new Tyre(11));Ez a 3 sor megcsinálja azt, amit itt szeretnél tenni...
List<Tyre> carTires = car.getTires();
System.out.println("Before: " + carTires.size());
car.setTires(carTires);Gondolom, azt vártad, hogy lesz egy 4 elemű listád [10,11,10,11] értékekkel? Vagy mi volt az elképzelés?
Egyébként így működött volna:public class Car {
private List<Tyre> tires = new ArrayList<Tyre>();
public void setTires(List<Tyre> t) {
this.tires.clear();
this.tires.addAll(t);
}
// Egyéb lekérdező metódusok
}
public class CarTest {
public static void main(String[] args) {
Car car = new Car();
car.addTire(new Tyre(10));
car.addTire(new Tyre(11));
List<Tyre> carTires = car.getTires();
System.out.println("Before: " + carTires.size());
Car anotherCar = new Car();
anotherCar.setTires(carTires);
System.out.println("After (1): " + car.getTires().size());
System.out.println("After (2): " + anotherCarTires.size());
}Kérdésedre válaszolva ezt a minta feladatot láttam valahol mint java-s teszt. Először elméletben találtam mellé, aztán megnéztem Eclipse alatt, de nem értettem, hogy miért keletkezik a hiba.
Annyit PHP-ztam az elmúlt időszakban a munka miatt, hogy kopik a Java tudásom... úgyhogy vizsgák után egyből akarok gyakorolni, meg hát voltam közben életem első Java-s interjú tesztjén...
Mondjuk úgy, hogy a vereség arra ösztökél, hogy jobb legyek... :/Ha magam kellett volna, hogy programozam, akkor nem így csináltam volna természetesen
-
WonderCSabo
félisten
-
WonderCSabo
félisten
-
WonderCSabo
félisten
Az egészet nem értem egyébként.
Car car = new Car();
car.addTire(new Tyre(10));
car.addTire(new Tyre(11));Ez a 3 sor megcsinálja azt, amit itt szeretnél tenni...
List<Tyre> carTires = car.getTires();
System.out.println("Before: " + carTires.size());
car.setTires(carTires);Gondolom, azt vártad, hogy lesz egy 4 elemű listád [10,11,10,11] értékekkel? Vagy mi volt az elképzelés?
Egyébként így működött volna:public class Car {
private List<Tyre> tires = new ArrayList<Tyre>();
public void setTires(List<Tyre> t) {
this.tires.clear();
this.tires.addAll(t);
}
// Egyéb lekérdező metódusok
}
public class CarTest {
public static void main(String[] args) {
Car car = new Car();
car.addTire(new Tyre(10));
car.addTire(new Tyre(11));
List<Tyre> carTires = car.getTires();
System.out.println("Before: " + carTires.size());
Car anotherCar = new Car();
anotherCar.setTires(carTires);
System.out.println("After (1): " + car.getTires().size());
System.out.println("After (2): " + anotherCarTires.size());
} -
az a gondom, hogy eddig javaban csak ablakban / konsolon futó programokat írtam (azt is kb 3-4 éve) és most kell gyorsan átnyargalnom grassfish-es webes mókára
Kemény lesz...teljesen más világ.
tudom de muszáj mert egy kolléga elment a cégtől ahol dolgozom és kitalálták, hogy vegyem át a munkáját
. Az utóbbi 3-4 évben szinte csak php,apache,linux-oztam szóval külön nehéz ...de a projekt forrásait meg nem találom csak a jar és class cuccokat
...
Egyébként továbbra is az a véleményem, hogy már design szempontjából célszerűbb loopon kívül deklarálni ebben az esetben a streameket. 
mástól nem hallottam vissza ezügyben semmit.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Kingston KC3000 PCIe 4.0 NVMe M.2 2TB-os, bontatlan SSD, 2 év garanciával eladó!
- Samsung 990 Pro 1TB-os PCIe 4.0 M.2 NVMe 2280 SSD, bontatlanul, 2 év garanciával eladó!
- ADATA Legend 900 Pro 2TB-os PCIe Gen4 M.2 NVMe 2280 SSD, bontatlanul, 5 év garanciával eladó!
- AMD R7 350X és RX550 VGA kártyák
- Megvigyázott, 3,5 éves, 128 Gb, iPhone 13, 81% akku
- LG UltraWide 34WQ75X-B IPS Monitor! sRGB 99% / 3440x1440 / 5ms / 60Hz / DAS
- GAMER PC! i5-13500 / RTX 3070 Ti / 16GB DDR / 512GB NVMe / 650w!
- Bomba ár! Lenovo ThinkPad X390 - i7-8G I 16GB I 256SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- Dell Latitude 7410 Core i5-10310u, 16GB RAM, SSD, jó akku, számla, 6 hó gar
- Thermalright Phantom Spirit 120 SE
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest