Açık Kaynak: O Kadar Korkunç Değil!

Aşağıdakiler, Kadın Geliştiriciler için Toptal Burslarının başlatılmasından önce yayınlandı.

Bir geliştirici olarak, teknolojideki en son trendlere ayak uydurmak heyecan verici ve zordur. Her gün yeni diller, çerçeveler ve cihazlar dikkatimizi çekiyor ve buluşmalarda, forumlarda ve sohbetlerde sohbetleri teşvik ediyor. Bununla birlikte, geliştirici topluluğumuz araçlardan değil insanlardan oluşur ve sosyopolitik yönlerini keşfetmek büyüleyicidir (daha iyi bir kelime olmadığı için; “sosyal” bugünlerde sosyal ağlarla ilişkilendirilme eğilimindedir).

Toptal'da kısa süre önce kadınların açık kaynağa ne kadar katkıda bulunduğu ve onların daha fazla katkıda bulunmalarını nelerin engelleyebileceği konusunda ilginç sohbetler yaptık, bu yüzden konuyu araştırdık. Breanden Beneschott ve Bozhidar Batsov ile bu sohbetin bir parçası olarak merak ettim: Bozhidar, GitHub'a en çok katkıda bulunanlardan biridir. Neredeyim? Bugün itibariyle herkese açık GitHub hesabıma bakarsanız, öğrencilerim için sınıfta kullandığım ağırlıklı olarak küçük test projeleri. Yarı pişmişler ve kesinlikle benim becerilerimi veya uzmanlığımı temsil etmiyorlar. (Bu konuda sözüme güvenmeniz gerekecek.) Biri beni bu hesapta bulabileceklerine göre işe almayı düşünse, sanırım geçimimi sağlamakta zorlanırım. Yine de 20 yılı aşkın süredir profesyonel bir geliştiriciyim ve günlük işimde hatırladığımdan daha fazla açık kaynaklı yazılım kullanıyorum. Zamanla, belirli bir ihtiyaca göre bükebilmek için Linux çekirdeğini hackledim, satın aldığım her yönlendiriciyi ve NAS'ı ayarladım, elime almak için aylarca sabırla Raspberry Pi bekleme listesinde bekledim ve ev yapımı ev bilgisayarımı aldım. Beğendim. Yine de, bu ince ayar ve testlerin hiçbiri GitHub'ı açık kaynak haline getirmedi. Ayrıca, Tomcat'in ilk sürümlerinden birindeki bir hatayı düzeltmenin yanı sıra, hiçbir zaman açık kaynaklı bir projeye katkıda bulunmadım. Meraklı, değil mi?

Bunun sadece zaman ya da ilgi eksikliği olduğunu düşünebilirsiniz, ama öyle olmadığını biliyorum. Kişisel projelerime gelince, yaptığım şeyle kimsenin gerçekten ilgilenmeyeceğini düşünmüş olabilirim, ancak çoğunlukla, çalışmamı herkesin görmesi ve gelecek kuşaklar için orada yayınlama fikri beni çok korkutuyor. GitHub'dan kişisel bir projeyi her zaman kaldırabilseniz de, yaygın olarak bulunan bir açık kaynak projesine katkıda bulunmaya çalıştığınız gün, geri dönüş yoktur. Ya kodum yeterince iyi değilse? Ya sorunu doğru anlamadıysam? Ya çekme isteğim reddedilirse? Ya insanlar beni trollerse?

Çoğu kadın olan geliştirici arkadaşlarla yaptığım kısa bir görüşme kısa sürede beni bu soruna sahip olan tek kişi olmadığıma ikna etti, ancak bir mühendis için sorun yoktur, yalnızca çözümler vardır, değil mi?

Bu çözülmesi gereken önemli bir sorun çünkü açık kaynaklı bir projeye katkıda bulunmak çarpıcı bir fark yaratabilir:

• Kariyeriniz boyunca : Birçok müşteri sizi işe almaya karar vermeden önce sosyal durumunuza bakacak; GitHub hesabınız ve LinkedIn özgeçmişiniz, Facebook ve Twitter profillerinizle birlikte listenin başında gelir. Onları akıllıca kullanmalısın.
• Teknik becerileriniz için : Diğer geliştiriciler ve genellikle çok iyi olanlar tarafından yazılmış bir kod tabanını incelemek size çok şey öğretir. Kötü yazılmış bir kod tabanından anlamı çıkarma yeteneği, size meydan okuyacak ve size de aynı şekilde öğretecektir.
• Sosyal becerileriniz için : Açık kaynak yazılım, işbirliğine dayalı bir süreçtir ve hemen hemen tüm ilginç projeler ekipler tarafından oluşturulur. Herkesin kullandığı araçlar aracılığıyla diğer geliştiricilerle çalışmayı, ekibe uyum sağlamayı, verimli iletişim kurmayı öğrenmek, sizi yalnızca yetenekli bir geliştirici değil, harika bir geliştirici yapacaktır.
• Topluluk için : Açık kaynaklı bir projeye katkıda bulunduğunuz her bit önemlidir. Ne kadar çok katkıda bulunursanız o kadar iyi olur, ancak çevirideki küçük bir yazım hatasını düzeltmek bile nihai ürünü daha iyi hale getirecektir.
• Ağınız için : Şirketlere yüzlerce özgeçmiş gönderebilirsiniz, ancak hiçbir şey kişisel bağlantıları olan meslektaşlarınız gibi olamaz. Açık kaynak kodlu bir projede aktif olarak yer almak, insanlarla tanışmanızı ve onların saygısını kazanmanızı sağlayacak ve herhangi bir profesyonel için paha biçilmez olan itibarınız artacaktır.

Bu, bu korkuyla savaşmak için benim küçük kişisel yolculuğum. Bu makaleyi yayınlamak, yolculuğun kendisinin bir parçasıdır. Blog yazısı yazması engellenen veya küçük bir katkıda bulunmaktan korkan herkesin sonunda bunun o kadar da korkutucu olmadığını görmesini umarak yazıyorum. Ayrıca, açık kaynağa katkıda bulunmak isteyen, ancak nereden başlayacağını gerçekten bilmeyen herkese yardım etmeyi amaçlıyor, bu yüzden temel bilgilerle başlayacağım.

Açık Kaynak Yazılım nedir ve onu nerede bulabilirim?

Açık kaynaklı yazılım veya kısaca OSS, kaynak koduyla birlikte yayınlanan herhangi bir yazılımdır ve onu değiştirmenize ve yeniden dağıtmanıza izin veren bir lisans içerir. Herhangi bir yere teslim edilebilir: bir web sitesinde, bir posta listesi aracılığıyla veya bir baykuşla. En yaygın ve bizim ilgilendiğimiz senaryo, kod tabanının ortak bir depoda sürdürülmesidir. Burada GitHub'a odaklanıyoruz, ancak SourceForge ve Bitbucket gibi başka seçenekler de var. GitHub çok arkadaş canlısıdır, geniş bir kullanıcı tabanına sahiptir, her türlü kod için ve kullandığınız herhangi bir geliştirme ortamı ile kullanılabilir. Daha da önemlisi, açık kaynaklı olmayan projeler için de yaygın olarak kullanılmaktadır. Muhtemelen bir sonraki müşteri projeniz orada barındırılacaktır, bu nedenle onunla nasıl çalışılacağını bilmek başlı başına faydalı bir beceridir.

Ya kodlamayı bilmiyorsam?

Bunu okuyorsanız, kodlamayı öğrenmek istiyor olabilirsiniz. Birkaç ücretsiz ve ücretli web sitesinde harika kurslar bulabilirsiniz. Öğrenmek için bir dil seçmelisiniz; bir tercihiniz yoksa, JavaScript ile gidin. Web tarayıcınızda başlamak için ihtiyacınız olan her şeye zaten sahipsiniz ve bu en yaygın kullanılan ve pazarlanabilir becerilerden biridir. Benim kişisel favorim hem web geliştirmede hem de bilimsel uygulamalarda kullanılan Python. Ayrıca, Udacity'de "Bilgisayar bilimine giriş" adlı kişisel favori başlangıç ​​kursum var. Seviyorum çünkü öğrendikçe bir proje üzerinde çalıştığınız uygulamalı bir kurs. Ayrıca Coursera, Khan Academy ve PluralSight'ta başka kurslar da bulabilirsiniz.

Ya Git'i bilmiyorsam?

Daha önce de belirtildiği gibi Git'i bilmek önemlidir, bu yüzden bir Git dersi alın. Git ile bir süredir çalışıyor olsanız bile yapın; Git hakkında gerçekten çalışmadan ne kadar bilmediğini bilemezsin. rebase komutunun ne yaptığını güvenle açıklayamıyorsanız yapın. Yanlış bir yeniden temellendirme sizi korkutmasa bile yapın. Code School'da tam Git yolunu kullandım, ancak yine daha fazla seçenek için diğer siteleri keşfedebilirsiniz.

GitHub'da nasıl proje seçerim?

Günlük gelişiminizde biraz OSS kullanmanız muhtemeldir. Tanıdık bir çerçeve seçmek iyi bir başlangıç ​​noktasıdır; özelliklere ve çerçevenin nasıl çalıştığına zaten aşinasınız. Kaynak koduna daldığınızda daha fazlasını öğreneceksiniz ve mantığını daha da net anlayacaksınız. Özellikle beğendiğiniz bir teknoloji veya araç varsa, ondan bahseden projeleri veya aracın projesinin kendisini arayın. Son çare olarak GitHub Vitrinlerinde projeleri inceleyebilir ve ilginizi çeken bir kategori seçerek başlayabilirsiniz.

Örneğin, GitHub'ın aramasında “Ahududu” için hızlı bir arama, 17 binden fazla depoyu gösterir. Kaybolmak kolaydır, bu nedenle iyi bir topluluğa ve iyi sorun takibine sahip bir proje arayın. Bir proje seçerken, aşağıdakilerin sayısını kontrol edin:

• Katkıda Bulunanlar : Katkıda bulunanların üzerindeki her şeyi hedefleyin. Bu, projenin yeterli ilgiye sahip olmasını ve sadece küçük bir ekip çalışması olmamasını sağlamalıdır. OSS'de yeniyseniz veya çok yetenekli değilseniz, aramanızı en fazla elli katkıda bulunan projelerle sınırlandırın; daha büyük topluluklar, daha büyük kod tabanları ve daha karmaşık projeler anlamına gelir.
• Taahhütler : En az bin taahhüt içeren ve en son aktivitenin bir haftadan eski olmadığı projelere gidin. Bir ay veya daha uzun süredir etkin olmayan bir proje, OSS açısından eski ve bayattır ve muhtemelen hızlı bir şekilde yanıt alamayacaksınız. Günlük aktivite sağlıklı bir projenin işaretidir.
• Sorunlar : Sorunlar, açık sorunlar, bildirilen hatalar veya uygulanması istenen özelliklerdir. Size bir başlangıç ​​noktası verecekler ve projeye gösterilen ilginin iyi bir ölçüsü olacaklar.

Ayrıca, projenin ana dilinin ne olduğunu öğrenin; dil istatistiklerini ana proje sayfasının üst çubuğunda görebilirsiniz. Tartışmanın tonunu okumak için biraz zaman ayırın, yorumların ne kadar samimi ve eğitimli olduğunu görün. Bazı projeler saldırgan toplulukları nedeniyle kötü bir üne sahiptir, bu nedenle doğru başlangıç ​​noktası olmayabilirler.

Sütunlu bir veri depolama projesi olan ScyllaDB'yi seçtim, çünkü verilere - performansla ilgili her şeye karşı bir hayranlığım var. Onunla hiç çalışmadım, ancak kod tabanına dalmayı umuyorum. Bildiğim araçlarla çalışmak daha kolay olabilir, ancak bunu bir meydan okuma ve yeni bir şeyler öğrenmek için bir fırsat olarak görüyorum. Geri kalanı için, tasarıya mükemmel bir şekilde uyuyor; 18 katkıda bulunan, 6.5k taahhüt (en son yazı yazılırken 23 saat önceydi), 178 açık konu ve aktif görünüyor.

Ben şimdi ne yapacağım?

İlk olarak, depoyu klonlayın ve hareketli parçaları hakkında bir fikir edinmek için yazılımı makinenize yükleyin. Ardından, konuları okumaya başlayın. Kendinizi hazır hissettiğinizde, sorunu makinenizde yeniden oluşturup oluşturamayacağınıza bakın ve ardından yazılımın hatalı çalışmasına neyin neden olduğunu analiz etmeye başlayın.

Başka bir yaklaşım, kendinizi geliştirebileceğiniz veya değiştirebileceğiniz bir şey bulmak olacaktır. Örneğin, bir yazım hatası veya yanlış hizalanmış bir yazı tipi fark etmiş olabilirsiniz. Küçük bir hatayı, özellikle de betiğin belgelerinde kullanılan yanlış bir değişken adını düzeltmeyi seçtim.

Küçük görünüyor, ancak yanlış dokümantasyon, dokümantasyon olmamasından çok daha kötü. Kullanıcılar ScyllaDB'yi kuracak ve kurulum adımlarını takip edecekler, bu komut dosyasında yazılanlara körü körüne güvenecekler ve sonunda büyük bir hüsranla karşılaşacaklar. Bu, yeteneklerim için mükemmeldi ve bunu düzeltmek, tüm süreci takip etmemi ve kod tabanına biraz aşina olmamı gerektirecek. Hata düzeltme sıkıcıdır, ancak bir projede yolunuzu bulmak için harika bir başlangıçtır.

çatal oluşturma

Bu önemsiz olabilir, ancak şu anda ScyllaDB projesi için ben Bayan Hiçkimseyim; denetim olmadan kodlarında değişiklik yapmama izin vermek riskli olur. Yapmam gereken kendi GitHub hesabımda bir “çatal” oluşturmak. İşte benim ScyllaDB çatalım. Tüm kodlara erişebildiğim kendi oyun alanım ve dosyaları istediğim gibi değiştirebiliyorum. Kendi ScyllaDB sürümümü oluşturmak ve orijinal amacından tamamen farklı bir şey yapmak için ince ayar yapmak isteseydim, bunu burada yapabilirdim. Bir çatal oluşturmak basittir; projenin ana sayfasına gidin ve “çatal” düğmesine tıklayın. Hiç korkutucu değil.

Hatayı düzeltme zamanı

Şimdi, kodu bilgisayarınızda test etme ve gerekli değişiklikleri yapma zamanı. Her şeyden önce, Git istemcisini makinenize yüklediğinizden emin olun. Ardından SSH ortak anahtarınızı GitHub'a ekleyin ve ssh aracınız tarafından yüklendiğinden emin olun. Kodu yerel olarak almak basittir; ana dal yerine çatalınıza işaret eden git clone komutunu kullanın:

 git clone [email protected]:acbellini/scylla.git

Şimdiye kadar projeyi ana dalda test etmiş olmalısınız, bu nedenle kodunuzu yerel olarak oluşturacak ve aynı şekilde test edeceksiniz. Referanslar göreceli olduğundan, projenizin dayandığı diğer GitHub projelerini çatallamanız gerekeceğini unutmayın. Benim durumumda, deniz yıldızı, scylla-ami ve scylla-swagger-ui'yi çatallamak zorunda kaldım.

Düzeltmem gereken hata nispeten basit; conf/scylla.yaml içindeki belgeler, yapılandırılabilir üç dizinden bahseder: Biri veri dosyaları için, biri işlem günlükleri için ve biri, görünüşe göre kullanılmayan önbellekler için, tümü varsayılan olarak $CASSANDRA_HOME alt dizinindedir:

Kodun içine dalmak, varsayılanların farklı olduğunu ve başladığım #372 numaralı konuda belirtildiği gibi $CASSANDRA_HOME kullanılmaması gerektiğini gösteriyor. Kodu birkaç farklı ayarla test ederek, ayarı yapılandırma dosyasından kaldırarak ve hangi dizinlerin kullanıldığını kontrol ederek hipotezimi doğrularım. Her şeyin doğru olduğundan yeterince emin olduktan sonra, değiştirilen dosyayı ekleyebilir, onaylayabilir ve gönderebilirim:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

Taahhüt mesajında ​​​​bir karmadan önce gelen sayı numarasını sunduğumu unutmayın. Bu, GitHub'a kodumu otomatik olarak sorunun kendisine bağlamasını söyleyecektir.

Unutulmaması gereken bir diğer önemli nokta ise, kodu araştırdığımda, önbellekler için olan üçüncü dizinin aslında kullanılmadığını fark ettim. Çok ileri gitmek ve bu ayarın kendisini kaldırmak veya kullanılmayan ancak 372 numaralı sorunun kapsamı dışında kalacak bir yorum eklemek caziptir ve bununla kesinlikle ilgili olmayan herhangi bir şey yapmak yanlış olur. konu. Değişikliklerinizi odaklanmış ve elinizdeki görevle sınırlı tutmalısınız.

Bu noktada kod düzeltildi ve özel çatalımda GitHub'da. Korkunç kısım burada devreye giriyor: ScyllaDB çalışanlarından kodumu kabul etmelerini istemek. Buna çekme isteği denir.

Son adım: çekme isteği

Doğrudan GitHub'daki web arayüzünden çekme istekleri oluşturmayı seviyorum. Komut satırından yapmaya çalışmaktan daha sezgisel ve hataya dayanıklı buluyorum. Çekme isteğimi oluşturmak için tek yapmam gereken şube adımın yanındaki küçük yeşil düğmeye tıklamak:

Yorumun GitHub tarafından otomatik olarak hesaplandığını unutmayın. Şubemin şimdi bir yeni taahhüdü var, ancak çatalımı oluşturduğumdan beri ana depoda 14 taahhüt daha var, bu yüzden soldaki yeşil simgeye tıklayacağım.

Neyse ki, tek taahhüdüm diğer 14 kişiyle çelişmiyor, bu nedenle GitHub, gitmeye hazır olduğumu bildiriyor. Başka bir yorum veya mesaj eklememe gerek yok. Taahhüt mesajı, çok kısa olmakla birlikte, her şeyi söylüyor: Kod değişikliğimin ne yaptığı ve neyle ilgili olduğu. İsteğimi onaylamak için son düğmeye tıkladığımda, birkaç gün önce bu kadar korkutucu bulduğum şeyin ne olduğunu merak ediyorum. Şu anda bana kükreyen bir canavar yok ve cehennemin alevleri yanıyor gibi de değil. Dürüst olmak gerekirse, hiç korkutucu değildi. Muhtemel bir durumda yanlış anladım, düzeltmem kabul edilmeyecek ve o kadar olacak.

Şimdi sorun ayrıntılarını kontrol ederseniz, GitHub'ın bu soruna atıfta bulunan bir çekme isteği olduğuna dair otomatik olarak bir not eklediğini görebilirsiniz. Bu, taahhüt mesajındaki # 372'nin büyüsüdür. Bu, başkalarının zaten düzeltilmiş bir şeyi düzeltmek için zaman kaybetmesini önlemeye yardımcı olacaktır.

Son notlar

Şimdi çekme talebimin kabul edilmesini bekliyorum, bu olduğunda bir bildirim alacağım. Bunun birkaç gün, hatta haftalar sürebileceğini unutmayın; birisinin kodumu gözden geçirmesi, açıklandığı gibi çalıştığını test etmesi, sorunu çözmesi ve nihayetinde kodun geri kalanının işlevselliğini olumsuz etkilemediğinden emin olması gerekir (okuyun: yeni hatalar oluşturur). Bütün bunlar birinin zamanını alır, bu yüzden sabırlı olun. Sonunda, çekme talebim kabul edildiğinde, ScyllaDB'nin bir katılımcısı daha, bir sorunu daha az olacak ve ilk OSS katkımı almış olacağım. Artık sizin de denemenizin zamanı geldi. Sonuçta, hiç de korkutucu değil.