Egy áttekinthető cikk open source .NET library portolásáról .Net Portability Analyzer segítségével .NET Core-ra, példakóddal.
Mit is jelent pontosan a sikertelenség?
A CHAOS jelentés szerint (2002-ben) mindössze a projektek 34%-a sikeres.
A Standish Csoport CHAOS jelentése sok millió IT projektekre elvesztegetett dollárról beszél évek óta. A 34% egyébként a 2001-es 28%-hoz képest még növekedett is. De mit is jelent valójában a sikertelenség??
A chaos jelentés definíciója szerint egy projekt határidőig befejezve, a költségvetést nem túllépve és a legtöbb várt funkcionalitást megvalósítva jelent sikeres projektet. De ez egészen biztosan a siker definíciója? Miután a Windows 95 rettenetes késéssel jött ki a Microsoftot azért üzletileg nagyon sikeressé tette.
Amikor azt mondjuk, hogy egy projekt elbukott, mert túl későn lett kész, vagy kifutott a költségkeretből, én azt javasolnám, hogy ilyenkor inkább mondjuk azt, hogy a tervezés bukott el. Vagyis, a CHAOS jelentés nem a szoftverfejlesztési projektek bukásának, hanem a projekttervek bukásának a története.
Akkor mi számít sikernek? Ha tudnánk mérni, akkor a válasz a befektetésarányos megtérülés lenne. Sajnos ez a következő, amit nem tudunk mérni (ld. a produktivitás nem mérhető). Végülis ehhez az üzleti elégedettség érzetét kéne megfelelő módon összemérni a projekt költségeivel. Ez így talán egy nem kielégítő meghatározás, de sok üzleti aktivitás egyszerűen így működik. Máskülönben a számítogépek lennének a cégvezetők.
Python, Haskell, J, Mel, SQL, C#, C++ és még egy csomó nyelven ugyanaz a feladat elkészítve
A feladat: Olyan programot írni, ami ezt a kimenetet eredményezi:
Smile!Smile!Smile!
Smile!Smile!
Smile!
Homework Question: How do I write a program that produces the following output?
A produktivitás nem mérhető
Rengeteg érzelemmel telített vita zajlik a fejlesztési módszertanok, tervezési gyakorlat és hasonló témák körül. A legtöbb ilyen konfliktust lehetetlen feloldani, mivel az iparágban hiányzik a képesség a szoftverfejlesztés hatákonysági alapelemeinek a mérésére. A termelékenység mérésére például nincs ésszerű módszerünk.
A termelékenységet józan paraszti ésszel valahogy úgy lehetne meghatározni, hogy megnézzük, hogy a bemeneti tevékenységek milyen kimeneti eredményeket produkálnak. Vagyis ahhoz, hogy mérjük a fejlesztés termelékenységét mérnünk kell az eredményt. És itt a baj, ugyanis az eredményt nem tudjuk mérni.
Ez természetesen nem azt jelenti, hogy még nem próbálta senki. A legjobban azok a tanulmányok zavarnak, amik a termelékenységet a leírt kódsorok száma alapján próbálják mérni. Először is, különböző programnyelvek léteznek, különböző kódolási stílussal valamint formázási megszokásokon alapuló különbségekkel. De tegyük fel, hogy a kezdetektől következetesen mérünk, ugyanazt a nyelvet és automatikusan ugyanolyan kódolási stílust használunk - nos, a sorok száma ekkor sem megfelelő arra, hogy a kimenetünket mérjük vele.
Minden jó fejlesztő tudja, hogy ugyanazt a dolgot rengeteg féle képpen lehet megvalósítani, ráadásul, azok a kódok, amik jobban vannak tervezve általában rövidebbek, mert például a duplikációkat kiszűrik a kódból. Fordítva, a másolás és beillesztés programozási módszer pedig rossz tervezéshez és magasabb számú sorhoz vezet, ugyanis gyártja a többszörözést. Ezt be is tudjuk bizonyítani olyan refactoring eszközzel, ami támogatja az egysoros függvény és a függvény kivonat használatát. Ha ezt a gyakori eljárásoknál jól és ügyesen használjuk, simán meg tudjuk duplázni a kódsorok számát.
Gondolhatnánk, hogy a kódsorok száma alapú mérések mára már kihaltak, de nem. Minden hónapban találkozhatunk erre alapuló termelékenységi tanulmányokkal - még az olyan köztiszteletben álló folyóiratoknál is mint az IEEE, pedig nekik ezt már tudniuk kellene.
Ez persze nem jelenti azt, hogy a kódsorok száma teljességgel használhatatlan. Jól tudja például jelezni egy redszer méretét. Az azért valószínű, hogy egy 100.000 soros rendszer nagyobb, mint egy 10.000 soros. De ez csak becslés, ha én írok egy rendszert 100.000 sorból, a munkatársam Joe pedig megírja ugyanazt 10.000 sorból az nem tesz engem produktívabbá. Valójában inkább azt a következtetést lehet levonni ebből, hogy a termelékenységünk nagyjából azonos, de az én rendszerem sokkal rosszabbul van tervezve.
Egy másik megközelítése a témának, ha a kimenetet a funkciópontok számával jellemezzük. Ez számomra már egy kicsit szimpatikusabb, de még mindig nem meggyőző. Ebben mondjuk az sem segít, hogy hallottam olyan történetet, amiben egyetlen rendszer különböző pontszámai között egy hármas szorzó volt, persze ugyanazt az elemző rendszert használva.
De még ha precízen tudnánk is számolni a funkciópontokat, azt hiszem akkor is elhibáznánk a termelékenységi mérést. Azt nyilván mondhatjuk, hogy a funkcionalitás mérése egy módszer a szoftverfejlesztés közvetlen kimenetének a vizsgálatához, de a valódi kimenet azért egy kicsit más. Tegyük fel, hogy van egy precíz funkciópont mérési rendszerünk. Ha például én egy évben leszállítok egy 100 funkciópontos rendszert, Joe pedig egy 50 pontosat, akkor vajon feltételezhetjük-e, hogy az én termelékenységem magasabb? Azt mondanám, hogy nem. Az is lehet például, hogy az én 100 pontomból csak 30 olyan funkcionalitás van, ami ténylegesen használható is a vásárlómnak, amíg Joe 50 pontjából mindegyik használható. Ez inkább azt jelenti, hogy bár az én nyers, közvetlen termelékenységem magasabb, Joe valódi, használható termelékenysége a jobb.
Jeff Grigg arra hívta fel a figyelmemet, hogy belső tényezők is számítanak az egyes funkciópontok szállításakor. "Az én 100 pontom feltűnően hasonló funkcionalitást takar, és elvitt egy évemet, mivel nem sikerült megfelelő szintre emelnem menet közben a kód újrafelhasználást. Joe 50 pontja feltűnően különbözik (ez volt számára a rossz hír). Gyakorlatilag semmilyen újrafelhasználás nem történt. De annak ellenére, hogy 50 látványosan különböző funkciót kellett megvalósítania, és semmilyen újrafelhasználást ehhez nem tudott kialakítani, mindössze 1 év alatt elkészült vele. Szóval Joe egyszerűen fantasztikus,"
De mindez teljességgel figyelmen kívül hagyja, hogy még a használható funkcionalitás sem jelenti a jó mérőszámot. Például, ha én 30 használható funkciópontot gyártok, Joe pedig 15-öt, de valaki rájön, hogy az ő ügyfelei 15 millió dollár extra profithoz jutottak ezáltal, míg az én munkám csak 5 millió dollárhoz vezetett. Ismét azt kell mondanom, hogy Joe valódi produktivitása nagyobb, hiszen több üzleti értéket szállított - és egyben ráébreszt, hogy a szoftverfejlesztés valódi termelékenységét mérő adatoknak a leszállított, üzletileg értékes dolgokon kellene alapulnia.
Ezek a gondolatok elvezetnek a sikeresség vizsgálatához. Általánosságban megállapítani egy szoftver sikerét nehéz ügy, mivel az emberek nem értik, mit is jelent pontosan a sikertelenség. Érvelhetek úgy, hogy a sikeres projekt az, ahol több üzleti értéket szállítok, mint amennyibe került a projekt. Rendben, akkor mi van, ha Joe is és én is öt projektet vezetünk, én sikeres vagyok néggyel, Joe pedig eggyel - most végre sikeresebb vagyok, mint Joe? Nos, nem feltétlenül. Ha az én négy sikeres projektem egyenként 1 millió dollár nyereséget hoz, de Joe az egy sikeres projekten 10 millióval több bevételt termel, mint amennyibe került az összes projektje, akkor bizony őt kell ünnepelni.
Így hát vannak olyanok, akik azt mondják, hogy amit nem tudsz mérni, azt nem is tudod kezelni. Vagyis, dobjuk el az összes szabályt. Az üzleti szereplők valójában folyamatosan kezelnek megmérhetetlen dolgokat is. Hogy méred meg egy céges jogász produktivitását, a marketing osztályét vagy éppen az oktatási intézményekét? (erről bővebben itt olvashatsz: Robert Austin
Ha egy csapat hatékonyságát nehéz megmérni, akkor sokkal nehezebb megmérni a csapatot alkotó egyének együttműködését. Figyelheted erősen a csapat által fejlesztett funkcionalitások számát fejlesztési ciklusonként. Ez nyers értelmezés, de érzékelheted, hogy melyik csapat gyorsult fel, vagy érzékelheted, ha egyik csapat sokkal gyorsabb, mint a másik. De egyének közreműködését sokkal nehezebb értékelni. Amíg egyes emberek az egyes funkcionalitások fejlesztéséért felelősek, a többiek támogató szerepet játszanak - másoknak segítenek a funkciókat megvalósítani. Az ő közreműködésük nagyon is számít a teljes csapat termelékenységében - de nagyon nehéz megérteni az ő személyes teljesítményüket, anélkül, hogy a csapatban dolgozó fejlesztő lennél.
És ha ez az egész még nem lenne elég bonyolult, az Economist (2003. szeptember 13-19) közzétett egy cikket a produktivitással kapcsolatos trendekről. Ebben az állt, hogy az újságírók már látják, hogy a 90-es években a termelékenység növekedett az informatikai beruházásoknak köszönhetően. A lényeg azonban az, hogy a növekedés időben lemaradva követi a beruházásokat: "Az informatikai beruházások nem automatikusan növelik a produktivitást; az üzleti gyakorlatot is át kell szervezni ehhez". Ugyanez az időeltolódás történt az elektronikába történő beruházásokkor.
Tehát nem csak az üzleti értéket mérése nehezíti az életet, hanem még az időeltolódást is. Vagyis, talán a csapatod termelékenységét egészen addig nem fogod tudni jól megmérni, amíg el nem telik néhány év az általuk fejlesztett szoftver kiadását követően
Teljesen érthető, hogy a termelékenység mérése miért olyan csábító cél. Ha tudnánk ilyet, akkor sokkal könnyebben értékelhetnénk a szoftvereinket, mint ahogy most ezt meg tudjuk tenni. De egy rossz mérés csak még rosszabbá teszi a dolgokat. Ezért szerintem érdemes beismernünk, hogy milyen tudatlanok is vagyunk e területen valójában.
Ami a felhőből megmaradt, könnyen köddé válhat
És akkor íme a beígért pentest, Arányi Gábor "tollából". Hangsúlyozottan etikus hekk, Gábor engedélyt kért a hálózatunk szétbuherálására.
Mottó: hogyan menjünk be a NetAcademia hálózatára? Először azért jöjjön a mentegetőzés: hát ez azé' mer azé'... vagyis ... nincs mentség! Nyitvahagytunk ezt és azt, valljuk be. A mentegetőzést így lezárva innentől a pentestet publikálom.
************************** Pentest by A.G. ***********************
Ahogy ez a legtöbb internetes kapcsolatban lenni szokott, egy e-maillel kezdődött minden...
Remek! Nyissuk meg!
Van egy IP címünk. Nézzük meg, hogy kihez tartozik, illetve van-e még ott ahonnan ez jött? Whois.sc:
Hányan lehetnek élők, avagy hányan pingelhetők? Természetesen hping-gel tovább finomítható az eredmény.
fping -g 195.70.46.96 195.70.46.111
Vannak live hostok, de a 195.56.20.177-ről vajon mit lehet tudni?
Tehát 195.70.46.96, 195.70.46.111 nem játszik. Később kiderült, miért nem. Hálózat és broadcast címek.
Nézzük szépen sorban!
195.70.46.100
-ping megy WAN oldalról, tehát lehetne ping of death, de az olyan hangos és oldschool...
Nézzünk egy half open scant, de IP-t nem rejtünk (pl.: proxychains, decoy scan, idle scan), időből meg kevés van, ezért nincs -T:
21-es port:
Ez jó lehet... Keressünk rá exploitot!
Az első a kernel verzió (előző nmap) miatt biztosan nem jó.
A második működhet, ha a pure-FTP autentikációját külső modul végzi. Metasploit konzolon keressük meg az említett exploitot!
Nézzük meg az opciókat, paraméterezzük és indítsuk is el a támadást!
Úgy néz ki, ez most nem jött össze. Valószínűleg default az autentikáció kezelése (pure- authd). Nem törünk le, nézzük tovább!
81-es port:
Ha tényleg IIS 8.0 a kiszolgáló, akkor a következő recept hatásos lehet: MS15-034 - Denial of Service (DoS) and/or Remote Code Execution (RCE)
Rövid teszt, amiben megpróbáljuk Range headeren keresztül rávenni a kiszolgálót, hogy 18446744073709551615 bájtnyi adatot adjon át nekünk. Ez láthatóan nem sikerül neki.
Ezt kerestük! Hajrá:
wget --header="Range:bytes=18-18446744073709551615" http://195.70.46.100:81/iis-8.png
A várt hatás nem marad el:
Természetesen az egysoros wget beletehető egy for ciklusba és tetszőleges ideig futhat...
Amint helyreállt az IIS (előzőleg összeomlott és újraindult) körbenézünk. OWASP Dirbuster:
Nézzük a tartalmát!
Hasznos holmi...
************************** Pentest by A.G. ***********************
Na jó, elsőre elég ennyi horror. Folyt. köv. sajn. os.
PowerShell logging aka PowerShell Transcript Windows Server 2016-ban
Bizonyára sokan elgondolkodtunk már azon, hogy egy Windows szerveres környezetben milyen jó is lenne, ha a korábban kiadott PowerShell utasításokat valamilyen módon vissza lehetne nézni, a hab a tortán már csak az lenne, ha az eredményt, kimenetet, hibákat is lehetne látni később bármikor. A habot pedig tovább is lehetne ízesíteni azzal, ha ezt mondjuk az összes gépen meg lehetne valósítani, az élményt esetleg lehetne fokozni azzal, ha mindezt néhány kattintással meg lehetne oldani, az pedig már a kulináris élvezet mesterfokát is túlhaladná, ha ezt az infót egy központi helyen is lehetne tárolni.
Na, lássuk a hozzávalókat:
1. PWS "log" készítése --> PowerShell Transcipt
2. Megvalósítás az összes gépen, néhány kattintással --> GPO
Mint minden jó szakácskönyv elején a "végy egy tejszínhabot" kijelentést itt a "végy egy Windows Server 2016-ot, vagy tölts le egy TP5-öt"-re lehetne fordítani.
És akkor a recept:
1. Készítsünk egy megosztott könyvtárat valamelyik szerverünkön. A megosztási engedélyekhez "elég" az Everyone --> Change. A Security fül pedig mindenkinek a saját ízlése szerint állítandó (ahogy ugyebár a csipet só is kérdéses sokszor, hogy vajon mennyi is pontosan). Azt javaslom, hogy azért nem árt, ha a System és mondjuk az adminok (bármilyen szintű adminra lehet gondolni) hozzáférnek legalább módosítással, az OSI modell 8. rétege (= normál userek) pedig nem kap engedélyt, hiszen nem is kell neki onnan semmi.
2. Csoportházirend készítése. Csináljunk egy "PowerShell Settings" nevű GPO-t és linkeljük a domainhez. Ezzel meg is oldottuk azt, hogy az összes gépről működjön a logging, már csak a beállítások megadása van hátra.
A létrehozott GPO-ban a Computer Configuration\Policies\Administrative Templates\Windows Components\Windows PowerShell konténerben találunk egy Turn on PowerShell Transcription részt, amit állítsunk Enabled-re, majd az output directorynál adjuk meg az első lépésben megosztott könyvtárunk UNC útvonalát.
3. Innentől már csak a csoportházirend érvényesülését kell megvárni (ha órabérbe dolgozunk), vagy a jól ismert gpupdate /force parancsot kiadni (ha viszont teljesítménybérezés van). Nekem egy újraindítás kellett azért, de vélhetően csak türelmetlen voltam, az igazán türelmesek (akik addig simogatják a vasmacskát is, amíg dorombolni nem kezd) kipróbálhatják újraindítás nélkül is.
4. Próbálkozzunk valamilyen PowerShell utasítással. Lehet először azon a szerveren, ahol a megosztást csináltuk, hogy kiderüljön, egyáltalán működik-e a beállításunk, aztán lehet nézelődni a többi szerveren (vagy akár kliensen) is.
Aztán már csak a puding próbája maradt, jelen esetben a logfájlok vizsgálata. Ha elnavigálunk a megosztott könyvtárba, akkor máris láthatóak lesznek a rendszer által létrehozott text fájlok
Ezekben, ha szerencsénk van, akkor a PowerShell ablakból kiadott parancsokat találjuk, kimenettel, hibákkal, mindennel együtt. Ja, lesz egy fejléc is hozzá. Ja, és elég részletes infót is ad. Ja, és tényleg látszódik minden. Ja, és mi van, ha mondjuk nem a Get-Service parancsot írom, hanem mondjuk egy egyszerű dir-t. Az ment volna vajon? Ki kell próbálni, a lényeg, hogy PowerShellből futtassuk a dir-t is.
Mi a különbség az egyes .NET változatokban?
3 részes cikksorozat példákkal és példakódokkal az egyes .NET változatokban megjelenő új funkcionalitásokról és különbségekről.
.NET Backward Compatibility – Part 1
ASP.NET Core alkalmazásba LinkedIn bejelentkezés integrációja
Egy kimerítően részletes cikk a kezdetektől a végéig.
Az Async/Await egy jó eszköz, de erre érdemes figyelni!
A RavenDB fejlesztőjétől egy forráskód és magyarázat, mikor NEM érdemes async/await kódot használni.
Gyakorlatok az ASP.NET Authorization használatához
A Microsoft az ASP.NET Identity-t kínálja a webes felhasználók azonosításához. Ha azonosítottuk a felhasználót, akkor a következő lépés a jogosultságkezelés. Vagyis, elérni, hogy mindent elérjen, amire van engedélye, és semmit, amire nincs. Ezt a témakört járják körül a kövektkező gyakorlatok:
ASP.NET Core Authorization Lab