
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ባለፉት ዓመታት፣ ሁሉንም ዓይነት ፕሮጀክቶች ላይ ሰርቻለሁ—ትላልቅ፣ ትናንሽ፣ ግራ የሚያጋቡ፣ ከመጠን በላይ የተነደፉ፣ “ጊዜያዊ”፣ በተባለ መልኩ በጥሩ ሁኔታ የተገነቡ፣ እና በመካከላቸው ያለውን ሁሉ። ግን አንድ አቀራረብ በ አስቂኝ ሁኔታ ወጥ የሆነ ሆኖአል: ሰነዱ ሁል ጊዜ የለም፣ ጊዜው ያለፈበት፣ ወይም በ 2019 የጊዜ ማህተም በተጠበቀው በ Confluence forgotten corner ውስጥ ተቀብሮ ይገኛል። እያንዳንዱ ፕሮጀክት ሰነድ እንዳለው  ይናገራል። እያንዳንዱ ቡድን ሰነዱን ወቅታዊ እንደሚያደርግ  ቃል ገብቷል። እና እያንዳንዱ ገንቢ በልበ-ሙሉነት እንዲህ ይላል፣ “አይጨነቁ፣ በኋላ እጽፈዋለሁ,” ይህም፣ ሁላችንም እንደምናውቀው፣ “ቼኩ በመልዕክት ላይ ነው” ከማለት ጋር እኩል ነው። ይህ ዑደት ከማመን ይልቅ ብዙ ጊዜ ሲደጋገም ካየሁ በኋላ፣ አንድ ቀላል ግን እውነት የሆነ ነገር ተገነዘብኩ: 
 
 ሰነድ የሚተርፈው ከኮዱ አጠገብ ከተቀመጠ ብቻ ነው—ምክንያቱም ገንቢዎች (እኔን ጨምሮ) ሰነፍ ፍጡራን ነን። ከዚያም ሌላ ግንዛቤ መጣ - ጊዜው ያለፈበት ሰነድ ዋና ችግር አብዛኛዎቹ ቡድኖች እንደ ዋና የልማት ዑደት አካል አድርገው አለመውሰዳቸው ነው ፣ ለኋላ ትተውታል ወይም በ Confluence ውስጥ ባላቸው የቅድመ-ልማት ስፔሻሊቶች ጥቂት ነገር ይዘው ይሰራሉ። ትርጉም ያለው ሰነድ ለመጻፍ፣ በመጀመሪያ ለሶፍትዌር ክፍል ምን ዓይነት ሰነድ እንዳለ እንወያይ: ገንቢዎች በእርግጥ ሊጠቀሙበት የሚችሉትን ኮድ የማስመዝገብ መንገዶች ሰነድ ከኮዱ አጠገብ መኖር አለበት ብለው ከተቀበሉ፣ የሚቀጥለው ጥያቄ   እንደሚገነባ ነው። እንዴት በመሠረቱ፣ ጥሩ ሰነድ ነጠላ ቅርሶች እንዳልሆነ ተገንዝቤያለሁ - እሱ የንብርቦች ትንሽ ሥነ-ምህዳር ነው ፣ እያንዳንዱም የተለያዩ ዓላማዎችን እና ተመልካቾችን ያገለግላል። በጠቀስኩት ፕሮጀክት (በ Java + Spring Boot የተጻፈ) አራት ዋና የሰነድ ዓይነቶችን ለይተናል: 1. የደንበኛ ስፔሻሊቶች እነዚህ በተለምዶ የትምህርት ባለሙያ የሚያጠናቅቃቸው የተለመዱ ሰነዶች ናቸው። በ ideal ሁኔታ፣ በ ሁለንተናዊ ቋንቋ የበለፀጉ እና የንግድ ጉዳዮችን ከኮድ-ነጻ የሆኑ መግለጫዎችን ይሰጣሉ - በሌላ አነጋገር፣ አንድ መሐንዲስ የሚያስፈልገው የችግሩን ሙሉ ግንዛቤ ለማግኘት ነው። እንደ አለመታደል ሆኖ፣ በእውነታው፣ እነዚህ ሰነዶች ብዙውን ጊዜ በ Confluence ውስጥ የሆነ ቦታ ይቀመጣሉ፣ በፕሮጀክቱ መጀመሪያ ላይ ለቡድኑ ይጋራሉ፣ ከዚያም ከሞላ ጎደል በጭራሽ አይዘመኑም። አትሳሳቱኝ: እነዚህ ሰነዶች   ናቸው። አስፈላጊ ከአስተዳደግ ባለሙያዎች እውቀት ማውጣት ለየትኛውም የኢንጅነሪንግ ቡድን ከፍተኛ ቅድሚያ ሊሰጠው ይገባል። ነገር ግን ስፔሻሊቶች ይለወጣሉ፣ ቀነ-ገደቦች ሁሉንም ሰው ይጨቁናል፣ እና እነዚያ የመጀመሪያ ሰነዶች በዝግታ ግን በእርግጠኝነት ጊዜው ያለፈባቸው መሠረቶች ይሆናሉ። የሚለዋወጡት መስፈርቶች፣ የገደል ጉዳዮች፣ እና የፕሮጀክት ለውጦች እውቀት በኮዱ ውስጥ - ወይም የከፋ! - በ ከፍተኛ መሐንዲስ ራሶች ውስጥ ይኖራል። ይህንን ለመፍታት፣ በዘፈቀደ የ Word ፋይሎች ወይም የ Confluence ገጾች ላይ ስፔሻሊቶችን መጻፍ አቆምን እና በተቻለ መጠን ከፊት መስመር አጠገብ አስቀመጥናቸው:  የኮድ ማጠራቀሚያ። በማጠራቀሚያው ውስጥ የ Markdown (.md) ፋይሎችን እንደማከማቸት ጀመርን ፣ ብዙውን ጊዜ በ docs/ አቃፊ ውስጥ። በትላልቅ ማይክሮሰርቪስ አካባቢዎች፣ እነዚህ ሰነዶች እንደ   በተገናኘ የራሳቸው ማጠራቀሚያ መኖሩን ሊያረጋግጡ ይችላሉ። ንዑስ ሞጁሎች ብዙ ጊዜ ችላ ይባላሉ፣ ነገር ግን የብዙ-ማጠራቀሚያ ሥነ-ምህዳሮችን ማደራጀት ኃይለኛ መንገድ ናቸው። Git submodule ስለ ንዑስ ሞጁሎች ለተጨማሪ ንባብ፣ ይህን ብሎግ ጽሑፍ በጣም እመክራለሁ -  . link 2. README – ለሰው ልጆች የፊት በር የደንበኛ ስፔሻሊቶች ኢንሳይክሎፔዲያ ከሆኑ፣ README የፊት በር ነው። ሆኖም ግን፣ በሶፍትዌር ፕሮጀክቶች ውስጥ በጣም ችላ ከሚባሉት የሰነድ ክፍሎች አንዱ ነው። በአስቂኝ ሁኔታ፣ ከሞላ ጎደል እያንዳንዱ የ ስሪት-ቁጥጥር መድረክ - GitHub, GitLab, Bitbucket - README ን በዋናው የፕሮጀክት ገጽ ላይ በራስ-ሰር ያሳያል። ገንቢ በማጠራቀሚያው ውስጥ ሲደርስ የሚያየው የመጀመሪያው ነገር ነው። ይህ ቢሆንም፣ README ዎች ብዙውን ጊዜ በሚያስደንቅ ሁኔታ ባዶ፣ በሚያሳዝን ሁኔታ ጊዜው ያለፈባቸው፣ ወይም “TODO: በኋላ ሰነድ ጻፍ” በሚለው አስፈሪ ነገር ተሞልተዋል፣ ይህም በእርግጥ አይከሰትም። ጥሩ README አማራጭ አይደለም። በእርግጥ ሊነበብ የሚችል ብቸኛው ሰነድ ነው ምክንያቱም   ስለሚያስፈልገው። እና በማጠራቀሚያው ስር ስለሚገኝ፣ ገንቢዎች ከኮዱ ጋር በሚሰሩበት ጊዜ እሱን ለማዘመን የበለጠ ዕድል አላቸው። የትንሹ ተቃውሞ ጎዳና የሚኖር ሰነድ ነው። ዜሮ ጠቅታዎች በደንብ የተጻፈ README አንድ ገንቢ ከፕሮጀክቱ ጋር በሚገናኝበት በመጀመሪያዎቹ ደቂቃዎች ውስጥ ሊኖረው የሚገባውን በጣም አስፈላጊ ጥያቄዎች መመለስ አለበት: 
 
 
 
 
 
 
  አጭር ዓላማ እና የዐውደ-ጽሑፍ መግለጫ - የግብይት ቆሻሻ የለም። ይህ አገልግሎት/ፕሮጀክት/ክፍል ምን ያደርጋል? -  የማስፈጸሚያ መመሪያዎች፣ የአካባቢ ተለዋዋጮች፣ የጥገኝነት መዋቀር፣ እና ማንኛውም የፕሮጀክት-ነክ ትዕዛዞች። በአገር ውስጥ እንዴት ነው የማስኬደው? -  የዩኒት ምርመራዎች፣ የኢንተግሬሽን ምርመራዎች፣ የሙከራ ውሂብ መዋቅር፣ እና ማንኛውም ከፈተና ጋር የተያያዘ መሳሪያ። እንዴት ነው የምፈትሸው? -  የአቃፊ አቀማመጥ አጭር ማብራሪያ፣ ቁልፍ ሞጁሎች፣ እና የኮዱን አስፈላጊ ክፍሎች የት እንደሚገኙ። ፕሮጀክቱ እንዴት ነው የተገነባው? -  የማሰማራት ስክሪፕቶች፣ የ CI/CD ማስታወሻዎች፣ የሚያስፈልጉ ፈቃዶች፣ ወይም የመድረክ ልዩነቶች። እንዴት ነው የምጭነው?  ወደ ተፈጠሩ ሰነዶች፣ የህንፃ ማስታወሻዎች፣ የ API ማጣቀሻዎች፣ እና የተማከለ የንድፍ ሰነዶች አገናኞች። የት ነው የበለጠ ማንበብ የምችለው? - README የፕሮጀክቱ መግቢያ በር ነው። የሚጠበቁትን ያዘጋጃል፣ የ onboarding ጊዜን ይቀንሳል፣ እና እያንዳንዱ መሐንዲስ—አዲስ ወይም ልምድ ያለው—ግልጽ የሆነ የ orientation ነጥብ ይሰጣል። በትክክል ከተጠበቀ፣ በጠቅላላው ማጠራቀሚያ ውስጥ በጣም ጠቃሚው ነጠላ ሰነድ ይሆናል። 3. JavaDocs – Compilers የሚያስቸግርዎት ሰነዶች JavaDocs - ብዙውን ጊዜ የማይታዩ፣ ብዙ ጊዜ የሚረሱ፣ ነገር ግን አንድ ነገር ሲበላሽ absoultely አስፈላጊ ናቸው። በመሠረቱ፣ የ Java ፕሮጀክቶችን ሰነድ ማድረግ ብዙውን ጊዜ በሁለት ጽንፎች ይወድቃል፡ ወይ  ፣ ወይም   ምክንያቱም “ኮዱ ራሱን የሚያስመዘግብ ነው”። እውነቱ፣ እንደ ሁልጊዜው፣ በመካከላቸው ነው። እያንዳንዱን ትንሽ መስመር ከመጠን በላይ አስተያየት መስጠት ምንም አስተያየት አለመስጠት ለፕሮጀክታችን፣   ለማስመዝገብ ሆን ብለን ወሰንን። ያ ማለት: በእውነት የሚያስፈልገውን ብቻ 
 
 
 
 
 የንግድ ስፔሻሊቶችን በትክክል የሚዛመዱ የ   መጠቀም ሁለንተናዊ ቋንቋ የኮዱን ቀድሞ የሚያሳየውን   ሳይሆን፣ አሳማኝ ላልሆኑ ውሳኔዎች   ማብራራት ምን ለምን ዋና የጎራ ክፍሎች፣ በይነገጾች፣ እና የተወሳሰቡ የስራ ፍሰቶችን መመዝገብ የዘዴውን ስም በ verbose መልክ የሚደግሙ የአስተያየት ግድግዳዎችን ማስወገድ JavaDocs፣ በትክክል ጥቅም ላይ ሲውል፣ ኮዱን ሳያሳንስ ዓላማውን የሚያጸዳ ማይክሮ-ደረጃ ሰነድ ሆኖ ያገለግላል። እና ከ Confluence ገጾች በተለየ፣ JavaDocs አብሮ የተሰራ ጥቅም አላቸው: 
 
 Compler እነርሱን ሲያስቀይሟቸው ያማርራል። አንድ ግቤት ከሰረዙ ነገር ግን የዘፈቀደ የ JavaDoc መለያ ከረሱ፣ ግንባታው ያስታውሰዎታል። አንድ ዘዴ ከሰረዙ ነገር ግን ያረጁ የአስተያየት ማጣቀሻዎችን ቢተዉ፣ IDE እንደ የገና ዛፍ ያበራል። ይህ ቀላል ግጭት JavaDocs ከሌሎች የሰነድ ዓይነቶች ይልቅ የበለጠ ትክክለኛ እንዲሆኑ የሚያደርጋቸው ነው - ችላ ማለታቸው የሚያበሳጭ ነው። ሁሉንም ነገር ለማድረግ እና “የሰነድ ደሴቶች” ለማስወገድ፣   ን ተጠቀምን። Doxygen Doxygen በሶፍትዌር ልማት ውስጥ በሰፊው ጥቅም ላይ የዋለ የሰነድ ማመንጨት መሣሪያ ነው። ምንም እንኳን በዋናነት በ C++ ማህበረሰብ ውስጥ ጥቅም ላይ የዋለ ቢሆንም፣ እሱን የ JavaDocs ን ወደ ወጥ የሆነ፣ ሊያስስ የሚችል ማጣቀሻ - የ HTML ገጽ ለማሰባሰብ ተጠቀምነው። JavaDoc ከማያቀርባቸው ብዙ ባህሪያት አሉት፣ ለምሳሌ የክፍል ገበታዎች ለተዋረዶች እና የትብብር አውድ፣ ተጨማሪ ማጠቃለያ ገጾች፣ እና ብዙ ተጨማሪ። ይህም በተበታተኑ IDE ፍንጮች ላይ ሳይመሰረት የጠቅላላውን የኮድ መሠረት ንጹህ፣ የተባበረ እይታ ሰጠን። 4. ንጹህ ኮድ – ማቆየት የማያስፈልግዎ ሰነድ በመጨረሻም፣ በጣም ዝቅተኛ ዋጋ ያለው የሰነድ አይነት ደግሞ ገንቢዎች በእውነት እስኪፈልጉት ድረስ በጣም የማይገነዘቡት ነው:  ንጹህ ኮድ። አስተያየቶች ያረጁአሉ። ስፔሻሊቶች ይርቃሉ። README ዎች ችላ ይባላሉ። JavaDocs ሊያረጁ ይችላሉ። ነገር ግን በደንብ የተጻፈ ኮድ—ግልጽ፣ ሆን ተብሎ፣ እና ገላጭ—  ሰነድ። ነው እንደ አጎቴ ቦብ በታዋቂነት እንደተናገረው፣  “ንጹህ ኮድ እንደ ጥሩ የተጻፈ ንባብ ነው።” እና በመሠረቱ፣ ያ ማለት: 
 
 
 
 
 
 
 ዓላማቸውን የሚያሳዩ ስሞች ያላቸው ክፍሎች እና ዘዴዎች አንድ ነገር የሚያደርጉ እና በደንብ የሚያደርጉ ተግባራት በአጠቃላይ በተከታታይ ጥቅም ላይ የዋለ የጎራ ቃላት ለራስ ሲባል ምንም ብልሃት የለም በጎንዮሽ ተጽእኖዎች የተደበቁ ያልተጠበቁ ባህሪያት የሉም ለመረዳት ፒኤችዲ የሚያስፈልጋቸው አላስፈላጊ ጥልቅ የከፍተኛ ደረጃዎች የሉም ንጹህ ኮድ በ  ,  , የሰራተኞች ለውጥ, እና የድርጅት ግራ መጋባት በኩል የሚያልፍ ዋስትና ያለው ብቸኛው ቅርሶች ነው። ከስርዓቱ ባህሪ ጋር ሁልጊዜም የተዋሃደ ነው ምክንያቱም—እሱ  refactors sprints የስርዓቱ ባህሪ ነው። አንድ ቀላል ህግ በጊዜያችን ለእኛ ተነሳ:  አንድን ዘዴ ለማብራራት አንድ አንቀጽ አስተያየት ከፈለጉ፣ እውነተኛ ችግር ዘዴው ነው። ኮዱ ገላጭ ሲሆን፣ ሁሉም ነገር ቀላል ይሆናል → JavaDocs ቀለል ያሉ እና የበለጠ ትኩረት የሚሰጡ ይሆናሉ → onboarding ግልጽ ስለሆነ README ይቀንሳል → የጎራ ሞዴል ከንግድ መዝገበ-ቃላት ጋር ስለሚመሳሰል ስፔሻሊቶች ግልጽ ይሆናሉ። ንጹህ ኮድ የሰነድ ፍላጎትን አያስወግድም; እሱን  ያቆራኝዋል። ሁሉም ሌሎች የሰነድ ዓይነቶች—ስፔሻሊቶች፣ README ዎች፣ JavaDocs—እውነትን ከማስመሰል ይልቅ እውነታውን ከማረጋገጥ ያረጋግጣል። በመጨረሻ፣ ንጹህ ኮድ ምንም ዓይነት ጥገና፣ ምንም የ CI ውህደት፣ እና ምንም መሣሪያ የማይጠይቅ ሰነድ ነው። ስርዓቱ በእውነቱ ምን እንደሚያደርግ በጣም ሐቀኛ፣ አስተማማኝ ማብራሪያ ነው። ሁሉንም አንድ ላይ ማምጣት — የሕያው ሰነድ የቧንቧ መስመር ሰነድ እንዴት እንደምንጽፍ ካሻሸን በኋላ፣ የመጨረሻው እርምጃ የተፈጠረ ብቻ ሳይሆን—በተከታታይ እንዲሰጥ እና ሁልጊዜም ተደራሽ እንዲሆን ማድረግ ነበር። ለእሱ፣ ከስፔሻሊቶች፣ README ፋይሎች፣ እና JavaDocs ወደ አንድ፣ የተባበረ   የለወጥነውን የሰነድ የቧንቧ መስመር ገንብተናል። ሕያው ሰነድ መግቢያ በር ሰነዶቻችን ከኮዳችን ጋር በተቻለ መጠን ቅርብ እንዲሆኑ ስለምንፈልግ፣   ን ለመጠቀም ወሰንን፣ ይህም ከኮድ-መሠረቱ ጋር በቀጥታ የተገናኘ የችግር-ነጻ፣ ስሪት-የተጠበቀ ማስተናገጃ መፍትሄ ሰጠን። Github Pages ለ GitHub የተለየ አይደለም (GitLab, ለምሳሌ, ደግሞ GitLab pages አለው) - ይህ ታዋቂ የ ስሪት-ቁጥጥር ስርዓቶች ሌላው አስደናቂ ባህሪ ነው እኔም ለተጨማሪ ንባብ እመክራለሁ -  . GitHub Pages link ሁሉንም ነገር ወደ አንድ ወጥ የሆነ የገጾች ስብስብ ለማጠናቀር፣   ን ተጠቀምን። Sphinx Sphinx በ Python የተጻፈ ኃይለኛ የሰነድ ማመንጫ ነው። ከ reStructuredText ወይም Markdown የተጻፉ የsource ፋይሎችን ወስዶ ወደ የተለያዩ የ output ቅርጸቶች ይለውጣል፣ HTML, PDF, እና ePub ን ጨምሮ። Sphinx ግንባታውን፣ አሰሳውን፣ እና ገጽታውን ተቆጣጠረ። Doxygen የ JavaDocs ን በ    በመጠቀም   ን አውቶ-ማመንጨት ሰጠው፣ ይህም ከsource ኮዱ በቀጥታ ሙሉ በሙሉ ሊያስስ የሚችል የ API ማጣቀሻ ሰጠን። Meanwhile, the root README served as the immediate entry point for developers exploring the repository, linking seamlessly into the generated documentation site. Breathe plugin Sphinx እያንዳንዱ ወደ main የሚገባው merge ሰነዶችን እንደገና የሚገነባ CI job ን ቀስቅሷል፣ ይህም መግቢያው የቅርብ ጊዜ የኮድ ለውጦችን፣ የ API ዝማኔዎችን፣ እና የንድፍ ውሳኔዎችን የሚያንፀባርቅ መሆኑን አረጋግጧል። ምንም ነገር በተናጠል አልኖረም። ምንም ነገር በእጅ ማመሳሰል አላስፈለገም። እና በወሳኝነት—ምንም ነገር ከአንድ ጠቅታ የራቀ አልነበረም። ይህም ሰነዶቻችንን ከስታቲክ ቅርሶች ወደ ገንቢዎች በእርግጥ የሚጠቀሙበት ቀጣይነት ያለው ስርዓት ለወጠው፣ ምክንያቱም በዕለታዊ የስራ ፍሰታቸው ውስጥ ተዋህደው ከኮዱ ጎን ስለሚኖሩ ነው። መደምደሚያ — ሰነድ የእኛ ኃላፊነት እንጂ የእኛ ሸክም አይደለም በቀኑ መጨረሻ ላይ፣ ሰነድ መጻፍ አማራጭ አይደለም። እንደ ሙያዊ መሐንዲስ የኛ ስራ አካል ነው። የወደፊት ባልደረቦች በእሱ ላይ ይመሰረታሉ። Onboarding በእሱ ላይ ይመሰረታል። ጥገና፣ አስተማማኝነት፣ እና የህንፃ ግልጽነት እንኳን በእሱ ላይ ይመሰረታሉ። ነገር ግን ያንን ኃላፊነት መቀበል ሰነድ የሚያሰቃይ መሆን አለበት ማለት አይደለም። ሰነዶችን ከኮዱ አጠገብ በማቆየት፣ ሊሟላ የሚችለውን ሁሉ በራስ-ሰር በማድረግ፣ እና Markdown, JavaDocs, Doxygen, እና Sphinx ባሉ ዘመናዊ መሣሪያዎች በመጠቀም፣ መደበኛውን የሰነድ ጥረቶችን የሚያጠፋውን ግጭት እናስወግዳለን። በተለምዶ እንደ ጭንቅላት የሚሰማውን ነገር ወደ የዕለት ተዕለት ልማት ተፈጥሯዊ ቅጥያ እንለውጠዋለን። እና ያንን ከንጹህ ኮድ፣ ጥሩ README ዎች፣ እና የጎራ-ሀብታም ስፔሻሊቶች ጋር ስናጣምር፣ ጠቅላላው ሥነ-ምህዳር ራሱን የሚያስተዳድር ይሆናል። ሰነድ ፍጹም መሆን የለበትም—ተደራሽ፣ ትክክለኛ፣ እና ሕያው መሆን ብቻ ይበቃዋል። ገንቢዎች ኮድ እንደጻፉት በቀላሉ ሰነድ እንዲያዘምኑ የሚያበረታቱ ስርዓቶችን ስንገነባ፣ ሁሉም ይጠቀማሉ: ቡድኑ፣ ምርቱ፣ እና ከሁሉም በላይ፣ ከስድስት ወራት በኋላ ፕሮጀክቱን የሚረከበው ድሀው ነፍስ። ጥሩ ሰነድ እኛን ሰነፎች አያደርገንም። እኛ ሰነፎች ታላቅ ሶፍትዌር ከመገንባት ጋር ተኳሃኝ ያደርገናል።

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

ይህ ኦዲዮ የተዘጋጀው በታሪኩ የመጀመሪያ ቋንቋ ነው!

የእርስዎ ሰነድ ለመክፈት ሁለት ጠቅታዎች ከወሰደ እንኳን ደስ ያለዎት - እሱ ቀድሞውኑ ጊዜው ያለፈበት ነው።

About Author

አስተያየቶች

ተንጠልጣይ መለያዎች

ይህ ጽሑፍ ቀርቧል

Related Stories

AMA with Rana Gujral, CEO of Behavioral Signals and Noonies Nominee, on September 30th, 9 am PST

Democratizing Tech Skills with Jeremy Morgan of Pluralsight, LIVE AMA on August 17th, 12 pm EST

SOME ANOMALIES

Startups Legal Advice discussion with Josh Ephraim, AMA on September 3rd, 9 am PST

AMA with Rana Gujral, CEO of Behavioral Signals and Noonies Nominee, on September 30th, 9 am PST

Democratizing Tech Skills with Jeremy Morgan of Pluralsight, LIVE AMA on August 17th, 12 pm EST

SOME ANOMALIES

Startups Legal Advice discussion with Josh Ephraim, AMA on September 3rd, 9 am PST

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps