Inspiration

Nowadays, I started playing the F1 24 game on my PlayStation. It is really fun. Even with the controller, the driving experience is amazing. The more interesting part for me is that this game also enables us to get telemetry data. Yes, you can take your real-time telemetry data. I wrote a basic Python script to listen to that data. It is in binary format over UDP packets, so you need to decode the binary packets to get the needed data points. I stopped at that part because there are already some open-source packages designed to read and decode telemetry data for this game. When I searched the web, I found more tools and apps designed for this game. For example, during a race, you can open an app on your second screen to see more info (live map, stats, lap records, setup suggestions, etc.). I really like P1 Telemetry for anyone who is interested.

Then I thought, can I build something similar for real life? I mean, collecting data from my car and building some visualizations, stats and basically a dashboard… But I don’t think I am able to collect any data from my 2012 VW Jetta :) So I thought about using the most powerful device that I have (my iPhone📱) to collect data. I was planning to use GPS so I would be able to collect some basic data like location, speed, and distance. Of course, this is a small amount of data compared to telemetry data, but my purpose was just to make it happen.

Starting to build

My plan was simple: building an iOS app that generates data and a web dashboard that visualizes my driving and provides some insights.

The problem is, as a data engineer, I don’t know how to code a mobile app or a web interface with the features I want. So at this point, I wanted to give a chance to AI IDE’s like Cursor and Windsurf. I had done some small tests with them before, but I hadn’t tested their full capabilities. This was also a good chance to test them.

Transporter Telemetry

I started development with the mobile app. I wanted to generate my data first. My methodology was writing simple documentation about my app. It included some info about what my app does, which technologies it will use and which key features it has. After that, I gave my documentation to Gemini and asked it to generate a PRD (Product Requirements Document). Once it was done, I started developing my app feature by feature with Windsurf.

It was not a straightforward process. I had to solve many problems, bugs and issues. Doing 70% of the app was quick, but the rest was a bit of a painful process. However, I handled it properly and successfully built the app. Basically, it records my driving. It collects data using the SwiftUI Core Location library. Every 1000 ms (yes, 1000x slower than F1 telemetry, but this is enough 😊), it records my location (longitude, latitude), speed, and distance. You can also add your tire type, car model, and driver for more data. Since it isn’t connected to my car, of course, I don’t have detailed driving data like throttle, braking, or gear usage. I extracted as much data as possible from my phone.

You can check the repository of this app here -> Transporter Telemetry

Unfortunately, it is not on the App Store, yet. If I start producing more iOS apps, then I might consider buying an Apple Developer Account and launching my apps._

The Transporter

The Transporter Telemetry app generates data as JSON files. So we have the driving data. I wanted to build a dashboard that would calculate some statistics like max speed, total distance, average speed, and total time from this data and also display my driving on a graph. Additionally, I wanted to compare my trips with other trips.

I planned to use Next.js. I followed the same procedure as I did with the iOS app: I wrote documentation and generated a PRD with Gemini. After that, I started implementing my features one by one using Cursor.

The challenging part was Route Visualization. I wanted to show my trip on a map view. I wanted to indicate my throttle and braking with green/red colors, along with a navigation cursor. I broke many things during this process, but using git commits after completing each feature helped me a lot. Because when something broke, I could revert to a previous version with Git. After completing the small details, I deployed my project to the web. You can visit the-transporter-inky.vercel.app and test it yourself.

Github repo for The Transporter

So basically…

By getting inspiration from F1, I built my own driving analytics tools. I could say I enjoyed the process a lot. I tested the capabilities of AI tools (which also helped me understand the future of AI programming) and also worked with data that I generated myself. As a data engineer, I usually work with third-party data, but it is more fun when you are the owner of the data. You have more control over it and can modify it as you wish.

I have stopped developing this project. But in my imagination, I was thinking about this project as a social driving application. Everything would be inside the mobile app, and people would follow their friends and track their driving sessions. Maybe we will continue developing it—maybe one day?

Not alma ve verimlilik gibi konularla ilgiliyseniz Notion isimli uygulamayı büyük ihtimal duymuşsunuzdur. Bilmeyenler içinse Notion, 2018 yılında piyasaya çıkan, not tutmaktan proje yönetimine bir çok kullanım amacını karşılayan çok güçlü bir uygulama. Son bir kaç ayda ise büyük bir kullanıcı kitlesine ulaştığını da eklemek istiyorum.

Benim içinse Notion, çıktığı ilk günden beri kullanmaya çalıştığım, çabaladığım ve en sonunda sürekli pes ettiğim bir uygulama oldu. Defalarca kez bu döngüye girmemin sebebi ise uygulamanın sunduğu özelliklerin oldukça cezbedici olması. Notion’ın çok güçlü bir uygulama olduğunu söylemeliyim. Evernote, Trello, Excel, Calendar gibi uygulamaların birleşimi, hatta bazı yerlerde çok daha fazlası. Kendi tabirleriyle “All-in-one workspace” bir uygulama. Teker teker bu uygulamalara girmek yerine “all in one” bir uygulama gerçekten çok cezbedici geliyor. Bu sebepten dolayı da defalarca kez Notion’a geçmeye çalıştım fakat sonu hep hüsranla bitti.

Bunun hüsranın temel nedeni ise Notion’ın çok iyi bir uygulama olması. Evet, gerçekten çok iyi bir uygulama. Uçsuz bucaksız Notion dünyasında yapamayacağımız, kişiselleştiremeyeceğimiz bir şey yok gibi. Tabi bunun da beraberinde getirdiği bazı sorunlar yok değil.

Karmaşıklık, Notion dünyasına ilk adımı attığımdan beri peşimi bırakmayın bir şeydi. Yaptığı her işi olabildiğince basit hale getirmeye çalışan şahsım için karmaşık şeylerden ne kadar hoşlandığımı tahmin edebiliyorsunuzdur :) Karmaşıklık gerçekten büyük bir engel, friction (verimlilik konusuna ilgiliyseniz bu kavramı araştırmanızı tavsiye ederim, sürtünme diye çevirmek istemedim). Uygulama içerisinde yapacaklarımızın bir sınırının olmayışı, beni sürekli daha karmaşık bir yapıya sürükledi ve friction’ı arttırdı. (O yüzden bazen uygulama limitleri de yararlı olabiliyor. Süreci olabildiğince basit tutup verimi attırmak önemli bir nokta.) Bir diğer sorun ise üzerinde zaman harcamaya çok müsait olması. Şunu şöyle yapayım, burada roket iconu kullanayım, bu sayfanın kapak resmi manzara olsun, burada linked database kullanayım derken bir bakıyorsun saatler geçmiş… Productivity tool dediğimiz bu araçların bizim daha verimli çalışmamızı sağlaması gerekirken, Notion benim için bir unproductivity tool haline geldi. Uygulamada geçirdiğim vakit artıyor, verimim ise tam tersi istikamette düşüyordu. Bu yüzden cezbedici tüm özelliklerine rağmen Notion’a geçiş denemelerimi sonlandırmaya karar verdim. Aynı sorunlardan tek ben mi müzdaribim derken ise şöyle bir entry’e denk geldim:

Nedir bu overengineering?

Overengineering ilk kez duyduğum bir kavramdı. Bu kavramı araştırırken yıllar önce izlediğim bir belgeselle bağlantısı olduğunu görünce ise beni çok heyecanlandırdı. Öncesinde “overengineering” kavramını açıklamak istiyorum. Kelime olarak “aşırı mühendislik”, anlam olarak ise “bir ürünü gerçekleştirirken aşırıya kaçma olayı” şeklinde bir anlam barındırıyor. Benim izlediğim belgeselle olan bağlantısı ise Almanların meşhur tankı King Tiger‘dan geliyor.

Overengineering kavramını açıklamak için en sık kullanılan örneklerden birisi, II.Dünya Savaşı’nda kullanılan King Tiger tankları.

Hitler’in “ne kadar büyük o kadar iyi” mentalitesini belki duymuşsunuzdur. Bu mentalitenin en büyük eserlerini II.Dünya Savaşı sırasında Nazi Almanyası’nda gördük. 5 tonluk Panzer tankı ile başlayan Alman tankları, Ferdinand Porsche’nin yaptığı (evet, Porsche’nin kurucusu) devasa Maus tankına kadar büyüyecekti (10 metre uzunluğunda, 188 ton ağırlığında).

King Tiger tankına dönecek olursak 75 tonluk bu devasa tank, hali hazırda oldukça güçlü Tiger I tankının devamı niteliğindeydi. Çok daha büyük, çok daha ağır ve çok daha güçlüydü. Tiger I tankı ise Almanların “el yapımı” şahesereydi. El yapımı ve karışık dizaynının doğurduğu bazı sorunları mevcuttu (bakımı çok zordu, savaş alanında arızalanan tigerlar tamir edilemiyordu ve düşmanların eline geçmesin diye alman askerleri tarafından imha ediliyordu). King Tigerlar ise hali hazırdaki Tiger I tanklarının karışıklığına karışıklık katacaktı. Overengineering kavramı da aslında tam olarak burada devreye giriyor. Tiger I tankları, müttefik tanklarını kolaylıkla etkisiz hale getiren çok güçlü bir tanktı. Yerini ise daha fazla zaman, kaynak ve emek gerektiren King Tiger tankları almış oldu. Kaynakların muazzam öneme sahip olduğu II.Dünya savaşında, yüksek kaynak gerektiren King Tiger’lardan sadece 492 tane üretildi. Sovyetler Birliği ise savaş sırasında yaklaşık 3.900 IS-2 tankı üretti. Sovyetler toplamda 108.000’den fazla tank üretirken Amerikalılar ise 88.000 Sherman tankı üretti. (ABD’nin Tigerları yok etmek için ürettiği Sherman Firefly tankını, Sherman tanklarının üzerine daha güçlü silahları monte ederek ürettiğini de belirtmek istiyorum.)

Aşırı ağır, aşırı komplike süper silahlı tanklar yapmak işe yaramadığı anlaşılan II.Dünya Savaşında, Amerikalılar seri üretimde olan orta büyüklükteki bir tankı alıp geliştirip, sayıca daha az ama daha güçlü olan Tiger tanklarını mağlup etmeyi başarmıştı. “Sonuçta daha kötü ama daha çok Sherman’a sahip olmanın daha iyi olduğu ortaya çıktı.”

“II.Dünya Savaşı, malzemeyi korkunç bir hızla yiyip bitiren bir üretim yarışmasıydı. 500’den az King Tiger, ne kadar güçlü olursa olsun, sonucu değiştirmeyecekti.”

Peki sonuç?

Gelelim en başa. Notion overengineering bir ürün müdür bilmiyorum fakat daha iyisi her zaman en iyi olmayabiliyor. Aslında kullanım amaçlarımız “en iyi” kavramını şekillendiriyor. Notion iyi bir ürün, ama benim kullanım koşullarımda “en iyisi” değil. Daha vasat gözüken ama benim kullanım amacıma daha iyi şekilde hizmet eden ürünün benim için daha iyi olduğuna kanı getirdim. Genel olarak bu hikayeden kendime çıkardığım derste bu oldu.

En iyisi mi? Hayır, teşekkürler…

Bu yazıyı yazarken yararlandıklarım:

https://eksisozluk.com/entry/110722745

https://nationalinterest.org/blog/reboot/meet-hitlers-huge-king-tiger-tank-nazi-germanys-paper-tiger-164232

https://eksisozluk.com/entry/30938077

https://en.wikipedia.org/wiki/Panzer_I

https://www.youtube.com/watch?v=aAIFQcQ1gd8 (Nazilerin Mega Yapıları - Süper Tanklar Belgeseli)