Bloglamaya Başlayın: Geliştiriciler İçin Temel Bir Kılavuz

Yani blog başlatmak isteyen bir geliştirici misiniz? Bu kılavuzda, alan adlarından site oluşturmaya, SEO ve dağıtıma kadar kendi blog sitenizi yönetme konusunda size rehberlik edeceğim.

İçindekiler

• Bölüm 0 (isteğe bağlı) - Blog platformlarında yazmaya başlayın
  • Geliştirme
  • Hashnode
  • HackerÖğlen
• Bölüm 1 - Alan adı satın alın
  • Hangi alan adını seçmelisiniz?
  • Alan adı nereden satın alınır?
  • Alan adı maliyetleri
• Bölüm 2 - Statik Site Oluşturucu kullanarak basit bir site oluşturma
  • Statik Site Oluşturucu Nedir?
  • Neden SSG kullanmalısınız?
  • Hugo ile basit bir site oluşturma
• Bölüm 3 - Blogunuzu barındırın
• Bölüm 4 - Analitik
• Bölüm 5 - Temel SEO
  • Google'a var olduğunuzu bildirme
  • Sorunlar kontrol ediliyor
  • Kanonikleştirme ve Kanonik URL'ler
  • Özel GitHub deposu
  • Geri bağlantılar ve alan adı otoritesi
• Bölüm 6 - Çalışmanızı paylaşma
  • Reddit'i kullanın
  • Belirli alt dizinlerde yayınlayın
  • Her alt düzenleme için kuralları kontrol edin
  • Topluluğun bir parçası olun
• Bölüm 7 - Blog platformlarında yeniden yayınlama
  • Yeniden yayınlanan makaleler için kanonikleştirme
    • dev.to için kanonikler
    • Hashnode'daki Kanonikler
    • HackerNoon'da kanonikleştirme
    • FreeCodeCamp'te kanonikleştiremezsiniz!
  • Tanıtım sizin için yapıldı
  • Yeniden yayınlama dezavantajları
• Ek
  • Neden blog?
    • Yazma ve iletişim becerilerinizi geliştirir
    • Neden bahsettiğinizi bildiğinizi kanıtlamanın bir yolunu sunar
    • Kendinizi pazarlamanıza yardımcı olur ve fırsatlar yaratır
  • SSG'lerin hızlı bir karşılaştırması
    • Jekyll
    • Onbir
    • Gatsby
    • Hugo

Bölüm 0 (İsteğe Bağlı) - Blog Platformlarında Yazmaya Başlayın

Kendi sitenizi kurma çabasına girmeden önce biraz ısınmak istiyorsanız yapılacak en kolay ve en basit şey, yazmaya başlamak ve çalışmalarınızı mevcut blog platformlarına katkıda bulunmaktır.

Sonuçta blog yazmanın en zor yanı gerçek yazı yazmaktır - en azından biz geliştiriciler için durum genellikle budur! Bu nedenle, beğenip beğenmediğinizi görmek için önce onu hissetmenin zararı olmaz. Ayrıca, daha sonra göreceğimiz gibi, kendi ayrı blog sitenizi kursanız/kurduğunuzda bile bunlardan faydalanmak hâlâ faydalıdır.

Geliştirme

Muhtemelen dev.to'yu zaten duymuşsunuzdur; hâlâ en büyük geliştirici blog platformudur ve başlamanızı tavsiye ettiğim yer burasıdır. Basit işaretleme düzenleyicilerini kullanarak kolayca yazmaya başlayabilirsiniz ve geniş bir okuyucu kitlesine sahiptir, böylece çalışmanıza hemen çok sayıda göz atacaksınız.

Gönderilerinizi kaç kişinin okuduğunu ve hatta bunları nasıl bulduğunu (ör. Reddit veya Twitter) görmenize yardımcı olabilecek harika yerleşik analizlere sahiptir. Bu, çalışmanızı paylaştığınızda en iyi neyin işe yaradığını görmenize yardımcı olur.

Tasarımı, mesaj panosu tarzı tartışma konularının yanı sıra, beğeniler ve gönderilere verilen tepkiler de dahil olmak üzere çok sayıda sosyal medya tarzı öğe içerir. (Zevkinize bağlı olarak bu bir profesyonel veya aleyhte olabilir.)

Herhangi bir şüpheniz varsa buradan başlayın!

Hashnode

Hashnode daha yeni bir geliştirici blog sitesidir. Bana göre dev.to'dan çok daha profesyonel bir havası var. Dev.to'dan çok daha çok blog odaklı ve bir sosyal medya sitesine daha az benziyor; size ayrı bir blog alt alan adı verir ve blogunuza site içinde biraz ayrı bir kimlik kazandırır.

İsterseniz bunu kendi özel alan adınıza bile bağlayabilirsiniz.

Ne yazık ki, dev.to'ya göre çok daha az popüler ve deneyimlerime göre bu siteden neredeyse hiç trafik alamıyorum. Daha sade tarzını beğeniyorsanız, bir göz atmaya değer olabilir, ancak gönderilerinizin fark edilmesi için daha fazla ayak işi yapmayı bekleyebilirsiniz.

HackerÖğlen

HackerNoon , dev.to & Hashnode'dan çok farklıdır; buraya gönderdiğiniz herhangi bir makalenin, yayınlanmadan önce makalenizin en iyi durumda olmasını sağlamak için sizinle birlikte çalışan bir insan editörden geçmesi gerekir. Ancak makalenizi hiç yayınlamamayı tercih edebilirler.

Bunun bazı dezavantajları var; Bir yandan bu harika bir öğrenme deneyimi ama diğer yandan istediğiniz zaman ve ne istediğinizi yayınlama özgürlüğünüzü kısıtlıyor. Bu nedenle, size sağlayacağı öğrenme deneyimi için çalışmanızı HackerNoon'a göndermenizi öneririm, ancak blogunuzun ana merkezini başka bir yerde tutmayı düşünün.

Bölüm 1 - Alan Adı Satın Alma

Ne yazık ki, kendi blogunuzu oluşturmak geliştiricilerin en korkulan görevlerinden birini, yani şeylere isim vermeyi gerektiriyor! Tamamen teknik açıdan çok zor olmasa da, önceden araştırmaya ve düşünmeye değer; Sitenizi kurarken bunu iyice düşünün.

Hangi Alan Adını Seçmelisiniz?

Burada iki ana seçenek var:

1. Blogunuza kendinizin adını verin

2. Blogunuza ayrı bir adla kendi kimliğini verin

   
   

Her biri hakkında farklı görüşlerle karşılaştım; kendi bloguma sadece kendi adımı verdim. Benim düşüncem, eğer adınızı duyurmak için bir blog kullanıyorsanız neden adınızı blogunuzda kullanmayasınız?

Hangisini seçerseniz seçin, alan adınızı değiştirmenin biraz zahmetli olduğunu unutmayın; bu nedenle kendinize güvendiğiniz bir alan adı bulmak için zaman ayırmaya değer. Ancak, istediğiniz alan adı zaten alınmışsa, alan adınızı yeniden düşünmeniz veya uyarlamanız gerekebilir; bu nedenle, buna çok fazla karar vermeden önce, alan adınızın mevcut olup olmadığını kontrol edin.

Alan Adı Nereden Satın Alınır?

Muhtemelen BlueHost , Hostinger , GoDaddy ve Namecheap gibi birçok alan adı kayıt şirketini zaten duymuşsunuzdur.

Ancak göz atılması gereken en önemli nokta Google Domains'dir çünkü .dev alan adlarını satan tek kayıt şirketi Google'dır . Benim tavsiyem, eğer alabiliyorsanız .com hala en iyisi olduğudur, bu nedenle beğendiğiniz bir tane varsa onu tercih edin, yoksa .dev harika bir alternatif olabilir.

Alan Adı Maliyetleri

Alan adlarının değişen miktarlarda maliyeti olduğunu ve dahası, onları elinizde tutmak için her yıl ödeme yapmanız gerektiğini unutmayın. Alan adları yıllık 10 ABD Doları kadar ucuz olabilir; bu nedenle, iş amacıyla bir alan adı satın almıyorsanız, pahalı bir alan adı satın almadan önce iyice düşünün.

Bölüm 2 - Statik Site Oluşturucu Kullanarak Basit Bir Site Oluşturma

Statik Site Oluşturucu Nedir?

Statik site oluşturucu - veya SSG - bir web sitesi içeriğini, bir web sunucusunda tutulan statik dosyalar olarak sunulabilecek şekilde şablonlayacak ve oluşturacaktır.

Sitenin ana yapısını (ana sayfanız, gönderiler dizininiz, 'hakkında' sayfanız vb. gibi) ayarladıktan sonra, yalnızca işaretleme dosyalarını ekleyerek tam sayfalar oluşturabilirsiniz.

Neden SSG Kullanmalı?

Kısaca SSG'ler

• sana hızlı siteler ver

• GitOps iş akışını kullanarak yayınlamanıza izin verin

• güvenlidir (saldırılacak veritabanı yok!)

• platformların sağlayabileceği şeylerle sınırlı kalmak yerine, teknoloji becerilerinizden yararlanmanıza olanak tanır

  
  

Geliştiriciler olarak hemen hemen her gün çok benzer bir şey yapan bir şey kullanıyoruz: GitHub. Kod depolarımızda, benioku ve diğer belgeleri işaretlemeye yazacağız ve GitHub bunu bir web sayfasında görüntülenmek üzere güzel bir şekilde biçimlendirecek.

SSG, kendi blogunuz için hemen hemen aynı GitOps iş akışını takip etmenize izin verebilir. dev.to'da yazmaya başladığımda taslaklarımı Git deposunda yönetiyordum. Yayınlanmak istenene kadar bu sorun değildi, bu noktada içerikleri web düzenleyicilerine aktarmam gerekiyordu.

Bu iyiydi, ancak SSG'lerin GitHub'daki bir benioku güncellemek için kullandığınız iş akışının aynısını kullanmanıza izin verebileceğini öğrendiğimde, bu benim daha fazla bilgi edinmek istemem için yeterliydi.

Blog kurmanın yaygın bir yolu WordPress gibi bir şey kullanmaktır; Bunun elbette pek çok avantajı var, ancak tüm içeriğinizi bir veritabanında saklıyor. Statik olarak oluşturulmuş bir sitenin buna ihtiyacı yoktur, bu da öncelikle çok daha hızlı olacağı anlamına gelir.

Hız elbette her şey değildir, ancak Google sitenizin ne kadar hızlı yüklendiğiyle ilgilenir ; o halde neden SSG tarafından oluşturulan bir sitenin size sağlayabileceği hızdan yararlanmayasınız?

Hugo ile Temel Site Oluşturma

Statik bir site oluşturmak için Hugo'yu öneririm. Kısacası bunun nedeni popüler olması, iyi desteklenmesi, hızlı olması ve önceden hazırlanmış şablonlarla hızla çalışmaya başlamanıza olanak sağlamasıdır.

(Alternatif SSG'lerle ilgili ayrıntılar için ekteki SSG'leri Karşılaştırma bölümüne bakın.)

Hugo'nun resmi belgelerinin hızlı başlangıç sayfası, temel bir Hugo sitesi kurulumunun nasıl yapılacağına ilişkin harika bir açıklama sunar. Sağladığı adımları izleyin, ancak 'site oluştur' komutlarına ulaştığınızda bunları aşağıdaki şekilde değiştirmenizi öneririm:

 hugo new site quickstart cd quickstart git init echo "/public/" >> .gitignore echo "/resources/_gen/" >> .gitignore echo ".hugo_build.lock" >> .gitignore git clone https://github.com/leafee98/hugo-theme-flat themes/flat rm -rf themes/flat/.git/ themes/flat/.github/ echo "theme = flat" >> hugo.toml hugo server

Bunun resmi kılavuzdan aşağıdaki farklılıkları vardır:

• Bir .gitignore dosyası kurar

• Ananke teması yerine mükemmel 'Düz' temasını kullanıyor

• Temayı git alt modülü yerine kendi deponuzdaki kod olarak ayarlar; bu, temayı daha sonra kendi zevkinize göre ayarlamanızı çok daha kolaylaştırır.

GitHub deponuzu oluştururken onu özel yapın ; bu, daha sonra inceleyeceğimiz SEO nedenlerinden kaynaklanmaktadır.

Kılavuzu izledikten sonra, barındırmaya hazır bir siteniz olacak! Bu noktada büyük olasılıkla sitenin değiştirmek isteyeceğiniz yönleri olacaktır. Ancak bunun sizi ev sahipliği yapmaktan alıkoymasına izin vermenize gerek yok.

Daha sonra değiştirmekten kaçınmak isteyeceğiniz en önemli şey URL'lerinizdir ; diğer her şey daha sonra değiştirilebilir.

Bölüm 3 - Blogunuzu Barındırın

Hugo dokümanlarının Barındırma ve Dağıtım bölümünde açıklandığı gibi, statik bir siteniz olduğundan, hemen hemen her yerde ve neredeyse kesinlikle ücretsiz olarak barındırılabilir.

Elbette, WordPress tabanlı siteler için de çok sayıda ücretsiz/ucuz sunucu mevcut, ancak herhangi bir sunucu size yalnızca belirli bir bant genişliği sağlayacaktır; Genel olarak, statik bir site, aslında hiç para vermemiş olsanız bile, paranızın karşılığında daha fazla bant genişliği sağlar.

Hugo'nun barındırma kılavuzu birçok olasılığı listeliyor, ancak kişisel olarak Bryce Wray'in CloudFlare Sayfalarına gitme önerisine katılıyorum; ücretsiz katmanı muhtemelen piyasadaki en hızlı olanıdır ve kullanımı kolaydır.

'GitHub deposu kurma' bölümünden itibaren kılavuzlarını takip etmeniz yeterlidir. Bu noktada siteniz çevrimiçi olacak! Ancak my-blog-xyz.pages.dev gibi çirkin bir etki alanınız olacak. Sitenizi daha önce satın aldığınız alanda yayınlamak için CloudFlare'in özel alan adı ayarlama kılavuzunu takip etmeniz yeterlidir.

Bölüm 4 - Analitik

Gösterişlerin kibiri, her şey kibir!

— Vaizler 1:2

Aslına bakarsanız bu isteğe bağlı bir adımdır ancak bu noktada siteniz için analitik ayarlamaya değer. Belki de kibirliyim ama benim için blog yazmanın en büyük eğlencesi, insanların yazdıklarınızı gerçekten gördüğünü ve önemsediğini görebilmektir.

Statik bir site kurmanın sınırlamalarından biri, bir tür veritabanı gerektireceğinden analitiği kendiniz barındıramayacağınızdır. Ancak pek çok iyi üçüncü taraf analiz sağlayıcısı mevcut olduğundan bu zaten çok fazla sorun değil.

Muhtemelen duyacağınız en büyüğü Google Analytics'tir.

Analitiklerin üçüncü taraf bir sağlayıcıyla ayarlanması genellikle şunları içerir:

1. Hesap oluşturma

   
   

2. Sayfalarınıza bir javascript pasajı veya bağlantı ekleme.

Tavsiye ettiğim Hugo şablonunda head.html şablon dosyanıza aşağıdakine benzer bir şey eklemeniz yeterlidir:

 {{/* Include analytics, but only in production */}} {{- if hugo.IsProduction | or (eq site.Params.env "production") }} <script defer data-domain="yourdomain.com" src="/link/to/script.js"></script> {{- end }}

Siteniz için GA kurmak istiyorsanız Google'ın resmi dokümanlarını takip edin.

Birlikte çalıştığım analiz sağlayıcısı Plausible'dır . Ne yazık ki ücretsiz değil - ayda yaklaşık 9 dolar - ama kullanımı kolay, hafif (komut dosyası 1kb'den az) ve gizliliğe saygı duyuyor, bu yüzden IMO'ya bir göz atmaya değer.

Bölüm 5 - Temel SEO

Eğer inşa edersen gelecekler

- Düşler alanı

Yukarıdaki alıntıda bazı gerçekler var; Blogunuzun Google'da yer alması için yapmanız gereken çok fazla bir şey yok ve şükürler olsun ki anahtar kelime doldurma maskaralıklarının olduğu günler geride kaldı ; sonuçta önemli olan iyi içerik yazmaktır ki bu da bizim gibi bağımsız blogcular için iyi bir haber.

Bununla birlikte, sitenizin arama motorları için güncel olduğundan emin olmak için yapabileceğiniz birkaç şey vardır.

Google'a Varlığınızı Bildirme

Google'ın web tarayıcıları eninde sonunda sitenizi bulacaktır, ancak bu kesinlikle Google'a bir avantaj sağlamaya ve sitenizi Google arama konsolunda ayarlamaya yardımcı olur. Aşağıdakileri yapmak isteyeceksiniz:

• Üye olmak

• Alan adresinizi kaydedin (alan adınızı Google Domains'den satın aldıysanız bu işlem büyük ölçüde kolaylaşacaktır)

• Site haritası sekmesine sitenizin sitemap.xml dosyasının URL'sini gönderin. Neyse ki Hugo sizin için https://yourdomain.com/sitemap.xml adresinde bir tane oluşturmuş olacak.

Bu yapıldıktan sonra Google (önümüzdeki birkaç gün içinde) web sitenizi taramaya başlayacaktır. Ancak arama konsolunda birkaç günlük bir gecikme olduğunu unutmayın.

Sitenizde nelerin dizine eklendiğini görmenin en güvenilir yolu site: sorgusunu kullanarak Google'da arama yapmaktır, örneğin site:yourdomain.dom .

Arama konsolunda kurulum yapmanın bir diğer yararlı faydası da 'Sayfalar' sekmesi altında, Google'ın sayfalarınızı neden dizine ekleyemediği veya dizine ekleyemediğiyle ilgili bildirilen sorunları görebilmenizdir.

Sorunları Kontrol Etme

Hugo ve kullandığımız şablon, iyi SEO uygulamalarının temellerinin çoğunu kapsamalıdır. Ancak yine de sitenizi Google'ın PageSpeed Insights aracından kontrol etmenin bir zararı olmaz. (Şablon dosyalarında ince ayar yaparak sitenizi kendi beğeninize göre düzenlemeye başladığınızda/başladığınızda bu daha önemli hale gelecektir.)

Bu size sayfanın performansı, erişilebilirliği ve SEO sorunları (eksik meta etiketler gibi) hakkında iyi bir genel bakış sağlayacaktır.

Kanonikleştirme ve Kanonik URL'ler

Bir blogcu olarak anlamanın anahtarı olan SEO kavramlarından biri kanonikleştirme ve kanonik URL'lerdir . Temel olarak fikir, aynı içeriğe farklı URL'ler aracılığıyla erişilebilmesidir, ancak Google'ın tek bir sayfanın sayfa sıralamasını birden fazla URL'ye bölmesini istemezsiniz.

Bu nedenle, bir sayfanın, arama motorlarının sayfanın URL'si olarak hangi URL'yi dikkate alması gerektiğini beyan etmesini sağlayabilirsiniz.

CloudFlare'in, özel alan adınızın yanı sıra my-blog-xyz.pages.dev gibi "çirkin" bir alan adı da oluşturduğunu unutmayın. Barındırma sağlayıcılarının çoğu (hepsi olmasa da) bu temel alan adını kapatmanıza izin vermez, ancak sayfalarınızda standart URL'ler ayarlandığı sürece bu bir sorun olmayacaktır - Google yalnızca özel alan adınız altında listeleyecektir. "çirkin" olan değil.

Hugo için Düz temayı önermemin nedenlerinden biri (Ananke'nin önerilen varsayılanının aksine) zaten kanonik bir bağlantı içermesidir. Ancak farklı bir tema kullanmak istiyorsanız bunu başlık şablonunuza şu şekilde ekleyebilirsiniz:

 <link rel="canonical" href="{{ .Permalink }}" />

Yukarıda bahsedilen PageSpeed Insights aracını kullanarak herhangi bir sayfa için bunun doğru şekilde ayarlandığını kontrol edebilirsiniz; “SEO” bölümünün altında bir sayfanın kanonik bir URL'ye sahip olup olmadığını bir kontrol listesi öğesi olarak göreceksiniz.

Kanonikleştirmeyi aşağıda yeniden yayınlama bölümünde daha ayrıntılı olarak inceleyeceğiz.

Özel GitHub Repo'su

GitHub deponuzu özel hale getirdiğinizi daha önce hatırlayacaksınız. Bunun nedeni (yazma sırasında) işaretleme belgelerine kanonik URL'ler veya noindex etiketleri ekleyememenizdir ve bu da başka bir ince kod çoğaltma sorunu olarak hizmet eder. Özel bir repo bu sorunu çözer.

Geri Bağlantılar ve Etki Alanı Otoritesi

Google'ın bir siteyi sıralamasındaki faktörlerden birinin, diğer kaç sitenin o siteye bağlantı verdiği olduğunu muhtemelen duymuşsunuzdur; buna etki alanı otoritesi denir ve bu bağlamda bir siteden diğerine verilen bu tür bağlantılara geri bağlantılar denir.

Blogunuzun Google'da daha üst sıralara çıkmasını sağlamak için geri bağlantıların nasıl "çiftleneceği" hakkında konuşmayacağım; Öncelikle, Google bu tür planlara karşı akıllıca davranmıştır ve ayrıca, kendi sitenizi oluşturmanın faydalarından biri de, web'i bu tür pisliklerle daha fazla doldurmak yerine, web'i daha iyi bir yer haline getirmeye yardımcı olabilmenizdir.

Bunun yerine ana çıkarım , Google'da iyi bir sıralamaya sahip olmanızın zaman alacağıdır ; Başlangıçta çok fazla etki alanı yetkiniz olmayacak, ancak bu zamanla büyüyecek. Her zaman olduğu gibi odak noktanız mümkün olan en iyi gönderileri yazmak olmalıdır.

Bölüm 6 - Çalışmanızı Paylaşmak

Reklam yalnızca kötü şeylerin reklamını yaptığında kötüdür.

-David Ogilvy

Her ne kadar Google'ın blogunuzu bulabilmesinin yeterli olduğunu söylemek istesem de gerçekçi olmak gerekirse, biraz tanıtım yapmak ve yayınlarınızı çevrimiçi paylaşmak gerçekten yardımcı oluyor.

Reddit'i kullanın

Bunu yapmanın en iyi yolu Reddit'teki makalelerinize bağlantılar göndermektir. Sosyal medyada paylaşım yapmak zarar vermez ancak Reddit'in en önemli avantajı, oylama sisteminin, iyi gönderilerin (sizinkinin de öyle olacağından eminim) hemen silinmek yerine bir süre alt dizinin ön sayfalarında kalabileceği anlamına gelmesidir. zaman çizelgesi boyunca.

Belirli Alt Dizinlerde Yayınlayın

Hakkında yazdığınız programlama dili veya teknolojisi gibi belirli bir alt dizine gönderin. Alt dizin ne kadar büyük olursa, gönderinizi potansiyel olarak o kadar çok kişi görecektir, ancak sorun şu ki /r/programming gibi büyük alt dizinler, kendi gönderilerini açık tutmaya yardımcı olmak için çoğu zaman taktiksel olarak iyi gönderilere olumsuz oy veren birçok kişiye sahip olabilir. tepe.

Bunun yerine, gönderiniz için geçerli olan en spesifik Reddit'lere sadık kalarak daha fazla şansınız olacak; bu tür toplulukların gönderinizi önemsemesi ve okuması daha olasıdır ve kendilerini tanıtmaya daha açık olurlar.

Her Alt Dizinin Kurallarını Kontrol Edin

Bir alt diziye aşina değilseniz, paylaşımda bulunmadan önce daima topluluk kurallarını kontrol edin . Her alt dizinin farklı kuralları, özellikle de kendi makalelerinize bağlantı verme konusunda farklı toleransları olacaktır.

Bu, kişisel reklamın tamamen yasaklanması, çok fazla paylaşım yapmamanız beklentisi veya hiçbir kısıtlama olmaması arasında değişebilir.

Dikkat edilmesi gereken bir diğer önemli kural ise istenmeyen gönderi konularının muhtemelen daha uygun bir alt dizine yönlendirilmesidir. Örneğin, /r/programming kuralları sizden teknik soruları bunun yerine r/learnprogramming yönlendirmenizi ve benzer şekilde iş listelerini /r/forhire yönlendirmenizi ister.

Topluluğun bir parçası olun

Gönderdiğiniz alt dizinin kuralları ne olursa olsun, Reddit'i yalnızca kendi amaçlarınız için bir araç olarak kullanmak yerine topluluğun bir parçası olmak her zaman iyi bir fikirdir. Hoşunuza giden diğer bloglardan bağlantılar yayınlayın, tartışmalara katılın ve sadece eğlenin.

Sorumlu bir şekilde katılıp katılmadığınızı kontrol etmek için arada bir “Reddiquette” i okuyun.

Bölüm 7 - Blog Platformlarında Yeniden Yayınlama

Kendi ayrı blogunuza sahip olmak ne kadar ödüllendirici olsa da, yazılarınızı dev.to gibi geliştirici bloglama platformlarında yeniden yayınlamak da faydalıdır. Kendi blogunuzu kurmaya zaman ayırdıktan sonra neden tekrar geri döndüğümüzü merak edebilirsiniz.

Sonuçta önemli olan tek şey, düşüncelerinizin diğer geliştiriciler tarafından okunmasını ve takdir edilmesini sağlamaktır ve yeniden yayınlamak, insanların çalışmanıza ulaşması için başka bir yol ekleyerek bunu yapmanıza yardımcı olur.

Diğer bir önemli faydası da, geri bağlantılar aracılığıyla kendi blogunuz için etki alanı otoritesi oluşturmanıza yardımcı olmasıdır; ancak sitenizin bu geri bağlantılarla anılması için, doğru şekilde yeniden yayınlamanız gerekir.

Yeniden Yayınlanan Makaleler için Kanonikleştirme

Daha önce tartıştığımız kanonik URL kavramını hatırlıyor musunuz? Makalelerinizi başka bir yerde yeniden yayınlarken, ideal olarak yalnızca makalenizin standart sürümünün blogunuzdaki sürüm olduğunu belirtmenize izin veren sitelerde yayınlamak istersiniz.

Bu şekilde, yeniden yayınlamanın görünürlük avantajlarından yararlanırsınız, ancak sonuçta ortaya çıkan herhangi bir geri bağlantı, kendi blogunuzun etki alanı otoritesini oluşturur.

dev.to için kanonikler

dev.to'nun editör kılavuzunda ayrıntılı olarak açıklandığı gibi, bir gönderinin "ön konu" özelliklerine canonical_url özelliğini ekleyerek kanonik bir URL ekleyebilirsiniz.

Hashnode'daki Kanonikler

Bir Hashnode makalesinde “Yeniden yayınlıyor musunuz?” başlığı altında kanonik bir URL ayarlayabilirsiniz. Bir makalenin “Makale ayarları” görünümündeki bölüm. (Daha fazla ayrıntı için belgelerine bakın.)

HackerNoon'da kanonikleştirme

HackerNoon'un belgelerinde anlatıldığı gibi, yayınınızın ayarlarındaki "İlk Görülme Yeri" bölümünde standart bir URL ayarlayabilirsiniz.

FreeCodeCamp'te kanonikleştiremezsiniz!

Bu Hashnode makalesinde belirtildiği gibi, çalışmanızı FreeCodeCamp'te yeniden yayınlamadan önce iki kez düşünün, çünkü FreeCodeCamp kanonik bir URL ayarlamanıza izin vermez. Aslında bu geliştirici gönderisi , bu durumun bazı blog yazarları üzerinde yarattığı olumsuz etkiyi ayrıntılarıyla anlatıyor.

Tanıtım Sizin İçin Yapıldı

Yeniden yayınlamanın bir başka faydası da çalışmanızı Reddit ve diğer sosyal medyada paylaşmanın bazı gerekliliklerinin genellikle sizin yerinize yapılmasıdır.

Belirli topluluklar için makaleler düzenleyen botlar ve blog yazarları, çalışmanızı genellikle blog platformlarındaki belirli etiketler aracılığıyla bulacak ve sosyal medyada paylaşacaktır.

Yeniden Yayınlamanın Dezavantajları

Ancak yeniden yayınlamanın bazı maliyetleri de vardır:

• Özellikle kendi sitenizde yayınlarken güzel GitOps akışının aksine, bu sitelerde yeniden yayınlamak biraz iş gerektirebilir. (Yine de burada işlere yardımcı olmak için bazı otomatik ve yarı otomatik çözümler mevcuttur.)

• Yeniden yayınlanan çalışmanızın, arama motorlarında orijinal çalışmalarınızı geride bırakması mümkündür. İdeal olarak, kanonik URL'ler, yeniden yayınlanan çalışmanın tamamen dizine eklenmediği anlamına gelir, ancak bu garanti edilmez (benim deneyimime göre özellikle Bing için)

Bu nedenle , orijinali yayınladıktan bir süre sonra (örneğin bir veya iki hafta, ancak bu size kalmış) yeniden yayınlamayı düşünmeye değer. Bunun aşağıdaki faydaları vardır:

• Orijinalleriniz ve yeniden yayınlarınız genelinde düzeltmeler ve eklemeler yaparak iş tekrarlarının azaltılması; Kaçınılmaz olarak, düzeltme çabalarınıza rağmen siz veya okuyucularınız gözden kaçırdığınız sorunları veya şeyleri fark edeceksiniz; bunu makale yalnızca kendi blogunuzda varken yapmak zorunda olmak daha iyidir.

• Arama motorlarının öncelikle sitenizi dizine ekleme zamanı vardır.

Ek

Neden Blog?

Yazma ve iletişim becerilerinizi geliştirir

Neyse ki Agile, yazılım geliştirmenin daha önceki dönemlerde olduğu gibi yığınlarca belge üretmeyi nadiren gerektirdiği anlamına gelse de, sarkacın biraz fazla diğer tarafa doğru sallandığını düşünüyorum ve yeni gelenlere bu konuyu tanıtmaya yardımcı olan iyi belgeler. bir sistem veya depo ne yazık ki ihmal edilmiştir.

Bir geliştirici olarak kariyerinizde ilerledikçe, düşüncelerinizi daha da netleştirmeye ve karmaşık kavram ve sistemleri açık ve öz bir şekilde açıklamaya daha fazla ihtiyaç duyacaksınız.

Blog yazmak size bu becerileri geliştirmeniz için harika bir yol sunar. Özellikle izleyici kitlesine sahip olmak büyük bir motive edici faktördür!

Neden bahsettiğinizi bildiğinizi kanıtlamanın bir yolunu sunar

Bildiğiniz teknolojilerin bir listesinin özgeçmişinizde yer alması bir şeydir; zanaatınızı baştan sona bildiğinizi açıkça gösteren, yazdığınız makalelere bağlantı vererek onları gerçekten anladığınızı kanıtlamak bambaşka bir şeydir.

Kendinizi pazarlamanıza yardımcı olur ve fırsatlar yaratır

Jeff Atwood, Joel Spolsky ile kısmen Coding Horror adlı blogu aracılığıyla tanıştı ve daha sonra Stack Overflow adında küçük bir şey yaratmaya devam ettiler.

Sadece bir blog oluşturarak bu tür şeylerin gerçekleşeceğini garanti edemezsiniz, ancak kesinlikle zararı da yoktur. Özellikle niş teknoloji alanlarında, geçmişte bir makalenizi okumuş biri aracılığıyla isminizin ön plana çıktığını görebilirsiniz.

SSG'lerin Hızlı Bir Karşılaştırması

İşte birkaç popüler SSG hakkındaki düşüncelerim ve Hugo'ya nasıl karar verdiğim. Çok daha büyük bir liste için jamstack.org'a bakın.

Jekyll

Jekyll eskiden çok popülerdi ama artık daha az. GitHub sayfalarına güç verir ve oldukça blog odaklıdır. Başlangıçta bunu düşündüm, ancak blog sayfalarının URL'ye gömülü bir tarih bileşenine sahip olduğu konusunda ısrar eden katı URL yapısı nedeniyle ertelendi, bu da kendi blogum için kaçınmak istediğim bir şeydi.

Bu, daha soyut bir "koleksiyon" türünün parçası olarak yazılar yazarak önlenebilir, ancak bu, kendi blog yazısı soyutlaması içinde çalışmanın faydalarının çoğunu kaybedecektir.

Onbir

Eleventy, oldukça popülerlik kazanan bir SSG'dir. node.js tarafından desteklenmektedir ve çok esnektir; şablon oluşturma motorunu ve işaretleme oluşturucuyu özelleştirebilir, hatta aynı site içindeki farklı sayfalar için farklı seçenekler kullanmanıza bile izin verebilirsiniz.

Bununla ilgili bulduğum en büyük dezavantaj, herhangi bir yerleşik şablonla gelmemesi, dolayısıyla kutudan çıkar çıkmaz kolayca bir blog oluşturamamanızdır. Ayrıca, düğüm üzerinde çalıştığı ve kurulumunu daha karmaşık hale getirdiği de dikkate alınmalıdır; hiçbir şekilde anlaşmayı bozucu değil ama Hugo kadar kullanışlı da değil.

Gatsby

Gatsby de son zamanlarda oldukça popüler hale geliyor. Ancak statik siteler yerine tepki tabanlı tek sayfalık uygulamalar üretir. Bu geçerli bir seçenektir; Blogumu oluştururken saf HTML ve CSS'nin basitliğini istedim.

Üstelik bu yazarın onu kullanma konusunda kötü bir deneyime sahip olduğunu ve bunun yerine Hugo'yu önerdiğini gördüm.

Hugo

Son olarak kendi blogum için kullandığım SSG Hugo'ya geliyoruz. Go'da yazılmıştır ve onu kullanmanın tek bir ikili dosya yüklemek anlamına geldiği anlamına gelir. Bunun barındırma açısından avantajları vardır; sağlayıcımda Hugo sürümünü belirtebilirsiniz ve yerel olarak nasıl davranacaksa aynı şekilde davranacağından emin olabilirsiniz.

Hızla parlıyor. Blogunuz yalnızca birkaç gönderi içerdiğinde bu çok az fark yaratsa da, siteniz büyüdükçe oluşturma süresinin güvenilir bir şekilde hızlı kalacağını bilmek güzel.

En popüler SSG'dir (GitHub yıldızlarına bakılırsa) , bu da iyi kullanıldığı, belgelendiği ve hemen hemen tüm statik site barındırma platformları tarafından iyi desteklendiği anlamına gelir.

Her şeyden önce başlamanıza yardımcı olacak şablonlar var. Muhtemelen bir noktada kendi şablonlarınızı oluşturmak (veya en azından bunları kendi zevkinize göre değiştirmek) isteyecek olsanız da, bu size en azından kutudan çıktığı gibi başlamanız için bir şeyler verir.

Başlıca dezavantajı Go'nun şablon dilini kullanmasıdır; hiçbir şekilde berbat değil, ancak bazılarıyla karşılaştırıldığında biraz hantaldır ve eğer başka bir şablon diline meraklıysanız o zaman burada şansınız kalmaz. Bu sizin için bir sorunsa Eleventy'ye bir göz atmaya değer olabilir.