Twitter címkéhez tartozó bejegyzések

TechEd Europe 2012 – 1. nap

A mai nap a plenáris előadással kezdetét vette a TechEd Europe 2012 konferencia Amszterdamban. Pontosabban már hétfőn voltak egész napos ún. “pre-conference seminar”-ok, de azokról nem tudok beszámolni, mert az idén nem voltunk rá hivatalosak, de a többi általam hallgatott előadásról igyekszem hírt adni. Ezt már reggel el is kezdtem a nyitó előadás alatt a Twitteren, de az előző évek hagyományait folytatva (aki emlékszik még Cheese-re, az tudja, hogy akkor flottabbul mentek a dolgok) az idén is összeomlott a wifi a konferencia központban, így csak utólag tudom összefoglalni a nap történéseit. Holnaptól remélhetőleg már nem lesz ilyen probléma és folyamatosan közvetíthetek.

teched-welcome

A nyitó előadást a Management & Security Division vezetője, Brad Anderson tartotta, olyan vendégszereplőkkel, mint Jason Zander (Corporate Vice President, Visual Studio), Mark Russinovich és Scott Guthrie (CVP, Server and Tools Business Division).

Akkor most tartsunk egy gondolatnyi szünetet: vajon mi köti össze ezeket az embereket és a területeiket? Hát persze, hogy a felhő. Ez a konferencia az Azure-ról szól, csak néha üzemeltetői, máskor meg fejlesztői szemmel. Windows Phone előadás van egy-kettő, de nincs Office, nincs Silverlight, nincs se WPF, se WCF, sőt a korábbi évek nagy slágere, a biztonság is csak elvétve jelenik meg. Van viszont cloud és persze rajta IAAS, PAAS, na meg SharePoint és SQL+BI. Szép új világ, tessék hozzászokni. Még egy új kifejezést is tanultam: “my clouds” (még emésztem).

A nyitó előadáson alapvetően két fontos irányból közelítették meg a felhőt:

  • A Windows Azure immár nem csak PAAS, hanem IAAS a nem régen bejelentett  virtual machine és networking szolgáltatásoknak köszönhetően.
  • A felhő alapja a Windows Server. Mindegy, hogy az Azure-ról van-e, vagy private cloud-ról, annak Windows Server a lelke.

A Windows Server 2012-ben nagyon hisz a Microsoft, amit talán az is bizonyít, hogy a Bing szerverei már a Windows Server 2012 RC változaton futnak. Hogy a Bing méretét érezni lehessen: 300+ petabájtnyi adatról van szó.

Hatalmas újdonságok nem hangzottak el a keynote-on, de persze a vakítás megvolt. Rövid demó egy “industry standard hardware”-en: 256 GB RAM, 80 CPU, 40 SSD hoszt gépként, amin virtualizálva fut egy vendég gép, ami kap 64 processzort és 64GB RAM-ot, és persze a 40 SSD-t. Ezen sikerült olyan eredményt villantani, hogy 1 millió I/O művelet másodpercenként, meg olyat, hogy 1 gigabájt/sec sebességű fájl másolás. Ééééés? (Kérdezzünk meg egy átlagos anyukát, mit gondol arról, hogy Hófehérke vidáman dalolva, egyedül látott el hét törpét.)

teched-keynote-server

A megnyitó után jöttek a foundational session-ök: egy blokkban mindössze 5 előadás a kiemelt témákról. SQL Server, ALM, consumerization of IT (?), Jeffrey Snover és a PowerShell, illetve Scott Guthrie és az Azure. Én persze Scott előadására ültem be, de lényegében ugyanazt mondta el, mint a június 7-i bejelentésen, csak jobban: VM, networking és website.

A megnyitónál sokkal érdekesebbnek és hasznosabbnak találtam Mark Russinovich Windows Azure Virtual Machines and Virtual Networks című előadását. Ez ugyan egy 200-as szintű előadás (egyesek szerint ez az a szint, amit még a főnököd is értene), és már elég sokat hallottam erről a témáról, de Russinovich előadását akkor is meghallgatom, ha már végigültem egyszer. Azzal kezdte, hogy nagyon logikusan levezette, hogy az új perzisztens virtuális gép és a hálózati szolgáltatások azért kellenek, hogy a korábbi alkalmazásokat fel lehessen vinni a felhőbe. Végre őszintén kimondta valaki a Microsofttól, hogy a VM Role nem IAAS megoldás, még akkor sem, ha a marketing részleg korábban ezt állította róla. Az alkalmazások egy jelentős részének, különösen a szerver alkalmazásoknak igenis kell az állapotmegőrzés, nem véletlenül volt ennek a szolgáltatásnak a kezdeti munkaneve “persistent VM role”. Ők azzal az alapelvvel álltak neki az új funkciók fejlesztésének, hogy mindennek simán kell mennie, és “ha fejlesztő kell hozzá, akkor az nem IAAS”.  És íme a példa, hogy a végeredmény teljesíti az elvárásokat, még egy született nem fejlesztő is meg tudja csinálni Mosolygó arc

Két érdekes apróság az előadásból:

  • A VHD-k dinamikus diszkek, tehát a blob storage-ban csak annyi tárolódik, amennyit már beleírtunk és folyamatosan nő a mérete.
  • Az Azure Storage magát tanítja. Figyeli a használati mintákat, megtalálja a “hot spotokat” és tuningolja magát, ezért ha teljesítményt akar mérni az ember, akkor érdemes legalább 45 perces bemelegedési időt hagyni az alkalmazásnak. A következő hónapokban további teljesítmény javítások várhatók a storage területén.

A virtuális gépek kapcsán még gyakrabban felmerül a kérdés, hogy “meddig” látnak a gépek, azaz hogy hol vannak a private network határok. Ezt is röviden, de korrektül végigmondta, és ha felkerülnek a webre a videók, megnézem megint. Persze van terminológiai zavar itt is,  a “cloud service” itt egy fontos fogalom, ő a határ. A cloud service-en belül pedig “a virtual machine is a single instance role” (ezt inkább nem fordítom le, így egyértelműbb).

Délután meghallgattam a Web Sites on Windows Azure előadást, ami számomra azért volt kevéssé izgalmas, mert én már májusban, a bejelentés előtt tesztelhettem az új portált és a szolgáltatásokat, így igazán túl sok újdonságot itt nem hallottam. Az előadópáros nem volt a legprofibb, de azoknak tudom ajánlani, akik step-by-step demót szeretnének mindenről (szerintem ennek is fel fog kerülni a videója előbb-utóbb a webre). Egyszerű az egész, mint a faék: Start simple, code smart, go live.

Az utolsó szekcióban sajnos több általam preferált előadás is elmaradt, ezért a konferencia központ többszöri végignyargalása után végül a Twenty Free Windows Tools That You Never Knew Existed címűre estem be. A hosszú cím valójában Windows client managementet takar és a hozzá kapcsolódó hasznos eszközöket. Tavaly az amerikai TechEden már elhangzott ez az előadás, most közkívánatra ismételték. Aki ezzel a témával foglalkozik, annak hasznos lehet a lista, a tavalyi PPT-ben megtalálhatóak a linkek. Én nem foglalkozom aktívan Windows desktop managementtel, de ezeket kiírtam magamnak (megvoltak már korábban, de már elhalványultak az emlékek, pedig hasznos eszközök):

  • Windows2Go
  • Windows Performance Recorder
  • Problem Steps Recorder

A nap végén az ilyenkor szokásos módon a látogatók ellepik a kiállítási területet, végigkóstolják a helyi söröket és megy a lazulás. Az idei év sztárjai a Kinect vezérelt, életnagyságú bokszoló robotok, amik a keynote videó elején is láthatóak. Íme a robotok a ringben:

teched-robots1

És mikor összecsapnak (oldalt látható a két irányító játékos):

teched-robots2

A bemutató videót érdemes megnézni, elég csak annyit mondani, hogy a Coding4Fun csapat készítette Mosolygó arc

Folyt. köv. @gyorgybalassy

 

Technorati-címkék: ,,
Reklámok

Kimaradhat a XAML a Windows 8-ból

ms-days-logoAkik esetleg követnek Facebookon vagy Twitteren már tudhatják, hogy múlt héten Dávid Zoli barátommal Szófiában voltunk.

A bolgár Microsoft múlt héten rendezte meg az MS Days 2012 konferenciát, ami egy meglehetősen komoly rendezvény fejlesztők és üzemeltetők számára. Csak hogy a méreteket érezni lehessen: két nap, 8 párhuzamos szekció, 72 előadás (melynek kb. a fele angolul), 49 előadó (akik közül sokat külföldről reptettek oda) és minderre több, mint 1000 résztvevő.

A szervezés nagyon profi volt, minden egészen flottul ment, talán csak a helyi Lurdy Ház, a Кино Арена volt egy kicsit szűkös ennyi embernek:

Кино Арена

Zolival két előadást tartottunk JavaScriptről, HTML5-ről, MVC-ről és Azure-ról, főként tapasztalatokról és legjobb gyakorlatokról. Akit érdekel, letöltheti az előadásokhoz tartozó prezentációkat és demókat innen. Büszkén jelenthetem, hogy mindkét előadás nagyon népszerű volt, sokkal többen jöttek, mint ahányan a terembe befértek, még a “falakon is lógtak”. Az értékelőlapok összesítését még nem kaptuk meg, de a Twitteren már jött néhány pozitív visszajelzés (kettőnk közül csak én vagyok Twitteren, ezért csak engem emlegetnek, de az előadásokat együtt tartottuk):

ms-bg-twitter1

ms-bg-twitter2

A második előadás után megkeresett minket a Microsoft Research két munkatársa és elmondták, hogy az egyik kiemelt projektjükben kompatibilitási problémák megoldásán dolgoznak és az előadások alapján arra gondoltak, hogy szívesen bevonnának minket is. Konkrétan azon elmélkednek, hogy a XAML egy gigantikus zsákutca, mert már sok “dialektus” van belőle (Silverlight, WPF, Windows Phone, Windows 8) és mindegyik jelentősen eltér a másiktól.

Erről egyébként bárki meggyőződhet: a CODE Magazin atyja, Markus Egger egy nagyon hasznos eszközt tett közzé a CodePlexen XAML Dialect Comparer Tool néven. Az eszköz annyit tud, hogy megadunk neki egy forrás és egy cél XAML változatot, ő pedig végigszántja a névtereket és megmondja, mennyire kompatibilisek egymással. Például ha Silverlight 5-ről Windows 8 Metro-ra akarunk átállni, akkor csak 55,19%-os kompatibilitással számolhatunk. Mindenki eldöntheti, hogy a saját esetében ez mire elég.

XamlComparer

Vissza Bulgáriához. Szóval az MSR-nél két projekten dolgoznak és mivel egy szóval sem mondták, hogy ne beszéljünk róla, elmesélem. Az egyik projekt célja, hogy XAML markupot HTML-re fordítsanak, a másiké pedig, hogy a HTML+JavaScript alkalmazásoknak 100%-osan kompatibilis környezetet biztosítsanak minden platformon. Komolyan elkezdtek azon gondolkodni, hogy a Windows 8 Metro stílusú alkalmazásoknál kínált JavaScript lehetőségek pontosan ugyanabba az irányba viszik a HTML+JS párost, mint a XAML-t: dialektikus zsákutcába. Márpedig ezt a hibát az MS nem akarja még egyszer elkövetni, így nem csoda, hogy Steven Sinofsky-t is komolyan érdeklik ezek a kutatások.

Íme egy példa! Windows 8 Metro stílusú alkalmazásban használhatunk WinJS.UI.ListView vezérlőt, így:

<div id="playeritemtemplate" data-win-control="WinJS.Binding.Template">
    <div data-win-bind="innerText:Name" style="height: 20px;" />
    <img data-win-bind="src:Photo" style="width: 200px; height: 150px;" />
</div>

<div id="PlayerListView" 
    style="height: 185px;" 
    data-win-control="WinJS.UI.ListView"     
    data-win-options="{itemRenderer:playeritemtemplate,
                       layout:{type:WinJS.UI.GridLayout,maxRows:1}}" />

Ez működik kiválóan Windows 8 esetén, de sehol máshol. Arról nem beszélve, hogy a kód elég nehezen olvasható, hiszen a WinJS.UI.ListView vezérlő hozza azt a produktivitást, ami miatt az egészet csináljuk, de fogalmunk sincs, hogy az hogyan működik. Íme egy másik példa, ezúttal egy datepicker:

<div data-win-control="WinJS.UI.DatePicker" 
     data-win-options={maxYear:2020,minYear:2000}" />

Ez is csak Windows 8-on fog bármit is produkálni, miközben dátumválasztásra mindenhol szükség van. Persze vannak tökéletes megoldások: az adatkötés megoldható például KnockoutJS-sel, a dátumválasztás pedig jQueryUI DatePickerrel. Ezek tisztán JavaScript alapú megoldások (beszéltünk is róluk az előadásunkban), tehát nincs platform probléma, feltéve persze, hogy a JavaScript futtatás nem okoz gondot az adott környezetben. Weben mindez természetes, tehát ahol webböngészőt tudunk beágyazni, ott a probléma megoldva. Nézzük sorban:

Silverlight: átfordítjuk a XAML-t HTML-re, a code behindot pedig JavaScriptre és ha a hoszt egy böngésző, akkor máris készen vagyunk. A C#-JavaScript konverzióra Nikhil Kothari Script# projektje szolgáltat megoldást. Ha out-of-browser SL alkalmazásról van szó, akkor sincs nagy gond, hiszen akkor a hoszt az explorer.exe, ami szintén beépítetten támogatja a HTML-t és a JavaScriptet (mindenki emlékszik még a böngésző beépítése körüli jogi hercehurcára). Ez egyben a SL jövője körüli kérdést is megoldja.

WPF: csakúgy mint SL-nél, itt is átfordítjuk a XAML-t HTML-re, a code behindot pedig JS-re, és mivel a hoszt itt is az explorer.exe, futni is fog vidáman. Itt már gyakrabban jöhet elő egy olyan nehézség, ami SL5-nél is, konkrétan a P/Invoke, ez ugyanis kimutat a .NET runtime adta környezetből. Erre még nincs teljeskörű megoldás, egyelőre ott tartunk, hogy aki P/Invoke-ra épít, annak valószínűleg kevésbé fontos a hordozhatóság, de ez még nem kielégítő válasz.

Windows Phone: biztos hallottátok már azt a pletykát, hogy a Windows Phone 8-nál cserélni fogják a kernelt, ami már a Windows 8-ra fog épülni. Ezt egyelőre sem megerősíteni, sem cáfolni nem tudom (ugye értitek Kacsintó arc), a mi szempontunkból csak az a lényeg, hogy ez lesz a legkevésbé fájdalommentes. Ami a Windows Phone 7-et illeti, ott szóba se jöhet egy kernel szintű módosítás, ezért valószínűleg egy runtime réteg fog bekerülni valamelyik frissítésbe, ami gyakorlatilag egy transzparens böngésző lesz a HTML alapú alkalmazások futtatására.

Windows 8: ez a legrizikósabb terület, ugyanis pont itt reklámozta az MS legjobban az új HTML lehetőségeket és most ebből kellene visszalépni a helyes útra, ami persze egy marketing öngyilkosság lenne. Bár erre bármikor lehet azt mondani, hogy eddig csak “preview” változatok láttak napvilágot, ami magában hordozta a változtatás lehetőségeit, és hogy csak az a fontos, hogy a végeredmény hosszú távon jó legyen. A Microsoft Research-ös srácokkal arról beszélgettünk, hogy Sinofsky képes lenne szembemenni a cégen belüli marketing gépezettel a profi végeredmény érdekében.

Felmerülhet persze még kérdésként a sokféle “form factor”, azaz a cél eszközök különböző mérete. Hogyan fognak megjelenni az alkalmazásaink egy kicsi telefonon vagy egy nagyobb monitor képernyőjén? Ezzel kapcsolatban szerencsére pont a Windows 8 miatt már kitalálták a megoldást, érdemes elolvasni Nacsa Sándor idevágó Standards-based adaptive layouts in Windows 8 (and IE10) című írását.

layout

Szintén érdekes problémakör az adattárolás kérdése. Itt az a szerencse, hogy a sok XAML környezet közül már a legkisebb is hozza a közös nevezőt: a Mango óta Windows Phone-on is lehet SQL Compact Editiont használni. Ha pedig külső SQL Serverre van szükség, akkor pedig maradnak a HTTP alapú REST-es API-k az adatbázis elérésére.

Mindezek a projektek gyönyörűen haladnak az MSR-nél, vannak működő megoldásaik nem csak egyszerű, hanem összetettebb alkalmazásokra is. Az igazi probléma az időzítés. Az MSR nem elég nagy ahhoz, hogy az igazi bevételt termelő Windows gépezetet visszatartsa, márpedig ha a Windows 8 megjelenik a Consumer Preview-ban található XAML és a HTML lehetőségekkel, akkor már nincs visszaút, az MS végérvényesen belezöttyen a kátyúba, ahonnan évekig nem mászhat ki (lásd VB6 és ASP támogatás Windows 8-on).

Ennek a meccsnek két eredménye lehet:

1. Marad a mostani felállás, amivel útjára indítják a Windows 8-at mint egy gigantikus kísérletet, és az esetleges problémákat, zsákutcákat majd a Windows 9-ben kijavítják. Ebben az esetben a történelem a Vista-Windows 7 párost ismételné.

2. Sinofsky a sarkára áll és azt mondja, hogy tiszta szerencse, hogy időben észbe kaptunk, szorítsuk egy kicsit háttérbe a saját érdekeinket és adjunk ki egy olyan Windows 8 verziót, ami tényleg hosszú távon jó irányba mutat, hiszen operációs rendszert nem cserélnek sűrűn sem a végfelhasználók, sem a cégek.

Sinofsky már letett valamit az asztalra, és én arra tippelek, hogy elfogadnák az érvelését, bár ez nagy érvágás lenne a Microsoftnak. Ebben az esetben ugyanis jelentősen csúszna a Windows 8 kiadása (az idén biztosan nem lenne belőle semmi), hozzá kellene igazítani az eddig elkészült alkalmazásokat, fejlesztőeszközöket, mindent. Viszont arra is nagyon jó esély van, hogy a végeredmény nagyon jó termék lenne, amivel az MS tiszteletet érdemelhetne ki, ami persze végül a bevételi oldalon is éreztetné a hatását. Így nem meglepő, hogy jelenleg ez a valószínűbb lehetőség.

De mi lesz a fejlesztőkkel ebben az esetben? A XAML halála a WPF és a Silverlight bizonytalan jövője körüli homályos információk óta egyre valószínűbb. A XAML diverzitása a saját halálát okozza, miközben lényegében semmi előnyt nem hordoz a HTML-hez képest, hiszen csak címke parszolásról van szó. Elég csak az ASP.NET MVC 4-ben lévő Razor parserre gondolni és máris tisztán látszik, hogy a HTML alapú megoldások egyszerűen jobbak. (Egyébként a Razor parser is bekerült ebbe a projektbe) Nincs értelme fenntartani egy olyan szintaktikát, ami megosztja a fejlesztői tábort, miközben van egy olyan alternatíva, ami inkább újabb fejlesztőket hozna a Windows platformra.

Ti örülnétek, ha a XAML halála miatt csúszna a Windows 8 kiadása?

 

 

UPDATE: Fontos kiegészítés a fentiekhez: http://bit.ly/xamltohtml

 

Technorati-címkék: ,,,,

Twitter HTTPS-en

Egy ideje nagyon komolyan vesszük, hogy a weboldalaink ne csak a bejelentkezéshez, hanem a bejelentkezés után folyamatosan HTTPS-t használjanak. Nincs kifogás, authentication cookie-t nem küldünk át HTTP-n. Persze ez mindig okoz váratlan meglepetéseket, főleg külső könyvtárak használatakor. Az egyik készülő projektünkben például az Internet Explorer az alábbi üzenettel fogadott bejelentkezés után (én mondom, élmény ezzel a böngészővel tesztelni):

IE: Only secure content is displayed.

Nem kellett sokáig keresni (elég csak rányomni a Show all content gombra), hogy kiderüljön, az oldalra helyezett Twitter widget a bűnös. Derítsük ki miért!

Elsőre egyszerűnek tűnt a megoldás, hiszen a widget kódja a http://widgets.twimg.com oldalról töltődött le. Nosza írjunk elé HTTPS-t (mint a Facebook esetén) és kész is. Hát nem, akkor ugyanis egyáltalán nem töltődik be a script az oldalon, ez tisztán látszik az IE DevTools Network fülén és Firebugban is. Annak ellenére, hogy azon a szerveren van SSL. Hm, akkor mi lehet a gond? Nézzük meg a tanúsítványt:

cloudfront-cert

Bizony, itt van az eb elhantolva! A widgets.twimg.com szerveren lévő tanúsítvány valójában a *.cloudfront.net címre szól, azaz a fájlok az Amazon CDN-jéről töltődnének le, ha tudnának. Ha ráhibáznánk a * értékére, meg is lenne oldva a probléma. Tudja-e ezt valaki?

Szerencsére van egy másik domain, ahol rendben van a tanúsítvány:

https://twitter-widgets.s3.amazonaws.com/j/2/widget.js

Itt már nem panaszkodik a böngésző.

 

Technorati-címkék: ,

Csiripelő alkalmazás

A Twitter, a Messenger és a vuvuzela számomra egy kategória: mások által érthetetlen okokból imádott zajkeltő eszközök. Most az egyik projektünkben mégis azt kellett megoldanunk, hogy az alkalmazás időnként csiripeljen egyet a Twitteren.

Ennek megvalósítására nagyon sok példát lehet találni a neten, a legtöbb szépséghibája azonban, hogy a kihalásra ítélt basic hitelesítést használja, ami helyett már az OAuth a preferált. Az OAuthnak kétségkívül vannak előnyei, azonban a használata messze nem olyan egyszerű, mint a minden kliens által támogatott basic hitelesítésnek. Nézzük sorban!

Először is persze kell egy Twitter account, ahova az alkalmazás írogatni fog. Ezek után a Settings –> Connections oldalon regisztrálnunk kell a kliens alkalmazást. Nálunk egy webalkalmazásról volt szó, ezért az Application Type: Client, a Default Access Type pedig Read & Write lett. Bár a miénk egy webalkalmazás, azért lett a típusa Client és nem Browser, mert nem akartuk, hogy a felhasználó böngészője ide-oda ugráljon az saját weblapunk és a Twitter között, hanem az volt a cél, hogy a háttérben észrevétlenül kikerüljön egy csirip a Twitterre, ha történik valami a mi webhelyünkön. Fontos, hogy ha az alkalmazás csak posztol a Twitterre, de másra nem használja, akkor a Use Twitter for login opciót ne kapcsoljuk be. Ha ügyesek voltunk, akkor a varázsló végén kapunk egy oldalt a következő paraméterekkel:

  • Consumer key
  • Consumer secret
  • Request token URL
  • Access token URL
  • Authorize URL

Ez mind kell az OAuth-hoz. Sőt, ha egy konkrét alkalmazás a kliens, akkor kell még 2 adat, egy Access token és egy Access token secret, nosza szerezzük meg őket! Látogassunk el a http://dev.twitter.com/apps oldalra (biztos be is van linkelve valahova, csak én nem találtam meg), majd kattintsunk az alkalmazásunk mellett található Edit details linkre, majd a betöltődő oldalon az Application detail, végül pedig a My Access Token linkre. Jegyezzük fel gondosan az oauth_token és oauth_token_secret értékeket.

Megvan tehát mindenünk, irány a Visual Studio, írhatjuk a kódunkat, az sokkal egyszerűbb lesz. Mivel az OAuth protokollt és a teljes Twitter API-t valahogy nem volt kedvem implementálni, némi keresgélés és tesztelés után a választásom a Twitterizerre esett.

Próbaként készítsünk egy konzol alkalmazást, referenciaként adjuk hozzá a Twitterizer2.dll-t és persze kell egy using Twitterizer; sor is.

Az a jó a Twitterizerben, hogy az egész OAuth mizéria számunkra ennyit jelent:

  OAuthTokens tokens = new OAuthTokens()
  {
    ConsumerKey = @"jrnGHJxU...",
    ConsumerSecret = @"c0nsmR...",
    AccessToken = @"aCtKn...",
    AccessTokenSecret = @"scR3t..."
  };

Ezen kívül a központi objektum a TwitterStatus, például a korábbi csiripeket a GetHomeTimeLine függvénnyel kérdezhetjük le:

  TwitterStatusCollection statuses = TwitterStatus.GetHomeTimeline( tokens );
  foreach( TwitterStatus status in statuses )
  {
    Console.WriteLine( status.Text );
  }

Érdemes tudni, hogy az API-t nem lehet a végtelenségig megpörgetni, hanem mint sok más helyen, itt is vannak limitek, amiket így kérdezhetünk le:

  TwitterRateLimitStatus limit = TwitterRateLimitStatus.GetStatus( tokens );

A kapott limit objektum ilyen értékeket tartalmaz:

  {Twitterizer.TwitterRateLimitStatus}
    base {Twitterizer.Core.TwitterObject}: {Twitterizer.TwitterRateLimitStatus}
    HourlyLimit: 175
    RemainingHits: 174
    ResetTime: {2010.06.24. 18:05:52}
    ResetTimeString: "Thu Jun 24 16:05:52 +0000 2010"

Ezt a korlátot figyelembe véve már küldhetjük is az üzenetünket a nagyvilágnak:

  TwitterStatus result = TwitterStatus.Update( tokens, "Működik!" );

A kapott TwitterStatus objektum tulajdonságaiból sok minden kiderül, talán a legfontosabb a poszt egyedi azonosítója (Id), illetve hogy belefértünk-e a 140 karakterbe (IsTruncated).

Jó csiripelést!

 

Technorati-címkék: ,,