جادی

من گاهی به شوخی می‌گم یک راه حل برون رفت استارتاپ‌های نوپای خونگی از وضعیت مشتری نداشتن، اینه که با امضای یک قرارداد به یک جور اتحادیه یا سندیکای «استارتاپ‌های نوپا»‌ بپیوندن که توش اعضا متعهد می‌شن دائما از سرویس‌های همدیگه استفاده کنن؛ البته این عملی نمی‌شه چون تقریبا همه رهبران سندیکایی ایران یا کشته شدن یا در زندان هستن یا برای فرار از این دو عاقبت، از ایران خارج شدن.

ولی این ایده واقعا هم ایده بدی نیست. اقتصاد دانی به نام کینز هم نظرات مشابهی داشته و ایده من از اون می‌یاد. کینز می‌گفت برای برون رفت از شرایط بحران رکود دوره ای که گریبان سرمایه‌داری رو می‌گیره دولت باید دخالت کنه و سعی کنه پول رو در جامعه بچرخونه. یکی از ایده‌های عجیب کینز اینه:

دولت به گروهی پول بده که در کوه‌ها چاله بکنن، بعد به گروهی دیگه پول بده که اون چاله‌ها رو پر کنن.

این باعث چی می‌شه؟ دو گروه کار کردن و حقوق گرفتن‌ و این پول رو در جایی خرج می‌کنن. شاید با پولش یک ماشین ظرفشویی بخرن که باعث می‌شه کارخونه ساخت ماشین ظرفشویی کارگر بیشتری استخدام کنه و بهش حقوق بده و اون کارگر با پولش بخواد یه خودرو بخره و کارخونه خودروسازی مجبور بشه یه ماشین بیشتر بسازه و … پول در جامعه شروع به چرخیدن کنه.

این مساله به شکل نیمه جدی در استارتاپ‌های تازه پا می‌تونه کار کنه، اگر واقعا کسی از من بخره و من هم قول بدم از یکی دیگه بخرم خب به هرحال مثل قبل پول خاصی نیست ولی من دارم کار می کنم و وقتی من مشغول کارم احتمال اینکه یکی دیگه هم از من خرید کنه بیشتره. می‌گن بیزنس ها در ایران اگر بتونن دو سال اول رو زنده بمونن، احتمال ورشکستگی‌شون خیلی کم می‌شه.

حالا همه اینها رو گفتم که بگم من خیلی ایمیل‌هایی به این فرم می‌گیرم:

سلام جادی. ما یک هاستینگ داریم که دیروز فلان مشکل رو پیدا کردیم. می شه بگی چطوری باید حلش کنیم؟

یا مثلا:

ما یک شرکت هستیم که دنبال یک شیوه صحیح ارتباط داخلی و مدیریت اسناد می‌گردیم، به نظرت چه سرویسی برامون خوبه؟

و موارد بسیار مشابه. من معمولا به شکل خلاصه جواب می دم ولی هربار فکر می کنم باید در این مورد حرف بزنیم که اگر یک نفر از کاری پول در می یاره و توش مشکلی داره که دوست داره حل بشه،‌ معقوله که برای حلش معتقد باشه لازمه حداقل پیشنهاد بده که پول خرج کنه. سخت گفتم؟ خشن‌ترش اینه که اگر کسی از کسی سرویس می‌خواد تا پول در بیاره، لازمه پول سرویسش رو هم بده. البته معلومه که من برای چنین ایمیل ها و جواب هایی قرار نیست پول بگیرم و سوال کننده ها هم در حال پولدار شدن از جواب من یا حتی کار فعلی شون در مرحله فعلی نیستن، ولی در کل هر بار فکر میکنم یکی باید این حرفها رو بزنه. اصل حرف من اینه:

ما همه در یک محیط کوچیک کار می کنیم که بهش می گیم جامعه نرم افزار ایران. در این جامعه حقوق و درآمد همه ما به همدیگه وابسته است و اگر اولویت من در به دست آوردن یک چیزی (مثلا صبحانه، ناهار، نون، پیشنهاد، چاپ، سی دی ان، ویدئو، اخبار، ….) سایت همکارهام باشه و در این مورد خست به خرج ندم، احتمال موفقیت نهایی خودم هم بیشتره. اگر ما صد نمونه داشته باشیم که توش یه سرمایه گذار با سرمایه گذاری در یک استارتاپ، پولدار شده باشه احتمال اینکه یکی روی ایده منم یکی سرمایه گذاری کنه خیلی بالاتره.

ما تقریبا مشابه شرایط کینز هستیم و دخالت دولتی‌اش هستیم؛ لازمه حتی اگر مجبور نیستیم از هم حمایت کنیم، به هم لینک بدیم، همدیگه رو معرفی کنیم و از همه بالاتر پول سرویس های همدیگه رو بدیم تا کارهامون بچرخه و پا بگیره و زیرپاهامون محکم بشه. معلومه که همین که رقیب بهتری پیدا شد سوییچ می کنیم یا هر چیزی ولی «خست» نباید به خرج بدیم و از اون بالاتر حرص خوردن از موفقیت دیگران رو باید کنار بذاریم. همراهی همه ما می تونه کل محیط رو به نفع همه ما بکنه. چه در بحث حقوق ماهانه باشه چه در بحث پا گرفتن استارتاپ‌هامون.

---

• من اقتصاد دان نیستم. اگر اشتباه گفتم خوشحال می‌شم بگین که اصلاح کنم یا در کامنت‌ها تکمیل کنید

مثل همیشه اوبونتو منتشر شده و رسیده‌ایم به اوبونتوی ۱۶.۱۰. انواع جشن‌ها هم در جریانه و من فعلا توی این دو تا برنامه هستم و به همراه دوستان خوب، صحبت می کنیم در مورد اوبونتو، اخبار، تاریخچه و هر چیز جالبی دیگه.

• همایش نرم‌ازارهای آزاد استان البرز،‌ اولین پنجشنبه آذر ماه. اگر کرج هستین، می‌تونین از اینجا ثبت نام کنید. آپدیت: به خاطر ترکیب ناهمگونی سخنران ها، من مشکوکم که برم یا نه. اسمم هست ولی خب نمی شه از نرم افزار آزاد و آزادی بگیم در کنار پلیس فتا و بقیه دوستانشون که بخشی از کارشون گرفتن آزادی‌های پایه ای (مثل آزادی بیان) از دیگرانه (: قرار شد مشخص کنن که وضع چیه. آپدیت تر:‌ ترکیب سخنران ها رو اصلاح کردن. ما می ریم (:
• همایش نرم‌افزارهای آزاد و جشن انتشار اوبونتو ۱۶.۱۰ دانشگاه باهنر کرمان در تاریخ ۲۰ آبان. شرکت در همایش رایگان است و کارگاه‌ها بسیار بسیار ارزان؛ ثبت نام کنین.

امیدوارم ببینمتون و مثل همیشه خوش بگذره بهمون (:

آپدیت: کامنت ها رو هم بخونین. بعضی ها می گن این مساله به خاطر رسانه ها بزرگ نمایی شده و از اونی که هست خطرناکتر نشون داده شده

سه روز هم از مشکل حاد امنیتی لینوکس با عنوان گاو کثیف که با آپدیت حل می شد نگذشته که مشکلی پیچیده‌تر در ویندوز نشون داده شده؛ اینبار ظاهرا غیرقابل حل با آپدیت‌های فعلی: اتم بمبینگ یا همون AtomBombing.

محققین امنیتی تکنیکی رو نشون دادن که حمله کننده می‌تونه کد مخربش رو در ویندوزهای مختلف (حتی ده آپدیت آخر) تزریق کنه بدون اینکه ابزارهای معمول آنتی ویروس بتونن چیزی تشخیص بدن. مشکل اصلی اینجاست که این مساله مربوط به یک باگ خاص نیست که بشه حلش کرد بلکه ظاهرا معماری اشتباه باعث این مساله شده.

حمله از طریق جدول‌های اتم (Atom Tables) اتفاق می‌افته؛ قابلیتی که ویندوز به برنامه‌ها می‌ده تا اطلاعات مربوط به رشته‌های کاراکتری، آبجکت‌ها و بقیه انواع داده‌ رو ذخیره کنن و بهشون دسترسی داشته باشن. این جدول‌ها مشترک هستن و همه برنامه‌ها بهشون دسترسی پیدا می‌کنن (برای اطلاعات بیشتر وبلاگ مایکروسافت رو بخونین).

محققین شرکت امنیتی ان سیلو حالا روشی نشون دادن که به خاطر اشتباه طراحی این جداول، اجازه می‌ده کد مخرب بتونه این جدول‌ها رو تغییر بده و باعث بشه برنامه‌های معتبر بتونن کدهای مخرب رو به جای اون اجرا کنن. این مساله باعث می شه عملا آنتی ویروس ها و غیره با روش های فعلی شون نتونن جلوی اجرای این کدها رو بگیرن.

چنین حمله‌ای می تونه در شکل های دیگه باعث حملات مرد میانی، اسکرین شات گرفتن از صفحه دسکتاپ یوزر و دسترسی به پسوردهای ذخیره شده توی براوزر بشه.

در حال حاضر همه نسخه‌های ویندوز نسبت به این مساله آسیب پذیر هستن و به گفته لیبرمن

متاسفانه این مساله قابل پچ نیست چون مشکل در یک باگ نرم افزار یا کد اشتباه نیست – این مساله به خاطر شیوه طراحی سیستم عامل پیش اومده.

که البته امیدوارم مایکروسافت سریعا راه حلی براش پیدا کنه.

آیا نگران باشیم؟

بله ولی در عمل نمی‌تونیم کاری بکنیم. مطمئنا کسی به شما پیشنهاد نمی ده در این لحظه به لینوکس سوییچ کنین ولی خب در نهایت .. چه می دونم. راستش توصیه من به یک آدم معمول در جهان اینه که «نگران نباشین، زندگی همینه». اگر یک آدم مرسوم در دنیا هستین، منتظر بشین ببینین شرکت های بزرگ چه می کنن به زودی.

• منبع اصلی
• اطلاعات فنی تر
• سورس روی گیت هاب

خلاصه مدیریتی:‌ بازم من چند ساعتی از کامپیوترم فاصله گرفتم و جهان به دست نااهلان افتاد! یک مشکل امنیتی توی لینوکس‌ نشون داده شده که می‌تونه باید ارتقای دسترسی افرادی بشه که روی یک سرور اکانت دارن، به اسم مشکل امنیتی می‌گن «گاو کثیف» یا درست‌تر از اون Dirty Cow. راه حل؟ آپدیت کردن لینوکستون به طور صد در صد این مشکل رو حل می‌کنه.

اسم از کجا اومده و این باگ چه می‌کنه

اسم رسمی این مشکل امنیتی هست CVE-2016-5195 ولی از اونجایی که ماجرا مرتبط می‌شه به یک وضعیت رقابتی در شیوه هندل شدن copy on write (یا همون COW) در کرنل لینوکس، بهش گاو کثیف می‌گیم. این شرایط رقابتی باعث می‌شه یک کاربر معمولی بتونه به بخش‌هایی از حافظه که قرار بود غیرقابل نوشتن باشه دسترسی رایت پیدا کنه و در نتیجه بتونه دسترسی خودش رو افزایش بده باگ رو در باگزیلای ردهت ببینین.

آیا لینوکس من هم این مشکل رو داره

بله. تمام لینوکس‌هایی که‌ آپدیت نشده باشن این مشکل رو دارن. هر لینوکسی باید به شکل مطلق و به سرعت آپدیت بشه. در صورتی که کرنل‌های شما قدیمی‌تر از این کرنل‌ها هستن، شما هم این باگ رو دارین:

3.16.36-1+deb8u2 for Debian 8
3.2.82-1 for Debian 7
4.7.8-1 for Debian unstable
4.8.0-26.28 for Ubuntu 16.10
4.4.0-45.66 for Ubuntu 16.04 LTS
3.13.0-100.147 for Ubuntu 14.04 LTS
3.2.0-113.155 for Ubuntu 12.04 LTS

چجوری حلش کنم؟

به سادگی. در هر توزیع مرسوم لینوکس که هستین، یک آپدیت و بعد لود کردن کرنل جدید (ریبوت) میتونه شما رو در مقابل این باگ حفاظت کنه.

کی این رو کشف کرده و آیا لینوکس ناامنه؟

این باگ توسط فیل اوستر کشف و گزارش شده. لینوکس در این لحظه از این نظر ناامن نیست چون یک آپدیت مشکل رو حل می‌کنه. لینوکس قبل از این آپدیت از این نظر ناامن بوده. هر سیستم عاملی در هر لحظه به دلایل مختلف ناامن است و فقط نکته اینه که این ناامنی‌ها در چه لحظه ای گزارش می‌شن و در چه لحظه ای حل می‌شن. خوبی لینوکس اینه که این چنین مشکلاتی رو تقریبا در زمان گزارش حل می‌کنن و با یک آپدیت همه در مقابلش مصون می‌شن ولی تا وقتی از نرم افزار استفاده می‌کنیم، شاهد چنین چیزهایی در تمام سیستم عامل‌ها خواهیم بود.

اطلاعات بیشتر رو از کجا به دست بیارم

اینجا

و آپدیت یادتون نره!

اشاره: متن پیش رو برگردان پستی است که Tom Preston-Werner در وبلاگش با عنوان Open Source (Almost) Everything منتشر کرده و به جهت اهمیت مطلبی که در آن بیان کرده، نظیر ترس کسب‌وکارها از منبع باز کردن محصولات‌شان، مرور آن ضروری می‌نماید. او در این نوشته توضیح می‌دهد که چرا و چگونه بر ترس متن‌باز کردن نرم‌افزارهای‌شان غلبه کرده و به سمت ایجاد کسب‌وکاری بر مبنای نرم‌افزارهای متن‌باز حرکت کردند. این متن را امیرپوریا مهری ترجمه کرده و من در جادی.نت بازنشرش می‌کنم. شاید من در مورد جزییات یا حتی استفاده از عباراتی مثل «بازمتن» در مقابل «آزاد» نظرات متفاوتی داشته باشم ولی در کل خوندن این مطلب بسیار راهگشا است.

---

در اواخر سال ۲۰۰۷، من و کریس (Chris Wanstrath) شروع به کار بر روی گیت‌هاب کردیم، کار به دو قسمت تقسیم شد: کریس بر روی توسعه‌ی برنامه‌های Rails متمرکز بود و من روی Grit کار می‌کردم که نخستین Git‌ نوشته شده بر پایه‌ی Ruby بود. پس از شش ماه توسعه، Grit به اندازه‌ی کافی آماده بود تا قدرت‌بخش گیت‌هاب شود و سایت را به انتشار عمومی دربیاوریم. در همین حال ما با سوال جالبی مواجه شدیم:

بهتر است Grit را متن‌باز کنیم و یا این که کدهای آن را به صورت اختصاصی نگه داریم؟

اختصاصی نگه داشتن کدهای Grit در رقابت با سایت‌های میزبان Git‌که برپایه‌های Ruby نوشته شده‌اند، پرش بزرگی بود و می‌توانست مزیت رقابتی ما باشد. اما متن‌باز کردن آن به این معنا بود که هزاران نفر در سراسر جهان می‌توانند از آن برای ساختن ابزارهای Git مورد نظرشان استفاده کنند. در واقع با این کار یک اکوسیستم چالاک پیرامون Git تشکیل می‌شد.

پس از کمی بحث و چانه‌زنی تصمیم به متن‌باز کردن Grit گرفتیم. من جزییات مکالمات‌مان را به یاد ندارم اما آن تصمیم قریب به چهار سال پیش، ما را به سمتی هدایت کرد که فکر می‌کنم حالا یکی از مهم‌ترین ارزش‌های اصلی گروه ما است: متن‌باز کردن (تقریبا) همه چیز.

چرا متن‌باز کردن (تقریبا) همه‌چیز این‌قدر هیجان‌انگیز است؟

اگر آن را به شیوه‌ی درست انجام دهید، کدهای متن‌باز تبلیغ بزرگی برای خود و شرکت‌تان خواهد بود. در گیت‌هاب دوست داریم درباره‌ی کتابخانه‌ها و سیستم‌هایی که کدهای آن را زده‌ایم و هنوز متن‌بسته‌اند، ولی تصمیم داریم آنها را متن‌باز کرده، به‌طور عمومی بحث کنیم. این شگرد چندین مزیت در خود دارد. از جمله کمک می‌کند تا تععین کنیم چه چیزی را باید متن‌باز کرده و اهمیت آن برای ما چقدر است تا در اولویت کاری انتشار قرار دهیم. ما اخیرا Hubot، چت‌بات‌مان را منبع باز کردیم؛ تا شمار زیادی را خوشحال کنیم. در عرض دو روز ۵۰۰ نفر در گیت‌هاب به بررسی آن پرداختند و ۴۰۹ رای مثبت در وب‌سایت Hacker News نصیب این برنامه شد. این کار نزد مردم به حسن‌نیت گیت‌هاب ترجمه می‌شود و موجب افزایش شمار طرافداران دو‌آتشته برای ما شد.

اگر کدهای شما به اندازه‌ی کافی محبوب باشند تا موجب جذب همکاری توسعه‌دهندگانی خارج از شرکت‌تان شود؛ شما نیروی مضاعفی به وجود آورده‌اید که کمک‌تان می‌کند کارهای بیشتری را سریع‌تر و ارزان‌تر از پیش به سرانجام برسانید. کاربران بیشتر به معنای آن است که کارهایتان توسط مشتریان بیشتری در حال استفاده و بررسی است که این خود به معنای قوی‌تر شدن کدهای‌تان است. Resque کتابخانه‌ی اختصاصی ما، توسط ۱۱۵ فرد مختلف از خارج از شرکت بهبود یافت و صدها پلاگین برای آن توسعه داده شد که به گسترش قابلیت های این کتابخانه کمک کرد. هر رفع اشکال و ویژگی جدیدی که اضافه می‌شوند، موجب صرفه‌جویی در وقت شما شده و از سرخوردگی احتمالی مشتری‌تان، به خاطر کمبود ویژگی‌ها و یا باگ‌های فراوان، جلوگیری می‌کند.

افراد باهوش دوست دارند تا با افراد باهوش درگیر باشند. توسعه‌دهندگان باهوش نیز دوست دارند تا با کدهای هوشمندانه درگیر شوند. وقتی شما کدهای سودمندی را منبع باز می‌کنید، استعدادها را جذب خواهید کرد. هر بار که توسعه‌دهنده‌ای با استعداد درگیر کدهای متن‌باز شده‌ی شما می‌شود، برنده شما اید. من در کنفرانس‌های فناوری، گفتگوهای ارزشمندی درباره‌ی کدهای متن‌باز خودم داشته‌ام. برخی از این گفتگوها موجب جرقه خوردن ایده‌های جدیدی شد که به طور مستقیم راه‌حل‌های بهتری را در مواجهه با مشکلات پروژه‌هایم پیش پا گذاشتند. در صنعتی با چنین طیف گسترده‌ای از خلاقیت و بهره‌وری در میان توسعه‌دهندگان، در مرکز توجه قرار گرفتن کدهای‌تان می‌تواند تفاوت بزرگی ایجاد کند.

اگر به دنبال استخدام هستید، بهترین مصاحبه‌ی فنی ممکن، این است که اصلا صورت نگیرد؛ چرا که داوطلب پیش از این در یکی از پرو‌ژه‌های منبع باز شما دست برده است. هنگامی که برتری فنی در چنین مسیری تثبیت شود؛ تمام آنچه باقی می‌ماند، بررسی این است که آیا فرد به فرهنگ شرکت‌تان می‌خورد یا نه و سپس مرحله‌ی متقاعد کردن او تا برای‌تان کار کند. اگر آنها درباره‌ی کدهای متن‌باز-ای که نوشته‌اند مشتاق باشند؛ و شما از شمار شرکت‌هایی باشید که به کدهای تمیز اهمیت می‌دهد (که باید باشید) این فرایند (استخدام) باید ساده باشد. ما Vicent Martí را پس از این‌که کارهای درخشان او را روی کتابخانه ی libgit2 دیدیم، استخدام کردیم. پروژه‌ای که در گیت‌هاب رهبری‌اش می‌کنیم تا قابلیت‌های اصلی Git‌ را بر روی کتابخانه‌ی مستقل C ببریم. مصاحبه ی فنی نیاز نبود. Vicent مهارت‌های اش را از طریق کدهای متن‌باز-اش به اثبات رسانیده بود.

هنگامی که شما این چنین استعدادهایی را از طریق مشارکت‌های‌شان استخدام می‌کنید؛ اختصاص دادن وقت آنها به کار روی کدهای متن‌باز، راه عالی و موثری برای حفظ آن استعدادها است. بیایید با آن روبرو شویم، توسعه‌دهندگان بزرگ در این صورت می‌توانند به درستی آن کاری را برای انجام دادن انتخاب کنند، که در آن عالی هستند. این همان توسعه‌دهندگانی هستند که ارزش کدنویسی به شیوه‌ی متن‌باز را می‌دانند و می‌خواهند برای خودشان به این طریق مجموعه‌ای از پروژه‌ها ایجاد کنند تا بتوانند به دوستان‌شان نمایش‌اش دهند و در موقع لزوم برای ارایه به عنوان نمونه کار به کارفرمایان آتی‌شان ارایه کنند. درست است، یک پارادوکس! به این ترتیب برای خوشحال نگه‌داشتن یک توسعه‌دهنده‌ی حرفه‌ای، مجبورید کمک‌شان کنید تا برای کارفرمایان آینده‌شان جذاب‌تر به نظر برسند. اما مشکلی نیست. چرا که آنها دقیقا همان نوع توسعه‌دهنده‌گانی هستند که شما می‌خواهید برای‌تان کار کنند. بنابراین خونسرد باشید و اجازه دهید روی پروژه‌های متن‌باز کار کنند و در غیر این صورت آنها به جای دیگری خواهند رفت تا بتوانند آن‌گونه کار کنند که دوست دارند.

وقتی من پروژه‌ی جدیدی را آغاز می‌کنم، فرض‌م بر این است که در نهایت این پروژه متن‌باز خواهد شد، حتی اگر بعید باشد. این طرز تفکر منجر به ماژولار کردن بی‌دردسر پروژه‌ها می‌شود. اگر به این فکر کنید که چطور افرادی خارج از شرکت شما می‌توانند از کدهای شما استفاده کنند؛ در این صورت بعید به نظر می‌رسد که به سراغ پیکربندی‌های اختصاصی بروید. این کار به نوبه‌ی خود موجب می‌شود تا کدهای تمیزتر و قابل نگه‌داری‌تر بنویسید. حتی کدهای داخلی شرکت باید طوری نوشته شوند که گویی قرارست متن‌باز شده و در اختیار همه قرار گیرند.

آیا تابه‌حال در یکی از شرکت‌هایی که برایش کار می‌کردید، کتابخانه یا ابزاری شگفت‌انگیز نوشته‌اید که بعد از ترک آن شرکت و به استخدام جای دیگری درآمدن، بخواهید همان کد را بنویسید ولی با نداشتن آن کدها احساس تیره بختی کنید؟ من چنین تجربه‌ای داشته‌ام و افتضاح است.

با انتشار عمومی کدها می‌توانیم به شدت از چندباره‌کاری جلوگیری کنیم. چندباره‌کاری نکردن به معنی کار کردن فقط برای چیزهایی است که اهمیت دارند.

در نهایت، [متن‌باز کردن کدها] این بهترین کاری‌ست که انجام می‌دهیم. تقریبا غیرممکن است که این روزها هرگونه کاری انجام دهیم و مستقیم و یا غیرمستقیم به اجرای مقادیر زیادی از کدهای متن‌باز اقدام نکنیم. اگر شما از اینترنت استفاده می کنید، در حال استفاده از کدهای متن‌باز هستید. این کدها بیانگر میلیون‌ها انسان-ساعت زمان صرف شده توسط نیروهای انسانی برای نوشتن آنهاست که در نهایت به جامعه‌ی بشری بازگردانده شده تا هرکسی بتواند از آن بهره‌مند شود. همه‌ی ما از مزایای نرم‌افزارهای متن‌باز بهره می‌بریم و من معتقدم که همه‌ی ما از نظر از نظر اخلاقی موظفیم که به این جامعه (جامعه‌ی نرم‌افزارهای متن‌باز) کمک کنیم. اگر جهان نرم‌افزار را اقیانوسی در نظر بگیریم، آن گاه متن‌باز به مثابه‌ی جریان‌های اقیانوسی‌ست که کشتی‌ها را به پیش می‌برد.

خب، پس چه موقع نباید نرم‌افزارم را متن‌باز کنم؟

ساده است، هر چیزی را که نشان‌دهنده‌ی ارزش اصلی کسب‌وکار شماست، نباید متن‌باز کنید. این‌جا تعدادی نمونه می‌آورم از چیزهایی که متن‌باز نکردیم و دلیل‌اش را هم می‌گویم.

• هسته‌ی برنامه‌ی اصلی مبتنی بر Rails گیت‌هاب (وقتی متن‌بسته است راحت می‌توانید آن‌را بفروشید)
• برنامه‌ی Jobs Sinatra (ساخته شد تا در گیت‌هاب دات کام ادغام شود)

این هم تعدادی نمونه از چیزهایی است که متن‌باز کردیم به همراه دلیل آن:

• Grit (Git bindings همه منظوره، مفید برای ساختن ابزارها)
• Ernie (BERT-RPC سرور همه‌منظوره)
• Resque (job processing همه‌منظوره)
• Jekyll (صفحه استاتیک‌ساز همه‌منظوره)
• Gollum (ویکی اپ همه‌منظوره)
• Hubot (چت‌بات همه‌منظوره)
• Charlock_Holmes (character encoding detection همه منظوره)
• Albino (syntax highlighting همه‌منظوره)
• Linguist (filetype detection همه‌منظوره)

توجه کنید که هر چیزی را که متن‌بسته نگه داشتیم، ارزش کسب‌وکار (business value) خاص ما بود که می‌تواند با در دست رقبای‌مان قرار گرفتن، کسب‌وکارمان را به خطر بیاندازد. هر چیزی را که متن‌باز کردیم، ابزاری همه‌منظوره است که می‌تواند توسط عموم مردم و شرکت‌ها برای ساختن همه نوع چیزی استفاده شود.

مجوز درست حسابی کدام است؟

من مجوز MIT را ترجیح می‌دهم و تقریبا تمام چیزهایی که در گیت‌هاب متن‌باز کردیم با این مجوز منتشر شدند. من این مجوز را به چندین دلیل دوست دارم:

• کوتاه است. هر کسی می‌تواند متن این مجوز را مطالعه کرده و بفهمد دقیقا چه می‌گوید بدون این‌که نیاز باشد با پرداخت حق مشاوره، وکلا را پول‌دارتر کند.
• به اندازه‌ی کافی از کدنویس حمایت می‌کند تا مطمئن باشم اگر کد به درستی کار نکرد، از من شکایت نمی‌شود.
• هر کسی پیامدهای قانونی مجوز MIT را می‌فهمد. مجوزهای عجیب-و-غریب مثل WTFPL و Beer تظاهر می‌کنند که در میان مجوزهای آزاد بهترین هستند، اما کاملا در این هدف شکست خورده‌اند. این مجوزهای حاشیه‌ای بیش از حد مبهم و غیرقابل اجرا هستند تا برای استفاده در شرکت‌ها قابل قبول باشند. در سوی دیگر، مجوز GPL‌ بیش از اندازه محدود شده و متعصبانه است تا قابل استفاده برای عموم کارها باشد. من می‌خواهم همه بتوانند از کدهایم بهره‌مند شوند، «همه». این چیزی است که از واژه‌ی «باز» و «آزاد» تداعی می‌شود.

خب، حالا می‌پرسید چگونه آغاز کنم؟

ساده است. به جای مخازن بسته، شروع به استفاده از مخازن متن‌باز عمومی گیت‌هاب کنید و درباره‌ی نرم‌افزارهایی که نوشته‌اید، از طریق وبلاگ، توییتر، سایت Hacker News و سایر رسانه‌های تاثیرگذار محلی‌تان تبلیغ کنید. سپس می‌توانید عقب نشسته، استراحت کرده و از سهیم بودن در جنبشی بزرگ لذت ببرید.

شرکت المارین یک شرکت بین المللی است که در حوزه ارائه خدمات مخابراتی، ناوبری، مکانیکی و موارد مشابه در صنعت دریایی فعالیت می‌کند. ما در حال توسعه تیم نرم‌افزاری‌مان هستیم و به دنبال همکارهایی شاد و باهوش با توانایی‌های زیر می‌گردیم.

برنامه نویس Full-stack وب:

• بک‌اند: مسلط به یکی از زبان های php ،Node.js ،Python، Ruby یا هر زبون دیگه ای. در واقع مهمترین مشخصه این آدم اینه که شاد و پر انرژی باشه و اصولی کد بزنه
• فرانت‌اند : مسلط به HTML و CSS با توانایی کار با Backbone.js یا AngularJS یا jquery یا Ember یا هر فریمورک مرسوم و مشابه دیگه‌ای

شرایط کاری در شرکت المارین :

• پروژه هایی که انجام میدیم گستردگی کمی دارن ولی نیازمند کیفیت بالا هستن. به همین دلیل کد زدن فرسایشی و یکنواخت روی یک کد بیس رو نداریم
• محل کار خیابان اسدآبادی ( یوسف آباد) است
• معمولا فشار و استرس کاری نداریم
• حقوق اینجا قابل رقابت با شرکت های دیگه هست و از همون ابتدا بیمه داریم
• ساعت کاری قابل تغییر هست و از این بابت سخت گیری وجود نداره مخصوصا برای دانشجوها

‫لطفا مشخصات، ‬شرایط‪ ‬و‪ ‬مهارت‪ ‌های خودتون‪ ‬رو‪ ‬به‪ jobs@elmarin.com ‬ارسال‪ ‬کنید‪ ‬تا‪ ‬باهاتون‪ ‬تماس‪ ‬بگیریم‪ ‬و‪ ‬برای‪ ‬مصاحبه‪ ‬و‬ ‫آشنایی‪ ‬بیشتر‪ ‬هماهنگ‪ ‬کنیم