Aktív témák

• #180 bdav őstag Protezis #179

  2008-04-06 12:03:47 #180

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bdav

  őstag

  válasz Protezis #179 üzenetére

  na akkor ma is tanultam valami újat

  (ha esetleg duplázódott volna akkor sry, de nem láttam h. az előző bekerült volna)

• #178 bdav őstag Protezis #177

  2008-04-06 00:39:45 #178

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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ól

  mvc 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

• #176 bdav őstag Protezis #175

  2008-04-05 23:38:58 #176

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #174 sghc_toma senior tag Protezis #172

  2008-04-05 17:01:30 #174

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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..

• #173 bdav őstag Protezis #172

  2008-04-05 16:47:07 #173

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

• #171 bdav őstag Protezis #170

  2008-04-05 13:04:31 #171

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bdav

  őstag

  válasz Protezis #170 üzenetére

  nem is mondtam hogy ne tanítsák

• #169 bdav őstag Protezis #166

  2008-04-04 23:28:32 #169

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #167 dabadab titán Protezis #166

  2008-04-04 02:53:58 #167

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #164 bdav őstag Protezis #163

  2008-04-03 21:43:53 #164

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #162 P.H. senior tag Protezis #160

  2008-04-03 21:07:52 #162

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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).

• #161 doc nagyúr Protezis #160

  2008-04-03 20:29:13 #161

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

• #159 doc nagyúr Protezis #158

  2008-04-03 20:07:01 #159

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

• #156 doc nagyúr Protezis #155

  2008-04-03 18:10:19 #156

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  doc

  nagyúr

  válasz Protezis #155 üzenetére

  na akkor én kb. a másodiknál járhatok, mert nem jöttem még rá hogy miért is olyan hasznos a singleton (tudom mire val, de hogy miért jobb, mint simán használni egy class-t, az még nem esett le)
  a könyvet nemrég kezdtem, remélem azért sikerül nagyjából "magamévá tenni"

Aktív témák