Soci (Soczó Zsolt) szakmai blogja

2014.07.30.

Windows system backup NAS-ra

Filed under: Szakmai élet — Soczó Zsolt @ 19:09

Első nekifutásra nem működik, azt mondja Error code 0x80070544. A megoldás egyszerű, amikor beírjuk a user nevet, amivel csatlakozik a NAS-hoz, be kell írni a NAS nevét, pl. nálam diskstation\soci.

2014.07.28.

WCF channel és channelfactory lezárás

Filed under: .NET,.NET 4.5,Szakmai élet,WCF — Soczó Zsolt @ 12:59

A WCF channelek lezárása egyértelmű, ha rendben van a csatorna Close(), ha faulted, Abort().
De mi van a channelfactory-vel?
Amiért a kérdés előjött az az, hogy egy szerviz rendszeres használata során 2 perc utáni hívásoknál elszállt a hívás. A kliens ezt élte meg:
An existing connection was forcibly closed by the remote host

A szerveren meg egy belső exception volt, amit a WCF lenyelt, de jelezte, hogy valami nem ok:
The I/O operation has been aborted because of either a thread exit or an application request.

A figyelmem a channelfactory-re terelődött. Az lokális változóként volt létrehozva, és ebek harmincadjára szabadon engedve. Jaj, ez beteg. Lokális dispose nem jó rá, mert akkor lezárja az összes általa nyitott csatornát (legalábbis vélemények szerint).

Próbáltam egy statikus példányt letárolni, azzal létrehozni a csatornákat, de ez is lepukkant 2 perc után (doksi szerint thread safe, több szálból használtam).

Végül nem maradt más, mint minden csatornához saját factory instance-et létrehozni, és a csatorna használata után mindkettőt lezárni. Pedig elvileg meg lehet osztani a factory-t, teljesítmény okokból. Ebben az alkalmazásban ez megfelelő megoldás, de ha sok csatornát kellene nyitni, az nem tetszene. Valaki látott már ilyen esetet?

AlwaysOn ReadOnly replika olvasás

Hangyál Zoli hívta fel a figyelmem egy finomságra. AlwaysOn, ReadOnly replika, szinkron kapcsolat. Egy adott módosítás hatása látszik-e azonnal a replikán, ha a primary-n a tranzakció commitról kaptunk visszajelzést?

2014.07.26.

MemoryCache bug

Filed under: .NET,.NET 4,.NET 4.5,ASP.NET,Szakmai élet — Soczó Zsolt @ 16:53

A MemoryCache osztály ASP.NET hoszt alatt időnként Dispose-olja magát. Nagyon kedves. Mindezt úgy teszi, hogy nem dob semmiféle exceptiont, csak ha beleraksz valamit, nem marad benne.
4.5-ben fixálták, de 4.0-ra is van workaround vagy hotfix is. Részletek itt.

2014.07.23.

Rest apik verziózása

Filed under: Szakmai élet — Soczó Zsolt @ 14:48

Érdekes cikk a témáról.

Kiemelve a cikkből:

URL: You simply whack the API version into the URL, for example: https://haveibeenpwned.com/api/v2/breachedaccount/foo
Custom request header: You use the same URL as before but add a header such as “api-version: 2”
Accept header: You modify the accept header to specify the version, for example “Accept: application/vnd.haveibeenpwned.v2+json”

Ennek kapcsán filózok valamin. A restes cuccok erőforrásokról szólnak, azaz ha adatokban gondolkodunk, entitásokat címzünk meg, azokon végzünk műveletet. De mi van, ha nem egy konkrét entitáson kell végezni műveletet? Pl. Tiltsd le xy usert a rendszerben. Ez sokkal inkább operation jellegű dolog, sok entitást érinthet, az ilyeneket nem szokás rest alapon megcsinálni, jól érzem? De ha nem, akkor hogy?

2014.07.16.

Brokernet

Filed under: Élet,Tőzsde — Soczó Zsolt @ 10:16

Tóth úr (dr. Tóth András tanácsadó, Brokernet) írja hírlevelében:

“Az elmúlt évtizedben elképesztő mennyiségű ócska pénzügyi konstrukciót kínáltak vállalkozói nyugdíj célra. Ezek jelentős része hatalmas csalódást okozott. Akikkel most tárgyaltam, azok nagyobbik része már ki is szállt ezekből, a kisebbik része meg gondolkodik erről. És hatalmas a tanácstalanság.”

No, ha valaki, akkor a Brokernet igazán sokat tett, hogy ez a szabadrablás szisztematikusan működjön. Nem sorolom fel az összes megszüntetett unit linked biztosításomat, csak egyet mondok el, már csak ez él, de ennek sincs értelme.

CIG unit linked konstrukció. Az első két évből lenyúlnak 40 (negyven!) százalékot. Ettől mondhatni fejnehéz a biztosítás. Emiatt nem lehet normálisan szabadulni tőle, meg ez az első szintű rablás.
A befektetett minden egyes összegekből levonnak 5%-ot, és évente a akkumulálódni szándékozó, de nem tudó összegből 1.75%-os alapkezelői díjat, meg pár ezer forintot évente számlavezetési díjként.

Tegyük fel be akarok fektetni 10 évre. A 2 évi 40% 10 évre osztva évi 8%. Ehhez jön még az 5% amikor betolom a pénzt, illetve az 1.75%, ami ráadásul minden évi eredményre vagy megmaradt összegre rámegy. Ez összesen 14.75%. Nem teljesen pontos a szám, mivel a különböző számok más alapra viszonyulnak, de a nagyságrend jó.

No, akkor most jön a kérdés. Milyen passzív, buy and hold befektetés fog évi 26%-ot kitermelni, hogy abból kijöjjön a 14%-os rablás, és még nekem is maradjon az “ígért” 12%-os hosszútávú átlagos hozam?
Ne akarja nekem senki azt mondani, hogy de váltani kell az instrumentumok között, figyelve a trendeket. Aki ezzel konzisztensen tud pénzt csinálni, az kezdjen el tőzsdézni. De az, hogy a legjobb amerikai hedge fundok évi 30%-ot csinálnak, olyan emberekkel és technológiával, akiket elképzelni se tudunk, az nekem azt jelzi, hogy egy átlagember az alapváltásokkal sokkal nagyobb valószínűséggel veszít, mint nyer. Beating the market, ez nem egy olyan dolog, amit meló mellett tőzsdézgetve egy átlagember meg tud tenni. Szóval számomra unit linked biztosítás = undorító rablás.

2014.07.14.

Auto VPN Windows 8-ban

Filed under: Szakmai élet — Soczó Zsolt @ 17:26

Ez hasznos, és működik is jól.

Powered by WordPress