- Álláskeresés, interjú, önéletrajz
- Synology NAS
- Musk szerint már jövőre itt vannak a Tesla Optimus humanoid robotok
- Az MSI RadiX AXE6600 tesztje – router, játékosoknak
- QNAP hálózati adattárolók (NAS)
- Olcsóbb lett a Tesla Full Self-Driving szoftvere
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen program, ami...?
- Microsoft Excel topic
- Otthoni hálózat és internet megosztás
-
IT café
Új hozzászólás Aktív témák
-
martonx
veterán
válasz Oppenheimer #8148 üzenetére
Szerintem meg semmi különbség nincs a kettő között. Bármelyiket is választod mindkettőben sok lehetőség van, és mindkettő egyforma jó karriert ígér. Én ASP.Net vonalon dolgozok, és nem telik el olyan nap, hogy ne fusson be legalább egy fejvadász megkeresés.
Én kérek elnézést!
-
fordfairlane
veterán
válasz Oppenheimer #8150 üzenetére
neten mindenhol azt találtam, hogy javaval jobban lehet ervenyesulni.
Én is ezt tapasztaltam.
x gon' give it to ya
-
martonx
veterán
válasz Oppenheimer #8150 üzenetére
Kérdeztél érveket, én írtam rá egy választ. Engm nem kell meggyőznöd semmiről, magadat kell meggyőznöd. Csak leírtam, hogy szvsz .Net vonalon pont ugyanúgy lehet érvényesülni, mint Java vonalon.
Én kérek elnézést!
-
Karma
félisten
válasz Oppenheimer #8148 üzenetére
Halkan azért hozzátenném, hogy egyik választható tárgy se annyira mély vagy hasznos, hogy csak erre alapozd a karrieredet. Az újgen.NET még a frissebb adatlap szerint is eléggé elavultnak tűnik - amit linkeltél meg talán pont ugyanaz, mint amit anno én is hallgattam.
A J2EE-be belelépés se feltétlen adja vissza azt, ami a való életben kelleni fog.
Ha választani kell, én azt mondanám, hogy hallgasd mindkettőt
[ Szerkesztve ]
“All nothings are not equal.”
-
kispx
addikt
válasz Oppenheimer #8154 üzenetére
Minek előre tervezni, majd a Neptun eldönti helyetted, hogy mi a jó Neked
(#8156) Oppenheimer
Jah, akkor nálatok nincs olyan, hogy 4 főre hirdetnek meg egy tárgyat.[ Szerkesztve ]
-
Jim-Y
veterán
válasz Oppenheimer #8156 üzenetére
És mi lenne ha kipróbálnád ezt is, azt is, és arra tendálódnál amihez leginkább van affinitásod?!
-
gygabor88
tag
válasz Oppenheimer #8156 üzenetére
Hát a java kurzust kihagynám a helyedben. JSP, Struts, EJB 2.1 ...
Kétlem hogy ezeket schönherznél kérdeznék tesztben, mert nagyon kevés hely van ahova ezek kellenek. -
Jim-Y
veterán
válasz Oppenheimer #8158 üzenetére
Akkor legyen JavaScript.
-
modder
aktív tag
válasz Oppenheimer #8165 üzenetére
Én hallgattam a Java EE-s kurzust pár éve, nincsen benne EJB 2.1, szerintem JSP-t is alig említik, gyakorlat inkább JSF+EJB. Gyakorlaton Netbeansben van a fejlesztés, ami legenerálja a CRUD EJB-ket meg ilyenek.
Amit fontos tudni, hogy rettentő sok az anyag, nem is csoda, mert hihetetlen nagy állat az egész Java EE framework, érdemes jó sok pontot szerezni a házin, mert olyan sok az anyag, hogy vizsgára nehéz mindent rendesen megtanulni.
A másik dolog, hogy akkor a gyakorlatok Netbeansben voltak, ami sok kódot, egész projektet legenerált, nagyon megkönnyítve ezzel a dolgunkat, de nekem akkor nem is állt össze pontosan, hogy mire jó, hogyan működik az EJB, JPA. Csak később, amikor munkahelyen láttam egy életnagyságú Java EE projektet, ahol minden réteg (megjelenítés, üzleti, adat model) külön Ant (vagy Maven) projekt volt, akkor esett le az egész. Ezzel annyit akartam mondani, hogy hasznos, de magadtól is érdemes letölteni pár Java EE sample projektet githubról, ami valami konvencionális build toolt használ (maven, ant, gradle), hogy lásd, a valóságban milyen egy projekt, mert a való életben nem Netbeans-szel generálják a kódot.
Ja, és ha már Java vagy .NET... én szeretem a Javát, nem is feltétlenül a nyelvet, hanem azt a sokszínű platformot, amit a JVM nyújt. Nagyon sok nyelvet támogat, és mind futtatható a JVM-en együttműködve: Scala, Clojure, JavaScript, Groovy. Sokféle Webes keretrendszer. Ha akarod hackelheted a javac fordítót, hogy fordítás közben generálj kódot (pl. Project Lombok). IntelliJ Idea-t istenítik, ami fizetős, de a legújabb Eclipse is már elég fasza támogatást nyújt webfejlesztés terén.
Ami viszont tény, hogy körülményesebb tud lenni, mint a .NET: neked kell kitalálnod google segítségével, hogy esetlegesen melyik osztály milyen Jarban lehet benne, ha hiányzik valami függőség a projektedben és csak egy ClassNotFound exception-t kapsz. Nehézkes a főggőség menedzsment. Egy nagyobb projektnél nehéz lehet konfigurálni az Antot vagy Mavent, ezekbe mind bele kell tanulni. Sokszor ki kell előre választani, hogy milyen szervlet vagy Java EE konténeren akarod futtatni az alkalmazásodat, mert habár standard a Servlet api, meg az összes Java EE szolgáltatás, mindig előjönnek konténer specifikus konfigurációk. Míg .NET-nél elvileg mindig IIS-en futtatod, jól össze van integrálva VS-val, és minden librarynak egyetlen, a hivatalos Microsoft implementációja van, nem neked kell kiválasztani.
[ Szerkesztve ]
-
Karma
félisten
válasz Oppenheimer #8199 üzenetére
Az, hogy "úgy volt", nem jelenti azt, hogy a most kezdő gólyáknál is ez a tanterv. Nem sok konkrétummal, de egy nemrég végzett kollégám mondogatja, hogy alaposan átalakítják a képzést a most kezdőknél.
“All nothings are not equal.”
-
Jim Tonic
nagyúr
válasz Oppenheimer #8200 üzenetére
Én azt hallom vissza a szakmából, hogy az SZTE infója már jobb, mivel rendkívül gyakorlatorientált a képzés. Nem tudom, csak hallottam.
szerk.: Az NNG állítólag pont azért bővít ott: [link]
[ Szerkesztve ]
Alcohol & calculus don't mix. Never drink & derive.
-
veterán
válasz Oppenheimer #8220 üzenetére
Már mind1, csak szar az IDE, és nem szólt hogy kihagytam egy betűt. 3 napig kerestem.
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
beleszólok
senior tag
-
beleszólok
senior tag
válasz Oppenheimer #8317 üzenetére
(értelmetlennek tartom ugyan, de kipróbáltam)
Semmi változás.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
nagyúr
válasz Oppenheimer #8476 üzenetére
Szerintem eleg sok haszna van, de ha elsosorban latoteret szeretnel tagitani, akkor en nem Scala-t tanulnek, hanem valami erosebben funkcionalis nyelvet. JVM-en pl. Clojure, vagy esetleg valami ML-varians, F# mondjuk. Ha jo vagy OCAML-ben, akkor tudok mondani egy allast, ami juniorkent 80k fontot fizet evente, aztan ez mondjuk megduplazodik
A Scala az kicsit olyan, mint a C++, amiben tizenotfeleke paradigma lehet programozni.
while (!sleep) sheep++;
-
nagyúr
válasz Oppenheimer #8479 üzenetére
Total mas, mint az ML-alapu nyelvek. A Scala nem erolteti tul a funkcionalis hozzaallast. Hibrid nyelvkent szerintem a F# egy jobb konstrukcio, de masik okoszisztema, szal mindegy is. Az ipari alkalmazasai elsosorban a penzugyi teruleten jelentosek; bar egy jo baratom dolgozik HPC kornyezetben is Scalaval.
En sokkal erdekesebbnek tartom pl. a Clojure-t, ott vannak extrem eloremutato dolgok, mint pl. teljes lockmentes konkurens programozas STM-mel, meg ilyesmik.
while (!sleep) sheep++;
-
nagyúr
válasz Oppenheimer #8482 üzenetére
Hat, meg a tranzakciók, rendes restart, rollback, stb.. A trükk az, hogy mutable dolgokkal működő nyelven ezt nem nagyon lehet rendesen megcsinalni.
Semelyik nyelvben nincs magic (bar most a C# 6.0 engedi a catch blokkban használni az await-et, na, az közel magic ).
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
válasz Oppenheimer #8484 üzenetére
Nezd meg, hogy a Java topicban mi megy mar a lambdak korul is -- csomo Java fejleszto szerint atlathatatlan (?). Az async/await meg vegkepp sok lenne mar az absztrakciobol
@Cathfaern: hat, nemtom. Hogy lehet ezt specifikalni?
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
-
Rimuru
veterán
válasz Oppenheimer #8628 üzenetére
Másodikra se. A zárójelezést (nagyon) könnyű elrontani.
Vigyázat, csalok!
-
repvez
addikt
válasz Oppenheimer #8641 üzenetére
Azokból kiderül, hogy esetleg több fájl is egymásra hatással van? TEhát, hogy az egyik fájl számitásánál egy másikból hiv be adatot vagy oda továbbit és ezt már a modositás kor is meg kéne nyitni, hogy a forditás során ne okozzon hibát?
Azért érdekelne, hogy megoldható lenne e egy külső ingyenes fizikai motor beleintegrálása külön modulként, mint a phisyx vagy a JSBSim
-
olivera88
veterán
válasz Oppenheimer #8735 üzenetére
-DCMAKE_INSTALL_PREFIX=/usr/local Így gondoltad ugye?
Köszi. Bár lehet próbáltam már nem tudom.
Hogy lehet újra installálni h ne keljen lefordítani még egyszer?
Evvel indul ugye a fordítás és itt van meghatározva a telepités helye. cmake /home/oliver/build/Magics-2.24.7 -DCMAKE_INSTALL_PREFIX=usr/local
Lefordítja a fájlokat és aztán kell installálni.
LG Velvet 5G Android 11 - Windows 10 Pro x64 & Debian 11 Bullseye - WoWS unsinkable_sam_
-
Xantor
tag
válasz Oppenheimer #8840 üzenetére
Elsősorban a web alapú programozás érdekel, illetve egy kicsit a vállalati alkalmazások programozása.
A józan ész olyan ritka manapság, hogy lassan a "szuper erő" kategóriájába sorolható...
-
nagyúr
válasz Oppenheimer #8895 üzenetére
"Ennek tudtában azt csinálnám (csinálom a mostani verzióban is), hogy minden userhez tartozik egy max 1.000.000 millió méretű terület a táblában, tehát például az n-edik usernek [n x 1.000.000] és [(n-1) x 1.000.000] közé esnének az Exceptionjeinek az ID-jai."
Ejha, miert tennel ilyesmit? Arra spekulalsz, hogy ilyen modon gyorsabban tudsz majd lekerdezni? Ugy, hogy azt se tudod, hogy valojaban ez bottleneck lesz-e, ill. azt sem, hogy hany exception instance lesz userenkent?
Siman legyen autoincrementalt ID-je az exceptionoknek, es ha ugy latod, hogy tul sok a felhasznalo, akkor majd skalazol. Arra gondolj, hogy egy ilyen sor kb. 20 bajt, tehat ha van egymilliard exception, akkor az meg siman elfer a memoriaban (!) egy komolyabb szerveren.
Abszolut tulgondolod szerintem, ill. informacio nelkul hozol technologiai donteseket.
"Beszúrás már más kérdés, szerintem ha Java kódból EntityManageren keresztül nyomok egy persist-et, semmiképp se fogom tudni elkerülni, hogy lockolja az egész táblát, és a többi tranzakció ami közben olvasna belőle, ne blokkolódjon."
Ize, miert kene lockolni az egesz tablat, ha inzertalsz? Olvass utana az MVCC-nek Szar lenne az elet, ha az egesz tablat zarolnank egy inserthez
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
válasz Oppenheimer #8897 üzenetére
Nem tudod 'ugy' megcsinalni, mert a valosag altalaban mas, mint amire szamitasz, szoval valoszinuleg egesz mas problemaid lettek volna, mint amire most gondolsz (es ez nem is nagyon fog valtozni, ilyen ez a popszakma).
while (!sleep) sheep++;
-
nagyúr
-
inf3rno
nagyúr
válasz Oppenheimer #8895 üzenetére
Nem csak noSQL létezik, van newSQL is, ami ugyanúgy SQL, csak nulláról írt adatbázis motorokkal, és azt mondják sebességben felveszi a versenyt a noSQL adatbázisokkal. Rengeteg van egyébként, olvastam egy könyvet polyglot persistence témában régebben, amiben felsoroltak legalább 10 divatosat, mint mongodb, neo4j, riak, stb... Mindegyiknél megvan az a feladat, amiben nagyon jó, meg persze az is, amiben nagyon rossz. Szóval lekérdezés alapján érdemes adatbázist választani. Kis alkalmazásoknál persze választasz egyet azt kalap. Nagy alkalmazásoknál meg jobb helyeken váltanak monolitról microservice-re egy méret felett, és minden microservice-nek egy vagy több adatbázist adnak, amelyek eltérő típusúak (is lehetnek). A típus attól függ, hogy az adott lekérdezés csomagra melyik adatbázis alkalmasabb a legjobban. Ezeket úgy frissítik, hogy csinálnak egy központi event storage-et, ami a teljes rendszer állapotát tárolja, aztán az abba bekerülő domain event-eket figyelik, és ha új event érkezik, akkor annak megfelelően frissítik a microservice-hez tartozó adatbázist. Nem kell multiphase commit, hogy szinkronban legyenek az adatbázisok, mert elég ha az event storage letárolja az event-et, a kis adatbázisok ha valami rosszul megy, akkor maximum eldobják a jelenlegi táblát, és nulláról újra lekérik az összes event-et, és végrehajtják magukon. Ez nagyon rugalmas rendszer így, mert egyedül az event storage lecserélése, ami problémás. A microservice-ekhez tartozó query database-eket bármikor tetszés szerint lehet cserélni, vagy akár még több különbözőt is lehet párhuzamosan futtatni, és A/B teszteket csinálni, és loggolni, hogy a kliens mennyi idő alatt kapott választ a lekérdezésre. A hátrány annyi, hogy legalább 2 helyen meglesz ugyanaz az adat, illetve, hogy visszamenőleg nehéz módosítani domain event-eket, mert akkor vagy belenyúlsz az event storage-be és módosítod a már letárolt event-ek adatait, hogy pl új tulajdonságok is kapjanak értéket, vagy mondjuk bevezetsz egy MyDomainEventV2 osztályt, ami már tartalmazza az új tulajdonságokat. Egyik sem tűnik valami jónak. Na asszem már túl sokat bloggoltam, mi is volt a kérdés?
Buliban hasznos! =]
-
TheProb
veterán
válasz Oppenheimer #8912 üzenetére
így van, erre keresnék vállalkozó egyéneket
[ Szerkesztve ]
"Boba is Mickey, Mickey is Boba" - Finkle Einhorn | PC Rig: https://pcpartpicker.com/b/bBy48d
-
inf3rno
nagyúr
válasz Oppenheimer #8912 üzenetére
Szvsz ebből a saját translator ami húzós. Ahogy nézem OCR-el dunát lehet rekeszteni. Legózásban azért OCR-nél is jó lehet, ha van egy nyelv felismerő, ami a rosszul olvasható szavakat meg tudja tippelni a kontextus alapján. Olyan fordítót meg bonyolult írni, ami felismeri a kontextust. Párszor már nekifutottam, hogy hogyan lehetne modellezni a problémát, de nem sokra jutottam. Lehet, hogy tényleg jobban jártok, ha a translator API-t használjátok, bár sokszor az is szemetet dobál ki magából.
[ Szerkesztve ]
Buliban hasznos! =]
-
hemaka
nagyúr
válasz Oppenheimer #8984 üzenetére
Ennyire nem érdemes már foglalkozni vele? Nem követtem mostanában mi a jobb helyette, ASP.net vagy mit használnak?
-
dabadab
titán
-
válasz Oppenheimer #9093 üzenetére
csak amikor Dabadab kiteszi a szmájlit, akkor ő naprendszer alatt nem egy napot plusz kilenc bolygót ért, hanem egy napot, kilenc bolygót, azok holdjait, az aszteroida övezetet, a Kuiper övet meg egy csomó kósza üstököst érti
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
dabadab
titán
válasz Oppenheimer #9105 üzenetére
Van számítógépes kő-papír-olló bajnokság, ha ráklikkelsz a botoknál Human VS Computer gombra, akkor te is szerencsét próbálhatsz: [link]
DRM is theft
-
martonx
veterán
válasz Oppenheimer #9132 üzenetére
Az 1Gb ram miatt én bármilyen fapados is, de a lementett statisztikát simán file-ban tárolnám. Ha jól értem ez nem más mint egy nagy Json adat.
Ha bőven lenne ram a gépben, akkor javasolnám a redis, memcache- meg ilyesmik használatát. Bár azt sem tudjuk, hogy mekkora adatról van szó, mert ha pár száz Kbyte, akkor vélhetően simán elfér a memóriában is.Én kérek elnézést!
-
Jim Tonic
nagyúr
válasz Oppenheimer #9132 üzenetére
Miért nem tolod ki simán XML-be vagy JSON-ba? Utána olvassák azt a kliens programok.
Alcohol & calculus don't mix. Never drink & derive.
-
Jim Tonic
nagyúr
válasz Oppenheimer #9136 üzenetére
Szerintem az nem gond. Ha Te szerkesztésre nyitod meg, a többiek akkor is tudják olvasni. Ez akkor így így lenne, ha DB-ben tárolod. Ha exlusive lock kerül rá, a többiek nem látják, shared lock esetén meg előfordulhat, hogy éppen módosítod.
Alcohol & calculus don't mix. Never drink & derive.
-
válasz Oppenheimer #9136 üzenetére
szerintem web szerver adatterületére kell kigenerálni a statisztikákat.
rendes fájlrendszernél nincs probléma abból, hogy az egyik szál kiszolgálja a fájlt, a másik meg letörli vagy újraírja. max. abból lehet gond, hogy újraírás közben kezdi letölteni, mert akkor lehet, a végét nem kapja meg a kliens.ilyenkor szokás temporális fájlba generálni az eredményt és egy move utasítással a helyére tenni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Jim Tonic
nagyúr
válasz Oppenheimer #9139 üzenetére
Még azt megteheted pluszban, hogy ramdrive-ot hozol létre. Akkor nagyon gyors lesz az írás-olvasás. Szinte esélytelen olyan ütközés, amiből gond lenne, de az read errort amúgy is kötelező kezelni.
Alcohol & calculus don't mix. Never drink & derive.
-
inf3rno
nagyúr
válasz Oppenheimer #9136 üzenetére
Ezt az állapot kerül a szerverbe témát kifejthetnéd, hogy miért probléma. Hozz létre timestamp alapján fájlt, aztán akkor nem kell izgulni, hogy mi van, ha felülírod az előzőt. Gondolom pár json fájlba nem szakad bele a szerver, meg be tudsz lőni egy cache gc-t, ami törli őket bizonyos időközönként. Adatbázisban is meg lehet oldani view-okkal, ha csak néhány query-ről van szó, illetve gondolom létezik olyan, hogy query cache vagy ilyesmi. Annyi extra, hogy talán nagyobb lesz a latency, ha az adatbázis más gépen van. Egy HTTP cache-t mindenképp tegyél be mellé, ami modified-since headert nézi. Nem tűnik bonyolult feladatnak ez az egész.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Oppenheimer #9143 üzenetére
A HTTP cache nem böngészőfüggő dolog, bármilyen klienshez hozzá lehet csapni.
View-okkal gyorsabban menne a JSON előállítása, cserébe valamivel lassabb lenne az írás.
Eléggé képben vagyok a stateless constraint-el kapcsolatban, a memória kérések kesselésére történő használata semmiben nem mond ellent neki.
[ Szerkesztve ]
Buliban hasznos! =]
-
válasz Oppenheimer #9146 üzenetére
azt, hogy ne akard újra feltalálni a kereket.
az oprendszerben van blokkeszköz cache, ne programozz le ilyet, használd azt.
a fájlrendszer megoldja rendesen a konkurens hozzáférést, azt használd és ne agyalj máson.minden, amit újrafelhasználsz, a te melódat csökkenti.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Karma
félisten
válasz Oppenheimer #9146 üzenetére
Én továbbvinném, amit bambano írt, és a fájlrendszert is kihagynám a buliból. Redist, Ehcache-t vagy Memcached-t elő, aztán hadd szóljon. A fájlokkal szórakozni feleslegesen alacsony szintű, és teljesítményben se determinisztikus.
“All nothings are not equal.”
-
nagyúr
válasz Oppenheimer #9152 üzenetére
> Mongot
gratulalunk
(mongo: losing data on web scale!)
while (!sleep) sheep++;
-
válasz Oppenheimer #9152 üzenetére
a vps-re gondolom nem windowst akarsz rakni, hogy szanaszéjjel törjék?
ha ilyen memcached meg hasonló csodákat raksz az architektúrába, akkor annak a kódja is visz el a ramból, azt a programot is ütemezni kell, stb. tehát ha kevés a lóerő, akkor érdemes kidobálni a ballasztot.
ja, és miért vársz a mysql json-ra, mikor a postgres ezer éve tudja?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
inf3rno
nagyúr
válasz Oppenheimer #9146 üzenetére
Szerintem mindenképp előnyösebb a memória. Fájlba csak akkor van értelme menteni, ha túl nagy vagy ha history-t akarsz több fájlból.
A stateless-nél arra kell figyelni, hogy a client state-et ne tárold a service-ben, akkor is menjen két egymás utáni kérés, ha közöttük újraindítod a szervert, vagy éppen eltérő instance kezeli a két kérést.
Az authentikációt, authorizációt ugyanígy érdemes memóriába kesselni, hogy ne kelljen minden kérésnél az adatbázisból kiolvasni a felhasználó vagy a kliens jogait a felh név és jelszó vagy éppen az access token alapján.
A HTTP cache-t akkor tudod használni, ha több service van egymásra rétegezve aka. layered system. Ilyenkor az aktuális kliens mindig az eggyel alatta lévő réteg service-eit hívja, és tudja kesselni a válaszukat. Így az alsóbb rétegek, amik az adatbázisokhoz közelebb vannak, kevesebb terhelést kapnak. Ha nálad a kliens 3rd party, akkor nem tudod kiharcolni, hogy az is kesseljen, szóval lényegtelen. Ha te írod a klienseket is, akkor viszont érdemes beleépíteni.
Igazából ezek a REST constraint-ek csak akkor működnek, ha tényleg komoly terhelést kap (vagy fog kapni) az alkalmazás.Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Oppenheimer #9152 üzenetére
Nem vágom ezt a kotlin dolgot meg a java-t. Szerintem azért gondold át, hogy a kliensnek JSON kell. Szóval ha objektumban tárolod, és minden kérésnél JSON szerializálod, akkor az lassít. Az objektum gráfot akkor éri meg a JSON meg az adatbázis közé tenni, ha az egyes részeit eltérő időben frissíted az adatbázisból, vagy ha a kliensek csak egy-egy részét kérik le. Ilyenkor is érdemes JSON formában eltárolni a gyakori kliens kérésekhez küldött válaszokat, ha van rá elég memória, meg ha túl nagy a terhelés a szerializálás miatt. Mérni kellene.
Ohh most olvasom, hogy eleve JSON-t tárolsz le. Akkor minek futni még egy kört a parsolással és újra szerializálással?
[ Szerkesztve ]
Buliban hasznos! =]
-
veterán
válasz Oppenheimer #9164 üzenetére
Nagyon jó, bevált!
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
nagyúr
-
amargo
addikt
válasz Oppenheimer #9169 üzenetére
Ez teljesen igaz, viszont később, ha elkezd dolgozni, akkor vélhetően normális IDE lesz előtte, na akkor nagy előny tud lenni, hogy ismeri már.
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
repvez
addikt
válasz Oppenheimer #9337 üzenetére
oké a pyton,de ha egy komplett windowsos progit akarok majd később csinálni akkor szinte a nulláról kezdhetem el a C++ példáil,mert a kódszavak nem ugyan azok avgy nem ugyan azt a funkciót csinálják.
Pytonnal eddig még csak scriptekként találkoztam a 3d modellező progiknál.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!