daron yöndem | Microsoft Regional Director | Silverlight MVP
Microsoft Regional Director | Nokia Developer Champion | Azure MVP

Daha önceki yazılarımda Cloud Services için geçerli olan VIP SWAP'ten bahsetmiştim. Azure'da Production ve Staging ortamları yaratbileceğimizi ve bunlar arası hızlıca geçiş yapabileceğimizi görmüştük. Tüm bunları Azure Web Sites için de yapabileceğinizi biliyor muydunuz? Yeni Azure Management Portal ile beraber artık Azure Web Sites için de "Deployment Slots" kavramı var. Bu yazıda Deployment Slots'un ne olduğuna ve nasıl kullanacağına göz atacağız.

Deployment Slots konseptini kullanabilmeniz için sitenizin "Standard Mode" fiyatlandırma seviyesinde olması gerekiyor. Bunun için tek çekirdekli bir makine seçerek sitenizi scale etmeniz gerekecek. Sonrasında hemen portalda sitenizin altındaki "Deployment Slots" listesinden yeni bir slot ekleyebilirsiniz.

Staging Deployment Slot ekliyoruz.
Staging Deployment Slot ekliyoruz.

Yeni slot eklerken slota vereceğiniz ismin yanı sıra yeni slottaki uygulamanın konfigürasyon ayarlarının da productiondan kopyalanıp kopyalanmayacağını seçme şansınız var. Aslında Azure Web Sites içerisindeki yapı Cloud Services'dan daha esnek çünkü sadece Production ve Staging bakış açışı ile yaklaşılmış değil. İstediğiniz kadar deplyoment slot yaratabilirsiniz. Bunun bir nedeni de ileride bahsedeceğimiz A/B Testing senaryoları.

SWAP Zamanı
SWAP Zamanı

Her şey hazır olduğunda üst bardaki "SWAP" düğmesine basarak hedef bir deployment slot seçip değiş tokuşu gerçekleştirebilirsiniz. Buradaki yapı Cloud Services'daki VIP SWAP ile bire bir aynı. İç tarafta bir DNS/IP değişliğinden öte değil SWAP işlemi. Yani konfigürasyonlarınıza dikkat etmenizde fayda var. Aksi halde Staging database'ine giden Staging ortamınınz bir anda Production'a geçip Staging database'ine giden bir Prod ortamına kavuşabilirsiniz :) Korkutucu gözüktüğünden eminim. O nedenle dikkatli olmakta fayda var.

Dikkat Dikkat!

Şimdi ben güzel güzel deployment slot'un adını "Staging" diye koydum da :) dikkatinizi çektiyse söz konusu slotun URL'i de http://darontest-staging.azurewebsites.net oldu. Buradaki tehlike ne mi? Bu adresi tahmin etmek hiç de zor değil. Cloud Services tarafında Staging ortamlarına verilen URL'lerde birer GUID var. O nedenle o adreslerin tahmin edilmesi zor ama burada "staging" adının kullanılması tehlikeli olabilir. Ama zaten o adı biz vermedik mi? Evet :) Yani özetle,  staging amacı ile yeni bir deployment slot yaratırken adını "staging" koymak ne kadar pratik olsa da bana kalırsa random bir Suffix ile kullanın. Böylece dışarıdan deployment adınızı bilen birisi sonuna staging ekleyerek staging ortamınıza ulaşamasın.

A/B Testing

Deployment slotslar ile yapabileceğiniz bir diğer şey de A/B Testing. Sitenizin farklı sürümlerini farklı slotlara deploy ederek trafiğin belirli bir kısmını bir slota diğer bir kısmını da başka bir slota yönlendirebilirsiniz. Böylece %10luk bir trafiği bir slota yönlendirerek gerçek trafik ile test sürüşü yapma şansınız olabilir. A/B Testing sadece sitenin işlevselliği anlamında değil genel olarak kullanımı anlamında da test edilmesi için kullanılabilir. Örneğin her bir slota farklı Analytics hesapları bağlayarak belirli bir süre 10% trafiği bir slota gönderip toplanan veriyi karşılaştırarak sitenizle ilgili hangi tasarım değişikliğinin daha doğru olacağına karar verebilirsiniz.

Testing in production...
Testing in production...

Ne kadar adı korkutucu gözükse de :) bu özelliği Azure tarafında "Testing in production" denmiş. Yukarıda ekran görüntüsünde de görebileceğiniz üzere ben trafiğin 10%'unu staging ortamına yönlendirme kararı aldım :) Unutmayın ki istediğiniz kadar deployment slot yaratarak istediğiniz gibi trafiği dağıtabilirsiniz.

Hepinize kolay gelsin.

Webjobs konusunda daha önce sizlerle birkaç makale paylaşmıştım. Tam yeni bir makale ile konuya devam edelim diyecektim ki Azure SDK 2.5 çıktı :) Yeni sürüm ile beraber WebJobs tarafında da süper yenilikler geldi. Yeniliklerin çoğu doğrudan Visual Studio içerisindeki WebJobs geliştirme deneyimine dair yeni araçlardan oluşuyor. Gelin bu yazıda Azure SDK 2.5'te WebJobs ile ilgili ne yenilikler varmış bir göz atalım.

Publish as Azure WebJobs
Publish as Azure WebJobs

İlk göreceğiniz yenilik "Solution Explorer" içerisinde herhangi bir WebJobs projesine sağ tıklayınca karşınıza gelecek. Artık WebJobs Publish etmek için bir Wizard / Sihirbaz var :) Aşağıda ekran görüntüsünü görebileceğiniz sihirbaz farklı Job tipleri arasındaki geçişleri ve ayarları kolaylaştırıyor.

WebJobs Publishing Wizard
WebJobs Publishing Wizard

Sihirbaz içerisinde yapılan tüm ayarlar webjob-publish-settings.json dosyasında proje içerisinde saklanıyor. İsterseniz sonradan elle değiştirme şansınız da var.

[webjob-publish-settings.json ]

{
  "$schema""http://schemastore.org/schemas/json/webjob-publish-settings.json",
  "webJobName""WebJobsTestApp",
  "startTime"null,
  "endTime"null,
  "jobRecurrenceFrequency"null,
  "interval"null,
  "runMode""OnDemand"
}

Bir diğer yenilik de artık WebJobs'ların "Server Explorer"da kendini göstermiş olması. Buradan rahatlıkla WebJobs'ları listeleyerek OnDemand Job'ları da Visual Studio içerisinden çalıştırabiliyorsunuz.

Server Explorer'da WebJobs
Server Explorer'da WebJobs

Son güzellik ise artık WebJobs'ları doğrudan Visual Studio içerisinden Debug edebilmek. Bunun için WebJobs çalışırken Server Explorer'da söz konusu Job'a sağ tıklayıp "Attach Debugger" demeniz yeterli olacak. Böylece WebJobs için de Remote Debugging yapabileceksiniz.

WebJobs Debugging
WebJobs Debugging

SDK 2.5 içerisinde Webjobs yenilikleri bunlar. Webjobs da kendi içinde olgun bir ürün/servis olmaya doğru ilerliyor. Özellikle şu son gelen yeniliklerle WebJobs SDK'de GA olduğuna göre ürünün ilk sürümü her şeyi ile ortada demektir.

Görüşmek üzere!

Geçen hafta MVP Summit 2014 için Seattle, Redmond'daydım. MVP olduğum sekiz yıldır MVP Summit'e gidiyorum :) Daha önceleri bazılarında kısa blog yazıları ile sizlerle ortamı paylaşmaya çalıştım. Bu sene ise biraz daha farklı bir atraskyona giriyim dedim :) ve günü birlik VideoBlog'lar kaydettim. Hatta her gün de Youtube kanalımdan yayınladım. Takip edemeyenler için bu videoları ayrı bir playlist olarak aşağıda blogdan da paylaşmak istiyorum.

Maalesef Summit'in konsepti gereği Summit'deki oturumların içeriklerini paylaşma şansım yok. Ama yukarıdaki videolarla en azından sizlerle ortamı ve summit deneyimini az çok paylaşabilirim. Umarım sizler de beğenirsiniz :) Görüşmek üzere.

Her şey çok gizli...
Her şey çok gizli...

Bir önceki yazıda Azure API Management konusuna hızlı bir giriş yapmıştık. Basit bir servisi alıp wrap etmiştik. Bu yazıda biraz daha derinlere girip sadece UrlReWrite değil farklı transformasyonlara da göz atacağız. Bunun için API Management portalındaki Policies sekmesine yönelmemiz gerekiyor.

Policy'ler ile bir çok farklı hareket yapmak mümkün.
Policy'ler ile bir çok farklı hareket yapmak mümkün.

Policies ekranına geçtiğinde portalınızdaki bir ürün, API ve sonrasında da API'ın operasyonunu seçmeniz gerekiyor. Bir önceki makalede hazırladığımız HavaDurumu servisinden ilerleyecek olursak bizim zaten bir GET operasyonumuz vardı. Hatırlarsanız kullandığımız harici servis XML çıktı veriyordu. Gelin biz bu XML'i bizim API'larımızdan gerektiğinde JSON olarak verilebilecek hale getirelim. Bunun için "Configure Policy" düğmesine tıklayarak sağ tarafta bulunan olası policy askyonlarından "Convert XML to JSON"ı alıp orta kısma sürüklemeniz gerekiyor. Burada editör çok da süper bir editör değil açıkçası :) O nedenle XML dokümanı içerisinde doğru şeyleri doğru yerlere koymazsanız hata alırsınız.

<policies>
    <inbound>
        <base />
        <rewrite-uri template="forecast?q={sehir}&amp;mode=xml" />
    </inbound>
    <outbound>
        <xml-to-json kind="direct" apply="content-type-xml" consider-accept-header="true" />
        <base />
    </outbound>
</policies>

Kullanacağımız final policy dosyası yukarıdaki gibi olacak. Outbound tagının içerisinde çıkışta XML-JSON çeviri işlemi yapacağımızı ekliyoruz. Bu işlemi yaparken de API'mıza gelen talepteki Accept Header'ına saygı duyacağımızı belirtmemizde fayda var. Aksi halde sürekli JSON vermek durumunda kalabiliriz. Bence isteyenin kendi istediği çıktıyı seçebilmesi önemli.

JSON Output hazır.
JSON Output hazır.

Artık dışarıdan API'mız çağrıldığında eğer Accept Header'da app/json varsa API'mız kendisine gelen XML'i JSON'a çevirerek dışarıya verecek. Böylece aslında bakarsanız olası bir senaryoda şirket içerisindeki bir XML çıktıya sahip servisi alıp güzel bir JSON API'ına UrlRewrite ile REST API konseptine uygun bir şekilde toparlayarak işimizi hızlıca bitirebiliyoruz. Gelin bir adım daha ileri giderek bir de output cache ekleyelim API'mıza. Sürekli içerideki diğer servise gitmek istemeyebiliriz.

<policies>
    <inbound>
        <cache-lookup vary-by-developer="true" vary-by-developer-groups="false" downstream-caching-type="public">
            <vary-by-header>Accept</vary-by-header>
            <vary-by-header>Accept-Charset</vary-by-header>
        </cache-lookup>
        <base />
        <rewrite-uri template="forecast?q={sehir}&amp;mode=xml" />
    </inbound>
    <outbound>
        <xml-to-json kind="direct" apply="content-type-xml" consider-accept-header="true" />
        <base />
        <cache-store duration="90" caching-mode="cache-on" />
    </outbound>
</policies>

Bu sefer policymizin iki farklı ayağına da dokunmamız gerekiyor. InBound ayağında eğer varsa önbelleklenmiş bir şey onu dışarıya aktarmamız gerek. O nedenle InBound'da Cache-Lookup yapıyoruz. Lookup yaparken cache'in neye göre invalide olacağına karar verebilirsiniz. Benim örneğimde ilk olarak her developer için ayrı önbelleklenme şartı koştum fakat developer grouplarına göre ise önbelleği ayırmadım. Developer Group konsepti Azure Management API'ın Management ekranında var olan bir gruplama yapısı. Son olarak Accept Header'ının ve Charset'in de ayrı ayrı önbelleklenmesi şart :) JSON isteyene XML vermek istemiyorsanız :)

Önbellek ayarlarını yaptıktan sonra sıra geliyor çıkış noktasında önbellek çıktısını açıp önbellek süresini belirlemeye. Bizim örneğimizde önbellek süresi 90 saniye.

Önbellekleme 90 saniyede.
Önbellekleme 90 saniyede.

Yukarıdakiler gibi bir çok policy aksyonu mevcut. Bunların içerisinde full text replace bile var :) Açıkçası XSLT tadında bir şema transformasyon aracı olsaydı tadından yenmezdi :) ve belki de şu an bulunan çoğu policy aksyonunu daha generic bir seçenekle sağlamış olabilirlerdi. Fakat öyle bir şey yok :) Nitekim API Management'a aşırı yük yüklemek de çok doğru olmayabilir. Özellikle önbelleklemeyi açmazsanız ve çok fazla response processing yaparsanız yavaşlıklarla baş başa kalabilirsiniz veya sırf bu nedenle scale etmek zorunda da kalabilirsiniz. O nedenle belki de en önemli noktalardan biri doğru önbellekleme politikasını tanımlamış olmak. Tabi önbelleğinizi toplam miktarı da bir noktaca scale etmenize neden olabilir :) Tabi günün sonunda bu servisleri sattığınızı düşünürsek pek de büyük dert olmasa gerek.

Görüşmek üzere.

Azure API Management olarak bundan bir süre önce hizmete açılan ürün aslında Microsoft'un sonradan satın aldığı Apiphany firmasına ait. Ürünün amacı elinde veri olan firmaların kolayca bu veriyi JSON REST API'lar ile dışarıya açabilmesini sağlamak. Hali hazırda hiç API'nız olmayabilir, WSDL'leriniz olabilir veya kafanıza göre yazdığınız API'lar vardır :) tüm bunları toplayıp üzerine adam gibi bir dokümantasyon portalı koymak, portal üzerinden lisans modelleri yaratıp verinizi o modellere uygun fiyatlandırmalarla satmak, kullanım miktarlarını ölçmek ve sınırlamak vs gibi elinizdeki API olarak hizmet formatında kullandırmak istediğinize ihtiyacınız olabilecek neredeyse her şey API Management ürünü içerisine yer alıyor. Ürün bir anlamda veriniz ile dış dünya arasında proxy işlemi görürken transformasyon, ölçümleme, authorization gibi bir çok ek işlevsellik sunuyor.

Azure API Management
Azure API Management

Her Azure ürününde olduğu gibi API Management için de Azure portalından gibip bir service account edinebiliyorsunuz. Toplamda sadece iki tane fiyatlandırma seviyesi var; Developer ve Standard. Developer sürümü ile Standard arasında işlevsellik açısından bir farklılık yok. Sadece kullanabileceğiniz kotalar ve ödeyeceğiniz rakam değişiyor. Standard modelde Unit başında günlük 22$ ödeyerek aylık 200 Milyon API Request, 1TB veri transferi, 10GB önbellek sahibi oluyorsunuz. Şu an için dört ünitenin üzerine çıkmak isterseniz doğrudan Support Ticket açmanız gerekiyor. Eğer fazladan bandwidth kullanırsanız o durumda da standard Azure bandwidth maliyetleri karşınıza çıkıyor.

Hello World!

Bu yazıda API Management'daki konseptler ve ürünün genel manzarasından öte hızlı bir demo ile çok basit bir şekilde ürünün ne yaptığını kabaca göstermek istiyorum. Detayları ve konseptleri sonraki yazılarda inceleriz. Örneğimizde kullanacağımız servis internete açık bir hava durumu servisi olacak. Bu servisi şirketiniz içerisinde, normal şartlarda dışarıya açık olmayan bir servis olarak hayal edebilirsiniz.

http://api.openweathermap.org/data/2.5/forecast?q=istanbul&mode=xml

Yukarıda da gördüğünüz servis epey basit. Şimdi bu arkadaşı alıp hem URLReWrite yapacağız, hem satılabilir bir API ürünün içine koyacağız, hem önünde key based authentication alacağız :) Tüm bunları yaparken bu API'yı bir de API Developer Portal sahibi haline getireceğiz. Tahmin edeceğiniz üzere tüm bu işlemleri zaten API Management otomatik olarak hallediyor.

API Management portalına geçelim.
API Management portalına geçelim.

API Management Service Account'unuzun provisioning işlemi sonrasında ekrana karşınıza yukarıdaki görüntü gelecek. Buradan hemen Management Console'a geçmenize fayda var. Tüm işimiz Management Console içerisinde olacak.

Yeni bir API ekleyelim.
Yeni bir API ekleyelim.

Yeni API'mızı eklerken istediğimiz ismi ve URL'i tanımlayabiliriz. Daha önce de dediğim gibi aslında en basit hali ile API Management API'lar arası proxy görevi yapıyor. Proxy olmanın avantajı ile tabi ki var olan bir API'ın üzerine bir çok özellik ekleyebiliyor. Bir sonraki adımda karşınıza gelen sayfada API'mızın ana ayarlarını yapacağız.

API'mızın ana ayarları burada.
API'mızın ana ayarları burada.

API'ya verdiğimiz isin developer portalımızda gözükecek. Web Service URL kısmına ise kullanacağımız servisi root URL'ini veriyoruz. Son olarak da URL Suffix kısmına bizim API adresimizde bu API'ın barındırılacağı konumu belirliyoruz. Zaten kabaca ekranın altında URL'in son halini görebilirsiniz. "Save" diyerek devam ettiğiniz sıra gelecek bu API için farklı operasyonları tanımlamaya. Hemen "Operations" tabından "Add Operation" diyerek sonraki adıma geçebilirsiniz.

GET Operasyonumuzu tanımlıyoruz.
GET Operasyonumuzu tanımlıyoruz.

URL Template kısmında gördüğünüz operasyon tipi bizim dışarıya açacağımız ve aynı anda hava durumu servisine de göndereceğimiz HTTP operasyonu olan GET. Template'ın diğer kısmı ise bizim dışarıya açacağımız şablon. Biz dışarıdan sadece şehir bilgisi verilmesini ve bunun bir QueryString parametresi olarak değil de URL'in bir parçası olarak gelmesini istiyoruz. Bir alt adımda Url ReWrite Template ise ana kaynağımız olan API'ya nasıl gidileceğini tanımlıyoruz. Her iki template içerisinde de aynı "{sehir}" parametresini neden kullandığımı sanırım tahmin edebilmişsinizdir :) Son olarak "Display Name" e developer portalında bu API'ın nasıl gözükeceğini yazıyoruz.

Şimdilik bu kadarı yeter. API Management'ı daha fazla mıncıklamadan bu hazırladığımız API'yı nasıl kullanabiliriz ona göz atalım. İlk olarak bu API'yı bir ürüne eklememiz gerek. Doğru okudunuz; "Bir Ürün" dedim. API'larınızı dışarıya açıyorsanız bunlar bir ürün olarak düşünülmeli. En azından API Management konseptinde belirli API setlerininin beraber gruplanarak bir ürün olarak açılacağı düşünülmüş. O nedenle hemen Management portalında "Products" sekmesine geçiyoruz. Bu bölümde "Unlimited" ve "Starter" diye iki ürünün hali hazırda tanımlı olduğunu göreceksiniz. Bu ürünlerden "Unlimited"'ı seçerek "Add API to Product" dediğinizde karşınıza "Hava Durumu" API'mız gelecek. Seçip "Save" derseniz söz konusu API'yı Unlimited adındaki API ürünümüze eklemiş olacağız. Hemen ekranın sağ üstünde "Developer Portal" linki göreceksiniz. Tıklayın!

API Management Developer Portal karşınızda.
API Management Developer Portal karşınızda.

Portala girdiğinizde üst kısımdan "API" sekmesine tıklarsanız tüm API'larımız bir listesi gelecek. Oradan "Hava Durumu"nu seçin ve "Open Console" diyin. Karşınıza API'nızı çağırabileceğiniz bir test ortamı gelecek. Bu sayfadaki bilgilere dikkat ederseniz bizim kaynak olarak kullandığımız API'n adı bile geçmiyor. Tabiri caiz ise API'yı API ile wrap ettik :) Üzerine farkında olmaran subscription base authentication bile koyduk. Nasıl mı? Şu an bu API'yı konsoldan çalıştırmaya kalkarsanız çalışmadığını göreceksiniz çünkü size özel verilecek subscription key olmadan API'lara ulaşamazsınız. Bunun için normalde kullanıcının yani developerın portalınıza kayıt olması vs gerekiyor ama biz kendimiz için hızlıca key alabiliriz. Hemen portalın sonuna /developer yazın (benim örneğimde https://darontest.portal.azure-api.net/developer) ve o adresten key'inizi alın. Key'i aldıktan sonra konsol kısmında uygun yerleri doldurursanız istediğiniz şehrin adını da yazıp API'yı çağırabilirsiniz. Siz bu API'yı kendi keyiniz ile çağırdığınız API Management arkada bizim kaynak API'yı kullanarak veriyi alıp verecek.

İşte böyle....

Sanırım az çok Azure API Management'ın nasıl bir sorunu çözmeye çalıştığını anlatabilmişimdir. Konuyu konsept olarak anlatmaktansa bir örnek üzerinden gitmenin daha iyi olacağını düşündüm. Tabi ki bu yazıda anlatmadığım milyon tane şey var. API Management basit bir proxy olmanın çok ötesinde. Diğer yandan API Management "API Yazmamıza gerek yok mu artık?" gibi bir sorunun nedeni de olamaz. API Management'ı bir anlamda API'nızı enstrümante eden bir ürün olarak görebilirsiniz. Kurum olarak dışarıya açacağınız API'ların güzel bir şekilde kontrolü, transformasonu, throttle işlemlerini vs yapmak istiyorsanız API Management süper bir çözüm olacaktır. API yazanlar bilir :) API yazmakla bitmiyor, monitorin, caching, throttling, billing vs derken işler iyice karışabiliyor ve esas yapmak istediklerinizden, sunmak istediğiniz değerden bir süre uzaklaşmanıza neden olabiliyor. API Management bu sorunların çözümü olabilir.

Görüşmek üzere.

Hatırlarsanız bundan bir süre önce Azure WebJobs konusundan bahsetmiş, hatta ilk girişi yapmanın yanı sıra Blob'lara WebJobs SDK kullanımına da göz atmıştık. Bu yazıda ise aynı konuya davem ederken Azure WebJobs ile beraber Azure Storage'daki Queue yapılarını, yani kuyrukları nasıl kullanabileceğimize göz atacağız. Queue Storage servisine hiç göz atmamış olanlarla ilk başta Queue Servisi yazısını sonra da Role'ler arası iletişimde nasıl kullanıldığına dair yazıyı okumanızı tavsiye ederim. Böylece Azure Storage Queue yapısının hangi problemleri çözmeye çalıştığını ve nasıl bir şey olduğunu hızlıca öğrenebilirsiniz.

WebJobs'ın kuyruklarla çalışma şekli bloblarla çalışma şekli ile az çok aynı. Kuyruktaki Message'ları teker teker WebJob'ınızı çalıştırılmasına neden olurken kuryuktaki mesaj doğrudan WebJob tanımındaki fonsiyonunuza parametre olarak geçiyor.

[C#]

public static void KuyruktanGelen([QueueInput("kuyrugum")] string parametre)
{

}

Metodun parametresini isterseniz yukarıdaki gibi dekore ederek QueueInput'a kullanmak istediğiniz kuyruğun adını verebiliyorsunuz. Parametre tipi eğer string olarak bırakılırsa aslında arka planda kullanılan CloudQueueMessage üzerinden AsString ile alınan sonuç size iletiliyor. Alternatif olarak "object" tipinde tanımlarsanız paramtreyi bu sefer de AsBytes ile Byte Array döndürülecektir.

 Kuyruklarla çalışanlarınız hatırlayacaktır, kuyruktaki mesajların alınma süreleri, expire süreleri var. Eğer belirli bir zamanda kuyruktan alınan mesajı işleyemezseniz UpdateMessage ile expire süresini uzatmak zorundasınız. Tüm bu işlemler WebJobs SDK tarafından otomatik olarak gerçekleştiriliyor. Yani yukarıdaki metod ne kadar uzun sürerse sürsün arka planda WebJobsSDK sürekli UpdateMessage ile kuyruktan aldığınız mesajın expire süresini öteleyecektir. Aslına WebJobs SDK'in yaptıkları bu kadarla da kalmıyor. Eğer metod içerisinde herhangi bir noktada Exception throw ederseniz doğrudan mesaj kuyruğa geri bırakılıyor. Özetle yapılmaya çalışılan aslında olabildiğince sizi doğrudan gerçekeştirmeniz gerekecek kuyruk operasyonlarından uzaklaştırmak ve böylece işinizi kolaylaştırmak.

POCO desteği de var!

Çoğumuz kuyruklara mesaj atarken Serialized bir obje atıyoruz. Basit stringler atmıyoruz. Bu durumun farkında olan SDK ekibi ciddi güzel bir hareket yapmış ve Serialize-Deserialize olaylarını da transparan hale getirmeye çalışmış. Bence çok da iyi iş çıkarmışlar.

[C#]

public class OrnekKuyrukMesaji
{
    public string Icerik1 { getset; }
    public string Icerik2 { getset; }
}
public static void KuyruktanGelen([QueueInput("queuename")] OrnekKuyrukMesaji parametre)
{

}

Bence bu çok şık bir hareket. Atla deve değil. Sonuç itibari ile gelen String biz de DeSerialize edebilirdik ama böyle ufak şeyler hem kodu daha temiz tutarken hem de sonuç itibari ile günlük işleri kolaylaştırıyor.

Kuyruğa geri mesaj atmak istersek?

Diyelim ki kuyruktan mesajı aldınız, işlediniz ve başka bir kuyruğa atacaksınız veya Blobları da kullanıyorsunuz ve bloblardan gelen bir trigger sonrasında bir kuyruğa mesaj atmak istediniz. Özetle, şu ana kadar kuyruklardan nasıl mesaj alırız kısmına baktık. Şimdi ise nasıl mesaj atabileceğimize göz atacağız.

[C#]

public class OrnekKuyrukMesaji
{
    public string Icerik1 { getset; }
    public string Icerik2 { getset; }
}

public class GidenMesaj
{
    public string Icerik1 { getset; }
    public string Icerik2 { getset; }
}
public static void KuyruktanGelenKuyrugaGider(
    [QueueInput("gelenkuyruk")] OrnekKuyrukMesaji parametre,
    [QueueOutput("gidenkuyruk")] out GidenMesaj gidenParametre,
    [QueueOutput("log")] out string log)
{
    gidenParametre = new GidenMesaj();
    gidenParametre.Icerik2 = parametre.Icerik1;
    gidenParametre.Icerik1 = parametre.Icerik1;
    log = gidenParametre.Icerik1;
}

Yukarıdaki örnekteki iki farklı POCO'yu bir kenara koyalım. En son metoda baktığınızda bir değil tam üç tane kuyrukla alakamız olduğunu göreceksiniz. Bu kuyruklardan ilki "gelenkuyruk" içinden mesaj alacağımız yer olacak. Oradan gelen mesajları "OrnekKuyrukMesaji" nesnesine DeSerialize ediyoruz. Sonra output parametre olarak iki farklı parametremiz var ve ikisi de aslında farklı kuyruklara gidiyor. Birine Seralize olacak bir obje olarak GidenMesaj nesnesini gönderirken diğerine string gönderiyoruz. Bu metod WebJobs tarafından çalıştırıldığında bir kuyruktan alından mesajı transform edip iki ayrı kuyruğa mesaj göndermiş olacağız. Yazdığımız kodun normak Azure SDK'deki Queue operasyonlarına göre inanılmaz derece kısalmış olduğunu söylemem gerek. İtiraf etmek gerekirse WebJobs SDK benim tüm Azure SDK'leri arasında en favori SDK'lerimden biri.

WebJobs candır diyerek :) bir sonraki makaleye kadar görüşmek üzere!

Bundan yaklaşık iki sene önce Azure Drives ile ilgili bir yazı yazmıştım. Özellikle migration veya on-prem (şirket içi) legacy uygulamalar, sistemlerle cloud ortamındaki yapıları konuşturmak için kullanılabilecek bir alt yapıydı Azure Drive. Neden geçmiş zamanlı konuşuyorum? Çünkü Azure Drive hizmeti 2015 yılı içerisinde sonlandırılacak ve onun yerine şu anda Preview olan Azure Files gelecek. Durum bu olunca ben de erkenden Azure Files ile ilgili bir yazı yazarak hem ne nedir sorusunu biraz cevaplayalım, hem de Azure Drive kullandığınız yerleri nasıl Azure Files'a geçirirsiniz göz atalım istedim.

Azure Drives servisi normal Storage Account'lar üzerinden veriliyor. Hizmet şu anda Preview olduğu için ilk olarak Preview hizmetler sayfasından aktif hale getirmeniz gerekecek. Hizmeti aktif hale getirdikten sonra yeni bir Storage Account yaratmanız gerekiyor. Eski hesaplara şu an için Azure Files otomatik olarak eklenmiyor.

Nasıl kullanılır?

Azure Files esasen SMB 2.1 destekleyen bir Folder Share. Yani bildiğimiz Folder Share. Azure Drive kullananlar hatırlayacaktır; Azure Drive yazma-okuma anlamında sadece bir instance/VM'e ataçlanabiliyordu. Bu durum Azure Files'da böyle değil :) İstediğiniz kadar makineye, instance'a ataçlayabilirsiniz Folder Share'leri. Azure Drive ile en büyük farklılıklarından biri zaten bu SMB 2.1 desteği. Bu protokol desteği Azure Drive'ın ITPro'lar tarafından da rahatlıkla kullanılmasını sağlıyor. Karşılaştıracak olursak Azure Drive aslında sadece developerlara hitap eden bir araç olarak kalmıştı ve özünde çözmeye çalıştığı sorunlar düşünüldüğünde ITPro'lar tarafından kullanılamıyor olması aslında çok da akıllıca değildi. Azure Files ile bu sorun çözülürken bu sefer de aklınıza, "Tamam da ben developer olarak REST isterim!" haykırışı gelebilir :) Merak etmeyin, o da var. Zaten benim de odaklanacağım taraf o olarak. ITPro tarafına bulaşma niyetim yok :)

REST API'lar üzerinden Azure Files'a ulaşmak için Storage Client'ın 4.0 ve üstü sürümlerinden birini kullanmanız gerekiyor. Ben bu yazıyı yazarken Storage Account kütüphanesi zaten 4.2 sürümünde.  Gelin ufak bir proje yaratıp Nuget paketini ekleyelim bakalım neler yapabiliyoruz.

[C#]

CloudStorageAccount account = CloudStorageAccount.Parse(this.connString);
CloudFileClient client = account.CreateCloudFileClient();
CloudFileShare share = client.GetShareReference("birklasor");
share.CreateIfNotExistsAsync().Wait();

Storage Account'larla çalışanlar için yukarıdaki kod süper tanıdık gözükecektir. Her zamanki StorageAccount objesi üzerinden normal Blob, Table, Queue ile çalıştığımız zamanlardaki gibi bu sefer de CloudFileClient alıyoruz. Bu client üzerinden var olan veya olmayan bir ShareFolder'ın ismini verip referansını aldıktan sonra IfNotExist ile Share Folder'ı oluşturuyoruz. Hepsi bu kadar aslında. REST üzerinden Folder Share'i yaratmış olduk.

Azure Files Storage Account Endpoint'lerinden biri.
Azure Files Storage Account Endpoint'lerinden biri.

Şimdi bu noktada birkaç uyarıda bulunmam gerek ve bunlar maalesef can sıkıcı olacak. İlk olarak şu anda maalesef Azure Files desteği local Storage Emülatöründe yok. O nedenle herşeyi Cloud ortamına karşı çalıştırmak zorundasınız. Bir diğer sıkıntı ise SMB desteğinin sadece storage accountun bulunduğu bölgede (region) verilmesi. Yani başka bir datacenterdaki VM'i alıp da storage accounttaki Folder Share'i bağlayamazsınız. Bu durum local bilgisayarınız için de geçerli :( Yani yukarıdaki kod REST üzerinden gittiği için bilgisayarınızdan çalıştırdığınızda sıkıntı olmayacaktır ama gidip de bu Folder Share'i kendi bilgisayarınız map etmeye kalkarsanız maalesef sonuç hüsran olacak. İşin o kısmını test etmek için benim tavsiyem Storage Account ile aynı Region'da Visual Studio yüklü bir VM provision etmeniz. İtiraf etmek gerekirse dev/testing açısından bu durum biraz kötü. En azından local emülatör desteği gelirse süper olacak.

Azure Files Folder Share VM'e maplendi.
Azure Files Folder Share VM'e maplendi.

Kod ile REST üzerinden Folder Share'i oluşturduktan sonra hemen test için bir console açıp "net use" ile yukarıdaki ekran görüntüsünde de görebileceğiniz üzere share'i VM'e mapledim. Böylece Azure Files üzerinde bir Folder Share'imiz var artık. Buraya atılan tüm dosyalar, dosya sistemi artık hem SMB hem de REST üzerinden ulaşılabilir durumda. Test sonrası "net use z: /delete" ile mapi kaldırabilirsiniz.

Web ve Worker Role'dan kullanımı?

Aslında yukarıdaki taktikten yola çıkarsak ne yapacağımı tahmin edebilirsiniz sanırım. Net Use'ü doğrudan process olarak çalıştırarak map işlemini Web veya Worker role içerisinde de yapabiliriz. Burada önemli olan nokta WebRole.cs'teki RoleStart'ta yapmamak. Aslında bu genel bir kural değil. Esas sorun Role'ünüz security context'ini elevated hale getirirseniz ortaya çıkıyor. Malum Folder Share Map'leri söz konusu user context içerisinde çalışıyor. RoleEnvironment ile Application farklı security contextlerde çalışırsa doğal olarak birbirlerinin oluşturduğu mapleri göremeyeceklerdir. Eğer Role'ün security contexti yükseltirseniz Role System hesabı ile çalışırken uygulamanız varsayılan kullanıcı hesap ile çalışır. Unutmayan Role WaIISHost.Exe tarafından host edilirken uygulama w3wp.exe tarafından host ediliyor. Bu gibi durumları engellemek için en iyisi mapleme işlemini uygulama içerisinde yapmak. Eğer her iki tarafta da diske ihtiyacınız varsa hem Role Start hem de App Start'da mapleme yapmanız şart.

[C#]

Process p = new Process();
int exitCode;
p.StartInfo.FileName = "net.exe";
p.StartInfo.Arguments = "use z: \\azurefilesdarontest.file.core.windows.net\birklasor 
                                        /u:azurefilesdarontest HhAItw2Q=="
;
p.StartInfo.CreateNoWindow = true;
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardError = true;
p.Start();
string error = p.StandardError.ReadToEnd();
p.WaitForExit(20000);
exitCode = p.ExitCode;
p.Close();

using (StreamWriter outfile = new StreamWriter(@"Z:\deneme.txt"))
{
    outfile.Write("Merhaba Dünya!");
}

Map işlemi bittikten sonra gördüğünüz üzere normal System.IO altındaki her şeyi bu diskte kullanabiliyorum. Artık birden çok instance, role tarafından erişilebilecek bir folder share'imiz var :) Süper! Örneğin bu diski IAAS tarafından alınmış bir VM'e mapleyip, PAAS tarafındaki role instancelarınıza da mapleyip IAAS ortamına kurulu stand-alone bir uygulama ile PAAS taki uygulamanızın birbiri ile basit bir folder share üzerinden konuşmasını sağlayabilirsiniz. Bu senaryo özellikle kodu ve mimarisi sizin yönetiminizde olmayan uygulamalarla entegrasyon için çok anlamlı olabiliyor.

REST üzerinden disk erişimi

SMB haricinde REST desteğinin de olduğundan bahsetmiştik fakat bu noktaya kadar REST üzerinden Share Folder yaratmak dışında bir şey yapmadık. REST üzerinden doğrudak diskteki tüm dosya ve klasörlere full erişim hakkınız da var. Bu seçenek özellikle uygulamanız ayrı bölge (region) içerisinde değilse süper işe yarayacaktır. Malum SMB için aynı region içerisinde olmanız şart.

[C#]

CloudStorageAccount account = CloudStorageAccount.Parse(this.connString);
CloudFileClient client = account.CreateCloudFileClient();
CloudFileShare share = client.GetShareReference("birklasor");
CloudFileDirectory rootDirectory = share.GetRootDirectoryReference();
CloudFile aCloudFile = rootDirectory.GetFileReference("deneme.txt");
Response.Write(aCloudFile.DownloadText());

Yukarıdaki kod içerisinde CloudFileShare'den root klasörü istedikten sonra artık iş CloudFileDirectory ve CloudFile objeleri ile çalışmaya kalıyor. Tüm buradaki objeler üzerinde yaptığınız işlemler doğrudan REST API'lar üzerinden gerçekleştiriliyor. O nedenle bu şekilde Azure Files'a erişen bir uygulamanınz SMB protokolüne bağımlılığı yok.

Blob mu File Share mi?

İtiraf etmem gerek eğer bu soruyu soruyorsanız kafanız epey karışmış demektir :) Ama bu çok da normal. Birincisi Azure Files'da SMB var. Bu aslında servisin çözmeye çalıştığı sorun adına çok şey anlatıyor. Buradaki amaç sadece bir storage sistemi sağlamak değil, hatta storage sistemi sağlamak da değil. Buradaki amaç Bloblar gibi inanılmaz ölçeklenebilirliliğe sahip storage yapılarını kullanamayan, migrate edilemeyen senaryolarda bir çözüm sunabilmek. Daha açıkçası, uygulamaların Cloud'a taşınmasını kolaylaştırmak ve (IAAS/PAAS) hybrid uygulama yapılarını kolaylaştırmak. Teknik karşılaştırma isterseniz eğer; bloblarda bir container 500TB olabilirken burada bir Share azami 5TB olabiliyor. Erişim olarak 60MBps storage'da blob başına gelirken Azure Files'da Share başına geliyor. Diğer yandan bloblarda esasen Directory diye bir konsept yokken burada var. Bloblarda isimler büyük, küçük harf duyarlıyken burada değil. Bloblarda snapshow var, burada yok :) Son olarak bloblarda byte başına para ödeniyor burada toplam size için.

Azure Disk ile Azure Files farkı nedir?

Azure Disk'i hatırlamayanlar için hemen ip ucu veriyim; bir VM yarattığınızda ona ataçladığınız disk bir Azure Disk. Azure Disk'ler tek bir VM tarafından kullanılabiliyorlar. Azure Files ile en büyük farklılıkları aslında bu. Diğer yandan REST üzerinden erişim şansınız da yok ama Azure Disk'ler aslında Blob'lar üzerinde yaşadığı için Snapshot özelliği var. Azure Disk'lerde en büyük disk boyutu 1TB, Azure Files'da Share boyutu 5TB. Veri erişimi hızı aynı olsa da 8KB IOps'da Azure Disk 500 verirken Azure Files 1000 veriyor.

Son olarak, yukarıdaki kodları hemen alıp test etmek isterseniz makaleyi yazarken kullandığım test kodlarını Github'a attım.

Görüşmek üzere.

Azure Mobile Services konusunda bundan önce sizlerle bazı videolar paylaştım, webcastler yaptık ama itiraf etmek gerekirse Azure Mobile Services kullanımını pek de Mobile dışında düşünmedik. Zaten aslına bakarsanız Microsoft da böyle düşünmüyor :) Fakat ürünün ismini bir kenara koyar ve ne yaptığına bakarsak kaba tabiri ile bize REST üzerinde basit ve hızlı olarak data erişimi sağlıyor. Tabi ki data erişimi dışında Mobile Services'da daha bir çok component var ama dedim ya, kaba bir şekilde ürünün olayı bu. Bu noktaya kadar aynı fikirdeysek şimdi geçelim hikayenin diğer açısına.

Geçenlerde bir web sitesi projesi ile ilgili düşünürken sitenin tüm veri erişimini REST üzerinden bir API set ile tasarlamaya karar verdim. Genelde bu gibi mimari tasarımları pek sevmem. Neden mi? Siteye giren ziyaretçinin ilk yaptığı request ile ona ihtiyacı olan veriyi yollamak yerine ihtiyacı olan veriyi alabileceği bir uygulama yolluyor olmak ve sonrasında ikinci, üçüncü HTTP talepleri ile esas ziyaretçinin görmek istediği şeyi vermek bence kullanıcı deneyimi açısından inanılmaz anlamsız ve saçma. Böyle projelerde bulundum :), gördüm, saçma. Yanlış olmasın, özellikle bahsettiğim saçmalık daha ilk sayfa açıldığında yüklenecek verinin sonradan async API call ile yüklenmesi. Bu durum özünde bir "mimari moloz sendromu" :) Ah şu "Mimari Moloz Sendormu" yazısını yazmış olsaydım link verirdim şimdi. Neyse, kısmet :) Konumuza dönersek, peki ben neden bu bahsettiğim web projesinde işleri böyle yapiyim dedim? Aslında nedeni çok da önemli değil çünkü konumuz o değil ama kabaca anlatmak gerekirse söz konusu web sitesinin full HTML olması gerekiyordu :) Dedim ya, uzun hikaye.

Yani?

Şimdi geleceğim nokta şudur ki, tüm veri kaynağını vs REST üzerinden siteye beslemeye karar verince bir baktım normal bir asp.net projesinden daha kompleks (doğal olarak) istemci-sunucu kafasında bir yapı nedeniyle iş yükü gereksiz artıyor. API yaz, tüket vs... ohooo yapacağımız bir web sitesi zaten ve malum HTML'den öteye bile geçemiyor. İşte o anda aklıma aslında tam da bu işleri çözen yani otomatik olarak API açan ve üzerinden veri erişimi vs sağlayan Mobile Services geldi. Dedim ya normalde Mobile Services mobil uygulamalar için tasarlanmış bir yapı ama sonuç itibari ile bu Mobile Services HTML5 ile programlanan Windows8 Tablet uygulamalarında da kullanılabiliyor ve tam da bu nedenle bir JavaScript SDK'yi var!! İşte bu!

Service erişimi anahtarı... Hmm...

Hayalimde taşlar çok güzel yerli yerine oturuyordu ki hemen aklıma Mobile Services endpoint erişimi için kullandığımız management key'ler geldi. O key'leri normal şartlarda biz mobil uygulamanın içine gömüyoruz ve doğrudan erişilemiyor. En azından kolay yoldan erişilemiyor diyelim. Bir web sitesi üzerinden Mobile Services kullandığımızda ise söz konusu key/anahtar apaçık JavaScript kodunun içerisinde durmak zorunda. Bir an hayallerim söndü. Sonra bir silkelendim :) Azure Mobile Services ile daha önce ilgilenenler hatırlayacaktır her entity set, table için permission / izinler ayarlayabiliyoruz. O ayarlar listesinde "Everyone" diye bir seçenek var :) O seçeneği kullanmak mobil uygulama geliştirirken pek de aklımıza gelmiyor çünkü zaten key'i uygulamanın içine gömüyoruz ve her tür erişimi "key ile erişilebilir" diye ayarlıyoruz. Oysa web ortamında "Everyone" olarak ayarlı bir tablo çok daha işimizi görebilir ve keyi alenen paylaşmaktan kurtuluruz. Tabi bu noktada aklınıza "Key yok herkes erişecek aman Allah'ım" gibi korku cümleleri gelebilir :) Tamam da zaten REST API değil de normal web sitesi üzerinden HTML ile sunsaydık veriyi herkes erişemeyecek miydi? Pelki REST olduğu için :) otomatik kötüye kullanımı bilenler için kolaylaştırmış oluyoruz fakat konsept olarak herkesin ulaşmasını istediğiniz veriyi ne formatta açacaksanız açın sonuç itibari ile herkese açacaksınız :) "Everyone" candır diyerek devam edelim. Böylece "key"i JavaScript'in içinde bulundurmaktan kurtulduk.

<script src='//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js'></script>
<script src='http://ajax.aspnetcdn.com/ajax/mobileservices/MobileServices.Web-1.1.0.min.js'></script>

<script type="text/javascript">
   
    var client = new WindowsAzure.MobileServiceClient('https://darondeneme.azure-mobile.net/');
    todoItemTable = client.getTable('todoitem');
    var sorgu = todoItemTable.where({ complete: false });

    sorgu.read().then(function (todoItems) {
        for (var i = 0; i < todoItems.length; i++) {
            alert(todoItems[i].text)
        };
    }, hataolursa);

    function hataolursa(hata) {
        var text = hata + (hata.request ? ' - ' + hata.request.status : '');
        alert(text);
    }
</script>

Yukarıdaki kod süper basit bir şekilde Azure Mobile Services SDK ile beraber gelen Windows 8 HTML5 örneklerinden çırptığım bir kod :) MobileServices Client'ı oluştururken key vermek için kullanılan ikinci parametreyi tamamen sildim. "todoItem" adındaki mobile services varsayılan örneği ile gelen tabloya da "Everyone" okuma izni verdim.

Herkese okuma izni verdik.
Herkese okuma izni verdik.

İşte bu kadar :) artık Azure Mobile Services SDK içerisindeki Windows 8 HTML uygulama geliştirmek için yer alan tüm kaynakları kullanabilir, tüm JavaScript SDK'yi kullanabilir ve her türlü veri erişimizi Mobile Services üzerinden yapabilirsiniz. Özetle web sitenizin arka planı tamamen Azure Mobile Services olmuş oluyor.

Her şey güzel gibi....

İtiraf etmek gerekirse Azure Mobile Services'ın bu şekilde kullanılabileceğinin Microsoft'un aklına geldiğini bile sanmıyorum. Materyallere, dokümanlara vs baktığınızda Azure Mobile Services'ın web sitelerinde kullanımından bahsedildiğini hiç görmedim. Zaten ürünün adı da belli :) Mobile Services. Peki bu işin altından bir sıkıntı çıkar mı? Tek bir olası sıkıntı var; maliyet. Mobile services ücretsiz sürümünde 500.000 API erişimi limiti var. Yani sitenizde bir ayda 500.000 kişi girip sadece ana sayfanıza baksa bile bu limite dayanabilirsiniz. 1.5 milyon API Call ise kabaca 25$. Kesinlikle ucuz değil. Mobile uygulamlarda Mobile Services kullanımı bu fiyatlandırmada çok daha karlı oluyor çünkü o marketteki getiri potansiyeli normal web ortamından daha farklı ve mobile services'ın ölçeklenebilirliği göreceli daha değerli bir pozisyonda oluyor. Normal web sitesi kullanımında ise insan biraz daha teredütte kalıyor. İlla sitenizin verisini API üzerinden verecekseniz ve aceleniz varsa, yeterli yazılım geliştirme kaynaklarınız (zaman vs) yok ama bütçeniz varsa Mobile Services süper uygun bir seçenek olabilir. Bir diğer senaryo ise zaten hali hazırda Mobile Services kullanan mobil uygulamalarınız varken web sitenizi de buradan besleyebilmek olabilir. Böylece mobil uygulaması olan web sitesi olmayan çoğu startup web sitelerini daha hızlı bir şekilde release etme şansına sahip olabilir. Daha eminim ki benim aklıma gelmeyen bir çok senaryo vardır ama genel olarak maliyeti akılda tuttukça ben başka bir olası sorun ile karşılaşılabileceğini düşünmüyorum.

Görüşmek üzere.

Aslında epey oluyor ben Dell Venu 8 Pro'yu satın alalı. Sanırım bir seneyi bulmuştur. Fakat tabi ki sizin de tahmin edebileceğiniz üzere 8" bir bilgisayarı, tableti ana bilgisayarım olarak kullanmıyorum :) Aslına bakarsanız tablet olarak da pek kullanmıyorum. Hayatımda maalesef bir tabletin yeri yok. Nedense kullanamıyorum, zaman veya fırsat olmuyor. Genelde ne yapacak olsam hep bir PC'ye ihtiyacım oluyor. Kitap okuma konusuna da gelince ya okuyacağım kitapların dijital halleri olmuyor ya da zaten AudioBook halleri oluyor ve o şekilde tüketmeyi çok daha uygun buluyorum. Kitap okumak konusundaki fikirlerimi ve deneyimleri daha önce bir yazıda sizlerle paylaşmıştım. Okumayanlar göz atsın derim :) Biz dönelim Dell Venue 8 Pro'ya.

Benim Dell Venue 8 Pro'yu esas satın alma amacım özellikle iş gezilerinde kullanabileceğim ve bir PC'de yapabileceğim her şeyi yapabileceğim bir cihaza sahip olmaktı. Ayrıca tablet kullanamıyorum dediğimi hatırlıyorum :) ama gerçek anlamda bir tablet ihtiyacı hissettiğim ve kullandığım tek yer de 17 saati bulan Amerika uçuşları oluyor. Eh bilenler bilir, çalıştığım şirket nedeniyle iş gezisi demek benim için Seattle'a uçmak demek. Bu da doğrudan 17-18 saatlik uçuş demek. Tüm bu ihtiyaçları toparladığımızda ve yılda en az dört defa bu tip iş gezileri yapmak zorunda kaldığım düşünülürse Dell Venu 8 Pro doğru bir yatırım olarak gözüküyordu. Öyle de oldu. İş gezilerinde tüm ihtiyaçlarımı karşılayabilen bir cihaz olarak başarılı bir şekilde Dell Venue 8 Pro'yu kullanabildim, kullanıyorum. Ufak bir araştırma yaptığımda Türkiye'de şu anda satışta bulamadım Venue8'yi ama satışta olduğunda 750TL gibi güzel bir fiyatla satılmış anladığım kadarıyla.

Teknik özellikler?

İlk merak ettikleriniz tabi ki teknik özellikleri olacak ama öncesinde şu kadarından bahsediyim, cihaz süper ince ve ufak. Zaten adı üzerinde 8". Ben 64GB bellek ile gelen en yüksek bellek seçenekli sürümünü satın aldım. Yanına bir de 64GB MicroSD kart koydum. Böylece benim için kabul edilebilir sayılabilecek 128GB'a ulaşabildim. Cihazın 1280*800 çözünürlüklü IPS ekranı süper parlak ve ışıl ışıl. Cihaz şu göreceli yeni çıkan dört çekirdekli Intel Atom'larla (Z3740D) geliyor. Eski Atom'lar gibi yerlerde sürünmüyor ama inanılmaz performans beklemek de doğru olmaz tabi ki. 2GB bellekli Intel HD Graphics de 8" bir cihaz için fazlası ile idare eder nitelikte. Tabletin üzerinde bir micro-USB bir de kulaklık-mikrofon kombo girişi var. Hepsi bu kadar :)

Kişisel deneyimlerime gelirsek...

Tablet olarak çok kullanmasam da cihaz bence tablet olarak başarılı bir cihaz. Pil ömrü hiç rahatsız etmedi. Kaç saat gidiyor derseniz... valla hiç pili bittiği için şarj etmedim. iPad'den farksız bence. Tabi bu noktada Win8 uygulamalarının zenginliği de etkili olmuş olabilir :) Yani pili tüketecek kadar kullanacak uygulama bulamamış olabilirim. Şaka bir yana ben Kindle uygulaması ile kitap okuyarak bir günde pilini bitiremedim. 10-15 saat çok rahat kitap okumuşumdur bir defada. Tablet olarak bunun dışında pek de kullanmadım zaten. Hafif, ince, pili güzel giden Win8 bir tablet için bence en başarılı cihazlardan biri. Şarj olayı da üzerinde micro-USB ile yapılıyor ama bu noktada bir sıkıntısı var. Şarj konusunda epey seçici Dell Venu8. 2AMP şarj cihazlarının hepsi ile çalışmıyor. Nedeni ile ilgili hiçbir fikrim yok. iPad şarj cihazı yetmiyor örneğin. 1AMP şarj soketleri ise kesinlikle şarj etmiyor. Bence bu çok büyük bir eksik. Örneğin uçakta, koltuk arkalarından USB'lerden şarj edemedim. Dell'in bunu düşünmüş olması gerekirdi.

Cihazı bir PC'den beklediğim her şeyi yapabilir bir cihaz olarak tanımladım ama diskin 128GB olduğunu unutmamak gerek. Ben Visual Studio yüklemedim çünkü zaten Dropbox dosyaların SD kartı tamamen doldurdu ve VS yükleyecek yer kalmadı. VS gerektiğinde Azure'daki VM'ime bağlanıyorum. O nedenle Visual Studio performansı konusunda yorum yapamayacağım. Tahmin etmemi isterseniz eğer, sonuç olarak Atom :) yani compile sürelerinde çılgın hızlar beklemeyin ama zaten 8" cihazda da en fazla bir bugfix check-ini yaparsınız o kadar. Onu da rahatlıkla yaparsınız bence.

Venue8'in şarj sıkıntısı haricinde en büyük sıkıntısı firmware ve driverlarda. Random bir şekilde 2-3 günlük kullanımda en az bir kere Wireless sürücüleri tamamen dağılıyor. Bilgisayara full restart atmadan kendine gelmiyor. Tabi cihazın micro-USB'sini şarj için kullandığım için mouse ve klavye de bluetooth ve tabi ki wireless sürücüleri çatlayınca Bluetooth da çatlıyor. Allah'tan 2-3 günde bir oluyor bu durum da cihazı tamamen kullanılmaz hale getirmiyor.

Peki sunum yapmak isterseniz? Yani bu ufacık cihaza bir harici monitör bağlamak isteseniz? Harici USB ekran kartlarından alıyorsunuz, micro-USB to USB çevirici ile olayı çözebiliyorsunuz. Ama tabi ki harici monitöre var olan tek micro-USB'yi kullanarak bağlanacağınız için bu sürede pilinizi şarj etmeniz mümkün olmuyor. Bence Dell'in bu konuda bir adaptör çıkarması gerekirdi. Maalesef böyle bir adaptör yok. Elle yapanlar var internette ama uğraşır mısınız bilmem.

Yukarıda sürekli problemleri sıraladım ama bunların dışında cihaz bir yolculuk boyunca tüm işlerinizi görebileceğiniz ve Win8 tablet uygulamaları yettiğince tablet olarak da kullanabileceğiniz, şarj süresi vs yerinde güzel bir 8" tablet, PC. Yukarıdaki sorunlar çözülse, üzerine bir de 256GB bellek gelse bu cihazı kimse tutamazmış :)

Peki size tavsiyem nedir?

Açıkçası eğer iPad'iniz yoksa :) büyük ihtimal bir tablet alma ihtiyacı hissetmediniz bugüne kadar demektir. Bu durumda birkaç seçenek var. Ya tablete ihtiyacınız yok ve Venue8 de sizin için gereksiz olabilir. Ya da tablet cihazları sadece tablet olarak yatırıma uygun görmüyorsunuz. Ben ikinci gruba giriyorum. Sanırım iki defa farklı iPad'ler aldım ve her seferinde kullanmadığım, bir kenarda durduğu için elden çıkardım. Yolculuklarda çok işime yarıyordu ama hem tablet hem laptop taşımak anlamsız geliyordu. Diğer yandan sadece yolculuklarda yolda kullanabileceğimiz bir cihazı kenarda tutmak da pek anlamlı gelmedi bana. Dell Venue 8 hem uçuş süresince uçakta tablet olarak kullanabileceğim hem de gittiğim şehirde bir bilgisayar olarak kullanabileceğim bir cihaz olarak çok daha anlamlı oldu :) Hybrid cihazlarla ilgili genelde karışık duygular içerisindeyim. İtiraf etmek gerekirse çok yolculuk yapmasam Dell Venue 8'de süper anlamsız olacak. Tabi benim hayal edemediğim senaryolar da söz konusu olabilir. Ben deneyimlerimi paylaşiyim istedim ;) Umarım işinize yarar.

Görüşmek üzere.

"Körün istediği bir göz allah verdi iki göz" şeklinde esasen uygunsuz bir örnek vererek başlangıç yapıyorum. Blogumu sürekli takip edenler bilirler yoğun istek üzerine geçen ay başında azure mobile services üzerine bir webiner düzenlemiştim. Hatta video kaydını da sonrasında sizlerle paylaşmıştım. Kaçıranlar, "Benim sorum vardı, soramadım." diyenler üzülmesin :) 12 Haziran akşamı 19.30'da bir azure mobile services webineri daha yapıyoruz. Bu sefer tek başıma da değilim. Webinerde bana Microsoft'tan Yazılım Geliştirme Teknolojileri Yöneticisi Selçuk Uzun’un da katılacak. Data, Push Notification, Authorization, Scheduler, Diagnostic & Scale gibi konulara değinerek sorularınızı da alacağız. Her zamanki gibi webiner tamamen ücretsiz!

Webinerde örneklerimizi JavaScript ve C# ile yapacağız ama aklınızda bulunsan Azure Mobil Services'in Android, iPhone SDK'leri de mevcut. Mobil uygulama geliştirme ile ilgilenen herkes için ilginç bir webiner olacağından eminim.

Azure Mobile Services Webiner

Katılım için kayıt olmayı unutmayın! http://msft.it/Microsoft-Azure-Mobil-Servisler-Kayit

Görüşmek üzere.

Twitter
RSS
Youtube
RSS Blog Search
Arşiv'de tüm yazıların listesi var. Yine de blog'da arama yapmak istersen tıkla!
Instagram Instagram