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 گو ...

مفهوم (رویکرد، الگو) zero allocation به چه چیزی اشاره می کند؟ بدفهمی این رویکرد در کجا نهفته شده است؟
خیلی پیش میاد برای خود من که جاهای مختلف به این مفهوم اشاره بشه، ولی درک درستی از آن وجود نداشته باشه در اون گفت و گو (نمونه)، که منجر به ایجاد انواع خطاها شناختی و در نهایت خطاهای تصمیم سازی می کنه.
اولین اشتباهی که رایج هست این هست که یک بد فهمی زیاد حول دو الگوی zero allocation و Object pool pattern وجود دارد. به صورت لغوی هم اگر بررسی کنیم zero به معنای دقیقا هیچ می باشد نه حتی یک تخصیص. پس قطعا reuse کردن یک مقدار allocate شده (عموما در بخشی به ساختار داده heap) در استفاده های تکراری با نگهداری آدرس مقدار تخصیص داده شده در یک pool را به عنوان zero allocation نباید در نظر گرفته شود. این رویکرد همانطور که در بالا نام برده شد، به نام Object pool pattern شناخته می شود و استفاده از آن شرایط خاصی را طلب می کند. لذا اگر به خوبی مفهوم #memory_management تسلط داشته باشیم براحتی می تونیم این اشتباه (یکی دانستن این دو الگو) را متوجه بشیم. قبلا هم بارها تاکید کردیم که بهتره از تفکرات خوبی که در چندین دهه بوجود آمده استفاده کنیم و از گمانه زنی های بی مورد در خصوص اشاره به مفاهیم قدیمی دوری کنیم. مخصوصا مفاهیمی که حول OOP وجود دارد بدلیل غنای فکری نه به صورت نحوه پیاده سازی در زبان های مدعی، بلکه به استناد مستندات اکثرا دانشگاهی، می توانند مرجع و خوراک فکری خوبی برای ما باشند.
حال چرایی ادعای کذب کتابخانه هایی مثل fasthttp در زبان Go را متوجه می شویم. همین اول بگم سوتفاهم پیش نیاد که این کتابخانه یا زبان بد هستند، اصلا اینجوری نیست و ما نمی خوایم حتی 1% این حس را منتقل کنیم. فقط منظور این هست که استفاده از رویکرد pool در یک کتابخانه مثل همین fasthttp باعث ادعای دروغین zero allocation نباید بشود که گمراهی به همراه بیاورد.
نکته مهم که باید همیشه یادمون باشه که به object life cycle باید دقت کنیم و بدون در نظر گرفتن رویکرد pool به توسعه بپردازیم. چرایی اهمیت این قضیه، باز نمونه عدم دقتش میشه کتابخانه fasthttp که بدلیل allocate کردن زیاد برای یک object که قرار reuse بشه که باعث نیاز به reinit کردن زیاد خواهد داشت. و می دونیم که وقتی allocate های ما زیاد باشه یعنی درگیری بیشتر رم بجای کش های cpu که قطعا باعث افزایش مصرف cpu با نرخ کارکرد پایین به دلیل نیاز مبرم به اجرای دستورات مقداردهی رم. لذا هر چه ما کمتر از runtime memory management استفاده کنیم بهره وری نرم افزار به شدت بالاتر خواهد بود، نه در حد چند درصد بلکه چند صد درصد.
نمونه های زیادی در زبان هایی با کنترل زیاد روی memory management مثل C یا Rust وجود داره ولی عموما در زبان های مثل Go به جز راهکارهای به شدت unsafe به هیچ عنوان امکان پیاده سازی این مفهوم zero allocation وجود ندارد.
https://github.com/rikvdh/zabuffer
https://github.com/nrc/zero/blob/master/src/lib.rs

قطعا می دونیم نمیشه توی یک پست چند خطی همه این موضوعات را باز کنیم و قصد ارائه عمق موارد، مثل همیشه نیست و صرفا #تلنگر_ذهنی و ایجاد پرسش هدف پست ها هست. و قطعا قصد ساده انگاری این موضوع را هم نداریم و می دانیم در نرم افزارهای چند نخ (thread) آن هم در user space قطعا مفاهیمی مثل stack و heap و alloc به شدت پر جزییات تر از این حرف ها، در چند خط هست.
در نهایت بیاییم با استفاده دقیق تر از کلمات، جامعه تخصصی حرفه ای تری را شکل بدهیم که نخواهیم سر پایه ای ترین موضوع یعنی توافق روی معنا و مفهوم کلمات ساعت ها وقت یکدیگر را بگیریم.
هیچ فرصتی را برای مطالعه حتی روی کلماتی که فکر می کنیم خیلی بدیهی هستند را از دست ندهیم. (تلنگر قوی حتی به خودم)

آیا Low code, no code developing frameworks (software developing) یک ضرورت هست یا انتخاب؟

جواب خیلی کوتاه قطعا یک ضرورت. و خیلی خلاصه بخوایم بگیم توسعه بدون چارچوب اصلا امکان پذیر نمی باشد و چارچوبی خوب هست که نیاز توسعه ای اصلی (کسب و کاری) را به طور کامل پوشش دهد و انتخاب ها را تا حد ممکن محدود کند. مثلا در علوم کامپیوتر بحث انتخاب نحوه کد گزاری داده ها برای انتقال بین کامپیوترها در شبکه، می تواند شامل صدها گزینه باشد، ولی چارچوب توسعه ای خوب هست که توسعه دهنده بیزینس را به هیچ عنوان درگیر این انتخاب نکند. وقتی محدودیتی وجود دارد باز با هوشمندی عمل کند. مثلا وقتی در حال ساخت SDK برای زبانی خاص هست که از codec مورد نظر پشتیبانی نمی کند خودش بهترین گزینه را انتخاب کند.
باید اشاره شود دو عبارت Low code, no code اصلا چیزهای جدیدی نیستند و برعکس ایده های خیلی قدیمی هستند ولی بدلیل ارتقا نیازمندی ها و عدم ارتقا آن ابزارها ما عملا چندین سال اسمی از این مفاهیم را نشنیده ایم. در نظر بگیریم این دو عبارت ذاتا مسئله مهم جداسازی در توسعه به بخش های کوچک تر را شامل میشه. یعنی یک سازمان دغدغه توسعه نیازمندی های خودش را داشته باشه و سازمانی دیگر (یا تیمی دیگر در سازمان) چارچوب های توسعه را برایش فراهم کند. لذا مثل همیشه با دقت به تک تک کلمات می تونیم به اهمیت و قطعیت نیاز به چارچوب توسعه (framework) اشاره کنیم. این موضوع محدود به علوم و مهندسی کامپیوتر هم نیست، در اکثر صنایع این مهم وجود داره. مثلا چارچوب توسعه یک کارخانه تولید سیمان یا آهن نیز از توسعه واقعی خود کارخانه موضوعی کاملا جدا می باشد.

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

رویکرد قدیم در توسعه نرم افزار در بخش هایی مانند شبکه پنهان کردن پیچیدگی ها بوده است ولی رویکرد صحیح و بهتر قطعا شناخت و انتخاب فرآیندها بر اساس نیاز می باشد. به طور مثال در پروتکل ALTO به طور مشخص به همین بحث نیاز به عدم پنهان سازی جزییات شبکه از لایه اپلیکیشن ورود کرده و باعث ایجاد گفتمان های نه چندان قوی در اکوسیستم شده است.
Specifically, in today's networks, network information such as network topologies, link availability, routing policies, and path costs are hidden from the application layer, and many applications benefited from such hiding of network complexity. However, new applications, such as application-layer overlays, can benefit from information about the underlying network infrastructure.
هر چند به این پروتکل ALTO نقدهای جدی وارد هست مثلا تصمیم به گره زدن یک پروتکل سطح پایین به کدکی مانند json رفتار به شدت عجیبی هست، در حالی که قطعا سرویس های این پروتکل پس از نهایی شدن RFC بدون تغییر خواهند بود حتی استفاده از پروتکل هایی مانند protobuf نیز بهینه نیست و بهتر از کدک های ثابت همانند option های پروتکل های قدیمی مثل IP و TCP یا فریم های QUIC استفاده شوند.