- Redmi Note 13 4G
- Samsung Galaxy A36 5G - a középső testvér
- Yettel topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- iPhone topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy A54 - türelemjáték
- Xiaomi 13 - felnőni nehéz
- Huawei Watch GT 5 Pro - egészség + stílus
- Magisk
-
Mobilarena
Új hozzászólás Aktív témák
-
#8166
modder
aktív tag
Oppenheimer
#8165
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.
-
modder
aktív tag
válasz
bambano
#8025
üzenetére
Hali,
Nem konkrétan programozáshoz kötődő kérdés, de hátha valaki foglalkozott már ilyennel.Lenne egy olyan (tipikus) promóció, ahol a termékre elhelyezett kódot be lehet küldeni sms-ben (vagy weben, de most az sms a lényeg). Ismertek olyan konkrét szolgáltatást, amivel meg lehet oldani a tömeges sms fogadást és küldést úgy, hogy az valamilyen API-n keresztül vezérelhető, hiszen a fogadott kódokat fel is kell tudni dolgozni automatizáltan?
Első keresésre ezt találtam:
https://seeme.hu/tudastar/reszletek/sms-gateway-leiras
Illetve t-systemnek van egy ilyenje, de nem találok róla infót, hogy ennek lenne API-ja, csak excel export lehetőség:
http://www.uzletitelekom.hu/informatika/uzletmenetet_segito_informatikai_szolgaltatasok/tomeges_sms -
modder
aktív tag
válasz
martonx
#7659
üzenetére
Scooby dou: Kivéve, ha kiderül, hogy valami "legendary" nagy koponya vagy, mert akkor csinálhatsz egy játékot például, amivel híressé válasz
Amúgy, ha komolyan akarsz vele foglalkozni, csak akkor ne menj egyetemre, ha nagyon nem tudsz 3,5-4 évet rászánni pl. semmi támogatást nem kapsz otthonról, nem jutnál be államilag támogatottra (mérnök infora, mikor én kezdtem, elég alacsonyak voltak a ponthatárok), pénzt kell keresned, hogy eltartsd a családod.
Megjegyzem, ha nem vesznek fel államilag támogatottra, akkor még mindig ott van a diákhitel 2, ami nem az ördögtől való, és ez legalább olyan szakma, amivel ki is tudod termelni a törlesztőt (mérlegelni kell, hogy -2M forinttal kezded az életed, de olyan munkád lesz életed végéig, amivel többszörösét visszakeresed). ha felvesznek, akkor pedig diákhitel 1-ből szűkösen, de eltarthatod magad. Csak ehhez az kell, hogy tényleg komolyan veszed, és megcsinálod rendes képzési idő alatt, mert ha félúton elbuksz, akkor nyakadban a törlesztő és még munkát sem fogsz kapni.
Ha tényleg nem akarsz menni, akkor egy papírt pl. helyettesíthet, hogy amikor eljutottál a megfelelő szintre, open source projektekbe segítesz be. Ez ingyen munka, de ha szerzel 1-2-3 komolyabb, sokak által használt projektet, amibe tehetsz be kódot rendszeresen mondjuk egy évig, akkor az már jó reputáció. Egyébként én azt javasolnám, hogy menj legalább levelezőre. Ezt a képzést pedig csak egyetemen: Óbudai Egyetem, ELTE vagy BME, esetleg Szegedi?
-
modder
aktív tag
válasz
lotuska
#7590
üzenetére
Szerintem 2 állásinterjúból ne szűrj le messzemenő következtetéseket. Egyébként a poszt első felét inkább tedd fel a "Jövedelem" topicban, ott fognak okosat mondani. Nem tudom, hogy hol voltál állásinterjún, de érdemes más, nagyobb befektetési bankokat esetleg könyv vizságó cégeket, mint PWC megkeresned, ha ilyen jó eredményeid vannak, és ambíciózus vagy. Elképzelhető, hogy valaki azt szűri le belőle, hogy te nem vagy csapatjátékos, mert túlságosan önérdekű vagy. Szerintem inkább gondolkodj el azon, hogy egy legközelebbi interjúban hogyan tudnád hangsúlyozni, hogy te csapatjátékos vagy. (Amúgy ezt az indokot atomfaszságnak tartom. Úgyis mindig ott van a próbaidő, ahol kiderülhetnek a dolgok)
Szóval szerintem emiatt ne válts....
szerk.: Meg hát nem ismerlek személyesen, de az is előfordulhat, hogy olyan a testbeszéded, amiből azt szűri le egy képzett HR-es, hogy te ilyen vagy. Akkor inkább ezen kéne változtatni.
-
modder
aktív tag
Tehát a válaszban "Accept-Encoding: compress, gzip" van, de maga a tartalom mégsincs tömörítve.
lehet, hogy csak elírtad, de ha a válaszban Accept-encoding van, akkor az irreleváns. a content-encodingot kell nézni. tudtommal az accept encoding csak requestnél használatos, ennek ellenére lehet, hogy a webszerver így tudatja a klienssel, hogy még mire képes.
-
modder
aktív tag
Egyébként ez melyik webserver vagy weboldal? Nekem nem tűnik helyes működésnek, hogy gzip tömörítést jelez, de nincsen tömörítve.
Nem feltétlenül működnek tökéletesen a webserverek, sajnos ezekre fel kell készülni egy valós alkalmazásban. Más is találkozott már ezzel a problémával: http://stackoverflow.com/questions/12280805/http-response-with-content-encoding-gzip-but-the-content-is-not-gzippedA válaszban azt írja a srác, hogy ebben az esetben a chrome hibát jelez.
-
modder
aktív tag
válasz
Jhonny06
#7567
üzenetére
Szerintem alapvetően a TCP/IP POSIX API-t értik ez alatt (vagy Windows API, ha az egyik már megy, a másikat is meg lehet tanulni). Értsd: tudj kódban listener portot nyitni, kapcsolatot fogadni, kapcsolódni másik géphez. Tehát papíron képes legyél ezeket leprogramozni.
Tudd mi a különbség a TCP, UDP, IP és más protokollok között (ICMP, TLS, DNS, alkalmazásszintű protokollok). Alapvető hibakezelési stratégiák a kommunikációban. Mit csinálsz, ha nem sorrendben érkeznek a csomagok (szintén UDP). Szálkezelés.
A Tannenbaum könyv egy referencia. Ha erre teszed fel az életed, akkor el kell olvasnod az általános részeket, de egyébként ha UDP kommunikációval foglalkozol, akkor fölösleges az ICMP csomagokat bit szintent ismerni. De az UDP-t pedig muszáj.
Példának okáért, hogy legyen fogalmad arról, miért kell a mély tudás (talán ezen az oldalon volt http://fabiensanglard.net/quake3/network.php)
Csak legfeljebb 1400 byteos UDP csomagokat küldözgettek a hálózaton annak ellenére, hogy elvben ~65000 byteos lehet egy UDP csomag, mert a default MTU a routereken általában 1500 byte. Sokkal nagyobb késleltetést okozna bevárni az összes slice-t a teljes UDP csomaghoz minden routeren, mint eleve kisebb csomagokat küldözgetni.
@bucsupeti Akkor sry
-
modder
aktív tag
válasz
doboka98
#7562
üzenetére
Ja, és ha már elkezded, tegyél egy szívességet magadnak, és ne PHP-val kezdd, hanem Pl. Python Django-val. (Igen, ezt is nagyon sokan használják, és hasznos tudás). https://www.djangoproject.com/
Pl. told végig a tutorialt: https://docs.djangoproject.com/en/1.6/ És igen, igazad van, nehéz belekezdeni, és sok minden lesz, amit nem fogsz egyből megérteni, de ez erről szól. Nincsen könnyen megszerezhető tudás. Egyszer mindenki megszenvedett azért, amit most tud.
Még mielőtt flamewarba kezdünk, azért írtam, hogy ne PHP-val, mert a PHP fos
-
#7558
modder
aktív tag
férfiállat
#7557
modder
aktív tag
válasz
férfiállat
#7557
üzenetére
hogy lásd, milyen nagylelkűek vagyunk
Windows alatt Visual Studio Express for Windows vagy Windows Desktop
http://www.visualstudio.com/en-US/products/visual-studio-express-vsÉn Eclipse-et szoktam használni MinGW-vel (ez gcc-t használ a windows compiler helyett). Google segít benne.
Code:
locksot nem ajánlom, mert egyetemen elterjedt, hogy milyen egyszerű és jó, aztán mindenkinek csak baja volt vele, hogy nem működik a debuggolás, meg úgy összességében egy fos. -
-
modder
aktív tag
alternatíva: (bocs, ha már írták) Képeknél érdemes vagy vízjelet a képbe generálni, vagy ha az oldal célja az, hogy a képekből hasznot húzzon, akkor mindig egy kisebb felbontásút vagy rosszabb minőségűt szoktak az oldalra feltölteni, ami jól látszik monitoron, de nem alkalmas arra, hogy kinyomtassák vagy újra felhasználják, beépítsék.
Sk8erPeterrel meg egyetértek, rettentően idegesítő a context menü letiltása. pl sokszor másolok onnan url-t. Amikor nem tudok, akkor mindig megőrülök.
-
modder
aktív tag
válasz
Tomi0703
#7368
üzenetére
Szakmai gyakorlaton? Akkor ez production kód?
Nem menő céges kódot kiposztolni az internetre. Nálunk rúgtak már ki embert azért, mert hazavitte a munkát.Mondjuk téged a kirúgás már nem fenyeget, de amikor elmész egy céghez dolgozni, akár szakmai gyakorlatra, az esetek 99%-ában aláíratnak veled titoktartási szerződés, szóval ezért akár még polgári perelhetnek is. Úgyhogy csak óvatosan az ilyenekkel.
Az meg a slusz poén, hogy ha lusta vagy, ne itt kérj segítésget. Ha tudsz folyamatábrát csinálni C, C++, Java kódból, akkor tudsz C#-ból is.
-
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.
-
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.
-
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. -
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.
-
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. -
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)
-
modder
aktív tag
de igen, lehet alternatíva, és nagyon sokan használták. viszont szerintem a perl szerepét kezdi átvenni a python. modernebb nyelv, és átláthatóbb kódot eredményez, mint a perl. utóbbiban nagyon gyorsan lehet hasznos programokat írni, de ha már valami több száz soros, később nagyon nehéz lesz megfejteni a működését. de amúgy igen, a perl is jó eszköz rendszergazdai feladatokra.
-
modder
aktív tag
válasz
McSzaby
#6993
üzenetére
http://docs.python.org/3.3/tutorial/
Vagy felmész amazonra, és megnézed melyik Python témájú könyv kapta a legtöbb csillagot, aztán letöltöd isohuntról vagy megrendeledÁtszokni egyik nyelvről a másikra mindenképpen munka. A legtöbb köztudatban élő nyelv imperatív nyelv. Így a Python, C, C++, Java, PHP, C# is, és még sok egyéb, így az alap koncepció nem változik: ciklusok, értékadások, függvények, vezérlési szerkezetek. Váltás közöttünk 1-2 hét kérdése, mire használható tudást birtokolsz
Azonban C++-ról Javara átszokni sokkal egyszerűbb, mint Pythonra, mert utóbbi esetben a Python szintaxisa teljesen más: függvénydefiníció sorbehúzással, és nem kapcsos zárójellel, for-each ciklusok máshogy vannak definiálva...
Viszont amikor az új nyelv új paradigmákat is hoz, például C -> C++ esetben objektum orientáltság és template-ek, vagy amikor imperatív nyelvről funkcionális nyelvre akarunk átszokni, akkor gyakorlatilag ismét meg kell tanulni az új nyelvet, nem csak átszokni.
-
modder
aktív tag
válasz
McSzaby
#6991
üzenetére
attól függ, mi a célod. ha csak meg akarsz tanulni programozni, hogy hasznos toolokat csinálj esetleg, akkor a python jó. Minden linux gépre egyszerűen telepíthető, gyorsan lehet vele fejleszteni, még webalkalmazásokhoz is fogod tudni használni Django keretrendszerrel. Ha közelebbi kapcsolatba szeretnél kerülni a linuxszal, akkor C. C-ben később írhatsz kernel modulokat, fájlrendszert, drivert, akármit.
A Python eladhatóbb tudás, ha például rendszergazdai feladatokat szeretnél ellátni, mert jóval egyszerűbb abban összehozni egy szkriptet valamilyen feladat automatizálására, mint C-ben. Például fájl soronkénti beolvasása, reguláris kifejezésre illesztés, szöveg kicserélése jóval egyszerűbb Pythonban.
Ugyanakkor szerintem egyiket sem nehezebb megtanulni a másiknál. C-től sokan félnek, de a Pythonnak is megvannak a buktatói, ahogy minden nyelvnek. Előbbivel annyi előnyre teszel szert, hogy kicsit közelebb kerülsz a számítógéphez, és jobban meg fogod érteni, hogyan működnek a programok: típusok, pointerek, egy objektum memóriaképe, heap, stack, memóriaszivárgás. csupa jó dolgok
szerk.: C++-t csak C után, de lehet, hogy nem is érdemes vele bajlódnod, mert az egy külön állatfaj. Én is csak mostanában jöttem rá, hogy mennyire bonyolult nyelv, és az átlagos C++ programozó a nyelv lehetőségeinek a felét használja ki.
-
#6880
modder
aktív tag
phanfantom
#6873
modder
aktív tag
válasz
phanfantom
#6873
üzenetére
Nálunk (BME) úgy volt, hogy voltak begyakorolható példák, ahol a konkrét algoritmussal kellett megoldani a feladatot. Itt az segít, ha magadnak papíron példa adattal levezeted az algoritmust: bejárások, keresések, beszúrások, akármi. Szerencsére kis méretű adatokkal szépen ki lehet próbálni a különböző algoritmusokat, és nagyon sokat segít a megértésben. Sőt, ha nem próbálod ki, csak egyszerűen elolvasod, és azt hiszed, hogy érted, az biztos fail.
Voltak a dinamikus programozásos példák, ez neccesebb. Például ott van a hátizsák probléma, vagy legrövidebb út keresés gráfban. Olyan feladatokat gyártottak, ahol az ott megtanult módszereket kellett alkalmazni kissé eltérő módon. Itt ha felismered az alap algoritmust, amiből ki kell indulni, az már félsiker. Erre a legjobb módszer megintcsak: papíron begyakorlod különböző példa adatokra. Ha van példatár, akkor az ott szereplő feladatokat visszavezeted egy tanult algoritmusra, és kitalálod, mit kell változtatni azon, hogy működjön a feladatbeli problémára. Például van a hátizsákprobléma, amit dinamikus programozással egy mátrixot töltesz fel sorról sorra, mindig az előző sor adatait figyelembe véve. Elég sok feladatot meg lehet oldani ugyanígy azzal a különbséggel, hogy más lesz a feltétel, ami alapján az új cellákat ki kell tölteni.
Erre értettem az előzőt: "Ha van példatár, akkor az ott szereplő feladatokat visszavezeted egy tanult algoritmusra," Sajnos itt gondolkodni kell: próbálni-elbukni-próbálni-elbukni, amíg ki nem találod a megfelelő algoritmust. Ahogy próbálkozol, és elbuksz, az eshetőségek szépen elraktározódnak az agytekervényeidben, így ZH-n már "tapasztaltabban" fogod kitalálni a megoldást.
-
#6874
modder
aktív tag
phanfantom
#6873
modder
aktív tag
válasz
phanfantom
#6873
üzenetére
sokat kell gondolkodni
-
modder
aktív tag
Mi hangzott el tőled, és hogyan lett kiforgatva? Mi a kérdés?
Szerintem a játékos esetre simán rá lehet húzni az inkompatibilitás definícióját. Amennyiben egy program a célját nem a specifikáció szerinti minőségben éri el, akkor helytelenül működik. A szoftvereknek működésének csomó aspektusa van. ahogy egy hard-realtime rendszerben a program kifut az időből (még ha helyes eredmény is adott volna), az ugyanúgy helytelen működésnek számít, mint ahogy a játék esetében a lassúság miatti használhatatlanság.
Egyébként a definícióhoz hozzá tartozik szerintem, hogy A szoftverkomponens akkor inkompatibilis B komponenssel, ha létezik legalább egy harmadik C szoftver, amivel B komponens képes helyesen működni ugyanazon az interfészén keresztül. Ekkor A hibájából nem jött létre a megfelelő együttműködés. Tehát van létező kompatibilis együttműködés B komponenssel.
Tehát Feltéve, hogy van olyan olyan emulátor (C), amin a játék (B) megfelelő sebességgel fut, én azt mondanám, hogy az eredeti emulátor (A) inkompatibilis a játékkal (és nem a játék a szar, pláne, hogy az emulátornak kell nyújtania az emulált környezetet, amiben a program fut, és nem fordítva)
-
modder
aktív tag
válasz
McNamara
#6566
üzenetére
Szerintem érdemes lenne bemenni megnézni egy órát, vagy csak bemenni és kérdezősködni, hogy miylen az oktatás. Manapság, ahol az felsőfokú szakképzéseket azzal hirdetik, hogy "Sok diákkedvezmény, diákigazolvány még 2 évig!! kedvezményes utazás!", ha valaki tanulni is akar, és nem csak fényesíteni a bránert, jól körül kell néznie hová megy.
Amúgy pedig ez az iskola arra lesz jó, hogy tényleg az alapokat megtanítsa, ahogy nézem heti 12 óra. az lófütty. Nem tudom mennyi a házi, de emellett még heti 12-24 órát kell programozni és gyakorolni MINIMUM, hogy az ember kilépve az iskola kapuin versenyképes legyen.
Ami pedig a cégeket illeti:
A jó önéletrajz eladja az embert, ha te fel tudod mutatni az önéletrajzodban, hogy a suli mellett van/volt egy pet projected amit fejlesztgettél, és leírod, hogy milyen eredményeket értél el vele, miket tanultál meg, vagy éppenséggel 1-2 mondatban milyen problémákat küzdöttél le, az nagyon imponáló! Az nem különböztet meg téged más programozóktól, hogy odaírod az iskola nevét, és standard technológia stacket amit ott megtanultál, ellenben konkrétumok már sokkal közelebbi képet festenek az emberről. -- különben is, az ember tanulja meg értékelni az erőfeszítéseit
-
modder
aktív tag
válasz
peterszky
#6435
üzenetére
Hasonlít a hátizsák problémára:
legyenek a számok súlyok. A hátizsákok az 1. listabeli elemek, maximális súly kapacitásuk pedig a szám.
A téglák a 2. listabeli elemek, súlyuk szintén maga a szám, értékük pedig legyen annál nagyobb, minél nagyobb a szám: tehát lehet maga a szám az érték is. Ez azért jó, mert ha úgy pakolsz egy hátizsákba, hogy nagyobb téglákat használsz, azzal kevesebbet is egyben, így nagyobb lesz a valószínűsége annak, hogy a kisebb értékekből a többi zsákot meg tudod tömni: mert több kisebb értékből több kombinációt tudsz összehozni.A probléma az, hogy amíg egy zsákos problémára van optimális algoritmus, addig a több zsák egy NP-teljes probléma, amire nincsen egzakt algoritmus. Elfogadható időben csak egy közelítőleg jó megoldást tudsz találni.
A probléma inkább erre hasonlít: http://en.wikipedia.org/wiki/Bin_packing_problemOtt van is két algoritmus.
Jó lenne tudni, hogy az 1. listabeli elemeket MINDIG ki lehet-e rakni teljesen a 2. listabeli elemekből, mert ha nem, akkor be kell vezetni egy mércét, ami értékeli a megoldást: Minél több 1. listabeli elemet tettünk ki; Minél több számot használtunk fel teljesen a 2. listából; Az 1. listabeli teljesen kirakott elemek összege maximális;
Nézd meg a fenti linket.
-
modder
aktív tag
válasz
szoke12
#6426
üzenetére
segítene egy kódrészlet
egyébként:/usr/bin/programod &
sleep 10
/usr/bin/masikprogram& a háttérben indítja
Ja, meg hogy "nem jön vissza hibaüzenet". Hát azért a programok elég sokfélék, hogy mit csinálnak
Várhat inputra, valami blokkolhatja, vagy lehet ez az alap működése. -
modder
aktív tag
Én valami ilyesmit próbálnék, nem ellenőriztem, hogy működik-e, de kíváncsi lennék mennyit fut
A $fileMap egy asszociatív tömb lesz, aminek az elemei listák az ugyanolyan nevű és méretű fájlok elérési útjáról. A végén csak azokat íratom ki, ahol ennek a listának a mérete nagyobb, mint 1, mert az azt jelenti, hogy több elérési út is tartozott ugyanahhoz a névhez és mérethez, tehát duplikált a fájl.
$loc = get-location
$files = get-childitem -Path $loc -Recurse | where {$_.Length -gt 0}
$length = $files.length
$fileMap = @{}
for($i=0;$i -lt $length;++$i){
$file = $files[$i]
$key = $file.Name + $file.Length
if($fileMap.ContainsKey($key)){
$fileMap[$key] += file.FullName
} else {
$fileMap[$key] = @(file.FullName)
}
}
foreach($duplicates in $fileMap.GetEnumerator()){
if($duplicates.length > 1){
Write-Host $duplicates.Name ( $duplicates.Value )
}
}
$fileMap > fileMap.txt -
modder
aktív tag
if($multiples -contains $files[$i].Name){ } -- Ahogy nő a $multiples tömb, egyre inkább több időt fog tölteni azzal, hogy a fájlnevet megtalálja benne, mert a -contains végignézi az egész tömböt. A duplikált fájlnevek tárolására használj inkább asszociatív tömböt, mert azt fájlnév szerint lehet címezni, és a szervezése Hash táblaszerű, tehát gyorsabb benne név alapján megtalálni egy elemet.
http://powershell.com/cs/blogs/tips/archive/2009/09/09/checking-whether-hash-table-contains-key.aspxfor($j=$i+1;$j -lt $length;++$j){
if($files[$j].Name -eq $elem.Name -and $files[$j].Length -eq $elem.Length){
$multiples += $files[$j].FullName
$ismultiple = 1
}
}
-- Itt a belső ciklusban szintén szekvenciálisan keresel végig a fájlnevek listáján, aminél átlagos keresési idő n/2. Jobb eredményt érsz el, ha először a fájlnevek listáját rendezed név szerint növekvő sorrendben, és egy ismert egyszerű kereső algoritmust használsz rá, pl. bináris keresés. Nem tudom, hogy erre van-e beépített szolgáltatása a Powershellnek, de lehet valaki már írt rá kódot a neten.Mivel gondolom egy egyszeri feladat volt, ezért már nem fogsz vele vacakolni, de van helye a fejlődésnek
-
#6403
modder
aktív tag
fordfairlane
#6402
modder
aktív tag
válasz
fordfairlane
#6402
üzenetére
igazad van, bevallom, nem néztem át tüzetesebben. Annyi mentségem legyen, hogy a kérdéshez hasonlóan a válaszom a teljesség igénye nélkül született
-
modder
aktív tag
az elég durva, ha két ujjal így gépelsz, most kipróbáltam 10 ujjal és nem lett sokkal jobb, mint a tiéd. Gondolom annak ellenére, hogy nem tudsz 10 ujjal gépelni, már nem nézed a billentyűzetet ..ha néznéd, nem tudnál ilyen gyorsan gépelni. Ha két ujjal is ilyen gyorsan gépelsz, nincs értelme megtanulni 10 ujjal gépelni, főleg, hogy amíg megtanulod, az kb. 1 év...
gépelni...
-
modder
aktív tag
válasz
bambano
#6279
üzenetére
Igen, ez hirtelen eszembe sem jutott.
Van olyan ismerősöm, aki természettudományi karon van, vagy biomérnöknek tanul, már tőlük is megkövetelik, hogy legyen fogalmuk a programozásról. És ők is kiszenvedik magukból a házikat.
Ezt csak azért mondom, mert nem tudom, mit tanul az illető hozzászóló, de ha nem informatikát, akkor is illedelmes lenne megpróbálni megoldani magától.Amikor valaki azzal kezdi, hogy nem tudja hogyan kezdjen hozzá, az már annak a következménye, hogy egész félévben beletojt a tárgyba. -- Aztán ilyenkor jönnek ezek a hozzászólások, amikor közeleg a határidő, és már nincs idő belerázódni
-
modder
aktív tag
válasz
Atti575
#6275
üzenetére
Gondolom iskolai vagy egyetemi feladat. Amúgy a fórumok nem arra vannak, hogy valaki megírja helyetted a programot, hanem arra, hogy segítsenek ha elakadsz egy problémával, amivel egyébként magadtól is tudsz haladni.
Amit te szeretnél arra az iskolatársak vagy barátok vannak, akiket meg lehet kérni hogy üljetek össze és csináljátok meg együtt, aztán meghívod egy fagyira, és nagyon hálás vagy neki.Ma már, amikor mindenki hajt hogy jobb legyen a saját területén (joggal) nem lehet elvárni az emberektől, hogy a kemény munkával megszerzett tudásukat rápocsékolják olyanokra, akik önerőből sem tudnak egyről a kettőre jutni.
-
#5832
modder
aktív tag
csucsbicep
#5830
modder
aktív tag
válasz
csucsbicep
#5830
üzenetére
a feladat egyszerűsége révén PHP. Már csak azért is, mert még egy évvel ezelőttig a PHP SDK volt a legfejlettebb, révén, hogy azt kezdtél el legelőször fejleszteni.
-
#5527
modder
aktív tag
SektorFlop
#5526
modder
aktív tag
válasz
SektorFlop
#5526
üzenetére
gyors googlizás után kiderült, hogy nincsen mysql jdbc driver androidhoz külön, és jar-t behúzni nem olyan egyszerű, mert java SE-re épül, és nem biztos, hogy minden megvan hozzá az android apiban. (valami ilyesmi a lényeg)
Szerintem jobban jársz, ha szerver oldalon csinálsz egy vékony REST service réteget, amiből lekérdezed az adatokat, mondjuk json-ben, és feldolgozod az alkalmazásban.
http://timewasted.net/?p=127 -
modder
aktív tag
Helló,
Az Indigo a legújabb Eclipse kódneve, eclipse.org-ról legkönnyebben azt tudod letölteni
Mivel a letöltések nem telepítőfájlok, hanem tömörített mappák, nincs szükség installálásra. Ez jó abból a szempontból, hogy megkönnyíti különböző verziók egyidejű jelenlétét is a rendszereden.
Én külön "telepítést" használok minden egyes nyelvhez, hogy a sok modul ne lassítsa be teljesen az IDE-t.
Itt van Java EE és Java SE-hez külön ide: http://www.eclipse.org/downloads/
PHP-hoz letöltöd pl az Eclipse classic-ot, azután eszerint jársz el: http://www.eclipse.org/downloads/php_package.php
Python-hoz is szerintem Eclipse classic, és ha szerencséd van, van fönt a neten valami modul, de biztosan találsz valami Python development in eclipse tutorialt a neten
-
modder
aktív tag
Köszi
Igen, előnye a C# technológiáknak, hogy mobilra is adaptálták őket sőt, nem akarok hülyeséget mondani, de talán még iPhone-ra is lehet .net-ben fejleszteni. Nem gondoltam, de kábeltelevíziós set-top-boxokra is bizony .net-ben fejlesztenek.
Én pedig még annyit fűznék hozzá, hogy manapság sajnos egy programnyelv ismerete már nem azt jelenti, hogy bekérek a parancssorból és kiíratok. Nagyon komoly és összetett technológiákat kell ismerni a piacképes tudáshoz adott rétegen belül is. Olyanok, mint az említett WCF, WPF, vagy amit mostanában tanulgatok Java EE platformon JPA, JSF és megannyi sok csúnya 3-4 betűs mozaikszó
-
modder
aktív tag
Nem tudom milyen a kódból generált XML doksi. Amit én használtam az a Doxygen, ami feloldja az asszociációkat a jól dokumentált Osztályok és függvények között, majd ezt egy jól érthető HTML vagy PDF formátumban kimenti osztálydiagramokkal együtt. Sőt, léteznek olyan szoftverek is, amik pusztán a kód olvasásából megértik az együttműködéseket, és az alapján generálnak diagramokat. Ezzel felváltható a kézzel megírt végleges fejlesztői dokumentáció egy része is. Nyilván az olvasható, jól dokumentált kód erény, de nem lesz ettől rendszerszinten áttekinthető.
Most mindannyian sokkal okosabbak lettünk
-
modder
aktív tag
válasz
Gülredy
#5256
üzenetére
Hali!
Az a baj ezzel a kérdéssel, hogy nem objektív, hanem meggyőződésből eredő válaszokat kapsz majd, ezért hogy jó nyelvet válassz magadnak meg kell fontolnod pár dolgot.
Először döntsd el, hogy milyen típusú alkalmazást szeretnél fejleszteni pl. hagyományos desktop, webes alkalmazás (website), webes kliens oldali, háttérben futó rendszerszintű programok, mobil nevezzük ezeket rétegeknek. Majdnem minden mainstream programnyelv lefedi ezeket a rétegeket, azonban a választás segít eldönteni, hogy milyen információkat keress.
Én azt ajánlom, hogy ha eldöntötted, hogy milyen réteget és programnyelvet választasz, akkor ragadj hozzá, és szerezz róla magabiztos tudást, majd mehetsz a többi rétegre is ismerkedni velük.
Áttekintés rétegenként
1) Desktop alkalmazás:
Egyértelműen C# és .NET. Azért, mert a legelterjedtebb a Windows. Olyan technológiákat használ, amiket átültetheted kapásból mobilra is, ha arra szeretnél orientálódni.
Emellett nekem még tetszik a C++-ban Qt. A Qt egy grafikus könyvtár és egy előfordító. Linuxra KDE ebben íródott, Nokia telefonokon lesz elérhető.2) Webes alkalmazás:
ASP.NET és webes technológiái, Java EE és webes technológiái, PHP, illetve szaporodik a Ruby on rails. PHP-ból sok a munka, sok a programozó is, szerintem nem fizetik meg annyira. Az első kettő közül mindegyik piacképes tudást ad, viszont rettentő sok technológia épül rájuk.3) Webes kliens:
Flash... hát nem tudom, nekem nem szimpi. Silverlight elterjedőben, keresett. Emellett egyre nagyobb tudást igényelnek a kliens oldali JavaScript könyvtárak, HTML5 ilyesmi.4) Rendszer:
c++ unix/linux alapon, windows alapon .net, c++. Emellett az operációs rendszerek nagyon átfogó ismerete, és oprendszer api kőkemény ismerete.5) Mobil:
Java: Android; .net: windows mobile; C++ Qt: nokia; Objective-C: iPhone, Ipad.6) Grafikai program:
Ha játékot akarsz írni, akkor C++ és OpenGL vagy C# és XNA.Üzleti megfontolások, mivel szakíthatsz a legtöbbet?
Szerintem Webes szerver oldali platformokkal, de sok idő beletanulni, azonban ezen a vonalon szép karriert lehet csinálni. (ASP.net, Java EE)Mivel juthatsz legkönnyebben a piacra?
Web: kliens + PHP; Manapság még android vagy iPhone fejlesztési gyakorlattal.Ez a lista a teljesség igénye nélkül született, és az én objektíven szubjektív megítélésem
-
modder
aktív tag
Igaz, hogy a kód lehet jó dokumentáció, de ehhez a kód jól dokumentáltsága is szükséges, amiből aztán jó dokumentáció generálható. Nem Javadoc, mert az nem mutat semmit, de pl. Doxygen (vagy fizetős vállalati eszközök). -- ezt csak megjegyzésben írtam, tegyük fel, hogy ez adott.
Jól kifejtetted, a teljesség igénye nélkül néhány dolog ami még eszembe jut.
Mint mondtad, különböző modulok kapcsolódási pontjához hasznos a dokumentáció. Tegyük fel, hogy egy library-t megírt egy fejlesztő, aminek a használata szükségessé válik a projekt egy előrehaladottabb fázisában. Itt már nem biztos, hogy az automatikusan generált osztálydiagram elég, mert az nem fog semmit jelenteni a többi fejlesztő számára a lib használatát illetően. ilyen esetben, akár a hivatalos fejlesztői dokumentációban is megjeleníthető legalább valami kollaborációs diagramra szükség lesz, amit a fejlesztőnek kell létrehozni. -- te is hasonlóra gondoltál?
Egy kis csoportról beszélve, akik egy modulon dolgoznak, pedig szintén nem árt, ha ismerik az UML-t. Egy megbeszélés alkalmával rögzített program flow-t lehet rögzíteni akár papírra, így az adott iterációban vissza lehet hivatkozni rá. Kvázi ez egyenlő azzal, hogy nem kell fejben tartani. Ez egy informális dokumentáció, de UML-t használva még kevesebb hibához is vezethet, mint egy "móriczkarajz"
A használati eset és az activity diagramm legyen a projektvezető dolga szintén.
Ebben igazad van, de valakinek (a szoftverfejlesztőnek) el kell tudni olvasni azt.Rengeteg példa van arra, hogy a rendszer változott, csak a doksikban nem vezették át.
Igen, sajnos a dokumentációt is karban kell tartani. Ha már automatikusan generált doksit említettem, ezt lehet a buildelési fázishoz is kötni. Viszont elvetemült öltet lenne minden iterációban újravizsgálni a dokumentációt is.Egyetértek azzal, hogy nem kell túldokumentálni mindent, és jól működik általában a szoftverfejlesztés formális és informális megbeszélések alapján. Ami igazából a mondanivalóm, az az , hogy az UML teljesen alkalmas ezen megbeszélések alkalmával információátadásra, ideiglenes dokumentációként.
Dekompozició elve:
Minden dekompozició legvégül egy adatbázis tervhez vezet, de tényleg fölösleges az egész rendszert megtervezni adatbázis szinten az elején. Tulajdonképpen az iteratív szoftverfejlesztés pont erről szól, nem? Nem lehet úgy végigcsinálni egy szoftverfejlesztést, mint egy hidat: terv -> implementáció -> kész
-
modder
aktív tag
Hali,
Az UML előnye nem is az 1-2 fős projekteknél ütközik ki, ahol a fejlesztő egy személyben a business analyst, az architect, a manager, a tesztelő is. Bár kifejezetten hasznos.
Amikor több: 5-10-20 fős fejlesztői csapatot kell koordinálni, akkor bizony a fejlesztési módszertanokkal együtt az UML-t is használni kell. Ezek együttesen segítenek mind a szoftver, mind a szoftverfejlesztés minőségét javítani. Persze a dokumentáció mennyiségének növekedésével a szoftverfejlesztés időtartama kitolódik.
Néhány példa, hogy mikor előnyös:
UML activity diagram: Egy nagyobb cégnél a fejlesztők nem találkoznak az ügyféllel közvetlenül, de tudniuk kell mit várnak el a szoftvertől. Ennek lekommunikálásának egyik leghatékonyabb módja pl. egy UML activity diagram.
UML use-case diagram: Az UML activity diagramot az ügyfél beszámolója alapján elkészített use-case-ből generálják. Máris van egy dokumentum, amihez tudnak a fejlesztők fordulni, ha kérdésük van a program flow-val kapcsolatban, és nem kell a BA-t csesztetni.
UML class diagram: szerintem erre gondoltál, amikor azt mondtad, hogy ez úgyis változik, hiszen a belső struktúra az, amit először nem lehet a legjobban eltalálni. Ugyanakkor egy nagyobb projektben szükség van rá interfészek deklarálásához, mert különböző komponenseket különböző fejlesztők készítenek el, tudniuk kell, hogyan csatlakoznak ezek egymáshoz.
UML szekvenciadiagram: Ennek előfeltétele az UML class diagram, megmondja, hogy a komponensek vagy osztályok hogyan kommunikálnak egymással. Ez egy specifikáció a tesztelők számára, akik nem ismerik teljes mértékben a szoftver belső működését, de felismerik, ha az üzenetváltások nem a specifikáció szerint alakulnak.
UML kommunikációs diagram: Más fejlesztők által létrehozott komponensek hogyan kommunikálnak majd egymással. Ennek szerepe lehet architektúra tervezésnél, és mérvadó lehet a kommunikáló komponensek interfészeinek kialakításánál.A diagramok egy része az implementáció megkezdése előtt születik, más részük közben, megint más részük utólag. Természetesen elkerülhetetlen a változás, mert nem lehet minden eshetőséget lefedni a fejlesztés során. Sajnos rossz gyakorlat az, hogy a dokumentációt fejlesztés után készítik el, és a fejlesztés gyakorlatilag ad-hoc módon történik: a fejlesztők egymás között ledumálják ki mit csinál, aztán probléma van, amikor össze kell hegeszteni a dolgot egy egésszé. Erről legtöbbször nem a fejlesztő tehet, mert a határidő mindig valamikor tegnap.
El kell fogadni, hogy a dokumentáció a fejlesztés szerves része, és mint említettem, nagyobb projekteknél a kommunikáció folyamatossága érdekében elkerülhetetlen rossz vagy éppen jó. A példákból pedig látható, hogysajnosa fejlesztőnek is részesülnie kell belőle....szerintem
locksot nem ajánlom, mert egyetemen elterjedt, hogy milyen egyszerű és jó, aztán mindenkinek csak baja volt vele, hogy nem működik a debuggolás, meg úgy összességében egy fos.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- AKCIÓ! GAMER PC: Új RYZEN 5 4500-5600X +RTX 3060/3070/3080 +Új 16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ
- UHH! HP EliteBook 840 G8 Fémházas Laptop 14" -45% i5-1145G7 4Mag 32/512 FHD IPS Intel Iris Xe Magyar
- Xiaomi Redmi Note 13 Pro 5G - 8/256 - Media Markt garancia
- Xiaomi Redmi 9at - 2/32 - szürke
- Xiaomi Mi8 - 6/128 - fekete
- Lenovo Legion 5 15ACH6 Az ár irányár, komoly érdeklődés esetén van lehetőség egyeztetésre
- AKCIÓ! MSI B550 R7 3700X 16GB DDR4 512GB SSD RTX 3060Ti 8GB Rampage SHIVA Seasonic 650W
- Csere-Beszámítás! Asus Rog Strix RTX 3070Ti 8GB GDDR6X Videokártya!
- BESZÁMÍTÁS! HP Elitebook 840 G11 üzleti notebook - Intel Core Ultra 5 135U 16GB DDR5 RAM 256GB W11
- LG 65BX - 65" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest