Soci blog

Soós Tibi powershellt tanul, ez lelkessé tett engem is. Én ugyan már túl vagyok az alap szintaxon, de a példái kapcsán érdekel, mi történik a háttérben.

Legutóbb ojjektumok properyjét listázgatta, formázgatta. Nyilván .NET programolóként tudjuk, hogy ez a reflection triviális felhasználása, de nem is ez a lényeg belőle. A kérdés akkor vált érdekessé, amikor elkezdte rendeztetni a Hastable-ben levő ojjektumokat ($result). A Hastable egy nagy ojjektumként megy át a csövön, ezért azon nincs mit rendezni. A példa GetEnumerator() hívása ravasz trükk. Ennek hatására a csőbe behullanak a cuccosok mint DictionaryEntry ojjektumok. Ez már egy sima, sik tömb, System.Array. Cool.
Ezt kéne rendeztetni, a Key propery alapján. Tibi viszont Name-et írt, és jól működött. Ez elgondolkodtatott. Miért megy ez jól, mikor nincs is Name-je a DictionaryEntry-nek?

No, hát a címbeli Custom Methods and Property-k miatt. Merthogy, a jámbor rendszergazda a saját szemüvegén keresztül látja a dolgokat, ő nem programoló. Ezért egyes nehezen emészthető fogalmakat, mint Key álnevekkel látnak el. Ezek xml fájlokban vannak, pl. a types.ps1xml-ben van elég sok. Konkrét alanyunk így néz ki:

   <Type>
        <Name>System.Collections.DictionaryEntry</Name>
        <Members>
            <AliasProperty>
                <Name>Name</Name>
                <ReferencedMemberName>Key</ReferencedMemberName>
            </AliasProperty>
        </Members>
    </Type>

Teccik látni, ezért érti a Sort-Object a Key helyett a Name property-t.

(A címbe majdnem bedobtam a Microsoft Powers Hell viccet, de ez már szakállas, nem?)

Bálint a betegsége miatt sokáig nem volt oviban, és nagyon aranyos, kezelhető kisfiú lett belőle, csodálkoztunk is, mi van vele?

Aztán a héten elkezdett oviba járni újra, és jön elő az az akaratos, direkt kötekedő, ingerült énje, ami tavaly oly sok szomorúságot okozott nekünk is és neki is.

Mit lehet tenni? Írassuk át másik oviba? Szerintem normálisak az ovónők, csak Bálint azt mondja, zavarja, hogy sok a gyerek, és zajonganak. Meg az ő érdeklődése olyan, hogy untatja az óvoda, az öntözőrendszerek meg az elektromosság sokkal érdekesebb, mint a körtánc.

Mi a francot lehet tenni? Pszichológussal vajon érdemes lenne beszélni?

-Mielőtt nem volt a Föld, akkor mi volt?
-Mielőtt nem volt élet a Földön, akkor mi volt itt?
-Az űrben ha nincs levegő, akkor mi van?
-A Föld is az űrben van?
-Az űrhajósok hogy tudnak lélegezni az űrben?
-Hol voltam mielőtt megszülettem?
-Stb.

Az utolsó kérdésre azt mondtam neki, ezen még a felnőttek is rágódnak, van, aki szerint előtte nem léteztél, van, aki szerint igen. A többi azért nem fog ki rajtam. :)

Ha valakinek hiányzik ez, nem csak nekem, akkor szavazzon erre.

A pletykák szerint egyébként a következő 2008 CTP-ben (február) már lesz. Nekem nagyon hiányzik ez a 2005-ből.

A cégnél már több mint egy éve TFS-t használunk Source Control céljára. Nincs vele különösebb gond, megszerettem.

De most nagyon megszivatott. Vistán dolgozok, UAC bekapcsolva, ahogy kell. Általában a LUA accountommal geteltem le a fájlokat. Néha azonban a saját nevemben, de adminként (ugye az UAC már csak ilyen skizofrén dolog).
Amikor adminként geteltem, akkor olyan acl került a fájlokra, amely a sima usereknek, mint amilyen én is vagyok, amikor normál módon dolgozok, csak Modify joga van a fájlokhoz, az adminoknak Full Control. Ez jó is így, minek Full Control, ha egyszer csak írja a fájlokat a kliens, jogot nem állít rajta (tudomásom szerint).

Hiába volt írás jogom a fájlokra, mégis Access Denied-okat kaptam. Elő a process monitorral. És lebukott a pára! Full Access-szel akarja megnyitni a fájlokat, nem Modify-jal, persze, hogy nem sikerül neki.

Két dolog lehet.
1. Trehány volt a programoló, és több jogot kér, mint kellene, mert neki az nem fáj. Nekem igen.
2. Van, amikor jogokat is állít a fájlokon, ehhez kell a Full Access. Nem tudom, hol az igazság.

Ekkor.

Ezek után ne tessék csodálkozni, hogy el kell telni valamennyi időnek, mire újra belerázódik a munkába.

Nem ismertem, de nagyon sajnálom.

Ami megdöbbentő, hogy pár napja még rengeteget írt a blogjában, valószínűleg váratlanul halt meg.

Jó könyveket írt, jó szakember volt, Isten nyugosztalja.

Mi van, ha egy LINQ kifejezésben olyan szűrést szeretnénk végrehajtani, amit a LINQ2SQL réteg nem tud okosan végrehajtani, mert pl. TSQL függvényt kellene használnunk a where feltételben?
Ha nem ügyeskedünk, átjön a 100 millió sor az adatelérő rétegbe, aztán szűr a LINQ maga. Szép is lenne.

No, az okosság az ilyen esetekre az, hogy lehet használni TSQL függvényeket a LINQ where feltételben. Ettől még nem lesz index seek, de legalább a szerver szűr.

A linkelt példát kipróbáltam, tényleg a szerver szűr.

AdwentureWorks-szel:

AWDataContext dc = new AWDataContext();
dc.Log = Console.Out;

var q = from o in dc.PurchaseOrderHeaders
        where dc.WeekOfYear(o.OrderDate) == 23
        select o;

foreach (var item in q)
{
    Console.WriteLine(item.OrderDate);
}

ALTER FUNCTION WeekOfYear(@Date DateTime)
RETURNS Int
AS
BEGIN
RETURN (CAST(DATEPART(ww, @Date) AS INT))
END

Az SQL, ami bemegy a szerverhez:

SELECT [t0].[PurchaseOrderID], [t0].[RevisionNumber], [t0].[Status],
[t0].[EmployeeID], [t0].[VendorID], [t0].[ShipMethodID], [t0].[OrderDate],
[t0].[ShipDate],
 [t0].[SubTotal], [t0].[TaxAmt], [t0].[Freight], [t0].[TotalDue],
[t0].[ModifiedDate]
FROM [Purchasing].[PurchaseOrderHeader] AS [t0]
WHERE [dbo].[WeekOfYear]([t0].[OrderDate]) = @p0
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [23]
-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21022.8

Kb. másfél éve a Firefoxot használom IE helyett, általában elégedetten. Az IE-ben sokat fejlesztek, így azt gyakran kell újraindítani, így nem kell mindig újra betöltenem az állandó oldalaimat, mint a gmail és a google reader.

Viszont minden nap eljön az a pont, amikor elkezd a gép veszettül kerregni, és belassul, de nagyon. Ilyenkor mindig azt látom, hogy a Firefox viszi el a memóriát, láttam már 700 megás Peak Working Setet.

Uraim ott mozilláéknál, nem leszünk így jóban. Feltételezem az Ajaxoló gmail és reader javascriptjei miatt a Firefox hibás js implementációja miatt leakelnek. De ez csak tipp. Ismeri valaki a gyógyírt?

http://www.youtube.com/watch?v=YnLu0vYJA-4

Mert napról-napra adnak rá okot. Hogy költöznének be Gyurcsány meg az összes rasszistázó házába ezek.

Ez tetszik. Nagyon.
Update. Bocs, az indexet akartam linkelni.

Lehet, hogy anarchista hajlamaim vannak? (Lehet. :)

Nem szeretem az erőszakos szervezeteket, amelyek a szólásszabadságot akarják kinyírni. Se a magyar politikusokat, akik az ún. gyűlöletbeszéden gondolkodnak, se a sció egyházat, se az embereket hülyítő Jehovákat és a többi pénzbeszedő szektát se.

Az ilyenek ellen valók az anarchikus módszerek. Lehet, hogy a 60-as évekbe kellett volna születnem, és Timothy Learyvel minden nap betépnem? Vagy a fáradságtól már be is téptem? :)

Ja, a cikk második videója nagyon állat, tudja valaki, milyen zene megy alatta?

A videó használja azt a fogalmat, hogy SP, az a Suppress Person, aki támadja az egyházat. Közellenség, más néven. Aki az ilyenekkel kapcsolatban áll, az meg a Potential Trouble Source. Hihetetlen, ezek miket ki nem találnak. Félelmetes, ahogy egy szervezet mint egy organizmus védi magát és támadja a környezetét. Van etikai tisztjük, az a belső rendőrőrmester. Durva banda, a legalja lelkes, megtévesztett műkedvelőkből áll, akik azt hiszik, megmentik a világot (minden szekta azt mondja, csak ők az út, pont ezért szekták). A tetején meg a hatalom- és pénzéhes hiénák, akik már tudják, hogy kamu az egész, de már nem akarnak kiszállni, ha már van hatalmuk és pénzük, meg 10 év után szar bevallani maguknak, hogy baromságban hittek felnőtt létükre, és kihasználták őket.
Közben nyomják a TR-eket, ettől azt hiszik megtanulnak kommunikálni, de valójában csak megtanulnak szenvten robottá válni, olyanokká, mint az Equlibrum c. film leszadált papjai. Pislogás nélkül ráerőszakolni az egyházi tákolmányokat az ártatlan kuncsaftra. Erre jó a TR. Mint ahogy az oxfordi teszt meg arra, hogy bevigye a népet, aztán benn már elcsábítják a híddal meg a többi csábítónak ható baromsággal. Kibaszottul ki van találva a rendszerük, ezért nagyon veszélyes.

Pár metódus még a geometry típushoz, aztán tényleg jönnek a valódi adatok és számítások.

A példáim eddig a geometry típusra építettek, azt könnyebb kezelni, de a metódusok jelentős része értelmezhető lesz a geograpy típuson is. Ha nem ebben a CTP-ben, majd a következőben (CTP6 pre-t már le tudnék tölteni mint MVP, de várok pár napot a végleges CTP-re, ne kelljen állandóan telepíteni). Nem mindent lehet viszont egy gömbön értelmezni, ezért nem teljesen azonos a két típus metóduskészlete, de erről majd később.

Csak ízelítőül, sík tartomány esetén (geometry) triviális értelmezni a kívül és a belül fogalmát, amelyik tartomány véges, az van belül. És egy gömbön? Ott mindkét tartomány véges. Akkor, most mi nézzük a majmokat az állatkertben, vagy ők néznek minket? Ezt a kérdést is elrendezzük majd. Ezeket csak azért mondom, hogy ne csüggedjen senki a sok metódus láttán, kellenek majd ezek.

Távolság meghatározás: STDistance. Ez egy pont és egy teszőleges alakzat között keresi meg a legrövidebb utat. Geometrynél ennek nincs mértékegysége, geograpy esetén pedig az SRID-től függ, mi lesz ez, sok esetben például fokban kapjuk meg a távolságot (hisz a geograpy szélesség-hosszúsággal dolgozik).
A példában még látható a STLength, az az alakzat körvonalának hosszát adja vissza (pl. egy ország kerülete).

DECLARE @g geometry;
DECLARE @h geometry;
DECLARE @i geometry;
SET @g = geometry::STGeomFromText('POLYGON((0 0, 2 0, 2 2, 0 2, 0 0))', 0);
SET @h = geometry::STGeomFromText('POINT(10 10)', 0);
SET @i = geometry::STGeomFromText('LINESTRING(2 2,10 10)', 0);
SELECT @g, @g.STDistance(@h), 0.1 as [Thickness], 'Green' as [Color]
UNION ALL
SELECT @i, @i.STLength(), 0.1 as [Thickness], 'Gray' as [Color] -- demonstration line
UNION ALL
SELECT @h, null, 0.3 as [Thickness], 'Red' as [Color];

POLYGON ((0 0, 2 0, 2 2, 0 2,  11.3137084989848       0.1                            Green
LINESTRING (2 2, 10 10)        11.3137084989848       0.1                            Gray
POINT (10 10)                  NULL                   0.3                            Red

Befoglaló téglalap meghatározása: STEnvelope. Ezt könnyű elképzelni, nem mellékelek képet, csak a kimenetet:

DECLARE @g geometry;
SET @g = geometry::STGeomFromText('LINESTRING(0 0, 2 3)', 0);
SELECT @g, @g.STEnvelope(), 0.1 as [Thickness];

LINESTRING (0 0, 2 3)                    POLYGON ((0 0, 2 0, 2 3, 0 3, 0 0))

Egyenlő-e két alakzat? STEquals. Azt gondolnánk ez egyszerű, de lehet, hogy másként vannak összerakva. Pl. egy sokszöget össze lehet rakni multi-lineként, aminek az első és utolsó pontja ugyanaz és polygonként is. A függvény észreveszi az ilyen csibészségeket.

DECLARE @g geometry
DECLARE @h geometry;
SET @g = geometry::STGeomFromText('LINESTRING(0 2, 2 0, 4 2)', 0);
SET @h = geometry::STGeomFromText('MULTILINESTRING((4 2, 2 0), (0 2, 2 0))', 0);
SELECT @h, @h.STEquals(@g), 'Blue' as [Color], 0.2 as [Thickness]
UNION ALL
SELECT @g, @g.STEquals(@h), 'Orange' as [Color], 0.1 as [Thickness];

MULTILINESTRING ((4 2, 2 0), (0 2, 2 0)) 1
LINESTRING (0 2, 2 0, 4 2)               1

A példából látszik, hogy a művelet kommutatív (még szép).

Külső körvonal meghatározása: STExteriorRing. A korábbi lukas négyzetes példában a külső négyzetet adja vissza. Ha egy épületegyüttes van például poligonok kollekciójaként leírva, akkor ezzel könnyű meghatározni az együttes körvonalukat. Az STInteriorRingN(n) kívülről befelé haladva az n. belső körvonalat adja vissza.

DECLARE @g geometry;
SET @g = geometry::STGeomFromText('POLYGON((0 0, 3 0, 3 3, 0 3, 0 0),(2 2, 2 1, 1 1, 1 2, 2 2))', 0);
SELECT @g, 0.3 as [Thickness], 'Red' as Color
UNION ALL
SELECT @g.STExteriorRing() AS [ExteriorRing], 0.1 as [Thickness], 'Yellow' as Color
UNION ALL
SELECT @g.STInteriorRingN(1) AS [FirstInteriorRing], 0.1 as [Thickness], 'Green' as Color;

POLYGON ((0 0, 3 0, 3 3, 0 3, 0 0), (2 2, 2 1, 1 1, 1 2, 2 2))         0.3                            Red
LINESTRING (0 0, 3 0, 3 3, 0 3, 0 0)                                   0.1                            Yellow
LINESTRING (2 2, 2 1, 1 1, 1 2, 2 2)                                   0.1                            Green

STIsEmpty: ez olyan, mint a NULL. Itt egy alakzat lehetne, de nincs. Azaz olyan, mint az ISNULL, csak geo izékre.

STIsClosed: zárt-e az alakzat. Ha a kezdő és a végpont ugyanaz, akkor zárt.

STIsSimple: ha az alakzat nem metszi saját magát. Pl. a 8-as, az X vagy az A nem egyszerű alakzat. Az O vagy a D igen.

STIsRing: akkor gyűrű valami, ha zárt és egyszerű. Az O pl. gyűrű, de a D is, az A nem, mert nem zárt (kilóg a két lába) és nem is egyszerű (a vízszintes beleér a két lábába).

STOverlaps: átfedi-e egymást két alakzat, elég egyszerű értelmezni. Mozgó alakzatoknál ütközést érzékelni is jó. (Doom for SQL Server) :)

STPointOnSurface: visszaad egy tetszőleges pontot egy felület belsejében. Nem igazán tudom még mire lehet jó, de talán arra, hogy ha pl. egy épülethez képest kell mérni valami, de nem tudjuk hol vannak az ajtók, akkor kiválasztunk a belsejében egy tetszőleges pontot a függvénnyel, és onnan mérünk. Ha valaki ismeri a pontos célját, írja meg.

Update.

Megkérdeztem az MVP newsgroupban, az egyik SQL Server fejlesztő kolléga (Isaac Kunen) azt mondta, arra jó, hogy ha az alakzathoz egy címkét szeretnénk rajzolni, akkor egy ahhoz használható pozíciót ad vissza a metódus. Hmm.

És végül (tényleg elfogyak a metódusok?) egy nem szabványos kiegészítés: Reduce.
Ezzel le lehet egyszerűsíteni alakzatokat, hogy egyszerűen fogalmazva durvább legyen a felbontásuk.

DECLARE @g geometry;
SET @g = geometry::STGeomFromText('LINESTRING(0 0, 0 1, 1 0, 2 1, 3 0, 4 1)', 0);
SELECT @g, 'Original' as [Display], 'Blue' AS [Color], 0.2 AS [Thickness]
UNION ALL
SELECT @g.Reduce(.75), 'Reduced' as [Display], 'Red' AS [Color], 0.1 AS [Thickness]

LINESTRING (0 0, 0 1, 1 0, 2 1, 3 0, 4 1)                              Original Blue  0.2
LINESTRING (0 0, 0 1, 3 0, 4 1)                                        Reduced  Red   0.1

A doksi szerint ő a Douglas-Peucker algoritmussal közelíti meg az eredeti alakzatot, a megadott paraméternek megfelelő agresszivitással. Gondolom akkor jön jól, ha egy számítás lassú lenne a finom felbontás mellett (pl. egy poligon 1500 darabkából), és ilyenkor a pontosság rovására, de egy mondjuk tizedére csökkentett oldalszámra egyszerűsített alakzattal számolunk. Érdemes megnézni, mit csinál egy körrel:

DECLARE @g geometry;
SET @g = geometry::STGeomFromText('POINT(0 0)', 0).STBuffer(10);
SELECT @g, 'Original' as [Display], 'Blue' AS [Color], 1 AS [Thickness]
UNION ALL
SELECT @g.Reduce(.75), 'Reduced1' as [Display], 'Red' AS [Color], 0.2 AS [Thickness]
UNION ALL
SELECT @g.Reduce(2), 'Reduced2' as [Display], 'Yellow' AS [Color], 0.2 AS [Thickness]
UNION ALL
SELECT @g.Reduce(5), 'Reduced3' as [Display], 'Green' AS [Color], 0.2 AS [Thickness]

Ez volt a kör négyszögesítése projekt.

No, még mindig nem érintettünk minden metódust, de a legfontosabbakat már láttuk. A következő részben letöltünk adatokat az országról és a környékéről, és elkezdünk méricskélni rajta. Ízelítőül megmutatom a környező országok kerületének és területének kiszámítását (Addig lehet ellenőrizni, jók-e az adatok? Románia területe nem gyanúsan nagy? ;)

select
CNTRY_NAME as 'Ország',
cast([geom].STArea() /1000 /1000 as int) as 'Terület [km2]',
cast([geom].STLength() /1000 as int) as 'Kerület [km]'
from Country

Ország                         Terület [km2] Kerület [km]
------------------------------ ------------- ------------
Byelarus                       1024          162
Poland                         139576        2068
Czech Republic                 54465         1303
Ukraine                        43739         1240
Germany                        3585          285
Slovakia                       48926         1207
Hungary                        92995         1562
Austria                        42468         966
Slovenia                       14000         651
Serbia                         76621         1614
Romania                        105365        1613
Bosnia and Herzegovina         51005         1173
Croatia                        52209         3009
Bulgaria                       19237         724
Montenegro                     7780          450

http://www.youtube.com/watch?v=KMU0tzLwhbE

Tessék jól felhangosítani. :)

Jó sok.

A feladvány itt van.
Tegnap éjjel fájt Benedek hasa, sétálgattam kicsit vele, közben kitaláltam rá egy megoldást, és még jó is az eredménye. :)

Pár nap múlva kirakom a sajátomat, addig is jöhet a tiétek.

Mielőtt tovább taglalnám a metódusokat, egy kis kiegészítés, egy kommentre válaszolva.

MI A FENÉRE JÓ EZ AZ EGÉSZ SPATIAL izé?

Nos, ha nem 1×1-es négyzetekkel dolgozunk, hanem mondjuk térképészeti adatokkal, akkor máris sok érdekes kérdést lehet megválaszolni ezekkel a lüke metódusokkal, mint például:
-Mekkora Magyarország területe?
-Melyik város van legközelebb az ország középpontjához?
-Milyen messze van egymástól a két legtávolabbi település?
-Milyen hosszú a Duna magyarországi szakasza?
-Melyik település fekszik folyóparton?
-Mekkora a vízzel borított és a száraz területek aránya egy adott részben?
-Hol van ATM automata x km-es körzetben?
Stb.

Mivel sikerült szereznem nem túl részletes, de valós adatokat Magyarországról és a szomszédokról, ezekre a kérdésekre igyekszek választ adni a későbbi részekben. Így már érthető, miért kellenek ezek a metódusok?

Geometry metódusok folytatás, előzmények itt.

Hány dimenziós az alakat? STDimensions. A pont 0, a vonal 1, a sokszög 2. Semmi meglepetés, több nem lehet, mert 2 dimenziós a koordináta-rendszerünk.

Halmazműveletek jönnek.

Két alakzat metszete, STIntersection.

DECLARE @g geometry;
DECLARE @h geometry;
SET @g = geometry::STGeomFromText('POLYGON((0 0, 0 2, 2 2, 2 0, 0 0))', 0);
SET @h = geometry::STGeomFromText('POLYGON((1 1, 3 1, 3 3, 1 3, 1 1))', 0);
SELECT @g, 'Blue' as [Color], 0.3 as [Thickness]
UNION ALL
SELECT @h, 'Green' as [Color], 0.2 as [Thickness]
UNION ALL
SELECT @g.STIntersection(@h), 'Orange' as [Color], 0.1 as [Thickness];

POLYGON ((0 0, 0 2, 2 2, 2 0, 0 0))      Blue   0.3
POLYGON ((1 1, 3 1, 3 3, 1 3, 1 1))      Green  0.2
POLYGON ((1 1, 2 1, 2 2, 1 2, 1 1))      Orange 0.1

A kis sárga terület a metszet.

Két alakzat uniója (hogy van ez szépen, magyarul?): STUnion.

DECLARE @g geometry;
DECLARE @h geometry;
SET @g = geometry::STGeomFromText('POLYGON((0 0, 0 2, 2 2, 2 0, 0 0))', 0);
SET @h = geometry::STGeomFromText('POLYGON((1 1, 3 1, 3 3, 1 3, 1 1))', 0);
select @g, 0.2 as [Thickness], 'Yellow' Color
union all
select @h, 0.2 as [Thickness], 'Blue' Color
union all
select @g.STUnion(@h), 0.1 as [Thickness], 'Red' Color;

POLYGON ((0 0, 0 2, 2 2, 2 0, 0 0))      0.2                            Yellow
POLYGON ((1 1, 3 1, 3 3, 1 3, 1 1))      0.2                            Blue
POLYGON ((0 0, 2 0, 2 1, 3 1, 3 3, 1 3,  0.1                            Red

Szimmetrikus különbség, STSymDifference. Az egyiket is kivonják a másikból (STDifference, láttuk már az előző részben), majd a másikat is az egyikből. Az eredő persze egy geometrikus alakzatokból álló kollekció lesz. Hogy ezt tudjuk vizualizálni, az STGeometryN metódussal beleindexelünk mindkét kollekció-elembe, és pirossal illetve naranccsal mutatom meg őket:

DECLARE @g geometry;
DECLARE @h geometry;
SET @g = geometry::STGeomFromText('POLYGON((0 0, 0 2, 2 2, 2 0, 0 0))', 0);
SET @h = geometry::STGeomFromText('POLYGON((1 1, 3 1, 3 3, 1 3, 1 1))', 0);
SELECT @g, 'Green' as [Color], 0.2 as [Thickness]
UNION ALL
SELECT @h, 'Yellow' as [Color], 0.2 as [Thickness]
UNION ALL
SELECT @g.STSymDifference(@h).STGeometryN(1), 'Red' as [Color], 0.1 as [Thickness]
UNION ALL
SELECT @g.STSymDifference(@h).STGeometryN(2), 'Orange' as [Color], 0.1 as [Thickness];

POLYGON ((0 0, 0 2, 2 2, 2 0, 0 0))      Green  0.2
POLYGON ((1 1, 3 1, 3 3, 1 3, 1 1))      Yellow 0.2
POLYGON ((2 1, 3 1, 3 3, 1 3, 1 2, 2 2,  Red    0.1
POLYGON ((0 0, 2 0, 2 1, 1 1, 1 2, 0 2,  Orange 0.1

Teljesen benne van-e az egyik alakzat a másikban? STWithin.

DECLARE @g geometry;
DECLARE @h geometry;
SET @g = geometry::STGeomFromText('POLYGON((0 0, 4 0, 4 4, 0 4, 0 0), (1 1, 3 1, 3 3, 1 3, 1 1))', 0);
SET @h = geometry::STGeomFromText('POLYGON((1.5 1.5, 2.5 1.5, 2.5 2.5, 1.5 2.5, 1.5 1.5))', 0);

SELECT @g, 'Red' as [Color], 0.1 as [Thickness]
UNION ALL
SELECT @h, 'Blue' as [Color], 0.1 as [Thickness]

Ennek a kimenete false. Trükkös példát raktam össze, egy lukas négyzetet, amiben van egy másik négyzet. Persze, hogy nincs benne egyik a másikban, nemhogy részben, de egyáltalán.

Kapcsolatban áll-e két alakat? STDisjoint. Ne keverjük a jointtal. :)
Akkor Disjoint két alakzat, ha a metszetük üres halmaz.

“My compiler complied yours” :)

Nem árulok el nagy titkot, de a C#, VB, és C++ compilert C++-ban írják. Érdekes, hogy a UNIX-ok világában a C++ mostohagyerek, ami nem annyira a nyelv miatt van szerintem, hanem marhára sokféle C++ compiler implementáció létezik, amelyek apró, de fontos pontokon különböznek, így nem portolható a kód rendesen. Vagy laza a nyelvi szabvány, vagy kupi van a másik oldalon, ízlés kérdése.

Persze, az msnek könnyebb dolga van, nem kell több platformra dolgozni, más kérdés, hogy Windows alatt is van sokféle compiler, mégis működik közöttük a bináris együttműködés, köszönhető egy okos szabványnak, a COM-nak.
Igen, a COM nem halt ki, pedig azt hittük, ki fog. Sok ponton soha nem lesz a COM alternatívája a .NET. Miért? Tegyük fel, egy IE vagy Shell extensiont írok (most tényleg azt, az előbbit). Ha .NET-ben írom, akkor be kell töltődni az általam használt CLR-nek a target processzbe. Ok, eddig nincs nagy baj. De mi van, ha egy másik gyártó cucca meg más CLR verziót kér? Egy processzben csak egy CLR verzió lehet, aki először betöltődött, az nyert. Azért ez igen gázos dolog egy extension írónak, nem? Mi marad? ATL, C++.

Mostanában sokat tanulom a C++-t, kaptam a cégtől pár könyvet, és kicsit úgy érzem, kezdek nagykorúvá válni a programolásban. Még mindig nem értek hozzá, soha nem is fogok, de egyre több dolgot látok belőle, és napról-napra ledöbbenek, mennyi mindent nem tudok még. De jó érzés tanulni, mindig van mit.

Zárásul még két adalék. A C++ fordítót tényleg C++-ban írják, mindig a saját verzióval. Tehát, most írják a 2008 utáni C++ compilert, és annak a fordításához felhasználják a “félkész” C++ compilert. Meredek? :)

Ja, és a JScript.NET compilert C#-ban írták. :) Meg lehet nézni reflectorral, én nem találtam bennük C++/CLI maradványokat (modopt, stb.):
C:\Windows\Microsoft.NET\Framework\v2.0.50727\jsc.exe
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.JScript.dll
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Vsa.dll

(A Sytem.Data pl. C++/CLI-ben készült, a program managere még a demókat is abban mutatta Redmondban).

Én meg most ébredek a csipkerjózsika álomból. Ez a vonat már elment. De aki ért hozzá, az gyorsan regisztráljon még, ha van hely.

Nézegettem az SQL 2008 könyvet, és az ottani példa alapján kedvem támadt kipróbálni a LINQ-t. Tetszik, nem tudom valódi appokban tényleg jó-e, de babrálni vele érdekes.

using System;
using System.Linq;
using Microsoft.SqlServer.Management.Dmf;

class Program
{
    static void Main(string[] args)
    {
        ConsoleColor origColor = Console.ForegroundColor;

        var fc = from f in PolicyStore.Facets
                 orderby f.DisplayName
                 select f;
        foreach (var fi in fc)
        {
            Console.ForegroundColor = ConsoleColor.Yellow;
            Console.WriteLine("Facet {0}:", fi.DisplayName);
            Console.ForegroundColor = origColor;

            var props = from f in fi.FacetProperties
                        orderby f.Name
                        select f;
            int i = 0;
            foreach (var pi in props)
            {
                Console.Write(pi.Name);
                if (i++ > 0)
                    Console.Write(", ");
            }
            Console.WriteLine();
            Console.WriteLine("-----------------------------------");
        }
    }
}

Állítólag ez a DMF nagy durranás az adminoknak, tessék örülni neki és olvasni az ingyenes fejezetet.

Tessék átgondolni..

És még, még, még.

Ezekből kiderül, hogy simán leállhat az élet az SQL Serveren egy sima fájlmásolástól, pl. felmásolod a szervizcsomagot a szerverre. Én szóltam…