امین سرابی | Amin Sarabi

بازگشت امین بر سر پروژه تستامین

Fri, 04 Jan 1405 20:34:16 GMT

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

در سال 1399 بود که پروژه تستامین رو شروع کرده بودم. مدت زیادی مشغول پشتیبانی از اون نرم افزار بودم و کاربران نسبتا زیادی هم داشتیم.

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

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

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

در اواخر سال 1404، تصمیم گرفتم که برگردم سروقت این پروژه خاطره انگیز و قدیمی.

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

با حجم فقط 1 مگابایت.

جزئیات خیلی بیشتری رو بعدا خواهم نوشت. فعلا همینقدر کافیه.

ارتباط با امین سرابی

Tue, 30 Oct 1404 00:00:00 GMT

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

<br/> <textarea style="border-radius: 20px; width: 100%; height: 200px; color: rgb(128,128,128); background: transparent; border: dashed rgb(128,128,128); padding: 10px;" type="text" id="message" placeholder="پیغام شما..."> </textarea> <br/> <button id="sendMessage" style="border-radius: 20px; padding: 10px; width: 100%; margin-top: 10px;" class="btn-card" type="button">ارسال به امین </button>

        function sendMessage() {
            let text = textField.value.trim();
            if (text.length > 3) {
                button.innerText = "درحال ارسال...";
                fetch("/contact", {
                    method: "post",
                    body: JSON.stringify({message: text}),
                    headers: {
                        "content-type": "application/json"
                    }
                }).then(value => {
                    if (value.ok) {
                        button.innerText = "ارسال شد...";
                        textField.value = ""
                    } else {
                        textField.value = text;
                        button.innerText = "ارسال با خطا مواجه شد."
                    }
                    setTimeout(function () {
                        button.innerText = "ارسال به امین";
                    }, 1500)
                })


            } else {
                button.innerText = "ارسال به امین";
                alert("متن شما خیلی کوتاه است.")
            }

        }

        button.onclick = sendMessage;

</script>

برنامه نویس کامپیوتر و آموزگار انسانها

Tue, 10 Jul 1404 20:34:16 GMT

دو هویت متفاوت

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

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

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

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

دشواری و حساسیت شغل معلمی

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

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

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

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

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

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

یکی زرنگه یکی بیخیال. یکی خجالتی هست و یکی گستاخ. یکی زورگو هست و یکی مظلوم. یکی ازت متنفره و یکی تو رو معلم محبوب خودش میدونه. و همه اینها باهم در کلاست نشستن و نگاهشون به توعه. و جالب اینجاست که اونا انتظار دارن با همشون یک جور برخورد کنی. حسادت باعث میشه که تفاوت برخورد شما با هرکدوم از اونها باعث یک فاجعه بشه. اگه رفتار و انتظاراتتون رو براساس شخصیت و کشش هرکدومشون تنظیم کنید اونها به سرعت متوجه این تفاوتها میشن و به این "بی عدالتی" اعتراض خواهند کرد و توانایی پذیرشش رو نخواهند داشت و اعتبار شما در بین اونها زیر سوال خواهد رفت.

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

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

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

قوانین امین در مدرسه

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

قانون اول: پایداری روان و گذر از نفس

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

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

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

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

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

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

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

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

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

قانون دوم: ممنوعیت خشونت فیزیکی و کلامی

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

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

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

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

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

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

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

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

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

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

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

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

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

قانون سوم: پذیرش تنفر کودک از آمپول

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

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

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

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

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

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

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

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

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

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

استفاده امین از کامپیوتر برای اهداف آموزشی

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

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

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

استفاده از هوش مصنوعی برای ساختن جملات انگلیسی مختلف و طراحی سوال رو هم به این موارد بالا اضافه کنید…

این نوشته به تدریج کامل خواهد شد. فعلا به همین شکل منتشرش میکنم…

به خیر تو امید نیست؛ شر مرسان!

Thu, 17 May 1404 20:34:16 GMT

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

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

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

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

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

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

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

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

وقتی میخوایم سیستمی رو با یک معیار مشخص مثل بررسی کنیم؛ چهار رویکرد کلی میتونن وجود داشته باشن:

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

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

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

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

Mon, 30 Apr 1404 20:34:16 GMT

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

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

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

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

همه برنامه‌نویسها شاید زمانی "منابع محدود" یک کامپیوتر رو هنگام نوشتن کدهاشون درنظر گرفتن. اما آیا همینقدر به محدودیت ذهن خودمون و کاربرمون دقت میکنیم؟ ما نرم‌افزار رو نه برای پردازنده‌ها بلکه برای انسانها میسازیم. ممکنه کدهایی نوشته باشیم که کمترین میزان RAM و CPU cycle رو استفاده میکنن. اما تا زمانی که محدودیت رم و پردازنده خودمون در درک کردن و تغییر دادن اون کد رو درنظر نگرفته باشیم؛ در اشتباهیم. تا زمانی که کاربران ما نمیتونن نرم‌افزارمون رو بفهمن، کارمون درست نبوده.

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

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

تست پذیری: سنجش خودکار صحت عملکرد

بدیهیه که نرم‌افزار خوب، باید درست عمل کنه. و تنها راه مطمئن شدن از اینکه چیزی درست عمل میکنه؛ تست کردنشه.

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

پس چک کردن، آسونتر و دردسترس‌تر از حل کردنه. این در دنیا به عنوان مسائل P و NP شناخته شده که میتونید دربارش بخونید.

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

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

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

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

قاعدتا باید متونی رو به عنوان ورودی به اون نرم‌افزار بدیم؛ و ببینیم که آیا خروجی اون با تعداد کلمات مترادف متن برابر هست یا نه.

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

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

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

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

نوشتن تست قبل از کد اصلی در دنیا به Test driven development معروف شده و اگه تا الان دربارش نمیدونستید؛ توصیه میکنم ساده از کنارش نگذرید.

کدهای json parser و date converter من با همین روش نوشته شدن.

یک json parser با رعایت تست پذیری

::github{repo="AminSarabi/JSON-Parser"}

دیباگ پذیری: خوانایی کد و شفافیت اجرا

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

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

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

درباره برنامه‌نویسی و نبوغ

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

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

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

بنظر من هرکسی که با مهندسی و حل مسئله درگیره؛ با مفهوم هوش و توانایی ذهنی متغیر انسانها هم درگیر بوده. و چه بهتر که یک بار برای همیشه، این موضوع رو درک کنیم و کنار بگذاریم. حتی اگه به قیمت طولانی شدن این متن تموم بشه.

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

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

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

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

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

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

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

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

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

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

این نوشته به تدریج ادامه پیدا خواهد کرد…

کدهای شیشه‌ای: شفافیت اجرا

Tue, 24 Apr 1404 20:34:16 GMT

دفترچه خاطرات کدها

یکی از عادتهای خوبی که یک برنامه نویس میتونه داشته باشه؛ اینه که کدهایی بنویسه که خودشون هم اهل نوشتن باشند. یعنی نرم‌افزار print statement های زیادی داشته باشه و اونارو در یک فایل ذخیره کنه. این باعث میشه رفع عیب کد به مراتب آسون‌تر باشه؛ چون خود کد در حین اجرا دفترچه خاطرات مینویسه و داستان اتفاقی که افتاده رو برای شما تعریف میکنه.

البته که این یه کشف جدید نیست؛ بلکه یه استاندارد شناخته شدست و حتی ماژولهای متنوعی برای این کار وجود دارن که به اسم logger شناخته میشن و مفاهیمی مثل log level و tag و logcat و… برای برنامه نویسها آشنا هستن.

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

console.error("Task failed successfully!")
// a documented failure is a successful failure!

ارائه نسخه جدید برای دیباگ

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

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

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

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

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

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

:::important[چنین گفت امین:] اولین کاربری که کدهای ما باید ازش پشتیبانی کنن خود ما هستیم. نوشتن کدهای قابل دیباگ، نوعی مهربون بودن با خودمون و پذیرش و سازگاری با محدودیتهامونه. :::

اطلاعات بستر و ورودیها

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

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

مورد دیگه‌ای که باید توی گزارشهامون بیاریم؛ درخواستهایی هست که به سایر api ها ارسال میشن. پاسخ این apiها ممکنه با چیزی که انتظارش رو داریم متفاوت باشه؛ و بهتره که محتوای ارسالی و دریافتی خودمون رو گزارش کنیم.

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

خطاهای پیشبنی نشده

معمولا ما انتظار برخی خطاها رو داریم و براشون آمادهایم. اما موضوع شاید مهم‌تر برخورد با Uncaught Exceptionها هست. یعنی خطاهایی که در نرم‌افزار ما پیشبینی نشدن؛ و پیش اومدن اونها باعث توقف کامل اجرای کدها میشه. مثلا تو اپلیکیشنهای اندروید در این حالت پنجره App has stopped working یا App keeps stopping نمایش داده میشن. درصورتی که ما آمادگی این خطاهارو نداشته باشیم؛ مجبور هستیم خودمون روی امولاتور یا گوشی شخصی اپ رو نصب کنیم و عین مراحلی که کاربر انجام میده رو ببینیم؛ و با بررسی logcat بالاخره متوجه بشیم قضیه از چه قرار بوده. این هم فقط در شرایطی ممکنه که شما دسترسی مستقیم به کاربر داری و میتونی ازش بپرسی که چه مراحلی رو انجام داده. ممکنه یکی از کاربراتون بیاد توی نظرات اپلیکیشن بنویسه: باز نمیشه! یا کار نمیکنه! و منظورش همین crash کردن نرم افزارتون هست اما شما نمیدونید کجا و در چه شرایطی این مشکل پیش اومده.

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

::github{repo="Ereza/CustomActivityOnCrash"}

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

public static String getExeptionStackTraceAsString(Throwable t{
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw);
t.printStackTrace(pw);
return sw.toString();
}

درصورتی که از Obfuscation استفاده میکنید ممکن هست اطلاعات line code حفظ نشن و اسم کلاسها و متغیرها در stacktrace با سورس کد متفاوت باشن. در این حالت باید از preserveLineNumber و فایلهای mapping استفاده کنید تا بتونید موقعیت خطا در سورس کد رو پیدا کنید.

همچنین مثلا توی NodeJs میتونیم برای گزارش کردن خطاهای پیشبینی نشده کدی شبیه به این بنویسیم:

process.on('uncaughtException', (err) => {
// Perform synchronous logging before exiting with a non-zero code.
process.exit(1);
});

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

مرتب کردن گزارشها

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

در نرم افزارهایی که چندین thread دارن هم، بهتره شماره thread رو به tag اضافه کنیم. در این حالت میتونیم گزارشهارو به یکی از thread ها که برای ما جالب توجهه محدود کنیم.

علاوه بر tag و thread بهتره که verbosity level رو هم مشخص کنیم. معمولا یه عدد هست که نشون میده که هر خط از گزارش ما تا چه حد مفصل و جزئی هست؛ و با توجه به اون در آینده میتونیم گزارشهارو براساس میزان جزئی بودنشون فیلتر کنیم. این به کاهش خطوط گزارش کمک میکنه و باعث میشه بتونیم به جای شروع از خوندن هزاران خط شامل گزارش‌ها ریز و درشت؛ اول از چند خط خلاصه وار شروع کنیم و بعد وارد جزئیاتش بشیم. مثلا در ابتدا تنظیم کنیم که گزارشهایی که verbosity کمتر از 3 دارن رو نشون بده؛ و با دیدن یک مورد غیرعادی در اون مرحله، توی قسمت خاصی که به نظر مشکلدار هست جزئی‌تر بشیم و اطلاعات مفصلتری رو ببینیم.

حریم خصوصی و گزارش‌های دیباگ

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

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

قابلیت غیرفعال کردن و حذف کردن

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

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

نورونهای خودخواه: داستان خودفریبی

Sat, 21 Apr 1404 20:34:16 GMT

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

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

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

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

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

یادگیری بین نسلی

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

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

یادگیری در سطح فرد

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

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

قرارداد لذت و رنج

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

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

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

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

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

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

بیراهه نورونها، خیانت به قرارداد

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

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

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

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

خودفریبی ذاتی

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

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

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

خودشیفتگی

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

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

یک سری از خودفریبیهایی که به ذهنم میرسه و متداول هستن رو در زیر آوردم:

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

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

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

محدود کردن منابع لذت

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

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

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

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

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

درکل اینکه ما موجودات هوشمندی هستیم؛ انگار یک اتفاق غیرمنتظره بوده و واقعا باعث تعجب هست که موفق شدیم در این حد جلو بریم!

اعتیاد یک مهندس به حل مسئله

این که منبع لذت خودم رو محدود به کارهای واقعی کرده بودم خیلی خوب جواب داد و من بعضی روزها حتی 15 ساعت از شبانه روز رو به کدنویسی اختصاص میدادم.

احساس میکردم موفق شدم این چرخه باطل اعتیاد به لذتهای بیخود رو بشکنم. چون هرچیزی که دربارش حس خوب داشتم؛ کدی بود که نوشته شده بود؛ کاری که واقعا انجام شده و مسئله‌ای که حل شده بود.

اما کم‌کم متوجه اتفاق عجیبی شدم که این اواخر حرصم رو درآورده. من به «حل مسئله» معتاد شده بودم.

یعنی برام مهم نبود که آیا این مسئله پیش روی من، آیا باید اولویت الان من باشه یا نه. مثلا پول برام هیچ اهمیتی نداشت و صرفا میخواستم مسئله‌ای سخت و پیچیده جلوی روم باشه و حلش کنم. مهندسی کردن و طراحی راه حل برام حس خوبی داشت. برای همین افتادم توی چرخ باطل از نو نوشتن کدهایی که هزاران نفر قبل از من اونارو نوشته بودن؛ صرفا چون دلم میخواست کل ماجرارو خودم به تنهایی حل کنم و از کسی کمک نگیرم. این حس «خودم تنهایی از پسش براومدم» تا جایی جلو رفت که تلاش کردم یک پیامرسان کامل رو از ابتدا تا انتها کدنویسی کنم؛ که در طول اون پروژه یک json parser و networking library و حتی مبدل تاریخ رو از ابتدا و خودم تنهایی نوشتم. یک دانلودمنیجر از اول ساختم و… و در هیچکدوم این پروژه‌ها حتی یک خط از کدهای دیگران استفاده نکردم!

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

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

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

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

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

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

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

کار میکردم چون به کارم معتاد بودم. از کارم لذت میبردم؛ کار من واقعی بود؛ چیزی که ساخته بودم واقعی بود؛ اما نباید اولویت من میشد. من اولویت بندی بلد نبودم و نمیتونستم با کم و کاستها کنار بیام.

انتخاب کاستیها، نرخ تلفات قابل قبول

این موضوع به نظر خیلی بدیهی میاد؛ اما من خیلی دیر متوجهش شدم:

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

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

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

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

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

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

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

Thu, 19 Apr 1404 20:34:16 GMT

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

راست چین بودن

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

از اونجایی که علاوه بر جهت متن، مفهوم «بعدی» و «قبلی» هم با چینش راست به چپ تغییر میکنه؛ منوها و عناوین و… باید به سمت راست آورده بشن تا برای کاربر ایرانی مانوس جلوه کنن. حتی سایتهایی وجود دارن که کارشون "راست چین" کردن قالبهای آماده خارجی برای نرم افزارهای تحت وب یا اندروید و... هست و سورس راست چین و فارسی شده رو به فروش میرسونن.

البته فارسی تنها زبان راست به چپ در دنیا نیست. برای همین، پشتیبانی از زبان های rtl (راست به چپ یا right to left) یک موضوع تقریبا شناخته شده هست و بیشتر نرم افزارها اخیرا سعی میکنن که این پشتیبانی رو داشته باشن.

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

گاهشماری شمسی

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

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

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

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

گاهشماری قمری

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

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

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

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

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

ساعت بهاری و پاییزی

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

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

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

به جای اینکه اعلام کنیم از فردا مثلا ادارات کارشون رو از ساعت 8 شروع میکنن، اعلام کردیم که از این به بعد ساعت 8 درواقع ساعت 7 هست! و بدتر اینکه همین کار رو هم به شکل منظم انجام ندادیم و چندبار قطع و وصلی داشته.

حتی وقتی این کار به شکل منظم انجام میشد هم مشکلات زیادی وجود داشتن. مثلا در لحظه ای که جلو و عقب کشیدن ساعت انجام میشد؛ ما شاهد تکرار شدن یک ساعت یا وجود نداشتن یک ساعت در یک روز میشدیم. مثلا ساعت 11 تا 12 رو دوبار زندگی میکردیم و روزمون 25 ساعته بود یا ساعت 12 تا 1 اصلا وجود نداشت و شاهد یک روز 23 ساعته بودیم. یادآورها، هشدارها و... در این شرایط نمیدونستن که باید چیکار کنن. حتی در برخی پیامرسانها، وضعیت عجیبی در صفحه چت ایجاد میشد که پیام "بعدی" ساعتش قبل از پیام قبلی بود. مثلا پیامی در ساعت 11:59 ارسال شده بود و طرف مقابل ساعت 11:02 بهش جواب داده بود! حتی به همین علت تراکنشهای بانکی رو هم در اون لحظه تا مدتی مسدود میکردن و امکان انجام کارت به کارت و... وجود نداشت. فرض کنیم وقتی شخص میگفت که من ساعت 11 براتون واریز کردم؛ معلوم نبود که منظور کدوم ساعت 11 هست و این یعنی کارکرد ساعت و تقویم در اون لحظه به کل مختل میشد.

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

قانون نسبیت زمان

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

کدهای متن باز

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

در زیر میتونید کد من رو مشاهده کنید:

::github{repo="AminSarabi/Persian-Date-Java"}

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

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

این بود غر زدن من درباره چالشهای پشتیبانی از کاربر ایرانی در حوزه نرم‌افزار و لزوم تلاش جمعی ما جهت حل و فصل این مسائل (به جز نظریه نسبیت که انگار کاریش نمیشه کرد)

درباره امین سرابی

Thu, 19 Apr 1404 20:34:16 GMT

من امین سرابی، برنامه نویس کامپیوتر متولد سال 1380 و ساکن ایران هستم.

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

همچنین درحال حاضر به عنوان دبیر زبان انگلیسی در وزارت آموزش و پرورش مشغول به کار هستم.

در ادامه چندمورد از شایستگیهای حرفه‌ای خودم رو ذکر میکنم:

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

زبانهای برنامه نویسی:

در طول این هشت سال و در طول کار روی پروژه‌های مختلف به زبانهای برنامه نویسی زیر تسلط پیدا کردم:
Java (اولین زبانی که یاد گرفتم)
JavaScript
Kotlin
C++
Python
Php
Rust
همچنین به html و css هم مسلط هستم.

پلتفرمها و حوزه‌های کاری

برنامه نویسی اندروید
توسعه بکند nodejs
مدیریت سرورهای لینوکسی
توسعه وب (برنامه نویسی وبسایت)
طراحی مدلهای هوش مصنوعی (pytorch)
الکترونیک، رباتیک و برنامه نویسی میکروکنترلرها

برخی از نمونه کارهای من:

اپلیکیشن کنکوری تستامین: در زمانی که کنکوری بودم برای برنامه ریزی و مدیریت مطالعه کنکور خودم اپلیکیشن تستامین رو طراحی کردم؛ که یک پاسخبرگ دیجیتال با زمان‌سنج خودکار بود و آمارهای مفیدی مثل سرعت حل تست در مباحث مختلف، میزان تسلطم روی بخشهای مختلف کتاب درسی، سوالاتی که وقت زیادی ازم گرفته بودن و… رو در اختیارم میگذاشت. این نرم‌افزار رو برای استفاده دیگران هم منتشر کردم. اپلیکیشن تستامین کم‌کم تبدیل به یک پروژه جدی شد و طرفداران خودش رو پیدا کرد. برای مدتی توسعه و پشتیبانی از این نرم‌افزار مسئله اول زندگیم شده بود و بارها بخشهای مختلف تستامین رو از اول نوشتم و چیزهای خیلی زیادی باهاش یاد گرفتم. اپلیکیشن تستامین به دلایل مختلف در اواخر سال 1404 به طور کلی از مارکتهای اندرویدی حذف شد و نسخه جدید اون رو دوباره از اول توسعه دادم و منتشر کردم. (تستامینی که شما الان در بازار/مایکت مشاهده میکنید تعداد نظرات و تعداد دانلودهاش فقط از 1405 به بعد رو شامل میشه)
پیامرسان ریچت: یکی از کارهای قابل توجه من در تستامین، راه‌اندازی یک پیامرسان کامل بود که بعدا به Reychat شناخته شد که برای ارتباط و رقابت درسی بین کنکوریها درنظر گرفته شده بود. من این سیستم پیامرسان رو به تنهایی و بدون استفاده از سرویسهای آماده ایجاد کرده بودم. پیامرسان من از گفتگوی دونفره، کانال و همچنین گروه‌های با هزاران عضو پشتیبانی میکرد و امکاناتی مثل ارسال عکس و پیام صوتی، ویرایش و حذف پیامها، نمایش کاربر درحال تایپ، گزارش تحویل به دستگاه و گزارش خوانده شدن پیام، سابقه چت آفلاین، استفاده همزمان و لاگین از چندین دستگاه، چت رمزنگاری شده و تماس تصویری رو ارائه می‌کرد. بکند و فرانتند پیامرسان رو خودم نوشته بودم؛ بکند پیامرسان من روی یک ماشین مجازی با یک هسته سی‌پی‌یو و دو گیگ رم، از صدها پیام برثانیه و ذخیره دائمی پیامها و فایلهای کاربران تستامین پشتیبانی می‌کرد. همچنین به علت استفاده از CustomViewها در سمت کلاینت اندروید، صفحات پیامرسان من به سرعت رندر میشد و حتی روی دستگاه‌های ضعیف سرعت ۶۰ فریم برثانیه رو حفظ می‌کرد.

در ادامه یک سابقه کوچک از زندگی خودم رو آوردم:

دوران تحصیلات ابتدایی و متوسطه

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

اولین روزهای کدنویسی

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

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

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

آشنایی با یادگیری ماشین و هوش مصنوعی

شاید هرکسی که مدتی با کامپیوترها سر و کله میزنه؛ کم‌کم به این فکر میفته که زبان آدمیزاد یادشون بده. من هم مدتی بدون اینکه درباره “هوش مصنوعی” شنیده باشم؛ درتلاش بودم که به کامپیوتر یاد بدم صحبت کنه و جملات معنی دار و درست بسازه. (میوه‌ها خوردنی هستند. سیب میوه است. پس سیب خوردنی است!) درواقع بدون اینکه متوجه باشم؛ درحال کار روی NLP بودم. البته نیاز به گفتن نداره که موفق نشدم زبان آدمیزاد به کامپیوتر یاد بدم؛ اما این تلاش باعث شد خودم زبان کامپیوتر رو بهتر یاد بگیرم.

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

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

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

شرایط همکاری با من

درصورت تمایل به همکاری با من به موارد زیر حتما توجه کنید:

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

ارتباط با من

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

عنوان	لینک
پیام مستقیم به من	https://aminsarabi.ir/posts/contact
پیامرسان تلگرام	https://t.me/amins7091
ایمیل شخصی	amin7091sarabi@gmail.com

نمونه کدهای من

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

درباره این وبلاگ

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