- Házimozi haladó szinten
- Házimozi belépő szinten
- Kormányok / autós szimulátorok topikja
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- 5:4 képarányú SXGA monitor jön ősszel az EIZO berkeiből
- Hobby elektronika
- Gaming notebook topik
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen videókártyát?
- Vezeték nélküli fülhallgatók
Aktív témák
-
Kkocos
tag
válasz
Jim Tonic
#186
üzenetére
A velemenyemet lenyegesen arnyaltabba teszi ez, ahol nem igazan lehet objektumokrol beszelni.Ha az objektumok tulajdonkeppen standardizalt kodok, akkor viszont, a legritkabb eseteket leszamitva, gyari funkciokon kivul nincsenek objektumok. Ha pedig, es a legtobb esetben igy van, par soros kodot akarsz beirni, nincs is szukseged standardizalni, a kulon blokokk hasznalatat nem indokolja semmi, sot csak belasitanak es meg atlathatatlanabba teszik a dolgot. Ez meg inkabb igy van ha tobben is belenyulnak a kodba.
Persze, a legtobb PC-s nyelvek mar nem tudnanak OOP nelkul meglenni, de kivetelek itt is vannak (Matlab), ahol sokkal jobban boldogulsz funkcio meghivasos modszerrel, mivel a tipuskonverziok nincsenek tamogatva, pointerek nem leteznek, stb.
Tehat ha a felhasznalt adat rendezeserol, felhasznalasanak modjarol van szo, ugyanugy el lehet boldogulni, OOPval mint nelkule. SQL-re csak alapszintem van szuksegem. Minden mukodik, csak a HM interfeszhez es a komunikaciohoz hasznalok objektumokat, de nem ezek a lenyeges, ha ugy tetszik "dolgozo" reszei a programnak, a tobbire csak a renszerbe agyazashoz van szukseg.
Elsore ennyi -
Lortech
addikt
válasz
norbiphu
#184
üzenetére
Szerintem azt válaszd, amihez jobban értesz, mert inkább az határozza meg majd az alkalmazásod teljesítményét, nem a két platform közötti teljesítménykülönbség. Egyébként alkalmazásoktól függően elég változó az egymáshoz viszonyított teljesítményük, de nagyjából egyforma teljesítmény érhető el velük. Ahol esetenként nagyobb különbség van, az a gyári osztályok megvalósításainak különbségében keresendő. (általában)
-
Minél nagyobb programot írsz, annál inkább előnyhöz jut az OOP. Egy osztályt annyiszor veszel elő, amennyiszer akarsz, és elég mindössze a nevét tudnod.
Kevés nyelv van manapság, ami nem támogat OOP-t. Kevesebb, mint a másik oldalon.
Ha a plattform-függetlenségről beszélünk, akkor meg ott a JAVA, amire a többi nyelv nem igazán képes.Kicsit régi dologra feleltem, de csak azért tettem, mert anno én is pont ilyen szemellenzős voltam. Pár soros programot ma sem raknék osztályokba, de már megváltozott a véleményem.
-
bdav
őstag
válasz
norbiphu
#184
üzenetére
úgy tudom .net gyorsabb valamivel
átlag weboldalhoz tökmindegy, elég gyors mindkettő, ha rendesen csinálod + értelmes gépet raksz alá.
Amúgy ha jól veszem ki a kommentedből, ennél az alkalmazásnál úgyis az adatbázis lesz a szűk keresztmetszet, az meg szintén nem annyira a keretrendszeren múlik. Mennyi lenne az a sok adat? -
norbiphu
őstag
nem találtam a kérdésemnek jobb helyet, remélem itt választ kapok rá.
tud valaki egy .net vs j2ee performancet mutatni valamerre? persze az is jó, ha véleményezitek a témát
. egy darabot találtam msdnan, azt nem tartottam túlzottam mérvadónak. olyan weboldalhoz kéne amin sok (nagyon sok) adatbázisban tárolt adat van (felhasználói profilok sok adattal, események, fórumok stb). 
előre is köszönöm
-
-
cucka
addikt
a php szkriptnyelv, ezért egyrészt butaság a c#-al hasonlítgatni, másrészt kifejezetten előny olyan esetekben, amikor valami egyszerűbb feladatot kell gyorsan megoldani - csakúgy, mint mondjuk a perl-nél.
vagy csak én vagyok annyira perverz, hogy az általános script feladatok jó részét php-ban írom meg? -
Vico87
tag
Egyébként én is legszívesebben C#-ban fejlesztek manapság. Nekem jobban tetszik a Javanál, a C++ pedig tök jó, csak lassabb benne fejleszteni (nagyokat tud nézni az ember egy-egy lefelejtett apróság által generált hibák miatt, amire egy felügyelt kódban nem kell figyelni).
Egyetértek azzal, hogy PHP-ben a típusbiztonság nem éppen megoldott dolog (kifejezetten nem tetszett, amikor először láttam PHP kódot, nekem valahogy reflex, hogy van típus, egyébként ezért is tartom a JavaScriptet undorítónak). -
bdav
őstag
válasz
Protezis
#177
üzenetére
firebug szvsz kevesebbet tud azért, bár tény hogy nem rossz, használom énis (breakpointban nem vagyok biztos, lehet bele rakni?). mondjuk ezt úgy mondom hogy igazán a VS2008 lehetőségeit ne ismerem a téren, és a bugot ise 100%-ig
C# vs. PHP: egyszerűen az előbbit jobb nyelvnek tartom. olyannyira hogy a most népszerű programozási nyelvek közül a legjobb (Javanal okosabb, C++-t meg akkor használok ha van rá valami jó okom, mert tény hogy többet kell szöszölni vele). Természetesen elismerem hogy a php-vel össze lehet hozni nagyon komoly oldalakat (és .net / java-val nagyon rosszakat), de akkor sem szeretem. pl. típusbiztonság nem nagyon van benne, debugolni nehéz, és ha nem használsz valami keretrendszert akkor nagyokat lehet gányolni vele.
A Microsoft megoldása elég letisztult ebből a szempontbólmvc meg nem technológia hanem design pattern vagy architektúrális pattern leginkább. Az meg az alkalmazás íróján múlik hogy mennyire követi
MS amúgy valami hasonlót már elég régóta támogat (Document - View, konkrétan MFC az nagyon ilyenre készült anno)Az én álláspontom az hogy alapvetően amit mostanában produkál a Microsoft az elég jó. A programozási eszközeik 2005-től kezdve mindenképp (akkor volt hasonlóan nagy launch, VS2005, .net2.0, sql 2005). az, hogy nem az ő ötletük az annyira nem zavar, mert nem mondthatom hogy 1az1ben nyúltak, hanem próbálták az "elődök" hibáit kiküszöbölni + ez bevett dolog ebben a szakmában (Sun is nyúlt ám rendesen a C#-ból az új Javakba). És végül hogy az előadásuk közben mit vakítanak, attól maga a cucc még nem biztos hogy rossz
-
Protezis
őstag
JS debug: firebug (bar ezt a reszet nem igazan hasznalom, nem tudom miota tudja)
"asp.net az a megjelenítésért felelős elsősorban, az alkalmazás vezérlését valami c# kód csinálja. ez önmagában nagyon nagy előny a php-hez képest." - ezt nem teljesen ertem. Mi az elonye a php-val szemben? Ha tobbgepes rendszert akarsz, akkor a php nyilvan nem jo megoldas, egyebkent mindegyiknek megvan a maga elonye es hatranya (egyebkent php-t is lehet parhuzamositani tobb gepen, nem is 1 megoldassal, igaz ami igaz, ezek nem beepitett featureok)
A php-val mindosszesen azert hozakodtam elo, mert abban van tapasztalatom orm-et es mvc-t illetoen (amik az MS-nel uj, illetve bevezetesre varo technologiak).De ahogy eszreveszem, egy allaspontot kepviselunk, csak mondhatni te szemet hunysz a dolgok felett, en meg az eloadas utan kicsit kikeltem magambol. De kezd eltunni a hab a szambol, es megfogadtam, hogy legkozelebb inkabb itthon maradok
-
bdav
őstag
válasz
Protezis
#175
üzenetére
ezen a hozzáálláson nem kell meglepődni, minden nagy cég olyan tálalásban adja elő a saját cuccait, mintha az lenne a világ 8. csodája. nem a marketing szöveget kell nézni, hanem a mögöttes tartalmat.
JS debug: én VisualStudio 2008 előtt nem láttam olyat ami hasonló szinten tud js-t debuggolni mint ez (breakpoint a js-be pl.)
asp.net az a megjelenítésért felelős elsősorban, az alkalmazás vezérlését valami c# kód csinálja. ez önmagában nagyon nagy előny a php-hez képest.
-
Protezis
őstag
"PHP azért messze nem egy kategória egy .nettel" - valoban nem, de ha az asp.net-et nezzuk (vagy akarmi is a pontos neve), akkor a ket dolog celja ugyanaz: webes kiszolgalas.
Mostmar vegleg felszivodott bennem az a gondolat, hogy az MS talalja ki az uj dolgokat, vagy akar csak reszben. Sajnos viszont sok ember azt gondolja, hogy wow, linq, mvc, js debug, ezaaaaz. Kozben meg ezeket masok mar reg hasznaljak. (emlitett olyat az eloado srac, hogy js-t eddig nem lehetett debugolni
)Ha ugy zajlott volna az eloadas, hogy ez es ez az orm, erre valo, az MS megvalositasat linq-nak nevezik, es igy mukodik..., egy szavam nem lenne. Nem ezeknek az eszkozoknek a letjogosultsagat, hasznossagat vitatom, hanem a koritest, amivel talaljak oket.
sghc_toma: koszonom!
-
sghc_toma
senior tag
válasz
Protezis
#172
üzenetére
egy mondatra reagálnék az írásból, erre:
Hogy az MS miert tartja komplexebbnek, bonyolultabbnak az opengl-t, mint a directx-et, arra nem jottem ra.a körítés miatt, gondolom.. legalábbis én amiatt tartom egyszerűbbnek a Direct3D-t.. pl. van kész vektor, kvaternió, textúra, vertex buffer, mesh, stb. osztály.. aztán az fx file-ok: szerintem sokkal egyszerűbb kezelni, mint az OpenGL vertex- és fragment shadereit.. úgy összességében kényelmesebb használni..
-
bdav
őstag
válasz
Protezis
#172
üzenetére
igazándiból a Microsoft elmúlt 2 évi fejlesztéseit nem igazán követtem, csak demo szinten láttam belőle dolgokat.
írásodhoz: PHP azért messze nem egy kategória egy .nettel
JavaScript debug az egy marha hasznos dolog + az is jo alapvetően hogy valami keretet tesznek az Ajax alá.
linq: orm az valóban nem egy új ötlet, és mondjuk a Hibernate - EJB3 Entity féle megoldás nekem jobban bejön. de valami ilyesminek a megvalósításával már adós volt a Microsoft egy ideje, pont amiatt hogy Java világ már tudja
-
Protezis
őstag
Ot eves egyetemi kepzest nem szabadna erre alapozni.
Mindenki: Miert jobb szalak helyett processzeket hasznalni? Ha a biztonsag a lenyeg, vagy akar tobb gep kozott akarjuk elosztani a feladatokat, akkor nyilvan processzeket kell inditani (mondjuk PVM), de ha egy felhasznaloi program idoigenyesebb reszet akarjuk parhuzamositani (1 gepen), akkor a szalazas elonyosebbnek tunik szamomra.
-
bdav
őstag
válasz
Protezis
#166
üzenetére
app szerver (akár .net akár java) párhuzamosítás nem arról szól hogy ilyen számítási műveletek kellenek. Ezek üzleti szoftverekhez készültek és pl. egy session beanból kifejezetten nem szabad szálat indítani. Itt ipikusan nem számolsz sokat. És amikor elmész programozó melóra, többségében ilyenek lesznek.
-
P.H.
senior tag
Protezis #163 és #166
A "túlmisztifikálás" kicsit erős volt, nem tagadom, de nem sokkal több az elméleti háttere, mint amit leírtam, az alkalmazása az adott szituációtól függ (és jó úton indultál el #166-ban: képzeld mondjuk ezt el egy 3x3 helyett 3000x3000-es mátrixra, egy vs. több szálon). Elméleti síkon (oktatásban) arra lehet elmenni nagyon messzire, hogy critical section-ök, összehangolás (amik közösadat-elérésnél mindig előjönnek, lásd adatbázisok), de tervezési fázisban ezek száraz tények, megvalósítási megközelítésben sem annyira fontos annyira ez, csak az OS-adta segítségek ismeretéig.
Egy példa:
A korábbiakban felmerült ebben a topikban a Dijkstra-algorimus. A legtöbb idő és energia azzal megy el, hogy megtaláld ezt és az ehhez kellő adatábrázolást, mint ideális megoldást az adott problémára. Magát az alapalgoritmust épeszű embernek nem jutna eszébe párhuzamosítani, mert többet veszt vele, mint nélküle. Viszont ha a - kapcsolatokra - alkalmazandó dinamizmus sokkal összetettebb és időigényesebb, mint amennyit a leírt alapadminisztráció megkövetel, akkor érdemes lehet elgondolkodni azon, hogy az épp feldolgozott ponthoz csatlakozó élek végleges súlyát ne párhuzamosan számoltassuk-e ki (a tárolás mellett többek között ezért fontos a listás gráfmegközelítésnél, hogy a lehetséges maximális kapcsolatszám egy ponthoz ismert-e).(Emlékszem persze - 0 amúgy
-, de nem akarok se szembemenni, se megerősíteni azt az oktatási nézőpontot, amiben én voltam: sok jót tudok mondani róla, de sok rosszat is; egyrészt a tanultak legalább 80%-át hasznosítottam azóta - mégha azt is gondoltam akkor, hogy erre nekem semmi szükségem nem lesz soha -, másrészt megtanított arra, hogy csak a specifikációknak higgyek, bármiről is legyen szó). Minden algoritmus megoldható egy szálon, maga a "programozás" talán arról szól, hogy a probléma és annak megoldása adott és kézzelfogható legyen. Hogy hogyan lehet »hatékonyabban«, az más megközelítés .dabadab #165 és #167:
Szál és process összehasonlítás SZVSZ nem ilyen egyszerű. Több szál azonos virtuális címtartományban fut egy process-en belül, ergo közös memóriájuk van, azonos adatterületen - főleg forrásadatoknál fontos ez - dolgozhatnak nagyjából kis ráfizetéssel (#166), de tényleg sok hibalehetőséggel (ezen a téren a CPU-gyártók is követettek el hibákak). A process-ek közti adatáramlás sokkal költségesebb, bonyolultabb (jellemzően file-alapú), viszont úgy látom, a világ mégis az előbbi felé halad (de leszögezem, a Linux lelki világát nem ismerem). Erről a Windows-os urban legend-ről még nem hallottam (de erről lehet szó itt is), de mégis arra haladnak a CPU-k, hogy azonos process-ben futó szálaknak minél kevesebb felesleges hátráltatást okozzanak task-váltáskor (gondolok itt AMD TLB-k esetén az Address Space Number-re, és Intel-nél a Hyperthreading-re és a speciálisan erre - nem csak alap több processor-ra - felkészített/optimalizált programokra is); pl. egyre fontosabb, hogy azonos process-hez tartozó szálak ne dobják ki a TLB-k és így az L1 cache-ek teljes tartalmát (amit tényleges process-váltásnál valóban meg kell tenni).
-
dabadab
titán
válasz
Protezis
#166
üzenetére
Ha hihetunk a varosi legendanak, akkor szalak egyedul azert vannak mindennapi hasznalatban, mert (es ez a resze tenyleg igy van) a Windows schedulere tul sokat pocsol(t) a processzek kozti kontextusvaltassal. Akar hogy is, mostanaban az a divatos elkepzeles, hogy a parhuzamositast szalakkal oldjak meg, nem processzekkel, ami joval tobb gond es hiba forrasa, mint amennyit egyszerusit a kommunikacion.
-
Protezis
őstag
"Meg mondjuk szerintem udvos lenne vegre leszokni a szalakrol es megint szep, tisztesseges processzeket hasznalni, tessek vegre rendes schedulert irni a Windowsba is" - ez erdekelne.
Egy processz ugye tobb szalbol allhat. Ezek a szalak - mivel egy processzen belul futnak - osztaznak az eroforrasokon, elerik ugyanazt a memoriateruletet. Mig processzek kozott nincs ez a szoros kapcsolat. Nem ertem, miert akarsz megszabadulni a szalaktol, amikor ha jol emlekszem a tanultakra, nem egy sulycsoportban vannak?!
Egyebkent meg most is indithatsz tobb processzt.Elobbiekhez: Parhuzamositasra pelda, ami ma jutott eszembe. Egyik jelenlegi kot.progomban matrixokat forgatok. Totalisan parhuzamosithato. Persze lehet, hogy semmi ertelme egy 3x3-as matrixnal inditani 9 szalat, de nem is ez a lenyeg, hanem az, hogy amikor megirtam a muveletet, eszembe nem jutott volna ez. Es ez a gond. Nem neveltek ra, hogy ha lehetoseg van ra, hasznaljam. Es ezt bizony nem parhuzamositja nekem automatikusan se a .NET Fw, se a Java VM.
-
dabadab
titán
"amúgy szvsz ma ha valaki programozónak megy, akkor meló közben 80% hogy nem fog saját maga párhuzamos szálat kezelni"
Nyilvan egy szal magamban nem vagyok tul reprezentativ pelda, de en eleg rendszeresen osszefutok azzal, hogy nekem kell tobb szalat programoznom. Igazabol debuggolni rossz nagyon, mert attol fuggoen, hogy az OS-nek epp' hogy sikerul idozitenie a szalakat, vagy elojon a hiba, v nem (vagy egy masik jon elo
).Meg mondjuk szerintem udvos lenne vegre leszokni a szalakrol es megint szep, tisztesseges processzeket hasznalni, tessek vegre rendes schedulert irni a Windowsba is
-
bdav
őstag
válasz
Protezis
#163
üzenetére
hát nekem nem volt párhuzamos programozásról kifejezetten tárgyam, de a problémakör elméleti síkon több helyen is előjött. sőt csináltam párhuzamosítást, java tárgy keretében, mert kellett
de az primitív volt.amúgy szvsz ma ha valaki programozónak megy, akkor meló közben 80% hogy nem fog saját maga párhuzamos szálat kezelni, mert elfedik előle a ma használt vállalati eszközök (ejb, .net ha úgy használod). ami felmerül az a "több-kliens ugyanazt az adatot bizgeti" probléma, amire szintén van aránylag jó megoldás (tranzakció), de itt azért néha gondolkozni kell hogy akkor most mivan.
-
Protezis
őstag
Miert tetted OFF-ba? Szerintem nagyon is ide tartozik.
Nem misztifikalom tul, legalabbis nem ez volt a celom. Amiket leirtal, azokrol mind tanultam mind elmeleti, mind gyakorlati sikon (Occam, Java). Ettol fuggetlenul peldaul volt olyan, hogy algoritmusok es adatszerkezetek tantargy kot.programjanal ki volt kotve, hogy nem lehet tobb szalat inditani
Es most tekintsunk el attol, hogy adott esetben celszeru lett volna, vagy sem.Raadasul ha visszaemlekszel (ha vissza kell, nekem nem, en meg egyetemista vagyok), akkor azokon a programozos orakon, ahol nem a parhuzamos programozas volt a kozeppontban, meg tudod mondani, hanyszor lattal/irtal tobbszalu programot? En igen: 0.
-
P.H.
senior tag
válasz
Protezis
#160
üzenetére
"Bar volt ilyen szakiranyos tantargyam, szerintem a jelentosegehez viszonyitva keveset foglalkoznak vele egyetemen."
A párhuzamosítást nem kell túlmisztifikálni, inkább csak megvalósítási, mint tervezési szemlélet, az algoritmus természetén múlik, hogy lehet-e egyáltalán, illetve ha lehet, hogyan lehet így megközelíteni.
Alapvetően két szemlélet lehetséges:
- a feladat több, egymástól független részfeladatra bontása: pl. ha egy kép átméretezése a feladat, akárhány részre (~szálra) bontva meg lehet tenni, a darabok függetlenek egymástól, lehetőség van közvetlen forrásmemóriából célmemóriába való feldolgozásra.
- több soros feldolgozási lépés van (kb. így működnek a médialejátszók), gyakorlatilag egy pipeline-on mennek keresztül az adatok: pl. adatkitömörítés->dekódolás->szín-hang konverzió->átméretezés. Egy-egy szálon egy-egy ilyen lépcsőfok fut, amelyek között ideiglenes bufferek (vagy ezek rendszere) tartják a kapcsolatot.
Lehet még beszélni a szinkronizációk elvéről, közös adatterületek elérési szabályairól, de sokkal több nincs benne.Amire nem lehet ráhúzni valamelyiket, azt nem lehet párhuzamosítani; és algoritmuselméleti szempontból az ilyen párhuzamosítás csak konstans lineáris gyorsulást hoz, tehát elméleti megközelítésben "meglehetősen unalmas" (soha nem okoz pl. NP->polinomiális vagy polinomiális->logaritmikus időigény-csökkenést), bár bír gyakorlati jelentőséggel (mivel irreális időigényű algoritmusokat úgysem programoznak le általánosan közzétéve).
-
doc
nagyúr
válasz
Protezis
#160
üzenetére
ez jo otlet, koszi!
igen, nalunk is csak egy felev parh.prog volt (valami pascalfc vagy hogy hivtak azt a nyelvet), ami epp' csak arra eleg, hogy az embernek nemi halvany fogalma legyen szemaforokrol, meg ugy altalaban a problemakrol amik elojohetnek, de tenyleges mt programozashoz keves volt
emlekszem, az elmeletre ugy kaptam meg a kettest hogy "na most az egyszer megadom", a gyakorlati vizsga meg ugy tetszett a tanarnak, hogy ott huldezett hogy hu de jo, jajj de jo, aztan mikor latta hogy milyen lett az elmelet, azt mondja: "nagy baj lenne ha csak harmast adnek?" mondom nekem nyóc, nem kell a kredit -
Protezis
őstag
"esetleg van még ötletetek, hogy milyen témákkal érdemes foglalkozni?" - huhh. Mindennel erdemes, de mivel nem adtal meg temakort, ezert modok olyat, ami sok helyen elojon: multithreading
Bar volt ilyen szakiranyos tantargyam, szerintem a jelentosegehez viszonyitva keveset foglalkoznak vele egyetemen.
-
doc
nagyúr
válasz
Protezis
#158
üzenetére
köszi mindkettőtöknek
a gond az, hogy nem írtam még olyan programot, ahol ez tényleg hasznos lett volna (vagy csak nem jöttem rá)
de majd befalom a könyvet, igyeXem megérteni, aztán a végén még Qrva okos leszek
esetleg van még ötletetek, hogy milyen témákkal érdemes foglalkozni? a Design Patterns is úgy jutott eszembe, hogy láttam pár álláshirdetésben, gondoltam csak megnézem már mi ez
tervezem még alaposan belemerülni a QT-be, idővel az OpenGL-be, de hirtelen nincs más ilyen jellegű ötletem -
Protezis
őstag
Akkor hasznos, ha garantalni akarod, hogy egy adott osztalybol csak 1 objektumod lehessen. Tipikusan adatbaziskapcsolodast megvalosito osztalyok eseten hasznalatos (meg persze rengeteg mas helyen). Olyan, mintha csinalnal egy globalis valtozot (egeszen pontosan egy globalis valtozohivatkozast, vagyis objektumhivatkozast... ehh), csak az nem tul szep megoldas. "Peldanyositaskor" pedig nem kell arra figyelned, hogy van -e mar olyan tipusu objektumod, vagy sem, a pattern elfedi eloled.
Az elozo OFF wolf7191 kolleganak ment
-
dabadab
titán
"(tudom mire val, de hogy miért jobb, mint simán használni egy class-t, az még nem esett le)"
A singleton azert jobb, mint a globalis valtozo (ill. objektum), mert egyreszt az inicializacio csak akkor fut le, amikor tenylegesen szukseg van ra, masreszt meg azert, mert nem globalis valtozo
-
doc
nagyúr
-
Protezis
őstag
Szia!
Singleton patternt rendszeresen hasznalok, egyszeru es nagyszeru
Ezen kivul hasznaltam factoryt, valamint elmeleti (ill tervezesi) sikon flyweight mintat. A tobbivel nem nagyon volt meg dolgom. Nagyjabol a felenel jarok az Erich Gamma fele konyvnek, es arra jottem ra, hogy eleg sokat kell hasznalni egy mintat, hogy igazan megertsd es a megfelelo helyen hasznalni is tudd. Az a legtobbszor nem megy, hogy adott problema eseten felcsapod a konyvet, es a tartalomjegyzeket vegigbogaraszva keresel egy szimpatikus mintat: 1 ora, mire felfogod, meg 1, mire nagyjabol megerted, miert is jo az, aztan meg 1, mire rajosz, hogy nem is az kell neked Es netan ezt akarod leprogramozni? Nezd meg a bongeszod cimsorat.
A forumban fent keress ra: ip, de tudod mit? Tessek! -
wolf7191
csendes tag
Sziasztok! Nem tudom mennyire vág a témába. De ti biztos többet tudtok erről mint én!
Nekem egy olyan problémám lenne, hogy regisztrálva vagyok az elitware.net oldalra, ahol sok jó dolgot lehet letölteni (film, zene, egyéb)
Általában minden több részeletben van rar formátumban. A bajom az, hogy egy részletet engedélyes letölteni, utána 90 perc szünetet kell tartani, mert többet nem engedélyez ingyen.
(http://rapidshare.com) Az IP cím alapján azonosítja, hogy töltöttél -e le már. nem tudom, hogy lehetne ezt kijátszani. Lehetséges ez valahogy -
Vico87
tag
válasz
S.P.Q.R.
#147
üzenetére
Hát ez tényleg attól függ, hogy mit programoz. Mert aki világ életében ügyviteli rendszerekkel foglalkozott, annak elég a négy alapművelet, aki viszont pl grafikával, annak óhatatlanul kell a gráfelmélet, lineáris algebra, geometria, stb...
Szerintem a középiskolás anyag a minimum, ami ajánlott programozáshoz, mert az már elég arra, hogy viszonylag sokféle problémát legalább alapszinten ismerjen az illető. -
S.P.Q.R.
csendes tag
Nah minekutána volt itt már szó algoritmusokról szerintem óhatatlanul felvetődik a kérdés, igazából egy programozónak mennyire kell jónak lennie matematikából?
Tudom ez kicsit tág kérdés szal inkább pontosítok, munkája során ki mennyire használja az analizist, esteleg a statisztikát valszámot, operációkutatást, halmazelméletet(ezt szerintem sokan) kriptográfiát, mátrixokat, mod 2-es algebrát stb...
Illetve ha te lennél XY egyetem rektora a mai informatikusoknak(főként a szoftverfejlesztőknek) melyik tárgyakat tartanád ezek közül a legfontosabbaknak?
üdv:
S.P.Q.R. -
S.P.Q.R.
csendes tag
Nem vitatozni akarok, én se használok főként mert ez egy elméleti modell amit algoritmusok vizsgálatához használnak fel(persze valóban épiteni lehet ilyen gépet). Használható továbbá annak bizonyitására, hogy léteznek algoritmikusan nem modellezhető problemek. Szal nem igaz az amit a 30-as évekig hittek: "midnen megoldható csak eleget kell rajta tökölni"
Én csak ebböl indultam ki, ennyi -
S.P.Q.R.
csendes tag
Ezzel vitatkoznék erősen. Vannak ugyanis algoritmikusan eldöntetlen/algoritmikusan nem modellezhető problémák.
Amelyekhez Nem tudsz olyan Turing gépet késziteni ami biztosan megáll!
És van ilyen
(Post probléma valamikor a 30-as években jöttek rá)
És vannak számitástechnikai szempontból kezelhetetlen algoritmusok is.
idézek:'A kezelhetetlen probléma definíciója
- Azok a problémák amelyek a futási idő
tekintetében a feladat méretének
exponenciális függvényével jellemezhetők,'
itten va hozzá egy jókis jegyzet, amiből a fenti idézet jött...
http://mokk.bme.hu/mediatervezo/targyak/programozas/media5_2.pdf
mindenkinek jó programozást meg fórumozást:
S.P. -
S.P.Q.R.
csendes tag
Bár kicsit brutálabb problémákat meg kell nézni hogy egyáltalán megoldható-e hatékonyan vagy létezik-e rá egyáltalán vmi. algoritmus.
Lásd Turing gépek,
http://www.kfki.hu/chemonet/TermVil/kulonsz/k002/algoritmus.html
Erröl jut eszembe P=NP?:S
már láttam anno a bme-n ilyen pólót is -
#141
Vico87
tag
kicsitomi88
#139
Vico87
tag
válasz
kicsitomi88
#139
üzenetére
Ha ez már egy "hogyan / hogyan ne programozzunk" topic, akkor leírom, hogy mindig érdemes algoritmuselméleti könyvben megnézni, ha valamire szükségünk van algoritmusra, ugyanis ha van benne, akkor nagy valószínűséggel jobb, mint amit mi találnánk ki, és még meg sem kell erõltetni magunkat (és így mindenki jobban jár).
Egy pár "híres" algoritmus:
gráfok : Dijkstra, Floyd, Bellman-Ford
rendezés : beszúrásos, összefésüléses, gyorsrendezés, kupac
keresés : lineáris, binárisEzekhez persze "járnak" adatszerkezetek is. És még egy tanács : ha algoritmusról van szó, akkor biztosan nem az elsõ gondolat a helyes
. -
#140
P.H.
senior tag
kicsitomi88
#139
P.H.
senior tag
válasz
kicsitomi88
#139
üzenetére
"Miert is erzem ugy, hogy ezt elobb tanulni(tanitani) kene mint csinalni(feladni otthonra)..."
Ez azért árulkodó: nehogy túlbonyolítsd! Ebbe a hibába sokan beleesnek. Csak azt oldd meg, ami a feladat.
Ha ez túlmutat azon, amit eddig tudsz/tudnod kellene, érdemes megkérdezni még egyszer, hogyan értették; lehet, hogy nem is az a feladat, amit gondolsz.Bár az olvasgatás nem árthat meg
-
#139
kicsitomi88
őstag
P.H.
#138
kicsitomi88
őstag
Nagyon köszönöm mindenkinek a valaszt, csak annyi gondom van, hogy az eletbe nem csinaltam meg hasonlot sem.
Tehat ha jol gondolom a feladatom az, hogy a szokott modon beolvasott adatokat egy elore kigondolt adatszerkezetbe helyezzem el amin vegrehajthato a dikjstra algoritmus. Miert is erzem ugy, hogy ezt elobb tanulni(tanitani) kene mint csinalni(feladni otthonra)...
Na jolvan, azt hiszem most egy kis olvasgatas jon a listas szerkezetrol.
-
#138
P.H.
senior tag
kicsitomi88
#134
P.H.
senior tag
válasz
kicsitomi88
#134
üzenetére
Szegedre jársz - ha nem tévedek -, gondolom, az Algoritmusok és adatszerkezetek tárgy ismerős (lesz, másodév). Oda az azonos című, részben helyi szerkesztésű könyv alapvető (nagy, fekete az a kiadása, ami nekem is megvan), abban nézz körül pl.
Ahogy írták is, a két alapvető gráftárolási megközelítés a mátrixos és a listás. Pár pro és kontra mindkettőre:
Mátrix-alapú:
- az adatszerkezet mérete exponenciális a pontok számával, mivel minden pont-pont kapcsolat helye - ha nem is lézetik ilyen - szerepel benne, ezért sűrű gráfok esetén érdemes alkalmazni
- Ha a kapcsolatoknak/éleknek több tulajdonsága is van (nem csak a hossza), akkor több, párhuzamos mátrix vagy nagyobb elemi mátrixelem-méret szükséges
- nagyon hatékony algoritmusok vannak a legrövidebb utak meghatározására (ebből érdemes kiindulni amúgy, az összes lehetséges még könnyű, a többi eléggé elbonyolítható), de nehéz dinamikussá tenni.Lista-alapú:
- nagyon hatékony adattárolási forma ritka mátrixokra: felsorolod a pontok mellé, hogy mely pontokkal állnak kapcsolatban
- viszont általános megoldásokban egyik kulcsjellemzője az egy ponthoz tartozó maximális (előre látott) lehetséges kapcsolatok száma, ennek változásával a hozzá tartozó algoritmusok is jelentősan változhatnak
- kézbentarthatóan (= lineárisan) skálázódik az erőforrásigénye (memória, file) a pontok számának növekedésével
- 'elég' hatékony algoritmusok vannak a legrövidebb utak meghatározására, de kis innovációval az eredetiekhez képest mindenképpen szükséges
- a tulajdonséggal rendelkező kapcsolatok adott szituációban való kiértékelése nagyon egyszerű, akár tiltással, akár helyzetenkénti eltérő súlyozással, stb.A buszjárat-feladat (a megállókkal) nagyon ritka gráfnak fogható fel, viszont rendelkezik jó pár további - dinamikus - kapcsolattulajdonsággal (várakozási idő, a célútvonal időintervalluma (reggel-délben-este), átszállás stb.), ezért - főleg nagyszámú pontnál - alkalmasabb a listás megközelítés, mint a mátrixos. Erre nagyon jó kiindulópont az előbbiekben linkelt Dijkstra-algoritmus.
-
#136
cucka
addikt
kicsitomi88
#134
cucka
addikt
válasz
kicsitomi88
#134
üzenetére
gráfot csúcsmátrixban vagy éllistával szokás tárolni, legrövidebb utak kereséséhez meg nézz utána a dijkstra algoritmusnak, amit célszerű az első reprezentációra megírni.
(csúcsmátrixnál a mátrix (x,y) pontjában az x-ből y-ba menő él hosszát tárolod el, éllistánál pedig minden csúcshoz tartozik egy lista, amelyben az adott csúcs szomszédai vannak.)elég rég tanultam ezeket, remélhetőleg jól emlékszem a terminológiára
-
#135
shev7
veterán
kicsitomi88
#134
shev7
veterán
válasz
kicsitomi88
#134
üzenetére
ha jol emlekszem ehhez az algoritmushoz egy egyszeru matrix a legcelszerubb, ami azt tarolja, hogy mennyi a tavolsag (a te esetedben ido a ket pont kozott) de igazad vna, egy csomo mindent figyelmen kivul hagytam... lehet, hogy felepited a grafot, de adott idopontban ott nem is jar busz... tovabb kell gondolni az algoritmust
-
#134
kicsitomi88
őstag
shev7
#133
kicsitomi88
őstag
Valszeg konnyu igen, viszont ezt igy eloszor csinalom.
Olyan adatszerkezetet irsz amiben konnyeden tudok tarolni grafokat, ilyen adatszerkezetrol leirast hol tudnek megnezni?
Valamint szamomra nem feltetlen kell legrovidebb ut, nekem csak egy ut kell
Ezt azert irom mert szamomra nem csak utat kell keresni, hanem megnezni, hogy az a bizonyos ut megfelel e egyeb kivanalmaknak(idopont stb), bar gondolom ezt az algon belul egy felteteles szerkezettel valo fuggo tetestol megoldom majd.Na szoval mi is az a grafos adatszerkezet?
-
#133
shev7
veterán
kicsitomi88
#132
shev7
veterán
válasz
kicsitomi88
#132
üzenetére
szerintem vegyel elo egy algoritmuselmelet konyvet
fogsz talalni olyan adatszerkezetet, amiben konnyen tarolhatsz grafokat, es amin gyorsan el tudod vegezni a legrövidebb ut kereseset. Azt a pseudo kodot akarmilyen kodda atirni nem nagy melo, gyorsabbat ugysem talalsz, es nem kell feltalalnod a spanyolviaszt Sot nem is kell algel konyv itt szepen le van irva a Dijkstra algoritmus.
-
#132
kicsitomi88
őstag
kicsitomi88
őstag
Sziasztok
Úgy volt, hogy az általam nyitott C programozas topikban teszem fel ezt az off kerdest, de valahogy itt kisse szakertobbnek lattam a tarsasagot akik nap mint nap itt voltak.
Nos van egy JAVA projektem egyetemen, nem nagy kunszt ahhoz kepest, hogy elso OO programkent irjuk, de egy resz megoldasaban nem vagyok biztos.
Van egy adatszerkezet melyben buszjaratok jellemzoit tarolom, ugy mint: jaratszam, elsojaratideje, utolsojaratideje, kovetesi ido, megallok es a hozza tartozo plusz percek indulastol szamitva hogy mikor er eppen oda.
Egy fajlbol szepen beolvastam a buszjaratok adatait, inputkent konzolrol fogadom a honnan hova mikor harmast, majd egy lehetseges utvonalat kell talalnom a honnan hova kozt idopontokkal, megallokkal es jaratszamokkal jelolve. A buszok korjaratok tehat visszafele is mennek, de ez mar nem is lenyeg.
Nos a kerdesem annyi lenne, hogy ennek a megvalositisara a visszalepeses kereses algoritmus jo otlet lenne-e? Vagy buveszkedjek magam ki egyet vagy teljesen rosszul gondolom?
A valaszt elore is koszonom ;)
-
doc
nagyúr
válasz
S.P.Q.R.
#130
üzenetére
a project fejlődése illetve "elkészülése" nem (csak) a PM-től függ
a mi játékunk is elkészült, igaz, szerintem még kellett volna bele egy-két apróság, de mindegy
viszont hiába készült el, és tette a dolgát remekül a zenész, a grafikusok, meg talán én is mint programozó, ha a játék kvázi eladhatatlan, mert nincs is piacra dobva. reklám kell, sok helyre bepróbálkozni, csinálni vele valamit. azzal hogy a vinyón üldögél, nehezen lesz bevétel...magába a fejlesztésbe szerintem ne szóljon bele nagyon egy PM, mondja el az elképzeléseit, sőt, a program/designtervet is csinálja meg, hogy tudjuk merre haladunk, figyelje azt hogy hogyan halad a project, hogy ne legyenek felesleges körök, pluszban elvégzett melók (nálunk sajna volt bőven), koordinálja a munkát, de ne ő mondja meg hogy hogyan írjam a kódot
-
S.P.Q.R.
csendes tag
Nah akkor megfordítom a kérdést(most figyeljetek
) Ha egy projekt manager nem a legalkalmasabb személy, akkor a projekt eleve veszve van?
A saját tapasztalatom az, hogy az egyik főnököm belenézett a kódba de az istennek sem akart kiszabadulni a visual basic-acces világból és csak abban volt hajlandó gondolkozni. De legalább(sajna) leült a kódhoz, bár php és java volt és mondott ezt-azt...A másik meg olyan volt, aki csak dirigált meg a szerződést lengette, hogy határidő meg stb...irreális dolgokat akart csináltatni, fontosabb volt számára a személyes ambíció stb, de nem pofázott bele mit hogyan valósítsunk meg...de a projekt mindkét esetben haladt, és nem tudom eldönteni, hogy melyik segített és melyik hátráltatott inkább...
A másik kérdés, ha nem feltétlen kell jó programozónak, és nem is feltétlen jó managernek vagy vezetőnek lennie a projekt managernek, akkor mi alapján lehet szerintetek eldönteni ki alkalmas rá és ki nem?
üdv:
S.P. -
doc
nagyúr
válasz
S.P.Q.R.
#127
üzenetére
nem kell hogy jó programozó legyen, elég ha van némi fogalma a dologról, arról hogy milyen megoldás mennyire reális/időigényes, inkább legyen jó "menedzser"
sajna a saját tapasztalatomból beszélek, egy ideje foglalkozom játékfejlesztéssel, és a tavaly áprilisban (!!) befejezett játékunk még mindig alig van kint a neten, a mostani meg már vagy egy hónapja nem haladt semmit, szóval katasztrófa...
pedig némi agilitással, meg "menedzserséggel" bőven meg lehetne ezeket a problémákat oldani, de a mi projectvezetőnk... -
shev7
veterán
válasz
S.P.Q.R.
#127
üzenetére
egyszer dolgoztam egy projecten, ahol szinte akadalymentesen mentek a dolgok. Szerintem a titka abban rejlett, hogy volt egy olyan kontakt szemely, aki a megrendelo kereseit ertelmesen le tudta forditani a programozoknak, minimalisra csokkentette a felreertesek lehetoseget, es rendelkezett akkora ralatassal a fejlesztoi oldalra, hogy a tul ertelmetlen kereseket mar elso korben elbuktatta. De emelett szukseg volt egy olyan project vezetore (nem neveznem managernek), aki tisztaban volt az egyes reszfeladatokkal, es a csapatban dolgozo emberek kepessegeivel.
-
S.P.Q.R.
csendes tag
Ki mit gondol, hogyan kell megközelíteniaz egység sugarú loosert...akarom mondani usert
Szal mi legyen az elsődleges szempont a user friendly felületen/arculaton. Ha a user olya tkér ami szakmailag nem indokolt, de pl ő a felhasználói képviselő, ti lebeszélnétek, vagy ráhagynátok ha ti lennétek ppéldául a projekt manager?
Következő kérdés, a projekt manager jó programozó legyen elsősorban hogy átlássa általánosságban(jó tudom ez így nem egészen lehet) a dolgot, vagy jó vezető ne adjisten jó menedzser? Vagy inkább ezek valamilyen arányú kombinációja?
Kinek mi erről a véleménye?
jó fórumozást:
S.P.stb.... -
S.P.Q.R.
csendes tag
Eléggé fel lesz paraméterezve, és úgy látom inkább hagyom a Visual studio-vs xml témát, ebböl is látszik hogy nem C#-ozom
Amúgy én a legutóbbi projektemben hosszú szövegek(nem olyan óriásikat azért;) változó fix), illetve cimkék tárolására használtam néha pedig sql scripteket tettem bele. A nagy adatoknak én is sql alapu db-t használtam, pl egy szótáron dolgoztam aminek a felületen megjelnő cimkéket xml-ből szedtem mig a szavakat és azok tulait MSSQL-ből.
Amúgy még mindig nem készültek el a SOAP-os kollegák, szal nem tudom beilleszteni, pedig már három órája várok rájuk -
Vico87
tag
válasz
S.P.Q.R.
#123
üzenetére
Ha adhatok egy tanácsot, akkor írd teljesen általánosra, a lényeg, hogy bármit képes legyen átküldeni és fogadni (nagyon széleskörûen paraméterezhetõ legyen), mert amikor legközelebb írsz SOAP-os cuccot, akkor jól jön. (Ha meg nem így csináltad, akkor nem lesz kedved egy nagyon hasonlót írni.)
@Lortech : én a lokalizáció kapcsán beszéltem XML-rõl (de újra elolvasva amit írtam tényleg nem egyértelmû, hogy arra gondoltam).
-
Lortech
addikt
válasz
S.P.Q.R.
#123
üzenetére
A gui leírásához (modell + viselkedés) nincs köze a visual studios xml-nek. Konkrétumot nem sokat írtatok, de ha nem ismerem a témát, úgy tűnt volna, hogy erre használatos (mint pl WPF + XAML-nél), közben meg nem. Erőforrások tárolására: lokalizáció, képek, szövegek, hangok stb. Akár egy konzolos alkalmazásnál is.
Én legutóbb az aláírásomból elérhető programhoz használtam xml-t, a prohardveres privát üzeneteket mentettem xml-be. Ilyen feladatokra pl. tökéletes és feleslegesnek tartottam egy mini adatbáziskezelőt hozzácsapni a programhoz.
Még objektumok sorosításához, webszolgáltatásokhoz használom remoting kapcsán a szakdogámban. -
S.P.Q.R.
csendes tag
Lehet almát körtével hasonlitunk, de mindkettő gömbölyű és finom, szal azért vannak hasonlóságok
A Visual studio Desiner kontra xml ezek szerint nagyjából jól sejtettem, bár most újdonságokat is megtudtam, és jó pap holtig tanulAmúgy mint irtam is, másféle dolgokra használom én is, de vannak határesetek amikor ez-is az is használható. Amúgy jó hogy a SOAP szóba jött most PHP5 alól épp SOAP-ozós progit fejelsztek ami majd valamilyen diagrammokhoz hiv meg függvényeket, vagy szolgáltat adatokat. Sajna kedves team-em késik ezzel szal határidő gondjaim lesznek, ha ők késnek én is kések
nah midnenkinek jó forumozás továbbra is:
S.P.Q.R. -
doc
nagyúr
nyilván teljesen másra való az XML és az SQL (pl.)
perpill. pl. egy flash menüt fejlesztek, ami 3D-s modelleket használ, ezek Collada objektumok (xml-ben tárolja a teljes modellt), a beállítások szintén xml-ben vannak, erre tökéletes, felesleges is lenne valami adatbázist mögé tenni (sőt, egy 3D objektumot elég érdekes lenne mondjuk SQL táblaként megoldani...)de mikor a php-val kezdtem foglalkozni, próbaképp csináltam egy több opció szerint kereshető/szűrhető listát a dvd-imről, ott nyilván sql-t használtam, eszembe sem jutott az XML
szóval almát körtével hasonlítunk, szerintem
-
Vico87
tag
válasz
S.P.Q.R.
#120
üzenetére
Bocsi, ha túl "magyarázó" voltam.
Én úgy tudom, hogy a Visual Studio (WinForms esetben, a WPF más tészta) designer módban rakja el XML-be, de amikor fordítod, és lesz belõle release, akkor egy dll-t csinál a különbözõ lokalizációkhoz. Ez azért van, mert az egyes lokalizációk esetében arra is kell gondolni, hogy egyes szövegeket hosszabban lehet leírni más nyelven, így pl a Button méretét is másra kell tervezni, de ha a Button nagyobb, akkor az vonzza magával, hogy mondjuk a ComboBox viszont kisebb, stb... ezért lesz belõle dll, mert kódot tartalmaz.
Egyébéknt az XML nagyon szép és jó, de egy méret után már nem emberi használatra való, hanem inkább kód kezelje. Mondjuk technológiailag lenyűgözõ, hogy mekkora szerep jutott az évek során az XML-nek (gondolok itt webszolgáltatásokra például, és annak vonzataira mint SOAP, WSDL, stb...).
-
S.P.Q.R.
csendes tag
Nah akkor válaszolok
Tökéletesen tisztában vagyok hogy más szintű és máshogy táolódnak az RDBMS rendszerekbe az adatok, mint a fastruktúrában tároló xpath-al könnyen kezelhető XML_ben.
Máshol és máshogyan alkalmazzák, hidd el én is irtam olyan progit eleget ami mindekettőből dolgozik, vagy épp XML-ből visz ád SQL alapú DB-be adatot, tehát ilyen konvertáló progi szerűt stb...
Csak azért írtam le így mindenféle kategorizálás nélkül egymás után őket, mert csak pl-nek hoztam fel őket beszédtémának. Szal hidd el tudatában vagyok miket írok
Amúgy azzal vitatkoznék kicsit, hogy másra alkalmasak,KIS méretű adathlamz esetén egy xml file xpath-al elég jól kezelhető, nagy méretben természetesen nem de igazából arra lennék kiváncsi, hogy ki hol és milyen mértékben használ pl XML-t bizonyos adatok tárolására. Pl tételezzük fel hogy van egy rendszer mondjuk egy portál/vagy éppen valami ablakos alkalmazás, ami többnyelvű kellen hogy legyen, ugye az kézenfekvő hogy a gombok menük szövege valahol tárolódik. Több féle megoldás is van ezekre. Például ha jól tudom,(ha nem mea culpa nem vagyok c# fejlesztő
) a visual studionak is van kül desiner felülete a GUi készítését elősegítendő. S ha jól tudom az ilyen jellegű adatokat XML-ben tárolja. Ez csak egy példa volt, az ilyen jellegű példák sokaságát várnám.
mindenkinek jó fórumozást:
S.P.Q.R. -
Vico87
tag
válasz
S.P.Q.R.
#115
üzenetére
Akkor én írok neked a DB-kről
.Szvsz másra alkalmasak az SQL és az XML alapon tárolt adatok. Az SQL esetén ugyebár van egy DBMS mögötte, amely igen sok verziót megért már (pl Oracle-nek 10, 11 még fejlesztés alatt, MSSQL 2008, ha jól tudom a 10-dik kiadás, pedig manapság jelenik vagy jelent meg) sok-sok funkcióval és optimalizálással. Mindez nincs XML esetén, hanem neked kell megírni a kezelést végzõ funkciókat (nyilván olyan API-k mint a Java vagy .net rengeteg objektumot a rendelkezésedre bocsát erre a célra).
Ezek a különbségek fõleg onnan erednek, hogy az SQL esetén relációs adatbázisból dolgozol (amely kezelésére vannak az elõbb említett DBMS-ek), míg XML esetén amolyan "adatkupac" jelleget ölt a dolog.
A relációs adatbázisok igen hatékonyak például üzleti adatok tárolására, amire az XML igencsak alkalmatlan. Ellenben egy fastruktúrát leírni egyszerűbb XML-ben. XML-ben nem lehet könnyen nagy mennyiségű adatot tárolni (itt igen sok adatra gondolok, de nem kell messzire menni, gondoljunk pl 10GB-nyi adatra, ami meg sem kottyan egy DBMS-nek, viszont ennyi adat kezelésére XML-alapú progit írni vérpisilõs mutatvány). Relációs adatbázisban minden mezõnek típusa van, míg XML-ben minden plain text, így kicsit könnyebb az adat ellenõrzése DBMS esetén (integritásellenõrzést alapszinten tud csak elvégezni, hiszen a DBMS "nem gondolkodik", de ez már sokkal több mint ami rendelkezésre áll XML-ben).
XML-ben van pl XSLT, amivel teljesen átírható az adat formátuma (nem a tartalom!), de ehhez hasonlót DBMS esetén sem nehéz megvalósítani.Mindezzel oda akartam kilyukadni, hogy más világ a kettõ. Nekem C#-ban volt szerencsém programot írni, ami egy MSSQL adatbázisból dolgozik, és azt kell mondanom, hogy kifejezetten tetszett a DataSet-es megközelítése az adatok leképezésének (lényegében minden táblához tartozik egy-egy osztály, amelyek egy "gyűjtõ" osztályban (class DataSet-bõl származó) vannak).
-
S.P.Q.R.
csendes tag
Nah úgy néz ki leült picit a téma javaslom kezdjük el az adatbázis alapú programokról szóló eszmefuttatást. A kérdéseket már feltettem feljebb..De megismételm.
-Ki mit gondol az SQL alapu db-kről?
-Mennyire kell elválasztani a kódot és a db-t egymástól? hallottam olyan véleméyneket, hogy lehetőleg legyenek függetlenek.
-Mit gondoltok kül OO-s db megoldásról pl olyamiről mint ami a Lotus alatt ketyeg?
-Újabb szabványok, pl XML(személyes kedvenc sokmindenre jó általános, jól kezelhető SGML származék) kezelésről, és adattárolásról kinek mi a véleméye?
-Ezeket ki milyen nyelven kezelné legszivesebben, személy szerint Java, PHP, C#-ban mind találtam rá nagyon jó kis megoldásokat
Nah lehet elmélekedni ezzel kapcsolatban
üdv: S.P.Q.R. -
doc
nagyúr
te beszélsz feltűnési viszketegségről meg "agyfosásról" ?
amúgy a felhozott példád remek, pontosan ez az a terület, ahol az OO sokkal kényelmesebben használható.
[i]
plus (a,b) : int;
a,b int;
plus:=a+b;plus (a,b) : real;
a,b : real
plus:=a+b;
[/i]itt most ugyanazt leírtad kétszer, azzal a különbséggel hogy az int-et kicserélted real-re... pont ezt (és még sok más "robotmunkát") segít elkerülni az OO szemlélet
pl. tegyük fel hogy az int és real nem alaptípusok, hanem annál bonyolultabb szerkezetek. ilyenkor ha szeretnél mondjuk még egy típust, nem kell szorgos hangya módjára copy-paste-elni, majd az int-eket más típusra cserélni, hanem egész egyszerűen származtatod az új, kibővített osztályt a régiből, és automatikusan jól működik minden. akkor kell a szóban forgó függvényt újra megírni, ha mást csinál, ha ugyanazt, akkor nem kell ötmilliószor lemásolni, erre való a virtuális metódus
egyébként már példát is hoztam a polimorfizmusra, tessék kicsit scrollozni, olyan sokat nem postoltam még ebbe a topicba...
-
Kkocos
tag
plus (a,b) : int;
a,b int;
plus:=a+b;plus (a,b) : real;
a,b : real
plus:=a+b;class complex
r,i: real;
end class;complex.plus (a,b: complex) : complex ;
begin
plus.r:=a.r+b.r;
plus.i:=a.i+b.i;
end;most ez nem polimorfizmus ha aszondom hogy c:=plus(a,b)\ c lehet barmi a fentiekbol?
Tul sokk az agy, a feltunosegi viszketegseg, senki se szol konkretumokrol, mindenki mindent tudd, csak epp maganak tartja, nem monda me' fel hogy beeg! Persze a kritikak omlenek, csak epp mire. Ha nem tetszik ne szolj hozza, ha hozaszolsz es epp kritikusan, ilenne megoldast is adni , igy csak agyfosasnak tunik
-
#110
Kkocos
tag
loszerafin
#107
Kkocos
tag
válasz
loszerafin
#107
üzenetére
Miert ne?
Ha aszondom hogy a plusz b
a lehet int,real,complex, mitomen
b csakugy
Ez polimorfizmus, nem?
Miert ne lehetne? -
dabadab
titán
[ Elkavartam valahova a sajtreszelot
]"Mit szolsz ehez
Tesszeb Button egy objektum
aszondom hogy :
new Button(x,y); \ahol x,y a pozicio. Mi a szentseget is csinaltam?????
Meghivtam az objektum construktorat. Nem? Vagyis?"Eloszor is azt, hogy soha nem keso megtanulni irni.
Masodszor meg azt, hogy a konstruktort hivtad meg, nem az objektumot. Objektumot nem lehet meghivni, csak az egyes metodusait (igen, a konstruktor az egy specialis metodus).
-
#107
loszerafin
senior tag
loszerafin
senior tag
Olvasgatom itt a flame-et az "OOP miért jó?" témáról. Lehet, hogy elsiklottam fölötte, de a lényeg talán nem világos:
Az OOP-t az "élet" kényszerítette ki. A sok befejezetlen, rossz IT project, a betartatlan határidők, túllépett keretek, a programozás minőségének ellenőrizhetetlensége. (stb)
A szakirodalom szerint főleg 5 dolog miatt kell OOP:
1 kód újrafelhasználhatóság
2 megbízhatóság
3 hajlékonyság
4 kiterjeszthetőség
5 karbantarthatóságSzerintem még van 1 fontos dolog: 6. kiforrott technológia segít OOP programokat írni.
Hogy éri el a célját az OOP programozó?
Kicsi, átlátható, tesztelhető apró darabokra vágja a problémát. A darabok egy kicsi részproblémát oldanak meg, da azt NAGYON JÓL. Gyorsan, hatékonyan, ellenőrzötten, tesztelten jól működik a kicsi program. A kicsi probléma jól körülhatárolt, világosan specifikált, a megoldása tömör, jól dokumentált, az API-k kiforrottak, könnyen kezelhetőek.Ezért ezek a kis részproblémákat megoldó programok könnyen felhasználhatók más programozók által, más projektben is, nem csak ott, ahol készültek.
A kis részproblémákat megoldó programokat összekapcsolják egymással, és így oldják meg az eredeti problémát. Az összekapcsolás kizárólag a dokumentált API-n keresztül történik, azaz NEM növelik a kis részek között a függést, a részek NEM látnak bele egymásba, nem módosítják egymást.
Tehát a részek belseje (a kódsorok) nyugodtan cserélhetők, feljleszthetők, javíthatók, ha az API nem változik, nem borul a teljes program.
Mivel a világban a problémák változnak, a programnak is változnia kell. Ehhez általában elég a kis részeket más sorrendben, más logikával "összeragasztani" -> gyorsan követhetik a programozók a világot.
A 6. pont is nagyon fontos:
OOP programnyelvekhez van pl. kód dokumentálás, UML, design patternek, unit tesztelés.
Ezek nélkül is lehet programozni, csak nem érdemes. Ha vmit megcsinálhatunk jól, akkor nem érdemes rosszul megcsinálni.Mit nem lehet struktuális programozással megvalósítani?
Hát pl. a polimorfizmust.
-
Kkocos
tag
???? "Felhozod a megdonthetetlennek hitt erveidet, de mivel nincs mogotte tudas, igy gyakorlatilag nincs ertelme annak amit mondasz..."?????
Furcsa
"Fogalmi zavarba kerultel... objektumot nem hivunk..."
Mit szolsz ehez
Tesszeb Button egy objektum
aszondom hogy :
new Button(x,y); \ahol x,y a pozicio. Mi a szentseget is csinaltam?????Meghivtam az objektum construktorat. Nem? Vagyis?
-
shev7
veterán
a helyzet az, hogy eddig senki sem mondta, hogy az OOP az isten minden mas szar, es mindehol az oopt kell hasznalni. Szemben veled aki lathatoan tudas nelkul mondasz velemenyt valami olyanrol amirol fogalmad sincs. Felhozod a megdonthetetlennek hitt erveidet, de mivel nincs mogotte tudas, igy gyakorlatilag nincs ertelme annak amit mondasz...
-
Kkocos
tag
Igen, lehet, koveted a secventialis elvet. Mint OOP, vannak objektumaid, deh az objektumok maguktol nem tudjak mien munkafazisban is vagy, ha csak nem bemenetkent megmondod nekik, es megfelo fazisban hajtjak vegyre a parancsokat, a tobbire meg "basznak" ra. Az uj amit ez hoz, hogy hiaba vannak meg a vegrehajtashoz az ossze kondicioja az objektumnak, nem dolgozza fel. en forditva gondolkodnek. csak akkor hivd meg az objektumot ha abba a fazisba kerultel. Nincs felesleges elenorzes
. egy darabot találtam msdnan, azt nem tartottam túlzottam mérvadónak. olyan weboldalhoz kéne amin sok (nagyon sok) adatbázisban tárolt adat van (felhasználói profilok sok adattal, események, fórumok stb). 
)
, azert irtam ide, hatha vlki a matlabban tud segiteni, francnak van kedve uj progit megtanulnia 
) Nemtom googlen azért csak akad hozzá anyag..
(Post probléma valamikor a 30-as években jöttek rá)
]
Aktív témák
Hirdetés
- QNAP TS-870U-RP 8 lemezes Rack NAS
- BESZÁMÍTÁS! MSI B450M R 5 5600X 32GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Corsair 650W
- Utolsó 3db - KIÁRUSÍTÁS - REFURBISHED és ÚJ - HP Thunderbolt Dock G2 230W docking station (3TR87AA)
- Apple iPhone 11 / 128GB / Kártyafüggetlen
- IKEA (HAVREHOJ) tablet vagy laptop tartó
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest