- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- btz: Internet fejlesztés országosan!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bambano: Bambanő háza tája
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
-
LOGOUT
Új hozzászólás Aktív témák
-
skoda12
aktív tag
Egy jo tanacs, amit en annak idejen nem fogadtam meg es megbantam: Olyan temat valassz, amihez mar ertesz es pikk-pakk osszedobod. Ha ez a DB kezeles egy webes felulet mogul, akkor azt kell valasztani. Nem szamit, hogy a temavezetoknek tele van a hocipojuk vele. Ha mast valasztasz, akkor eleve sok idot fog elvinni a tema koruljarasa es akkor meg nem irtal egy sor kodot sem. Ha nappalis vagy es meg nem dolgozol, akkor esetleg belefer valami ismeretlen terulet koruljarasa, egyebkent felejtos. Ezen kivul ne feledd, hogy kar szakdogaban villantani. Soha senki nem fog ranezni / rakerdezni a temavezeton es a vizsgabizottsagon kivul. Ezen egyszeruen csak tul kell lenni.
-
proci985
MODERÁTOR
válasz
bambano
#7095
üzenetére
vannak SoC megoldások a célra.
aquaero 5 LT
aquaero 5 Pro
Corsair Link -> ez lehet csak ambientet tud
mCubed tBalancer miniNG
mCubed Tbalanced classic
mCubed Tbalancer BigNGa miniNG olyan 10k, a többi jellemzően 20-25 körül mozog. de ez itt ebben a topikban nagyon off.
-
Atos23
senior tag
válasz
bambano
#7095
üzenetére
Köszi az ötletet, tényleg jók!
Annyit kifelejtettem, hogy a tanárom mondta, mivel programtervező informatikus a képzés, legyen kicsit közelebb a .net programozáshoz, mint az elektronikához.
Persze bármilyen tárgyból írhatok, szerencsére voltak hardveres óráink, bár sajnos a legtöbb tanár kizárólag szoftveres érdeklődésű.Az eddigi ötleteim:
- Rádióamatőr állomásvezérlő program, Winformok, soros porton keresztül morzézik is ha kell
- Távirányítós autó formájú "robot". Benne Raspberry pi-féle mini számítógép, futó grafikus OS-el. A gép wifivel kimegy netre. A Raspberryre távoli asztallal csatlakozom, és azon keresztül futtatom a léptetőmotor vezérlő programot. Internetes távirányítós autó, saját szoftverrel.
-
bambano
titán
engem érdekelne egy intelligens hűtésvezérlés pc-be, kis csavarással
mert normálisat még nem láttam...(többek között) stacker1-es házhoz van olyan vinyókeret, amibe 4 vinyót bele lehet rakni és van az elején egy nagy venti. hőérzékelőkkel mérni kellene a 4 vinyó hőmérsékletét és pic-cel vagy ilyesmivel szabályozni 0 és 100% között a ventilátor fordulatszámát.
még nem volt a kezemben olyan, ami megállította volna a ventit, ha nem kell, meg olyan sem, hogy több helyen mér és a legmelegebb szerint vezérel.
A másik ötlet: lakóház vezérlés. érzékelőkkel figyelni, ki mikor hol tartózkodik és kapcsolgatni a villanyt, stb. van rá kész protokoll is: X10.
-
Atos23
senior tag
Halihó!
Kreatív fórumtársakat, ötleteket keresek
PTI-s Szakdoga témát kell választanom, aminek sok köze van a programozáshoz. Szeretnék belevinni egy kis elektronikát, műszaki tartalmat is.
Először én is adatbázis témát akartam választani, de a tanárok sorra fakadtak ki, mert mindenki a DB-ket, webes technológiákat hajkurássza, és tele van a hócipőjük a sablon dogáktól.
Így elővettem rádióamatőr Énem, ki szeretnék gondolni valami okosat, amihez felhasználok c# programozást, portokon vezérlést, pici elektronikai tervezést is.Pl. Robotika, léptetőmotorok vezérlése programból, PC kommunikáció mérőműszer fejekkel, aminek adatait a gép feldogozza, stb stb.
Tudom, hogy nekem kell kreatívnak lennem, de mégis sok ember sok jót tud mondani. Lehet nem is jut most eszembe olyan, amiben jó vagyok, de elsiklok felette tervezéskor. Ötleteket várok, számítok rátok
-
#7091
Rivaul
addikt
Neil Watts
#7090
Rivaul
addikt
válasz
Neil Watts
#7090
üzenetére
Igen ilyesmire. Bár nem gondoltam hogy kínaiul lesz
Azt hiszem ehhez nagyon el kell szánnom magam mert semmit nem értek a témához. Legalább +van merre induljak. Köszönöm 
-
#7090
Neil Watts
veterán
Rivaul
#7089
-
Rivaul
addikt
Sziasztok. Nem tudom jó helyre írok-e.
Kéne nekem egy kis indító fájl ami a gépem ip-jét 1x automatára engedi, 1x meg ezt: 192.168.0.5 adja neki. Van egy külső eszközöm amit csak úgy tudok összekapcsolni a géppel ha ezt az ip-t adom meg neki. A net viszont csak akkor megy ha a gép "ip cím automatán kérése" opció alatt megy. Elég babramunka napi 36x belépkedni s átírni, kiszedni az opciót. Win 8 64-bit a rendszer. Ha meg lehet oldani az is jó lenne ha leírná valaki mit is kell tennem. Olyasmire gondoltam hogy 2 ikon az asztalon ha az egyikre kattintok auto ha a másikra akkor meg ez az ip amit használ. Thx
-
#7088
bucsupeti
senior tag
freelanced
#7086
bucsupeti
senior tag
válasz
freelanced
#7086
üzenetére
tudod mik ezek: változó, konstans, tömb, struktúra vagy rekord, mutató, utasításblokk, iteráció (ismétlés), szelekció (elágazás), függvény, eljárás.
Ha ezekkel nem vagy tisztába, akkor hagyd a fenébe egyelőre a javát és inkább pascalon keresztül kezdj el ismerkedni ezekkel. Itt egy magyar nyelvű oktató oldal.Ha rendben vannak ezek a fogalmak akkor jöhet az OOP, azaz az objektum orientált szemlélet megismerése. Ezt Java-n keresztül ajánlom, de itt már jó lehet a C# vagy a C++ is. A Java tiszta OO nyelv és ez szerintem jó a tanuláshoz.
-
#7087
cucka
addikt
freelanced
#7086
cucka
addikt
válasz
freelanced
#7086
üzenetére
A szemléletmód megértése a lényeg. Annak semmi értelme, hogy bármit megtanulj kívülről, arra ott a doksi, ahol bármikor utánanézhetsz.
-
#7086
freelanced
addikt
freelanced
addikt
Köszi mindenkinek!
Hát mit mondjak érdekes ez a Java, tetszik de egyelőre még tömény...
Csak annyi, hogy amik vannak gyakorló feladatok a könyvben azoknak a parancsait egyből jegyezzem meg(tehát tanuljam, memorizáljam?) vagy majd úgyis annyit használom, hogy megjegyzem?
-
#7085
bucsupeti
senior tag
freelanced
#7081
bucsupeti
senior tag
válasz
freelanced
#7081
üzenetére
Egyértelműen Java/C# a jó irány üzleti szempontból. Viszont ha most kezded a programozást, akkor szánj egy kis időt arra hogy magát a strukturált programozást ismerd meg.
A Java/C#/C++ soha sem magát a nyelvet jelenti, hanem a teljes környezetet, framework-öt, library-ket stb.
Ezek előre elkészített megoldásokat adnak és nagyban egyszerűsíti majd egy-egy komplex alkalmazás elkészítését. Én azt javaslom hogy ne ezeknek ess neki egyből.1. Először egy kicsit merülj el a strukturált programozásban, az adatstruktúrákban (pascalt javaslom).
2. Ha ezek már mennek akkor OOP alapokat tanulj, gyakorold (üzleti vonalon Java/C#, rendszerprogramozás vonalon C++).
3. Miután megy az OOP akkor jöhetnek a speciális utility-k/library-k megismerése (üzleti vonalon Java/C#, rendszerprogramozás vonalon C++) -
#7084
Neil Watts
veterán
freelanced
#7083
válasz
freelanced
#7083
üzenetére
-
#7083
freelanced
addikt
Neil Watts
#7082
freelanced
addikt
válasz
Neil Watts
#7082
üzenetére
Köszönet!
Könyvek terén mit tudnátok ajánlani?
Üdv! -
#7082
Neil Watts
veterán
freelanced
#7081
válasz
freelanced
#7081
üzenetére
Szia!
Amennyiben most jánlanom kéne akkor biztos hogy a C# illetve a Java felé terelnélek. Az alapvető programozási tételek illetve valami normélis müdszertan elsajátítása után egy jó könyvvel nekivágva egész jó dologkat lehet elérni, illetve az objektumorientáltság is fontos szempont szerintem. Amennyiben ezen szempontokat nem nézzük akkor is azt lehet látni, hogy a munkáltatók részéről van rá igény, tehát el lehet vele helyezkedni, illetve használható tudást ad mindkettő. Ellenben az egyetemeken tanított Pascallal - s igen, tudom ettől a szemléletmódtól nem leszek népszerű.
Szóval szerintem C# vagy Java így elsőkörben.
Talán a crossplatform miatt inkább Java.Üdv. core2
-
#7080
proci985
MODERÁTOR
freelanced
#7079
proci985
MODERÁTOR
válasz
freelanced
#7079
üzenetére
mindenképp. mindkettő aktívan használt, hasznos és relatíve egyszerű.
igazából bármelyikkel is kezded, utánna a másik egyszerűbb lesz (elég sok hasonlóság van), ha pedig kedved lenne a C/C++ pároshoz, akkor azok is menni fognak, mert elég sok hasonlóság van.
Eclipse Juno EMF / M2M, úgy néz ki ideális futáshoz x86 alatt ki kell lőni a multithreadelést, valamiért lassabb úgy az ATL.
-
#7078
proci985
MODERÁTOR
freelanced
#7077
proci985
MODERÁTOR
válasz
freelanced
#7077
üzenetére
nem feltétlen. itt svédeknél amit látom, hogy a környéken nagyon keresnek ebből az a C# és a Java. Java lehet nem a leg"gyors"abb (performance definíciófüggő), de egy valósidejű rendszernek alapvetően nem gyorsnak, hanem pontosnak kell lennie. mivel Ada programozókat egyre nehezebb találni, ezért a cégek kezdenek áttérni Adaról Javara. plusz ott az Android, ha tudsz Javat akkor kis túlzással tudsz Androidot is.
sima C első nyelvnek kemény dió, nagyon könnyű hibázni benne és elég nehéz debugolni. C++ egy fokkal jobb. Pascal programozót nem igazán keresnek/használnak, akkor meg inkább már Java szvsz.
más, az előző Eclipse M2Mre megvan a megoldás, az eclipse heap sizeot kell magasabbra állítani, illetve a többszálú végrehajtást engedélyezni (1.5 Juno M2M x86ban ez defaulton ki van kapcsolva, x64 meg instabil).
-
#7077
freelanced
addikt
freelanced
addikt
Amúgy köszi a segítséget mindenkinek, a java kiesett egyelőre...
Még nem sikerült teljesen eldönteni de egyelőre ezeket nézegetem:
1: C/C++
2: C#Mondjuk az első kettő bonyolultabbnak tűnik, viszont ahogy látom, hosszú távon hasznosabb lehet.
Lehet, hogy elsőre a sima C lesz...
Amúgy a Pascal meg a Pyton se tűnik rossznak...
-
proci985
MODERÁTOR
az létezik, hogy az x64es Eclipse java.lang.reflect.Invocation.TargetException hibaüzivel elszáll, ahol az x86os még stabil?
egy 1.000.000 soros XMI file alatt jött a hibaüzenet (ATL pluginnel M2M transzformációt benchelek épp, amiatt kell ilyen horror méretű file mert sokkal kisebbekkel nem látszik a skálázódás)
kieg: 1.200.000 sornál már a 32bites is elszáll.
a beépített xmi editor már olyan 200k sor másolgatásánál is összeomlott mondjuk heap errort dobva.
amargo: a májusi information and software technologyban volt erről egy érdekes cikk ami végigvette a Gang of Four féle Design Patterneket. az eredmény eléggé érdekes volt, hármat használnak, három megosztó -Singleton nem meglepő módon, illetve a Concrete Classok egyszerűségük miatt pár ember szerint nem minősül annak- a többi nagyon nem volt használatban a 21ből.
-
amargo
addikt
"Ezért absztrakcióra sincs akkora szükség."
Architektúráról hallottál?(#7072) bambano
"szerintem van az oop-nek egy overheadje, ami akkor kezd kifizetődni, ha túl nagy a probléma és már tényleg kell hozzá az oop. hogy minden piszlicsáré dolognál ágyúval lövünk verébre"
Innentől jön be szerintem, hogy ki milyen patterneket ismer. -
bambano
titán
egyik példám, amikor egy jávás programból kellett infót kiszedni. komoly veszekedést kellett tartani a fejlesztőkkel, hogy ne xml-ben adják ki az adatot, mert totál felesleges, elég a csv is.
meg hogy ha tudunk ldap szervert üzemeltetni, akkor használni is fogjuk, ha törik, ha szakad. hogy nincs rá szükség, az nem számít, tudunk ldap queryt programozni, akkor lesz.
szerintem az ilyen hozzáállás miatt lassúak a jáva programok.
(#7071) modder: a getter-setter max. addig nem probléma, amíg megírja helyetted a kódgenerátor. mert egyébként nem az álmok netovábbja gettersettert programozni, favágó munka legalja.
-
bambano
titán
én nem főállású programozó vagyok, nem ez a fő feladatom. nem vagyok meggyőződve arról, hogy azokat a feladatokat, amiket ma oop-ben oldanak meg, oop-ben érdemes megoldani. szerintem van az oop-nek egy overheadje, ami akkor kezd kifizetődni, ha túl nagy a probléma és már tényleg kell hozzá az oop. hogy minden piszlicsáré dolognál ágyúval lövünk verébre, annak a hatékonysága kétséges számomra.
-
modder
aktív tag
válasz
bambano
#7067
üzenetére
Ez a "túldizájnoltság" szerintem is probléma, és ettől tényleg lehet lassú valami. A Java EE-nek egyébként is az az alapelve, hogy minden specifikáció, minden egy interfész, aztán olyan implementációt teszel mögé, amit akarsz lásd: OpenJPA, Hibernate, Eclipselink JPA-ra; többféle servlet container; JSF implementációra Mojarra, Myfaces; JDBC connectors; És ezeknek persze együtt kell működniük.
Ez egyébként szerintem nagyon jó dolog, mert választhatsz, ha az egyik nem váltja be az ígéretet, akkor ott van a másik. A különböző implementációk versengenek egymással, így elvileg egyre jobbakká válnak. Sok opensource projektnél elég komoly QA is van. És szerintem nem is itt veszik el a teljesítmény: nem a Java EE service API-k és service providerek közötti vékony interfészen, hanem a service providerek implementációjában, és a programozók hozzá nem értésében, és a túlzott absztrakcióban.
Utóbbira példa, amikor belenéztem az activiti.org kódjába, és végigdebuggoltam egy adatbázis lekérdezést. Na ott fogtam a fejem. Volt benne struktúra bőségesen is azért, hogy az adatbázist el lehessen érni szimpla JDBC kapcsolaton keresztül, támogassa a Spring és JTA tranzakció kezelést stb... Na azt már egészségtelen volt látni
és ki tudja, hogy egy olyan, sokak által használt könyvtár, mint a Hibernate nincsen tele hasonló absztrakciókkal?Állandóan azt sugallja mindenki, hogy milyen jó az absztrakció, mert akkor az interfész mögötti implementációt mindig le lehet cserélni, és nagyon sok végfelhasználói program is ebben a szellemben készül el. Ez az egész attitűd a Java programozóknál pont lehet, hogy a Java hasonszőrű hozzáállásából ered. Nem is alaptalan hülyeség, mert a fenti, activiti.org-os példánál haszna tényleg van: van aki Springes alkalmazásként akarja használni, van aki Java EE alkalmazásba integrálva, van aki szeretne JTA-t használni, van aki nem... végfelhasználói alkalmazásoknál pedig olykor-olykor előfordul, amikor különböző rendszereket kell összekötni.
A másik oldalon mi van .NET-ben? Minden meg van írva a Microsoft által, ritkán kell külső library-ket használni. Az ember, amikor fejleszt, tudja, hogy mikor mihez kell nyúlnia, és tudja, hogy vagy azt a komponenst használja, vagy nagyon nyomós ok/különleges igény kell ahhoz, hogy valamilyen külső libet használjon. Amit pedig használ, az nem fog változni. Ezért absztrakcióra sincs akkora szükség. Nekem legalábbis ez az érzésem, még nem fejlesztettem .NET-ben.
Bár ezzel még nem írtam le a Javát, a fentiek miatt én maximum 5-10% sebességvesztést mondanék .NET-tel szemben, de ez csak intuíció.
A másik, hogy a Java-t tudni kell használni. Nem mindegy, hogy az ember LinkedList-et vagy ArrayListet használ orrba-szájba, nem mindegy, hogy Hashtable vagy HashMap. Nem mindegy, hogy mekkora függvényeket ír, mert a JIT csak függvény szinten fordít, ha ránéz, és látja, hogy ez biztony 200 sor, hülye lesz lefordítani
. Nem mindegy milyen String kezelő függvényeket használ. Nem mindegy, hogy fűz össze Stringeket. Nem mindegy, mekkora objektumokat használ: például kis méretű osztályokat lehet orrba-szájba példányosítani, majd hagyni felgereblyézni a garbage collector által, mert erre van külön optimalizáció a Hotspot VM-ben. String kezelés nagyon sokat el tud venni alapjában véve.
Akkor például, ha valaki JPA-t használ, hajlamos (én hajlamos vagyok) nem figyelni, hogy valójában hányszor fog az adatbázishoz fordulni a provider, amíg ez nincs optimalizálva, bizony előfordul, hogy egy oldal lekérdezés alatt több 10-szer is. Hogy van beállítva a cache, lehet, hogy a memória felét a Hibernate akárhanyad szintű cache-ében tárolt adatbázis objektumok alkotják.
Akkor aki JSF-et használ, nem árt belegondolni, hogy mennyire akar külső komponens library-ket használni, mint az Icefaces vagy Primefaces. Ezek nagyon szépek, sokat tudnak, de megvan az ára is sokszor: a komponensek állapota minden felhasználói sessionre egyedileg tárolódnak, így elég sok memóriát meg tudnak enni. (azt hiszem talán ASP.NET Webforms-szal is ez volt a probléma?) Figyelni kell, hogy mit tárolunk SessionScope beanekben, mert betolni a fél adatbázist memóriába, és ott tartani a user session végéig azért, hogy feltöltsünk egy datatable-t, amit fél percig néz a user, nem túl okos ötlet. Ugyenez vonatkozik JPA-ra is: Eager fetch-csel óvatosan, nehogy pár entitásért berántsa a fél adatbázist memóriába a tranzitív eager fetch propertiken keresztül.
Na ez csak pár dolog, ami eszembe jutott, és ami könnyen problémákhoz vezethet. Ha performance probléma van, nem egyből a nyelvet kell okolni, hanem profiling-ot kell alkalmazni, meg kell nézni, hogy mi lehet a szűk keresztmetszet. A fent leírtak közül bármi okozhat rohadt sok memóriazabálást, lassúságot.Na még egy gondolat, visszaugorva az esetlegesen lassú vagy optimalizálatlan service providerekhez. (mint Hibernate). Vajon jogos-e magát a nyelvet lassúnak kikiáltani úgy, hogy nem közvetlenül a nyelv lassú, hanem a köré épített platform? Szerintem jogos, elvégre a Java EE maga ezek a library-k, de nem egyértelmű, hogy ők okolhatóak ezért. Ott van például a korábban említett Cassandra, Neo4j vagy éppen a HBase, Hadoop platform, mind Javában vannak írva, és köszönik, nagyon jól megvannak és gyorsak. Jobban utána kéne járni a lassúság "sztereotípiának", hogy mi lehet az oka, és mennyi igazság van benne.
-
#25954560
törölt tag
válasz
bambano
#7067
üzenetére
ejgen, en is pont ezt a hasonlatot szoktam felhozni. nem kizart h tenyleg megszokasbol irodik a java kodok nagy resze, azert hatekonytalan. csakhogy nalunk fontos a sebesseg, vannak azert folyamatosan torekvesek az optimalizalasra. de nem az en asztalom, nem mennek bele.
-
bambano
titán
válasz
#25954560
#7065
üzenetére
a gyors jáva kód dolog akkor szokott átmenni mítoszba, mikor az első mások által faragott cuccot betöltöd a saját programodba. nem feltétlenül a jáva lassú, azok a framework-ök lassúak, amiket használni akarsz.
Nekem meg az a tapasztalatom, hogy azért lassúak a jáva programok, mert túldizájnoltak. Kiindulva a "ha kalapácsod van, mindent szögnek nézel" mondásból, én már láttam olyan jáva architektet, aki a budizást se tudta volna megoldani 50 gettersetter meg 3 xml parser nélkül. Mindent beleraknak a programba, amit valaha feltaláltak jáva területen. Olyan is lesz... de ettől még mindig nem a jáva lassú.
meg néha nem ártana elfelejteni, hogy a jáva oop...
-
skoda12
aktív tag
válasz
#25954560
#7065
üzenetére
Lehet, hogy nem olyan fejlett a gc vagy tobb memoriat foglal egy azonos hosszu string, mint egy masik nyelvben. Nyilvan byte kod miatt sosem lesz olyan gyors, mint egy nativ alkalmazas. Ettol fuggetlenul azt allitani, hogy ugyanaz a program tobb tucat peldanyban fut .NET-ben ugyanazon a vason, mint egy javas peldany azert az tobb, mint meredek. Eleve nem hiszem, hogy barki itt levo latott volna egy .NET-es meg egy javas alkalmazast, amiknek ugyanaz lenne az architekturaja es ugyanazt csinaljak, igy kar is belemenni abba, hogy ez a program ennyit eszik a masik meg annyit.
Most egy olyan rendszert raktunk ki productionbe, ami majdnem 2x16 giga memoriat fogyaszt. Ettol most a java szar? Nem (illetve nem ettol szar), egyszeruen csak arrol van szo, hogy a beerkezett tradeket par millisec alatt kell feldolgozni es ebbe nyilvan nem fer bele az, hogy elkuldunk tobb sql queryt egy DB szerver fele, amik egyenkent osszejoinolnak 2-3 tobb tizmillios tablat, ezert egyszeruen a memoriaban vannak tartva az aktiv adatok. -
#25954560
törölt tag
válasz
skoda12
#7064
üzenetére
valamiert az a tipikusabb akkor h emberek gyakrabban talalkoznak rosszul tervezett rendszerekkel. nem tudom miert van. nalunk a cegnel is van java fejlesztes, nyugodtan feltetelezhetjuk h van par jo koponya, megsem az a velemenyuk h gyors kod irhato java-ban. ettol fuggetlenul vannak elonyei.
-
skoda12
aktív tag
válasz
martonx
#7055
üzenetére
Ha ez a tapasztalatod a javaval, akkor az csak annyit jelent, hogy rosszul tervezett rendszerekkel talalkoztal java vonalon. Azert van keves publikus hostingja, mert nincs ra igeny ugyanis penzugyi szektorbol ki hostolna az adatait egy akarmilyen bt-nel? Amit meg a .NET java osszehasonlitasban emlitesz, egyszeruen nem igaz. Az meg, hogy osszeakadnak a jvm-ek egy vicc.
-
fatal`
titán
De van. C++ 4. félév, C 5. félév (Operációs rendszerek). Java van a 3. félévben kettő is (progtech, prognyelvek java), 4. félévben progtech 2, ötödikben alkalmazások fejlesztése és a hatodikban osztott rendszerek.
(#7049) Geli. : Van 5 félév analízis, 2 diszkrét matek, linalg, 2 félév num anal. Viszont pl. nincs fizika.
-
modder
aktív tag
Szerintem nem is a bonyolult infrastruktúra igény miatt van kevés hoszting, hanem nincs rá piaci igény. A Java-t többnyire az Enterprise réteg használta, és sokáig nagyon jól elvoltak a hatalmas cégek a saját infrastruktúrájukkal, amibe a Java alkalmazásukat deployolták.
Kevésbé volt népszerű az egyszeri kóder számára a Java. PHP-val, Pythonnal ellentétben. Gondolom legfőképpen azért, mert gyorsabb nekikezdeni egy PHP-t megtanulni, mint Javát. Tudom, mert én is PHP-val kezdtem, és ha visszagondolok, sokáig azt sem értettem, hogy mire való a WAR, amikor elkezdtem Javával foglalkozni.
Rákerestem a Java hostingra, és ezt találtam http://programmers.stackexchange.com/a/185518
De ez nem annak köszönhető, hogy több "egyszeri kóder" kezdte el használni a Javát, hanem annak, hogy az infrastruktúra outsource-olás tendenciává vált, ahol azok a cégek is vevők lehetnek egy Java PaaS-ra, akik eddig teljesen boldogak voltak a saját rendszerükkel.
Egyébként abban lehet valami, hogy sok memóriát zabál, de nekem is a konténer minimum heap size 512mbyte-nak van beállítva alapból, még nem próbáltam ki, hogy az alkalmazás, amin éppen dolgozom mekkora memórián fut el kényelmesen.
-
cucka
addikt
válasz
martonx
#7055
üzenetére
Nem realtime rendszereknél az erőforrásigény nagyjából senkit sem érdekel, annyira olcsó a hardver a programozói fizetésekhez képest. Előző hozzászólásban szóba jött a tízmilliós árú szerver, ugyanez a pénz Amerikában egy nem kezdő programozó 3-4 havi bérét fedezi. Gondolhatod, milyen erőfeszítéseket tehetnek ilyen bérszínvonal mellett, hogy megspóroljanak pár száz-ezer dollárt a szerver bekerülési költségein..
Java hoszting meg pont ugyanazért nincs, amiért .net hoszting sem: túl bonyolult ahhoz képest, hogy milyen vékony a célközönség. Aki nekiáll ezekben a technológiákban fejleszteni, az jellemzően nem egy kétpálcás shared hosting szolgáltatásban gondolkozik, hanem rendes saját szerverben, vagy cloudban.
-
martonx
veterán
válasz
bambano
#7051
üzenetére
Félreértettél. Én nem tisztán a futásidőkről beszélek. A komplett hardver kihasználásról. Egyszerűen a .Net nem annyira erőforrás pazarló, és itt nem is feltétlenül a processzor időt, hanem leginkább a memória használatot, aszinkron futási mód fejlettségét értem alatta.
Vajon miért van nagyon kevés java-s publikus hoszting? Mert míg egy néhány GB ram-os gépen több tucat asp.net-es alkalmazást futtathatsz, addig örülsz ha ugyanazon a vason elfut néhány jvm, és akkor még nem beszéltünk arról, hogy azok külön konténerekben vannak-e, meg összeakadnak-e, meg milyen időközönként fogy el a memória.
Távol álljon tőlem bármiféle java - .net flame, valaki kérdezett, én csak leírtam az eddigi tapasztalataimat. Nem volt célom senki lelkébe gázolni. -
modder
aktív tag
válasz
bambano
#7051
üzenetére
Bevallom, hogy elfogult vagyok a Java irányába, de nem a performancia tekintetében. Mindkét nyelv ugyanazon a módszeren alapul: virtuális gép, JIT. Mindkét platformon rohadt okos emberek dolgoznak, hogy jobbá tegyék, így szerintem sebesség tekintetében nem lesz nagy különbség, aminek örülök is, hogy tudtál igazolni.
De hogy még árnyaltabb legyen a helyzet a két nyelv közötti sebesség tekintetében, azt írja a péper, hogy Java 2 SE 1.3-mal mértek, ami 13 éves. A 13 év alatt mind a Java, mind a .NET hatalmas fejlesztéseken ment keresztül, úgyhogy nem lennék meglepve, ha a 16%-os különbség 0 közelébe konvergálna. Jó lenne ezeket a teszteket ma is lefuttatni.The Java HotSpot Virtual Machine is Sun Microsystems' virtual
machine for the Java 2 Platform Standard Edition since version
1.3. Java HotSpot VM consists of two basic components: the
runtime and the compiler. -
bambano
titán
válasz
martonx
#7048
üzenetére
Eszerint azt, amit jávában néhány tízmillióból kell összehozni, azt nem csinálod meg .net alatt sem sokkal kevesebből, mert a tesztje szerint átlagosan 16%-kal gyorsabb a .net és csak nagyon matekos feladatokban gyorsabb 75%-kal (ami a fordítási módszereket tekintve egyáltalán nem rossz eredmény).
-
modder
aktív tag
válasz
martonx
#7048
üzenetére
Nem tudom honnan veszed ezeket a teljesítményigényeket:
Java Több 10 milliós célhardver, tízmilliós nagyságrendű futtatókörnyezettel fog ugyanolyan teljesítményt szolgálni, mint ugyanaz a szoftver .NET platformon 1-2 milliós befektetéssel? Azért ne rugaszkodjunk már el a valóságtól, vagy mutass legalább egy hivatkozást, ami ezt alátámasztja.Egyébként azt tökéletesen el tudom képzelni, hogy a 10-15 éve megírt legacy Java alkalmazás alatt még a JVM-et sem merik megmozdítani, mert annyira fontos feladatot lát el, hogy jobbnak látják inkább alá pakolni a hardvert, mint bármit megmozdítani a szoftveren. Ez nagyon sok helyen tendencia. De ez nem egyenlő azzal, amit mondasz, mert a mai Hotspot VM amibe folyamatosan migrálják a jRockit VM optimalizálásait 600x jobb futásteljesítményt fognak biztosítani, mint a 10 évvel ezelőtti.
-
martonx
veterán
válasz
Jim Tonic
#7042
üzenetére
Minden nézőpont kérdése. Ha nagyvállalatoknak fejlesztesz java-ban, ahol nem téma egy tizmilliós nagyságrendű célhardver beszerzése, rá egy szintén tízmilliós nagyságrendű futtató környezet beszerzése (pl. weblogic), és van a linux-od mögött egy komoly üzemeltető, akkor valóban azt látod, hogy hol van itt a teljesítmény probléma, mikor ezekkel zökkenőmentesen kiszolgálsz pár ezer usert.
Aztán mikor mindezt megcsinálod .Net-ben, és egy néhány milliós hardveren (beleértve az oprendszer árát is), egy szál részmunkaidős üzemeltetővel az alap IIS-en pont ugyanolyan zökkenőmentesen elfut a pont ugyanolyan tudású rendszer, és pont ugyanannyi usert szolgál ki, akkor bizony sokan elgondolkoznak a platformok közötti erőforrás használáson, és hogy mégis melyik éri meg jobban.
És hogy ez még szemléletesebb legyen, vajon miért olyan ritkák a publikus elosztott java hosztingok? Ha ugyanolyan erőforrás kímélő, mint a PHP vagy a .Net? Költői kérdés volt.
Hozzáteszem a java nem rossz, iszonyatos történelmi beágyazottsággal rendelkezik, főleg a pénzügyi szektorban, ami nem jöhetett volna, ha rossz lenne. Csak a világ közben ellépdelt mellette, de pont ez az a szektor, ahol marha lassan váltanak, meg a tízmilliós nagyságrendek különben is aprópénznek számítanak.
A PHP meg teljesen más kérdés. A PHP teljesítmény problémái korántsem olyan vészesek (mára), mint amilyen rossz a híre. A híre meg azért rossz, mert a PHP világ tele van vérpistikékkel, akik főállásban kókányolnak (illetve régebben jóval macerásabb volt a PHP-t bytekódra fordítani). Tény, hogy alapból meg sem közelíti egy Java vagy .Net futásteljesítményét, de viszonylag könnyen, és ami a legfontosabb továbbra is ingyenes cuccokkal lehet optimalizálni.És végül egy alapvetés. Rosszul optimalizált kódot bármilyen nyelven lehet írni
-
Jim-Y
veterán
2008-as rendszerű C szakirányon már tudtommal egyáltalán nincs C++, se C#, de java 4-5 féléven keresztül. B szakirányon asszem van pár félév C++, utána C#. talán...
Nem igazán tudom, mert én még nem a 2008-as tanrendben kezdtem, nekem volt C++ több félév is, majd átmentem 2008-ra C szakirány, itt volt már 4-5 félév Java-m is.
-
válasz
bambano
#7041
üzenetére
Nem úgy értettem, hogy a webről is az optimalizálatlansága miatt szorulna szorulna ki. Egyszerűen, ahová teljesítmény kell, ott sokan kritizálják. Tény és való, hogy pl. egy játékprogramot komoly kompromisszumokkal tudnál benne megírni. Ugyanakkor az is igaz, hogy az SAP app serverei JAVA-ra (is) épülnek. Webre eléggé terjed a .NET, a LAMP meg inkább az egyszerűsége miatt kedvelt. Hozzáteszem, én csak desktopra dolgoztam JAVA-val. Érdekes nekem anno a suliban a JAVA-t kellett ész nélkül tolnom, talán ezzel a nyelvvel foglalkoztunk a legtöbbet, de nemrég meglepődtem, hogy az egyik egyetemen mérnök infón alig esett róla szó BSc.-n.
#7040: A GUI tenyleg lassu, de ez a platformfuggetlenseg ara, nem kell benne desktop appot irni es kesz. Erről van szó, azaz mégsem jó feltétlenül ezt ajánlani kezdőknek.
-
skoda12
aktív tag
válasz
Jim Tonic
#7039
üzenetére
Te vagy a masodik, aki aluloptimalizaltsagra hivatkozik, de szerintem ez nem igaz. Tozsdeken, bankoknal a low-latency penzugyi rendszerek javaban keszulnek vagy ott van pl a Cassandra, Neo4j , amik pont performanciara kihegyezett NoSql rendszerek es javaban keszultek. Nyilvan ezeket azert profik irjak. Ezenkivul jvm fuggo is a dolog. Volt olyan projekt, ami 30%-ot gyorsult, csak attol, hogy a hotspot jvm helyere JRockitet tettek. De lehet real-time jvm-eket is venni, ha az kell. Csak ezekkel a rendszerekkel az atlag felhasznalo nem talalkozik. A GUI tenyleg lassu, de ez a platformfuggetlenseg ara, nem kell benne desktop appot irni es kesz.
-
válasz
skoda12
#7036
üzenetére
Ez nem flame, erre való a topik.
Manapság sokan félnek az Oracle miatt tőle. Az rendben van, hogy tömegével vannak hozzá library-k, azonban a Java alapban optimalizálatlan, lassú, nagy bájthalmaz, ami sok (egyre több helyen) elfogadhatatlan. A webről egyes jóslatok szerint kiszorítja a LAMP és a .NET.
Persze nehéz megmondani, mi lesz a valóság, de még régen magam is határozottan a JAVA-t ajánlók közé tartoztam, ma már nem így van. -
#25954560
törölt tag
válasz
skoda12
#7036
üzenetére
ennyi. a szempontok dontik el.
szamomra aluloptimalizalt, bosszant az oracle telepitoje, stb. de egyszeruen vannak szempontok, ami miatt megis erdemes lehet java-t hasznalni. barmit hasznalsz, ugyis mindig kompromisszum. hol a fejlesztesi ido, hol a teljesitmeny, hol a karbantarthatosag. -
skoda12
aktív tag
válasz
Jim Tonic
#7028
üzenetére
Egyébként a Java érzésem szerint az Android nélkül (ami nem is Java) komolyan kezd veszíteni a vonzerejéből
Nem akarok flame wart inditani abszolut, de az igazsag az, hogy nalunk folyamatosan esnek be az uj javas projektek, van koztuk greenfield project is. Tavaly is vettunk fel egy csomo fejlesztot, most is kene hirtelen ~100 javas ember ev vegeig es meg kulfoldon is nyilnak uj szabad pozicioink valoszinuleg. En alapjaban veve C++ kedvelo vagyok, de be kell ismernem, hogy uj (nem desktopos) projectet en is javaban inditanek a meglevo libraryk bosege miatt.
-
#89874944
törölt tag
Igen, jól gondolod. Egy szimulátort készítek. Mobil hálózatokat vizsgálom, felhasználókkal, bázisállomásokkal, linkekkel. Először betölti a hálózati topológiát (vagy saját maga készíti el), aztán magában a szimulációban a felhasználók mozognak, adatot forgalmaznak, bázisállomást váltanak. Egy ilyen szimulációs kör nem tart sokáig, 3 másodperc, csakhogy ebből legalább 60ezer kell. A 3 másodperc 97%-a megy el az adott indexű objektum megkeresésével, ezt szeretném csökkenteni.
Akkor a map value részében konkrétan egy objektum példány legyen?
-
modder
aktív tag
válasz
#89874944
#7033
üzenetére
esetleg ez? http://www.mathworks.com/help/matlab/matlab_prog/mapping-to-different-value-types.html
több változót nem fogsz tudni tenni egy Map-be, előbb csinálnod kell valamilyen tároló objektumot, és azt tárolod el értékként.
Adatbázissal kapcsolatban:
Ha Matlabban írsz programot, akkor gondolom valamilyen elemző algoritmust készítesz, ahol egyszer betöltöd az adatokat a programba például csv fájlból, majd sokszor szükséged van rájuk a futás során. Amíg a memória nem korlátoz, ne szenvedj adatbázissal, mert az ugyanúgy sokkal lassabb lesz, mintha közvetlenül a program memóriából érnéd el a változóidat. -
#7033
#89874944
törölt tag
Sk8erPeter
#7031
#89874944
törölt tag
válasz
Sk8erPeter
#7031
üzenetére
Ilyet még nem csináltam. Tudnál egy linket adni ahol van ehhez leírás, példák?
modder:
Matlab-ot használok. Ennek most a Map object-jét próbálgatom. [link]
Ez vmi java hash. Csak eddig nem sikerült több változót is mögé raknom, az egy darab value nem lesz elég. -
modder
aktív tag
válasz
#89874944
#7030
üzenetére
Igen, a hash az ilyen. Jó volna tudni, hogy milyen programnyelven akarod implementálni, a legtöbb programnyelvben be van építve a hash (például az asszociatív tömbök ilyenek) vagy keresőfák. Ha nincs beépítve, valamilyen jól ismert könyvtár tartalmazza őket.
A másik lehetőség egy keresőfa. Ezek sem maradnak el nagyon a hash táblák mögött, de támogatja az intervallum keresést: x - y kulcsok közötti értékeket adja vissza. Ez utóbbi hash táblával lassabb is lehet, ha -tegyük fel- több 10 vagy 100 egymás utáni elemet akarsz visszakapni.Érdemes még megnézni, hogy konkrétan milyen implementációt használ a nyelv vagy könyvtár. Nekem is volt rá szükségem, hogy Javában több százezernyi objektumot tároljak hash táblával, amit először a Hashtable-lel próbáltam, de nem jött össze, mert annak egybefüggő memória terület kell, és nem tudott akkorát foglalni magának a program, LinkedHashMap-re átváltva már minden király volt (ez hashtáblák láncolt listában)
-
#7031
Sk8erPeter
nagyúr
#89874944
#7030
Sk8erPeter
nagyúr
válasz
#89874944
#7030
üzenetére
Használj adatbázist, táblákban tárolva a szükséges adatokat, normalizálásról, majd a megfelelő mezők indexeléséről ne feledkezz el.
Aztán az alkalmazásban olyan objektumokba töltöd a szükséges adatokat, amilyenbe csak szeretnéd.
Egy jól indexelt adatbázisban többmillió adatból is pillanatok alatt tudsz keresgélni (persze a sebesség szerverkonfigtól is függ). -
#89874944
törölt tag
Sziasztok!
Adatszerkezetet kellene választanom, sebesség szempontjából. Most az objektumokat (felhasználók, állomások, egyéb ) egyszerű tömbökben tárolom, az objektumokban egy egyedi azonosítóval és sok egyéb váltózóval. Ezeken az objektum tömbökön elég sokszor kell végigfutni, ha keresek vmit, és mivel elég sok is van belőlük ez nagyon sokáig tart. ( még nem teljes készlettel indítottam, és így is 4 millió ciklus)
Vmi olyan adatszerkezet kellene amit keresés nélkül tudok indexelni, ha tudom hogy a 213-as azonosítójú elem kell nekem, akkor ne menjen végig az elejétől az egészen.
Jól gondolom, hogy a hash az ilyen? Van másik lehetőség is? -
#7028
Jim Tonic
nagyúr
Peter Kiss
#7027
válasz
Peter Kiss
#7027
üzenetére
Szerintem arra gondolt, hogy az Androidra fejlesztés helyett válasszon valamilyen általánosabb célú megoldást elsőre, csak rosszul fogalmazta meg. Nekiugrás helyett jobb lenne javító szándékkal helyesbíteni.
Ha kötözködni akar az ember, Te is hülyeségeket írtál:
Milyen az az általános célú programnyelv? -> Ilyen.
Érted, Java csak "3 billion devices" szöveggel nyomul, és nem általános. Nem attól lesz általános, hogy mennyi eszközön fut. Egyébként a Java érzésem szerint az Android nélkül (ami nem is Java) komolyan kezd veszíteni a vonzerejéből. Még 5-10 éve az abszolút sláger volt, én sem feltétlenül ezt tanácsolnám. Jó lenne tudni, hogy az a 3mrd miből jön össze. -
#7027
Peter Kiss
őstag
Sk8erPeter
#7026
Peter Kiss
őstag
válasz
Sk8erPeter
#7026
üzenetére
Érted, Java csak "3 billion devices" szöveggel nyomul, és nem általános.
-
#7026
Sk8erPeter
nagyúr
Peter Kiss
#7024
Sk8erPeter
nagyúr
válasz
Peter Kiss
#7024
üzenetére
Mondjuk arra én is kíváncsi lennék, a Java például miért "specifikusabb" célú...
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
repvez
addikt
Valaki képben van a directx terén? Létezik olyan program amivel a játékvezérlőnél meg lehet változtatni a gombok sorszámát?
Mivel a windows alapból csak 32 gombot támogat és nekem van egy USB-s játékvezérlő panelem amin 64 gombot lehet rákötni.
Csak fizikailag ugy sikerült ráforrasztanom a vezetékeket,hogy 32-es számú fölé is került és igy nem látja a win.
32 alatt vannak még üres helyek,de úgy nem tudom rendesen ráforrasztani igy jó lenne ha softveresen tudnám átmozgatni a sorszámát , hogy a win felismerje.egyszerre most csak 28 gombot használok.
Vagy az is jó lenne ha 2x 32 es játékvezérlőnek ismerné fel,csak mivel 1 usb-n csatlakozik igy gondolom ez nehezebb megcsinálni. -
#7023
bucsupeti
senior tag
freelanced
#7022
bucsupeti
senior tag
válasz
freelanced
#7022
üzenetére
Meg tudnád írni bármilyen nyelven a következő kis programot:
Kérj be 20 db egész számot. Számold ki az átlagukat, majd írasd ki a számokat és az átlagtól való eltérésüket.Ha ez megvan bármilyen nyelven, akkor tényleg a java-val kell foglalkoznod, ha androidra akarsz fejleszteni.
Ha nem tudod megcsinálni, akkor még ne foglalkozz Javával. Inkább valami általános célú programnyelvvel kezdj (én a pascalt javaslom)
-
#7022
freelanced
addikt
freelanced
addikt
Üdv! Köszönöm!
Igen, lehet, hogy a kérdésem volt a hibás
Egyelőre én sem tudom mire lesz szükségem de informatikával szeretnék foglalkozni viszont ez a része jobban érdekel mint a többi, valószinűleg alkalmazásokat írnék de hát ez mind feltételezés. Érdekel az android téma is ezért gondoltam elsőre, hogy a java vonalon kezdenék. Viszont nem tudom, hogy melyik úgymond népszerűbb.
-
#7021
Jim Tonic
nagyúr
Sk8erPeter
#7019
válasz
Sk8erPeter
#7019
üzenetére
[Gonoszság ON]: Olyat szeretett volna, ami a genetikai térképéhez passzol.
[Gonoszság OFF]
Viccet félretéve, Freelanced, ha beírod a keresőbe, hogy "milyen nyelv, melyik nyelv", tonnányi válasz lesz. Könyvekkel, tanácsokkal, mindennel. Ám nekem mindig az a meglátásom, hogy ha Te komolyan érdeklődsz a programozás iránt, akkor konkrét elképzelésekkel érkezel a topikba, aztán megkérdezed a többiek véleményét a tervedről. Ne vedd bántásnak, de tényleg így van, szvsz. -
#7020
bucsupeti
senior tag
freelanced
#7017
bucsupeti
senior tag
válasz
freelanced
#7017
üzenetére
Azt írtad: "semmi tapasztalatom nincs a programozás terén".
Ebben az esetben általános programozással kell alapozni, amiről 10 hozzászóláson belül olvashatsz néhányat (az egyik pl a #7011)
Miután az alapvető dolgokkal tisztában vagy utána jöhet a konkrét célhoz illő nyelv/környezet kiválasztása és arra specializálni a tudást.
-
#7019
Sk8erPeter
nagyúr
freelanced
#7017
Sk8erPeter
nagyúr
válasz
freelanced
#7017
üzenetére
Hát az valóban kellemetlen szituáció, mert tényleg pont ugyanarról szólt a korábbi, belinkelt kérdés+válasz.
Ha konkrétabbat akarsz, és nem vagy elégedett az eddigiekkel, akkor konkrétabban kérdezz. -
#7018
Jim-Y
veterán
freelanced
#7014
Jim-Y
veterán
válasz
freelanced
#7014
üzenetére
En a helyedben kideritenem, bogy majd milyen feladatkorben kell programoznod, ugyanis irtad, hogy szukseged lesz ra. Na de megis mire lesz szukseged? Webet kell programoznod, vagy adatbazisokkal kell foglalkoznod, vagy egy szervert kell majd menedzselned, vagy alkalmazasokat kell irnod?
nyilvan mindent nem tudsz megtanulni, ezert kene pontositani, hogy mire lesz szukseged.
a fenti temakorokben en ezeket ajanlanam:
web: html5, css3, javascript + kesobb valami szerveroldal
web-vallalati: JEE
adatb: ingyenessege miatt MySql, tanulasra jo
szerver: bash, python
desktop: .NET, Javabarmelyik is lesz a vakasztottad, eloszor keress neten valami atfogo leiras a programozasrol, alapfogalmairol stb, utana pedig mehet az adott nyelv referenciaja, tutorialok olvasasa, es gyakorlas, gyakorlas, gyakorlas..
-
#7017
freelanced
addikt
freelanced
addikt
Lehet, hogy bennem van a hiba, de kicsit személyre szabottabb választ vártam, mert elolvastam az előzőt én is még sem lett sokkal tisztább a dolog...
-
#7016
bucsupeti
senior tag
freelanced
#7014
bucsupeti
senior tag
válasz
freelanced
#7014
üzenetére
az utolsó kb 5 hozzászólás erről szól...
-
#7015
plaschil
aktív tag
freelanced
#7014
plaschil
aktív tag
válasz
freelanced
#7014
üzenetére
-
#7014
freelanced
addikt
freelanced
addikt
Üdv!
Segítséget szeretnék kérni tőletek. Semmi tapasztalatom nincs a programozás terén, most szeretnék nekikezdeni, mivel szükségem lesz rá valószinűleg, ezért elkezdeném tanulni.
Viszont nem tudom, hogy is kezdjek hozzá, melyik nyelvet érdemes elkezdeni.
Tehát nagyon örülnék minden tanácsnak, hogy mivel fogjak hozzá és hogyan.
Nagyon köszönöm előre is!
-
bucsupeti
senior tag
válasz
AkosAkos
#7008
üzenetére
Algoritmusok és adatstruktúrák témát is olvasgathatod. Tanulj meg először algoritmusokat, foglalkozz adatszerkezetekkel, gyakorold az elemző, rendszerező gondolkodást.
Én azt javaslom hogy általános célú programnyelven kezdj tanulni. Az objektumorientált nyelvek szerintem nem jók kezdésnek. A Pascal nyelv ugyan régi és manapság már nem nagyon használják, de szerintem programozás megtanulására ideális. A C sok szabadságot ad, és éppen ezért a tanulás nehézkes lehet benne. A Pascal kötöttebb, ezért vezeti szinte a tanulót. Sokan más véleményen vannak ezzel kapcsolatban, de nem hitvitát akarok ezzel indítani (én magam jelenleg C(++)-ben és Java-ban programozok, Pacalban és Basicben tanultam, de komoly dologra ezek egyikét sem használtam)
A Visual Basic szerintem felejtős és én nem javaslok semmilyen "visual" rendszert a tanuláshoz.A programozás nem azt jelenti hogy valamilyen programozási eszközzel programot készítesz (ajajj). Az a kódolás. A programozás sokkal előbb történik. A kódolással csak materializálódik a program....
(((Van egy kezdő programozóknak készült blogom. Megtisztelsz ha meglátogatod. Talán még hasznos dolgokra is találhatsz ott.)))
http://programozz.blogspot.com -
#25954560
törölt tag
válasz
AkosAkos
#7008
üzenetére
akkor ketfele is indulhatsz. fogsz egy nagyon nepszeru nyelvet, amihez rengeteg forras, forum, szakirodalom all rendelkezesedre es belevagsz (pl c, java, python, pascal - a 'hello world' programmal erdemes kezdeni
)
vagy keresel valami nagyon altalanos leirast a programok mukodeserol (kornyezetek, kodolas, forditok, futtatas), gyakorlatilag barhol elkezded, tengernyi hivatkozas, uj link, referenciak jonnek veled szembe. ha olvasol angolul, meg jobb.
de egy tetszoleges *alapjai jegyzettel is el tudsz indulni, akar ezzel is. -
#7005
Sk8erPeter
nagyúr
Tomics
#7001
Sk8erPeter
nagyúr
"házihoz kell prog1-2 tárgyhoz"
Ha 2 féléved is lesz programozás alapjaiból, akkor feltételezem, olyan szakra jársz, ahol fontos szerepe van a programozásnak (ugye nem mérnök infóra vagy villamosmérnök szakra jársz?
), mivel később, más tárgyakból is szükséged lesz rá, tehát meg kell tanulnod programozni. Ha ennyire nem érdekel, miért nem hagyod inkább ott a szakot, és mész át egy teljesen másikra? Nem csak szopatás céljából szoktak házit feladni programozásból, hanem azért, hogy megtanulj önállóan (!!) is programozni.
Annyit kifelejtettem, hogy a tanárom mondta, mivel programtervező informatikus a képzés, legyen kicsit közelebb a .net programozáshoz, mint az elektronikához.
mert normálisat még nem láttam...
Azt hiszem ehhez nagyon el kell szánnom magam mert semmit nem értek a témához. Legalább +van merre induljak. Köszönöm 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
és ki tudja, hogy egy olyan, sokak által használt könyvtár, mint a Hibernate nincsen tele hasonló absztrakciókkal?
nálunk (BME m.infó) volt fél év c, fél év c++, fél év c#, és 14 ÓRA java gyakorlat, amolyan tanuld meg magad stílusban 
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- Milyen légkondit a lakásba?
- Kerékpárosok, bringások ide!
- Vezetékes FÜLhallgatók
- sziku69: Fűzzük össze a szavakat :)
- Parfüm topik
- Motorola G86 - majdnem Edge
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- MySQL topic
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Xbox Series X|S
- További aktív témák...
- PlayStation Portal 2026.12.03-ig gyári garanciával eladó!
- ASRock B560 Steel Legend + i5 11500 + ID-Cooling + 16 Gb Corsair Vengeance RGB Beszámitok!
- Samsung Galaxy A26 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 12 128GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Dell Latitude E5450 - i7-5GEN I 8GB I 256SSD I 14" FHD Touch I HDMI I Cam I W10 I Gari!
- BESZÁMÍTÁS! Intel Core i7 4770 4mag 8szál processzor garanciával hibátlan működéssel
- Bomba ár! Dell Latitude 7410 - i5-10GEN I 16GB I 256GB SSD I 14" FHD I HDMI I Cam I W11 I Garancia!
- Bomba ár! HP Pavilion 15 - i7-1065G7 I 16GB I 512SSD I Nvidia GTX1050 I 15,6" FHD I Cam I W11 I Gar
- Azonnali készpénzes AMD Radeon RX 9000 sorozat videokártya felvásárlás személyesen/csomagküldéssel
Állásajánlatok
Cég: FOTC
Város: Budapest