#طراحی یا #مهندسی !؟ مساله این است!

#تفکر_طراحی / #تفکر_مهندسی / #طراح (Designer) / #مهندس (Engineer) / طراحی مهندسی (Engineering design) / طراحی صنعتی (Industrial design) / ...
بدلیل بسیار بزرگ بودن این موضوع من صرفا به دادن چند کلمه کلیدی بالا بسنده می کنم و در ادامه صرفا دلیل اهمیت را بیان می کنم. باشد که اندیشمندان عزیزی که این پست را می خوانند بتوانند به اهمیت موضوع برسند و برای درک بهتر این کلمات و شکل گیری ذهن خود بیشتر تفکر و تامل کنند. و چون این تعریف از هنری پتروسکی نویسنده‌ی سرشناس حوزه‌ی طراحی و مهندسی با کتاب معروف "مهندسی انسان: نقش شکست در موفقیت طراحی مهندسی" در باب این دو کلمه را بنظرم جالب بود اینجا میارم، که جمله‌ی ساده و شفافی را برای بیان تفاوت میان این‌دو به کار می‌برد: طراحی، آن‌چه را نیست به وجود می‌آورد و مهندسی، آن‌چه را هست، یک گام بهبود می‌دهد.

اینقدر تفاوت این موضوعات مهم هست که هر چی صحبت بشه در موردش کم هست. #نکته مهم این هست که یادمون باشه برای درک بهتر این کلمات و ارتباط دادن به حوزه علمی که درش فعال هستیم، اگر در اون علم مثل علوم کامپیوتر که پیشینه عمیقی وجود نداشت، می تونیم از دیگر علوم کمک بگیریم و ارتباط معنادار بین علوم پیدا کنیم. مثلا در طراحی رابط کاربر نرم افزارهای کامپیوتری (software user interface) عمق علم تولید شده واقعا زیاد نیست ولی می تونیم با مراجعه به علم طراحی مخصوصا در بخش طراحی صنعتی کلی زاویه دید جدید پیدا کنیم. مثلا موضوع مهم #کهنه_شوندگی (عمدی یا مصنوعی) و ارتباط آن با مفهوم فرسودگی در دنیای واقعی و تاثیر آن بر طراحی خیلی در کامپیوتر نه بررسی شده و نه مطرح هست، ولی در علم طراحی صنعتی کلی صحبت آکادمیک حولش شکل گرفته. مطلب فارسی زیادی در این خصوص متاسفانه در دسترس نیست و صرفا من در یکی از جلسات uxshiraz یادم هست این موضوع توسط یکی از اساتید دانشکده هنر (طراحی صنعتی) دانشگاه شیراز مطرح شد. ولی می تونید با کلمه کلیدی artificial aging software به مطالب جالبی برسید.

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

بسیاری از متخصصان حوزه ی #امنیت نگران فراگیریه مفاهیم (قدیمی تر) مانند PaaS, SaaS و (کمی جدیدتر) low code / no code در توسعه نرم افزار ها هستند. تحقیقات نشون داده که شرکت ها کمبود بسیاری در دید کنترل و دانش لازم برای برآورد کردن امنیت در نرم افزار(های) سازمانی دارند. چند مورد از مشکلاتی که این اپلیکیشن ها فراهم می کنند را در ادامه ی مطلب که برگرفته از این مقاله هست، براتون فراهم کنم:
- هیچ نظارتی مبنی بر اینکه نرم افزارهای برون سپاری شده چجوری به داده های ما دسترسی پیدا می کنند وجود نداره .
- اعتماد کردن واقعا مسئله ی مهمیه. اگه بخواهیم اینجا تست امنیتی رو در نظر بگیریم نرم افزارها های pro-code معمولا با ابزار های اسکن و config به عنوان بخشی از ci/cd ساخته میشوند و این مسئله واقعا بسته به اینکه شما چقدر روی دادها سازمان خود حساس هستید میتونه برای نرم افزار و سازمان شما آسیب زا باشه.
- ما اصلا نمی دونیم چجوری این آسیب پذیری ها رو در نرم افزارهای برون سپاری شده چک کنیم . مسلما شما نمی تونید امنیت کدی که بهش دسترسی ندارید رو حفظ کنید. (یا چک کنید)
- با بوجود اومدن مفاهیمی مثل platform as a service / kubernetes / serverless functions نگرانی های زیادی در باب کنترل ، امنیت و ‌مشاهده ی داده بوجود اومده.
درک مشکلاتی که توسعه بر پایه نرم افزارهای low code / no code به همراه خودشون میارن اولین قدمی هست که ما باید برداریم. برای ارائه ی راه حل های جایگزین احتیاج هست کار کردن با "داده" رو یاد بگیریم و سعی کنیم به درک بالایی از داده برسیم. شرکت ها در مراحل متفاوتی از توسعه ی نرم افزارها، نیازمندی به control , visibility و necessary knowledge رو در جریان داده های خودشون درک می کنند. امیدواریم یکی از افراد اون سازمان خواننده ی این پست باشه.

درصدد رفع این مشکل و بدست آوردن این علم در توسعه ی این ابزار ها و درک کافی در کار با #داده لازم دیدیم جلساتی مبنی بر عنوان "data governance" را در کنار همه ی توسعه دهندگان نرم افزار (برنامه نویسان در حوزه ی IT) داشته باشیم تا بتونیم در درجه ی اول سوالات صحیحی رو در طی توسعه ی نرم افزار بپرسیم و در درجه ی دوم توانایی پاسخ به اون نیازمندی ها رو در خودمون ایجاد کنیم. در اولین سری این جلسات به بررسی کتاب با نام مشابه یعنی data governance: The Definitive Guide: People, Processes, and Tools می پردازیم.

راوی: دلارام غلام پور سقا
زمان: اولین جلسه شنبه سه اردیبهشت در سرور دیسکورد گروه توسعه برگزار میشه و جلسات بعدی در ایونت مربوطه در همان سرور دیسکورد به اطلاع علاقه مندان میرسه

تو این پست می خوایم جزییات بیشتری از لایه storage توسعه #نرم_افزار های کامپیوتری یعنی جایی که داده هایی داریم که برامون مهم هستند و هر زمان نیاز شد باید بتونیم با کمترین هزینه بهشون دسترسی پیدا کنیم و حفاظت از این داده ها نیاز به اخذ کلی تصمیمات مهمی برای هر سازمانی داره.

اول بیایم درباره یک #افسانه صحبت کنیم که زیاد هم استفاده میشه. افسانه چیزی نیست جز #داده بدون ساختار یا schemaless. در ماهیت مفهوم، اشکالی نیست و میشه به داده های متنی یا داده هایی مثل محتوای وب (html) گفت داده بدون ساختار ولی مشکل جاهایی هست که عموما استفاده میشه، یعنی برای برچسب زدن به داده ها و ابزارهای لایه storage! زیاد می بینیم اشتباها میگن مثلا از mongodb استفاده کنیم چون داده هامون ساختار مشخصی ندارن! اونجا اشتباه داریم فکر می کنیم و قطعا ساختارهای داده ای ما در لایه storage مشخص هستند و صرفا ابزارهای به اصطلاح NO-SQL(Not Only SQL) نیازی به دانستن schema داده های ما برای فراهم کردن امکانات ذخیره سازی نیستند ولی به معنای این هست که قطعا یک لایه دیگر در نرم افزار باید ساختار را بدونه تا بتونه باهاش ون کار کنه. پس با تفکر به این ابزارها نگاه کنیم و سعی نکنیم خودمونو گول بزنیم و بدونیم تغییر schema در لایه storage قطعا هزینه داره و نباید فکر کنیم این تغییر کم هزینه هست. سعی کنیم در طراحی دامنه های سرویس ها دقت کافی را داشته باشیم تا نیاز کمتری به تغییر داشته باشیم.

پس از افسانه schemaless حالا می تونیم افسانه دوم یعنی پاسخگویی بهتر با ایجاد کپی از داده ها با رویکرد secondary replica databases یا secondary database servers را بررسی کنیم. خلاصه که این نحو پاسخگویی به نیازمندی "عدم توانایی پاسخگویی یک نود نرم افزار (مسئول نگهداری بخشی از داده های نرم افزار) به درخواست های کاربران" به مشکل، نیز یک رویکرد غیر هوشمند و قدیمی و بدون یکپارچگی در تصمیمات #معماری_نرم_افزار هست و تا جای امکان باید توسط راهکاری های هوشمند تر cache مخصوصا کش لبه Edge caching (اگر کمی گوگل کنید می بینید ترند امروز و آینده توسعه نرم افزار هست) جایگزین بشه. رویکرد نگهداری چند نسخه بدون هدف مشخص داده ها توسط تیم اجرایی خیلی غیر بهینه هست و هزینه اضافه (در توسعه و نگهداری) به سازمان وارد می کنه. البته برای رسیدن به کش هوشمند نیاز هست رویکرد لایه storage در توسعه تغییر کنه و کمی جزییات بیشتری در این لایه درون نرم افزار سازمان هندل بشه مخصوصا اگر نیازمندی لایه ذخیره سازی بلند مدت داده با کمک نرم افزارهای دیگه مانند DBMS ها انجام میشه. البته باز باید اشاره کنیم رویکرد کتابخانه محور بودن برای رفع نیازمندی ها در بلند مدت به شدت بهینه تر می باشد هر چند کمی درک توسعه معماری را برای متخصصان بدون دانش کافی، سخت می کنه.
باید یادآوری کنم که پایه ای ترین نیازمندی لایه ذخیره ساز همیشه (طبق معماری فعلی سخت افزارها) ذخیره به صورت کلید/مقدار key/value هست و اگر سازمانی بتونه بهتره این نیازمندی درون کل معماری و پیاده سازی نرم افزار الحاق بشه نه به صورت ابزارها و نرم افزارهای مستقل. این رویکرد خیلی وقت هست توسط شرکت های بزرگ داره استفاده میشه و نشانه هاش هم متن باز کردن کتابخانه هایی مانند rocksdb vs leveldb هست. سعی می کنیم در یک یا چند جلسه در دیسکورد بیشتر راجب به این موضوع صحبت کنیم.

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

#تغییرات، #نسخه (version) جدید یا #ماهیت (Quiddity) جدید؟
یکی از موضوعات مورد اختلاف نسبتا زیاد در همه علوم نحوه برخورد با تغییرات هست. مثلا تا چه حد اگر ماهیت یا هویتی که به نام #انسان می شناسیم، تغییر کرد اجازه داریم همچنان از کلمه انسان برای خطاب قرار دادن آن ماهیت استفاده کنیم؟ یا مثلا شرکت بنز تا چه حد تغییراتی به خودروی مدل S500 خود می تواند این نام را برای نسخه های جدید آن استفاده کند؟ مثال زیاد هست با کمی تفکر خودتون می تونید مثال بسازید.

این موضوع در #علم_کامپیوتر هم مطرح هست، ولی بدلیل کمبود گفتمان پیرامون نحوه برخورد با این موضوع برای اعضای اکوسیستم، موضوع شفاف نیست. معیار تغییرات برای نسخه جدید چی باید باشه و چه زمانی باید دست از استفاده از مفهوم نسخه برداریم و بگیم با ماهیت جدیدی روبرو هستیم که صرفا در صورت نیاز باید ارتباطی بین ماهیت های مختلف ایجاد کنیم.
واقعا موضوع پیچیدگی خاص خود را دارد و نباید براحتی از کنار این موضوع بگذریم. اشتباهات رایج زیادی هم در برخورد با موضوع تغییر وجود داره. مثلا همه فکر می کنند پروتکل semantic versioning را اگر رعایت کنند تمام جزییات حل شده است. مثلا با برخورد با تغییر Major version می بینیم که براحتی با بالا بردن یک یا چند شماره از نسخه 1 به 3 کل نرم افزار، سرویس ها، صفحات، ... تغییرات بنیادی کرده است. عدم دقت به Software Release Life Cycle ها در سطح کل نرم افزار و هم در سطح بخش های مختلف که به شدت مورد غفلت قرار میگیره در معماری و توسعه هم مشکلات خیلی زیادی برای هر سازمانی خواهد داشت. پیشنهاد می کنم در صورت تغییر در سطح ساختار های داده ای (سرویس ها و صفحات) که به اسم API changes می شناسیم دقیق تر بررسی کنید که آیا واقعا این تغییرات باعث ایجاد ماهیت جدید نشده است؟ عموما جواب این سوال بله است. لذا بهتره آن بخش را دست نخورده باقی بگذارید و سعی در ایجاد و تعریف ماهیت جدید در جای دیگر (دامنه دیگر) داشته باشید.

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

version: something a little different from others of the same type

در سری نشست های بررسی مفاهیم یک #کتاب، اینبار راوی گروه سراغ کتابی در موضوع مهم و چالش برانگیز با عنوان Learning Domain-Driven Design رفته و می خواد عصاره و خلاصه ای از آن را به ما در چند ساعت انتقال بده. متن زیر هم پست خودش در لینکدین هست:

در توسعه ی نرم افزار افرادی رو میبینیم که در به اشتراک گذاشتن کوچکترین مفاهیم در بین اعضای تیم IT مشکل دارند. افراد، در حالی در مورد پیاده سازی صحبت می کنند که هیچ توافقی توی راه حل ( solution) با هم دیگه ندارند . و در نهایت اون باگی که در production ایجاد میشه حاصل سو تفاهم ها از کلمات ساده ای هست که یک فرد به تنهایی مسئول توصیف اون رو به عهده گرفته.
شنبه ساعت ۶ بعد از ظهر در سرور جینیسس گروپ بیشتر در مورد جزییات domain driven design صحبت می کنیم. مایلم با هم افزایی دوستان در این جلسات بیشتر در مورد پروژه ی art-record و چالش هایی که در جدا سازی دامنه هاش داریم با هم صحبت کنیم.

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

آیا تقسیم #توسعه و #تیم_سازی یا صفت دهی به متخصص های حوزه توسعه نرم افزار با کلمات #بک_اند و #فرانت_اند صحیح می باشد؟

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

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

مثل همیشه صرفا قصد ایجاد یک تلنگر ذهنی را داریم و از باز کردن زیاد جزییات پرهیز می کنیم. و انتقال بینش برای تصمیم سازی را کافی می دانیم و هر تصمیم ساز را مختار در تصمیم گیری می دانیم.
در نهایت بنظر میرسه همانطور که همیشه انتخاب بهتر تیم ها و سازمان ها این بوده که بخش توسعه و کار روی لایه storage توسط متخصص هایی انجام بشه که دید قوی مهندسی نرم افزار دارند، بهتره بخش ساختار محتوا و نمایش محتوا (همون html, css در وب) را به متخصص های خودش واگذار بشه و توسعه دهنده های منطق، توسعه منطق سرویس ها و صفحات را انجام بدهند. به همین دلیل بنظر میرسه تفکر سنتی یعنی تقسیم بندی توسعه دهنده ها به بک اند و فرانت اند صحیحی نبوده و بهتره با تفکر بیشتری این روش تقسیم بندی و تصمیم گیری بظاهر بد را در تیم ها و سازمان های خود اصلاح کنیم.

چرا دانستن تفاوت های #علم، #شبه_علم و #ناعلم مهم هست؟
یا چرا مطالعه #فلسفه_علم بر هر خردمند، دانشمند و ... واجب هست؟
حتما خیلی شنیدین که میگن مهارت های نرم خیلی مواقع مهم تر از مهارت سخت (مهارت های یک رشته خاص علمی) هست، دقیقا به همین دلیل مطالعه علوم مرتبط با #فلسفه_علم مهم هست. چون به خود علم را یاد میده، نحوه خوندن و یاد گرفتنش را یاد میده و یاد میده که چجوری باید وقتی مطلبی با ادعای علمی را می خونیم بتونیم جزییات مختلف را ازش استنتاج (جزییات را از کلیات مطرح شده استخراج) کنیم و جلوی انواع خطاهای شناختی را بگیریم.
یکی از اهداف دیگه مطالعه #فلسفه_علم این هست که اگر نمی خوایم فقط مصرف کننده علم باشیم و دوست داریم بتونیم در فرآیند توسعه خود علم هم کمکی هر چند بسیار کوچک داشته باشیم باید مجهز به ابزارهای لازم بشیم که یکی از مهمترین هاش همین داشتن دانش و درک فلسفه علم هست.
شاید جالب باشه که بدونیم چرا در مقاطع لیسانس و فوق لیسانس به کار و مطالعه علمی دانشجو میگیم #پایان_نامه ولی در مقطع 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