- iPhone topik
- Samsung Galaxy Watch7 - kötelező kör
- Bemutatkozott a Poco X7 és X7 Pro
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Android alkalmazások - szoftver kibeszélő topik
- Redmi Note 10S - egy a sok közül
- Itt egy pár fotó az iPhone 17 sorozatról
- Több újítással támad a Xiaomi Redmi 3s
- Garmin Venu X1 - vékony, virtuóz, váltságíjas
- Mindenki Z Fold7-et akar
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Új hozzászólás Aktív témák
-
#20084
hiperFizikus
senior tag
bandi0000
#20083
hiperFizikus
senior tag
válasz
bandi0000
#20083
üzenetére
Nem benned van a hiba !
chatgpt/
A trunk alapú elágazási stratégia előnyei és hatékonysága változhat a projekt sajátosságaitól és a csapat méretétől függően. Néhány előnye és értéke:
Egyszerűség: A trunk alapú stratégia egyszerűsége lehetővé teszi, hogy a csapat könnyen követhesse és megértse a kódváltoztatásokat. Ezáltal gyakran hatékonyabbá válik a fejlesztés folyamata.Gyors visszajelzés: A gyakori integráció és a folyamatos integráció révén a trunk alapú fejlesztés gyors visszajelzést biztosít a kódminőségről és a hibákról. Ez segíthet a hibák korai felfedezésében és javításában.
Konfliktusok csökkentése: A folyamatos integráció révén a kódbázisban keletkező konfliktusokat gyorsan fel lehet ismerni és megoldani, mivel a változtatásokat rendszeresen összefuttatják a főágba.
Együttműködés ösztönzése: Mivel a fejlesztők gyakran integrálják a változtatásaikat a főágba, a trunk alapú stratégia ösztönzi a csapatmunkát és az együttműködést.
Azonban a trunk alapú elágazási stratégia nem minden esetben ideális, és bizonyos körülmények között hátrányokat is jelenthet:Nagy projektek bonyolultsága: Nagyobb projektek esetén a trunk alapú stratégia nehezebben skálázható, és könnyebben keletkezhetnek konfliktusok és egyéb problémák a főágban.
Függőségek kezelése: Ha a projekt függ más projektektől vagy külső erőforrásoktól, a főágban történő változtatások könnyen konfliktusokhoz vezethetnek, különösen, ha azokat más csapatok is használják.
Kultúra és tapasztalat: A trunk alapú fejlesztéshez egyfajta fejlesztői kultúra és tapasztalat szükséges, amely nem minden csapat számára lehet természetes vagy könnyen kialakítható.
Összességében a trunk alapú elágazási stratégia hatékony lehet a kisebb és közepes méretű projektek esetén, különösen, ha a csapat megfelelően fel van készítve és betartja a legjobb gyakorlatokat. Fontos azonban megfontolni a projekt sajátosságait és a csapat igényeit a stratégia kiválasztásakor.
/chatgpt
-
bandi0000
nagyúr
válasz
bandi0000
#19758
üzenetére
Szóval a példa amit kértetek kb így nézne ki:
Egyszerűség kevéért tegyük fel, hogy ez egy Logolós funkció lesz, vár egy string-et,amit tekinthetünk egy TAG-nek, és egy Map-et, amibe bármit belerakunk nyilván egy String lesz a végén
Szóval valahogy így néz ki:
Kotlinba írodott a csoda példám, de talán érthetőTalán már az interactorig értem is így, hogy miért kellett, jó sok mindent lehagytam, szóval tételezhetjük fel, hogy az jó, de ami sötét nekem, hogy miben segít az interactor alatti rész, ugyanis anélkül, hogy a konkrét felhasználáskor ezt csinálnám:
val data = SpecificSecondScreenData()data.name = "Tag"SecondScreenLoggerImpl().log(data)Csinálhatnám szimplán ezt:
PerfLogInteractor().logSecondScreenLogs("TAG",mapOf())interface ILogger{
fun logFirstScreenLogs(name: String, list: List<Any>)
fun logSecondScreenLogs(name: String, attrs: Map<String, Any>)
}
class LoggerImpl(): ILogger{
//Itt azért sok egyéb dolog van, de a lényegi része ennyi:
override fun logFirstScreenLogs(name: String, list: List<Any>) {
ThirdPartyLogger.getInstance().Log(name, list)
}
override fun logSecondScreenLogs(name: String, attrs: Map<String, Any>) {
ThirdPartyLogger.getInstance().Log(name, attrs)
}
}
class PerfLogHelper(){
private val Logger = LoggerImpl()
fun getInstance() = PerfLogHelper()
fun logFirstScreenLogs(name: String, list: List<Any>){
Logger.logFirstScreenLogs(name,list)
}
fun logSecondScreenLogs(name: String, attrs: Map<String, Any>){
Logger.logSecondScreenLogs(name,attrs)
}
}
//Ez a kettő multi modul miatt kell
interface IPerfLogInteractor{
fun logFirstScreenLogs(name: String, list: List<Any>)
fun logSecondScreenLogs(name: String, attrs: Map<String, Any>)
}
class PerfLogInteractor(): IPerfLogInteractor{
override fun logFirstScreenLogs(name: String, list: List<Any>) {
PerfLogHelper.getInstance().logFirstScreenLogs(name,list)
}
override fun logSecondScreenLogs(name: String, attrs: Map<String, Any>) {
PerfLogHelper.getInstance().logFirstScreenLogs(name,attrs)
}
}class SpecificSecondScreenData(): ISecondScreenData{override var name: String = "TAG"override fun getAttrs(): Map<String, Any> {return mapOf()}}
interface ISecondScreenData{
var name: String
fun getAttrs(): Map<String,Any>
}
interface ISecondScreenLogger{
fun log(data: ISecondScreenData)
}
class SecondScreenLoggerImpl(): ISecondScreenLogger{
val interactor: IPerfLogInteractor = PerfLogInteractor()
override fun log(data: ISecondScreenData) {
interactor.logSecondScreenLogs(data.name,data.getAttrs())
}
} -
coco2
őstag
válasz
bandi0000
#19753
üzenetére
Amikor előre tudom, mi mindenre lesz szükségem, az implementációt jellemzően az előre tervezett szerkezet szerint csinálom akkor is, ha az első mérföldkőnél csak kismillió placeholder kerül ide-oda-amoda, mert a funkció még nem kell. Mondjuk olyan esetben nem csak egy interface van ott, hanem legalább egy sornyi komment is, ami a dokumentáció adott fejezetére mutat. Hogy a te esetedben olyasmiről van-e szó, természetesen nem tudom. Ez csak egy tipp.
-
Drizzt
nagyúr
-
coco2
őstag
válasz
bandi0000
#19325
üzenetére
Ha a problémád maga a blocking UI fill, akkor az a probléma függetleníthető a kimondott java-tól, és programozástechnikai. Amit UI-on tenned kell, az placeholderek létrehozása előre, amikbe alap esetben valami indikátort raksz bele. Referenciát tárolsz hozzájuk, hogy a GC nem törölje ki. A feltöltésüket külön szálra rakod.
Ha a UI szálon egyébként van elég gépidő, és csak a hirtelen akadás a ronda, akkor használhatsz időzítőt is főszálon aszinkron technikával. Úgy megúszod a szálak kezelését. Viszont idővel úgyis beleszaladsz abba, hogy túlterheltté válik a UI szál.
Vagy lehet félreértettem a problémádat.
-
válasz
bandi0000
#17402
üzenetére
Ha pl olyan oprenszeren akarnánk futtatni (Elvben nincs ilyen, de ki tudja), ami nagyon régi, és nem támogatná a .Net 6-ot, ott milyen lehetőségek lennének, valami ilyesmire találták ki a Dockert nem?
Nem. Eleve a windowsos Dockernek minimum Hyper-V vagy WSL2 kell, szóval Win10 (meg a szerveres megfelelői) alatt nincs is
Másrészt meg mindenki konténereknél mindenki ugyanazt a kernelt használja, szóval nem egy full virtuális gép, mondjuk azt illetően nem vagyok teljesen képben, hogy ez windowsnál konkrétan milyen megkötésekkel jár (a windowsos Docker egy kicsit amolyan mostohagyerek, igazán Linux alatt érzi jól magát).Azon is gondolkodunk, hogy ezt a TFS szisztémát lecserélnénk Azure-ra, amit már konkrétan én/mi csinálnák az elejétől, mennyire lehet benyolult egy ilyen szisztémát felépíteni 0 tudással?
Amennyire én néztem, az Azure DevOps tulajdonképpen egy felhőre költöztetett TFS, szóval szimplán átmigrálni nem kellene, hogy túl nagy gond legyen, de persze az bármit megnehezít, ha nem értesz hozzá - viszont egyben rengeteg lehetőséget ad a tanulásra
-
dqdb
nagyúr
válasz
bandi0000
#17402
üzenetére
Ha pl olyan oprenszeren akarnánk futtatni (Elvben nincs ilyen, de ki tudja), ami nagyon régi, és nem támogatná a .Net 6-ot, ott milyen lehetőségek lennének, valami ilyesmire találták ki a Dockert nem?
Amelyik operációs rendszer olyan régi, hogy nem telepíthető rá a .NET 6, akkor az valószínűleg olyan öreg, hogy Dockert sem lehet rátenni (Windows esetében biztosan ez az eset).Azon is gondolkodunk, hogy ezt a TFS szisztémát lecserélnénk Azure-ra, amit már konkrétan én/mi csinálnák az elejétől, mennyire lehet benyolult egy ilyen szisztémát felépíteni 0 tudással?
Ez erősen függ a konkrét igényektől és a környezettől, amibe bele kell integrálni. Egy nulláról felépített CI/CD pipeline-ba emberhónapokat is bele lehet tolni, de lehet, hogy pár nap alatt ósszedrótozható.Ha nincsen olyan ember a cégnél, aki teljesen átlátja a TFS alapú rendszer működését, akkor előbb legyen, és csak utána szabad gondolkozni a pipeline bármiféle átalakításán. Eléggé kellemetlen tud lenni, ha nem tudtok release-elni egy ideig.
-
válasz
bandi0000
#17398
üzenetére
Angularban pont ilyesmire találták ki a service classokat (nem tudom, hogy milyen nyelven csinálod, ahol duck-typing van, ott egyszerűbben megy, szigorúan típusos nyelveknél egy kicsit macerásabb, de nem sokkal).
Amikor létrehozod a dialogot, akkor a konstruktorban átadsz neki egy osztályt, aminek egyelten publikus metódusa van, egy getListElements() és a dialógod ezt a metódust meghívva kap adatot, innen kezdve nem kell azzal foglalkoznia, hogy honann és hogyan jönnek az adatok, ő csak egyszerűen megkapja őket (ez unit testnél is hasznos, mert akkor meg csinálsz vmi mock service osztályt, ami a tesztadatokat köpi ki magából, nem kell mögé webservice-t rakni).
A service osztályt meg egyszer megírod, aztán az endpoint címét meg megkapja konstruktorparaméterkent, illetve ha vmi enum is más az egyes osztályoknál, azt meg templatespecializációval megcsinálod.
-
sisi22
aktív tag
válasz
bandi0000
#17129
üzenetére
Szóval így kvázi irreális az, hogy ledobják a papírt, délutánig mondj rá valami óraszámot, de a leírás meg eléggé részletszegény
Dejavu... Huszoneve egy konferencian kellett egy kis prezit tartanom, meg aznap megkerestek, hogy nagyszeru online rendszert csinaltunk, meghivnak egy belso koros tendereztetesbe EU-s finanszirozasu onlany rendszer kiepitesere. Az elso kor utan negy ceg maradt, akkor jottek az erdekes feladatok, a legelso az volt, hogy toltsunk fel egy rendszertervet, es majd a gyoztesnek elaruljak a hardver es sw kornyezetet, hogy mire kell raszabni - na, attol kezdve csak egy ceg maradt versenyben es nagyon csodalkozott a tenderezteto.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
coco2
őstag
válasz
bandi0000
#17129
üzenetére
Szerintem túlgondolod. Simán csak szivatnak
Óraszámot mondani olyan valaki tud, aki ugyan azt a feladatot már vagy 5x megcsinálta. És az az alapja annak, hogy tud mondani valamit. Aki életében először csinálja, teljesen esélytelen. Maximum lehet mondani valami körülbelül x 2.5-ös értéket, aztán remélni, hogy legalább abba biztosan belefér. Példának okáért számlázó program, ami már van a cégnél, és nem túl nagy alkalmazás ezernyi részlettel, hanem csak apróság - 3 hónap elég lesz. Ha nagyobb alkalmazás, oknyomozni kell, és se kép se hang amiből becsülhetsz, mondj rá 3 évet
-
válasz
bandi0000
#17129
üzenetére
Nálunk ez úgy néz ki, hogy az emberünk, aki úgy nagyjából admin szinten ismeri a szoftverünket meg elég jól a területet, ahol alkalmazzák, elmegy tárgyalni az ügyféllel és kiszedi belőle vagy együtt kitalálják hogy tulajdonképpen mit is akar (van, akinek csak halvány elképzelései vannak meg van, aki hosszú követelménylistával jön) és összerak velük egy olyan követelménylistát, ami nagyjából illeszkedik a mi szoftverünk logikájához.
Aztán átvesszük vele mi, fejlesztők ezt a listát, megnézzük, hogy mi az, amit tudunk gond nélkül, mi az, amihez esetleg vmi ravaszabb konfiguráció vagy script kell meg mi az, ami tényleg új fejlesztés.
Következő kör nálunk fejlesztőknél, hogy mit hogyan tudunk megoldani.
Aztán a fejlesztési feladatokat szétszedjük kisebb, nagyjából belátható részekre, függőségek alapján csoportosítjük őket, aztán az egyes részeket planning pokerrel megbecsüljük.
(Fontos lenne itt még egy plusz rész, ahol a tényleges fejlesztési idők alapján megnézzük, hogy mennyire voltunk pontosak és ha nagyon félrement valami, akkor miért, de ezt nehéz megvalósítani: az igényfelméréstől a konkrét megvalósításig viszonylag sok idő tud eltelni, szóval nem feltételnül emlékszünk már, hogy mit miért gondoltunk, illetve az időfelhasználást se trackeljük igazán.)
Ennyiből szerintem látszik, hogy ami igazán fontos, az az első lépésben lévő ember munkája, szerintem azon bukik vagy áll az egész. -
pelyib
tag
válasz
bandi0000
#17129
üzenetére
"Nálunk ugye vannak erre emberek, akik ezt megcsinálják," VS "nekem kell becslés közben gondolkodnom rajta, hogy kell rá nyél is, mert kalapálni akarnak"
Ez azt jelenti, h aki elotted megcsinalja a specifikaciot szarul / hanyagul dolgozik. Az o kormukre kene koppintani."délutánig mondj rá valami óraszámot, de a leírás meg eléggé részletszegény" ilyenre szoktuk adni egy XXXXL t-shirt size-t, ami kb a vegtelen. Ebbol a business szokta erti, h itt meg boven van mit csiszolnia az otleten.
Mi most a RUP-al probalkozunk, szepen lassan vezetjuk be. Szepen vegigvezet, megvan mindennek a helye (nem csak a fejlesztoknek, de a businessnek is), ehhez mondjuk ismerni kell a sajat processeiteket es ahhoz kell adaptalni a RUP-t.
-
skoda12
aktív tag
válasz
bandi0000
#17131
üzenetére
Hát pedig nincs más megoldás és még csak nem is a becslés miatt. Ha nem tiszta a requirement, akkor muszáj szerezni infót valakitől vagy elfogadják, hogy teljesen random lesz lefejlesztve, ami nincs expliciten leírva és ez csak utólag derül ki. Abba tényleg nem szabad belemenni, hogy az egész csapat ott üljön egy ilyen megbeszélésen órákig. Úgyis az van, hogy 1-2 húzóember járul hozzá ilyenkor a megbeszéléshez a többiek meg alszanak vagy neteznek.
-
Ispy
nagyúr
válasz
bandi0000
#17129
üzenetére
Tipikusan az a helyzet, amikor vannak a konzulensek a programozó és az ügyfél között, amivel általában az a baj, hogy ezek az emberek nem programozók vagy nem voltak programozók, így nem is úgy gondolkodnak, nem azokra a kérdésekre adnak válasz és nem úgy, ahogy egy programozó tenné. Ezért is kell neked még pluszban dolgoznod...
Nálunk a programozó közvetlen kontaktban van az ügyféllel, részt vesz a tervezési fázisban is, már akkor feszeget olyan kérdéseket, ami az ügyfélnek csak a bevezetés után 3 hónappal jutna eszébe. Persze ennek is van árny oldala, nem minden kocka tudja megértetni magát halandó emberekkel, szóval ja, nem egyszerű.
És még ilyenkor is előfordul, hogy megbeszéljük, megtervezzük, leírjuk, megcsináljuk és nem válik be valamiért és módosítani kell, mert az élet azt mondta, hogy mindenki kapja be.
-
coco2
őstag
válasz
bandi0000
#17116
üzenetére
Ha futott már a cégnél hasonló project, kérdezősködj kollégáktól, arra mennyi idő ment el. Cégen belül esélyesen copy/paste-elhetsz kódot más projectekből, a rendetlenebb cégeknél jogi finomságokra sosem szoktak figyelni. Ha nem ismered azokat a projecteket, kollégák segíthetnek átlátni, mit hogyan ollózhatsz át. Ha egyedül vagy a káoszban, és semmi világosság nincsen, plusz a könyvelés szakmai részéhez sem értesz, és úgy kell programot írni, jobb, ha előre szólsz, hogy az a project egészben neked túl nagy falat.
-
Drizzt
nagyúr
válasz
bandi0000
#17116
üzenetére
Nálunk ez most úgy megy, hogy konkrétan nincsen becslés. Megmondja nagy vonalakban a business, hogy mi kéne neki. Megmondja, hogy mikorra kell neki. Mi meg ezután kitaláljuk, hogy ebből reálisan mit tudunk megcsinálni és elkezdjük kidolgozni, meg PoC-ként implementálni, hogy minél hamarabb rájöjjenek, hogy mennyi mindent kell még tisztázni rajta.
Ha valakinek nagyon kidolgozott requirement kell, hogy valamin elkezdjen dolgozni, az nálam a junior developer definíciója. Nálam ott kezdődik a senioritás, hogy korlátozott mértékű leírás alapján is el tudjon kezdeni valamit az ember csinálni, ha mást nem, akkor pár értelmes kérdéssel, saját ötlettel visszatérni.
Nagyon kényelmes lenne tűéles definícióból dolgozni, de aki írja ezt a dokumentációt, annak gyakran egyszerűbb rögtön Java-ban írnia, mint angolul egy Jira ticketbe. Hamarabb megvan. -
emvy
félisten
válasz
bandi0000
#17116
üzenetére
> Én részemről az lenne a tuti, ha olyan doksit kapnék, ami alapjàn leülök és lekódolom kérdés nélkül
ilyen nincs, legfeljebb nagyon egyszerű feladatok esetén. Főleg azért, mert ha lenne ilyen doksi, akkor lehetne olyan compilert írni, ami programot fordítana a doksiból.
Minél bizonytalanabb a feladat, annál nagyobb puffert kell hagyni. Nálunk az a szokás, hogy adunk egy 50%-os becslést meg egy 90%-osat. Például : 50%, hogy megvan 3 hónap alatt, és 90%, hogy megvan 5 hónap alatt.
de agilis fejlesztés esetén fordítva szokás nézni: mi az, ami belefér X időbe -
válasz
bandi0000
#16257
üzenetére
Altalanossagban nem igazan lehet erre valaszolni.
- Jatekra nagyon jok, UE es Unity is zsenialisan oldja meg.
- Sima, relative egyszeru, plane webview-os appokra nagyon jok.
- Ennel talan egy fokkal bonyolultabb, de meg mindig relative egyszeru appokra kollegak istenitik a fluttert, hozzateve, hogy vannak azert idegesito hulyesegei, amik miatt sokszor az utolso 1%-a a fejlesztesnek elviszi a fejlesztesi ido 20%-at. Es ezt rendesen megtervezett kodnal, idiota utolagos "csak meg egy dolog, de nyugi, semmi komoly, nektek csak ket kattintas ugyis" nelkul kell erteni. Tervezni kell vele es kesz.
- Bonyolult, teljesitmenyigenyes, de nem jatek appra meg ott a nativ kod. -
-
Silεncε
őstag
válasz
bandi0000
#15549
üzenetére
Én is ezen gondolkoztam, de ez meg tárhelyben sok (+ egy csomó időt elvesz a lista menedzselése)
A leggyorsabb az, amit axioma ír (Knuth), meg gondolom bambano is arra gondol (nem magamtól vagyok ilyen okos, hogy rájöttem (bárcsak), csak axioma korábbi kommentje után utánakerestem
) -
-
#14984
Dr.Szilícium
csendes tag
bandi0000
#14982
Dr.Szilícium
csendes tag
válasz
bandi0000
#14982
üzenetére
A másik választ jóval később akartam elküldeni, megírása is időbe telt, lévén szó egy terjedelmesebb szakmai válaszról. Ezért nem is akartam eldobni, ha már munkát is fektettem bele.
Úgyhogy nem ez volt a gond, ettől függetlenül korábban sem kedveltem ezt az itteni hülye szokást, a válaszok egybeszerkesztését. Ilyenek nehezítik később egy szál visszakövetését, mikor már keverednek a dolgok. Tudom, hogy a fórummotort akarják kímélni, de akkor is kellemetlen. Persze, csak emiatt nem távoztam volna önként erről a fórumról, évekkel ezelőtt.
Most egy másik témában viszont kimondottan kártékony és buta tanácsok ellen is szóltam, főleg azt nem bírtam már nézni. -
vz12
tag
válasz
bandi0000
#14932
üzenetére
Igen, valami "NVL"-féleség akkor megoldás lehet.
A NULL az az eset, amikor csak 1 sor van? (nincs 2 összetartozó sor?)
Akkor a végén a "-1"-et és a "nagy" számot majd vissza kell alakítani NULL-nak.Vagy esetleg lehet "+1" lépésben is:
(1) az első SELECT-be kell egy WHERE: "rpld IS NOT NULL"
(4) "celtabla"-hoz hozzá kell INSERT-elni az "input_table"-ból az "rpld IS NULL" sorokat is a végén, persze azt nem árt figyelni / tudni, hogy a "celtabla" létrejött-e egyáltalán, mert nem létező táblába nem lehet INSERT-elni (illetve ekkor az eredeti tábla egyben a céltábla, nem kell csinálni "semmit") -
vz12
tag
válasz
bandi0000
#14927
üzenetére
TEMP tábla ugye használható?
Az alábbi ötletem van, a szintaktikát a környezetedre kell majd konkretizálni.(1) CREATE TABLE temp AS(SELECT MIN(pld,rpld) pld, MAX(pld,rpld) rpld, qtt FROM input_table)(2) CREATE TABLE celtabla AS(SELECT pld, rpld, SUM(qtt) qtt FROM temp GROUP BY pld,rpld ORDER BY pld, rpld)(3) DROP TABLE temp -
Drizzt
nagyúr
válasz
bandi0000
#14927
üzenetére
Hát, ha befér az összes a memóriába, akkor:
1. Csinál egy mapet, amiben a kulcs egy id pár(pId, rPid), az érték meg maga a sor lesz.
2. Menj végig az összes DB soron. Nézd meg, hogy az adott sor (rPid,pId) párosával szerepel-e már elem az 1-es pont map-jében. Ha igen, akkor update-eld meg a hozzá tartozó sort, s valahogy jelöld meg, hogy a db-be is ki kell majd írni(pl. a kulcsát beteszed egy toUpdate Set<pId, rPid> halmazba). Az éppen olvasott sort meg rakd bele egy toDelete Set<pId, rPid>-be. Sőt, még egyszerűbb egy toUpdate Set<id> setet használni inkább.
3. Amikor végigértél az értékeken, akkor már csak annyi a dolgod, hogy a toUpdate elemeire tolsz egy batch update-et, a toDelete értékeivel jelzett sorra meg egy batch delete-et.Viszon ahogy elnézem a db sorodat... Nem kell a cId-t is belevenni a buliba, s hármasokat keresni inkább a párok helyett?
-
pelyib
tag
válasz
bandi0000
#14927
üzenetére
SQL (bar eleg koki vagyok benne):
left join onmagara (pid = rpid), sum a qtt-re (left join miatt itt figyelni kell, ha nincs masik sor, akkor default 0) group by cid
Ez csak akkor mukodik ha 2 sorod van (de mondom, koki vagyok hozza!)Vagy a sum_qtt-t subselect-tel is meg lehet oldalni. Ez tuti mukodik tobb sorral is.
-
bambano
titán
válasz
bandi0000
#14823
üzenetére
csinálsz egy táblát, amibe belerakod az adott termék/adott rendelés azonosítóit, egy azonosítót, hogy melyik árazási függvénnyel számoltak, és magát a kiszámolt árat.
ezek után x darab program, szubrutin, stb. bármi, lefut, és mindegyik beleönti ebbe a táblába a saját árát.
majd ebből a táblából kiválasztod termék/rendelés azonosító alapján, hogy a konkrét esetben melyik árat érvényesíted. -
válasz
bandi0000
#14827
üzenetére
Ebben az esetben dabadab kollegával értek egyet, ha már ennyi kész van, plusz ilyen ritkán kell változtatni, és ilyen kevés a variáció, akkor nem éri meg szopni egy teljesen generikus rendszerrel meg szétrefaktorálni az agyadat, vésd oda és kész, ha szépen csinálod meg dokumentálod (akár simán kommenteléssel), nincs azzal semmi gond, legalább triviális, de minimum egyszerű debuggolni.
-
válasz
bandi0000
#14823
üzenetére
Egyedi ár mindig olcsóbb, mint a bármi más akciós ár?
Akciós ár mindig olcsóbb, mint a bármi más, kivéve egyedi ár?
Hogy kéne ezt elképzelni? Van egy meglevő terméklista, vagy ilyesmi, illetve vevők, és vevő kaphat egyedi árat, termék kaphat akciós árat? Hogy lehet egy terméknek több ára (ie: maradékból a legolcsóbb)?Valami valós példát be tudsz dobni légyszi, árakkal, ilyesmivel?
Illetve: létező rendszerbe akarunk extra funkciót (akció) vagy nulláról tervezett/írt rendszerről beszélünk, aminek ez lesz az egyik funkciója?
-
válasz
bandi0000
#14823
üzenetére
Addig, amíg tényleg három ilyen szabály van, szerintem a fixen bedrótozott kódnál jobb megoldás nincs.
Majd ha lesz sok, akkor lesz egyrészt értelme annak, hogy ezt az ember valamiféle általános módon kezelje meg akkor fog látszani, hogy hogyan is érdemes a követelményeket lemodellezni (mert ugye ilyenkor az szokott lenni, hogy a három példa alapján kitalálsz valami rendszert, lekódolod, örülsz, aztán másnap valaki kitalál egy negyediket, ami baromira nem illeszkedik abba, amit megcsináltál és vagy széthekkeled a rendszered vagy kezdheted majdnem előről). -
válasz
bandi0000
#14819
üzenetére
Csak hogy jól értem-e a feladatot:
Van n darab függvényed (mondjuk A1, A2, A3 stb) amik visszaadnak egy értéket.
Vannak szabályaid, amik azt mondják meg, hogy a fentiek közül melyik függvények értékei közül kell kiválasztani a (legkisebb? legnagyobb?) értéket, valami olyasmi, hogy min(A1, A3, A17).
És kellene írnod valamit, ami a szabályokat kezeli.
Jól értem? -
haxiboy
veterán
válasz
bandi0000
#14244
üzenetére
Találj ki valami hasznosat, például egy Warehouse management system.
Elég nagy falat, viszont ha jól van megcsinálva, később akár mint open source cucc elég sok felhasználója lehet.
Ha elkülöníted a business logic-ot a presentation layertől biztosan szeretni fogják akár a kisebb vállalatok is, főleg ha valami fincsi API is van hozzá írva amivel 3rd party programok is végezhetnek műveleteket. -
Ispy
nagyúr
válasz
bandi0000
#13989
üzenetére
Az is felmerült bennem, SHA1-el. De tényleg nincs valami szögegyszerű módszerre erre? Mondjuk most az is kiderült, hogy jó lenne mérni szerver oldalon a hivások számát, ki, mikor, mit, szóval azure-ba így is ki kell majd nyulni, szóval lehet csinálok egy webservicet, ami a háttérben kiküldi azure-ba az adatokat és a weboldal meg onnan lehívja, így meg van oldva a havi reportálás is.
-
martonx
veterán
válasz
bandi0000
#13937
üzenetére
Se az amazon s3, se azure blob storage nincs teljesen ingyen, noha annyira filléresek, és havi 1 EUR alatt ki se számlázzák, hogy végülis mondható róluk, hogy ingyen vannak, pár file tárolásakor.
A frontendről egyenesen felhőbe feltöltés a jó megoldás. Viszont ez esetben annyi backendednek akkor is lennie kellene, ami elküldi a signolt urlt, ahova fel kell majd tölteni a file-t, mert gondolom a credential-öket semmiképp nem akarnád frontenden tartani
-
martonx
veterán
válasz
bandi0000
#13931
üzenetére
Felhőben file tárolás kb. ingyenes (Aws S3 vagy Azure blob storage). Innen tudsz futtatni komplett static page-eket, Spa-kat mondhatni ingyen.
Ha kell alá backend api, akkor Aws Lambda vagy Azure Function a legolcsóbb, gyakorlatilag szintén ingyenes.
És ha a backend alá db is kell, akkor kismillió lehetőséged van. Tranzakciós db-k zsebbe nyúlosak, értsd havi pár EUR - tól indulnak mind Aws, mind Azure-ban. Nosql-ek olcsóbbak, azokat ingyen is lehet találni. Felhős NoSql-ek közül az Azure Cosmos Db-t emelném ki, mert egyrészt full ingyenes (is lehet), másrészt nosql-hez képest rohadt sokat tud. Aws oldalról a Dynamo Db hasonló NoSql, elhanyagolható a havi díja, viszont elég buta is sajnos.
Szvsz a két nagy rivális felhoszolgaltató közül Azure egy halvány fokkal jobb (többet ad, olcsóbban, és viccesen könnyű beüzemelni). De a különbség nagyon kevés, leginkább szimpátia kérdése, hogy melyik felhőszolgáltatót választja az ember. Én napi szinten mindkettőt használom.
Összegezve: Azure-ban totál ingyenesen ki tudod hozni NoSql-el, miközben a Cosmos db, egész tűrhető tudású. Aws-ben is lehet, hogy sikerül havi 1 EUR alatt maradni dynamo db-vel (lusta vagyok megnézni a pontos díjait, fejből meg nem vágom), viszont a dynamo db elég kompromisszumos cucc. -
petyus_
senior tag
válasz
bandi0000
#13931
üzenetére
Nekem Azure van egy saját használatra szánt oldal hostolva. Van egy API, ami app-service-ben fur, egy SPA, amit blob storage-ról hostolok, illetve egy SQL DB. Ez összesen kb $25 havonta. Lehetne kevesebb is, ha az app-service kisebb csomagra tenném, de mivel a VS subscriptionömhöz jár $50 havonta, ezért belefér. A CI/CD felsetupolás így elég egyszerű volt, és nagyon kényelmes így fejleszteni.
Ebbből egyébként a blob kb elhanyagolható, $0,15/GB, az app-service $15-20 körül, a DB meg kb $5.
-
haxiboy
veterán
válasz
bandi0000
#13931
üzenetére
Attól függ hogy mennyi adatot szeretnél tárolni és ehhez milyen gyakran szeretnél hozzáférni.
Adatbázist általában külön szerverre szoktuk telepíteni, nálunk a kritikusabb cégeknél van failover is, de ha egy webtárhelyet veszel valamilyen szolgáltatónál, ott ez megoldott. -
bandi0000
nagyúr
válasz
bandi0000
#13930
üzenetére
mondjuk nem szóltam, majd megpróbálom belőni ezt a minio-t
Amúgy sac/kb mekkora egy komplett weboldal éves üzemeltetése, ha pl valami felhő tárhelyet használok az adatokhoz, aztán frontend backend, mondjuk azt nem tudom, hogy kell e adatbázisszerver, vagy az ott fut ahol a backend?
-
haxiboy
veterán
válasz
bandi0000
#13922
üzenetére
Attól függ hogy mire van szükséged.
Egy ismerősnek írtam anno olyan backendet ahol a fileok titkosítva mentek fel, ömlesztve egy helyre, a nevük egy GUID. SQL szerveren pedig az adott userhez tartozik egy key amivel a saját filejait fel tudja oldani, illetve a "könyvtárak" milyen hierarchiát alkotnak, és az adott file melyik "könyvtár" alá tartozik. De a valóságban ezek nem léteznek csupán az adatbázisban.Frontend terén ezzel az infóval azt kezdesz amit szeretnél, SQL szinten valahogy úgy néz ki hogy van 2 tábla, Folder illetve File
A foldernek van egy id-ja egy neve valamint egy opcionális parent ami egy másik folder id-ra mutat. (illetve van egy harmadik tábla ami felmappeli az adott folder illetve file tulajdonjogait/jogosultságait az userekhez/user groupokhoz).De ha nincs szükség jogosultságkezelésre, csak mappatartalmat szeretnél listázni, akkor általában a webszerverek, pl apache vagy nginx-ben van ilyen modul ami kilistázza egy mappa tartalmát.
-
motoflug
őstag
válasz
bandi0000
#13876
üzenetére
Pár napja kiírtam, hogy szeretnék megtanulni programozni, ezzel kapcsolatban gyakorlatilag minden nap megnéztem 1-1,5 órányi videót, és azt tapasztaltam, amit te írtál, és tök jó észrevétel: minden alaptudást igényel. Mivel még nem tisztáztam, hogy melyik programnyelv legyen (a Javascriptet tudnám hasznosítani a munkámban, de a java érdekelne), így pontosan ez az alapozás hiányzik, amit a hozzászolásodban említettél, a problémamegoldás készsége. Basics of programming néven találtam egy-két dolgot, de nem az igazi.
Tapasztalataitok alapján mi lehet a jó 0. lépés, amivel magát a gondolatmenetet tudom magamba szívni? Ész nélkül nem akarok nekiállni és sok időt, energiát beletolni.
-
martonx
veterán
válasz
bandi0000
#13898
üzenetére
1. CKEditor 5-ös verziótól, egész jól segít a képek beszúrásában. Magát a képet semmiképpen se tárolnám db-ben, valahova felhős tárhelyre feltölteném, és a szövegbe csak az url-jét tenném.
2. A nosql fejben teljesen más megközelítést igényel, mint az sql. Felejtsd el a normál formákat, táblánkénti adat struktúrákat. Nem véletlen, hogy a nosql nem is jó minden esetre, leginkább a beömlő nyers adatok gyors letárolásához jó, és sokszor inkább csak kiegészíti a hagyományos relációs adatbázist (ha komplexebb adat struktúra kell).
-
martonx
veterán
válasz
bandi0000
#13879
üzenetére
Attól még tök jó frontendes (css-re gondolok most itt főleg) lehet belőle, ahol meg pont az a jó ha szépérzéke van valakinek.
Én nem jelenteném ki, így kerek-perec hogy ezek az oktatások (pláne ami ingyenes) rosszak lennének / semmit nem érnek.
Noha nyilván ezt én inkább csak egyfajta kedvcsinálónak fogom fel, és ha valakinek meghozza a kedvét, akkor utána majd évekig tudatosan képzi magát ebbe az irányba.
Még mindig jobb, mintha egy több millió Forintos, fél éves XY gyorstalpaló képzés vége felé jön rá valaki, hogy na akkor ez mégse neki való -
-
Silεncε
őstag
válasz
bandi0000
#13876
üzenetére
Ez egy ingyenes kepzes
Egyebkent ezzel egy kicsit vitatkoznek: alap algoritmusokat nem.fog tudni anelkul megerteni, hogy tudna mik azok a ciklusok, a valtozok stb. Nem veletlenul mukodik az egyetem is ugy, hogy adnak egy nagyon alap programozoi tudast, majd ha ez megvan, utana kezdenek algoritmusozni. Az OOP-re meginkabb igaz ez. + az szerintem mocskosul el tudja venni egy kezdo minden kedvet az egesztol, ha nekiallsz rendezesi algoritmusokat meg hasonlokat magoltatni vele (foleg, hogy magara az algoritmusra nagy valoszinuseggel az eleteben nem lesz szuksege) -
Silεncε
őstag
válasz
bandi0000
#13830
üzenetére
Nekem van rá most db oldalon egy kulon fuggvenyem, ami megnezi, hogy ugyanaz a userid (vagy egyaltalan barmilyen userid) jon vissza a REST API-tol mint amit a user postol.
Refresh token db-ben (mar ha van, serverless appoknal en beqrtam a localStorage-ba jovanazugy' cimszo alatt
)De tulajdonkeppen arrol van szo amit mondasz.
-
Silεncε
őstag
válasz
bandi0000
#13827
üzenetére
Nálunk az access token 1 óra lejárati idővel van, a refresh token talán egy hónapig jó. Én most úgy használok OAuth2-t, hogy kliens oldalon beleptetem az OAuth sajat login ablakával (vagy átirányitva, tok8), majd a megkapott authorizatiob tokent kliens oldalon cserelem AT meg RT-re és ezeket kuldom el a szervernek. Korabban hasonloan csinaltam, amikor egy chatbotot irtam, ami OAuth-on keresztul fer hozza megadott idokozonkent a belso rendszerunkhoz, akkor ugy csinaltam, hogy AT-vel elkertem amit akartam, ha lejart, RT-vel refresh, ha valid akkor AT tarol, ha az is lejart, ujra login. Az RT pont arra van, hogy ne kelljen mindig beleptetni a usert, ha lejar az AT (ami altalaban rovid idore szol), hanem a szolgaltatas kerhessen uj AT-t az RT-vel.
Nem tudom ez valasz-e a kerdesedre
martonx: ha jol tudom, nem okolszabaly, hogy a szervernek kell azonositani, lehet kliens authentikaciot is
-
martonx
veterán
válasz
bandi0000
#13827
üzenetére
Asp.Net Core vonalon pont van olyan template ami mindenzt eleve megcsinálja neked. Indíts egy új projektet egy OAuth-os template-tel, és nézd meg a kódját.
Illetve egy helyen zavart érzek az erőben. Ha pl. google Oauth-ot használsz, akkor sem a kliens oldalnak kell a google felé authentikálnia, hanem a szerver oldalnak. És majd szerver oldalon lefut google vs szervered között, hogy sikeres volt-e az authentikációd.
Hiszen utána is a szervereddel áll a js app kapcsolatba, afelé kell minden egyes requestnél igazolnia, hogy jogosult-e. -
haxiboy
veterán
válasz
bandi0000
#13791
üzenetére
Pedig ez a valóság, gyakorlatilag a napi effektív munkám van amikor meghaladja a 15-16 órát mert van 1-1 probléma ami nem hagy nyugodni, és utazás/fürdés/lefekvés/filmezés közben is azon gondolkodok.
Jelenleg például lakásfelújítunk, okosotthont terveztem, home assistant, rengeteg kód. Tele vagyok ötletekkel hogy tudnánk ezt az ERP mellé eladni az ügyfeleinknek -
válasz
bandi0000
#13791
üzenetére
Rosszul szamolsz. Egyreszt lehet ezt csinalni utazas kozben is, masreszt ha mondjuk csinalsz sajat projektet vagy valami hetvegen, legalabb egy napot, az maris rengeteget ad hozza osszesen. Plusz az, amiket neha melo utan is megcsinalsz akar mert otthon jottel ra, hogy lehet jobban es belogolsz gyorsan, akar sajat projektben, akar csak valahol latsz egy erdekes cikket es elolvasod/kiprobalod es ott a vege, hogy melo mellett siman foglalkozol a dologgal napi extra 2-3 orat.
-
haxiboy
veterán
válasz
bandi0000
#13788
üzenetére
Szerintem a valóság pontosan fedi ezt. Én mint akinek a kódolás a hobbija, még munka után is ezzel foglalkozok, noha nem kapcsolódik erőteljesen a munkámhoz (pl. különböző diy projektek) már a gondolat hogy ezeket hogyan lehetne hasznosítani céges környezetben elősegíti a fejlődést. De kivel nem fordult még elő hogy hajnali fél 4-kor (már ha éppen alszik ilyenkor még) ne riadt volna fel arra hogy hogyan lehetne optimalizálni az előző napi kódot
-
-
martonx
veterán
válasz
bandi0000
#13434
üzenetére
Illetve ahogy az állásoknál, úgy a pesti albérletnél is túl magasan van az elvárásod. Ha külföldre mennél, se rögtön egy két szobás havi 2000 fontos (nem vagyok otthon a londoni albérlet áraknál, lehet, hogy keveset mondtam?) albérletet vennél ki a gyakornoki / juniori fizudból, hanem örülnél, ha 4-ed magaddal meghúznád magad valahol.
Na, ugyanígy pesten is simán lehet kezdeni egy egyszobás albérlettel, netán csak egy szobával, nem rögtön a 150K-s albérletet kell lendületből kivenni
Azaz továbbra is azt mondom, hogy előbb a saját fejedben tegyél rendet, és vállalj el kb. bármilyen munkát (otthon / pesten / külföldön mindegy), utána lehet okosodni, tapasztalatot gyűjteni, ráérezni, hogy hogy is, milyen irányba is lenne jobb mozdulni.
Pl. ismerek olyan kollégát, aki PHP-vel kezdett, utána objective-c-vel iphone mobil appot fejlesztett, most meg a Wizz Air C#-os csapatában van. -
skoda12
aktív tag
válasz
bandi0000
#13428
üzenetére
Pedig szerintem jobban tennéd, ha inkább rendesen felkészülnél interjúra még akkor is, ha hónapokig tartana.
Nézd, pályakezdő állásból nincs sok. Ha valahol bukod az interjút, akkor oda általában 1 évig nem tudsz újra jelentkezni. Ha leszűkíted a lehetőségeket, hogy mondjuk téged fixen XY technológia érdekel, akkor nagyon gyorsan végig lehet pörgetni az összes céget, ahova kezdőket felvesznek.
Most rákerestem linkedinen, hogy az országban hány db junior c# állás van. 13 db találatot dobott ki és csomó hamis találat van, mert az egyikben 4 év tapasztalat kell, meg vannak olyanok, ahova tesztelőt vagy cpp-s embert keresnek előnyként feltüntetve a c# tudást. De ez amúgy bármilyen technológiára igaz lesz szerintem.
Ok, a linkedin csak 1 oldal. Lehet, hogy találnék még pár lehetőséget, ha minden álláskereső portált átböngésznék, de tippre nagyságrendileg nem változnának a számok. Így hogy két helyről már elutasítottak és vidéken vagy, szerintem már nem nagyon hibázhatsz a következőnél vagy könnyen költözés és/vagy más technológia lesz a vége, amit nem szeretnél.
-
martonx
veterán
válasz
bandi0000
#13437
üzenetére
Rengeteg olyan maszek munka van kisebb cégeknek, akik nem akarják / tudják a nagy cégek 15-20000 Ft-os óradíját kifizetni, ráadásul nagyon durván felülbecsült óraszámmal. Mégis nekik is kellenek fejlesztések, nem ritkán, egész komoly sok milliós cuccok. Csak amit egy freelancer csapat összerak nekik mondjuk 6 millióból, az egy nagy IT céggel csináltatva, nem állna meg 20 alatt. Miközben a minősége se lesz jobb a drágábbnak (lásd BKV online jegy buktája
).
No, ezek a cégek alkalmazzák a freelancereket, másnéven maszek programozókat. Ha konkrét ilyen projektek érdekelnek, keress meg nyugodtan, folyamatosan keresek embert. -
#13436
instantwater
addikt
bandi0000
#13434
válasz
bandi0000
#13434
üzenetére
Külföldet döntsd el minél hamarabb, mert később csak nehezebb lesz.
Idősebb leszel, családod lesz, beleragadsz az otthoni komfortzónába amiben jó lesz siránkozni, de nehéz kimászni belőle.Az, hogy itt hol és, hogyan érdemes kezdeni az már az Anglia topik témája. Londonország/vidék.
Itt is keresnek juniorokat, de neked kell kiszámolni hol mennyiért laksz/dolgozol és az megéri-e. Nagyon kezdőként ismerős nélkül marad a 3-4-5-en egy lakásban modell. Nekem nem volt itt segítségem, de mivel nem voltam totál kezdő így nem kellett összeköltözni másokkal.
-
Silεncε
őstag
válasz
bandi0000
#13428
üzenetére
Azért lehet vidéken is találni munkát. Én Szegeden vagyok egyetemen, most húzom a 3. évem gyakornokként (duális képzés), de a legtöbb ismerősőm is dolgozik/kezd nemsokára dolgozni. Ha mész MSc-re, mindenképpen keress mellette valami gyakornoki helyet (akár a duálist is megpróbálhatod, ha van az egyetemeden), 0 tapasztalattal sajnos tényleg nehezen fognak felvenni bárhova is főállásra.
Ez az MSc is jó kérdés, én is most gondolkozok, mi legyen vele, elvileg nyáron végzek, utána kezdeném rögtön, de nem tudom, megéri-e még a 2 év... Főleg, hogy munkahely meg lenne, már vagy a harmadik helyről keresnek meg, pedig még diplomám sincs... Vagy akár maradhatnék a mostani helyemen is. Annyi előnye lenne, hogy addig el tudnám dönteni, merre is akarok tulajdonképpen menni...
Egyébként ha nagyon nem találsz semmit, meg lehet próbálni a freelancerkedést is, csinálja több kollégám is, mondjuk ők csak mellékállásban, de az is jobb mint a semmi. Legalább tudsz felmutatni valami portfóliót.
-
martonx
veterán
válasz
bandi0000
#13425
üzenetére
Rosszul állsz hozzá. Ha pályakezdőként túl kevésnek bizonyul valahol, akkor az azt jelenti, hogy túl magas pozícióra pályáztál. Gondolkodás helyett kezdj el bárhol dolgozni, akár csak gyakornokként, és meglátod, hogy egy éven belül magadnak fogod tudni megvaladzolni a jelenlegi kérdéseid.
Bocs a hibákért mobilról vagyok.
-
#13432
instantwater
addikt
bandi0000
#13428
válasz
bandi0000
#13428
üzenetére
Sajnos Magyarország kis ország, a legtöbb fejlesztői munka Budapesten van.
Van néhány a nagyobb megyeszékhelyen is, de jellemzően nem annyi, és nem annyiért mint szeretnéd, és vidékről vidékre költözni talán még kisebb a hajlandóságod, mint a fővárosba, bár ez egyéni preferencia, van akit tankkal sem lehetne felvontatni pestre, van aki pedig örül, hogy végre felköltözött.
Ha a C#/.Net érdekel, annál elég nagy világvége kellene, hogy legyen, hogy ne legyen pesten nyitott junior pozíció.
Nyílt titok, hogy fejlesztőként már egyetem alatt lehet/kell/érdemes elkezdeni dolgozni, így szeretve némi tapasztalatot. Ilyenkor jellemzően olcsó helyen lakik az ember (kolesz, osztott albérlet), de mindenképpen kevesebb a mentális/anyagi teher, mint amikor egyszercsak rájössz, hogy végetért a buli, és neked 0 tapasztalatod van az adott szakterületen.
Egy ismerősöm így járt. Szépen lediplomázott, majd nem talált munkát, mert nem volt tapasztalata. Kiment Írországba, de még rendszergazdának is csak nehezen vették fel, fillérekért. Egy év után megunta, hazament MSc-re. Nem hiszem, hogy ez fogja neki meghozni az áttörést. Inkább gyakorlati tapasztalat kellene.
Ha akarod/teheted visszamehetsz MScre alibiből, és mellette diákként elkezded a pályafutásod.
Vagy hasonlóan alacsony, vagy talán még alacsonyabb bérért mint diákként (diákként kevesebb az adó) elmész egy kezdő poziba ahol elkezded a valós tapasztalatokat felszedni.
Egyetértek veled, nem érdemes otthon görcsölni hónapokig egy nyevvel. Az alapok mindegyikben ugyanazok, plusz egy kis nyelvspecifikus körítés, és némileg más mintákat követ a közösség.
Tanuld meg az alapokat, amik ahhoz kellenek, hogy el tudj kezdeni dolgozni.
Én mondjuk azzal kezdenék, hogy összeraknék egy egyszerű CRUDot, egy Todo appot.
Frontendre némi HTML, CSS, JavaScript, React, REST/GraphQL APIval.
Backendre a te esetedben .Net backend, valami hozzá passzoló SQL adatbázissal.Ezt max 1-2 hónap alatt meg lehet tanulni Udemyről.
Ha ez kész, akkor nagy vonalakban érted az alapokat, mehetsz interjúzni, még kódmintád is van amit tudsz mutatni.
Ha minden kötél szakad, ott van külföld.
Nyelvekkel hogy állsz?Én is vidékről származom, diákként dolgoztam egyetem mellett, volt is tapasztalatom egy kezdő/mid pozícióhoz PHP és társaival, de nem akartam fillérekért elmenni dolgozni, és vidékről feljárni sem, így gondoltam egy nagyot és kijöttem Angliába.
Bár tapasztalat nélkül itt sem vesznek fel senkit, úgyhogy inkább még ne csomagolj.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Miért vezet mindenki úgy, mint egy állat?
- Nők, nőügyek (18+)
- A fociról könnyedén, egy baráti társaságban
- Házimozi haladó szinten
- iPhone topik
- Samsung Galaxy Watch7 - kötelező kör
- Kerékpárosok, bringások ide!
- AliExpress tapasztalatok
- Bemutatkozott a Poco X7 és X7 Pro
- sziku69: Szólánc.
- További aktív témák...
- Kingston FURY Renegade 32GB 2x16GB DDR4 3600MHz kit - 38 hónap Aqua.hu Garancia / Beszámítás OK!
- AKCIÓ!!! GAMER PC: RYZEN 9 5900X +RX 9060XT/RX9070/RX9070XT +16-64GB DDR4! GAR/SZÁMLA!
- AKCIÓ! DDR5 GAMER PC: Intel Core Ultra 5 225F/245K +RX 9060XT/9070/9070XT +16-64GB DDR5! GAR/SZÁMLA!
- Samsung 870 EVO 256GB 2,5" SSD
- Samsung 960 256GB M.2 NVMe SSD
- Sima Vs.Windows Logitech Mx keys s plus és hagyományos Mx keys magyar bemutatása. Új videó linkel
- Apple iPhone 13 Mini / 128GB / Gyárifüggetlen / 12Hó Garancia / 84% akku
- Törött, Hibás iPhone felvásárlás!!
- LG 55C2 - 55" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen5 CPU
- LG 34WQ75X-B - 34" Ívelt IPS Panel - 3440x1440 2K QHD - 60Hz 5ms - FreeSync - USB Type-C 90W
Állásajánlatok
Cég: FOTC
Város: Budapest