Karrier

[Greene 10]

Abból ne általánosítsunk már, hogy egy ismeretlen kernelű, ismereten (talán alap) beállításokkal/jogosultságokkal rendelkező Linuxos szervert mennyi idő alatt törtek fel.

Aki Linuxozik az nem rak be szervert alapbeállításokkal. Nekünk több száz Linuxot futtató szerverünk van, egyiket se törték még meg. Erről ennyit.

Az oldalak 99%-a meg nem banki fizetési oldal, és nagy ívben tojnak a fejlesztők a RIA-ra.

A Windows nagy előnye a szerverpiacon szerintem az Active Directory.

Szóval amit írtál Destroy-Man az egy nagy marketing-semmi. Biztos sokan elhiszik, de nálam kiverte a biztosítékot.

[arpsoft 12]

Meg az IIS7, ami nagyon jóra sikeredett!

[[OP]Destroy-man 160]

Én az IIS7.5-öt használom, de semmi probléma nincs vele. Tökéletesen futtatja az ASP.NET-et, MVC-t és a PHP-s oldalakat. Az apache az elõbbi kettõvel nem birkózik meg. Ha a fejlesztési idõt nézzük egy átlag weboldalnál, akkor töredék idõ alatt lehet végezni MVC alatt ugyan azzal a feladattal, mint PHP-n.

[Greene 10]

Tehát akkor karrier témában várjuk a hozzászólásokat a továbbiakban, akár arról is, hogy milyen ASP tanfolyamokat érdemes elvégezni.

[payskin 918]

MVC alatt a Model - View - Controllert értjük? Mert PHP-hoz van úgy 2 tucat különböző bonyolultságú framework, mind MVC alapú. Az például jó karriertanács, hogy a népszerűbbek közül 1-2-t érdemes ismerni (Zend, Kohana. CodeIgniter, Yii, Symphony például).

[[OP]Destroy-man 160]

Igen, azt értjük alatta. Bár az elnevezéssel én nem értek egyet, mert a helyes sorrend az MCV, vagyis Model -> Controller -> View. Legalábbis ASP.NET MVC alatt így kell fejleszteni.

[Vagadero 0]

Ugyan nem mai a topik de:

http://forums.debian.net/viewtopic.php?f=2...pi+cert#p124302

 

Remélem másnak is hasznos lesz.

 

S mi a helyzet a bankokra, azon belül pl. ATM automatákra specializálódással? Tegnap jutott eszembe a kérdés. Hiszen ATM van rengeteg akkor munkának is (kellene) lennie.

Edited April 19, 2012 by Vagadero

[arpsoft 12]

Ott szerintem elég kemény biztonsági követelményeknek kell megfelelned már ahhoz is, hogy szóba álljanak veled.

[KGigi 21]

Álljon meg a menet. A MVC miért lenne szerverfüggõ? Az csak egy elég egyszerû szoftverarchitektúra. Az ASP meg nyilván nem megy Linux alapú szervereken, hiszen nincs normális .NET, így nem túl fair az összehasonlítás.

 

Személyes megjegyzés. Bottal sem piszkálom meg az ASP-t. Iszonyatosan nehézkes a fejlesztés a PHP-hoz képest, ráadásul ugyebár nem crossplatform. PHP-ban sokkal könnyebb szövegekkel is dolgozni, mert gyengén típusos. Ez pedig webes alkalmazások esetén az egyik leggyakoribb feladat. Ha használsz valamilyen PHP keretrendszert, képességekben is simán hozza azt, amit a .NET. Webes alkalmazásokhoz nem kell sok dolog. PHP keretrendszerekbõl egyébként most a Zend az, ami nagyon megy. Én még CodeIgnitert tanultam, az sem rossz, de a Zend sokkal jobb.

 

Személyes megjegyzés 2. Bottal sem piszkálok meg weboldalt, két dolog miatt. 1) Tömegével képeznek "webprogramozókat", akik normális programozási tudás nélkül gányolnak alkalmazásokat, rosszabb esetben példakódokat összeollózva. Ez különösen jellemzõ a Flash-re. Ennek hála iszonyúan nehéz jó munkát találni, ahol egyrészt megfizetik a valódi programozói tudást, másrészt nem vagy körülvéve olyanokkal, akik nem értenek ahhoz, amit csinálnak. 2) Ha sikerül is jó állást találni, az egész hatalmas szívás. Az elmúlt években nagyon sokat javult a helyzet (IE 10, JQuery), de még mindig sokszor annyit kell dolgozni, mint kellene, rengeteg az idõrabló pepecselés agyvérzéssel megtoldva. Ennek az az oka, hogy platform nem egységes, nem is igazán beszélhetünk platformról. A szerveroldal PHP, C# stb., a kliensoldal pedig (X)HTML és JavaScript keveréke. Ezek közül a kliensoldallal van gond, több okból is. a) A böngészõk, elsõsorban az IE képtelen úgy megjeleníteni a szabványnak megfelelõ weboldalakat, ahogyan azt kellene, ráadásul a JavaScriptet is hajlamosak másképpen értelmezni. b) A JavaScript egy hulladék, pokol benne programozni, rég eljárt felette az idõ. c) Nincs egyetlen elterjedt megoldás, vannak HTML 4, HTML 5 és XHTML alapú oldalak, illetve ezek összegányolt keverékei. Ráadásul a HTML 5 még nem is végleges, és belátható idõn belül nem is lesz az. d) Erre jön még rá a Flash és a Silverlight. Szóval a hátam közepére nem kívánom az egészet.

[payskin 918]

A javascriptes megjegyzésedet azért nem értem, mert egyrészt folyamatosan fejlesztik (ECMA megvan, nem? Jóval előrébb járnak annál, ami ma implementálva van a böngészőkben), másrészt jól látszik, hogy az egész HTML5 történet erre épül. Sok vita tárgyát képezi, ez igaz, ugyanakkor remek eszközöket írnak benne, ami nagyságrenddel könnyíti meg a cross-platform fejlesztést, akár HTML5-ben is!

 

Apropó HTML5, a másik, amit nem értek ez a görcsös ragaszkodás ahhoz, hogy a HTML5 még nem végleges. Azt hiszem, már próbáltam elmondani, hogy ez a fél világot nem akadályozza meg abban, hogy HTML5-ös oldalakat csináljon. Az alapok évek óta kőbe vannak vésve, 2010-ben HTML5 alapúra csináltam a JátékNetet, és épp most építek hozzá egy új "szárnyat", amiben már bátran használom az új tageket is, meg a CSS3 néhány egyszerűbb dolgát.

 

Az IE-vel szembeni ellenállásod is kezd egy kicsit kifújni: az IE9-en azért már elég nehéz fogást találni, az IE10-ről pedig az a hír járja, hogy átveszi a stafétát a Chrome/Firefox/Opera duótól, és úttörő lesz a szabványok támogatásában. Igaz, hogy még mindig sokan használnak 6/7/8-at, de a mint tudjuk...

 

http://dowebsitesneedtolookexactlythesameineverybrowser.com/

 

Akik nem jönnek a technológiával, így jártak. Mostanában a legnépszerűbb analógia a fekete-fehér és a színes tévék példája. Akinek fekete-fehér tévéje volt, nem tudott átjutni a folyón az Aztec Challenge-ben, megették a piranhák. azt hiszem ennyi.

[Pjotr 9]

A PHP-t ne hasonlítsuk össze az ASP.NET-tel (Web Forms / MVC), mert nagyon nem ugyanaz. PHP-val kapcsolatban mindig olyan érzés fog el, hogy egy tákolmány sz.r, mert régrõl jön, scriptnyelv, tele van régi dolgokkal és egyszerûen csúnya, míg a .NET teljesen OO és alkalmazásírásra termedt. Amíg nem kell bonyolult dolgokat létrehoznod (a.k.a alap CRUD mûveleteket végez majdnem csak az alkalmazásod), akkor a Web Forms-szal van a legkönnyebb dolgod, de mûködésileg ugye nem túl gyors. Amint bonyolultabb UI jön szóba például, mindjárt képbe kerül az ASP.NET MVC, ami viszont már nagyon penge (iszonyat rugalmas), a PHP pedig mindezek mellett ott van folyamatosan valamilyen formában. Nézegettem PHP MVC kereteket, de mindegyik ocsmánynak hat, egyszerûen nem használnám szívesen, ezért is írtam/írok magamnak egy egyszerûbbet, ami egyébként hajaz az ASP.NET MVC rendszerére mûködésileg/programozásilag.

Azt sem szabad elfelejteni, hogy ugyan az ASP.NET csak Windows-on megy, de ott teljes feature list-tel, nincs PECL, nincs kiegészítés, semmi. Ami benne van a .NET-ben (az a rengeteg elem, csak egy példának: robosztus cache), azt eléred.

 

Weben nem beszélünk Flash-rõl és Silverlight-ról.

 

Javascript pedig mindenütt ott van, minden platformon mûködik, és nem csak webed környezetben. Ha épp tanulna valami újat, akkor szívja magába keményen a Javascript-et, az mindig kelleni fog.

[KGigi 21]

@Balázs

Értem én, hogy folyamatosan fejlesztik a JavaScriptet, de már több mint tíz nyelvet tanultam alaposabban, és egyetlen eggyel sem szívtam annyira, mint a JavaScripttel. A JQuery nagyon jó, viszont a kód nehezen olvasható. Nekem megtanulni is nehéz volt, nagyon nem állt kézre. Arról nem is beszélve, hogy nehogy már egy nyelv csak azután legyen használható arra, amire kitalálták, hogy a felismerhetetlenségig átírták egy könyvtárral.

 

Azért baj, hogy a HTML 5 nem végleges, mert ha kihasználsz valami újat, amin késõbb változtatnak, akkor csinálhatod újra. De ez a legkisebb gond az összes közül, és az elõnyök bõven felülmúlják az esetleges ebbõl származó hátrányt, szóval alapvetõen nincs bajom vele, csak írtam, hogy ez is egy bizonytalansági tényezõ a fejlesztés során. Kicsinek kicsi, de létezik.

 

Az IE-t azért írtam, mert függetlenül attól, hogy a 9-10 egészen használható és szabványkövetõ, ettõl még a régi verziók jelen vannak, és még sokáig jelen is lesznek, különösen céges környezetben. Ráadásul a 10-est nem lehet XP-re telepíteni, ha az emlékeim nem csalnak.

 

@Pjotr

Ég és föld a kettõ, viszont mivel a felhasználási terület legalábbis hasonló, szerintem elkerülhetetlen az összehasonlítás. A PHP idõközben felnõtt, nekem semmi problémám nincsen vele. Ugyanaz a hátránya, ami a C++-nak is, vagyis hogy nem objektumorientált, hanem egy meglévõ nyelv objektumorientált kiterjesztése. Ha az ember ezzel együtt tud élni, nem gond. Mondom ezt úgy, hogy a C# messze a kedvenc nyelvem.

 

Nem azt mondtam, hogy ezek a keretrendszerek vannak olyan jók, mint a .NET, hanem azt, hogy amilyen környezetben az ASP használva van, nincs igazán nagy elõnye. Az ASP-nél egyébként elsõsorban azzal volt problémám, hogy képtelen voltam rendesen módosítani az oldal tartalmát, túlságosan távol van a HTML-tõl, amire aztán az egész lefordul. Rengeteget szívtam az eseménykezelõkkel is. Végül elegem lett az egészbõl, és a jó öreg PHP-s kõbalta módszerrel írtam meg, vagyis nyitottam egy kód részt a weboldalban, és kiírásokkal közvetlenül HTML-t gyártottam. Ritka gány megoldás, ráadásul elvesztem az összes elõnyt, amit a .NET adna.

 

Természetesen van olyan felhasználása az ASP-nek, amiben sokkal jobb. Különben rég kihalt volna

 

Weben nem beszélünk Flash-rõl és Silverlight-ról.

Ezt nem értem. Amíg az oldalak tele vannak a beépülõkkel, egyes oldalak pedig kizárólag ezekben vannak megírva, muszáj. Hogy ez milyen minõségû megoldás, az teljesen más kérdés.

 

Nem lebeszélni akarom. De úgy gondolom, hogy ezeket jobb, ha elõre tudja, és nem közben tapasztalja meg.

[payskin 918]

Ésszel történő PHP-áztatás témában ez a legfrissebb, egyben a legkiterjedtebb történet, látszik, hogy a fickó nem a levegőbe beszél.

 

http://me.veekun.com/blog/2012/04/09/php-a...-of-bad-design/

 

Kemény egy órás olvasmány. Állítólag a core-fejlesztők részéről pozitív visszajelzés volt, de valószínűleg sosem fognak rajta változtatni, ez már ilyen marad. Érdemes elolvasni a kommenteket is.

 

Viszont ennek olvastán én is elkezdtem gondolkodni a C# megtanulásán. Főleg az OOP-t szeretném valahonnan jól megtanulni, mert az alapokon túl annyira nincs közöm hozzá, hogy szégyellem bevallani. Négy napja írom ezt a trágya modult a bolthoz, próbálok classokban gondolkodni, de annyira fogalmam nincs, hogy néha fáj.

 

A JQuery nagyon jó, viszont a kód nehezen olvasható. Nekem megtanulni is nehéz volt, nagyon nem állt kézre.

Ez azért fura nekem, mert a jQuery arról lett hírhedt/híres, hogy olyanok is tudják használni, akiknek gőze nincs a programozáshoz és a JS-hez, viszont kapiskálják a HTML-t és a CSS-t. Gyakorlatilag a CSS-alapú kiválasztási rendszer és néhány viszonylag egyszerű eseménykezelő, stíluskezelő paranccsal emberek csodákra voltak képesek. Maga a jQ forráskód is tele van olyan okosságokkal, amikből rengeteget lehet tanulni (lásd Paul Irish két zseniális videója), és újabban van egy olyan törekvés is, hogy visszatereljék a népet a jQueryről a natív JS felé:

 

From jQuery to java script: A Reference (Van ennek valahol egy egyoldalas összefoglalója, de azt sajnos most nem találom.)

 

Az végképp nem igaz, hogy a JS ne volna használható önmagában, hiszen a jQ előtt kénytelenek voltunk önmagában használni. Giraffe, például, egyáltalán nem használ jQ-t, natívban tolja az oldalait, én is csak akkor használom, ha lusta vagyok vagy AJAX-ozni kell.

[KGigi 21]

JavaScript órákról leginkább arra emlékszem, hogy vért izzadtam, mire kivertem a kódból, hogy minden böngészőben ugyanazt csinálja. Pedig IE6-ra már akkor sem kellett fejlesztenünk. Az egész kódom tele volt elágazásokkal, amik bizonyos funkciók meglétét vizsgálták, mert egy-egy böngészőben azok nem elérhetőek. Ezt szokták kívülállók if (IE)-ként emlegetni, de ennél lényegesen többről van szó.

 

A JQuery-ből pedig arra emlékszem, hogy nem egészen úgy működött, mint egy normális imperatív nyelv, hanem pontokkal fűztük egymásra az utasításokat, amik ugyanahhoz az objektumhoz tartoztak. Valahogy úgy, ahogyan üzeneteket küldünk Smalltalkban és és Objective C-ben a metódushívások helyett.* Szóval ahelyett, hogy

objektum.elsometodus();
objektum.masodikmetodus();
objektum.harmadikmetodus();

valami olyasmi volt, hogy

objektum.elsometodus().masodikmetodus().harmadikmetodus();

Ez ha jól emlékszem, úgy van megvalósítva, hogy minden eljárás, azaz nincs visszatérési érték. De mégis van, mert valójában minden eljárás egy olyan függvény, ami magával az objektummal tér vissza. Ilyen másutt is van, így lehet pl. C++-ban olyat írni, hogy a = b = c, ugyanis az értékadó operátor objektum referenciát ad vissza. Ez egyébként tényleg tök jó például arra, hogy bizonyos tulajdonságokat beállítsunk egy elemre. Viszont kínszenvedés, ha nincs másféle működés. A rakás anonim függvénytől is agyvérzést kaptam. Egyszerűen rugalmatlan az egész.

 

* Ezeket a nyelveket egyébként azzal reklámozzák, hogy egy óvodás is pár perc alatt megérti a működésüket, úgyhogy lehet valami abban, amit mondasz a JQuery egyszerűségéről.

 

A PHP-s cikket elolvasom, érdekesnek tűnik. Bár valószínűleg azt fogja kifejteni, amit Pjotr is írt, hogy folyamatosan foltozgatva lett. Egyébként a Javának is ez a legnagyobb baja.

 

Gondolkodom OOP könyvön, hogy mi lenne jó.

[[OP]Destroy-man 160]

C#-ból a Reiter féle könyv a legjobb. Ingyen letölthetõ a DevPortálról.

https://devportal.hu/Fajlok/Download.ashx?s...et%5ccsharp.pdf

[Pjotr 9]

Abból a jegyzetbõl, illetve valamelyik nyelvet tanulva senki sem fogja megérteni, begyakorolni az OOP lényegét.

[KGigi 21]

Azt hiszem, ezt ajánlották nekünk bibliának. És a Wikipédián is azt írják, hogy sokan a valaha született legjobb OOP tankönyvnek tartják. Az író egyébként az Eiffel programozási nyelv atyja is.

[payskin 918]

Ez ha jól emlékszem, úgy van megvalósítva, hogy minden eljárás, azaz nincs visszatérési érték. De mégis van, mert valójában minden eljárás egy olyan függvény, ami magával az objektummal tér vissza.

Ez így van, ezt hívják chainingnek.

 

...tök jó például arra, hogy bizonyos tulajdonságokat beállítsunk egy elemre. Viszont kínszenvedés, ha nincs másféle működés. A rakás anonim függvénytől is agyvérzést kaptam. Egyszerűen rugalmatlan az egész.

Nem látom be, miért volna ez rugalmatlan? Szerintem épp ellenkezőleg, ennél rugalmasabb nincs a világon. Csak egyszer kell hivatkoznom az oldalelemekre, amivel foglalkozni szeretnék, és utána felfűzhetem egy láncra, hogy mit szeretnék velük csinálni. Sőt! A dolog annyira rugalmas, hogy visszafelé is lépkedhetek a láncon! Ha, mondjuk, van egy olyan kijelölésem, ami először sok elemből kiválaszt valamilyen módszer szerint egyet, azon elvégez egy műveletet, utána mondhatom azt, hogy köszi, akkor most térjünk vissza az összeshez, és azon végezzünk el egy másikat (.end()). Hajam letettem, amikor ezzel először találkoztam egy pluginban. Apropó, tök egyszerűen használható pluginok = rugalmasság világcsúcsa.

 

A másik, hogy semmi nem tart vissza, hogy minden functionnek (gondolom, eseményvezérlők voltak) nevet adj, de mennyivel rugalmasabb már, hogy nem kell nevet adni nekik, nyugodtan használhatod őket anonimként. Nyilván abban a pillanatban, ahogy egy eseményvezérlőt több helyről is meg kell hívni, máris nevesítve használom, de amíg csak egy sima onclick/onchange történet van, addig az anonim function a barátom.

 

És ne felejtsük el, hogy a jQuery maximálisan cross-browser, úgyhogy még ezt a rugalmatlanságát is megoldja a JS-nek. Egyébként nem tudom, mik lehettek azok a sok if-ek, amikben folyton vizsgálnotok kellett a dolgokat? Az addEventListener? Vagy getElementsByClassName-et használtatok? Mert hirtelen más nem jut eszembe, ami nem cross-browser az elmúlt 5-8 évben.

 

Köszi a könyvajánlókat, megnézegetem őket.

[KGigi 21]

Mi azt tanultuk konvenciónak, és ez általánosan is elfogadott, sok nyelv nem is enged mást, hogy egy függvény bemenő paraméterekből értéket állít elő, "kiszámol valamit", míg az eljárás megváltoztatja a paraméterül kapott objektumokat. Azaz a függvénynek nincs mellékhatása, az eljárást pedig eleve azért hívjuk meg, mert meg szeretnénk változtatni valamit. Objektumok esetén pedig arra számítunk, hogy csak az objektum fog változni, amin a metódust meghívtuk, a paraméterek nem. A JQuery ezzel teljesen szembemegy.

 

Nekem teljesen idegen az, hogy elindulok egy objektummal, azon meghívok egy metódust, majd még egyet, és a második hívás már egy másik objektumra vonatkozik, miközben a hivatkozott objektumok megváltoznak. Közben átadok neki esetleg egy függvényt, majd visszalépek egy másik objektumra. Iszonyatos koncentráció kell ahhoz, hogy követni tudjam, mi történik. És mivel a JavaScript gyengén típusos, még egy nyamvadt figyelmeztetést sem kapok, ha nyilvánvalóan kreténséget írtam. Egyszerűen csak nem fog működni.

 

A rugalmatlant azért írtam, mert azt hittem, mindig az eredeti objektummal tér vissza. Közben leesett, hogy még ráadásul variálja is. Lekérek egy elemet a DOM-ból, és a következő utasítás már arra vonatkozik.

 

Természetesen én is használok láncokat, de az legfeljebb néhány utasítás egyben, és célja van. Pl. megkeresek egy objektumot egy listában, annak meghívom egy metódusát, és mondjuk a visszaadott objektum ToString()-jét. Vagy ugyanannak az objektumnak, jellemzően egy szövegnek halmozom a metódusait:

String[] tomb = input.SubString(0,input.Length-1).Split(",");

Ez teljesen más, mint a fent vázolt működés, ugyanis végig kézben tartom, hogy mi történik. Minden metódus valamilyen típusú objektummal tér vissza, majd a végén az egész belecsatornázódik egy változóba. Vagyis a célom egy valamilyen típusú objektum előállítása, jellemzően információ kinyerése egy valamilyen módon nagyobb bonyolultságú objektumból. Közben egyik objektumot sem változtatom meg, hanem újat állítok elő. Természetesen eljárásokat nem is lehet láncba fűzni, hiszen nincsen visszatérési értékük. Ezzel kivédve, hogy össze-vissza történjen mindenféle.

 

Ez a getElementsByClassName ismerős, szerintem ez volt az.