A cikk megmutatja, hogy az ImputFormatter/OutputFormatter segítségével hogy lehet C# POCO osztályokat CSV adatokká és onnan vissza konvertálni.
IMPORT AND EXPORT CSV IN ASP.NET CORE
A cikk megmutatja, hogy az ImputFormatter/OutputFormatter segítségével hogy lehet C# POCO osztályokat CSV adatokká és onnan vissza konvertálni.
IMPORT AND EXPORT CSV IN ASP.NET CORE
(Martin Fowler segít a témában tisztán látni.)
Képzeljük el a következőt: egy meglévő rendszerhez hozzá kell adni egy új dolgot. Ilyenkor általában két irányban indulhatunk el. Az egyik megoldást gyorsan tető alá tudjuk hozni és a végeredményül kapott kód meglehetősen rendetlen lenne. Így biztosak vagyunk benne, hogy nehezen karbantartható kódot eredményezne. A másik megoldás egy tiszta tervezés eredményéül kapott jól áttekinthető kód és az első megoldásnál jelentősen tovább tart megvalósítani.
A műszaki adósság egy csodálatos hasonlat, szerzője Ward Cunningham (Itt egy videó is). Segítségével új nézőponton keresztül gondolkodhatunk erről a problémáról. Ebben a hasonlatban tehát elvégezzük a tűzoltást olyan gyorsan, ahogy tudjuk, és ezzel műszaki adósságot veszünk a nyakunkba. És bizony ez az adósság bizonyos szempontból hasonlóan viselkedik, mint egy pénzügyi kölcsön felvételével járó adósság. A kölcsönfelvételhez hasonlóan a műszaki adósságunknak is ára van, kamatot kell majd fizetni: abból a pluszmunkából adódik, ami a későbbi fejlesztések során jelentkezik, és az oka bizony a tűzoltásként létrehozott kód.
Ennek tudatában több lehetőségünk van. Dönthetünk úgy, hogy folyamatosan fizetjük ezt a kamatot, vagy dönthetünk úgy is, hogy refaktoráljuk a kódunkat: a tűzoltást újratervezzük majd implementáljuk. Így tulajdonképpen megfizetjük a minket terhelő adósságot. Természetesen elő is törleszthetünk: csak az adósság egy részét fizetjük ki, ezzel a további kamatterheket csökkentjük.
A hasonlat azt is segít megérteni, hogy a tűzoltás miért veszélyes bár érthető megoldás. Egy hitelfelvétel segítségével ki lehet használni egy adódó üzleti lehetőséget. Hasonló módon, annak érdekében, hogy teljesítsenek fontos határidőket a fejlesztők is felhalmozhatnak műszaki adósságot. Ezzel kapcsolatban a leggyakoribb probléma az adósságcsabda: a fejlesztők elvesztik az irányítást a műszaki adósságuk felett, így a jövőben fejlesztési kapacitásukat megbénítják a kamatfizetési kötelezettségek.
A furfangos része természetesen a műszaki adósságnak az, hogy a pénzhitellel ellentétben ezt nem lehet hatékonyan mérni. A kamatfizetési kötelezettség persze lehúzza a csapat hatékonyságát. És mivel a hatékonység nem mérhető, így műszaki adósságunk hatása valójában felmérhetetlen.
Könnyű elfelejteni, hogy adósság által pénzt csak úgy termelhetünk, ha bármibe is fektetünk, a végén terméket vagy szolgáltatást készítünk és azt el is adjuk. A legnagyobb költsége a műszaki adósságnak az a tény, hogy lelassít minket, ugyanis gyengíti a jövőben szállítandó fejlesztések előállításához szükséges képességünket. Tehát járulékos költségként fennáll az a lehetőség is, hogy ez még további bevételkiesést eredményez végül. Ha elfogadjuk a tervezés stabilitásának elvét, akkor a tűzoltással az előtt kell elkészülnünk egy-egy szállítandó egységgel, mielőtt elérjük a jól tervezett megoldáshoz szükséges időkeretet, hiszen csak így lesz esélyünk az adósságból előnyt kovácsolni. De a műszaki adósság begyűjtése gyakran olyan mértékben lelassíthatja a fejlesztő csapatot, hogy képtelen lesz időben szállítani.
A műszaki adósság számos különböző forrásból származhat, ezek közül van ami hasznos és van ami nem. Ennek leírására a műszaki adósság négyszögét használom.
(Amennyire meg tudom mondani, Ward ezt az elgondolását először az 1992-es OOPSLA-ra készített élménybeszámolójában mutatta be. Ezen kívül egy ehhez kapcsolódó vitát is folytatott a wiki-jén.)
Az eredeti cikk: Technical Debt
A cikkben hivatkozott érdekesebb cikkeket (a hatékonység nem mérhető, a tervezés stabilitásának elve, a műszaki adósság négyszöge) terveink szerint a jövőben itt a blogon lefordítjuk majd.
Tiszta erőből nyár
Hidd el, sajnálom, hogy most is dolgozol. Most a kollégáid vannak a strandon, Te majd csak ezután mész. Vagy már voltál és akkor már a karácsonyi szabit várod.
Feltűnt nekem, hogy az apukák a strandon sokszor viszik a gyereküket is a csapolt-sörös pulthoz. A gyerek ilyenkor csurom vizesen, lila szájjal, kacsás úszógumival a derekán visít a sorban, hogy már menne vissza a vízbe. Az apuka hajthatatlan. Szegény gyermek nemcsak végigállja a sort, de meg kell hogy várja még azt is, ahogyan apuka komótosan lehúzza a habzó sört.
Apuka rendszergazda. Biztos az. Nagyon jól tudja azt, hogy mit is ír a CISSP-könyv a védelemről. Időben állandóan valósul meg. Nem lehet otthagyni a gyereket egyetlen percre sem a medencében, így hát nincs mit tenni, vinni kell sörözni is.
Már csak azt nem értem, hogy a nyári szabadságok idején miért hallom annyiszor, hogy:
- Ezzel várjuk meg a Bélát! Ezt ő csinálja.
- Akkor lehet, hogy a héten nincs is backup? – kérdezem.
- DeEeEe, vaAaAan. – nyávogják kórusban a többiek, de mindenki tudja, hogy nincs.
A gyerekére Béla biztosan jobban vigyázz. Lehet, hogy pont őket láttam a strandon? A következő CISSP tréningen is biztos ott lesz. Sörözni ugyan csak a vizsga után fogunk, de minden olyan dolgot megtanulunk majd a védelemről, amit ma még csak ösztönösen teszünk.
Egy jó kis tutorial, hogy hogy is kell használni.
A weboldala: gunDB
Robotika GO nyelven és 18 platformon
Robotika Ruby alapokon, 15 platformon
Végül, de nem utolsó sorban, JavaScript is van a tarsolyban, támogat 43(!) különböző fizikai platformot:
Időről időre felbukkannak hírek, amelyekben nagynevű biztonságtechnikai cégek ordas biztonásgi hiányosságairól olvashatunk. Mivel a biztonsági hibák 100%-ban emberi hibák, és mivel minden cégnél 100%-ban emberek dolgoznak (kivéve talán a konflisiparágban, ahol lovak is), a hibák elkövetése elkerülhetetlen. Vagy mégsem? Vajon mi lehet a mélyen meghúzódó oka annak, ha egy ilyen cég hálózata lyukas?
Vegyünk egy ismertebb, közelebbről meg nem nevezett céget, elég legyen talán annyit tudni róla, hogy a cég neve N-nel kezdődik (és etAcademiával folytatódik :)), ahol a közelmúltban hasonló áldatlan állapotokat talált Arányi Gábor etikus hekker. Szóval nálunk járt a Mikulás, csak nem hozott, hanem vitt. És nem a kéményen át jött be...
Mielőtt a teljes pentestet kipublikálnám, engedtesség meg nekem egy kis mentegetőzés: nem úgy van az! Meg: de ezt mi tudtuk! Meg esetleg még ez: úgysem mész vele semmire. Csakhogy erre a pentester azt válaszolja, hogy, igen, mindenütt ezt hallom, de valójában be lehet mászkálni a hálózatotokra. Hmmm. Erre, mi a válasz?
Az, hogy igen, be. És az, hogy ez így nem jó, sőt, ciki. Van egy gyenge mentségünk, de ettől még a hibákat javítani kell: ezen a hálózaton gyakorlatilag nincs semmi (a tantermeken kívül). Öt éve is van már talán annak, hogy az égvilágon MINDENT a felhőbe pakoltunk, a minden alatt azt értjük, hogy MINDENT. És ez bizony ellustított minket, mert felvettük azt a hozzáállást, hogy ha az adatokat kiszerveztük, a biztonságot is kiszerveztük. Ami egyébként nagyrészt igaz is.
Tehát jogosnak tűnik a kalkulus, hogy az irodai hálózatunk kábé annyira fontos és védett, mint egy kávézó nyilvános wifi-hálózata. Nesze neked, vegyed-vigyed, légy vele boldog!
Legalábbis ezt hittük eddig. Erre jön egy csibész, és bebizonyítja, hogy nem. További cikkekben a teljes penteszt eredményét fogom publikálni több részletben, mert sajnos igen-igen hosszúra sikeredett. Stay tuned!
(Szerintem ez is egy jó kis CISSP-rémtörténet amúgy...)
A bot framework röviden abban segít, hogy saját alkalmazásunkkal chatelni tudjunk. Ha például van egy levelezőszerverünk, akkor megoldható, hogy chat üzenetekkel e-mailt küldjünk, vagy a beérkező üzenetekről chaten értesüljünk. (chat alatt értve skype, vagy slack klienst, ami akár telefonunkon is futhat.) Hasonlóan saját IoT fejlesztéseinket is elérhetjük chat-en. Olyanra kell gondolni, hogy például be tudjuk állítani a termosztátunkat, ki/bekapcsolhatjut a riasztót a házunkban. Vagy chat-en utasíthatjuk a zenelejátszónkat de akár a tévénket, hogy éppen mit néznénk szívesen.
Ez utóbbit a github HUBOT-jából loptam.
A lényeg, hogy tetszőleges program vagy szolgáltatás felületeként használhatjuk a chat alkalmazásunkat. Egy lépéssel továbbgondolva és egy jól működő beszédfelismeréssel összekapcsolva jövős lehetőségről beszélünk. Persze az ördög a részletekben rejtezik.
Egy kellően részletes összefoglaló cikk forráskóddal és tudnivalókkal a miértekről és a hogyanokról.
An Introduction to the Microsoft Bot Framework
Lassan 2 éve tartó munka eredményeképpen a JQuery 3-as változata elkészült. Kisebb és gyorsabb lett, és bár a verziószám jelzi, hogy lesznek dolgok, amik nem teljesen kompatibilisek visszafelé, a készítők szerint nagyobbrészt változatlanul használhatók az elkészült kódok. Készült dokumentáció a korábbi változatokról való áttéréshez (upgrade guilde), és készült migrate plugin a kompatibilitási problémák könnyebb azonosításához.
Ez a terv: