Kişisel bir okuyucuyla web’i geri almak
(olano.dev)- Yazılım sektöründen ve mevcut sosyal medyadan yorulduktan sonra Mastodon’u da denemiştim; ama aslında ihtiyaç duyduğum şey, insan merkezli bir zaman akışından çok web’deki yazıları ve bildirimleri bir araya getiren kişisel bir feed okuyucusuydu
- Hedef, RSS okuyucularındaki e-posta kutusu benzeri birikmiş liste değil; Twitter·Mastodon ana akışı gibi, her açtığımda ilginç içeriklerin aktığı akış tipi bir arayüzdü
- Tasarım ölçütü kullanıcı deneyimi > operasyon kolaylığı > geliştirme kolaylığı idi; htmx·hyperscript, monolitik Web uygulaması, SQLite, Python, gevent ve Huey eklentisi gibi basitçe işletilebilecek seçeneklere öncelik verildi
- Gerçek kullanım sürecinde uygulama içinde yazı okuma, sonra okumak için pinleme, bookmark, kaynakları yayımlama sıklığına göre sıralama, kaydırırken otomatik “zaten görüldü” işaretleme gibi özellikler eklendi
- Yaklaşık 3 aylık gevşek bir çalışmanın sonunda feedi geliştirildi; birkaç ay boyunca “internetin ilk sayfası” olarak kullanılırken tüketilen bilgi üzerinde kontrol hissi yeniden kazanıldı
Tükenmişlikten sonra web’i kullanma biçimini yeniden bulmak
- Art arda gelen kötü projeler ve yazılım sektörüne dair hayal kırıklığı nedeniyle kariyer tükenmişliği yaşandı
- İş yükü azaltıldı, işten ayrılındı ve terapiye başlandı; yemek, egzersiz, meditasyon gibi alışkanlıklar düzeltildi
- Programlamadan ve yazılımla ilgili okumalar yapmaktan bir süre uzak duruldu; son kullanılan sosyal medya olan Twitter da bırakıldı
- How to Do Nothing okunurken alternatif çevrimiçi topluluk olarak Mastodon yeniden incelenmeye başlandı
Mastodon’da görülen sınırlar
- Mastodon, algoritmik aracılar olmadan kronolojik feed sunarak feed üzerinde yeniden kontrol hissi veriyor
- Yazılım sektörü ve web konusunda benzer rahatsızlıklar hisseden insanlar; RSS, BBS, digital gardens, webrings gibi geçmiş web öğelerine yeniden bakıyor veya daha açık ve bağımsız bir web hayal ediyordu
- Gerçek kullanım amacı mikrobloglamadan çok bilgi merkezine yakındı
- İnsanları takip etme nedeni, web sitelerine yazı koyduklarında bildirim almaktı
- Botları takip etme nedeni, bağlantı toplayıcı içerikleri almaktı
- IndieWeb’in social readers kavramıyla karşılaştıktan sonra, ihtiyaç duyulan aracın Mastodon değil, doğrudan ayarlanabilir bir feed okuyucusu olduğu sonucuna varıldı
Kişisel okuyucunun kullanıcı hedefleri
- Genel RSS okuyucularındaki e-posta kutusu benzeri birikmiş liste değil, uygulama her açıldığında ilginç içeriklerin aktığı bir stream isteniyordu
- Feed’de farklı kaynaklar birlikte karışmalıydı
- Bloglar, dergiler, haber siteleri ve bağlantı toplayıcıların yazıları
- Mastodon, Goodreads, GitHub gibi kişisel hesap bildirimleri
- Kaynakların veri biçimleri farklı olsa bile tutarlı bir görünüm ve his oluşturabilmek için parsing özelleştirmesi gerekiyordu
- Tam teşekküllü bir IndieWeb okuyucusunun sosyal özellikleri uygulama kapsamına dahil değildi
- Yorum yapmak için başka bir sekme açmak sorun değildi
- İçeriğin üçüncü taraf sitelere dağılmış olması da sorun değildi
- Kısa vadeli hedef, bu aracın ana, hatta tek web bilgi kaynağı olup olamayacağını hızla görmekti; değilse projeyi hemen kapatma planı vardı
Geliştirme ilkeleri ve kapsam
- Geliştirme ilkesi
user > ops > devidi- İş önceliklerinde ve tasarım ödünlerinde geliştirme kolaylığı yerine operasyon kolaylığı seçildi
- Onun da üstüne kullanıcı deneyimi kondu
- Kişisel bir uygulama olduğu için “kullanıcı önceliği”, dogfooding yaparak önce kendi ihtiyaçlarını karşılamak anlamına geliyordu
- İdeal bir kullanıcı varsaymaktansa, ergonomik olarak kendine uyan bir araç yapmanın daha faydalı olma ihtimalinin yüksek olduğu düşünüldü
- Bu proje bir öğrenme projesi ya da portföy projesi olmamalıydı
- Hedef üretkenlik değil, yazılım geliştirmenin keyfiyle yeniden bağ kurmaktı
- Keyif, “bir şey yapmak”tan çok “kendi yaptığı şeyi kullanmak”tan gelmeliydi
- Tek bir hedef kullanıcı varsayımıyla birçok karar ertelenebildi
- Hemen gerekmeyen kullanıcı kimlik doğrulaması sonraya bırakıldı
- Kindle’a gönderme gibi çok spesifik özellikler erken aşamada ele alınabildi
- Feed parser özelleştirmesi veya Mastodon girişi gibi programlama bilgisi varsayılabildi
UI ve mimari seçimleri
- Yalnızca dizüstünden değil, telefondan da erişebilmek için bunun bir Web uygulaması olması gerekiyordu
- İki cihazı tek arayüzle desteklemenin maliyet-etkin yoluydu
- Aşina olunan HTML ve CSS kullanılabiliyordu
- Durumu sunucuda saklayarak cihazlar arası senkronizasyon çözülebiliyordu
- Web UI’ın bir ölçüde dinamik olması gerekiyordu; ancak ayrı bir frontend uygulaması veya yeni framework öğrenmek istenmiyordu
- boring tech ve radical simplicity tavsiyeleri doğrultusunda sunucu tarafı rendering kütüphanesi arandı; htmx ve hyperscript birlikte kullanıldı
- Operasyon dostu olması için dağıtım ve yerel kurulum kolay olmalıydı; Docker veya Nix gibi altyapılara bağımlı olmak istenmedi
- Aaron Parecki’nin tarif ettiği resmi IndieWeb reader; Micropub, Microsub, Webmentions gibi çeşitli protokollere ait bileşenlere ayrılıyor, ancak kişisel kullanımda bu yalnızca geliştirmeyi ve operasyonu karmaşıklaştırıyor, büyük bir avantaj sağlamıyordu
- Sonuç olarak monolitik Web uygulaması seçildi; kurulup yapılandırılacak bileşen sayısını azaltmak için veritabanı olarak SQLite kullanıldı
Dil ve arka plan işleri
- Go; basit ve genel amaçlı olması, garbage collection’a sahip olması, yeterince hızlı çalışması, eşzamanlılık modeli ve kolay dağıtılabilen binary’leriyle bu projeye uygun görünüyordu
- Ancak daha önce tek satır Go yazılmamıştı ve projenin bir öğrenme projesine dönüşmesi istenmiyordu
- Zaten aşina olunan diller arasında en hızlı prototip çıkarılabilecek dil olan Python seçildi
- Python’da ortam ve bağımlılıklar, özellikle de host OS kütüphane bağımlılıkları dezavantaj olarak kaldı
- Periyodik feed polling için ayrı bileşenleri artırmak istenmedi; araştırmanın ardından gevent ve Huey’nin mini-huey eklentisi kullanılarak arka plan işleri uygulama sürecinin içinde çalıştırıldı
- Buna karşılık Python’da HTTP, feed parsing ve scraping için kullanılabilecek iyi kütüphaneler vardı
Testlerin ertelenme nedeni
- Başlangıçta test yazmamaya karar verildi
- Özellikleri ekleyip silerek ve yerlerini değiştirerek deneyler yapılacağı için unit test bakım maliyetinin değerinden yüksek olduğu düşünüldü
- Küçük mantık hataları kabul edilebilirdi; her gün doğrudan kullanılan bir uygulama olduğundan önemli hataların zamanla ortaya çıkması bekleniyordu
- Güvenilirlik sağlamada entegrasyon testlerinin daha değerli olduğu düşünülse de, bu projedeki hataların çoğu dış kaynak entegrasyonlarından ve UI’dan geliyordu
- Entegrasyon testleri bazı hataları ve regresyonları daha erken yakalayabilirdi; ancak başlangıç maliyetine değmeyeceğine karar verildi
Gerçek kullanımın özellikleri yönlendirme süreci
- Her gün son kullanıcı olarak doğrudan kullanmak fikirleri, deneyleri ve öncelikleri belirledi
- Birkaç UI düzeni ve özellik denendikten sonra kullanım kalıbı oturdu
- Uygulamayı açmak
- Ana feed’de kaydırmak
- Sonra okunacak öğeleri pinlemek
- Şimdi okunacak öğeleri açmak
- Daha sonra başvurulacak öğeleri bookmark’lamak
- Uygulamadan ayrılmadan yazı okuma özelliği istendi; bunun nedenlerinden biri paywall’lardan ve izin/onay pop-up’larından kaçınmaktı
- HTML içerik çıkarımı için birkaç Python kütüphanesi denendi, ancak hiçbiri Firefox’un kullandığı readability kadar iyi çalışmadı
- readability bir JavaScript paketi olduğu için Node.js isteğe bağlı bağımlılık olarak eklendi
Feed sıralaması ve “zaten görüldü” işleme
- Temel özellikler tamamlandıktan sonra bile yalnızca yayımlanma tarihine göre sıralama, ilginç içerikleri bulmayı zorlaştırıyordu
- Seyrek yayımlanan blog yazıları Mastodon toot’larının arkasında gömülüyordu
- Dergilerin uzun yazıları günlük haber makalelerinin arkasında kayboluyordu
- Takip edilen kaynakların tamamı ilgi duyulan kaynaklar olduğundan, yayın sıklığı düşük kaynakların içeriğini önce görmek istendiği varsayıldı
- Aylık bir bülten son birkaç gün içinde yayımlandıysa, mikrobloglama veya günlük haberlerden yukarıda görünmeliydi
- Kaynaklar “frequency buckets” olarak sınıflandırıldı ve feed, sıklığı düşük bucket’lar önce görünecek şekilde sıralandı
- Seyrek içeriklerin uygulama her açıldığında sürekli en üstte kalması sorununu önlemek için, aşağı kaydırıldığında öğeleri otomatik olarak “already seen” işaretleyen bir özellik eklendi
- Bu yöntemle hem her zaman yeni içerik görülür oldu hem de seyrek güncellemeler kaçırılmadı
Yerelden VPS’e
- Başta uygulama dizüstündeki bir terminal sekmesinde çalıştırılarak geliştirme ve kullanım birlikte yürütüldü
- Feed’de gösterilen içerikler beğenilmeye başlayınca, her zaman erişilebilir olması için yerel ağdaki Raspberry Pi sunucusuna taşındı
- Raspberry Pi üzerinde sürekli kullanılmaya başlanınca telefondan erişim için mobil rendering iyileştirildi
- Dışarıdayken de uygulamayı kullanma özlemi duyulan noktada VPS’e dağıtıldı
- VPS dağıtımı, ertelenen kimlik doğrulama ve çok kullanıcılı desteğin eklenmesine yol açtı; birkaç arkadaşa beta test erişimi verilebildi
- VPS kurulumu bir domain satın almaya ve bu web sitesini oluşturmaya vesile oldu; bu da başlangıçta ilham veren IndieWeb idealine daha da yaklaşma süreciydi
feedi’nin sonucu
- Yaklaşık 3 aylık gevşek çalışmanın sonunda kişisel feed okuyucusu feedi yapıldı
- feedi, tamamlanmış bir üründen çok Emacs yapılandırması gibi sürekli yarı bozuk kalan ama bedene yerleşen bir araca yakın
- Üretkenlik açısından gerekçelendirmek zor; ancak kişinin kendi koşullarına göre yapılmış bir araç olduğu için tatmin sağlıyor
- Birkaç ay boyunca feedi “front page of the internet” olarak kullanıldı
- Kişisel okuyucu kullanmak, tüketilen bilgiyi yeniden kontrol etmeyi; ilginç blogları ve dergileri aktif biçimde aramayı; keşif ve şaşkınlık anlarına daha açık olmayı sağladı
1 yorum
Hacker News görüşleri
urlwatch(https://urlwatch.readthedocs.io/en/latest/) kurmak epey keyifliydi. Özellikle Puppeteer boilerplate’ini aşıp bir Chrome örneğiyle JavaScript sitelerini kazıyabilir hâle gelince, web’i çekip bakmak yerine sana doğru itilmesini sağlayarak kontrol ediyormuşsun gibi hissettiriyor.
Web sitelerini zahmetsizce izlemeye alıp sabah gözden geçirebilmenin gücü büyük. Sevdiğin bir şirketin iş ilanları, mevcut şirketinin işe alımları/son tarihleri, indirime girmesini/stoğa dönmesini/yenilenmiş ürün olarak çıkmasını beklediğin ürünler, COVID atık su istatistikleri, apartman ilanları, ilgilendiğin GitHub sürümleri ve önemli web sitelerinin şartlarındaki değişiklikler bile izlenebiliyor.
Kişisel olarak RSS okuyucumu ve Telegram botumu da self-host ediyorum, deneme amaçlı küçük HTTP siteleri de sıkça yaptığım için DigitalOcean $5 Droplet kullanıyorum; ama her gün aynı saatte çalışması gerekmediğinden dizüstünde de yapılabilir.
Kişisel kullanım için olduğundan yalnızca ilgilendiğim konulardaki Twitter güncellemelerinin özetini alıyorum; sitenin kendisinden, zehirli tartışmalardan ve can sıkıcı reklamlardan kaçınabiliyorum.
BT’nin mevcut hâli beni o kadar öfkelendiriyor ki düzgün toparlamam zor, ama bazen “benim BT sorumlum” diye bir kavram hayal ediyorum. Mahalle berberi, aile hekimi, terzi, fırıncı gibi dijital hayatının bir kısmını üstlenen biri.
Küçük bir yerel altyapıya sahip olup kişiselleştirilmiş feed’ler oluşturması, gizlilik ve dijital sağlığı gözetmesi, basit arayüzler ya da açık protokoller üzerinden feed okuyuculara bağlaması gibi. Filmler, yazılar, meme’ler, eğlenceli videolar da dâhil; ama işin özü gelir optimizasyonu algoritmaları değil, konuşabileceğin bir insanın varlığı.
Yerel topluluğun işlettiği veri merkezlerini kütüphane gibi konumlandırmak ya da ev interneti üzerinden basit içerik hizmetleri sunmak gibi fikirler de aklıma geliyor. Bu yüzden Veilid(https://gitlab.com/veilid/veilid) gibi yaklaşımları sevdim.
Fediverse’e geçtikten sonra daha sağlıklı hâle geldiğini söyleyenleri ilk kez duymuyorum. Ben de Puppeteer’ın üstüne betikler ve mini uygulamalar koyuyor, yerel llamacpp ile özetleme ve öneri çalıştırıyorum; ileride daha da cilalayıp arkadaşlarıma ve aileme önermek istiyorum.
Bu betiklere “not a browser” adını verdim. HTML/CSS/JS’yi veriyle birlikte sunan web’i değil, yalnızca veriyi sağlayan ve nasıl gösterileceğine kullanıcının karar verdiği web’i istiyorum.
Kullanıcıya düşman algoritmalar ya da reklam tabanlı sistemler yok; çoğunlukla kullanıcıyı önceleyen ve açık protokollerden söz eden yazılımlar. BT sektöründeysen ve sunucuyu kendin işletebiliyorsan mümkün, ama böyle olmayan insanlar ne yapacak, sorun bu.
Kişisel “BT sorumlusu” fikri ilginç. Büyük teknoloji şirketleri ve algoritmalardan uzaklaşıp daha kişisel şeyler kullanmak isteyen ama teknik imkânı olmayan insanlara böyle bir hizmet sunulabilir mi merak ediyorum.
Sağlık verileri de benzer. Tıbbi kayıtlarımın MyChart’ta ve çeşitli kapalı sistemlerde tutulmasından, kontrolün bende olmamasından hoşlanmıyorum. Cebimde bir süper bilgisayar var; neden kayıtlarımın bir kopyasını kendim saklayıp muayene sırasında doktora seçerek paylaşamıyorum, anlamıyorum.
Hastanelerin hâlâ birbirine faks göndermek zorunda olması da tuhaf. Tek bir düğmeyle verilerimi paylaşabilmeliyim. Apple Health bazı işlevlerde buna en yakın şey, ama ABD’de benimsenmesi neredeyse yok gibi görünüyor; üstelik o da Apple kullanıcılarının lehine. Sağlık verileri, yerelde çalışan Apple Health benzeri bir biçimde olsa bile kapalı sistemlere hapsolmamalı; açık protokollere ve bir uygulama ekosistemine ihtiyaç var.
Pazarlama ve açgözlülük interneti ele geçirmeden önce, kısa da olsa iyi bir dönem vardı. Son kullanıcıya fayda sağlayan uygulamalara sahip Synology NAS gibi ürünler ve bunlara yardımcı olan bir “benim BT sorumlum” modeliyle iyi çalışabilir.
Kişisel verileri ve parayı sömürmeye çalışan bir yapı olmadığı sürece kullanıcı açısından ütopyaya yakın olurdu; ama ekonomik açıdan muhtemelen düşük marjlı ve yüksek riskli bir iş olur. Örneğin dosya kaybından doğan sorumluluk gibi meseleler büyük.
Kodu bir kez yazıp neredeyse ek maliyet olmadan milyon kez çalıştıran bir yapı. Tüm yapısal güçler ters yönde işliyormuş gibi görünüyor. Yapay zeka işlerimizin tamamını elimizden aldıktan sonra belki daha mümkün hâle gelir.
Jenny Odell’in How to Do Nothing kitabı gerçekten mükemmel bir kitap. Hacker News’ün genel okur kitlesinden biraz farklı olabilir, ama dikkat ekonomisinin dayattığı sahte “üretkenlik” baskısını hissetmeye başlayan herkese şiddetle tavsiye ederim.
Jenny Odell’in diğer projeleri de görülmeye değer. Örneğin The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html) var.
Aynı bağlamda Jenny Odell’in Saving Time kitabını da öneririm. Sessiz ama son derece radikal bir kitap; kişisel olarak iki kitap arasında daha iyi buldum. Anlatısı daha odaklıydı.
Basit bir kişisel akışın ötesinde, zaman sınırlı ve dikkat dağıtmayan bir akış istiyorum
Takip ettiğim tüm yazılı içerikleri bir araya getirip, her gün yaklaşık 30 dakikalık okuma miktarı olacak şekilde öğe kombinasyonunu seçse iyi olur. Blog yazıları, makaleler, tweet'ler vb. hepsi dahil olmalı
ChatGPT ya da başka bir araç kullanarak en “besleyici” içerikleri süzmeli ve laf dalaşından daha değerli içeriklere öncelik vermeli. Sonra bunları Kindle'a ya da reMarkable tablete gönderip renklerden, parıltılardan ve hızlı internetten uzaklaşarak okumak istiyorum
Sonraki adım olarak bir arkadaşımın akışına abone olup ara sıra o akışın “konuk” içeriklerini de almak isterim
GPT özetleri ekleme fikri hoşuma gidiyor; başkaları da ilgilenirse toparlayıp paylaşabilirim. Şu anda yerelde kullandığım basit bir JavaScript uygulaması ama bu fikir başlangıçta düşündüğümden daha havalı görünüyor
Douglas Engelbart olduğunu sanıyorum ama ajanlarla ilgili materyali bulamadım. Başka bir teknoloji uzmanı da olabilir
Başta otomasyon testi yapmamaya yönelik bilinçli karar dikkatimi çekti ve bana da mantıklı geldi. Test yazmayınca içime sinmeyen o hissi aşmam epey zaman aldı ama kişisel oyuncak projelerde artık benzer yaklaşıyorum
Çok fazla proje daha ilk gün civarında öldü. Aslında ivme kazanılması gereken noktada test altyapısı ve CI pipeline'ı kurarken hevesimi kaybettiğim için
Şimdi test eksikliği gerçek bir sorun haline gelirse o zaman eklerim ölçütüyle çalışıyorum
Çok sayıda geliştiricisi ve büyük bir kod tabanı olan olgun projelerde zorunlu olan şeyler, küçük tek kişilik projelerde ayak bağı olabilir
Sonrasında sorun çıktıkça geçici olarak test eklemeye odaklanıyorum
Birkaç yıl önce kişisel proje olarak solunum gazı analizörü yaptım ve Bluetooth üzerinden bağlanıp verileri gerçek zamanlı gösteren yazılım yazdım. Bilimsel hesaplamaları doğru yapması gereken fonksiyonlarda birim testleri çok yararlıydı ama arayüzün diğer kısımlarını test etmek geriye dönüp bakınca neredeyse zaman kaybıydı
Fonksiyonun artık değişmeyeceğinden emin olduktan sonra tüm testleri kaldırdım. Tek başına geliştirirken manuel test tek başına yeterli olabilir
Gelecek hakkında dürüstçe konuşmak için yeni bir anonim hesap açtım
Bu yazı sanki gelecekteki ben yazmış gibi göründüğü için şaşırdım. Yazarla ortak noktalarım inanılması zor derecede fazla
Tükenmişliği fark edip gelecek yılın başında işi bırakmayı planlıyordum. Anonim hesap açmamın nedeni de buydu. Muhtemelen benzer hisseden çok kişi vardır
Daha da şaşırtıcı olan, yazarın yaptığı şeyin benim ara verdiğim dönemde denemeyi hayal ettiğim şeye neredeyse birebir benzemesi. Açık web/IndieWeb'e nasıl katılacağımı düşünüyordum ve bu alanda deneyler yapacak bir uygulama yapmayı planlıyordum
Nadir paylaşımların selin içinde kaybolmamasını sağlama sorunu ya da hangi dil ve teknolojileri kullanacağım gibi teknik kaygılar bile benziyor. Web geliştirmede yaklaşık 10 yıl gerideyim ama modern web teknolojileriyle bir şeyler yapmayı da düşünmüştüm
Bir yandan son düşünce ve duygularımın doğrulandığını hissettiğim için mutluyum. Doğru yolda olduğumu hissediyorum. Öte yandan yazarın bunu benden önce yapmış olması canımı sıkıyor ve kıskançlık da kalıyor
O zaman kendi RSS okuyucumu istiyordum. Mevcut okuyuculardan hoşlanmıyordum; gelen kutusu gibi değil, sıradan bir blog gibi görünen ve istediğim gibi tasarlayabileceğim bir okuyucu istiyordum. Bu yüzden bir RSS akışı ayrıştırıcısı yaptım ve normal blogum gibi görünecek şekilde tasarladım
Sonra RSS akışında yalnızca özet varsa yazının tamamını getirecek şekilde değiştirdim. Tam yazıyı görmek için okuyucunun dışına tıklamak istemiyordum; her şeyin akış okuyucunun içinde olmasını istiyordum. Temel bir sayfa kazıyıcı ortaya çıkınca RSS'i olmayan sitelerde de kullandım; sosyal medya popüler olduğunda özellikle işe yaradı
Gerçek sosyal sitelere gitmeye gerek kalmadan istediğim içerikleri kendi akışımda görebiliyordum. 20 yıllık bir şey olduğu için PHP ve XSLT gibi eski teknolojilerle yapılmış durumda ve hâlâ öyle
Her hâlükârda kendin yapmanı şiddetle tavsiye ederim. Eğlenceli bir proje. Eski ve kaba saba, kazıma işlemi mükemmel değil; istediğim içeriğin çıkmadığı zamanlar da oluyor ama benim ve 20 yıldır her gün kullandığım bir okuyucu olduğu için seviyorum
Benzer bir deneme yapmanın işe yaramaması için bir neden yok. Kişisel okuyucu uygulayan ilk kişi de değildi
İlginç olan, bağlantı verdiğim IndieWeb yazısını tekrar gözden geçirince, o yazıdaki fikirleri neredeyse aynen tekrarlamışım gibi hissetmemdi. “Herkes için yazılım yapmaya çalışma, kendin için yap” tarzı bir tavsiye
Genel amaçlı yapmaya ve başkalarının kolay kullanabileceği hale getirmeye çalışırsan, kendi kullanılabilirliğini zedeleyen tavizler verebilir ya da var olmayan hayalî kullanıcılar için tasarım yapabilirsin. Yani bencilce yapıp kendin için daha yararlı hale getir demek
Gerçekten ferahlatıcıydı. Son 1 yılda çok benzer bir tükenmişlik/iyileşme yolundan geçtim ve işe yarar kişisel yazılımlar yaparak işten yeniden keyif alır hale geldim
Bir başka büyük artı da istediğin “alışılmadık” teknolojileri gönlünce deneyebilmek. Modern tarzda tek binary PHP çalıştırılabilir dosyası yapmak, prod ortamında SQLite kullanmak, Docker olmadan dağıtım yapmak gibi şeyler keyif veriyor
Bu çalışmaların asıl işime de yansımaları oldu. Kişisel depolarda yeni teknikler ve optimizasyonlar keşfedip bunları sık sık işime taşıyorum
Teknik insanların yan projelerde bir şeyler kurcalaması ve orada öğrendiklerini işlerinde yararlı, bazen de değerli biçimlerde kullanması ilginç. Ama işverenler bazen bu çabaları küçümsüyor ya da tutkuyu engelliyor
Belki de yanlış türden kurumlarda çalışmışımdır. Yine de bu yansıma etkisinin faydasını görmene sevindim
Okunacak/tüketilecek şeylerden oluşan bir kontrol listesindense akış zihniyetini seviyorum. Birkaç yıl boyunca birkaç RSS okuyucu denedim ama hiçbirinde uzun süre kalamadım
Bir gelen kutusunu daha yönetmeye gerek var mı diye düşündüm. Yine de feedi'ye (https://github.com/facundoolano/feedi) bakmayı düşünüyorum
Bunu kurmadan önce HN'de yeni bir şey var mı, Reuters'ta var mı diye amaçsızca oradan oraya tıklardım. Benim deneyimim https://news.ycombinator.com/item?id=38642092 ile örtüşüyor
Kişisel e-postalar, e-posta listeleri ve RSS akışları tek yerde toplanıyor. Ayrı spool'lara filtreleyip mutt gibi güçlü bir e-posta istemcisiyle birlikte kullanınca oldukça konforlu bir birleşik deneyim oluyor
Yazar, uygulamaya her yerden erişmek için kimlik doğrulama eklemiş gibi görünüyor
Bunun yerine bir VPN'e koyup, o VPN'i her yerden erişilebilir yapmak mümkün mü ya da daha kolay mı olur merak ediyorum
Kişisel web uygulamalarına güvenli şekilde erişmek istiyorum ama en kolay yaklaşımı arıyorum. Kimlik doğrulamaya her baktığımda kavramlar, protokoller ve kütüphanelerden oluşan bir labirent gibi geliyor; bunu bakımını üstlenmek istemiyorum
Evdeki Raspberry Pi üzerinde Home Assistant gibi birkaç uygulama barındırıyorum; o Pi'ye ve telefonuma Tailscale kurdum, çok iyi çalışıyor. Yapılması gereken tek kimlik doğrulama “her cihazda Tailscale'e giriş yapmak”
Kendi cihazlarınızdan güvenli bir ağ kurmanın kolaylığı açısından Tailscale'i gerçekten şiddetle tavsiye ederim
Başka web sitelerinden kırptığım metin parçalarını barındıran uygulamamı “korumak” için yeterli
Birçok yöntem var ama özü, VPN uç noktası ile web uygulamasını aynı konuma, örneğin aynı makineye ya da aynı ağa koymak ve web uygulamasına diğer konumlardan erişimi kısıtlamak
Caddy'yi yalnızca iç ağdan veya VPN'den gelen istekleri reverse proxy yapacak, aksi halde 404 döndürecek şekilde yapılandırdım. Bu yüzden VPN'de ya da ev ağında değilseniz hiçbir şey görünmüyor
Misafirlere ağı açıp açmadığınıza ve hangi servisleri çalıştırdığınıza bağlı olarak VLAN ya da ayrı bir misafir ağı gerekebilir. Evde çalıştırdığım birçok servisin kendi parola doğrulaması da var; bunu VPN kısıtlamasıyla birlikte kullanıyorum
Bu yapılandırma benim ilk aklıma gelen yöntem olduğu için uzmanlık alanım dışındaki nedenlerle güvenli olmayabilir. Artısı, aynı compose dosyasında Pi-hole da çalıştırmam; telefon VPN'e bağlanınca uzaktan reklam engellemeyi de “bedavaya” elde ediyorum
Tailscale'in kurulumu daha kolay ve arayüzü de iyi, ama iOS'ta çok pil tükettiği için bıraktım. “Başkasının sunucusuna güvenmek” zorunda olmak da bir sorun; yine de pil sorunu olmasaydı kolaylık uğruna bu ek riski muhtemelen alırdım
WireGuard uygulamasında kullanışlı bir özellik de var. Evdeyken olduğu gibi belirli ağlarda çalışmamasını belirtebiliyorsunuz; dışarı çıkınca otomatik açılıp eve gelince kapanabiliyor
Bu, seyir yatında ihtiyaç duyduğumu düşündüğüm şeye şaşırtıcı derecede yakın. Özellikle açık denizde bağlantı kesintili olduğundan, iki şey daha eklenirse tam isabet olur
LTE'nin çektiği bir adanın yanından geçerken olduğu gibi kısa süreli bağlantı anlarında şimdi senkronize et düğmesine basabilmek gerekir. Ayrıca varsayılan olarak Readability işlemesi ve yerel önbellekleme yapıp, görseller dahil tüm içeriğin çevrimdışı okunabilmesi gerekir