واکنش جامعه برنامه نویسان جهان به قتل جورج فلوید

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

چه اتفاقی افتاد ؟

با اینکه احتمالا در روز های اخیر مطالبی را در مورد قتل جورج فلوید خوندید ولی این مطلب بدون توضیح مختصری از مرگ جورج ناقص میمونه.

جورج فلوید ، مرد سیاهپوستی بود که در تاریخ 5 خرداد 99 توسط دِرِک شووین مامور سفید پوست اداره پلیس مینیاپولیس به قتل رسید به این صورت که مامور به مدت 8 دقیقه و 46 ثانیه زانوی خودش رو روی گردن جورج گذاشته بود در حالی که جورج دستبند زده و با صورت روی خیابان بود .این اتفاق بعد از دستگیری فلوید به گمان استفاده از یک اسکناس 20 دلاری جعلی برای خرید سیگار رخ داد.رهگذران زیادی از این حادثه فیلم گرفتند ، فیلم ها نشون میداد که جورج مدام تکرار می کنه : نمی توانم نفس بکشم. بعد از این واقعه و با انتشار این فیلم در شبکه های اجتماعی اعتراضات زیادی در آمریکا نسبت به برخورد پلیس با سیاه پوستان شکل گرفت.

جامعه برنامه نویسان و خصوصا جامعه جاوا اسکریپت یک صدا در این باره موضع گرفتند و از حرکت های ضد نژادپرستی حمایت کردند. حمایت اون ها فقط گفتن جملات متداول و نمادین نیست بلکه به معرفی و پشتیبانی از سازمان ها و تجمعاتی که با تبعیض نژادی مقابله می کنند نظیر (the Equal Justice Initiative) می پردازند . سازمان مذکور یک سازمانی غیر انتفاعی است که با بی عدالتی های نژادی و اقتصادی مقابله می کنه و به طور مثال وکیل قانونی برای زندانیانی که ممکنه به اشتباه محکوم شده اند یا زندانیانی که وضع اقتصادی خوبی برای گرفتن وکیل مناسب ندارند و یا در کل از حق قضاوت عادله برخوردار نیستند فراهم می کنه.


تایپ اسکریپت (TypeScript)

در صفحه رسمی تایپ اسکریپت شعار زندگی سیاهان مهم است (Black Lives Matter) را به وضوح میشه دید و رنگ قالب سایت از آبی به سیاه تغییر کرده.

ری‌اکت (React.js)

جامعه ری اکت نیز این اتفاق را نادیده نگرفت و بنر حمایت از از سازمان the Equal Justice Initiative رو در صفحه اصلی خودش قرار داد . علاوه بر این در کنار واکنش رسمی ری اکت ، برنامه نویسان زیادی از React Core Team حمایت خودشون رو اعلام کردن. به خصوص اینکه صد ها نفر از کارمندان فیس بوک یک اعتراض مجازی به تصیم مارک زاکربرگ مبنی بر عدم واکنش به پست های جنجال برانگیز ترامپ در مورد معترضان برگزار کردند.

https://www.hindustantimes.com/world-news/hundreds-of-facebook-employees-walk-out-over-zuckerberg-s-inaction-on-trump-s-posts/story-36GpTo94FnMp8xGfOxqAvJ.html

نود جی اس (Node js)

سایت اصلی نود جی اس قالب صفحه اصلی خودش را کاملا تغییر داده و در پایین شعار BlackLivesMatter اسامی سیاه پوستانی که به تعبیر خود سایت مورد وحشیگری پلیس آمریکا واقع شدن رو گذاشته و زیرش نوشته :

برتری سفید و وحشیگری پلیس مشکلات جهانی است. هر زندگی سیاه [پوستی] که در اثر قتل پلیس از دست رفت در سطح جهانی دارای اهمیت است. لیست فوق حاوی اسامی سیاهپوستانی است که از سال 2009 به واسطه وحشیگری پلیس در ایالات متحده به قتل رسیده اند. به همین خاطر است که ایالات متحده آمریکا منشأ جنبش Black Lives Matter و در حال حاضر قلب مقاومت است.

در ادامه هم لیستی از صندوق رسمی یادبود جورج فلوید گرفته تا برخی کمپین ها برای افرادی که اون ها هم داستان مشابه جورج دارن رو برای دونیت و کمک قرار داده .

اتفاق زیبا تر و قابل توجه تر یه جورایی بیانیه ای هست که بعدش نوشته و خلاصه اش این هست که می خوان برای فعال تر شدن و پیشرفت جامعه سیاهان کار هایی انجام بدین مثلا پژوه هایی رو که توسط افراد سیاه پوست ایجاد میشه رو به اشتراک بزارن و همچنین خواستن که هر راهی که به نظرتون برای کمک به جامعه سیاهان، مفید میاد رو به این ایمیل (blacklivesmatter@nodejs.org) ارسال کنید.

در ادامه اومده :

مسئولیت برچیدن برتری سفید بر عهده جامعه سیاه [پوستان] نیست ، این مسئولیت ماست

به افراد سیاه که به دنبال دسترسی یا همکاری هستند: ما در اینجا برای شما هستیم

به سیاهپوستانی که به دنبال تقویت یا مشاوره هستند: ما برای شما اینجا هستیم.

به اعضای سیاهپوست جامعه ما که به دنبال راهنمایی یا هر نوع پشتیبانی هستند: ما برای شما اینجا هستیم.

آنگولار (Angular)

وبسایت رسمی آنگولار هم برای نشان دادن همبستگی خود با جنبش های اخیر رنگ قالب خود که معمولا آبی بود به رنگ سیاه درآورد و شعار BlackLivesMatter رو هم در بالای سایت قرار داد.

همچنین توییتر رسمی آنگولار این تغییرات را توییت کرد:

بابِل (Babel)

بابِل پا را فراتر گذاشت و در روز 14 خرداد سایت رسمی اش را تعطیل کرد و پیام زیرا به کابران نمایش داد:

این پیام همچنین شامل لینک حمایت و دونیت از سازمان the Equal Justice Initiative و چند کمپین و.. دیگر است.

الکترون(Electron)

صفحه ی اصلی الکترون نیز میزبان پستی با امضای اعضای انجمن الکترون بود که همانطور که مشخصه لینک دونیت برای سازمان the Equal Justice Initiative و خانواده جورج فلوید و چند کمپین و … دیگر در آن قرار داده شده .

فلاتر (Flutter)

داخل سایت رسمی فلاتر در یک نوار شعار BlackLivesMatter قرار داده شده است که با کلیک بر روی آن وارد مطلبی از مدیر تولید فلاتر با عنوان BlackLivesMatter می شوید.

تست میس (TestMace)

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

ریداکس (Redux)

ریداکس هم به مانند بقیه شعار BlackLivesMatter و لینک دونیت سازمان the Equal Justice Initiative رو قرار داده .

ویو جی اس (Vue.js)

در سایت ویو نیز شعار BlackLivesMatter و لینک دونیت سازمان the Equal Justice Initiative در بنری سیاه قرار داده شده .

اکسپرس (Express)

در سایت رسمی اکسپرس هم شعار Black Lives Matter و لینک دونیت سازمان the Equal Justice Initiative قرار داده شده.

و در پایان

خیلی خوبه که برنامه نویسا اینقدر به مسائل انسانی اهمیت میدن و اینقدر خوب و هماهنگ با بی عدالتی و نژاد پرستی مقابله می کنند ، البته این حرکت ها رو جا های دیگه ای هم دیدم ولی هماهنگ ترینشون مربوط به برنامه نویس هاست ، مثلا داخل بازی COD : Warzone هم قسمت هایی از رابط کاربریش کاملا سیاه رنگ شده ، تا جایی که من فکر کردم مشکلی هست و جملاتی هم در حمایت سیاه پوستان نوشته شده.

منگر اندر نقش و اندر رنگ او
بنگر اندر عزم و در آهنگ او

گر سیاهست او هم‌آهنگ توست
تو سپیدش خوان که همرنگ توست
مولانا

همچنین ببینید :

https://virgool.io/@jadijadi/%D9%88%D9%82%D8%AA%DB%8C-%D9%87%DA%A9%D8%B1%D9%87%D8%A7%DB%8C-%D9%86%D8%A7%D8%B4%D9%86%D8%A7%D8%B3-%D8%AF%D9%88%D8%A8%D8%A7%D8%B1%D9%87-%D8%B8%D8%A7%D9%87%D8%B1-%D9%85%DB%8C-%D8%B4%D9%88%D9%86%D8%AF-%D8%A7%D9%86%D8%A7%D9%86%DB%8C%D9%85%D9%88%D8%B3-%D8%AF%D8%B1-%D8%AD%D9%85%D8%A7%DB%8C%D8%AA-%D8%A7%D8%B2-%D8%AA%D8%B8%D8%A7%D9%87%D8%B1%D8%A7%D8%AA-%D8%B6%D8%AF-%D9%86%DA%98%D8%A7%D8%AF-%D9%BE%D8%B1%D8%B3%D8%AA%DB%8C-dzy2toiorbyg

مطلب قبلی :

https://virgool.io/@Mrmoallem/%D8%B1%D8%A7%D8%A8%D8%B7-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%DB%8C-%D9%85%D9%86-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%D9%BE-%D9%85%D9%88%D8%A8%D8%A7%DB%8C%D9%84-%D9%88%DB%8C%D8%B1%DA%AF%D9%88%D9%84-ehontzsgkm8k

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

گردآوری توسط ایده طلایی

چطوری خدای پایتون بشم؟ خوان اول

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

خوان اول: آشنایی

برای یادگرفتن پایتون، اول باید پایتون یادگرفت 🙂 خیلی ساده‌س اما مهمه. کاری که باید بکنید اینه: یه منبع پیدا کنید، مطالعه کنید و یاد بگیرید. برای یادگرفتن هم مهم‌ترین نکته پشت‌کار داشتنه. اگر هم هرجای کار نیاز به کمک داشتید، بیاید این زیر بپرسید.

بهترین منابع برای یادگیری پایتون:

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

منابع انگلیسی:

کتاب Learn Python The Hard Way یکی از بهترین کتابهاست. از اسمش نترسید. درواقع اصلن هم سخت نیست. آموزش بر اساس مثال پیش می‌ره و خیلی دلنشین هم هست.

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

دوره‌ی ویدیویی Python Essential Training از سایت معروف لیندا هم یکی از گزینه‌های خوبه. نزدیک ۵ ساعت ویدیوئه که کلیت ماجرا رو خوب پوشش می‌ده.

رویکرد پیشنهادی: برای دست گرمی، دوره‌ی Sololearn رو بخونید یا کورس لیندا رو ببینید که با برنامه‌نویسی به صورت کلی آشنا بشید. بعد برید سراغ Learn Python The Hard Way و شروع کنید به یادگیری. حتمن هم تمرین ها رو همراه باهاش پیش برید. توی برنامه نویس شدن تمرین خیلی خیلی از مطالعه کردن مهمه تره.

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

منابع فارسی:

آموزش پایتون فرادرس تدریس شده توسط میترا تجربه کار. ۱۸ ساعت آموزشه و توی سرفصل‌هاش چیزای مهم پوشش داده شده. هزینه‌ش هم ۴۰ هزار تومنه.

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

راستش چون خودم هیچ کدوم از این دوره های فارسی رو ندیدم، نمی‌تونم کیفیتشون رو تضمین کنم. اما دوره‌ی آموزش پایتون مکتب‌خونه، یه مقدار به نظر بهتر میاد. اون کوئیز ها یقینن بهتون کمک می‌کنن. در انتها هم اگر توی آزمونش موفق باشید یه مدرک می‌گیرید. (البته این مدرک و در کل هیچ مدرک دیگه‌ای مطلقن هیچ کاربردی نداره و مهم‌ترین مدرک یه برنامه نویس، مهارتیه که از خودش نشون می‌ده).

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

توی هر جای کار هم نیاز به کمک داشتید، یا سوالی براتون پیش اومد، زیر همین مطلب بپرسید و من تلاش می‌کنم که زود جواب بدم. 🙂

اگر این مرحله رو تموم کردید، برید سراغ خوان دوم —-> به زودی.

اگر براتون مفید بود مطلب، با حمایت کردن ازش من رو دلگرم کنید برای تهیه کردن محتوا‌های بعدی. برای این کار می‌تونید از لایک کردن و کامنت کردن نظر و پیشنهاداتون شروع کنید و بعدش هم من رو توی توییتر دنبال کنید. شناسه‌ی من در توییتر: https://twitter.com/re_ke_mo

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

نوشته چطوری خدای پایتون بشم؟ خوان اول اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

[فِقط جاواسکریپت] 00. مقدمه

فِقط جاواسکریپت

سخن مترجم

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

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

  • بنویسم
  • یاد بگیرم
  • به اشتراک بذارم تا بقیه هم استفاده کنن

سعی می‌کنم روون و به زبون محاوره‌ ترجمه کنم. همچنین تلاشم بر اینه که تا جای ممکن کلمات تخصصی رو ترجمه نکنم و نظر شخصی‌م رو به هیچ‌وجه قاطی مطالب نکنم. هر جا، احساس کردید اشکالی وجود داره، حتما در قالب کامنت یا از طریق hbehkamal@gmail.com بهم بگید. خب بریم سراغ اصل مطلب.


سلام. من دَن آبراموف هستم.

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

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

خلاصه این دوره‌ها به درد من نمی‌خوردن!

چی می‌شد اگه یک دوره آنلاین بود که میتونست تو رو در درک جاواسکریپت آماده کنه و خسته‌کننده نباشه؟

فِقط جاواسکریپت دقیقا همون دوره آموزشیه که آرزو می‌کردم کاش داشتمش!

اگه حداقل مفاهیم پایه جاواسکریپت رو می‌دونید، فِقط جاواسکریپت کمک‌تون می‌کنه که اعتماد بیشتری به دانش‌تون به عنوان یک توسعه‌دهنده داشته باشید.

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


دوباره سخن مترجم:

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

نوشته [فِقط جاواسکریپت] 00. مقدمه اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

که عشق آسان نمود اول، ولی افتاد مشکل‌ها

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

منظورم از مسایل ساده، مسایلی از این دست است:

  • بررسی عضویت یک عنصر در مجموعه داده (membership)، به عنوان مثال، پاسخ به این سوال که آیا یک عدد در یک آرایه وجود داره یا نداره؟
  • شمارش تعداد عناصر متمایز در یک مجموعه داده (cardinality)، به عنوان مثال، در یک آرایه چند نوع عدد متفاوت وجود داره
  • محاسبه تعداد دفعات تکرار یک عنصر در یک مجموعه، یا شناسایی عناصر پرتکرار (frequency)، به عنوان مثال عدد ۴۲ چندبار در یک آرایه تکرار شده

و یا مسایل ساده‌ی دیگری از این جنس.

حل این مسایل بسیار ساده در بعضی شرایط بسیار سخت می‌شود.

  1. حجم (Volume) بسیار زیاد داده‌ها
  2. سرعت (Velocity) تولید و پردازش داده‌ها
  3. تنوع (Variety) و گوناگونی داده‌ها

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

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

مرورگر امن

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

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

پیشنهادها

فرض کنید که برنامه نویس سایت Medium یا ویرگول هستم! و قرار است که به هر کاربر چندین مقاله برای مطالعه پیشنهاد بدم، ولی می‌خوام مطمئن باشم که کاربر این مقاله را قبلا مطالعه نکرده باشه. به عبارت دیگر بعد از این‌که به کمک الگوریتم‌های توصیه‌گر، مجموعه‌ای از مقاله‌ها را برای کاربر ایجاد کردم، مقاله‌هایی که قبلا مطالعه کرده را از آن حذف کنم. بر اساس توئیت ویرگول در سال ۹۸ بیش از ۱۸ میلیون کاربر از ویرگول استفاده کرده‌اند. آیا برای این کار می‌توانم مقاله‌هایی که هر کاربر مطالعه کرده را در دیتابیس ذخیره کنم و برای حذف مقاله‌های قبلا خوانده شده از این دیتابیس استفاده کنم؟

توزیع محتوا

فرض کنید من برنامه نویس Akamai یا ابرآروان هستم! و قرار است که الگوریتمی برای مسیردهی درخواست‌ها ایجاد کنم به طوری که درخواست‌ها به کَش سروری مسیردهی شوند که پاسخ این درخواست در آن وجود دارد، و برای این کار باید تمامی کَش سرورها از اطلاعات کَش شده در دیگر کَش سرورها اطلاع داشته باشند (Cache Sharing)، آیا درست است که برای این کار، هر کَش سرور، آدرس درخواست‌هایی را که کَش کرده است را به تمامی کَش‌سرورها ارسال کند؟

سهام عدالت

فرض کنید من برنامه نویس سامانه سهام عدالت هستم!! و قرار است که وب‌سایتی راه‌اندازی کنم که ۸۰ میلیون ایرانی جستجو کنند که آیا سهام عدالت دارند یا نه. آیا راه درستیه که به ازای هر درخواست من در دیتابیس چند ده میلیونی دارندگان سهام عدالت جستجو کنم؟

فایروال

فرض کنید من برنامه نویس Fortigate یا یک شرکت ایرانی در این زمینه هستم! و قرار است بر روی یک پهنای باند ۱۰ گیگابیت در ثانیه، تمامی بسته‌ها (Packets) را بررسی کنم و لیستی از آی‌پی‌های پرتکرار بسازم. آیا می‌توانم به ازای هر بسته، در لیست آی‌پی‌ها جستجو کنم و شمارنده این آی‌پی را افزایش بدهم و در انتها با مرتب کردن تمامی این لیست، آی‌پی‌های پرتکرار را بسازم؟

توییتر

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

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

داده‌ساختارهای احتمالاتی

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

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

به عنوان مثال به کمک فیلتر کوکو (Cuckoo Filter) که یک داده‌ساختار احتمالاتی برای حل مساله عضویت (membership) در یک مجموعه است، برای پردازش یک میلیارد اِلِمان مجزا به کمی کمتر از یک گیگابایت حافظه نیاز دارد، پیچیدگی زمانی حذف و اضافه و جستجو O(1)‎ است.

چشم‌پوشی

آیا خطا در داده‌ساختار قابل چشم پوشی است؟ در بسیاری از موارد بله، قابل چشم پوشی‌است، به عنوان نمونه داده‌ساختارهایی که برای حل مساله عضویت وجود دارند، مانند فیلتر کوکو، یا فیلتر بلوم؛ دارای خطای «مثبت کاذب» (False-Positive) هستند ولی خطای «منفی کاذب» ندارند.

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

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

درهم‌سازی

پایه و اساس تمامی داده‌ساختارهای احتمالاتی توابع درهم‌ساز یا همان توابع هَش (Hash Functions) است.

توابع درهم‌سازی در دو دسته قرار می‌گیرند:

  1. توابع درهم‌ساز رمزنگارانه (Cryptographic Hash Functions)
  2. توابع درهم‌ساز غیررمزنگارانه

دسته اول برای استفاده در حوزه امنیت و رمزنگاری کاربرد دارند و معمولا به خاطر ویژگی‌هایی که دارند سرعت پردازشی کمتری به نسبت توابع درهم‌ساز دسته دوم دارند. به عنوان مثال SHA1-32 توانایی پردازش تقریبا ۳۰۰ مگابایت در ثانیه را دارد ولی MurMurHash3 توانایی پردازش نزدیک به ۳ گیگابایت در ثانیه، یا xxHash قدرت پردازشی نزدیک به 5.5 گیگابایت در ثانیه را دارد.

همانطور که حدس زده‌اید، در داده‌ساختارهای احتمالاتی از توابع درهم‌ساز غیر رمزنگارانه استفاده می‌شود که نرخ برخورد ( Collision Rate) کم و سرعت بسیار بالا دارند.

پیاده‌سازی

یکی از پیاده‌سازی‌های داده‌ساختارهای احتمالاتی که البته متعلق به نویسنده همین مطلب هم هست 🙂 در گیت‌هاب (github.com/zaghaghi/pdstl) قابل دسترس است. البته پیاده‌سازی‌های دیگری نیز به صورت متن‌باز وجود دارد ولی سعی شده و خواهد شد که در این پیاده‌سازی تقریبا بیشتر داده‌ساختارهای احتمالاتی به صورت یک‌جا و یک شکل پیاده‌سازی شود.

به عنوان مثال برای استفاده از فیلتر بلوم (Bloom Filter) به کمک کتابخانه PDSTL می‌توان به شکل زیر عمل کرد.

#include <membership/bloom_filter.h>
#include <vector>
#include <string>
#include <iostream>

int main() {
    // Read all urls from file or database into urls 
    std::vector<std::string> urls;
    // Define bloom filter with 11 hash functions and 16M memory bits
    bloom_filter<11, 16000000> url_bloom_filter;
    std::for_each(urls.begin(), urls.end(), [&url_bloom_filter](auto& item) {
        // Insert items into bloom filter
        url_bloom_filter.insert(item);
    });

    // Check that bloom filter contains an item or not
    if (url_bloom_filter.contains(&quothttps://gmail.com&quot)) {
        std::cout << &quotFOUND!!!!!&quot << std::endl;
    } else {
        std::cout << &quotNOT FOUND&quot << std::endl;
    }
}

بیشتر بخوانیم

یکی از مراجعی که برای خواندن در مورد این داده‌ساختارها وجود دارد، ویکی‌پدیا است. همچنین بهترین مرجع خود مقالات داده‌ساختارهاست و البته کتابی در سال ۲۰۱۹ منتشر شده که این داده‌ساختارها را یکجا جمع‌آوری کرده:

Probabilistic Data Structures and Algorithms for Big Data Applications by Andrii Gakhov, 2019, ISBN: 978-3748190486 (paperback) ASIN: B07MYKTY8W (e-book)

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

گردآوری توسط ایده طلایی

استخدام برنامه‌نویس Laravel در فرامحتوا

شرح موقعیت شغلی

  • مسلط به زبان PHP
  • مسلط به پایگاه داده mysql و postgresql
  • مسلط به فریم ورک Laravel
  • مسلط به معماری MVC و Restful
  • تجربه کار با Job و Event ها در Laravel
  • مسلط به ورژن کنترل Git و ساختار Gitflow
  • آشنایی با Design Pattern ها
  • مسلط به مفاهیم Caching در لاراول
  • توانایی نوشتن و نگه‌داری کدهای تمیز و خوانا
  • آشنا با مستند‌سازی کدها و دیتابیس
  • توانایی بالا در حل مسئله و ارائه راهکار های بهینه
  • جدیت و نظم در کار
  • مدیریت زمان
  • حداقل 3 سال سابقه برنامه نویس لاراول و داشتن نمونه کار قابل ارائه الزامی می باشد.

    مهارت‌های امتیازی:

  • آشنایی با Docker
  • آشنایی با CI/CD
  • آشنایی با مفاهیم متدولوژی Scrum

معرفی شرکت

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

ارسال رزومه به : khodae@faramohtava.com و همچنین شماره مندرج در تصویر

نوشته استخدام برنامه‌نویس Laravel در فرامحتوا اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

framework vs. library

به عنوان یک دانشجوی نرم افزار که از طریق دانشگاه با برنامه نویسی آشنا شد و به این حوزه علاقه مند شد همیشه واسم سوال بود که چرا دنیایه برنامه نویسی داره به سمت استفاده از فریم ورک میره بجای استفاده pure زبان های برنامه نویسی با اینکه زبان های pure آزادی عمل بیشتری رو بهمون میده.
سر کلاس درس از اکثر استاد هام این سوال رو پرسیدم ولی خیلی جواب واضحی نگرفتم بعد از تحقیق بسیار که موضوع برای خودم روشن شد خواستم این موضوع رو برای کسانی که تازه وارد دنیا برنامه نویسی شدن باز کنم.
در ابتدا باید بگم من مثال هام رو ممکنه با php و لاراول جلو ببرم ولی در کل این موضوعات برای تمام زبان های برنامه نویسی صدق میکنه.
وقتی شما شروع به یادگیری یک زبان برنامه نویسی مثلا php میکنید شاید برای پروژه یادگیری خودتان یک سایت را شروع به طراحی کنید وقتی کمی جلو بروید یا سایت خود را به یک متخصص نشان بدهید ایرادات بسیاری از شما میگیره نه بخاطر کم وقت گذاشتن شما یا کم تجربه بودن شما….بخاطر اینکه شما وقت ندارید تمام موارد امنیتی که کشف شده اند و راه حلش پیاده سازی شده اند یا تمام ماژول هایی که توسط برنامه نویس های دیگر نوشته شده اند رو خودتان پیاده سازی کنید.اینجاست که نوشتن اپلیکیشن با زبان خام کار طاقت فرسایی است و استفاده از frameworkها  و کتابخانه ها مطرح میشود.
همونطور که از معنای لغوی این کلمات مشخصه framework یک چهارچوب برای شما اماده میکند و کتابخانه مجموعه از متد ها و ماژول هاست.
از منظر شباهت این دو مفهوم، هردوی اینها برای حل مشکلات متداول و پیاده سازی مفهوم DRY(don’t repeat your self) و تمیز کد نوشتن توسط برنامه برنامه نویس های دیگر نوشته شده اند.
اما از منظر تفاوت این دو مفهوم باید به کلمه inversion controller مراجعه کرد.
کتابخانه مجموعه ایی از متد های پرکاربرده که شما رو از پیاده سازی الگوریتم های پیچیده رها میکنه و شما فقط کافیه یک متد را صدا بزنید. مانند: کتابخانه های ریاضیاتی.
اما framework ساختاری است که ممکنه شامل چندین کتابخانه و ماژول مختلف باشد که به مراتب ساختارمند تر و پیچیده تر از کتابخانه است اما به شما کمک میکند که طبق استاندارد های برنامه نویسی کدنویسی و تولید اپلیکیشن کنید.
به صورت خلاصه شما هرجایی که نیاز داشته باشید یک متد از کتابخانه رو صدا میزنید اما در framework شما باید کدهای خود را داخل مسیرهایی که framework برایتان مشخص کرده قرار بدهید تا اون هنگام اجرا اپلیکیشن به کد های شما مراجعه کرده و از آنها استفاده کند.به این نحوه استفاده و فراخوانی inversion controller میگویند.
مثلا اگر شما بخواهید با pure php شروع به پیاده سازی مدل mvc بکنید باید در ابتدا خودتان ساختار  کنترلر را پیاده سازی کنید و ارتباطی که دستورات از view شما به کنترلر برسند و در آنجا پردازش شوند و سپس در مدل ذخیره شوند را خودتان پیاده سازی کنید اما وقتی لاراول این کار را با درنظر گرفتن تمام مسائل امنیتی انجام داده است چرا شما باید خودتان این کار را بکنید؟
مسئله ایی که در مقایسه framework ها درنظر میگیرند و گفتنش در اینجا خالی از لطف نیست مسئله opinionated بودن یا سختگیر بودن framework هاست که باید به صورت موردی در هر framework بررسی بشود و در تعریف به میزان ازادی عمل برنامه نویس در دستکاری ساختار های اپلیکیشن برمیگردد.
به طور مثال من بر اساس تجربه خودم میگم که angular یک framework سختگیره و vuejs یک framework بازتری هستش.

نتیجه گیری:
کتابخانه ها و framework ها کدهایی هستند که برای حل مشکلات متداول به کمک شما می آیند و توسط افرادی مانند خود شما نوشته میشوند با این تفاوت که کتابخانه هارا هر کجا که نیاز دارید از آنها استفاده میکنید اما framework ها برای شما تعیین میکنن که هر کدی کجا نوشته بشه که این استاندارد کد نویسی شما رو ارتقا میده.
در آخر لازم به ذکر هستش که من برنامه نویس نیستم بلکه درحال یادگیری برنامه نویسیم و قطعا مقاله من ایراداتی رو داره که خوشحال میشم نظراتتون رو بخونم.

نوشته framework vs. library اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

درخواست های Http متمرکز در Redux

با استفاده از Thunk middleware می‌توانیم action های Redux رو از object های ساده به متد های هوشمند تبدیل کنیم. یکی از استفاده های معروفی که از این هوشمند سازی میشه, ارسال درخواست‏ های http از طریق action هاست. اگه به نمونه کد زیر نگاه کنیم در کنار مزیت انتقال درخواست ها به این بخش متوجه یه سری معایب هم می‌شویم:

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

می‌تونیم دوباره با middleware ها مشکلمون رو حل کنیم, مثلا هر بار که خواستیم درخواست http داشته باشیم این action رو dispatch کنیم:

و یه middleware داشته باشیم که در صورت dispatch شدن ‘API_REQUEST’ اطلاعات لازم رو از meta object بگیره و درخواست رو انجام بده:

حالا اگه بخواهیم مثلا baseURL رو هم تغییر بدیم فقط همین قسمت از کد نیاز به تغییر داره یا حتی می‌توانیم loading رو به سادگی به همه درخواست هامون اضافه کنیم:

به همین تمیزی! برای اضافه کردن middleware به store از اینجا کمک بگیرین.

نوشته درخواست های Http متمرکز در Redux اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

۶ عادت خوب برنامه نویسی برای توسعه دهندگان

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

همانطور که همه ما می دانیم، افراد با عادات خود شناخته میشوند. برای تبدیل شدن به یک برنامه نویس بهتر، باید سعی کنیم عادات خوب را در خود تقویت کنیم. در این مقاله به ۶ عادت مهم برنامه نویسان اشاره کرده ایم، که رعایت آنها به شما در مسیر تبدیل شدن به یک برنامه نویس خوب کمک میکند.

۱. کدهای خود را تمیر کنید

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

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

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

۲. کد خود را برای دیگران بنویسید

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

نسبت زمان صرف شده برای خواندن و درک کد ها در مقابل نوشتن آنها بیش از ۱۰ به ۱ است. بنابراین اگر کدهای خود را قابل فهم بنویسید، به خود و دیگران کمک بزرگی کرده اید. هنگام کدنویسی خیلی فانتزی و یا پیچیده کدنویسی نکنید، کد ساده ای بنویسید که همه بتوانند آن را درک کنند. واقعاً نیازی کدی را که سایت Stack Overflow کپی کرده اید و حتی خودتان هم نمیفهمید را در پروژه به کار ببرید.

۳. آنچه لازم است را انجام دهید و نه بیشتر از آن

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

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

۴. برای کدهای خود برنامه داشته باشید

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

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

به مشکلاتی که ممکن است در طول مسیر پیدا کنید و چگونگی مقابله به آن فکر کنید. چگونه می توانید کد های خود را ساختاربندی کنید؟ دلیل اجرای قابلیت های مثلا فلان قابلیت چیست؟ اینها سوالات بزرگی است که باید قبل از شروع کد نویسی از خود بپرسید. این سؤالات می توانند شما را از این واقعیت آگاه سازند که قبل از نوشتن کدها باید در مورد آنها فکر کنید.

۵. مستند سازی کنید

بله ، می دانم … مطمئناً این عادت جالب ترین عادت در این لیست نیست، اما یکی از بهترین هاست. مستندسازی در کار شما بسیار مهم است. آیا تا به حال مجبور شده اید کدهای برنامه نویسی را بررسی کنید که هیچ مستنداتی در مورد کدهای نوشته شده ارائه نکرده است، واقعا کار طاقت فرسایی است، پس همیشه مستند سازی را در نظر بگیرید.

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

معمولا نحوه نصب و راه اندازی در این فایل ها مشخص میشود. در کنار مستند سازی استفاده از اسامی واضح و خوب برای متغیرها و توابع نیز بسیاری اهمیت دارد. بهتر است نام توابع تشریح کننده عمکرد آنها باشند.

۶. هرگز یادگیری را متوقف نکنید

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

این کار بدان معنی نیست که شما باید در همه این زبان های برنامه نویسی یا چارچوب ها متخصص شوید. اما بهتر است از روند کاری آنها مطلع باشید. با توجه با اینکه هرکدام از این فریمورک ها راه حل جدید ارائه میدهند، بینش شما در حل مسائل بهبود میابد.

منبع : لرن سورس

نوشته ۶ عادت خوب برنامه نویسی برای توسعه دهندگان اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

قوانین معروف در توسعه نرم‌افزار

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

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

قانون مورفی (Murphy’s Law)

یکی از معروف‌ترین قوانین هست که فقط هم مختص توسعه نرم‌افزار نیست:

هر چیزی که ممکنه خراب بشه، حتما خراب میشه

استفاده از ورژن کنترل، متدلوژی TDD و توسعه نرم‌افزار به روش تدافعی و غیره همه روش‌هایی برای جلوگیری از این قانون هستند

قانون پارکینسون (Parkinson’s Law)

این قانون درباره مدیریت زمان و برنامه‌ریزی برای انجام کارهاست که میگه:

هر کار به اندازه زمانی که برای آن تخصیص داده شده طول می‌کشد

استفاده از ابزارهای مدیریت پروژه آنلاین، جلسات فردی و تیمی منظم، داشتن اهداف مشخص، زمانبندی دقیق برای انجام کارها و جلوگیری از multi-tasking همه از مواردی هستن که به جلوگیری از قانون پارکینسون کمک میکنه.

قانون بروکس (Brook’s Law)

آقای Fred Brooks نویسنده کتاب معروف The Mythical Man-Month این قانون رو در کتابش مطرح میکنه:

اضافه کردن نیروی انسانی به یک پروژه نرم‌افزاری با تاخیر، تاخیر اون رو بیشتر میکنه

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

قانون هافستدر (Hofstadter’s law)

از این قانون مجدد در کتاب The Mythical Man-Month و متدلوژی XP صحبت شده:

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

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

قانون کانوی (Conway’s Law)

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

هر سازمانی که سیستمی را طراحی می‌کند، ساختار طرح خروجی یک کپی از ساختار ارتباط درون سازمان خواهد بود

در بسیاری از شرکت‌ها افراد بر اساس توانایی‌ها در تیم‌های مختلف Frontend, Backend, DevOps و غیره قرار می‌گیرن. روش بهتر این هست که مثل طراحی میکروسرویس افراد که روی یک محصول یا سرویس کار می‌کنند در یک تیم قرار بگیرند تا ارتباط و خروجی بهتری داشته باشند.

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

قانون پاستل یا قانون قدرتمندی (Postel’s Law)

جان پاستل یکی از تاثیرگذارترین افراد در شکل‌گیری اینترنت، TCP و DNS این قانون رو مطرح میکنه که:

در ارسال‌ها محافظه‌کار باشید، ولی در دریافت روشن‌فکر باشید

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

اصل پارتو یا قانون ۸۰-۲۰ (Pareto Principle)

اصل پارتو که به نام‌های قانون ۸۰-۲۰ و قانون افراد اندک اساسی هم معروف هست میگه:

۸۰ درصد رخدادها از ۲۰ درصد دلایل به وجود می‌آیند

ارتباط این اصل با حوزه کاری توسعه نرم‌افزار به این شکله که معمولا ۸۰ درد باگ‌های نرم‌افزار مربوط به ۲۰ درصد پروژه هستند که با استفاده از ابزارهای Linter و Static Analysis به صورت اتوماتیک میتونیم این مشکلات رو راحت‌تر پیدا کنیم.

همچنین میشه گفت ۸۰ دصد کارها در یک سازمان توسط ۲۰ درصد افراد انجام میشه و مشخص کردن این که چه افرادی بیشترین کار رو انجام میدن کار سختی هست ولی به لطف ابزارهای آنلاین contribution های افراد و کیفیت انجام کارها راحت‌تر پیگیری میشه.

اصل پیتر (Peter Principle)

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

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

اصل پیتر حالت خاصی از «پدیده همه‌جانبگی» (ubiquitous observation) است: هر آنچه (درست) کار می‌کند در حالتی پیشرفته‌تر و چالش‌برانگیزتر به کار گرفته خواهد شد تا آنجا که دیگر کارایی از خود نشان ندهد.

اثر دانینگ–کروگر (Dunning–Kruger effect)

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

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

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

قانون لینوس (Linus’s Law)

لینوس توروالدز خالق کرنل لینوکس این قانون رو میگه:

هرچه چشم‌ها بیشتر باشند باگ‌ها کم عمق‌ترند

این جمله به نقل از لینوس توروالدز در کتاب «کلیسا و بازار» نوشته اریک ریموند گفته شده که تفاوت بین دو روش توسعه نرم‌افزار رو توضیح میده. روش کلیسا که میگه کد توسعه داده شده در بین release ها عمومی نیست و با هر release کد به صورت متن باز منتشر میشه که نمونه‌های این نرم‌افزارها GCC, Emacs هستن. روش بازار روشی هست که هسته لینوکس در دسترس عموم و در بستر اینترنت توسعه داده میشه و شروع کننده اون رو لینوس توروالدز میدونه.

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

قانون مور (Moore’s Law)

نخستین بار آقای مور از بنیان‌گذاران اینتل این قاعده رو بیان میکنه که:

تعداد ترانزیستورهای روی یک تراشه با مساحت ثابت هر ۲ سال ، به طور تقریبی دو برابر می‌شود

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

اطلاع داشتن از چنین قواعدی باعث میشه در طراحی و توسعه نرم‌افزارها دید بهتری از آینده داشته باشیم و پیش‌بینی های دقیق‌تری داشته باشیم. از نمونه‌های عدم آینده‌نگری در نرم‌افزارها میشه به مشکل سال ۲۰۳۸ اشاره کرد که در این سال timestamp روی سیستم‌های ۳۲ بیتی overflow میشه یا مشکل Y2K که تقویم‌های کامپیوترها بعد از سال ۱۹۹۹ و شروع سال ۲۰۰۰ به مشکل خوردن.

قانون ویرث (Wirth’s Law)

این قانون رو آقای نیکولاس ویرث خالق زبان برنامه‌نویسی پاسکال میگه:

سرعت کند شدن نرم‌افزار بیشتر از افزایش سرعت سخت‌افزار هست

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

قانون ۹۰-۹۰ (Ninety-Ninety rule)

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

۹۰ درصد کد در ۱۰ درصد زمان توسعه داده میشه. ۱۰ درصد مابقی کد ۹۰ درصد زمان رو میگیره.

اصل Knuth’s principle

این قانون درباره بهینه‌سازی کد هست که میگه:

بهینه‌سازی قبل از موعد عامل همه بدی‌هاست

روش استاندارد توسعه کد این هست که شما کد رو در وضعیتی که فکر میکنید خوبه توسعه میدین و بعد از پیدا شدن مشکلات سرعت، به دنبال رفع اونها برید. بهینه کردن قبل از موعد فقط باعث پیچیده و کند شدن توسعه میشه.

یک بار دنبال مقاله پارتیشن کردن دیتابیس Postgres بودم که اولش گفته بود اگر نمیدونین پارتیشن کردن دیتابیس چیه حتمن به اون نیازی ندارید!

قانون نورویگ (Norvig’s Law)

قانون نورویگ یکی از قوانین بدبینانه هست که میگه:

هر تکنولوژی که به درصد نفوذ بیشتر از ۵۰ درصدی میرسه، هرگز دیگر افزایش ۲ برابری نخواهد داشت (در هیچ بازه زمانی)

طبیعیه که مثلا استفاده کنندگان از تلفن هوشمند وقتی از ۱ میلیون به ۲ میلیون در کشور میرسه افزایش دوبرابری بوده ولی وقت مثلا ۳۰ میلیون استفاده کننده در کشور داریم هرگز افزایش ۲ برابری یعنی ۶۰ میلیون مشترک نخواهیم داشت.

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

گردآوری توسط ایده طلایی

نکات مثبت و منفی Jupyter Notebook برای دیتا ساینتیست ها

ژوپیتر نوت بوک

ژوپیتر نوت بوک سه ویژگی مثبت دارد:

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

نکات منفی ژوپیتر نوت بوک

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

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

عواقب تکرار کردن کد

  • همکاری با یکدیگر سخت میشود چون هر کدام از ما کد هایی را از یکدیگر کپی میکنیم.
  • به سختی میتوان به نتیجه کد اطمینان کرد. کدام یک از این نوت بوک ها نتیجه x را به ما داده است ؟

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

اما در شرکت های بزرگ به مشکل های زیادی برخورد میکنید چون نمیخواهید افراد زیادی دسترسی مستقیم به داده های مورد استفاده داشته باشند. ( GDPR را مطالعه فرمایید ). در عمل، در یک محیط کاری، نمودار ها به محیط پاورپوینت کپی پیست میشوند. این کار برای دیتا ساینتیست بیهوده است که هرگاه که داده ها تغییر میکنند، عمل کپی پیست را دوباره انجام دهد.

یک مثال

این مثال از این نوت بوک را در نظر بگیرید.

شروع کار آسان بود. فقط تعدادی از سلول ها را از بخش اول نوت بوک کپی کردم و سپس برای خودم شروع به گشت و گذار کردم. اما همینجا میتوانیم نکته منفی را ببینیم. قسمت مدیریت دسترسی (access-credentials management) حالا در تمام نوت بوک ها کپی شده است. اگر تغییر بکنند چه میشود؟ در این صورت همه نوت بوک ها را باید تغییر داد.

با اندکی بی نظمی، ممکن است ورژن های مختلفی از یک نوت بوک را ایجاد کنید که هیچکس به یاد ندارد نتیجه هرکدام چه چیزی است.

نکات مثبت یک IDE

میتوانید از Spyder یا PyCharm برای جایگزین ژوپیتر نوت بوک استفاده کنید.

در اسپایدر میتوانید بدون از دست دادن نتیجه کد فعلی خود، یک کد دیگر را بارگزاری کنید که این از ویژگی های خوب اسپایدر به حساب می آید. پس اگر میخواهید بسیاری از تغییرات خود را با استفاده از Pandas یا دیگر ابزار ها در کامپیوتر خود انجام دهید، اسپایدر یک گزینه ایده آل به حساب می آید. اگر از Anaconda استفاده میکنید، اسپایدر به همراه آناکوندا منتشر میشود.

پای‌چارم برای نوشتن برنامه های طولانی و گرفتن نتایج یکسان در کامپیوتر های مختلف مناسب است. پای‌چارم قابلیت های زیادی برای بهره‌وری بیشتر دارد. در اسپایدر و پای‌چارم میتوان از #%% استفاده کرد تا مثل ژوپیتر نوت بوک کد ها را به سلول های مختلف تقسیم بندی کرد.

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

تبدیل ماشین لرنینگ به محصول نهایی

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

برای نوت بوک ها میتوانید به Amazon SageMaker و Kubeflow مراجعه کنید.

خلاصه

آیا باید نوت بوک ها را حذف کنید ؟ نوت بوک ها ویژگی های مثبت زیادی دارند. این بستگی به محیط کار و نیاز های اصلی شما دارد:

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

نوشته نکات مثبت و منفی Jupyter Notebook برای دیتا ساینتیست ها اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی