مخلص کلامِ immutability

29 مهر 1398 - علوم رایانه

در زبان‌های برنامه‌نویسی با دو نوع از ساختار داده‌ها روبرو هستیم که به mutable و immutable تقسیم می‌شوند. احتمالاً خیلی برداشت‌ها بشه از معنای این دو نوع کرد ولی در حقیقت Immutability به معنای این نیست که ما تغییر داده رو منع می‌کنیم. در اصل Immutability بیشتر در مورد چگونگی تغییر داده‌ها صحبت می‌کنه. ما همچنان می‌تونیم به یه آرایه یه مقدار اضافه کنیم؛ داستان اینه که توی زمانی که داده‌‌ی ما Immutable هست فقط ما این کار رو به طور متفاوتی انجام می‌دیم.در دنیای mutable می‌تونیم به طور مستقیم توی یه آرایه یه مقدار جدید اضافه کنیم ولی توی دنیای immutable یه آرایه جدید ساخته می‌شه که توی مقدار جدید به آرایه جدیده اضافه شده. مفهم اصلی که باید درک کنیم فقط اینه که به جای تغییر مستقیم چیزی باید چیز جدید بسازیم و تغییرات رو روی اون اعمال کنیم.پس متوجه شدیم که immutability به معنای این هست که ما نمی‌تونیم خود داده رو مستقیماً تغییر بدیم. ولی راهی که وجود داره اینه که ما یه فانکشنی رو صدا می‌زنیم و اون فانکشن داده‌ی ما و مقداری جدید رو می‌گیره و یه داده‌ی جدید  با تغییرات اعمال شده به ما برمی‌گردونه.یه مثال خیلی ساده بزنم که باور کنید ما مدت‌ها ست با این مفهموم توی تمام زبان‌های برنامه‌نویسی کار می‌کنیم و فقط بهش دقت نکردیم. شما قطعاً با اعداد و عملگرهای ریاضی توی زبان‌های مختلف کار کردید دیگه! اعداد یا نوع داده‌های int , number از نوع immutable هستند و عملگرهای +، -، *، / همون فانکشن‌هایی هستند که به جای اینکه یه داده رو تغییر بدند اون داده رو می‌گیرند و تغییرات رو روش اعمال می‌کنند و یه مقدار جدید رو برمی‌گردونند. مقدار اولیه‌ی ما همچنان دست نخورده وجود داره و سرجاش می‌مونه.

مزایای Immutability چیه؟

  • کارایی و performance اپلیکیشن ما افزایش پیدا می‌کنه.
  • برنامه‌نویسی و دیباگ کردن راحت‌تر می‌شه به این طور که وقتی شما در طول لایف‌سایکل یه متغیر مطمئن باشی که هرگز تغییر نمی‌کنه خب با خیال راحت می‌تونی ازش استفاده کنی تا متغیری که ممکنه هر توی هر فانکشنی یا هر جایی از لایف‌سایکلش مقدار متفاوتی داشته باشه.
  • توی multi-threading یا چندریسمانی مشکلات کمتر می‌شه به این دلیل که داده‌ای که هیچوقت تغییر نمی‌کنه لازم نیست که lock بشه تا چندین تِرِد synchronize بشند.
  • مقایسه‌ی مقدار متغیرها در بعضی موارد بهبود پیدا می‌کنه مثل مقایسه‌ی عمیق یا deep comparison توی آبجکت‌ها

غولی که بی‌خود نبود

1 شهریور 1398 - آزاد

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

سایه

21 خرداد 1398 - آزاد

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

تصمیمات سخت

1 اردیبهشت 1398 - علوم رایانه، وب

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

شاید حیاتی‌ترین تصمیمی که گرفتم مربوط به انتخاب TypeScript (تایپ‌سکریپت) بود. یادمه مرداد ماه بود و با اتوبوس داشتیم می‌رفتیم تهران که توی اتوبوس ناگهان تصمیم گرفتم از روزی که برگردم اصفهان پروژه رو ببرم روی تایپ‌سکریپت. یه پروژه با بالای ۶۰ هزار خط کد. البته تصمیمم بی‌فکر نبود؛ مدت‌ها به مزایا و عواقبش فکر کرده بودم ولی عملی کردنش ناگهانی بود. بدون مشورت و اجازه این کار رو کردم و به سپهر هم گفتم باید تایپ‌سکریپت کد بزنه. یادمه چقدر پروسه‌ی سختی بود. نتیجه چی شد؟ عالی بود. بعد از چند ماه همه راضی بودند. هنوز مقاومت‌ها رو به یاد دارم. هنوز وقت کم آوردن برای ددلاین رو به یاد دارم چون مجبور بودم تمام تایپ‌های پروژه رو بنویسم. هنوز مستندات کافی پیدا نکردن‌ها رو به یاد دارم. حتی یادمه تایپ خود ری‌اکت هم آپدیت نبود ولی وقت و حوصله‌ی کافی برای کانتریبیوت رو نداشتم. یادمه.

تایپ‌سکریپت اولین تصمیم نسبتاً مهم نبود. فکر کنم اولیش کنار گذاشتن css modules و استفاده از یه لایبرری css in js بود. یادمه که به لایبرری emotion رسیدم که هیچ کسی از اطرافیانم نمی‌شناختش. تصمیم گرفتم ازش استفاده کنم و یک هفته‌ای کامپوننت‌هام رو با اون نوشتم. ولی اونقدر کامیونیتیش کوچک بود که یه روز کلافه شدم و در آنی styled-component رو جایگزین کردم. فقط به دلیل مستندات و کامیونیتی بزرگ‌تر چنین تصمیمی گرفتم. یادمه به این فکر کردم که این پروژه، پروژه‌ی تفریحی من نیست و نباید سر آینده‌اش ریسک کنم. اگه فردا من رفتم و جایگزین شدم باید نفر بعد سریع بتونه با پروژه هماهنگ بشه.

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

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

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

دریایی برای غرق شدن

3 اسفند 1397 - آزاد

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

اگه دریا دریای خدا و معشوق نباشه چی؟ اگه دریای دنیا و جامعه باشه چی؟

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

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

در دریای تو غرق شدم؟

کریمان عاشقند

5 آبان 1396 - روایت

ترک موتور بودیم و زیر لب زمزمه می‌کردیم «بی‌وفا دنیا» که نگاهمون به ایستگاه اتوبوس افتاد. سربازکی رو دیدیم که انبه به دست کنار دلبرکش نشسته.

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

عاشق و معشوق خر کیف از زندگی و ذوق‌زده.

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

گویی تمام بخشندگی عاشقان، مادران و کریمان تاریخ جلوی چشممونه.

افزایش سرعت لاراول

21 مهر 1396 - وب

افزایش سرعت لاراول می‌تونه با چند تا کار ساده انجام بشه. این راهنما موارد عمومی رو پوشش می‌ده و با چند روش ساده افزایش عملکرد رو شاهد خواهیم بود. ضمناً قرار نیست که وارد جزئیات وب اپلیکیشن‌های ویژه یا روش‌های زمان‌بر و پیچیده بشه.

نکته اینکه قرارم بر این بوده که هرجا بتونم توی هر موضوعی متنی رو به فارسی در وب منتشر کنم حتی اگه ترجمه باشه. این یادداشت ترجمهٔ ساده از مقالهٔ Speeding up  Laravel in Simple Steps هست که یه راهنمای خیلی ساده و جمع و جوره.

ادامه نوشته ⇜

ماست موسیر کاله یا هراز؟

12 مرداد 1396 - روایت

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

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

سوال‌هایی که توی ذهن خودم شکل گرفت این بود که آیا واقعاً انقدر «اطلاعات» مهم بود؟ آیا بقیه هم با چنین مشکلی(در دسترس نبود اطلاعات تکمیلی) یه محصول رو نمی‌خرند؟ آیا برای انتخاب دو محصول چنین مسائل کوچکی تأثیر داره؟ آیا توی یه وب سرویس هم ماجرا به همین سادگیه که مثلاً اگر کسی دستورالعمل اون محصول رو نمی‌دونه دیگه ازش استفاده نمی‌کنه؟

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

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

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

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

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

Instapaper vs. Pocket

6 مرداد 1396 - علوم رایانه

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

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

علت اینکه چنین چیزی رو دارم می‌نویسم اینه که دوست دارم تعداد کاربران اینستاپیپر بیشتر بشه تا این سرویس دوست‌داشتنی بسته نشه.

پیش‌نوشت: از خوبی‌های پاکت شروع می‌کنم و به خوبی‌های اینستاپیپر می‌رسم 😀

ادامه نوشته ⇜

چرا بیشتر باید در وب فارسی بنویسم؟

14 تیر 1396 - آزاد، وب

پارسال، پیارسال بود انگار؛ هکری اطلاعات جایی رو بدست آورده بود و یا روش نفوذ به جایی رو پیدا کرده بود یا یه چیزی مثل این :))) (سطح تعریف خاطره رو تو رو خدا) خلاصه اینکه این بنده خدا اطلاعات ماجرا رو در اعتراض به تک زبانه شدن وب به اسپانیولی منتشر کرده بود!

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

ادامه نوشته ⇜

نوشته‌های قدیمی‌تر