ugrás a tartalomhoz

hány óra alatt lehet megtanulni weboldal készítést?

toth_melinda · 2015. Júl. 13. (H), 10.04
Sziasztok. Szeretném megkérdezni, szerintetek teljesen az alapoktól, kezdő szintről mennyi idő alatt lehet megtanulni a weblapfejlesztést. Első sorban általános üzleti alkalmazásokra gondoltam kisvállalkozásoknak és webáruházra. Kódírással és értem ez alatt a html, css, javascript,php, mysql és jquery-t és valamilyen képszerkesztőt.Azt mondták, ezeket kell megtanulnom elsősorban, ezekhez kb hány óra szükségeltetik? tekintsünk most el attól, hogy mi minden csili vilit grafikai programozást stb is meg lehetne tanulni még. Egy átlagos üzleti weboldalhoz kb hány óra alatt lehet ezzel vegezni gyakorlással együtt? ne napokat írjatok légyszi, hanem óraszámot. köszönöm:-)
 
1

Évek... hosszú évek. Feltéve,

pythonozok · 2015. Júl. 13. (H), 10.14
Évek... hosszú évek.
Feltéve, hogy komoly munkáról van szó és nem Szomszéd Pistike Kft gányolásáról.
Webáruházban személyes adatokkal, sokszor pénzzel is dolgozni kell, pár órás tanulás után... hát én nem mernék felelősséggel belevágni.
Ha van cég, ahol többen dolgoznak és hajlandóak kezdőnek odaadni kisebb munkákat... úgy egy-két hónap intenzív tanulás után már talán...
2

köszi a válaszodat:-)

toth_melinda · 2015. Júl. 13. (H), 10.22
köszi a válaszodat:-)
3

10000

sandornemeth · 2015. Júl. 13. (H), 14.41
Lasd itt.

Es mivel meg egy kicsit uriember vagyok, ezert az elobb begepelt rantomat toroltem...
4

Ha a jó alapjaid megvannak, a

bamegakapa · 2015. Júl. 13. (H), 15.32
Ha a jó alapjaid megvannak, a csillivilli programozást már nagyon egyszerűen megtanulod, meg bármi mást is. A sok idő az, amíg eljutsz odáig.

Az elején lelkesedés kell, képesség a gondolkodásra és tanulási hajlam. Ha ezek megvannak, akkor menni fog. Ha nem, akkor neki se állj. Ha azt számolgatod, hány óra lesz, szerintem eleve neki se állj, mert nem fog menni. Nem lehet még csak becsülni se, hány óra, mert ez attól függ, hogy állsz hozzá. Valahol pár hónap és a végtelen között.

Azt kapásból felejtsd el, hogy belátható időn belül olyan dolgokat fejlessz, amiért emberek fizetnek és élesben kinn van a weben, mert így is elegen rontják a szakmánk hírnevét.

Mindennek ellenére én nem lebeszélni akarlak, ez egy király szakma.
5

Szvsz. attól függ, hogy ki

inf3rno · 2015. Júl. 13. (H), 16.27
Szvsz. attól függ, hogy ki tanít mire. Az alapokat elég gyorsan el lehet sajátítani, ha jó irányba terelnek már az elejétől, és tudod, hogy mi az, amit meg kell tanulnod, és mi az, amit kerülnöd kell. Szóval szerintem ideális esetben 1 hónap intenzív tanulás elég az alapokhoz, hogy átlásd a témát, onnantól meg csak gyakorlás és szorgalom kérdése, hogy hova fejlődsz tovább. Szerintem nem lehetetlen 1 év alatt megtanulni, de nem valószínű, hogy találsz olyan embert, akinek megvan a tudása, és tanítana. Innen-onnan összeszedni a dolgokat meg tényleg sok évet jelent.
6

Szóval szerintem ideális

Joó Ádám · 2015. Júl. 13. (H), 16.46
Szóval szerintem ideális esetben 1 hónap intenzív tanulás elég az alapokhoz, hogy átlásd a témát


Ez szerintem akkor igaz, ha programozni már tudsz. Neked hány év után került helyre például a rekurzió? (Nekem sok.)
8

Azt nem akarom elhinni, hogy

pythonozok · 2015. Júl. 13. (H), 17.11
Azt nem akarom elhinni, hogy egy faktoriális számítás leprogramozása ilyen nehezen emészthető feladat.
Mi tartott olyan sokáig?
Ezt most nagyon nem értem.

Vagy nem maga az elv, hanem a nyelvi implementációk hülyeségei okoztak gondot? (Python kis híján az őrületbe kergetett, mire rájöttem, hogy nem a rekurzióval van gond, csak a paraméterek átadása... khm... nem az elképzeléseim, hanem az utasításaim alapján működik :) )
10

Nekem a yield-el voltak

inf3rno · 2015. Júl. 13. (H), 17.48
Nekem a yield-el voltak hasonló problémáim. Elég össze-vissza dolog.
11

Azt kb. második nekifutásra

pythonozok · 2015. Júl. 13. (H), 18.06
Azt kb. második nekifutásra felfogtam. Viszont én relative szűz kézzel estem neki, nem volt friss gyakorlati tapasztalatom a közelmúltból.
Az OOP a mai napig gondot okoz, de már abbahagytam a tanulást - ami nem megy, ne erőltessük... :)
14

Mi tartott olyan

Joó Ádám · 2015. Júl. 13. (H), 20.38
Mi tartott olyan sokáig?


Utólag nyilván nehéz megmondani, mit nem értettél :) Persze itt nem arra kell gondolni, hogy pár éven keresztül minden nap órákat ültem felette, és mégse sikerült. Elég sokáig el lehet odázni a használatát, és ezzel a megértését, ha kellően ijesztő valami :)

Egyébként valószínűleg könyebb lett volna, ha megvannak az elméleti alapjaim, például tudom, mi az a call stack.
15

alapok

pythonozok · 2015. Júl. 13. (H), 20.56
Ö... izé... khm... célozni sem mertem rá, hogy ilyen ismeret hiányzott volna. ;)
Ilyenkor azért mindig örülök, hogy amikor én tanultam, a hardverközeli dolgokkal kezdtük a tanulást és fokozatosan építkeztünk ezekre az alapokra.
Bár az a hardver és szoftver környezeg már sehol sincs, nyomokban a mai napig tudom használni az akkor felszedett tudást.
16

15 éves voltam, és

Joó Ádám · 2015. Júl. 13. (H), 22.00
15 éves voltam, és gimnáziumba jártam. A kutya nem tanított semmit :)
17

Egy évvel idősebb voltam,

pythonozok · 2015. Júl. 13. (H), 22.26
Egy évvel idősebb voltam, amikor dolgozni kezdtem. És a programozók agyára menni az assembly mániámmal és a hozzá kapcsolódó kérdéseimmel :DDD
Igaz, én eleve programozói suliba jártam... (estin mikor meglátott az ottani osztályfőnök, még a szava is elakadt... ismert nappaliról :) )

De rég volt... :(((
20

Szerintem mindenki így

inf3rno · 2015. Júl. 13. (H), 23.11
Szerintem mindenki így kezdte. Én pár éve rátaláltam a régi kódjaimra, talán a mostani javascript obfuscatorok löknek ki olyat magukból. Öröm volt nézni. :D
21

Van, aki szerencsésebb, mint

Joó Ádám · 2015. Júl. 14. (K), 00.40
Van, aki szerencsésebb, mint például HZ, és van, aki vezesse, de nyilván nem lehet megúszni a bukdácsolást. Nekem is megvannak az első éles projektek, de még nem vettem elő őket nevetni – lassan ideje :)
23

A durva, hogy akiknek

BlaZe · 2015. Júl. 14. (K), 00.58
A durva, hogy akiknek tanították, sokéves aktív tapasztalatuk van is képesek lefagyni interjún egy "mi lakik a stacken", "hogyan okoznál stack overflowt", "hány stack van egy java programban" kérdéstől. Ok, utóbbi már kicsit haladóbb ismereket is igényel, de hallottam olyan válaszokat, hogy végtelen ciklussal, és hogy három. Utóbbinál nem bírtam megállni, hogy meg ne kérdezzem melyik három :)

15 évesen ez még érthető, hogy nem áll össze az ember fejében ha nem ilyen képzést kap, de 10 év gyakorlat után már fura. Metódusokat, függvényeket csak hív mindenki, és látott már stack tracet. Csak gyanús ott valami :)

Hasonló zűr szokott lenni a referencia fogalma és használata körül. A multithreading pedig - valamennyire érthető okokból - igen komoly zűröket szokott okozni.
24

Igen, az indirekció

Joó Ádám · 2015. Júl. 14. (K), 01.20
Igen, az indirekció tapasztalatom szerint elég magas léc. A referencia még hagyján, de amikor képbe jönnek a mutatók, akkor a pokol szabadul el :)
25

Jók ezek a stackes kérdések.

pythonozok · 2015. Júl. 14. (K), 01.42
Jók ezek a stackes kérdések. Nem biztos, hogy tőlem azt a választ kapnád amit vársz. :)
Pl. szerinted mi lakik a stacken? Melyiken? ;) Vagy mondjam, hogy minden, amit odateszel? Tényleg, erre mi a helyes válasz? Mert rémlik régről, hogy egyes nyelveken pl. a dinamikus változóktól kezdve a különböző függvényhívások visszatérési pontjain át, a bánat tudja meddig, sok minden.
Stack overflow? Milyen nyelven? :) Mondjuk egy végtelen rekuzió lehet megoldás? De úgy rémlik, valami malloc jellegű fv. eredménye is stackoverflow lesz megfelelően nagy érték esetén (??)
Hányféle stack van a javaban? Adat + utasítás + ??? Belelapozva a jvm doksiba, jóval több ha jól értem - vagy magára a Stack nevű osztályra kellene gondolni?
31

A kérdés célja, hogy

BlaZe · 2015. Júl. 14. (K), 13.45
A kérdés célja, hogy tesztelje a jelölt kicsit átfogóbb ismereteit, hogy hogy is működik egy program. Nem, vagy nem csak API ismeretet tesztelünk interjún, mert az nem lesz hasznos, ha váratlanabb szituációkba kerül munka közben.

A kérdés java/jvm témában kerül elő nálunk. Visszatérési információk, átadott paraméterek és metóduson belül létrehozott változók (primitívek, referenciák) laknak rajta, de nem objectek, azok a heapen laknak. Utóbbi a különbség, c-ben pl simán rá lehet erőszakolni a stackre egy marhanagy tömböt, aztán nézel :) Javaban nem. Ok, van escape analysis, és valójában megfelelő scope-ú objectek is kerülhetnek stackre (stack allocation, nem összekeverendő a thread-local allocationnel), akár regiszterekbe is, de ez olyan dolog, ami tényleg nem elvárás hogy tudják. Illetve ez egy fordító/runtime szintű optimalizáció, ami a GC overheadet hivatott elkerülni a stack természetes tulajdonságaira támaszkodva. Metódusból kilépve eldobásra kerül a frame, tehát gyakorlatilag nincs költsége a felszabadításnak. Meg persze segíti a cache localityt, ezáltal a végrehajtási sebességet csökkenti.

Minden threadnek saját stackje van. Illetve 2, egy a java és egy a native hívásoknak. De az bőven elég, hogy minden threadnek saját stackje van. És itt jön be, hogy miért fontos a kérdés. Ha valamiért eldöglik egy alkalmazás, nem akar leállni, deadlockba került stb, az egyik első dolog amit megnézel, hogy mit csinál épp. Ez pedig a thread dumpból derül ki, amit gyakorlatilag a stackekről szed össze.

És igen, a (megfelelően nagy, vagy végtelen) rekurzió megoldás, ezért is pont itt került elő a kérdés :)
26

Nem tudom, én nem tanultam,

inf3rno · 2015. Júl. 14. (K), 03.02
Nem tudom, én nem tanultam, nem is nagyon néztem utána alaposabban soha, mert annyira nem érdekel, de kb fél perc gondolkodással meg tudtam válaszolni ezek a kérdéseket (nem biztos, hogy helyesen). Szokatlan kérdések, nem tartozik a napi rutinhoz a megválaszolásuk, és ha újat kérdeznek valakitől stressz helyzetben, akkor hajlamos gondolkodás helyett lefagyni. Történt már velem is ilyen vizsgán, amikor úgy mentem oda, hogy jajj mi lesz, ha megbukok, nem úgy, hogy ez tök jó, mert megmutathatom, hogy mit tudok, és a legtöbbet fogom kihozni magamból. A két hozzáállás között azért elég nagy a szakadék...

Jó hát a multithreading az ördögtől való. :D
7

Nem tudok róla, hogy gondom

inf3rno · 2015. Júl. 13. (H), 17.11
Nem tudok róla, hogy gondom lett volna a rekurzióval, de ki emlékszik már arra. Inkább az oo-val küzködtem sokáig, kellett hozzá jópár könyv elolvasása, hogy helyrekerüljön minden. Ha a vizsgaidőszakokból indulok ki, amiket végigtoltam, ott sem okozott problémát 10 könyv megtanulása egy hónap alatt, úgyhogy annyira nem tűnik lehetetlennek ez az 1 hónapos gyorstalpaló.
13

A rekurzió az egyike az

Joó Ádám · 2015. Júl. 13. (H), 20.32
A rekurzió az egyike az általánosan nehézséget okozó koncepcióknak (ezt egyrészt magamon és később tanítványokon is láttam), de ilyenek lehetnek a logikai műveletek, vezérlés, indirekció és mások, kinek mi.

Tehát már csak ezért se – mert egy gondolkodásmód kialakítását igényli – hiszem, hogy mindenféle alap nélkül meg lehetne tanulni programozni egy hónap alatt. És akkor még nem beszéltünk arról a rengeteg diverz technológiáról, ami a webet alkotja.

Tény, más tizennéhány évesen, szervezetlenül, az internetről összeolvasgatva, hiányos angoltudással, és más egy-két évtizeddel később, tapasztalt oktató irányítása mellett, jól felépített segédanyagokkal. De még egyetemi szakokon, féléves felkészüléssel is igen nagy a bukási arány a programozás alapjai tárgyakból, kereszt- (meg sokadik kereszt-) féléveken is.
27

Miért nehéz megtanulni dolgokat

pp · 2015. Júl. 14. (K), 05.25
Ha igényed van valami olyanra, amit az eddigi eszközeiddel nem tudtál jól megoldani, akkor jöhet egy új fogalom és könnyedén megtanulható. Ha nincs meg ez az igényed, akkor piszok nehézé elhelyezni, következés képpen megtanulni.

Évek telhetnek el, amíg találsz olyan feladatot, ami rekurzióval jó megoldani.

Szerintem az az egyik fő baj a rekurzióval, hogy nem az elején próbálják meg megmutatni, hanem akkor amikor már az ember egyből látja, hogy na ezt a feladatot nem így kéne megoldani. Lásd Fibonacci számsor, amire a rekurzió a lehető legrosszabb megoldást jelenti, és ezt látod is amikor előveszik a mindenféle vezérlési szerkezet után, és nem is érted, hogy akkor ez miért jó, amikor lassú, és még nehezen is érthető. :)

pp
28

Nem kifejezetten életszerű

pythonozok · 2015. Júl. 14. (K), 07.55
Nem kifejezetten életszerű példa: 8 királynő (gondolom, ismerős).
Ha nem ismered a rekurzió fogalmát, esélyes, hogy meg tudod oldani más módon is. Vagy akár a faktoriális számítás, amin megtanultam, hogy mi is az a rekurzió és miért volt hülyeség az assembly tanárunktól, amikor kijelentette, hogy ez kerülendő, de nemtette hozzá, hogy csak az iskolai feladatok megoldásánál.
29

Nos a faktoriális számítás

pp · 2015. Júl. 14. (K), 08.46
Nos a faktoriális számítás szintén egy olyan példa aminek ugyan rekurzív a matematikai definíciója, de a megvalósításánál a rekurzió egy kérdés azért felvet:

Miért tároljuk le az összes faktoriálist, amikor egy sima ciklussal kiszámolva mindig csak az előzőre van szükségünk?

Szóval az olyan algoritmusoknál, ahol feleslegesen tárolunk, én nem látom túl nagy értelmét, szemben mondjuk egy quicksort algoritmussal, ahol a különböző állapot információkat ténylegesen tárolnunk kell.

Persze ez csak azért van így, mert a faktoriálist és a Fibonacci számot meg kellett tanulnom kifordítva kitalálni, vagyis a rekurzív definíciót átfordítani sima ciklussá, és amikor az arcomba kaptam a rekurziót, akkor szépen félre is tettem, hogy jó jó, értem én, de ez kb. semmire se jó, mert erre van már kész, ráadásul gyorsabb, stabilabban működő, nagyobb számokat kiszámoló, és világos(számomra ugye) megoldásom.

Aztán ahogy Ádám, én is évek múlva kerültem olyan feladat közelébe, aminél már világos volt, hogy ez az ami kell, mert bár meg tudnám oldani máshogy is, de miért is lássak hozzá egy olyan eszköz (stack) implementálásához, ami már a nyelv sajátja. (10 évesen kezdtem programozni, és főiskolán találkoztam a fenti rendezéssel)

pp
30

Végeredményben... tudsz olyan

pythonozok · 2015. Júl. 14. (K), 08.54
Végeredményben... tudsz olyan feladatot, ami csak rekurzióval oldható meg?
Ellenben... funkcionális nyelvek esetében csak rekurzív definícióval tudod leírni pl. a faktoriális számítást. ;)
Egyébként a faktoriális (vagy inkább a 8 vezér) csak példa volt arra, hogy nem feltétlenül szükséges kifogyni az eszközökből ahhoz, hogy érdemes legyen újakat keresni.
34

Lehet nem ment át amit mondani akartam.

pp · 2015. Júl. 15. (Sze), 07.32
Én azt mondtam csak, hogy nekem a Quicksort volt az amikor azt mondtam, hogy áhá, erre jó a rekurzió. Azt is meg lehet oldani nem rekurzívan még talán gyorsabb is lesz valamivel, cserébe kevésbé olvasható, érthető.

A fibonacci számnál, irreálisan nagy lesz a futásidő, a faktoriálisnál meg stackoverflow lehet(míg a nem rekurzívnál nem... zx81-en kezdtem, 1K RAM, ott ez valós probléma volt), tehát mindkét esetben a rekurzív megvalósítás rosszabb, míg a Quicksort-nál nem.

De mint írtam is, és még egyszer kihangsúlyoznám, hogy ez a személyes élményem, nem gondolom, hogy más is így van ezzel, vagy így kéne lennie ezzel.

Tökre el tudom fogadni, hogy valakinek a faktoriális segített, vagy a funckionális programozás. Nincs azzal semmi baj, sőt. Örülök, ha minél többen megosztják ezeket az élményeket, hisz akkor közelebb jutok ahhoz, hogy hogyan és mikor lehet jól átadni ezt a komplex fogalmat.

pp
33

Szvsz. ciklussal jobban

inf3rno · 2015. Júl. 14. (K), 15.19
Szvsz. ciklussal jobban átlátható a kód, mint rekurzióval, stack implementálás ide vagy oda.
35

Nézd a 34.-ben linkelt

pp · 2015. Júl. 15. (Sze), 07.34
Nézd a 34.-ben linkelt példát. Nekem kevésbé átlátható a nem rekurzív megvalósítás. Neked az jobban átlátható?

pp
36

Nekem egyik sem átlátható, a

inf3rno · 2015. Júl. 15. (Sze), 14.22
Nekem egyik sem átlátható, a comment meg kifejezetten haszontalan a másodiknál, de talán túl finnyás vagyok. :D Az első kétség kívül okosabban megírt algoritmus, de ez talán inkább a C programozói tudást tükrözi, mint a két technika közötti különbséget.

Egyébként ez az a/b vagy left/right szerintem rossz szokás. Talán a left/right még elmegy bizonyos esetekben, ha a right tényleg jobbra van a tömbön a másiktól. Jobb lenne helyette valami value/comparedValue/comparisonBase vagy valami ilyesmit használni, ami jobban kifejezi, hogy itt most a lényegi elem az összehasonlítás. (A másik lehetőség kivenni külön függvénybe az összehasonlítást, és a fordítóra bízni, hogy optimalizálja.) Engem legalábbis mindig zavart kódban ha ilyen a/b-t láttam, de persze én is átvettem jobb híján.

Csak hogy egy másik példát hozzak, fák bejárásánál PHP-ben is vagy rekurziót használsz vagy RecursiveIterator-t (vagy mifenét mindig elfelejtem a nevét). Ha nem kellenek nagyon extra dolgok, akkor simán rekurzívan szerintem valamivel átláthatóbb a dolog. Nekem legalábbis.
37

Köszi, a fabejárás egy újabb

pp · 2015. Júl. 15. (Sze), 15.44
Köszi, a fabejárás egy újabb minta ami segíthet megérteni/megértetni a rekurziót.

(ne de most már eléggé offba megyünk.)

pp
38

Engem a fabejárás

Joó Ádám · 2015. Júl. 16. (Cs), 18.35
Engem a fabejárás kényszerített rá a rekurzió megértésére. Iteratívan sehogy sem sikerült megfogalmazni a dolgot, teljesen belezavarodtam, a rekurzió így rögtön sokkal vonzóbbá vált, még ha varázslatnak is tűnt először.

Azóta persze már írtam parsert iteratív implementációval, de számomra máig a fabejárás a legkézzelfoghatóbb példája a rekurzió alkalmazásának, szemben az elvont matematikai definíciók adaptálásával.
9

Én az ezredforduló környékén

kuka · 2015. Júl. 13. (H), 17.42
Én az ezredforduló környékén kezdtem a webes fejlesztés megismerésébe. Az akkori alapoktól kezdtem: HTML, CGI, HTTP, …, Perl, … (Ja, kérem, akkoriban még nem a PHP volt a király.) Egyelőre még nem értem a tanulás végére.

„html, css, javascript,php, mysql és jquery-t és valamilyen képszerkesztőt” megtanulni nem egyszeri feladat. Most megtanulhatod a felsoroltakat a jelenlegi állapotukban (hacsak nem eleve az elavult dokumentációk közé tévedsz), de a tanulás ezzel még nem érhet véget.
19

Sosem érünk a végére, de ha

inf3rno · 2015. Júl. 13. (H), 23.08
Sosem érünk a végére, de ha megállsz, nagyon lemaradsz. Ilyen ez a pop szakma. :D
12

Sok dologtól függ

gabesz666 · 2015. Júl. 13. (H), 19.12
Azért egy ilyen kérdésre elég nehéz egzakt választ adni. Akár az is lehetne a kérdés, hogy mennyi ideig tart felépíteni egy házat. :) Sok mindentől függ a dolog. Mekkora ház? Hányan építik? Hányszor kell újrakezdeni a szar alaprajz miatt? Hasonlóan a webfejlesztés megtanulása is sok tényező függvénye. Milyen tapasztalataid vannak eddig? Mennyire fogadod be könnyen ezt a jellegű tudást? Kitől/honnan tanulsz? Satöbbi. Csak arról tudok magabiztosan nyilatkozni, hogy nekem mennyi idő volt és mennyi idő lehetett volna. Jelenleg 7 éve űzöm az ipart. Azt gondolom, hogy most már elég erős alapjaim vannak 3-4 nyelvben, illetve a programozás elméletének területén. De ez az idő lehetett volna akár a fele is, ha komolyabban ráfekszem a témára. A hosszú idő viszont ne tántorítson el, ez egy nagyon szép és értékes szakma. Érdemes belefeccölni az időt!
18

+1, az én lassan 20 évemet is

inf3rno · 2015. Júl. 13. (H), 23.06
+1, az én lassan 20 évemet is bele lehetne sűríteni 4 évbe, ha nem csak úgy ímmel-ámmal programozgatnék, meg nem netről tanultam volna mindent, meg nem foglalkoznék mellette még ezer másik dologgal. De nem sajnálom, hogy így alakult, sokminden érdekel és szeretek tanulni.
22

Nos, maga programozás nem ott

tóthika · 2015. Júl. 14. (K), 00.41
Nos, maga programozás nem ott kezdődik, hogy meg kell tanulnod egy nyelvet, oszt' csókolom. Először is, az embernek ki kell alakítania egy gondolkodásmódot. Ehhez nem kell tudni programozni, viszont a programozáshoz szükség lesz rá. Ahhoz viszont, hogy fejlődni tudj, több gondolkodásmódot is el kell sajátítanod - hiszen ha vesszük például azokat a típusú nyelveket, melyeket felsoroltál, eléggé eltérően kell őket felhasználni céljainkhoz.
A programozás egy adott probléma megoldására szolgál. Írhatsz egy pársoros chatboxot, de akár egy komplett tartalomkezelőt is. Nem mindegy viszont, hogy ezt hogyan teszed. Ahhoz, hogy jól karbantartható és átlátható kódot írj meg, rengeteg praktika is szükséges a gyakorlás mellett, melynek nagy részét érdemes megfogadnunk.
Egy nyelv szintaxisa tulajdonképpen arra szolgál, hogy a problémádat le tudd írni. Megfelelő logika/gondolkodásmód kialakításával a nyelvet egy amatőr hamarosan profiként is ki tudja használni, ez csakis a szándéktól függ. Ha fejlődni akarsz, utána kutakodsz, keresel, és a kódolási/logikai praktikákat kihasználva előbb-utóbb rendezett kódot fogsz írni - mert a szükség ezt kívánja tőled. A szép kód könnyebben javítható és jobb kódolási képességekkel fogsz hamarosan rendelkezni. Mindez persze rengeteg időt és utánanézést igényel.
Továbbá a kifejlesztett logikádat rengeteg más helyen is felhasználhatod. Ki ne programozna? :)
32

Csinaltam

janoszen · 2015. Júl. 14. (K), 14.46
Az itt hozzaszolok egy reszevel szemben en mar tartottam ilyen tanfolyamot nullarol. Ha NAGYON jo tanaraid vannak (akik jellemzoen nem egy iskolaban rohangalnak), es napi 8 oraban toltik beled a tudast, akkor 3 honap alatt eljutsz oda, hogy egyaltalan hozza tudsz nyulni a kodhoz, majd tovabbi 3 honap alatt oda, hogy talan ertekelheto a munkad. Kb. osszesen 2 ev utan fogsz tudni junior szinten megbizhatoan eloallitani kodot. Ha jo vagy.
39

10+ éve tolom, ebben volt

Gl3am · 2015. Júl. 17. (P), 11.42
10+ éve tolom, ebben volt designerkedés, frontend, backend, sysadmin. Ez egy életvitel, nem telhet úgy el egy szombat vagy vasárnap sem, hogy ne ez foglalkoztatna. Hála Istennek a lelkesedésem és az érdeklődésem az informatika felé, a mai napig sem lankadt. Eszembe sem jutott ezt órákban mérni, tudtam, hogy ha egyszer leülök a gép elé, akkor (remélhetőleg) idős koromban gép elől visznek el zsákban. :)

Nem órák és nem hónapok, hanem évek kellenek ahhoz, hogy egy magabiztos, eladható tudást összeszedj, és azt is kevésnek fogod érezni.
40

Koszonm mindenkinek a

toth_melinda · 2015. Júl. 17. (P), 12.29
Koszonm mindenkinek a valaszokat. Az orakat csak azert irtam, mert orakban merhetem az idomet, egy heten x orat tudok ra forditani es szerettem volna tudni, hogy akkor meddig fog tartani, de gondolom sokaig. Azert megprobalom.
41

Ha azt veszed észre, hogy

bamegakapa · 2015. Júl. 17. (P), 12.39
Ha azt veszed észre, hogy több időt fordítanál rá, mint amennyit megengedhetsz magadnak, az jó jel. Az érdeklődés, a lelkesedés nagyon fontos, ahogy többen is írták. Fontos, hogy ne verd át magad.

Ha tudsz angolul legalább olvasni, az segít. Ha nem, akkor azt is meg kell tanulnod.
42

Ha esetleg olvasnivalóval

inf3rno · 2015. Júl. 17. (P), 13.24
Ha esetleg olvasnivalóval vagy technológiával kapcsolatban kérnél tanácsot, akkor szívesen segítünk. Azt kéne szerintem először tisztáznod, hogy milyen szintű tudásra van szükséged. Pl objektum-orientált programozás, teszt-vezérelt fejlesztés, meg hasonló dolgok (amiket sok időbe telik megtanulni) egyáltalán nem kellenek, ha csak egy sima HTML oldalt akarsz összeütni egy kis CSS-el meg esetleg néhány jquery scripttel.
43

Nem érdemes már előre

bamegakapa · 2015. Júl. 17. (P), 16.19
Nem érdemes már előre elhatároznia, hogy megragad azon a szinten. Ha az alapok jók és a szemlélet nyitott, természetes lesz szerintem, hogy tovább akar fejlődni és még jobban akarja majd csinálni, amit csinál.
44

Gondolom egy konkrét projekt

inf3rno · 2015. Júl. 17. (P), 17.53
Gondolom egy konkrét projekt kedvéért kezdi el, nem mert éppen sok az ideje...
45

Hm, erre nem is gondoltam. Én

bamegakapa · 2015. Júl. 17. (P), 23.05
Hm, erre nem is gondoltam. Én úgy értettem, tényleg tanulni akar.
46

Olvasd el az indító

inf3rno · 2015. Júl. 17. (P), 23.12
Olvasd el az indító hozzászólást. Amúgy sokan vannak, akik gondolják, hogy majd összeszórnak egy webshopot házilag, aztán beletörik a bicskájuk.