-
IT café
Új hozzászólás Aktív témák
-
Még ha tegyük fel meg is van oldva tökéletesen, sebességben attól még nem lesz nyerő. Egyébként itt van row-level vs statement-level megkülönböztetés? Honnan tudja, hogy mely row-okra kell meghívni a "triggert", stb.? Ez mind overhead. Persze tudom, a hardver olcsóbb, mint a programozó.
Btw, én nem azt mondom, hogy SQL-be kell, hanem csak bizonyos részét az üzleti logikának célszerű a DB-be pakolni, mert jóval hatékonyabb, mindent használjunk arra amire való, ésszel.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
martonx
veterán
válasz akrobet #9893 üzenetére
"De mit csinálsz ha váltani kell egy másik providerre, neaggyisten valamilyen no-sql megoldásra?" - ok tegye fel a kezét, aki naponta vált MS SQL-ről Oracle-re és vissza SQL - NoSQL pedig még ORM-el sem átjárható, mivel teljesen más szemléletmódot, felhasználást várnak el.
Egy programnál mindig el kell dönteni, hogy milyen infrastruktúrán fog futni, és utána abból kihozni a legjobbat. Tipikus félreértés, hogy az ORM azért jó, mert elfedi a DB layert, és könnyű átjárhatóságot biztosít (az meg még nagyobb félreértés, hogy SQL - NoSQL átjárhatóságot is biztosítana). Mármint az átjárhatóság SQL-en belül még nagyjából igaz is, de ennek csak akkor van szerepe, ha az ember tudatosan, direkt pont olyan rendszert fejleszt, amit kb. bárhova el akar adni, és célja, hogy Oracle, MySql, PostgeSQL, MS Sql, bármilyen SQL felett tudjon működni a rendszere. Ebben az esetben némi plusz munkával valóban meg lehet írni ORM-el úgy a rendszert, hogy az tökéletesen átjárható legyen.
ORM-et elsősorban inkább azért használunk, mert kényelmes vele dolgozni, a kód valóban olvashatóbb lesz tőle, de fontos, hogy folyamatosan tartsuk szem előtt, hogy az ORM csak egy eszköz, és nagyon könnyen hibás architektúrákhoz vezethet, ha csak és kizárólag egy ORM-re alapozva fejlesztünk. Erre tökéletes példák vagytok ti.Ez az SQL-ben legyen logika dolog teljesen eset függő, nincs rá jó válasz. Én az általad megfogalmazott problémával kapcsolatban mondtam, hogy ebben az esetben szerintem tipikusan sokkal jobb megoldás tud lenni, ha komolyabban az SQL-re bízná magát az ember, és komolyabban elgondolkodna az SQL-ben való adatmodellezésen (nem is feltétlenül érdemi logikának kellene talán az SQL-ben lenni, egyszerűen csak végre komolyabban kellene gondolni, tervezni az SQL oldalon is a tábla struktúrákat, amikkel a várt dinamikus szabály rendszert könnyen lehetne modellezni, majd azt utána C# oldalon felhasználni).
Pláne amikor későbbi hszediből ki is derült, hogy a DB-t tényleg ahogy esik, úgy puffan alapon használjátok, szóval egyre biztosabb vagyok a meglátásom helyességében.
Szóval nem akarok olyan erős kijelentéseket tenni, hogy csak így, vagy csak úgy a jó, az elmúlt pár évben mindkét megoldást használtam, mindig azt amire éppen az adott esetben szükség volt.Főállásomban pont az elmúlt években volt / van egy ilyen komolyabb szemléletváltás, amikor az eredetileg mindent EF-el oldjunk meg, és kapja meg az adatot a C#, aztán majd abban jobban feldolgozzuk szemléletet a több milliárd adatsoros tábláknál már fel kellett, hogy váltsa az "oké, akkor amit lehet SQL oldalon oldjunk meg, de azért amit nem muszáj, az menjen továbbra is EF-el" szemlélet. Hidd el, pont ugyanúgy lehet mindent tesztelni SQL felhasználása mellett is, csak mondjuk egy teszt nem 5 másodpercig fog futni, hanem fél percig. De ha elég jól párhuzamosítod őket, akkor végül időben se tart feltétlenül tovább.
Minden csak hozzáállás kérdése, még az általad felvázolt alapvetően hibásnak tűnő architektúra is valószínűleg tesztelhető maradna némi refaktorálás után, megfelelő mockolásokkal.Én kérek elnézést!
-
MODERÁTOR
válasz fordfairlane #9903 üzenetére
Sajnos én is így gondolom, + a "mindentlátott kolléga" is ezt vallja itt mellettem!
Ugyanakkor maximális tiszteletem lezsónak is!
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
fordfairlane
veterán
Nem akarom bárkinek is a szakértelmét lekicsinyelni, sőt, de a tapasztalatom az, hogy tárolt eljárásokkal dolgozni horror. Egy szót sem szólok a kódbázis hordozhatóságáról, az ezen a szinten elég alacsony lehet, csak már maga a munka menete (pl. debuggolás) elég meghatározó, negatív élmény volt számomra.
[ Szerkesztve ]
x gon' give it to ya
-
hokkento
újonc
Sziasztok!
Mivel én nem nagyon értek hozzá, egy programozónak meg gondolom fél perc alatt sikerül megoldania, ezért kérem hozzáértő segítségét! Előre is köszönöm!
A "problémám" a következő: szeretnék egy parancsot írni, ami a windows bootolása után azonnal lefuttatja a parancsot. Konkrétan egy mappát kellene kitörölni minden WIndows indulásnál ...
Ez hogyan, miként oldható meg a legegyszerűbben?
Köszönöm előre is a segítségeteket!
Üdv: Gabi -
martonx
veterán
válasz fordfairlane #9903 üzenetére
+1 a triggerek ellen. A tárolt eljárások viszont egy bizonyos DB méret / teljesítmény elvárás felett kikerülhetetlenek. No persze ilyenkor jön be az, hogy X TB-os DB-t az ember már amúgy sem hordozgat, nem migrálgat Oracle-ről MS SQL-re és vissza, vagy pedig rászánja azt a pár ember hónapot a feladatra.
A debugolás persze más kérdés. Egyrészt MS SQL tárolt eljárásait lehet debugolni, másrészt SQL szinten a debugnak sokkal kevesebb értelme van, harmadrészt egy SQL kód azért még mindig egyszerűbb, mint egy komoly C# logika (jó, láttam már 1500 soros tárolt eljárást is, na azt debugolni nem volt kellemes, de azt is a kényszerűség szülte, direkt SQL szinten tartva a logikát is 15 perce futásideje volt egy 96 magos SQL szerveren).
Jellemzően azért könnyen meg lehet találni SQL-ben is, hogy hol ment félre egy where feltétel, vagy egy join.Én kérek elnézést!
-
válasz akrobet #9893 üzenetére
nem tudok elképzelni olyan helyet, ahol mssql-t ne lehetne találni. tehát ha szolgáltatót is kell váltani, adatbázismotort nemigen.
másrészt ha nosql-re kellene váltanod, ott a legkisebb problémád lesz az, hogy pár eljárás volt az sql motorban. sql-ről nosql-re váltani az kb. a komplett alkalmazás újratervezését jelenti."Nem lehetetlen SQL-ben megírt kódot tesztelni, karbantartani, csak nagyon hamar el fog menni tőle a kedved, ha egy olyan business model-ed van, ami kb 300 egyedi entitásból áll 15+ level mélységű relationokkel...": itt nem arról van szó, hogy az egészet tedd procedurális sql-be, hanem arról, hogy azt az egy problémát, amivel a threadet elindítottad, azt tedd ilyenbe.
nekem vannak kétségeim, hogy jól van-e tervezve az az adatbázis, amiben 15+ level mélységű relációk vannak, különös tekintettel a view-ekre...
"nagyon hamar el fog menni tőle a kedved": ezt a szempontot nem annyira szokták figyelembe venni... nekem pl. a felvételi elbeszélgetésen elmenne a kedvem, ha mssql-ről esne szó
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
postgreshez anno volt olyan cluster megoldás, ami az sql kéréseket szórta szét a node-ok között. utána a kéréseket minden node-on kiértékelte. így a random függvény is lefutott minden node-on külön. az összes jelszó meg autentikációs token meg minden ilyen, amiben véletlenszám is volt, úgy szétszaladt, hogy nem is lehetett többet összeterelni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz martonx #9907 üzenetére
Triggerekkel szerinted mi a gond, pl a példám miért nem jó? Before triggerek helyes használatára szerintem jó példa az egyes automatikusan generált mezők kitöltése, melyekhez pl külső táblból lekérés vagy tárolt eljáráshívás szükséges. Ezt lehet persze enélkül is csinálni, de ez szvsz tök olyan dolog, amit a DB-nek érdemes csinálnia.
(#9905) fordfairlane: Értelemszerűen nem szabad túl sok mindent rájuk bízni. A tranzakciókat nem is értem miért kéne idekeverni. Egy szóval nem mondtam, hogy az egész business logicot tárolt eljárásokkal meg triggerekkel kéne megoldani, ez persze hogy baromság. Csak egy kis részét lehet, hogy érdemes, attól függően, hogy mennyire bonyolult az adatszerkezeted.
(#9909) bambano: Ez se ma volt. De tény, natív replikáció a 9.0 óta van, viszonylag későn a konkurens megoldásokhoz képest. De van.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
Ezzel egyetértek. Magukkal triggerekkel nincs baj, az emberekkel van a probléma, akik rosszul használják.
Na, de hogy konkrét példák is legyenek, nálam ilyesmik fordulhatnak elő triggerekben (row-level):
BEFORE TRIGGER:
- automatikus mezők kitöltése (ahol a default nem használható)
- integritás ellenőrzés (ahol a check nem használható)
- tiltott operációkra exception (pl egy hsz időpontja nem módosítható)AFTER TRIGGER:
- cache táblák automatikus kitöltése
- kapcsolódó táblák cache mezőinek kitöltése (pl hszszámláló++)
- megváltozott adat korábbi értékének archiválása másik táblábaPersze valaki nem ért a PL/SQL-hez akkor ne így csinálja, s ezeknél magasabb szintű logikát tényleg nem szabad triggerekbe tenni, mert úgy láthatatlan, s abból csak baj lesz.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
martonx
veterán
A triggerekkel az a baj, hogy a tárolt eljárásokkal szemben abszolút debugolhatatlanok, nyomon követhetetlenek. Sőt az egész DB-t simán össze tudják omlasztani ha véletlenül valami deadlock befigyel a futásuk alatt.
Érted, a kódban debugolod, hogy mi történik és miért, meghívsz egy tárolt eljárást, akkor ugyan kontextust kell váltania hozzá, de semmivel nem nehezebb nyomon követni, hogy mi történik, nincs semmi rejtett varázslat.
Míg ha van pár triggered, amik netán még egymás módosításai miatt is elsülnek, akkor meg nézel baromi nagyokat, hogy neked most akkor miért nem futott le az inserted itt, helyette lett update amott, és kezdheted az egész db-t felderíteni, és mindezt folyamatosan fejbe kell tartanod, hogy ha itt kódban kiadsz egy insertet, akkor amott fog updatelni. Amíg az ember magának kókányolgat, addig semmi baj nincs a triggerekkel, illetve bizonyos esetekben tök ártalmatlanok, de alapvetően fejlesztésnél messzire kerülendő tipikus rossz gyakorlat a használatuk.A hozott példáid egytől egyig megoldhatóak lennének kódból, semmi hozadékuk nincs triggerekben tartani ezeket a logikákat (vagy átírni őket egy-egy tárolt eljárásra, még mindig sokkal karbantarthatóbb, áttekinthetőbb lenne).
[ Szerkesztve ]
Én kérek elnézést!
-
sztanozs
veterán
válasz martonx #9914 üzenetére
Triggerekben tényleg nem célszerű (általában) üzleti logikát tartani, de szép tervezésnél nincs direkt query alkalmazás oldalról, hanem SP-kön keresztül van megoldva az adatbázis lekérdezés/manipuláció.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
válasz martonx #9914 üzenetére
Valóban, a láthatatlanság problémás lehet, de szerintem amiket felsoroltam, azok elég egyszerű feladatok. Illetve triggernél nálam az egy megkötés, hogy ha ír valami mezőt vagy táblát, akkor ugyanazt alkalmazás oldalról csakis olvasom, sosem írom, különben ki tudja mi lesz.
Ez alól kivételt képez pl a particionálás. Itt pont az a feature, hogy a PL/SQL logika az alkalmazás elől elrejtse azt, hogy valójában több tábla van. Ez DB logika, az alkalmazásnak erről nem kell tudnia. Hasonló az, amikor pl valamilyen bonyolultabb adatszerkezetet (pl fát) tárolsz DB-ben, ennek szabályait is triggerekkel a legjobb megoldani, hogy az alkalmazás kódja ne bloatolódjon szét.
Igen, az sokszor előfordul, hogy a trigger ír másik táblába, s az meg újabb triggert süt el. Ezek lehet áttekinthetetlen valaki számára, de ha megfelelően jársz el, akkor nincs meglepi. Fontos az egyszerűség.
Meg lehet csinálni alkalmazás oldalról is, de úgy bonyolultabb megírni, meg jóval lassabb is lenne. Nálam a triggerek a nagyon egyszerű logikákat tartalmaznak, ami nem IF vagy hozzárendelés az kb mind SQL kérés, egyáltalán nem olyan dolog, mint amit alkalmazásban írnál. Ugyanezt tárolt eljárásra átírni elég furán hangzik, hisz maguk a triggerek is tárolt eljárások, csak automatikusan hívódnak, amikor kell. Mi értelme lenne kézzel hívnom, ha lehet automatikus?
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
martonx
veterán
"Mi értelme lenne kézzel hívnom, ha lehet automatikus?" - az, hogy ha téged holnap elüt a villamos, és te ugyan tudod, hogy mik a saját konvencióid, és mit miért csináltál, és odaültetnek a helyedre valaki mást, akkor az 3 hónapig azt se fogja tudni, hogy fiú-e vagy lány.
Rengeteg ilyen kódot vettem át, örököltem már meg, és mindig borzalmas volt lekövetni ezeket az elrejtett hülyeségeket, amik ráadásul jobban átgondolva éppen semmit nem is adnak hozzá kód futásteljesítményéhez, azon kívül, hogy kódban az ember esetleg megspórol 1-2 sornyi PHP-t.Én kérek elnézést!
-
válasz martonx #9917 üzenetére
Mielőtt egy friss programozó hozzányúl a kódhoz, megnézi, hogy épül fel az adatbázis, az rögtön látja, hogy hoppá, vannak triggerek, s máris ugyanott van, mint a tárolt eljárással. Na meg van egy olyan varázslatos dolog, hogy dokumentáció.
Attól még, hogy neked rengeteg rossz tapasztalatod van valamivel kapcsolatban, nem biztos, hogy az az ördögtől való. Pl rengeteg PHP-ban írt "műalkotás" létezik, de attól még nem lesz a nyelv szemét. Ha a kacsa nem tud úszni, nem a víz a hülye. Persze ha az ember bizonytalan, akkor értelemszerűen inkább ne csinálja, nehogy az legyen az eredmény, hogy valami triggerben van, más meg alkalmazás szinten, tök random, rendszer nélkül.
Az 1-2 sorral több PHP tök jó lenne, de sajnos nem igaz. Ha tegyük fel most le kéne cserélnem a triggereket PHP kódra, akkor pl egy új hsz felvitelénél egy sima INSERT mellett még ezeket kéne megcsinálnia a PHP kódnak:
- téma hsz-számának és utolsó hsz ID-jének frissítése
- téma utolsó hozzászólójának frissítése
- keresőindex frissítése
- particionálás kezelése
- a hozzászóló itt szóltam hozzá listájának frissítése
- a hozzászóló hsz-számának növelése (fórumtól függ, hogy milyen típusú)
- a hozzászóló rangjának léptetése, ha olyan van
- stb.Ha ezek bármelyike nincs, akkor borul a konzisztencia, ezért véleményem szerint az adatbázisban a helyük. Az alkalmazás feladata szerintem az, hogy validációt elvégezze a bemenő adatokon, s azokat az adatbázisnak megfelelő formába hozza és felvigye oda. Azzal nem kell foglalkoznia, hogy bizonyos származtatott vagy kapcsolódó adatok konzisztenciáját fenntartsa. Ezt persze nem kell elfogadni, csak azt próbálom megértetni, hogy mikor lehet létjogosultsága a triggereknek.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
MODERÁTOR
Az a baj, hogy a való életből vette a példát, amit én is alá tudok támasztani. Egy jó nevű autó gyártó cégnek karbantartottam szoftver majd a válság idején kikerült indiába majd vissza. Szóval ami te csinálsz az high quality de amit más nem biztos.
"Azzal nem kell foglalkoznia, hogy bizonyos származtatott vagy kapcsolódó adatok konzisztenciáját fenntartsa"
De igen, az is.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
De az ilyen tapasztalat az invalid argument, lásd a kacsa és a víz esete. A triggerek ellen szól persze rengeteg érv, de sok másik meg mellettük van. Tudni kell, hogy mire való a trigger, s arra használni, ésszel, ennyi a követelmény.
Azért írtam, hogy "szerintem" meg "nem kell foglalkoznia", nem pedig azt, hogy "ne foglalkozzon". Mindenki úgy írja meg, ahogy tudja, de azt ne mondja nekem senki, hogy a triggert nem szabad használni.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
martonx
veterán
Nem azt mondtam, hogy nem szabad, hanem azt mondtam, hogy kerülendő, és tipikus rossz gyakorlat. Amiket felsoroltál, hogy trigger csinálja, hát azt se mondanám jó gyakorlatnak, még ha így utólag nézve kényelmesnek is tűnik, és francnak van kedve normális kóddá refaktorálni 1-2 nap alatt a most is működő megoldást De mindegy hagyjuk, részemről a téma lezárva.
Én kérek elnézést!
-
fordfairlane
veterán
Ez tipikusan olyan lépéssorozat, ami egy tárolt eljárásban szépen, áttekinthetően implementálható, lépésről lépésre. Semmi szükség triggerekre, és az általuk jelentett rejtett adatfüggőségekre. A PHP-nak nem kell a hozzászólásokat tároló táblát piszkálnia, csak a tárolt eljárás nyújtotta API-hoz kell tudnia hozzáférni,a többit az eljárás intézi.
Az adatbázis triggerekkel az a baj, hogy a legtöbb relációs adatbázis event-driven modellje meglehetősen kezdetleges, nehezen összeegyeztethető a konkurens adatkezeléssel. Ezért is van az, hogy a kőegyszerű triggerekről továbblépve könnyen belefut az ember a susnyásba.
x gon' give it to ya
-
martonx
veterán
válasz fordfairlane #9922 üzenetére
Szívemből szóltál, csak én már inkább ráhagytam.
Én kérek elnézést!
-
válasz fordfairlane #9922 üzenetére
A csak tárolt eljárással való API-s megoldás nem jó, mert közvetlenül a tábla adatait szeretnéd piszkálni, akkor borul az egész. Triggerekkel maga az adatbázis önmagában is megáll, nem kell tudni semmilyen API-t, hogy jól működjön, mert elrejti a piszkos részleteket, it just works.
Na mindegy, én is befejezem, mert semmilyen előrelépést nem látok egymás álláspontjának megértésében. Valószínűleg azért, mert én az alkalmazás helyett a DB irányából közelítem meg a problémát, s ez a kettő gyökeresen más szemlélet.
(#9924) fordfairlane: Async trigger? Szerintem ez nagyon megkavarná a dolgokat. Mi lenne akkor a tranzakcióval? Tényleg tök más szemmel közelíted meg a dolgot.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
martonx
veterán
válasz fordfairlane #9924 üzenetére
Ezért is írtam valamivel feljebb, hogy az ilyen trigger szintű mókolás simán a komplett DB-t magával tudja rántani egy szerencsétlen deadlock esetén. Aztán az ember meg nézi, hogy de hát csak kiadtam egy ártatlan insert parancsot PHP-ben, mégis mitől omlott össze az egész DB.
Tényleg egyszer láttam már infinite loopba került triggereket is, amik egymást triggerelték. Na az se volt egy felemelő látvány.
De ez már lassan kezd átmenni sok beszédnek is sok az alja szintbeÉn kérek elnézést!
-
fordfairlane
veterán
A csak tárolt eljárással való API-s megoldás nem jó, mert közvetlenül a tábla adatait szeretnéd piszkálni, akkor borul az egész. Triggerekkel maga az adatbázis önmagában is megáll, nem kell tudni semmilyen API-t, hogy jól működjön, mert elrejti a piszkos részleteket, it just works.
Pont ezért nem hagyod, hogy közvetlenül írja a táblát. Ez egy kezdetleges OO egységbezárás, SQL módra.
x gon' give it to ya
-
válasz fordfairlane #9928 üzenetére
Ha már OOP, az ORDBMS mond valamit?
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
netpeti98
addikt
Sziasztok!
Juhász Tibor-Tóth Bertalan: Programozási ismeretek versenyzőknek című könyvével van valakinek tapasztalata? Jó lenne végre egy picit az algoritmizáláson is fejlesztenem.
-
Zola007
veterán
PERL 5.24
ebben a kis programban nem tudom mi a hiba:
a feladata, hogy beolvassa a fájl tartalmát, majd kiírja fordítva#!/usr/bin/perl -w
# Write a program to read a file, and then print its lines in reverse order, the last line first
$readfile = 'alphabet.txt';
open (ALPHABET, $readfile);
@alphabet = <ALPHABET>;
print "This is the English alphabet:\n\n";
print "@alphabet\n\n";
@reversealphabet = reverse @alphabet;
print "The reverse of the alphabet:\n\n";
print @reversealphabet;
close ALPHABET;
exit;Ezt kapom futás után, pedig a txt fájlban úgy szerepel mint a fehér részen:
[ Szerkesztve ]
Mʏ ᴘʜɪʟᴏsᴏᴘʜʏ ɪs: Iᴛ’s ɴᴏɴᴇ ᴏғ ᴍʏ ʙᴜsɪɴᴇss ᴡʜᴀᴛ ᴘᴇᴏᴘʟᴇ sᴀʏ ᴏғ ᴍᴇ ᴀɴᴅ ᴛʜɪɴᴋ ᴏғ ᴍᴇ. I ᴀᴍ ᴡʜᴀᴛ I ᴀᴍ ᴀɴᴅ I ᴅᴏ ᴡʜᴀᴛ I ᴅᴏ. I ᴇxᴘᴇᴄᴛ ɴᴏᴛʜɪɴɢ ᴀɴᴅ ᴀᴄᴄᴇᴘᴛ ᴇᴠᴇʀʏᴛʜɪɴɢ. Aɴᴅ ɪᴛ ᴍᴀᴋᴇs ʟɪғᴇ sᴏ ᴍᴜᴄʜ ᴇᴀsɪᴇʀ. - Sɪʀ Aɴᴛʜᴏɴʏ Hᴏᴘᴋɪɴs
-
Zola007
veterán
ha ütök egy entert a "aaaaaa" sor elé és a "hhhhhh" sor után, akkor működik
de hogy lehetne ezt beadni neki a programba, hogy enter nélkül is vegye figyelembe a dolgot?mert kiragadott/keresett szövegrészlettel is meg kell tudnom ezt csinálni és ott nem lesz aki entert ütögessen elé-után
[ Szerkesztve ]
Mʏ ᴘʜɪʟᴏsᴏᴘʜʏ ɪs: Iᴛ’s ɴᴏɴᴇ ᴏғ ᴍʏ ʙᴜsɪɴᴇss ᴡʜᴀᴛ ᴘᴇᴏᴘʟᴇ sᴀʏ ᴏғ ᴍᴇ ᴀɴᴅ ᴛʜɪɴᴋ ᴏғ ᴍᴇ. I ᴀᴍ ᴡʜᴀᴛ I ᴀᴍ ᴀɴᴅ I ᴅᴏ ᴡʜᴀᴛ I ᴅᴏ. I ᴇxᴘᴇᴄᴛ ɴᴏᴛʜɪɴɢ ᴀɴᴅ ᴀᴄᴄᴇᴘᴛ ᴇᴠᴇʀʏᴛʜɪɴɢ. Aɴᴅ ɪᴛ ᴍᴀᴋᴇs ʟɪғᴇ sᴏ ᴍᴜᴄʜ ᴇᴀsɪᴇʀ. - Sɪʀ Aɴᴛʜᴏɴʏ Hᴏᴘᴋɪɴs
-
racskobalazs
senior tag
Sziasztok! Magyarországon melyik programnyelvre van a legnagyobb igény? Nem tudom eldönteni, hogy melyikbe lenne érdemes belekezdeni. Most érettségiztem egy SZKI-ból ahol két év C# volt a prog tanulás, valamint érintőlegesen php. Melyik lenne a legjobb választás, ha a mai magyar keresletet nézzük? Illetve, mi lehet keresett a jövőben? Előre is köszönöm.
Az elmélet az, amikor mindenki tudja, de semmi sem működik. A gyakorlat az amikor minden működik, de senki se tudja miért. Az informatika az, amikor semmi nem működik és senki se tudja miért.
-
Jim-Y
veterán
válasz racskobalazs #9937 üzenetére
Jó, nem koca , javascript developerekre jelenleg nagy a kereslet. Ma azt mindenképp kifizetődő jól vágni.
-
martonx
veterán
válasz racskobalazs #9937 üzenetére
Egyrészt a C#-al jó irányban vagy. Másrészt ha webes fejlesztésekben kellene használni, akkor html/css/js valóban alapkövetelmény mellé. És ugyanez igaz a PHP-re is.
Én kérek elnézést!
-
fordfairlane
veterán
válasz racskobalazs #9937 üzenetére
A C# jó alap, erre akár egy ASP MVC tudást is fel lehet húzni.
x gon' give it to ya
-
racskobalazs
senior tag
válasz fordfairlane #9940 üzenetére
Köszönöm a válaszokat.
Akkor azt mondjátok, hogy ha már C#-ot kezdtem akkor folytassam is azt?Az elmélet az, amikor mindenki tudja, de semmi sem működik. A gyakorlat az amikor minden működik, de senki se tudja miért. Az informatika az, amikor semmi nem működik és senki se tudja miért.
-
martonx
veterán
válasz racskobalazs #9941 üzenetére
Szerintem érdemes. De a C#-nak rengeteg vetülete van a hagyományos desktop fejlesztésektől a cross-platform app fejlesztéseken keresztül a webfejlesztésig bezárólag. Szóval azért majd specializáld magad valamire, de az sem árt ha mindegyikkel megismerkedsz.
Én kérek elnézést!
-
kissbg
tag
Delphi programozó munka ha valakit érdekel, dobjon egy pivátot.
Üdv.
-
Zola007
veterán
Ezt meg lehet rövidebben vagy kevesebb változóval oldani (Perl 5.24)?
#!/usr/bin/perl -w
# Write a program that switches two bases in a DNA string at specified positions.
# Get the name of the file with the DNA sequence data
print "Please type in the sequence need to be modified: ";
$DNA = <STDIN>;
# Remove the newline
chomp $DNA;
# Get the base would like to change
print "Please type in which positions would like to switch?\n";
print " This position: ";
$pos1 = <STDIN>;
print "\n to this one: ";
$pos2 = <STDIN>;
# Remove the newline
chomp $pos1;
chomp $pos2;
# detect the bases at given positions to be modified
$base1= substr $DNA,($pos1 - 1),1;
$base2= substr $DNA,($pos2 - 1),1;
# change the bases among each other
$swap = substr $DNA,($pos1 - 1),1,$base2;
$swap = substr $DNA,($pos2 - 1),1,$base1;
print "The modified sequence is ",$DNA;
exit;[ Szerkesztve ]
Mʏ ᴘʜɪʟᴏsᴏᴘʜʏ ɪs: Iᴛ’s ɴᴏɴᴇ ᴏғ ᴍʏ ʙᴜsɪɴᴇss ᴡʜᴀᴛ ᴘᴇᴏᴘʟᴇ sᴀʏ ᴏғ ᴍᴇ ᴀɴᴅ ᴛʜɪɴᴋ ᴏғ ᴍᴇ. I ᴀᴍ ᴡʜᴀᴛ I ᴀᴍ ᴀɴᴅ I ᴅᴏ ᴡʜᴀᴛ I ᴅᴏ. I ᴇxᴘᴇᴄᴛ ɴᴏᴛʜɪɴɢ ᴀɴᴅ ᴀᴄᴄᴇᴘᴛ ᴇᴠᴇʀʏᴛʜɪɴɢ. Aɴᴅ ɪᴛ ᴍᴀᴋᴇs ʟɪғᴇ sᴏ ᴍᴜᴄʜ ᴇᴀsɪᴇʀ. - Sɪʀ Aɴᴛʜᴏɴʏ Hᴏᴘᴋɪɴs
-
Feruendios
aktív tag
válasz dangerzone #9048 üzenetére
Igen a Python volt/van az egyik legjobb nyelv statisztikai elemzésekre. Mostanában jönn föl az R language ami pontosan erre lett kifejlesztve.
Mérnőkként nem iOS aplikációt kell tudnod késziteni meg honlapot a fönöknek , hanem egy olyan programot/scriptet ami képes neked az adott számitást vagy vizsgálatott elvégezni.A Python egy sokoldalu nyelv és nem fognak rád bután nézzni, ha nekiálsz benne egy console applicationt összedobni.
Sajnos mar nincs magyar billentyuzetem :(
-
dabadab
titán
válasz Feruendios #9946 üzenetére
"Igen a Python volt/van az egyik legjobb nyelv statisztikai elemzésekre"
Statisztikus körökben mondjuk hagyományosan az SPSS használatos (nem mintha igazán jó lenne, viszont azt tudják használni )
DRM is theft
-
cattus
őstag
Hali!
Tudnátok ajánlani olyan oldalakat, ahol gyakorolhatnám az OO programozást? Arra gondolok, hogy kiad különböző feladatokat. A nyelv igazából mindegy, csak arra lenne szükségem, hogy feladatokat, problémákat állítson elém.
Do the thing!
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Revopoint POP 3 Kézi 3D Scanner Bolti-Fél áron!
- Eladó iPhone 7 Plus 256 GB Jet Black 100% akku, szép állapotú - 12 HÓ GARANCIA - R8039
- Eladó Leovo ThinkPad L580 notebook
- Bose Quietcomfort Ultra Wireless headset! Fél ár alatt!
- Sony A6000 ! 3600 EXPO! Legacélabb Szürke Legszebb Szín KIT 18-50mm Obi + Helios 44-2 58/2