Alaylı vs Mektepli

Herkese merhaba! Bu videomuzda alaylı ve mektepli yazılımcıları karşılaştıracağız 🙂 Burak BÖTE mezunu olmasına rağmen alaylı, Mert ise kendini alaylı hissetmesine rağmen mektepli rolünü üstlenecek.

 

İlk maddemiz, bilgisayar mühendisliği yazılımcılık mesleğiyle karıştırılmamalı. Bilgisayar mühendisliği mezunu olduğunuzda illa yazılımcı olmanız gerekmiyor. Bilgisayar mühendisleri iyi yazılım bilmek zorunda da değiller. Tabii ki tam tersi de geçerli, yazılım yapmak için bilgisayar mühendisi olmak zorunda değilsiniz. Aslında bilgisayar mühendisliği ülkemizde biraz farklı bir konumda. Yurtdışında (biz ABD’yi baz aldık) bilgisayar bilimleri (computer science) diye bir bilim var ve bunun alt dallarından birisi de bilgisayar mühendisliği. Bizde kavram olarak bilgisayar mühendisliği üst başlık gibi ve bunun alt dalları var gibi.

 

Aslında tüm üniversitelerde tüm bölümlerde çoğunlukla olan bir sorun; sadece teorik bilgi verilmesi, pratik kısmına öğrencilerin yeterince hazırlanmaması. Bilgisayar mühendisliği adına konuşmamız gerekirse, bu teorik bilgilerin çağı takip etmesi çok zor. Çünkü tüm teknoloji ve piyasa inanılmaz hızlı bir şekilde gelişiyor/değişiyor. Örneğin NoSQL henüz yeni bir teknoloji olmasından dolayı teorik olarak okullarda gösterilmesi çok mümkün değil. Ancak piyasada hızlıca kullanıma geçilmiş durumda. Bu durum öğrencilerde mezun olunca “öğrendiklerimiz işimize yaramayacak, şirketler bambaşka teknolojiler kullanıyor.” gibi bir düşünce yaratıyor. Haklılık payı olmakla birlikte aslında bu bilgiler işe yarıyor. Mezun olduğunuzda bu teknolojileri bilmiyor olsanız bile aldığınız eğitimle temeliniz sağlam olduğu için bu yeni teknolojileri hızlıca öğrenip çağa ayak uydurabiliyorsunuz.

 

Okullu yani mektepli olmanızın bir avantajı yukarıda da bahsettiğimiz gibi yeni teknolojileri hızlıca öğrenebilmek. Ancak alaylı iken bu çok kolay olmayabiliyor. Çünkü bilgi birikiminiz deneyimlerinizden geliyor ve eğer bu konu ile ilgili bir deneyiminiz yoksa konuya hakim olmanız biraz vakit alabiliyor. Sorunu bir şekilde çözüyorsunuz tabii 🙂 Bu noktada hemen bir not girelim, bahsettiğimiz herşey genelleme. Bilgisayar mühendisliği ya da ilgili bölümlerden mezun olup, teknolojiye ve yeniliklere çok uzak arkadaşlarımız da oldu, bambaşka disiplinlerden mezun olan (işletme gibi) ya da lisans eğitimi almayan ama bu sektörde çok başarılı arkadaşlarımız da oldu.

 

Bilgisayar mühendisinin yazılım yapacağını düşünürsek, mutlaka pratik yapması gerekiyor. Kendi kuracağı şirkette ya da çalışacağı bir şirkette yazılım geliştirebilmesi için bir proje deneyiminin olması gerekiyor. İşini hem hızlı hem de düzgün temellere oturmuş şekilde yapması için pratik şart. Üniversiteler bu sorunu staj ile çözüyor ancak maalesef kısa staj süreleri bunun için yeterli olmuyor. Uzun dönemli staj (Bilkent Üniversitesi gibi) bu anlamda çok mantıklı. Bunu öğretmenlik mesleği için eğitim fakülteleri daha güzel bir şekilde çözüyor. Son sene her haftanın bir günü öğretmenlik yapmaları çok iyi deneyimler kazandırıyor öğrencilere. Öğrencilere tavsiyemiz part-time iş olur, freelance olur bir şekilde bu dünyanın içine henüz öğrenciyken atılmaları. Erkenden atılan bu adımın ilerleyen süreçte işinizi çok kolaylaştıracağına inanıyoruz.

 

Toparlamak gerekirse; aslolan mesleğinizi severek ve layığıyla yerine getirmek. Bu noktada da ne mezunu olduğunuzun, ne okuduğunuzun çok da önemi kalmıyor. Tartışmalı da olsa bir kural var, bir konu üzerinde 10000 saat çalışırsanız, o konunun uzmanı olursunuz. Yani iş sizde bitiyor 🙂

 

Okuduğunuz, izlediğiniz için teşekkürler. Sonraki videolarda görüşmek üzere! 🙂

 

https://www.youtube.com/watch?v=HYVoRcw1nZk

Read More

Frontend vs Backend

Herkese merhaba,

Bu videodaki konumuz biraz ikimizi çatıştıracak bir konu 🙂 “Backend’çiler” ve “frontend’çiler”in ilişkileri dolayısıyla yaşadıkları çatışmalar. Kimi konuda backend’çinin kimi konuda frontend’çinin hataları oluyor. Bunların üzerinde biraz irdeleme yaparak, bazı sorunların nasıl çözülebileceğine dair fikirler sunacağız. Genel bir çözüm olarak ise ilgili tool’ları kullanmak ve düzgün dökümantasyon diyebiliriz.

Backend’çilerin bir sorun durumunda, önce sorunu düzeltip, sonra da “Abi orası zaten çalışıyor, tekrar kontrol et” demesi 🙂

Bilenler veya bilmeyenler olabilir, Burak Apps’te backend ve server işleriyle ilgilenirken, Mert de iOS uygulamalarıyla yani daha ziyade frontend tarafıyla ilgileniyor. İnsanlık hali belki backend işini yapan arkadaş unutmuş olabilir, yapıp deploy etmemiş olabilir çok da üzerine gitmemek lazım.

Şaka bir yana başımıza gelen bir olay. Backend’de bir sorun vardı ve biz bu sorunu ilettiğimizde backend’çi arkadaş(Burak değil başka biri 🙂 ) “orası zaten çalışıyor tekrar dener misin?” demişti. Ancak açıkça görünüyordu ki bütün backend değişmişti. Burak’ın daha farklı bir sorunu var, (ki bunu dış ses olarak Sedat söylüyor 🙂 ) Burak genelde yapması gereken  bir işi yapıyor ancak yaptığını söylemiyor. Endpoint’e eklenmesi gereken birşeyi söylediğimizde büyük ihtimalle 5 dakika içerisinde ekliyor ancak bize söylemediği için biz hala onunla uğraştığını zannedebiliyoruz. Kendi yerinde duran ve haberimizin olmadığı bir hizmet de açıkçası çok işimize yaramıyor.

Bu soruna çözüm önerisi olarak Postman gibi bir aracın kullanılmasını sunabiliriz. Backend’e birşey eklenildiği ya da orada bir sorun düzeltildiği an hemen Postman linkini alıp Frontend tarafına göndermek iyi bir alışkanlık olabilir. Bunun haricinde bir CI (continuous integration) sistemi varsa, her değişiklikte ilgililere bildirim göndermesi sağlanabilir. Ya da sırf bu iş için dünya kadar tool kullanmak yerine açık açık bir sorun vardı ve şimdi çözdüm, deneyebilirsin diyebilirsiniz 🙂 Sonuçta herkesin geliştirdiği sistemlerde bug çıkabiliyor, ayıp değil.

Frontend’çinin production ve development url’lerini karıştırması

Production’a development url’i ile çıkmak ya da development yaparken production url’i kullanmak,  frontend tarafında yaşanan karmaşalardan biri olabiliyor. Burada dikkat etmek gerekiyor  ya da build scriptler kullanıp, build ettiğiniz ortama göre url’lerin belirlenmesini sağlamak gerekiyor.

Mert bu sorunu kendi tarafında tek yönlü olarak çözmüş. Uygulamayı productiona çıkartmadan önce kontrol ettiği bir checklist’i var. Orda da bu konuyla ilgili bir madde var. Böylece productiona çıkarken development url kullanma sorununu çözmüş görünüyor. Ancak tersi için işlemiyor bu çözüm 🙂

Production url’i ile test yapmak tehlikeli olabiliyor. Bu canlı ortamda örneğin onbin kullanıcı varken, sırf test amaçlı bin kullanıcı daha eklerseniz işler karışabiliyor. Bu çıkan sorunlar da daha sonra backend’çinin başına kalıyor.

Backend’çinin hatasının faturasının Frontend’çiye kesilmesi

Mobil uygulamaların her ne kadar tasarım, backend, frontend, veritabanları vs. gibi bir çok katmanı olsa da, sonuçta uygulamayı yazan kişi frontend’çi olduğundan, tüm hatalardan ilk olarak o sorumlu tutuluyor. Tabii ki konu bir yerde backend’e ya da ilgili birime dönüyor ancak ilk darbeyi her zaman frontend karşılıyor. Baktığınızda özellikle tüm kısımlar bizim geliştirmemizdeyse çok da büyük bir sorun olarak görmüyoruz.

Genelde ufak problemler bu tarz sonuçlara yol açabiliyor. Hızlı olmak için bir kontrol es geçilmiş olabiliyor backend tarafında ya da server exceptionlar dönebiliyor bazı durumlarda. Ya da ülkemizde bir anda AWS kapatılabiliyor, ona bizim de yapabilecek birşeyimiz yok 🙂

Fiziksel olarak backend ve frontend geliştiricilerin yakın olması çok önemli. Tüm sorunlar bu şekilde hızlıca çözülebiliyor. Aynı şehirde olmak bile büyük avantajken, aynı odada çalışmak işleri gerçekten çok hızlandırıyor. Örneğin bir müşterimizle kapı komşusuyuz hatta tam kameradan baktığınız duvarın arkasında onlar var. Ve işin backend kısmı ile onlar ilgileniyor. Böyle olunca da tüm sorunlar çok hızlı bir şekilde çözülebiliyor.

Yanlış yapılan requestler

Bunun genel sebebi: kodun kopyala-yapıştır yapılması, en azından biz öyle tahmin ediyoruz 🙂 Özetle, POST metodu göndermeniz gereken yerde GET metodu göndermeniz ya da bir parametreyi body’den göndermek yerine header’dan göndermeye çalışmanız, hatalı bir request yapmanıza sebep olacaktır. Eğer bir frontend’çi olarak böyle bir durumda hemen backend’çiye dönüp “bu sorgu çalışmıyor” derseniz, üzülürsünüz 🙂 AppEngine gibi platformlarda bu hatalı requestler kolayca görünebiliyorken, kendi geliştirdiğimiz ortamlarda bu kadar kolay farkedilemeyebiliyor ve zaman kaybına yol açıyor.

REST mimarisine uygun geliştirilen sistemlerde aynı url üzerinden dört işlem yapılabiliyor. Dolayısıyla örneğin daha önce bir url ile POST metodunu kullanarak ekleme yaptığınız servise, aynı url ile okuma yapmak istediğinizde, kopyala-yapıştır yaparak aynı kodu kullanıp POST metodunu GET ile değiştirmediğiniz için istek düzgün cevaplanmıyor.

Çözüm olarak Burak her ne kadar Postman’de yeterince detay olduğunu söylese de, Mert bu detayların bazen gözden kaçabildiğini (kopyala yapıştıra devam edecek) söylüyor. Başka bir seçenek olarak 5 defa “neden?” sorusunu sorarak sorunun neden kaynaklandığını bulabilirsiniz. Konu ile ilgili tecrübeleriniz de arttıkça yani aynı sorunu sıkça yaşamaya başladıkça zaten suçu backend’e atmadan önce tüm sorguları kontrol etmeye başlıyorsunuz.

Tabii en güzel çözüm kopyala yapıştır yapmadan, her sorguyu baştan yazmak. Ancak Mert pek bu fikre sıcak bakmıyor gibi 🙂

Bütün iş mantığının client’a aktarılma çabası

Sebebi tamamen backend’çinin işten kaçıp, işi frontend’çiye yıkması 🙂 Bir işin mobilde yapılabiliyor olması, orada yapılmasını gerektirmiyor. Çünkü işlem gücü olarak mobil uygulamaların çalıştıkları cihazlar ile backend hizmetlerinin çalıştıkları makinalar aynı değil. Bir sunucunun görüntü işleme gücü ile mobil cihazın işleme gücü takdir edersiniz ki aynı değil. Hatta o kadar karmaşık bir işleme bile gerek yok. En basitinden uygulamada kullanılacak tarih formatı neyse, backend’den tüm tarihlerin o şekilde gelmesi gerekir, mobil uygulama tarihleri formatlama ile uğraşmamalıdır. Ya da uygulamada sadece kişinin yaşı kullanılacak, doğum tarihi kullanılmayacaksa, backend’den doğum tarihi gönderip, mobil uygulamada yaşı hesaplayıp göstermek yerine, backend’den doğrudan yaşın gelmesi daha doğru bir yaklaşım olacaktır.

Konumuzla doğrudan alakalı olmasa da artık mobil cihazlar sadece bilgi gösteren cihazlar haline gelmeye başladı ve bu devam edecek. Özellikle IoT ve giyilebilir cihazların yaygınlaşmasıyla mobil uygulamaların rolü iyice bilgi aktarımı ve gösterimi olmaya başladı. Bunun içindir ki işlemlerinizi backend’de yapın, bırakın frontend sadece bilgi göstersin 🙂

 

 

Bizim yaşadığımız sorunların bazıları bunlardı. Burak ve Mert kanlı bıçaklı değiller bu arada, sadece iş icabı bazı küçük tatlı çekişmeler 🙂 Eğer sizin de başınıza gelen backend-frontend çatışması varsa yorum ile bildirebilirsiniz.

 

Okuduğunuz / dinlediğiniz / izlediğiniz için teşekkür ederiz! 🙂

 

Read More

Yeni Başlayanlar için Mobil Tavsiyeler – 2

Yeni Başlayanlar için Mobil Tavsiyeler yazı dizimize devam ediyoruz.

 

How_to_Build_a_Mobile_AppAmerika’yı Yeniden Keşfetmeyin!

Büyük markalar bile (Instagram, Facebook vs.) uygulamalarında bazı modülleri hazır kullanırken, bizler neden yeni baştan yazalım? Ancak hazır modüller kullanın derken tabii ki emek hırsızlığından bahsetmiyorum. Açık kaynak kütüphaneler kullanmanızı ve bu ürünlerin lisanslarına dikkat etmenizi tavsiye ederim sizlere. Açık kaynak olması nedeniyle hem kütüphanenin nasıl yazıldığını inceleyip öğrenebilirsiniz hem de ufak ya da büyük, kütüphaneye katkı sağlayabilirsiniz. Ayrıca açık kaynak kütüphanelerin bir avantajı da kendi probleminize özel bazı ufak düzenlemeler yapabiliyorsunuz. (Lütfen bununla ilgili lisans sözleşmesine göz atın.)

Aşağıda bir kaç güzel kütüphane önereceğim Android için. Bir sonraki yazıda da iOS için olacak bu öneriler. Bu kütüphanelerin yaptığı işleri yapmanız gerekiyorsa tavsiyem kesinlikle ilgili kütüphaneyi kullanmanız. 🙂

Android-PullToRefresh

2012_06_02_ptrChris Banes’in yarattığı mükemmel bir kütüphane. Ancak baştan uyarmam gerek artık bu projenin bakımı ile ilgilenilmiyor. Son güncelleme 2 yıl önce gelmiş. Ancak hala temel ihtiyacımızı karşılıyor.

Neredeyse her uygulamada görmüşsünüzdür, bir liste vardır ve listeyi tutup aşağıya çektiğinizde içerik yenilenmeye başlar. Örneğin Twitter ve Facebook’un haber akışları. Bu görevi oldukça başarılı bir şekilde yerine getiriyor PullToRefresh kütüphanesi.

Android-Universal-Image-Loader1350641152_5486

Bu kütüphane de nostra13 kullanıcı adlı Sergey Tarasevich’in eseri. Bakımı oldukça iyi ve sık yapılan bir proje. Ayrıca Sergey’den farklı bir çok gönüllü de kütüphanenin gelişmesi için çabalıyor.

Android’de network işlemleri, cache’lemek, bunları yaparken performans kaybı yaşamamak zor işlerdir. Hele de bunları görseller göstermek için yapıyorsanız işiniz daha da zor-du bu kütüphaneyi kullanana kadar. Oldukça kolay kurulumu ve kullanımıyla sizi bu dertlerden kurtarıyor. Performans olarak da oldukça iyi bir kütüphane.

feature_01ActionBarSherlock

Android artık eski stil menüyü kaldırıp, tüm menüleri Action Bar şekline dönüştürüyor. Tabii ki biz geliştiricilerden de bunu bekliyor. Ancak bildiğiniz üzere bu menü, eski Android sürümlerinde desteklenmiyor. Jake Wharton bu sorunu çözmek için bahsettiğimiz kütüphaneyi yazmış. Basit ve hızlı kurulumu sayesinde uygulamanızı tüm Android versiyonları için Action Bar kullanır hale getirebileceksiniz.

Google Gson

Bazen objeleri karakterlere dökmek istersiniz. İşte Gson bu noktada devreye giriyor. Şaka bir yana örneğin bir objeyi SharedPreferences’a kaydetmenin en gson-java-jsonkolay yollarından biri bu. Objenizi Gson ile json formatında stringe çevirip, paylaşılan alanda saklayabiliyorsunuz. Kullanmak istediğinizde tekrar stringi objeye çevirebiliyorsunuz. Oldukça hızlı çalışan Gson, Google tarafından geliştirilmiş bir kütüphane.

 

 

Serinin bir sonraki yazısına kadar görüşmek üzere! 🙂

Read More

Yeni Başlayanlar için Mobil Tavsiyeler – 1

keep-calm-the-junior-developer-is-here

Merhaba. Bu yazı dizisinde istek üzerine, mobil uygulama geliştirmeye başlayacak arkadaşlar için naçizane “mobil tavsiyeler”de bulunacağım. Bazı önerilerim platform özelinde olacakken, bazıları daha genel olacak. Lütfen eklemek istediğiniz önerileri yorum olarak yazın, kaynak daha da gelişsin. 🙂

 

Nasıl Başlayacağım?

Belki de en büyük sorun bu olsa gerek! “Neresinden başlayacağım?” Bu soruyu ikiye bölerek cevaplamak istiyorum: Android ve iOS.

how-to-start-a-charity-597x358

 

 

Android

Sıradan bir nesne tabanlı programlama dili biliyorsanız (tercihen Java, C#, C++ vs.) işiniz kolay. Sadece biraz Android ortamını ve mantığını anlamanız gerekecek. Bu da sizin gözünüzü korkutmasın, kısa sürede alışacağınıza emin olabilirsiniz 🙂 İlk etapta bir kitap satın almanızı önerebilirim. Ancak alacağınız herhangi bir “Android’e Başlangıç” kitabı size yalnızca 1-2 hafta yardımcı olacaktır. Sonrasında kitabın yüzüne bakmayacaksınız. Yine de başlangıç sürecini hızlandırmak ve size yardımcı olması açısından bir kitap önerebilirim: Merhaba Android – Pusula Yayıncılık. Kitabın yazarlarından biri GDG Ankara‘nın kurucusu Ahmet Oğuz Mermerkaya. Bu kitap Android geliştirmeye başlamanızda karşınıza çıkacak sıkıntıları büyük ölçüde azaltacaktır.Bunun haricinde Android’in resmi geliştirici sitesi olan Developer Android‘den mutlaka yardım almalısınız. Aklınızdaki tüm soruların cevapları orada profesyonel bir şekilde ele alınmış. Her özelliğin nasıl kullanılacağı detaylı bir şekilde ve örnek kodlar yardımıyla anlatılmış.

Son olarak da Android’in üstadı olarak nitelendirebileceğimiz Lars Vogel var 🙂 Kendisi adeta bir kitap şeklinde tutorial’lar hazırlıyor. Ücretsiz olarak sunduğu bu içerik yardımıyla yapmayı düşündüğünüz herhangi bir uygulamayı hiç sıkıntı çekmeden geliştirebilirsiniz.

iOS

iOS’da – kişisel görüşümdür – başlamak biraz daha zor gibi. Evet IDE’miz XCode ve görsel tasarım kısımları Android’e göre daha başarılı ancak programlama dili oldukça karmaşık. Objective-C denen Apple’a özgü bir dil kullanıyoruz. Söz dizimi alışagelmiş programlama dillerinden biraz farklı. Bildiğimiz C diline obje yapısı entegre edilmiş. Yani klasik C kodlarını da çalıştırabiliyor derleyici.Peki başlamak için hangi kaynakları kullanabilirsiniz? Öncelikle yine nesne tabanlı bir programlama dili biliyor olmanız sizin avantajınıza. Başlangıç için yine aynı mantıkta bir kitap önerebilirim: Objective-C Programlama Dili – Umuttepe Yayınları. Bu kitap aslında iOS’u değil, Objective-C programlama dilini anlatıyor yalnızca. iOS anlatan güncel ve başarılı Türkçe kitap ben göremedim ne yazık ki, eğer bir öneriniz varsa lütfen belirtin. Özrümle beraber yazıya eklerim 🙂

Bu kitap yardımıyla Objective-C hakkında başlangıç düzeyinde fikir edindikten sonra uygulama geliştirmeye başlayabilirsiniz. Ancak iOS’a uygulama geliştirebilmek için bir Mac bilgisayar ihtiyacınız var. İlk öğrenme aşamasında eğer bir Mac’iniz yoksa sanal makine yardımıyla sorunu çözebilirsiniz. İş gerçek bir uygulama yaratmaya geldiğinde mutlaka Mac edinmelisiniz!

Xcode’unuzu kurduktan sonra ilk bakmanız gereken yer mutlaka Apple’ın resmi geliştirici sitesi olmalı. Dürüst olmak gerekirse burası – özellikle 1-2 yıl önceki – Android’in geliştirici sitesinden daha kaliteli hazırlanmış. Emin olun sadece bu kaynağı kullanarak istediğiniz iOS uygulamaları geliştirebilirsiniz. Örneğin şuradaki dökümanı inceleyerek, sıfırdan bir iOS uygulaması geliştirebilirsiniz.

Ayrıca AndroidWeekly ve iOSDevWeekly sitelerine üye olmanızı şiddetle tavsiye ederim!

Not: StackOverFlow‘u söylememe gerek yok sanırım 🙂

Mobil Cihazlar Birer MacBook Pro Değiller! Ama Bulut?

mobile-cloud-computingÖzellikle daha önceden OSX, Windows ve Linux gibi masaüstü sistemlere programlar, uygulamalar yazan biriyseniz ve artık mobil dünyaya adım attıysanız, önceki hayatınızı unutun. Gigabyte’larca RAM, 8 çekirdekli 2.5 GHz i7 işlemciler ve terabyte’larca (belki artık petabyte) depolama alanınız yok. Ekran kartınız da 2+2 Gb’lık çılgın cihazlardan değil. Bundan dolayı ilk dikkat etmeniz gereken konu optimize kaynak kullanımı. Fakat an gelecek, ancak öyle bilgisayarların yapabileceği işlemleri mobil cihazda yapmak durumunda kalacaksınız. Bunun için çözüm basit: Bulut! “İnternet bağlantısı” diye üzülmeyin, emin olun kullanıcılar mobil cihazlarının şarjlarını 5 dakikada %30 düşürmenizden ziyade, internete bağlanmayı tercih edeceklerdir.

Yaklaşık 2 yıl önce mobil dünya daha farklıydı. Bir uygulama geliştirirken ne kadar internete az bağlanırsa, kullanıcılar o kadar rahatlıyordu. Ancak artık çoğu mobil cihaz internete sürekli bağlı halde. Yani eskisi gibi “uygulamam internet kullanmasın, işini lokalde yapsın” demenize gerek yok. Eğer web ve backend tecrübeniz varsa kendinize böyle bulut hizmetleri yaratabilirsiniz. Yok eğer ben web, server tarafından anlamam derseniz, bu işler için oldukça başarılı hizmetler sunan firmalar var. Size tavsiyem eğer gerçekten böyle bir iş gücünüz yoksa, hiç uğraşmadan böyle bir hizmeti kullanın.

Bu hizmetlere örnek olarak ilk “Parse” diyebilirim. Web tarafında tüm mobil işlerinizi hallediyor. Kolay kullanılabilir bir veritabanı hizmeti ve bulutta işlem yapabilmek için “Cloud Code” hizmetini sunuyor. Mobildeki 2.5(!) dev olan Android, iOS ve Windows Phone için SDK’sı olduğu gibi, Unity, JavaScript ve diğer .NET platformlarına doğrudan entegre edebiliyorsunuz. Bunların yanında tabi REST api hizmeti de alabiliyorsunuz.

Parse’ın diğer güzel özelliği de “Push Notification” imkanı sunması. Basit bir arayüzden, detaylı şekilde push’lar gönderebilirsiniz. Bildiğiniz üzere artık bu Push Notification’lar mobil uygulamaların en ilgi çekici özelliklerinden biri olmuş durumda.

Peki nedir bu servisin fiyatı? Aslında ücretsiz seçeneği var ve fazlasıyla yeterli bu seçenek. Ama isterseniz 200$ verip biraz daha fazla özellik satın alabiliyorsunuz.

Parse haricinde ise aşağıdaki hizmetleri önereceğim:

Heroku

Google AppEngine

 

Kullanıcı Deneyimi Herşeydir

Belki de bu konuda benim bir şeyler söylemem hadsizlik olabilir. Ancak bir kaç konuya değinmek istiyorum 🙂

94478eaeb416efcf09925ff64a4f3481Mobil cihazların, özellikle de akıllı mobil cihazların çıkış amacı pratik kullanımı sayesinde hayatımızı kolaylaştırmak. En basitinden artık fotoğraf makinesini çıkartıp, özel ayarını yapıp fotoğraf çekmiyoruz. Bir de bu fotoğrafı paylaşmak için bilgisayara kablo yardımıyla atıp uğraşmıyoruz. Bunun yerine tek dokunuşla fotoğraf çekip yine tek dokunuşla – hatta artık konuşarak – istediğimiz mecralarda paylaşıyoruz.

*Kaynak: http://www.mobinett.com/
*Kaynak: http://www.mobinett.com/

Burada aslında kilit nokta basitlik, işlevsellik ve görsel zenginlik. Bence bu üçünü topladığımızda kullanıcı deneyimi yani user experience (UX) ortaya çıkıyor. Bu noktada size en basit örneği vermek istiyorum. Örneğin bir mobil uygulama geliştiriyorsunuz ve uygulamanız hem iOS hem de Android platformunda çalışacak. Haliyle tek bir tasarım yaptırarak maliyeti düşürmek isteyeceksinizdir. Her ne kadar ana hatları benzese de kesinlikle aynı tasarımı kullanmak hata olacaktır. Çünkü iOS kullanan insanlarla Android kullanan insanların deneyimleri aynı değil. Ayrıca iki işletim sistemini kullanan cihazlar da aynı değil. Örneğin bir “tab bar” kullanacaksanız, bunu Android’de ekranın üstüne, iOS’da ise ekranın altına koymanız gerekiyor. Ekranın altı kolay ulaşılabilir olduğu için iOS’da ekranın altına koyulmalı. Ancak Android’de ekranın altında artık navigasyon butonları bulunduğu ve tab bar’ınızın bu navigasyon butonlarıyla karışma ihtimali olduğu için ekranın üst kısmına koymalısınız tab bar’ı.

 

Kullanıcı deneyimi konusunda tavsiyem tasarımlarınızı bu alanda uzman kişilere yaptırın. Bunun haricinde aşağıda oldukça önemli kaynaklar var. Bu kaynakları kesinlikle okumalısınız.

 

Android Design Principles

iOS Design Principles

UX Design Process – Rıza Selçuk Saydam

The Elements Of The Mobile User Experience

Read More

Podcast #01 – Creative Commons

Join us now and share the software

– Richard Stallman

Herkese merhaba!

“Bize katılın ve yazılımı paylaşın!” demiş Richard Stallman “The Free Software Song” adlı şarkısında. Biz de 4pps ekibi olarak inanıyoruz ki, bilgi, tecrübe, teknoloji ve hatta aşk paylaşıldıkça çoğalır. Bilgilerimizi, tecrübelerimizi ve işimize olan aşkımızı paylaşmayı seviyoruz.

Podcast serimizin ikinci bölümünü de bu konu üzerine yapmak istedik ve Hacettepe Üniversitesi Bilgi ve Belge Yönetimi bölümü öğretim üyelerinden Orçun Madran ile “Creative Commons” hakkında sohbet ettik. Umarız keyif alırsınız. Yeni podcast’lerde görüşmek üzere!

Not: Biz de blogumuzu CC ile lisansladık! 🙂

Linkler:

Read More

Podcast #00 – “Try not. Do, or do not. There is no try.”

Merhaba Dünya!

Her yeni start-up şirketi, dünyaya bir blog yazısıyla merhaba der. Biz biraz farklı yaklaşalım dedik ve sesimizle merhaba dedik! 4pps kurucularından Burak Aydın ve bendeniz Orhun Mert Şimşek, mobil teknolojiler üzerine sohbet ettik, bu sohbeti de bir podcast haline getirdik. TOBB üniversitesi bahçesinde yaptığımız sohbet, bir podcast serisinin ilk parçasını oluşturuyor. Bundan böyle çeşitli konular üzerinde, çeşitli konuklarla yapılan söyleşilere podcast olarak blogumuz üzerinden erişebileceksiniz. Podcast konusundaki ilk deneyimimiz umarız hoşunuza gider. Yeni bölümlerde görüşmek üzere! 🙂

 

Podcasti indirmek için: 4pps-Podcast-00

 

Linkler:

Düzeltme: Android Geliştirici Günleri’nde 56 sponsor bulunuyormuş.

Düzeltme 2: Aygul GDG Berlin değil GDG Stuttgart’tan geldi ülkemize 🙂

Read More