Ana içeriğe atla

Web Öldü, Yaşasın Uygulamalar

Bu makalemizde “Wired” dergisinde kapak başlığı olmuş (Web is dead, long live internet) ve Bloomberg Bussinessweek dergisinde yayınlanmış[2] bir konudan bahsedeceğiz. “Web öldü yaşasın uygulamalar” başlığı ile ele alınan aslında günümüzde teknolojinin eğilimlerini ve bu eğilimlerin yaşam kültürüne yansımalarını farklı bir bakış açısıyla anlatmaktadır.
Derginin bu kapağı yapmasının nedeni son dönemde gördüğümüz ve önemini anlamaya başladığımız “Uygulamalar” ve “Uygulama Kullanma” eğilimidir. Wired dergisinin genel yayın yönetmeni Chris Anderson bu gelişmeyi şöyle anlatıyor:
  • Sabah kalktınız ve e-postalarınızı iPad’den kontrol ettiniz. Yani bir uygulama kullandınız.
  • Ardından kahvaltı sırasında Facebook, Twitter ve New York Times’a göz attınız. Üç uygulama daha kullandınız.
  • Ofise giderken akıllı telefonunuzdan bir podcast dinlediniz. Bir uygulama daha.
  • İşyerinde bir okuma programı üzerinden RSS bilgilerini taradınız ve Skype ile birkaç görüşme yaptınız.
  • Akşam saatlerinde eve geldiniz ve akşam yemeğini hazırlarken bir yandan Pandora’da müzik dinlemeye başladınız, yemekten sonra XBox Live oynadınız ve Netflix’den birkaç dizi seyrettiniz.
Aslında tüm günü internette geçirdiniz ama ‘web’de değildiniz.” Son birkaç yıl içinde, dijital dünyanın en önemli değişimlerin biri, direk browserdan erişmektense uygumlalar yardımı ile bilgileri taşıma şeklindedir.
Geçmişte, Google gibi arama motorlarından önce istenilen bilgiyi etkili ve kısa zamanda bulmak büyük bir külfet idi. Google web’in düzenlenmesi görevini üstlendi ve kısa zamanda rakiplerine büyük bir fark attı. Web büyüyor fakat Google dışında kalan herhangi bir şirket ciddi bir para kazanmıyordu.
Web’in para beklenen ivmeyi sağlayamadığı bu ortamda web’e bir alternatif oluşturulması gerekliliği ortaya çıktı. Burada da kapalı sistemler üzerinden ürünü veya hizmeti satmanın çok daha mantıklı bir model olduğu görüldü. Steve Jobs’un iTunes ile adını koyduğu bu model belki web gibi özgür, açık ve sosuz genişleme hevesinde değildi ama basit bir soruya cevap veriyordu: Para kazanabilir miyim? Evet. İyi bir oyun, bir verimlilik programı yazan bunu binlerce, on binlerce kişiye satıyor ve payını alıyordu. Üstelik Anderson’a göre web mühendisler tarafından tasarlanmıştı ve bilgiyi veya içeriği sunma yönünden çok da ve temiz etkili değildi. Buna karşın uygulamalar, kullanıcının arzu ettiği bilgiyi kolay, temiz ve şık ara yüz ile etkili biçimde veriyordu. Bu yüzden birçok insan web yerine oradaki birçok uygulamayı konsolide eden uygulamalara yöneldi. Bugün bu dünya hızla ve gelir modeli sağlam biçimde büyüyor.
Tüm bu gerçekler bir noktayı işaret ediyor: İnternetin gelecekteki merkezi uygulamalar olacak.
Kaynaklar:
  1. Bloomberg Bussinessweek dergisi, 2010, Serdar Turan, 5-18 Eylül, Sayfa: 32
Armağan DÖKER

Yorumlar

  1. Ben tam aksini düşünüyorum. Tarayıcılar öyle gelişiyor ki artık uygulamalar tarayıcıda çalışıyor.
    Skype hiç kurmadım google talk'ı webden kullanıyorum, Şimdilerde google amerikada gmail üzerinden tel görüşmesini de başlattı...
    RSS'lerimi bilgisayardan değil Google Reader sayfasından takip ediyorum, böylece her oturduğum bilgisayara uygulama kurmak zorunda değilim.
    HTML5'in getirdiği yeniliklerle HTML javascript ve CSS ile oyun bile yapılabiliyor.
    Evet uygulamalar olacak ama hepsi tarayıcılarda çalışacak. Ve ilerdeki bilgisayarlarda sadece tarayıcı olması yetecek.

    YanıtlaSil
  2. Merhaba Fikret bey, Görüslerinize kismen katiliyorum. Aslinda olayi web ve uygulamar diye ayirirken ki en kritik nokta; mobil cihazlarin hayatimizdaki öneminin giderek arttirmasi. Iphone, ipad, nexus one - android, motorola-droid, windows mobile yatirimlari ve üzerlerindeki uygulamalarin sayisinin artmasinin temel nedeni, bu cihazlarin satislarinda çok net artislarin olmasi. Bu cihazlarin satisi arttikça üzerindeki uygulamarin artmasi dogal bir arz-talep meselesi haline geliyor:) Örnegin google talk'i da su anda nexus one üzerinde rahatlikla kullanabiliyoruz. Yatirim çift tarafli devam edecektir. Cihazlar kullanimi artmaya basladiginda, ister istemez uygulamalar hayatimizda daha etkin rol oynayacaktir.

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara