NetAcademia

A legjobbakat tanítjuk!

Utolsó kommentek:

Meridian74 2024.04.18. 16:20:47

"Én egy senior SQL-fejlesztő vagyok. Már akkor sarokba lettem szorítva, amikor jött a Code First-megközelítés a dotnetben, de ez még hagyján, mert ha nagyon akartam, még mindig piszkálgathattam az adatbázist kézzel. Akartam is! Az az enyém! Az adatbázistervezést azonban ezzel réges-régen kicsavarták a kezemből, és én tudom is ezt, hisz ennek már vagy 5-6 éve."

Ez nem mindig igaz. Én ma futottam bele hoyg SQL tárolt eljárásokat kell átnéznem (kezdőként amúgy) és megemlítettem hogy de hát ez az üzelti logika pl miért nem az alkalmazásban van benne? A válasz: SAP SBO nem tudja. Van egy egyszerű primitív felület és az hivogatja meg ezeket a eljárásokat. :P Hát ennyi. Egy egyszerű Spring Data is egyszerűbbé és átláthatóbbá tené az egészet...

Bejegyzés: Junior-e a senior? Avagy mit tudhat a junoir, amiről fogalma sincs a seniornak?

Vaki Vaki 2018.09.11. 17:11:38

Csak félő, hogy a tempó növelése (és most nem az üresjáratok leépítését értem) oda vezet, hogy az elvi alapokat nem ismerjük, ok-okozat, mi miért történik nem értjük, de sok szép csillogó felszínes varázslatot mutatunk.

Bejegyzés: Gyorsítsuk fel az oktatást a tízszeresére!

Teszt.Elek 2018.06.07. 10:13:27

Érdekes bejegyzés, de alapjaiban ment félre szerintem, mivel összemossa a technológiai tapasztalatot a szenioritással.

Persze van korreláció, de csak közvetett. A senior fejlesztő több technológiát ismer magas szinten, mert esélyesen több technológiával volt már dolga a karrierje során. Ez nem jelenti azt, hogy ne lehetne nála sokkal fiatalabb, tapasztalatlanabb junior, aki SME (subject matter expert) egy adott területen, amihez a senior hozzá se szagolt még.

Mi a különbség köztük? A senior általában a szélesebb tech háttere miatt még az ismeretlen területekkel is viszonylag gyorsan megbirkózik és pusztán az ismert technológiák interpolációjából képes következtetni az új technológia bizonyos elemeire.

Még fontosabb a különbség a nem szigorúan hard skillek terén. Pusztán a tapasztalata miatt egy senior fejlesztő sok olyan hibát el tud kerülni, amit egy junior elkövet, egyszerűen azért, mert már találkozott az adott helyzettel és tudja miképp kell helyesen kezelni.

Szóval amikor egy cég senior embert keres, akkor nem a tech skillek kellenek a cégnek, hanem az a tapasztalat és érettség, amelyet csak a ledolgozott évek tudnak megadni valakinek.

Bejegyzés: Junior-e a senior? Avagy mit tudhat a junoir, amiről fogalma sincs a seniornak?

OKalman 2018.06.06. 12:52:50

Jézus, Mária! Nem biztos, hogy akarnék egy ilyen rendszert kapni miután elmennek az "okos" juniorok máshova dolgozni.

Bejegyzés: Junior-e a senior? Avagy mit tudhat a junoir, amiről fogalma sincs a seniornak?

444Hz (törölt) 2018.05.31. 02:25:23

@midnightcoder2: úgy tűnik, jobb ha éjjel keresgélek. Azt hiszem, valami ilyesmi volt, amit nem találtam már napok óta: en.wikipedia.org/wiki/Levenshtein_distance - és azért nem jegyeztem meg, mert a matematikai részletek már meghaladják a képzettségemet. :)

Bejegyzés: Mondom is, miért C#

444Hz (törölt) 2018.05.31. 01:58:20

@midnightcoder2: mondom, a log az csak egy példa volt, magát az elméletét keresem ennek az egésznek, nem a konkrét megvalósítást. Erősen feltételes módban talán a szövegbányászat keretein belül láthattam ilyet, talán valami statisztikai algoritmusok alkalmazásáról cikkben vagy valami más hasonló helyen, csak rácsodálkoztam, hogy "jé, hol tart már a tudomány", de akkoriban csak annyira érdekelt a téma, hogy átfutottam pár cikket, anélkül, hogy mélyebb nyomot hagyott volna bennem. Mindegy, nagy jelentősége nincs a dolognak, inkább csak a kíváncsiság hajt most is.

Bejegyzés: Mondom is, miért C#

midnightcoder2 2018.05.30. 12:20:00

Ez azért már elég egyedi probéma. Valahogy definiálni kell, hogy mi az ami érdektelen és mi az ami nem. Én valahogy definiálnám az érdektelen részeket mondjuk regexp-pel, és a maradékot vizsgálnám.

Bejegyzés: Mondom is, miért C#

444Hz (törölt) 2018.05.30. 09:37:47

@midnightcoder2: az előtő laptopomon nekem is csak virtualboxban volt. De csak azért, mert a hardver nagy részéhez csak windows driver volt. :)

Ha már ilyen kedélyesen elbeszélgetünk itt: nincs tipped, hogy ha szövegfájlokban hasonló sorok kiválogatása lenne a cél, akkor milyen eszközt keressek? Úgy értem, szövegfeldolgozáson belül mit?
Életből vett példa: linux logok, amiből ki akarom szűrni az rendszeresen előforduló sorokat, hogy csak a ritkán megjelenő, esetleg fontos sorok maradjanak. Amíg azonosságra kell keresni, addig nincs gond, de itt ugye van olyan, hogy "... DROP IN=eth0 ..." ebből van rengeteg és az esetek nagy részében érdektelenek, de a sorban a többi paraméter változik. Milyen eszköz kell az ilyen jellegű feladatokra? Általánosságban érdekel, nem konkrét framework vagy kész rendszer. Nincs valami tipped?

Bejegyzés: Mondom is, miért C#

midnightcoder2 2018.05.30. 08:17:10

@444Hz: Ja, az igazság az, hogy jelenleg Linux csak virtualboxban van a gépemen.

Bejegyzés: Mondom is, miért C#

2018.05.28. 11:38:33

@midnightcoder2: akkor bocs, csak a C:\ valahogy nem jellemző linuxon/unixon ;)

Ami különbség itt van, az pont a lényeg számomra. Épp az volt a fontos, hogy a használt nyelv mennyivel lassítja a dolgokat és ez elég jól kijött. Bár az érdekes, hogy a System idők is elég eltérőek. (a User lenne amit a program önmagában művel)

Bejegyzés: Mondom is, miért C#

midnightcoder2 2018.05.28. 09:51:11

@444Hz: De, tudom mi az a proc fájlrendszer, lásd 2018.05.27. 10:37:47-as hsz-em.
De a nyelvek szempontjából ez kb. mindegy, az alján jó eséllyel kb. ugyanaz a glibc-s függvényhívás lesz, mert hogy fájlként kezeljük. Ami különbség itt lehet az max. az ami e fölött van.

Bejegyzés: Mondom is, miért C#

2018.05.27. 20:09:15

@midnightcoder2: még csak nem is igazán a fájlrendszert. Jól sejtem, hogy a linux nem a te világod? :) Csak a 'C:\proc' miatt... A /proc egy virtuális fs, ahonnan a futó processzek adatait, meg pár egyéb, a rendszerhez kapcsolódó infót lehet lekérdezni I/O műveletekkel (ami többnyire kimerül az open/read/close trióban)
Ha a keretrendszer-kezdeményt nem számolom, akkor esetemben épp qz volt a cél, hogy felmérjem, a procfs kezelése elfogadható sebességgel megy-e pythonban, aztán jött mellé pár, más nyelven megírt teszt, előbb csak azok, amikkel én is boldogulok, később meg néhány öncélú, a közönség reklamációjára :)
Az általános célú benchmarkokban meg csökönyösen nem hiszek.

Bejegyzés: Mondom is, miért C#

midnightcoder2 2018.05.27. 17:06:38

Igazából mint mondtam, ez a teszt nagyjából csak a fájlrendszer elérésének a sebességét méri.
A fenti link amit beküldtem ennél picit szofisztikáltabb, de már nem annyira jó mint régebben amikor még tudott nyelveket hasonlítani azonos környezetekben.

A valósághoz kb. szerintem ez áll a legközelebb:
www.bioinformatics.org/benchmark/results.html

Vagy ez:
jaxenter.com/energy-efficient-programming-languages-137264.html

De ezek a tesztek mindig elég szubjektívek. Ha egy adott nyelvben egy adott művelet mögött egy, az adott dologra tökig optimalizált assembly kód áll, azt nyilván elég gyorsan fogja végrehajtani. Ha a teszt erre az egy dologra van kihegyezve, akkor az adott nyelv lesz a hegyek királya. Ugyanakkor a valós életben lehet, hogy ezt az adott műveletet 10 évente egyszer hívja meg a programod, és az adott nyelv minden másban viszont rohadt lassú.

Bejegyzés: Mondom is, miért C#

2018.05.27. 12:54:13

@444Hz: elkészült a nagy mű, azért én jóval többet vártam tőle. :(

Test: C#
User: 16.466179 System: 23.702187
User: 16.070435 System: 24.058626
U.avg: 16.268307 S.avg: 23.8804065 Total avg: 40.1487135

Test: C2
User: 2.295852 System: 14.594102
User: 2.239189 System: 14.7084
U.avg: 2.2675205 S.avg: 14.651250999999998 Total avg: 16.9187715

Test: Python3
User: 48.672912 System: 25.718156
User: 47.647527 System: 26.004727
U.avg: 48.1602195 S.avg: 25.861441499999998 Total avg: 74.021661

Test: Python2
User: 15.005631 System: 19.443078
User: 16.223801 System: 22.943473
U.avg: 15.614716000000001 S.avg: 21.1932755 Total avg: 36.8079915

A C2 azért 2, mert egy optimalizált, az én verziómnál gyorsabb kódot futtat. A python2 és 3 azonos kód, azon nagyon látszik, hogy mennyivel gyengébb e téren a 3-as. Viszont az, hogy a C# kb. a python2-vel van egy szinten, cseppet elkeserít. Valahogy arra számítottam, hogy közelebb lesz a natív C-hez.

Bejegyzés: Mondom is, miért C#

2018.05.27. 12:42:29

@444Hz: ez legalább gyorsan megoldva. Kicsit (nagyon) rosszul látok, nem tűnt fel, hogy hiányzik a run a paraméterek közül.

Bejegyzés: Mondom is, miért C#

2018.05.27. 12:40:43

@midnightcoder2: hát ezzel még dolgozni kell, mert nem pont úgy működik a dolog, ahogy elképzeltem, pl. a dotnet pythonból indítva nem igazán akar működni. :)
Parancssorból O.K., de ha beírom a paraméterfájlba és indítanám a saját keretemmel, akkor már csak egy helpet dob.

Bejegyzés: Mondom is, miért C#

2018.05.27. 12:08:03

@midnightcoder2: triviális nálam úgy néz ki egy ilyen helloworld színvonalú kódnál, hogy <fordító> <forrás> :)
Ezért mondtam, hogy nem annyira triviális a dolog.

Bejegyzés: Mondom is, miért C#

midnightcoder2 2018.05.27. 11:59:14

A kód elejére azért kell olyan, hogy

using System;
using System.IO;
using System.Linq;

Bejegyzés: Mondom is, miért C#

midnightcoder2 2018.05.27. 11:57:44

Elég triviális. Felteszed a .net core-t, csinálsz egy könytárat, belépsz, azt mondod dotnet new console, a program.cs-be beteszed a kódot, majd azt mondod hogy dotnet run

Bejegyzés: Mondom is, miért C#
süti beállítások módosítása