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

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

یک مثال هم بزنیم. خیلی رایج هست که اشاره میشه عددها به راحتی ما را گمراه می کنند، مثال هم زیاد هست برای این موضوع مثلا کیفیت یک دوربین فقط به تعداد پیکسل های سنسورش نیست بلکه مشخصات دیگه ای هم مهم هست برای مقایسه صحیح و ارزیابی کیفی، یا مثلا ستاره های گیت هاب یک رپو شاخص خوبی برای بی نقض بودن ایده نیست، و مثالی که می خوام کمی بازش کنم درصد مصرف CPU قطعا معیار مناسبی برای سنجش کیفیت و تخصیص منابع در توسعه نرم افزار نیست. مثلا در مقاله زیر به تفصیل توضیح داده شده که نرخ تبادل اطلاعات درون یک سیستم، در وضعیت های مشابهی که 100% cpu درگیر هست چقدر می تونه متفاوت باشه.
https://mazzo.li/posts/fast-pipes.html
یک نکته قابل اجرا هم به پست اضافه کنم. قطعا قبول داریم یکی از نقاط پر هزینه در معماری های فعلی سخت افزار هزینه allocate کردن مموری در پردازش ها هست و هر چی بتونیم این هزینه را کاهش بدیم می تونیم پردازش های مفیدتری با قدرت پردازشی که داریم انجام بدیم. یکی از جاهای مهمی که می تونید با کمترین هزینه توسعه ای به عملکرد و بهره وری بهتری برسید موضوع codec ها هست که با تغییر پروتکل های قدیمی با بهره وری پایین مثل json و SQL با پروتکل های بهتری مثل flat buffers به بهره وری منابع بالاتری دست پیدا کنید.

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

چرا مطالعه و درک صحیح پروتکل ها (RFCs) برای هر #توسعه_دهنده تصمیم سازی به شدت حیاتی هست؟
بنظرم میرسه بهترین روش نشان دادن اهمیت این موضوع، آوردن یک مثال کاملا شفاف هست. پس بیایید یکی از بزرگترین اشتباهات رایج این روزهای توسعه نرم افزار را بررسی کنیم.

زیاد می بینیم متاسفانه که با اشاره به یکسری اطلاعات پر غلط مثل پیشنهادهای مطرح شده در رویکردی معروف به Rest (تز دکترای یک دانشجو) به اشتباه درصد بالایی از اکوسیستم توسعه دهنده نرم افزار بخش هایی از پروتکل آدرس دهی پروتکل HTTP یعنی بخش URL را زیر پا میگذارند و متاسفانه به پیاده سازی خود، صفت #استاندارد را نیز اطلاق می کنند! اشتباه اصلی هم عدم درک صحیح و تفاوت اساسی داده هایی که باید در Path و query parameter ها قرار بگیرد.

برای نمونه وارد سایت #اسنپ_دکتر با این آدرس و این آدرس بشید. بعد از منوی سمت چپ یکی از تایتل های متخصصان موجود یا انواع مشاوره در منوی فیلتر را انتخاب کنید، اگر دقت کنید می بینید که آدرس url مرورگر هیچ تغییری نمی کند، شاید در نگاه اول بگید خوب مشکل خاصی نیست، ولی حال اگر روی یکی از دکترها کلیک کنید و به صفحه مشخصات دکتر برید و مثلا نوبت نداشته باشه یا اشتباه کلیک شده باشه و بخواید برگردید صفحه قبل، اون فیلتر متخصص عملا از بین رفته و باز دوباره کل دکترهای شهر شیراز را به شما نشان میده! خیلی بده، نه؟ تازه بدتر اینکه شما نمی تونید صفحه را با فیلترهای انتخابی با فرد دیگری به اشتراک بگذارید! دلیل واضح هست.
این مورد را در بخشی از جلسات گروه در دیسکورد بررسی کردیم و نشون دادیم عدم تسلط کافی توسعه دهنده های نرم افزار #اسنپ دکتر چجوری داره #تجربه_کاربر بدی را رقم میزنه و مثل اینکه اهمیت یا تمایلی به رفع این مشکل بعد از چند ماه از بررسی ما نبوده که همچنان در زمان نگارش این متن مشکل باقی مانده. مشکلات دیگری نیز این نرم افزار داره مثلا در همین صفحه شما اگر به انتهای صفحه برید که بخواید دکترهای بعدی را ببینید عملا در یک لوپ بی نهایت می افتید که دکترها را به صورت تکراری لود می کنه.
دلایل بوجود اینگونه مشکلات از دید نگارنده دقیقا به دلیل عدم تمایل به رعایت جزییات #علوم_کامپیوتر در توسعه می باشد، همان موضوعات همیشگی که اشاره می کنیم مثلا توسعه دهنده #معماری نرم افزار نمی تواند با توسعه دهنده سرویس و صفحه یکی باشد، چون دانش به شدت متفاوتی برای این دو بخش نیاز هست. البته نه اینکه کامل نشه ولی قطعا هر فردی باید در یک بخش متخصص (کارشناس) و در بخش های دیگر صرفا علاقه مند و در بهترین شرایط صاحب نظر باشه نه بیشتر.
برای روشن شدن بیشتر مثال، آدرس دهی های فعلی و روش صحیح آدرس دهی را در زیر ببینید و کمی تامل و تفکر کنید. در روش صحیح براحتی در گذر زمان اگر قرار به اضافه شدن فیلترهای جدید هم باشد براحتی می تواند بدون هیچ گونه تداخلی آدرس دهی را تکمیل تر کرد.
وضعیت فعلی:
https://snapp.doctor/webapp/appointment/expertsByCity/shiraz/
https://snapp.doctor/speciality/cardiologist/
پیشنهاد:
https://snapp.doctor/doctors?c=shiraz&e=cardiologist&vt=phone (c » city, e » expert, vt » visit type ...)

وضعیت فعلی:
https://snapp.doctor/webapp/Expert/View/63383/
https://snapp.doctor/webapp/appointment/detail?id=86055f1c-497e-487d-9666-5221be2cc07b
پیشنهاد:
https://snapp.doctor/doctor?id=86055f1c-497e-487d-9666-5221be2cc07b

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

پ.ن: برای درک بخش های مختلف هر علم، نیاز به جعبه ابزار کافی به جز موضوعات مطرح شده در هر رشته علمی داریم، و همانطور که در پست قبلی توضیح داده شد، #فلسفه_علم می تونه ابزارهای خوبی به ما در درک کلیات و روش استنتاج (استخراج جزییات از کلیات) بده.

سلام دوستان همونطور که می دونید مطالعه ی مباحث مهندسی نرم افزار کار سخت و زمان بری هست.
خیلی از افراد در طول توسعه ی نرم افزار در حالی از concurrency استفاده می‌کنند که حتی نمی دونندکه باید به optimistic and pessimistic concurrency control توجه کنند.
مارتین در یکی از کتاب‌های خودش به اسم the patterns of enterprise application architecture سعی داره خواننده رو نسبت به انتخاب کلمات حساس نگه داره. این کتاب سنگینه درکش به زمان تجربه و مکالمه با افراد تجربه احتیاج داره.
در سرور جینیسس گروپ شنبه ساعت 4 بعد از ظهر یک ایونت برگزار میکنیم و سعی می‌کنیم یه سری نکات کلیدی در این کتاب رو با هم بررسی کنیم.

سلام دوستان در کتاب implementing domain driven design , نویسنده سعی داره علاوه بر مفاهیم ddd مخاطب رو با معماری ها ی دیگه اشنا کنه در این جا نویسنده سعی داشته با باز کردن یه سری کلمات معماریه SOA رو بهتر بفهمیم . ما توی جلسات بار ها تاکیید میکنیم که افراد حرفه ای به کلمات حساس هستند . این موضوع من رو بر این داشت که قسمتی از کتابی که در حال مطالعش هستم رو با شما دوستان عزیز به اشتراک بزارم.

نویسنده : دلارام

هشدار !!! => این بخشی از صفحه ی ۸۱ تا ۸۶ کتاب patterns of enterprise application architecture هست. دوست داشتم راجب این قسمت هم توی ادامه ی جلساتی که داشتیم صحبت کنیم ولی متأسفانه وقت نشد. حتماً این ۶ صفحه رو خودتون مطالعه کنید که کامل درکش کنید. حتماً تفاوت کلمه ی state و status رو چک کنید بعد شروع کنید به مطالعه … در نهایت دقت کنید که احتیاج هست با نگارش خوده نویسنده آشنا باشید تا درک بهتری داشته از متن داشته باشید.من بیشترسعی کردم درک وخواندن بخش مهمی از این کتاب رو برای شما دوستان عزیز اسون تر کنم .من توی قسمت ways to store session state یکم خسته شدم مطالعه ی دقیق‌تر این قسمت رو به عهده ی خوده خواننده میزارم.

منظور مردم از سرور stateless چیست؟ البته تمام هدف object این است که state (داده) را با رفتار ترکیب می کند. یک object بدون state واقعی، object بدون فیلد است.
وقتی افراد به یک سرور بدون state اشاره می کنند، منظور آنها object است که بین درخواست ها state را حفظ نمی کند. چنین object ممکن است دارای فیلدهایی باشد، اما زمانی که متدی را در یک سرور بدون حالت فراخوانی می کنید، مقادیر فیلدها undefined است.
یک مثال از یک object سرور بدون state ممکن است یک صفحه وب باشد که همه چیز را در مورد یک کتاب به شما می گوید. شما با دسترسی به یک URL، یک call را بر روی آن فراخوانی می‌کنید - object ممکن است یک سند ASP یا یک سرورلت باشد. در URL شما یک شماره ISBN ارائه می کنید که سرور از آن برای تولید پاسخ HTTP استفاده می کند. در طول تعامل، object سرور ممکن است ISBN، عنوان و قیمت کتاب را در فیلدها پنهان کند.
آنها را قبل از تولید HTML از پایگاه داده برمی گرداند. شاید این یک business logic باشد تا مشخص کند کدامcomplementary reviews به کاربر نشان داده شود. با این حال، هنگامی که کار خود را انجام داد، اینvalue ها بی فایده می شوند. ISBN بعدی یک داستان کاملاً جدید است و object سرور احتمالاً برای پاک کردن مقادیر قدیمی برای جلوگیری از اشتباه مجدداً reinitialize می شود.
حال تصور کنید که می‌خواهید تمام ISBN‌های بازدید شده توسط یک آدرس IP که ماله مشتری به‌خصوصی هست را پیگیری کنید. شما می توانید این را در لیستی که توسط object سرور نگهداری می شود نگه دارید.
جابجایی از حالت stateless به stateful خیلی بیشتر از سه یا چهار حرف در انتهای کلمه است.
مشکل اصلی یکی از server resources است. هر object سرور statefull باید تمام state خود را حفظ کند در حالی که منتظر است کاربر یک صفحه وب را بررسی کند. با این حال، یک obejct سرور stateless، می‌تواند درخواست‌های دیگر session ها راprocess کند.

ادامه ی متن بالا :
ما صد نفر داریم که می خواهند درباره کتاب بدانند و رسیدگی به درخواست یک کتاب یک ثانیه طول می کشد. هر نفر هر ده ثانیه یک درخواست می کند و همه درخواست ها کاملاً متعادل هستند. اگر بخواهیم درخواست های کاربر را با یک object سرور stateful پیگیری کنیم ، ما باید یک object سرور برای هر کاربر داشته باشیم: صد object . اما 90 درصد مواقع این object ها دور هم نشسته اند و هیچ کاری انجام نمی دهند. اگر از ردیابی ISBN صرف نظر کنیم و فقط از object سرور stateless برای پاسخ به درخواست ها استفاده کنیم،، می‌توانیم تنها ده obejct سرور را که همیشه به طور کامل به کار گرفته شده‌اند،کار خود را راه بیندازیم (to get away with something). نکته این است که، اگر بین فراخوانی‌های متد state نداشته باشیم، فرقی نمی‌کند که کدام object درخواست را سرویس می‌دهد (which object services the request)، اما اگر state را ذخیره میکنیم ، باید همیشه همان object را دریافت کنیم. statelessness به ما این امکان را می دهد که object های خود را طوری جمع کنیم (pool) که object های کمتری برای هندل کردن کاربران بیشتری داشته باشیم. هر چه تعداد کاربران بی هدف بیشتر باشد، سرورهای state با ارزش تر هستند. همانطور که می توانید تصور کنید، سرورهای stateless در وب سایت های پر ترافیک بسیار مفید هستند. statelessness همچنین به خوبی با وب سازگار است زیرا HTTP یک پروتکل statelessness است.
پس همه چیز باید stateless باشد، درست است؟ خوب، اگر می شد می توانست باشد. مشکل این است که بسیاری از تعاملات مشتری ذاتا stateful هستند. استعاره (metaphor) سبد خرید را در نظر بگیرید که هزاران برنامهe-commerce را رو به جلو میبرد . تعامل کاربر شامل مرور چندین کتاب و انتخاب آنها برای خرید است. سبد خرید باید برای کلsession کاربر به خاطر سپرده شود. اساساً ما یک business transaction stateful داریم که نشان می دهد session باید stateful باشد. اگر فقط به کتاب نگاه کنم و چیزی نخرم، session من stateless است، اما اگر بخرم، stateful است. ما نمی توانیم از state اجتناب کنیم مگر اینکه فقیر بمانیم. در عوض، ما باید تصمیم بگیریم که با آن چه کنیم. خبر خوب این است که ما می توانیم از یک سرورstateless برای اجرای یک session statesful استفاده کنیم. خبر جالب این است که ما ممکن است نخواهیم.
Session State
جزئیات سبد خرید session state است، به این معنی که داده های سبد خرید فقط مربوط به آن sesstion خاص است. این state در یک business transaction است، به این معنی که از سایر session ها و business transaction آنها جدا شده است.
در حالی که مشتری در حال ویرایش یک بیمه نامه است، state فعلی بیمه نامه ممکن است قانونی نباشد. مشتری یک value را تغییر می دهد، از درخواستی برای ارسال آن به سیستم استفاده می کند و سیستم با نشان دادن مقادیر نامعتبر پاسخ می دهد. این value ها بخشی از session state هستند، اما معتبر نیستند. session state اغلب به این صورت است - در حین کار با قوانین اعتبارسنجی مطابقت ندارد. تنها زمانی معتبر می شود کهbusiness transaction کامیت (commit) شود. بزرگترین مشکل با session state، مقابله با isolation است. هنگامی که مشتری در حال ویرایش یک policy است، با تعداد زیادی انگشت در ظرف، چندین اتفاق می‌تواند رخ دهد. واضح ترین آن این است که دو نفر همزمان policy را ویرایش می کنند. اما این فقط تغییرات مستقیم نیست که یک مشکل است. در نظر بگیرید که دو record وجود دارد، خود policy و cutomer record. این policy دارای risk value است که تا حدی به کد پستی موجود در cutomer record بستگی دارد. مشتری با ویرایش policy شروع می‌کند و بعد از ده دقیقه کاری انجام می‌دهد که رکورد مشتری باز می‌شود تا بتواند کد پستی را ببیند. با این حال، در طول این مدت شخص دیگری کد پستی و risk value را تغییر داده است - که منجر بهinconsistence read می شود.
همه داده های نگهداری شده توسط session به عنوان session state به حساب نمی آیند. session ممکن است برخی از داده‌هایی را که واقعاً نیازی به ذخیره بین درخواست‌ها ندارند، اما برای بهبود عملکرد ذخیره می‌شوند، در حافظه cache نگه دارد. از آنجایی که می‌توانید کش را بدون از دست دادن رفتار صحیح ¸ از دست بدهید، این حالت باsession state متفاوت است، که باید بین درخواست‌ها, برای رفتار صحیح ذخیره شود.
Ways To Store Session State

Client Session State (456) stores the data on the client.

Server Session State (458) may be as simple as holding the data in memory between requests.

Database Session State (462) is also server-side storage, but it involves breaking up the data into tables and fields and storing it in the database much as you would store more lasting data.
پیشنهاد مارتین فولر :
My preference is for Server Session State (458), particularly if the memento is stored remotely so it can survive a server crash. I also like Client Session State(456) for session IDs and for session data that’s very small. I don’t like Database Session State (462) unless you need failover and clustering and if you can’t store remote mementos or if isolation between sessions isn’t an issue for you.

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

دو مورد کلمات مشابه که شاید به اشتباه در جای یکدیگر استفاده می شوند، را برای کمی غنا به پست اضافه می کنیم.

- مورد اول زیاد پیش میاد برای همه ما و یکی از اشتباهات رایج مخصوصا در دوستان توسعه دهنده و مخصوصا در صنعت نرم افزار هست، اشتباه در تفسیر دو کلمه #تبیین و #پیش_بینی هست، که در این پست یکی از اساتید عزیز حوزه #فلسفه_علم مفصل توضیح داده است.
https://news.1rj.ru/str/evophilosophy/407

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

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

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

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

- Low code, no code developing frameworks (software developing)
- Unix idea as Everything is files isn't against API pattern
- Cache is one the most important propositions in computer science
- Micro-Servers or Micro-Services? Which one is true naming for the nowadays trend architecture pattern

چرا تعریف #زمان شاید در ذهن خیلی از ماها بدرستی شکل نگرفته است؟
البته این سوال که آیا واقعا زمان وجود دارد شاید یکی از بزرگترین سوال های باز علم فیزیک همچنان هست ولی ما فعلا فرض می گیریم که مفهوم زمان واقعا وجود دارد. برای اینکه بتوانیم زمان را مشخص کنیم ما به دو مفهوم نیاز داریم. یکی مبدا زمان یا Epoch و یکی طول زمان Duration.
- مبدا زمان می تونه هر چیزی باشه ولی عموما به دو نوع ثابت و متغیر تقسیم میشن. ثابت ها چیزهایی هست که در طول روز زیاد ازشون استفاده می کنیم مثل مبعث پیامبر اسلام (هجری شمسی) یا تولد پیامبر مسیحیان (میلادی) یا unix epoch که البته این مورد عموما با استفاده از مبدا میلادی که میشه (00:00:00 UTC on 1 January 1970) محاسبه میشه.
البته که بدلایل کاربردی بودن مبدا های زمانی خیلی زیادی از هر کدام از مبدا های اصلی نشات گرفته مثلا utc یک مبدا میلادی هست ولی بدلیل مکان جغرافیایی آن در زمین که صفر گرینویچ هست و ما انسان ها نیاز داریم با مبدا دیگری که بیشتر باهاش کار داریم که همون مبدا روز و شب هست نزدیک کنیم سعی می کنیم انواع مبدا را بوجود بیاریم، هر چند که نسبت به امکانات کامپیوتری که اینروزا داریم به شکل خنده داری این موضوع ساده انگاری شده است. (مثلا قانون گذارهای حکومت فعلی زمان نگارش این پست در کشور ایران حتی درک درستی از مفهوم و چرایی نزدیک کردن دو مبدا یعنی هجری شمسی به روز و شب و دیگر جوامع ندارند و قوانین به شدت خنده دار هر چند سال یکبار تصویب می کنند)
- مورد دوم هم طول زمان هست، بر اساس پروتکل ثانیه که تعریف مشخص و سفت و سختی هم داره و هر از چند گاهی تغییر می کنه. (گوگل کنید: how is a second measured)
Definition. The second is defined by taking the fixed numerical value of the caesium frequency ∆ν, the unperturbed ground-state hyperfine transition frequency of the caesium 133 atom, to be 9 192 631 770 when expressed in the unit Hz, which is equal to s−1.

در علوم کامپیوتر ما دو مبدا را خیلی زیاد استفاده می کنیم یکی unix و یکی کمتر شناخته شده که monotonic نام داره که استفاده زیادی در جاهای بخصوص زیرساختی مثل مفهوم timer و timing داره. دلیل هم این هست که این مبدا در طول حیات یک سیستم غیر قابل تغییر هست. در linux مبدا آن زمان بوت شدن سخت افزار هست.
A monotonic clock is a time source that won't ever jump forward or backward (due to NTP or Daylight Savings Time updates) and "some unspecified point in the past". On Linux, that point corresponds to the number of seconds that the system has been running since it was booted


خوب از اینجا به بعد می خوایم یکم کتابخانه time زبان برنامه نویسی go را هم به چالش بکشیم. یکی از مشکلات این کتابخانه الحاقی به خود زبان این هست که دو مبدا مختلف یعنی unix و monotonic را با هم یکی کرده و صرفا با یکسری متد پر هزینه به شما اجازه دسترسی به یکسری زمان را میده. چرا میگیم پر هزینه چون اگر شما نیاز به زمان monotonic را داشته باشید عملا این امکان به شما داده نمیشه. مثلا فکر کنید یک ساختار دارید که بعد از گذشت یک زمان خاص expire میشه (مثل captcha های سنتی) خوب برای این حل این نیازمندی شما نباید از زمان هایی با مبدا متغییر مثل unix استفاده کنید چون براحتی با کوچکترین مشکلی در سرور NTP دیتاسنتر یا تغییر اشتباهی دستی زمان سخت افزار برنامه شما با مشکل مواجه میشه و حتی امکان هک سیستم فراهم میشه.

در نهایت خود خوانده می تونه بره کتابخانه time گو را بررسی کنه و مشکلاتی که گفته شد را بخونه.
هر چند هنوز کتابخانه چارچوب توسعه ما برای استفاده به ورژن یک (API stable) نرسیده ولی می تونید در صورت نیاز به مفهوم monotonic ازش استفاده کنید.
https://github.com/GeniusesGroup/libgo/blob/dev/time/monotonic/
دستور اضافه کردن به پروژه
go get github.com/GeniusesGroup/libgo/time/monotonic

Watch how immune cell chases bacteria and eliminates them:

یکی از موضوعات جذاب در توسعه (بدلیل ذات نیازی خود)، مطالعه علوم مختلف هست حتی به صورت بسیار سطحی و تفریحی. یکی از بهترین علوم برای سرگرم بودن و یادگیری همزمان و تقویت ایده پردازی یادگیری #سیستم_پیچیده هایی مثل بدن یک موجود زنده هست.
پیشنهاد می کنم منبع این ویدئو را بوسیله لینک زیر در شبکه اجتماعی لینکدین دنبال کنید تا کلی محتوای جذاب مخصوصا در حوزه علوم شناختی و مغز انسان بدست بیاورید.
https://www.linkedin.com/posts/slava-bobrov_neuroscience-biology-medicine-activity-6964940933205245952-a-7i?utm_source=linkedin_share&utm_medium=member_desktop_web

سلام دوستان من اخیرا کتابی رو در رابطه با معماری خوندم که دوست دارم در یک ایونت مطالبی رو که متوجه شدم با دوستان علاقه مند به اشتراک بزارم.کتاب مد نظر Fundementals of software architecture هست.

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

layered architecture style
pipeline architecture style
microkernel architecture style
service-based architecture style
event driven architecture style
space-based architecture style
orchestration-driven service-oriented architecture

لینک پست مریوطه در لینکدین :‌ https://www.linkedin.com/feed/update/urn:li:activity:6970621902679646209/

مکان برگزاری در اتاق این سرور دیسکورد : https://lnkd.in/ec3d4pjh

———————————
نگارنده : ‌ دلارام

#کامپایل یک نرم افزار برای سخت افزارهای مختلف (#Cross_compiling) پیچیده و نیاز به دقت بالایی داره.
به دلیل تعداد مسایل مختلف در این خصوص در پست های جداگانه به بررسی میپردازیم. این پست به اهمیت به دقت به endianness مرتبط هست. این موضوع بسیار مهمی هست و هر مهندس نرم افزار باید این موضوع و نحوه برخورد باهاش را بدونه، هر چند خواندن و درکش وقت زیادی هم نمیگیره. مخصوصا دوستانی که می خوان از گو در صنعت IoT استفاده کنند خیلی به این موضوع باید دقت کنند. مثل همیشه فقط قصد #تلنگر_ذهنی داریم و خواننده را به مطالعه بیشتر از منابع معتبر موجود هدایت می کنیم.
In computing, endianness is the order or sequence of bytes of a word of digital data in computer memory. Bi-endianness is a feature supported by numerous computer architectures that feature switchable endianness in data fetches and stores or for instruction fetches. Other orderings are generically called middle-endian or mixed-endian.


مثل همیشه بیایم این بررسی را در کتابخانه الحاقی به زبان گو انجام بدیم و ببینیم متاسفانه چرا این کتابخانه به شکل خطرناکی این موضوع را بدون دقت اصلا پاسخ نداده و اگر اشتباها نرم افزاری برای سخت افزارهای big endian کامپایل بشن که از پکیچ binary در توسعه استفاده شده باشه، قطعا به درستی کار نخواهند کرد.
هر چند تصمیم سازان ارشد به صورت قطعی در همان اوایل توسعه گو رد کردن که این موضوع توسط کامپایلر هندل بشه ولی تعجب بسیار هست که چرا در سطح کتابخانه الحاقی همچنان این مشکل حل نشده. و موضوع وقتی خیلی جالب میشه که خود اعضای ارشد گو در جاهای مختلف دیگه به جز رپو اصلی go مثل اینجا مشکل را دیدن و حتی پیشنهادی هم برای حل پکیچ binary دادن ولی دقت کافی از خصوصیات زبان گو مثل فلگ ها نداشتن و بدلیل استفاده از interface که یک موضوع چک شدن در runtime هست که هزینه مقدار کد کامپایل شده را زیاد می کنه و قطعا هزینه startup time نرم افزار را هم زیاد می کنه.

موضوع Bi-endianness موضوع جالبی هست ولی باید دقت کنیم در اکثر راه های موجود (دیگر رپوها موجود در گیت هاب) که چک کردیم اینجوری نیست همزمان هر دو ساپورت بشه و عموما با یک فلگ در زمان استارت سیستم باید مشخص بشه. جالبه بدونیم در لینوکس هم این موضوع بدلیل عدم تکیه بر قابلیت های کامپایلرهای مختلف، به صورت دستی در کدهای خود رپو حل کردند.
در نهایت ما این پکیچ را بازنویسی کردیم که API کاملا مشابه پکیچ در کتابخانه الحاقی به گو را داره، که هر کسی می تونه براحتی فقط import ها را تغییر بده و این مشکل را حل کنه. ما با استفاده از build flag ها موضوع مطرحه را حل کردیم که حجم فایل باینری ایجادی و start up time نرم افزار در بهینه ترین حالت ممکن باشه.
https://github.com/GeniusesGroup/libgo/tree/dev/binary

صوت جلسه امروز را اگر وقت و حوصله ای بود گوش بدید. از یک سوال ساده دوست خوبمون مهدی طهرانی عزیز بدون برنامه ریزی قبلی برگزار شد و در خصوص software orchestration و مفاهیم مورد نظر پیرامونش برای داشتن رویکردهای بهتر در توسعه معماری نرم افزار صحبت کردیم. از اینکه چرا باید به مکان #ناظر در توسعه معماری (یا حتی همه جا) دقت کنیم، و چجوری این موضوعات را با مفاهیمی مثل Unikernel, Cloud, Fog, Edge computing, NoOps ربط بدیم تا بتونیم بهترین تصمیمات را بگیریم. البته قطعا اشاره کنم جلسه محدود بود و در حد یک ساعت صرفا قصد گفتن کلیات را داشتیم نه جزییات زیاد.

راستی روز همه برنامه نویس ها هم مبارک باشه 💐

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

درود به همه مخاطبین گرامی
گاهی اوقات بعد از توسعه یک‌راهکار (چارچوب توسعه)، نیاز هست که اون توسعه برای مدل‌های بیشتر و مشابه، پیاده‌سازی بشه،
به‌عنوان مثال شما عملیات CRUD (Create, Read, Update, Delete) رو برای اکثر دامنه‌هایی که نیاز به نگهداری داده در پایگاه داده رو دارند، پیاده‌سازی می‌کنید. اگر ده‌ها دامنه مشابه رو در دستورکار داشته باشید، بطور حتم، کپی و جایگزین کردن نام دامنه‌ها بهتر از دوباره‌نویسی خواهد بود، اما روش بهتر استفاده از templateها هست،
در لغت template به‌معنی «قالب» و اشاره به نیازمندیِ تکثیر متن هست که در زبان «گو»، درحال‌حاضر در دو قالب text و ‌html توسط پکیج رسمی، ارائه می‌شه،
ویدئو‌یی که ارائه شده، یک تمرین برای پیاده‌سازی این پکیج با تعریف یک سناریوی نمونه هست که امیدوارم مفید باشه،
خوشحال می‌شم اشکالات‌ش رو اشاره کنید و اگر تجربه کار باهاش رو دارید، جهت استفاده علاقه‌مندان، مشارکت بفرمائید.
———————————
نگارنده : ‌ علیرضا مختاری گرکانی

🖤🥀


شرم‌تان باد ای خداوندان قدرت!
بس کنید!
بس کنید از این همه #ظلم و قساوت،
بس کنید!

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

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

دست ها از دست‌‌تان ای سنگ چشمان، بر خداست
گرچه می‌دانم،
آنچه بیداری ندارد،
خواب مرگ بی گناهان است و وجدان شماست!
با تمام اشکهایم، باز، -نومیدانه-
خواهش می‌کنم:
‌
بس کنید!
بس کنید!
فکر مادرهای دلواپس کنید.
رحم بر این غنچه‌های نازک نورس کنید.
بس کنید!


زنده یاد «فریدون مشیری»

#آرزوی همیشگی ما، دستیابی به #آزادی، #صلح و افزایش #کیفیت_زندگی

یادگیری و استفاده از مفاهیم پیرامون OOP در اکثر زبان های برنامه نویسی برای توسعه دهنده ها مفید هست.
همانگونه که در این نظرسنجی (اشاره به اصل abstraction یعنی محدودسازی دسترسی ها) نمود پیدا کرد، اکثریت (74%) مشارکت کنندگان اهمیت وجود قواعد در توسعه را قبول داریم.
به جز چند اصل (principle) پیشنهادی در OOP ، یادگیری و بکارگیری دیگر اصول (همراه با خود 4 اصل معروف به design pattern ها هستند) در توسعه در اکثرا زبان های برنامه نویسی حتی زبان هایی مانند C یا زبان های Functional مثل Erlang، می تونه خیلی کمک کننده باشه. موارد نه خیلی زیاد و نه خیلی کم هستند ولی بعضی ها کمتر شناخته شده هستند مثل object life cycle. باید دقت کنیم اگر سینتکس زبانی انتخابی ما به صورت مستقیم از این مفاهیم پشتیبانی می کند، نباید سعی در پوشش به صورت غیر مستقیم روی بیاوریم. زیاد دیده میشه مثلا در زبانی مثل Go (مخصوصا چارچوب های پرطرفدارش مثل gin و echo) که از روش "متد" پشتیبانی میکنه مفهوم encapsulation به صورت غیر صحیح با توابع ساده و استفاده اشتباه از مفهوم پکیچ، پیاده سازی انجام میشه.
هر چند حتی در زبان هایی مانند C که مستقیم از مفهوم های OOP مثل encapsulation (که عموما با تعریف متد در زبان ها نمود عینی پیدا می کنند) پشتیبانی نمی شود هم می توان به این مهم دست یافت و حتی از قدیم با استفاده از نام گذاری های متفاوتی مانند single responsibility و روش های دیگه وجود داشته اند که سعی در توسعه با خوانایی بالاتر داشتند.

ما به عنوان best practice در توسعه سه متد پیش فرض برای اکثر ساختارهامون در زبان گو تعریف می کنیم و این سه متد Init و Reinit و Deinit هستند، که برگرفته از همین مفهوم object life cycle هست.
- متد Init وظیفه عملیات مقداردهی را دارد. یعنی هر عملیاتی که قبل از فراخوانی دیگر وظیفه ها باید انجام شود.
- متد Reinit وظیفه آماده سازی ساختار برای استفاده مجدد را دارد، مثلا فرض بگیریم هزینه ساخت و مقدار دهی اولیه از نگهداری یک ساختار آماده در یک pool کمتر هست، لذا مصرف این متد فقط محدود به بررسی هزینه مربوطه هست. در خیلی از موارد مشاهده شده بدون بررسی دقیق هزینه دوباره مقدار دهی از هزینه آزادسازی منابع بیشتر هست، چون یادمان باشد ما برای استفاده مجدد حتما مراقب همه سناریوها خرابی فرآیند بدلیل نشتی اطلاعات از فرآیند قبلی باشیم.
- متد Deinit هم وظیفه انجام کارهای باقی ماننده قبل از آزادسازی منابع به عهده دارد.
باید اشاره کنیم این مفهوم object life cycle برگرفته از اصل encapsulation هست که میگه تمام فیلدها و رفتارها یک ساختار باید بتونه با هم در هر جایی منتقل (جابجا) بشه و دسترسی به فیلدها و متدهاش کاملا مشخص باشه. فقط اشاره کنیم اسم هایی که در زیر آمده، در زبان ها و منابع مختلف می تونه متفاوت باشه ولی با توجه به بررسی نگارنده بنظر میرسه بهترین ترکیب استفاده از نام ها این موارد می باشند. و اینکه فرض کنترل مموری با الگوریتم reference counting گذاشته شده ولی قطعا روش های دیگه هم وجود داره و به دید یک نمونه بهش نگاه کنید
allocates » initializes » [increment-reference] » use » [decrement-reference] » [re-initializes» [increment-reference] » use » [decrement-reference]] » de-initializes » de-allocates
یک نکته حائز اهمیت در این حین اینه که اشتباها بخشی از رفتار یک ساختار را با توجه به الگوهای طراحی دیگر مانند factory یا builder یا حتی singleton به تابع هایی خارج از ساختار منتقل می کنند. مثلا موضوع مقدار دهی اولیه بجای بودن در متد Init و فراخوانی توسط تابع New(*DesireStructureName) ،درون این تابع خارج از اسکوپ ساختار، پیاده سازی انجام میشود. این موضوع حتی در کتابخانه های الحاقی و رسمی به زبان هایی مانند Go به وفور دیده میشود که باعث کاهش کیفیت خوانایی کدها می شود. نمود عینی این موضوع در قانون گذاری جوامع انسانی نیز مشاهده می شود. مثلا بجای اصلاح یک قانون مشخص درون پکیچ خود قانون، قانون گذاران بدون توجه به اضافه شدن پیچیدگی های اجرای قانون، اصلاح بخشی را درون یک پکیچ قانونی دیگر انجام می دهند. مثلا نحوه رفتار مالیاتی درون قوانین توسعه ای دوره ای ایران به وفور دیده می شود!

باز مثل همیشه هدف صرفا #تلنگر_ذهنی هست و فقط خواستم یادآوری کنم اگر به اشتباه میگن مثلا زبان Go یا C یا ... یک زبان OOP نیست، تنبلی نکنیم و سعی کنیم در این بخش هم مطالعه کنیم و هم اصول و مفاهیم خوبی که در طی سالیان (بیش از 60 سالش) به واسطه تجربه در دیگر زبان های برنامه نویسی بوجود اومده را با کمی تفکر و تامل درون توسعه استفاده کنیم. و یادمون نره یادگیری این مفاهیم اصلا ربط مستقیم به زبان ها نداره و از منابع معتبر استفاده کنیم.
(ادامه برای ذکر یک مثال در کامنت)

درود خدمت اساتید، همکاران و دوستان عزیز،
«تمرین»‌های یک نوآموز، برای پاسخ‌دادن به نیازمندی توسعه دامنه‌های مشترک (به همراه عملیات CRUD + ولیدیشن + data sanitization) به‌اتمام رسید. این نیازمندی گام صفر جهت توسعه یک وب‌اپلیکیشن erp مالی خواهد بود. سپاسگزار خواهم بود، ایرادات رو مطرح بفرمائید تا اصلاح بشه.
ریپو روی گیت‌هاب، آدرس زیر دردسترس خواهد بود:
github.com/ar-mokhtari/orginfo/
−−−
ویدئوی ۲ تا ۶ هم جهت بررسی اساتید تقدیم می‌شه:
ارادتمند
———————————
نگارنده : ‌ علیرضا مختاری گرکانی

ویدئوهای ۲ تا ۶ - تمرین پیاده‌سازی جنریتور با استفاده از پکیج template گو ...