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

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