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

Podcast #04 – Where We’re Going We Don’t Need Roads

Read More

Podcast #02 – Who run the world? – ARDUINO!

Herkese Merhaba! Epey uzun bir aradan sonra ofisteki sessizligi firsat bilip Mert ile bir podcast hazirladik. Bununla birlikte eski podcastleri de Youtube kanalimiza tasimaya karar verdik. Bu arada ilk podcastimizi dinledik uzerinden cidden uzun sure gecmis ve nedense epey iyi oldugu hissine kapildik. On hazirlik yapip kayit yapmistik belki ondan belki de ilk olmasinin verdigi heyecan?

Linkler:

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