- A hagyományos (nem okos-) telefonok jelene és jövője
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Fotók, videók mobillal
- iPhone topik
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Android alkalmazások - szoftver kibeszélő topik
- VoLTE/VoWiFi
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Szívós, szép és kitartó az új OnePlus óra
Új hozzászólás Aktív témák
-
PumpkinSeed
addikt
A Consult nem csak azért érdemes használni, mert config-ot változtat automatikusan, hanem mert nagyban elősegíti a rendszered stabilitását. Pl.: Leáll valami, addig oké, hogy automatikusan újra is indul, de honnan fogja tudni, hogy a barátja felébredt-e már. Ha mondjuk systemd-vel van mendzselve a dolog akkor egy PreExecStart ami megoldja ezt a problémát, de 200 szolgáltatás esetén ember legyen a talpán aki átlátja. Szóval a Consul használata semmi máshoz csak jóhoz vezet. Szépen mindent le lehet kérni az adott szolgáltatásokról, és hiba esetén load balance is van, ha épp az amit keres nem elérhető. Viszont IP címek helyett domain neveket kell használni. Mi próbáltuk etcd, zookeeper megoldásokat, de a zookeeper eleve egy hulladék volt a memory overheadek meg a sok kiegészítőszükséglet miatt, az etcd már jobb, de azzal meg az volt a baj, hogy amit a Consul alapból támogat ahhoz az etcd-nek kell 3-4 plugin.
Amúgy is a microservice technológia nem létezik Service discovery nélkül, ahol az egyetlen hátrány, hogy a Consul csak docker esetén tud service discovery-t, és épeszű ember nem használ docker-t production-ben. -
floatr
veterán
Az ok, hogy vannak kötöttségek, de abban igaza van, hogy elég elbaltázott dolog az, ha egy rakat alkalmazás fut egy helyen és nem férnek hozzá egy közös adatbázishoz.
Amúgy nem tudom, hogy ennek az általad vázolt szisztémának milyen erőforrásigényei vannak, de kicsit úgy érzem, hogy túllősz a célon. Ennél sokkal kevesebb eszköz-ráfordítással is meg kéne tudni oldani (ami nyilván időben viszont több lenne mint 3 óra). Nálunk jboss clusterek vannak, aminél a jgroups eleve ott van, én azt használnám egy ilyen hálózat kiépítésére, ha nagyon cizelláltan kéne megoldani, de a legtöbbször a cizellált megoldásokat senki nem fizeti ki. -
skoda12
aktív tag
Bambano ötlete szerintem nem elvetendő.
Ansible szerintem már kb bármilyen VCS-ből le tud szedni valamilyen tagelt vagy release branchen levő stabil configot minden hostra az alkalmazásod mellé property fájlként. Az alkalmazásaid pedig apache common configurationnel újraindítás nélkül újra tudják tölteni a fájlokat és triggerelni a listenereket, ha változás történik.Így tényleg nem kell +1 rendszert üzemeltetni, monitorozni.
-
bambano
titán
"Es kerdes, hogy mondjuk service discoveryt irjunk mi, vagy hasznaljunk software defined networkinget?": helyes válasz: egyrészt elkerüljük, hogy service discovery-re legyen szükség, másrészt ha nem kerülhető el, akkor alap oprendszer cuccokkal oldjuk meg.
"De hiba mindenben van.": így van. vagyis a hibák össz-számát azzal tudod csökkenteni, ha a felhasznált komponensek darabszáma konvergál az elvi minimumhoz.
"A Docker nem tokeletes (sot, bugos fos), csak osszevetettem egy csomo minden massal, es per pillanat ez a kombo oldja meg a problemakat kozeptavon.": bare metállal is összevetetted?
egyébként is a docker meg az openstack környékén épp most tört ki egy orbitális balhé, úgyhogy bajban leszel.
"tehat inkabb human kerdesrol van szo.": lehetett érezni, hogy pebkac van
ha te üzemeltetsz egyedül, akkor nem elosztott csapat. maximum ki kell verekedned a csapatban a téged megillető pozíciót, ami szociológiai probléma. de sokat segít, ha csak nálad van root jelszó, a többi meg max. kibicel.
a service discoveryre visszatérve: ezzel, hogy úgy működik a hálózat, hogy bedobsz egy service-t és azt a többiek majd felfedezik, szemléletbeli problémát látok. ha te felügyeled a teljes lomot, akkor nem discoveryt kell csinálni, hanem leltár alapján beállítani azt, amit felfedezni kellene. ha politikai irányból szabad példát hozni, akkor amit csinálsz, az a szabadversenyes kapitalizmus. elkezdődik egy szolgáltatás, a piac meg vagy észreveszi, vagy nem. amit én javaslok, az a komcsi módszer: központi tervintézet előírja mindenkinek, hogy pontosan mit kell csinálni. ez utóbbi szerintem sokkal egyszerűbb.
a felskálázásról meg az a véleményem, hogyha 1000x teljesítményre kell felskálázni a cuccot, akkor bizonyára van már a plusz lóerőből valamennyi, ami majd ehhez kell. azon a plusz lóerőn kell felépíteni az új rendszert, új szemlélet szerint, nulláról, és nem a régi rendszer farigcsálásával konvergálni valamerre. ha meg nem tudnak pár plusz szervert biztosítani ehhez, akkor ott kell őket hagyni a fenébe.
"Postgres ele olyan interfeszt rakni hogy tudja azt, amit nekunk kell, az sokkal tobb melo.": ha jól láttam, két dologra akarod használni a consult: egyrészt értesüljön a gép, hogy konfig váltás volt, másrészt megkapja a konfigot. mindkettőre triviálisan megfelel a postgres, különösebb fejlesztés nélkül. egyébként sem tudok elképzelni adatbáziskezelő nélkül ilyen projektet, tehát valami már úgyis van alatta. ha nem postgres, akkor mysql, teljesen mindegy, a postgrest csak példának mondtam.
-
bambano
titán
nem ezzel a konkrét rendszerrel van bajom, hanem azokkal az architektekkel, akik úgy terveznek architektúrákat, hogy az üzemeltetés szempontjait nem veszik figyelembe. utána meg a rendszergazdák beleszakadnak, hogy életben tartsák a lomot. az ilyen "összehord a szél nagy halomba egy csomó appot, és üzemeltesd" hozzáállásból hosszabb távon mindig katasztrófa lesz.
tudod, hogy honnan lesz ezekhez a cuccokhoz supportod? elhiszed, hogy most nincs bennük hiba? elhiszed, hogy legalább addig nincs bennük hiba, míg meg nem unod és fel nem mondassz? (attól kezdve MVP: MásValaki Problémája lesz). biztos vagy benne, hogy nem hagyják abba a fejlesztését?
a másik probléma egyes architektekkel, hogy fogalmuk sincs a hálózat működéséről. arról meg pláne, hogy hogyan lehetne ugyanazt sokkal egyszerűbben megoldani.
a unix alapelve: KISS. keep it stupid and simple. ami nem kell, azt hajítsd ki, különben felesleges kockázatot vállalsz.
a magam részéről, ha választanom kellene, hogy consult rakok fel vagy postgrest, a postgres két fényévnyivel győzne. mert postgres lesz. lesz, aki kijavítja a hibáit. lesz hozzá support. consulhoz? weave helyett meg, ha nagyon muszáj, akkor openvpn.
de azt is el lehetne kezdeni firtatni, hogy valójában kell-e docker neked. csak a világ olyan, hogy aki ezt meg meri kérdezni, az eretnek és máglyára vetik.
-
-
bambano
titán
és a node-ok közötti hálózat is támogatja?
nem értem, minek raksz fel egy komplett infrastruktúrát olyan feladatra, amit valószínűleg létező cuccal is meg lehet oldani.például konfig postgresben egy konfig táblában, módosításra trigger, amit figyel az app. adatbázisod nagy valószínűséggel van. vagy dhcp opcióval, esetleg snmp trap-pel is lehet figyelmeztetni.
most arról nem beszéltem, hogy miért nem lehet úgy összerakni az alatta levő infrastruktúrát, hogy ne kelljen érdemi konfig változtatást csinálni. például pont a proxynál valószínűleg lehetne.
-
floatr
veterán
-
-
Szmeby
tag
Valóban, kis ész is kell a programozáshoz.
Legalábbis ha egy Optionallal találkozok, akkor nem hívom rá a get()-et izomból, hanem előtte tesztelem / szűröm / orElse..., hiszen bizonyára okkal lett Optional.
Sokkal többet ér, mint egy getApplication().getServiceProvider().getService()
.call(something.prepare().getValue()); trainwreck közepén felugró NPE.Inkább úgy fogalmaznék, az erkölcsi kényszer adott, a fejlesztő legfeljebb nem él vele. A saját belátására van bízva, mihez kezd. Míg egy null-t úgy be lehet nézni, mint a huzat.
-
floatr
veterán
Szerintem meg egyszerűen óvatosabban kéne bánnia mondatokkal, mert akik most jönnek, azoknak már halvány gőzük sincsen azokról az időkről, amikor a C++ modern nyelv volt. Már abba is beletörik a bicska, amikor elhangzik az, hogy "referencia szerint".
Az meg hogy egyes cégek hogyan interjúztatnak és vesznek fel embereket, nekem egyre viccesebbnek tűnik. Ezért elégeltük meg azt, hogy fél(re)képzett állítólagos fejlesztők jönnek csőstül (lehet a multik lehalásszák a piacot), és van saját képzésünk inkább.
-
WonderCSabo
félisten
Nyilván, hiszen a referencia esetén is a referencia értéke másolódik be, tehát érték szerinti paraméterátadás történik. Viszont azért ez még sem annyira klasszikus érték szerinti paraméterátadás, mint a primitívek esetében. Illetve a mondatommal csak ki akartam emelni, hogy nem áll ami bambano mondott
"ok, tehát a jávában mindig referencia szerinti átadás van, amit ők érték szerinti átadásnak neveznek".(#7790) bambano: nos, a unboxing az közel sem dereferencia, de igen, ott lesz még egy köztes lépés.
-
estro
csendes tag
"A változóknak két fajtája van: primitívek és hivatkozások.
A primitív változók olyan értékekkel vannak tele, amelyek a változó tényleges értékét ábrázolják.
Az objektum típusú változó (hivatkozó változó), azonban az objektum elérésének módját tárolják."
Agyhullám: Java könyvben ez szerepel.
Én nem értem, hogy lehet referencia egy primitív, habár még nem vagyok gyakorlott a Javaban :/.
A referencia változó az egy objektumra hivatkozik aminek vagy van beállított példány változói vagy nincs, ha nincs akkor csak egy sima tulajdonság nélküli objektum, viszont a primitív változó az int, float, double stb... és használat előtt bekell állítani valamilyen értékre.
Jelenlegi ismereteim alapján egyetlen közös tulajdonságuk van, hogy biteket ábrázolnak. De ha bonyolult az okkifejtése akkor tényleg hagyjuk -
bambano
titán
"probalj meg atadni egy referenciat referencia szerint Javaban, nem lehet": következmény: hangsúlyozni, hogy a referencia értékét adjuk át, értelmetlen. további következmény: nem érték szerint van az átadás.
kösz, hogy bizonyítod helyettem az állításomat
mindegy, én nem akarok ebből napokig tartó flame-t, úgyhogy nem erőltetem tovább a témát.
-
floatr
veterán
Nagyon egyszerű a válasz: a @Component annotáció nem örökölhető, ellentétben a @Transactional-lel. Ha azt akarod h a leszármazott osztályod is a kontextusba kerüljön, akkor annak is meg kell adni az annotációt.
Ennek az az egyszerű oka, hogy a komponensek nem kerülhetnek be "véletlenül" a konténerbe, vagy csinálhatsz absztrakt osztályokat, amibe beletörne a CGLib bicskája
Bár lehet h félreértem a problémádat. Ha másra gondoltál, akkor szólj.
-
F1rstK1nq
aktív tag
Ez nem szar, így van kitalálva Springben. Amit megjelölsz @Component annotációval (vagy valamelyik stereotype-jával) az az osztályod lesz Component és működnek rajta a spring specifikus dolgok (pl: Autowired). Ez természetesen a Spring álltal ajánlott implicit mód (Implicit bean discovery and automatic wiring). Lehet expliciten is @Bean annotációval Javaconfig-ból, meg xml config-ból is, de most kicsit elkalandoztam.
Amit te keresel, erre van egy jó kis "best practice" Springben: Csinálj egy üres marker interface-t abba a csomagodba ahol scannelni szeretnél és akkor arra az interfacere hivatkozz a ComponentScan-nél.
pl.: @Configuration
@ComponentScan(basePackageClasses = Application.class)
class ApplicationConfig {}marker interface:
public interface Application {} -
Ez megoldva, de nekem ez az egesz szarnak tunik.
Ha van egy osztalyom, ami egy @Component, akkor ha abbol leszarmazik egy masik osztaly, akkor az ososztalyba nem injektal a Spring Boot anelkul, hogy kulon a leszarmazott osztalynal megmondanam @ComponentScan-nel, hogy az ososztalyt is vegye bele a komponensek listajaba?
-
Oppenheimer
nagyúr
Ha a1 nyom egy yield-et, akkor a1-a10 es b1-b10 szalak kozul valamelyik fog utemezesre kerulni.
Ez alapján annyira random a yield, hogy az is lehet hogy a1 blocked állapotba kerül (hisz másképp nem kerülhetne ütemezésre a1-a10 közül más, mert az a1 foglalja a monitort), de az is lehet, hogy nem változik semmi?
A queued ne tevesszen meg, nincs sorrendiseg ertelmezve a varakozo szalak kozott.
Ez világos.
A queued az, ami nem var semmilyen monitoron, csak preemptalva lett (vagy csak elinditottak, de meg nem kerult utemezesre).
Csak a tisztánlátás végett: ha a példánkban a1 van az A objektum monitorában, és b1 a B monitorában, akkor a1 és b1 ami queued (vagy épp running, attól függ mi van beütemezve).
Yielddel nem csak a1 és b1 közötti ütemezést lehetne befolyásolni?
-
Gyuri16
senior tag
-
Oppenheimer
nagyúr
A productivity és a több paradigma miatt akarom megtanulni. Olvastam ellenvéleményeket, pont azokat a hátrányokat írták, amit te. Igaz olyat nem hallottam, hogy scalaról visszamentek javara, viszont csomó beszámolót olvastam a neten, hogy miért választották a scalat a következő projektünk nyelvének. [link] [link]
-
floatr
veterán
Elég gáz, hogy ez van:
new Long(1) == new Long(1); // false
new Long(1) == 1; // true
new Long(1).equals(new Long(1)); truevérgagyi
Akkor már oldják meg az operátor overloadingot, mert még az is jobb lenne.A servlet meg nyilván manapság nem cél, hanem az érthetőség miatt egy kis kitérő. Senki nem fog ma már servletet gyártani. A mostani projektben is amikor egy 10 évvel ezelőtti servletet akart valaki portolni, inkább REST WS-t ajánlottam, mert a framework miatt csak szopás lenne vele.
(#7379) jetarko semmi gond ezzel. Socket/RMI: hagyjuk; szálkezelés: fontos
De az alapok inkább fontosak, meg hogy mennyire mész utána egy problémának, ha belefutsz. Van olyan, aki csak ül és vár... -
Aethelstone
addikt
A fő gond ezzel a Scalaval az szerintem, hogy a programozás oktatás még nem készült fel erre a nyelvre. Ahogy a linkelt doksi is tartalmazza, nem találnak megfelelő fejlesztőket.
Because it's effectively impossible to hire people with prior Scala
experience (of the hundreds of people we've interviewed perhaps three had Scala
experience, of those three we hired one), this matters much more than it might
otherwise. If we take even the strongest of JVM engineers and rush them into
writing Scala, we increase our maintenance burden with their funky code; if we
invest heavily in teaching new hires Scala they won't be writing production code
for a while, increasing our time-to-market. Contrast this with the default for
the JVM ecosystem: if new hires write Java, they're productive as soon as we can
get them a keyboard.És ez szerintem középtávon nem is fog változni. Ugyanaz a helyzet kb. mint annó, amikor a sok c,pascal,dbase/clipper fejlesztőből akartak OO feljesztőket találni, de egészen egyszerűen egy nemzedéknek "ki kellett halnia" és fel kellett nőnie egy újnak, aki már ezt tanulta célirányosan.
Szerintem...
-
Gyuri16
senior tag
scala engem is erdekel, en ezt akarom atnezni bevezetokent: [link] aztan ha meg nem unom akkor ezt: [link]. leginkabb csak jatek szinten erdekel, reg nem tanultam valamit just for fun..
munkaban javat hasznalunk, es nem ritkan szeretnek valami kifejezobb nyelvvel dolgozni. remelem belathato idon belul hasznalhatunk java8-at, kivancsi vagyok lambdak es collection streamek mennyire lesznek hasznalhatoak.
-
floatr
veterán
Hát néha a klingonos sem az. Nemrég fordult elő, hogy valaki addig kavart az SVN branch-ekkel, hogy olyan is LIVE-ba ment, aminek nem kellett volna. Szó szerint nem release volt, de még csak nem is szabadjára engedték, hanem megszökött. A QA csoport véres hullái rész meg csak azért maradt el, mert mire fizikailag odaért volna a PO, addigra lecsillapodott
-
Oppenheimer
nagyúr
Először is itt egy működő példa |Movies2Actors| *----1 |Movies|:
MoviesEntity class:
@JsonIgnore
private List<Movies2ActorsEntity> characters;
@JsonIgnore
private List<GenresEntity> genres;
...
@OneToMany(mappedBy = "movie")
public List<Movies2ActorsEntity> getCharacters() {
return characters;
}
@OneToMany(mappedBy = "movie")
public List<GenresEntity> getGenres() {
return genres;
}Movies2ActorsEntity class:
private int m2aid;
private int movieid;
private int actorid;
private String asCharacter;
private ActorsEntity actor;
private MoviesEntity movie;
...
@Id
@Column(name = "m2aid", nullable = false, insertable = true, updatable = true)
public int getM2aid() { return m2aid; }
@ManyToOne
@JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false)
public MoviesEntity getMovie() {
return movie;
}És akkor a |Genres| *----1 |Movies|
GenresEntity:
private int movieid;
private String genre;
private int genreId;
@JsonIgnore
private MoviesEntity movie;
...
@Id
@Column(name = "genreId", nullable = false, insertable = true, updatable = true)
public int getGenreId() {
return genreId;
}
@ManyToOne
@JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false)
public MoviesEntity getMovie() {
return movie;
} -
Oppenheimer
nagyúr
De, persze, ezt a MoviesEntity-vel joinolom. Azóta az is belekerült az SO kérdésbe. De a kérdés inkább az, hogy a hibernate honnan szedi ezt a genre_id-t, amikor elvileg helyesen fel van annotálva, hogy genreId van az adatbázisban. MoviesEntity és Movies2ActorsEntity között ugyan ilyen OneToMany kapcsolat van és működik, ahhoz képest semmit sem csináltam másképp.
-
floatr
veterán
Bizonyos fokig a compiler is átver. Még az elmúlt évezredben volt egy olyan hardveres problémája az x86-os prociknak, amikor bejött a pipeline, hogy bizonyos kódegyüttállás esetén az egymást követő utasításokat x lépésen belül egyszerűen nem tudta feldolgozni. Ezt a legtöbb C fordító korrigálta úgy, hogy te nem tudtál róla. Ez a pozitív része az átverésnek, ha jól csinálta. Volt azonban olyan C fordító, ami úgy optimalizálta a fordított kódot, hogy éppen belefutott ebbe a pipeline/cache hibába.
Itt viszont egyik nyelvről a másikra generál egy kódot, amit egy framework keresztimplementáció igyekszik elfedni. A dolog már ott sántít, hogy eltérő implementációkról van szó.
A hibernate/JPA által generált SQL-re inkább nem mondok semmit. Nem véletlen, hogy nagyon kevés a jó HQL/JPQL szakember, mint ahogy az sem, hogy a kritikus query-k mind natív SQL-ben készülnek, vagy tárolt eljárásban. Amit meg a proxy-kkal, ASM/CGLIB meg egyéb témával generálnak, az nem ugyanaz a nagyságrend, amivel egy Java-JS fordításnál szembesülsz.
(#7227) Aethelstone Ja hogy a parse-oláshoz beaneket, milyen igaz. Úgy szar ahogy van
)
Kézzel jobbat gyártottam, és ráadásul tudtam, hol kell a sallangot kicsapni.
De mondhatnád a spring boot-ot is, a hibernate entitás/schema generátorát, meg ilyenek. Nem akarom elvinni a témát a nagyzolás irányába, de ezeket ha tehetem kerülöm, mint a pestisest. Még talán a schema generátor elmegy, de azon is sokat kell utólag szöszölni, mire összeáll úgy, ahogy szeretném, mert nem lehet eléggé teletűzdelni metaadatokkal, hogy mindent normálisan megcsináljon. Sajnizom, hogy rossz véleményem van róla -
Oppenheimer
nagyúr
-
Lortech
addikt
Szerintem arra gondolhat, hogy ha float f = 0.1; -t ír, akkor erre hibát jelez a fordító, mivel a 0.1 literál alapból egy double, de ha 0.1f -et ír, akkor már float.
szerk: ja.
Szóval zolka95, ha
float valami = 3.15;
helyett
float valami = 3.15f; -et írsz, akkor már nem panaszkodik a fordító. -
M_AND_Ms
veterán
A karikírozás, mint fogalom ismert?
Amúgy ezt a "kubikos" megfogalmazást egy számomra igen nagyra értékelt ember mondta, aki egy igencsak jól prosperáló, nemzetközi szinten is sikeres több, száz főt foglalkoztató szoftverfejlesztő céget alapított, alkotott, vezetett és vitt sikerre, egészen a haláláig. Ő tudta, hogy mit jellemez a kubikos hasonlattal.
-
WonderCSabo
félisten
Ezekkel tisztában vagyok. Csak azt mondom, hogy az eredeti problémát így meg lehet oldani.
-
moriak
tag
Konzolon hiba nem volt, tomcat hiba nem volt és most ott tartok, hogy az api-docs URL-re 404-et kapok.
Loggerben a level fejlesztés alatt ALL-on van, kilistázza az összes requestet végég a 2db api-docs URL-el.
Majd fut a swagger és megint kilistázódik az összes request viszont már az api-docs-os url-ek nélkül és így lesz belőle 404! -
WonderCSabo
félisten
12.sor : ArrayList is a raw type. References to generic type ArrayList<E> should be parameterized
13. sor: Type safety: The expression of type ArrayList needs unchecked conversion to conform to ArrayList<Object>Javac meg ezt mondja:
[WARNING] Test/src/Main.java:[12,17] found raw type: java.util.ArrayList
missing type arguments for generic class java.util.ArrayList<E>
[WARNING] Test/src/Main.java:[13,40] unchecked conversion
required: java.util.ArrayList<java.lang.Object>
found: java.util.ArrayList -
WonderCSabo
félisten
Ebben tévedsz, a reflectionnel ebben az esetben valóban le lehet kérdezni az az Integer-t. Ezt használja ki a Guava/Guice/stb TypeToken/TypeLiteral megoldása:
Type genericSuperclass = IntegerList.class.getGenericSuperclass();
ParameterizedType pt = (ParameterizedType) genericSuperclass;
System.out.println(pt.getActualTypeArguments()[0]); -
Aethelstone
addikt
egyszer irtam egy cuccot Hibernate fole, ami okos proxykat/wrappereket gyartott, amik a peldany getter/setter hivasait elkaptak runtime,
Azért azt Te is érzed, hogy ez nem egy tipikus/mindennapi use-case
Másrészt a Java fejlesztők 99%-a anélkül megy nyugdíjba, hogy valaha Reflectiont kellett volna használnia
(Hacsak nem csinál saját annotációkat)
-
floatr
veterán
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- A hagyományos (nem okos-) telefonok jelene és jövője
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen belső merevlemezt vegyek?
- PlayStation 5
- Fejhallgató erősítő és DAC topik
- Milyen légkondit a lakásba?
- Formula-1
- BestBuy topik
- 3D nyomtatás
- Fotók, videók mobillal
- További aktív témák...
- Gombászkönyvek egyben
- BESZÁMÍTÁS! Apple iMac Pro (2017) 5K - Xeon W-2140B 64GB DDR4 RAM 1TB SSD Radeon PRO Vega 56 8GB
- Apple iPhone 14 Pro, Kártyafüggetlen, 1 Év Garanciával
- Nvidia Quadro P400/ P600/ P620/ P1000/ T400/ T600/ T1000 - Low profile (LP) + RTX A2000 6/12Gb
- REFURBISHED és ÚJ - HP Thunderbolt Dock G2 230W docking station (3TR87AA)
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest