Bagaimana saya bisa menghindari menggunakan nama saya sendiri di pengidentifikasi, paket, atau ruang nama proyek sumber terbuka yang saya buat?


15

Saya melakukan banyak pengembangan di waktu saya sendiri. Proyek-proyek yang saya kerjakan ini semua hanya untuk bersenang-senang dan belajar (sejauh ini). Saya biasanya melakukan pengembangan Java dengan Maven tetapi saya juga dikenal berkecimpung di .NET dan Python. Semua proyek yang saya kerjakan menggunakan lisensi open source, meskipun kebanyakan dari mereka tidak pada repositori kode publik.

Pengembangan Java / Maven mengharuskan saya untuk menggunakan struktur unik groupId(mis. "Com.mydomain") dan unik package(direktori), biasanya berisi pengembangan groupIdsementara .NET mendorong keunikan namespacesdi mana saya menggunakan konvensi serupa dengan packagekonsep Java . Untuk memastikan keunikan, saya biasanya hanya menggunakan salah satu nama domain saya dengan bagian yang dibalik (mis. "Ca.jessewebb"); Saya percaya ini adalah praktik yang sangat umum.

Saya sedang dalam tahap awal membuat proyek Java / Maven, open source, baru (sebut saja "newproj") dan saya ingin meletakkannya di GitHub. Username saya di GitHub itu "jessewebb" jadi ini akan memberikan URL seperti: https://github.com/jessewebb/newproj. Saya tidak ingin repot mendaftarkan nama domain "newproj.com" jadi saya memutuskan untuk menggunakan "ca.jessewebb" dan "ca.jessewebb.newproj" sebagai groupIddan package, masing-masing.

Terpikir oleh saya bahwa keberadaan identitas pribadi saya dalam kode dan sebagai bagian dari rumah proyek (di URL GitHub) kemungkinan akan menyebabkan kontributor potensial untuk berpikir dua kali untuk terlibat dengan proyek saya. Ini masalah, saya tidak ingin itu menjadi proyek saya . Saya lebih suka jika saya bisa, sebagai gantinya, menyampaikan pesan bahwa saya tidak memiliki proyek. Sekarang, dalam semua kejujuran, itu sebenarnya bukan masalah besar karena saya ragu proyek saya akan mengumpulkan banyak keterlibatan masyarakat tetapi saya juga melihat ini sebagai alasan yang lebih besar untuk menghindari kemungkinan menghalangi calon kontributor.

Sebagai contoh lain, saya membuat proyek Google Code beberapa tahun yang lalu (sebut saja "oldproj"). Ketika saya membuat proyek, saya tahu saya akan meng-host-nya di Google Code jadi saya menggunakan groupIddan mengemas nama "com.googlecode.oldproj", yang merupakan kebalikan dari nama domain default yang disediakan Google Code pada setiap proyek baru. Ini ternyata bukan ide yang terlalu bagus; setahun atau lebih kemudian, saya memindahkan kode ke repo yang berbeda dan saya harus mengganti nama pengidentifikasi ini (baik saya tidak punyauntuk tetapi ...). Pada saat itu, saya tidak memiliki nama domain dan akhirnya saya membeli nama domain "oldproj.com" dan saya menggunakannya. Saya suka ini karena memberi proyek identitasnya sendiri dan saya tidak mencap nama saya pada kode di mana-mana. Saya bisa saja dengan mudah mendaftarkan nama domain "jessewebb.ca" dan menggunakan "ca.jessewebb.oldproj" sebagai nama paket, tetapi saya tidak melakukannya karena saya mempunyai masalah yang sama saat itu juga.

Jadi pertanyaan saya adalah ...

Bagaimana saya bisa menghindari menggunakan nama (domain) saya sendiri saat membuat proyek sumber terbuka sambil tetap mempertahankan keunikan paket / ruang nama?

Sebagai proyek mendapatkan momentum lebih, masuk akal untuk mendaftarkan nama domain tetapi tampaknya konyol dan buang-buang uang untuk melakukan ini sebelumnya. Saya menyadari bahwa saya sebenarnya tidak harus memiliki nama domain untuk menggunakannya dalam kode tetapi itu terasa salah dan dapat menyebabkan penghuni liar mengambilnya dari bawah Anda sementara itu. Apa yang dilakukan orang lain tentang dilema ini? Apakah ada contoh proyek sumber terbuka populer (digunakan secara luas, komunitas besar, dll.) Yang berisi identitas pengembang asli sebagai bagian dari pengidentifikasi sendiri?


2
Wah, cukup panjang, tapi masih pertanyaan yang bagus!
Marcel

1
Gunakan UUID di paket / ruang nama Anda? ;-)
Jeroen

Jawaban:


5

Dalam proyek saya, saya memberi mereka nama tetapi tidak harus domain. Jadi nama paket saya (dan ruang nama) biasanya hanya "projectname.libraryname", terlepas dari mana kode tersebut diinangi.

Saya terbiasa dengan .NET di mana handeled ini cukup bebas.


Saya pikir ini solusi yang baik ketika saya tidak memiliki atau (segera) ingin domain terdaftar untuk proyek ini. Saya bahkan bisa melakukan ini ketika saya memiliki domain. Bahkan akan membantu memastikan saya menggunakan nama proyek yang unik, yang tidak pernah merupakan hal yang buruk. Saya mungkin akan segera menerima jawaban ini, kecuali ada jawaban yang lebih baik. Terima kasih!
Jesse Webb

Ya, .NET programmer melakukan ini, tetapi itu bukan ide yang baik. Jika nama proyek adalah kata yang dibuat-buat, itu bisa berjalan dengan baik, tapi saya berharap saya punya satu dolar untuk setiap proyek "Downloader" atau "Browser" yang pernah saya lihat.
Ross Patterson

1
Saya sudah mulai menggunakan strategi ini untuk semua proyek saya. Saya datang dengan nama unik untuk proyek, hampir nama-kode (maafkan kata-kata), dan menggunakannya untuk paket / ruang nama saya. Menghemat saya karena khawatir tentang nama domain, setidaknya sampai waktunya tiba ketika saya menginginkannya.
Jesse Webb

2

Saya tidak ingat di mana saya melihatnya, tetapi saya melihatnya menyarankan untuk menggunakan struktur seperti ini:

YourIdentifier.YourProduct.YourComponent

Identifier Anda dapat berupa domain yang Anda miliki, alias internet Anda (yang cukup unik), dll. Nama komponen tidak digunakan untuk kode "inti" produk Anda. Misalnya, saya memiliki kerangka kerja MVC kecil bernama BarelyMVC, jadi saya memiliki ruang nama seperti ini di dalamnya:

Earlz.BarelyMVC
Earlz.BarelyMVC.Authentication
Earlz.BarelyMVC.Caching

dll. alias online Anda dalam banyak kasus sangat unik untuk menghindari konflik antara pengembang lain

Jika Anda takut menggunakan alias daring sendiri, buat sendiri "label" untuk diri sendiri. Tidak harus terdaftar secara resmi sebagai perusahaan atau apa pun (atau bahkan domain). Misalnya, Json.Netperpustakaan populer menggunakan namespace Newtonsoft.Json. Ini jelas didasarkan pada nama belakang penulis "newton", tapi saya tidak berpikir ada yang benar-benar peduli tentang itu. Dan jika Anda memiliki perusahaan resmi terdaftar, maka Anda tentu saja dapat menggunakannya. Sebagian besar API publik yang diproduksi oleh perusahaan saya misalnya memiliki ruang nama yang diawali dengan PreEmptiveSolutions, nama perusahaan


1
Sangat umum di dunia .NET, di mana nama domain mundur tidak pernah benar-benar menarik perhatian. Dan selama "YourIdentifier" benar-benar unik, ia berfungsi. Tetapi bahkan Newtonsoft hanya kebetulan unik - James Newton-King tidak benar-benar menjalankan perusahaan seperti itu, dan merek dagangnya hanya akan ada di Selandia Baru jika dia melakukannya.
Ross Patterson

1

Tidak ada aturan bahwa nama paket Java atau .NET namespaces menjadi nama domain. Bahkan tidak ada persyaratan bahwa mereka harus unik, meskipun itu pasti Ide yang Bagus. Saya benar-benar berpikir Anda benar untuk digunakan com.googlecode.oldproj, dan di sepatu Anda, saya tidak akan beralih ke com.oldprojkecuali saya mencoba untuk mendapatkan publisitas untuk nama domain baru.


Saya menyadari tidak ada aturan bahwa Anda harus menggunakan nama domain, tapi saya pikir itu adalah praktik yang sangat umum, setidaknya di dunia Java dan .NET, hanya karena itu membantu memastikan keunikan. Juga, kamu bilang kamu pikir aku benar untuk digunakan com.googlecode.oldproj, mengapa kamu pikir ini adalah ide yang bagus? Dalam retrospeksi, saya pikir itu agak konyol untuk mengikat kode ke penyedia hosting.
Jesse Webb

1
Intinya bukan bahwa itu mengikat Anda ke beberapa penyedia hosting, intinya adalah bahwa itu adalah pengidentifikasi unik yang khas untuk proyek ini. Itu semua "com.jesseweb.oldproj", secara teknis. Jadi karena Anda tidak ingin nama Anda terlampir, itu adalah keputusan yang bagus. Paket Java dan .NET namespaces tidak seharusnya menjadi rambu-rambu yang mengarahkan Anda ke situs unduhan , dll. , Hanya pengenal yang unik karena konvensi.
Ross Patterson
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.