#پروژه_تیمی

نیازمندی:
توسعه چارچوب قوی و کامل شامل قراردادهای توسعه #GUI در زبان گو با کمک کامل از اکوسیستم #وب. جزییات اینکار در جلسات به مفصل گفته خواهد شد.
این دومین پروژه تیمی گروه خواهد بود که پس از موفقیت های گردهم آوردن افرادی متخصص برای پیاده سازی پروتکل IP/TCP از صفر درون userspace و دور زدن کامل سیستم عامل برای هندل کردن این دو پروتکل، برنامه ریزی می شود.
انتظارات:
🔸تسلط نسبی به اصول کارکرد و پروتکل های وب (API ها) و مرورگرها
🔸آشنایی اولیه به زبان GO که optional هست یعنی اصلا بلد هم نبودید مهم نیست. در طول مسیر قطعا هم آشنا میشید و هم علاقه مند به یادگیری بیشتر این زبان
اطلاعات تکمیلی:
🔸قصد کامل استفاده از ظرفیت پروتکل های وب وجود داره و عملا ما دو بخش HTML و CSS را کاملا در توسعه دخیل خواهیم کرد. صرفا منطق اپ بجای js در go توسعه داده خواهد شد. هر چند ممکنه به صورت مستقیم API ها وب به صورت دست خورده انتقال داده شود.
🔸این پروژه در سه فاز پیاده سازی خواهد شد. اولین فاز پس از تکمیل پروتکل ها، نرم افزارهایی که با این پروتکل ها توسعه داده می شود با کامپایل کدهای go به js مستقیم در مرورگر اجرا خواهند شد. در دو فاز بعد کامپایل و اجرای مستقیم کدها با زبان گو با توسعه کتابخانه مورد نیاز با ارتباط مستقیم با سیستم عامل ها با||بدون نیاز به پیاده سازی engine اختصاصی در دستور کار می باشد.
زمان انجام پروژه:
🔸پیش بینی می شود از زمان شروع فاز اول، حداکثر 6 ماه کار توسعه با حداقل یک جلسه دو ساعته در ماه طول خواهد کشید.

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

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

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

#هاینریش_بل
نویسنده‌ی شهیر آلمانی
برنده نوبل ادبیات ۱۹۷۲

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

#نکته #معماری_نرم_افزار
سوال: ابزارهای زیادی برای پوشش نیازمندی های لایه storage نرم افزار وجود داره، چجوری انتخاب صحیحی داشته باشیم؟
برای پاسخ به این سوال باید ما علاوه بر بررسی مواردی که در پست reply شده این پست هست، جواب سوالات زیر را بدیم. یعنی کلا اول نباید بریم سراغ انتخاب ابزار یا حتی بررسی شباهت ها و تفاوت های آنها، اول باید ببینیم نیازمندی واقعی ما چی هست و رویکرد ما در مواجه با نیازمندی چجوری باید باشه.
- آیا توسعه نرم افزار برای این بیزینس باید با رویکرد توزیع شده در سطح معماری باشه؟ (عموما جواب بله هست اینروزا و رویکرد جداسازی بک/فرانت انتخاب میشه که یک رویکرد توزیع شده هست)
- آیا در بخش بک اند ما به رویکرد توزیع شده (multi node) نیاز داریم یا خیر؟ (همیشه جواب بله نخواهد بود، فکر کنید دارید یک نرم افزار برای یک کاسب محلی بدون هیچ برنامه ای برای گسترش کسب و کار توسعه میدید)
- اگر جواب سوال قبل خیر هست و پیش بینی تولید زیادی داده در طول عمر اون کسب و کار نداریم، به شدت پیشنهاد میشه ابزارهای عمومی و ساده را برای تمام نیازمندی های لایه storage انتخاب کنیم. اولین پیشنهاد این هست که یک کتابخانه ساده الحاقی (embeded storage engine) استفاده کنیم که بتونه API های مورد نیاز ما را پوشش بده، اگر کتابخانه ای را در زبان برنامه نویسی انتخابی خود پیدا نکردیم، بعدش باید بریم سراغ ابزارها یا بهتره بگیم نرم افزارهای تک منظوره عمومی دیگر، مثلا mysql که خودمون(فرد یا سازمان) تسلط بهتری روش داریم. به راحتی هر نیازمندی را می تونیم باهاش پاسخ بدیم. وقتی میگیم هر نیازمندی، یعنی رویکردهایی مثل key/value یا object storage یا time series یا داده های ساختارمند را اکثرا براحتی پوشش میدن.
- ولی اگر جواب سوال قبل بله هست موارد بیشتری را باید به صورت جزیی تر بررسی کنیم و مورد نظر قرار بدیم:

- باید شناخت کافی از داده هایی که در لایه storage می خوایم ذخیره سازی کنیم پیدا کنیم و بررسی کنیم لایه storage تا چه حد باید ساختار داده ما را بدونه. یعنی به عنوان پایه ترین ساختار آیا k/v را بدونه کافی هست؟ یا مثلا اگر فکر می کنیم ذات یک ساختار time series هست آیا واقعا لایه storage نیاز هست از این موضوع اطلاع داشته باشه یا ما باید در لایه لاجیک خودمون موضوع را هندل کنیم و در نهایت لایه storage ما فقط به صورت object به کل داده زمانی ما نگاه می کنه و مثلا به صورت روزانه آن را ذخیره می کنیم.
- باز مثل مورد قبل باید بررسی کنیم ببینیم کتابخانه ای لایه storage وجود داره که بتونه در ساختار توزیع شده به ما API های مورد نیازمون را بده یا نه، اگر نبود، بعد باید بریم سراغ نرم افزارهای تک منظوره مستقل و بررسی جزییات آنها که ببینیم نیاز ما را پوشش میدن یا خیر.
- نکات ریز در این بخش زیاد داریم مثلا اگر با داده زمانی طرف هستیم باید دقت کنیم که اگر نحوه اخذ اطلاعات روی یک رکورد وابسته به زمان هست رفتار آن ابزار هم مشابه باشه و نیاد ورژن های زمانی یک رکورد را در نودهای مختلف خود ذخیره سازی کنه.

در نهایت مهمترین نکته ای که باید بهش توجه کنیم تا جایی که میشه نیازمندی را به صورت کتابخانه پوشش بدیم نه یک نرم افزار جداگانه. چون نرم افزار جداگانه یعنی هزینه خیلی بیشتر و مصرف انرژی (در توسعه و اجرا) بیشتر برای هیچ و با رجوع به فرهنگ بسیار غنی ژاپنی ها این کار مغایر تفکر و فرهنگ #Lean هست.

#نکته
در باب اهمیت دادن به #داده مخصوصا در همان ابتدای امر توسعه یعنی در توسعه یا انتخاب #معماری_نرم_افزار هر چی بگیم کم گفتیم و هر چی مطالعه کنیم کم بوده. موضوعاتی که قبلا بهشون تاکید کردیم در خصوص اهمیت به اعتبار یک داده در طول زمان (time series data) و امکان تغییر حالت یک داده در طول زمان بود و بیشتر مثال هایی که زده شد از جنس داده های ساده (غیر گراف) بود ولی باید اشاره کنیم برای داده هایی از مدل و جنس گراف هم موضوع اعتبار در طول زمان مطرح هست، که در بخش یال ها (edge) که ارتباط دو گره (node) را مشخص می کنند، می توان در طول زمان تغییر کنند.
مثلا فکر کنید در شبکه اجتماعی لینکدین شما با یک دوست جدید کانکشن ایجاد می کنید این باعث تغییر در یال های ارتباط شما با دوستان دوست جدید شما می شود. یعنی قبلا اگر فردی با شما هیچ ارتباط دوست درجه سوم نداشت، حالا این یال شکل میگیره ولی اگر شما ارتباطتون را با اون دوست مشترک قطع کنید، این ارتباط درجه سومی از بین میره ولی باعث نمیشه اون بازه زمانی ارتباط شما از بین بره و صرفا باعث میشه شما مثلا به دوست درجه پنچم با آن فرد تغییر کنید.
باید اشاره کنیم داده های گراف صرفا محدود به شبکه های اجتماعی نمیشن و در صنایع و بخش های دیگر اجتماع های انسانی کاربرد خودشون را دارند. و با اضافه کردن مفهوم اعتبار زمانی به داده های گراف می تونیم کلی ایده پردازی های باحالی داشته باشیم که منجر به پاسخگویی نیازمندی های زیادی مخصوصا در حوزه های امنیت مثل fraud detection بشه، که عزیزانی که در صنایعی مثل صنعت مالی هستند خیلی خوب درک می کنند که چقدر نیاز داریم به این مدل اطلاعات.

پ.ن:
- برای تکمیل صحبت های قبلی در باب اهمیت داده های سری زمانی (time series data)، پیشنهاد می کنم برای درک بیشتر و استفاده از این مفهوم در توسعه دو مقاله در اینجا و اینجا را مطالعه کنید. می تونید حمیدرضا را هم در لینکدین دنبال کنید، که یکی از فعالان خوب حوزه داده و هوش مصنوعی هست که پست هاش غنای علمی خیلی خوبی داره.
- موضوعات مطرحه در این سری پست ها ارتباط مستقیمی به گرایش های #علوم_کامپیوتر و #مهندسی_کامپیوتر در گرایش #مهندسی_داده داره که می تونید با گوگل به جزییات بیشتری برسید. مثلا برای درک داده های گراف باید بخش ریاضی و علوم کامپیوتر مغز خودتون را اتقا بدید که متاسفانه هیچ راه میانبری به جز مطالعه نداره.
- پیشنهاد می کنم اگر تابحال friendship cycle را گوگل نکردید حتما اینکارو انجام بدید و دید خودتون را نسبت به اجتماع های انسانی و نحوه شکل دهی دوستان خود تغییر بدید. جالبه بدونید در زبان عربی ۱۲ لایه دوستی براش کلمه وجود داره! جالبه بدونید عدد 500 لینکدین برای حداکثر تعداد connection ها عدد علمی هست که دقیقا برگرفته از همین موضوع هست.
- و شاید براتون جالب باشه که بدونید یک نظریه به اسم شش درجه جدایی داریم که میگه در دنیا اگر دو انسان را انتخاب کنیم، قطعا با 6 یا کمتر درجه می تونیم بین اونها ارتباط دوستی پیدا کنیم! جالب نیست؟! خیلی ها وقت خودمون هم میگیم چقدر دنیا کوچیکه، و این جمله خودش شده شروع یک نظریه!

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

نمی خوام زیاد حس و حال پست و گروه توسعه را به سمت علوم کامپیوتر سوق بدم ولی فعلا فکر می کنم بهتره از باب علوم کامپیوتر و بخصوص توسعه نرم افزار به این پرسش پاسخ بدیم فعلا و بعدا در پست های دیگری از دید علوم دیگر بهش نگاه کنیم و پاسخ بدیم مخصوصا علم جامعه شناسی. سالیان سال هست که تفکر mutable operating systems بر تفکر توسعه ما تاثیر به شدت بالایی گذاشته ولی باید اعتراف کنیم، یواش یواش که تعداد متخصصان این حوزه بیشتر شده داره کم کم این سوال پیش میاد که آیا واقعا داشتن ناظر بیرونی در توسعه نرم افزار درست بوده و هست؟ بنظرم میرسه بخشی از اکوسیستم صنعت کامپیوتر (بخصوص نرم افزار) به این نتیجه رسیدن که immutable operating systems می تونه پاسخ خیلی بهتری باشه. دلایل زیاد براش وجود داره و قصد نیست پست را طولانی کنم و مشتاقان می تونن براحتی با گوگل کردن کلمات کلیدی این پست به محتواهای خوبی برسند.
مصداق های ناظر بیرونی:
- هر نوع داده کانفیگ به صورت فایل، env vars یا os args ها که از بیرون رفتار نرم افزار ها یا خود سیستم عامل را عموما در runtime تحت تاثیر میذاره. باید در نظر بگیریم این مقادیر (کانفیگ ها) عموما یکبار بر رفتار نرم افزار تاثیر عموما زیادی می گذارند لذا این رفتار ناظر بیرونی می تواند با رفتن به compile time به ناظر درونی تغییر کند. دلیل هم واضح هست، افزایش شدید بهره وری منابع (انرژی، نیروی متخصص، ...) همزمان با کاهش پیچیدگی، هم در زمان توسعه و هم در اجرا (فرهنگ DevOps).
فقط اشتباه نشه که بعضی مواقع یکسری متغییر های رفتاری هست که نیاز هست در ران تایم لحاظ بشه. ولی در نهایت نرم افزار باید بتونه بدون نیاز به هیچ داده اولیه ای (کانفیگ) راه اندازی بشه و بتواند در ادامه در صورت نیاز، آن هم با مکانیزم های درونی، تغییر روند دهند. یعنی ما همیشه وقتی مثلا در زبان گو، تابع main را صدا میزنیم همیشه یک رفتار مشابه را می توانیم انتظار داشته باشیم و این اصل در رویکردهایی مثل #Functional_Programming هم به شدت تاکید شده و میشه.
- اعمال دستورات از نرم افزارهای دیگر مانند k8s که رفتار نرم افزار ما تحت نظر دارند. مثلا یک ابزار خارجی به نرم افزار شما دیکته کند که نیاز به اجرای یک node دیگر برای پاسخگویی به رشد تعداد درخواست می باشد.
حال شاید سوال بشه چرا موضوع تبدیل ناظر بیرونی به درونی اینقدر می تونه در افزایش کیفیت نرم افزار تاثیر بذاره؟ مثلا بیایم scheduler یک ناظر بیرونی مثل k8s را بررسی کنیم. وقتی شما ناظر بیرونی هستید برای اینکه وقتی یک نود از نرم افزار داره به حداکثر مصرف منابع نزدیک میشه با ابهام بیشتری باید تصمیم بگیرید که چجوری باید یک نود جدید ایجاد کنید و عملا باز با ابهام بیشتری درخواست ها را به نود جدید ارسال کنید. با کمی تامل و تفکر میشه فهمید که حتی اگر ناظر بیرونی بخواد بدون ابهام کارشو انجام بده عملا نیازه هم ناظر و هم خود نرم افزار داده تکراری زیادی را با مصرف بیش از دو برابری منابع نگهداری و پردازش کنه که خوب معقول نیست واقعا.
- برون سپاری نگهداری داده ها یعنی نرم افزارهای عموما #دیتابیس نامیده می شوند که در این پست هم بهش اشاره کردیم . در دنیای واقعی مثل این هست که یک بانک بجای نگهداری ذخیره طلای خودش، طلاها را به سازمان دیگری جهت نگهداری واگذار کنه. قطعا میشه و حتی انجام میشه ولی آیا درسته؟

در نهایت باز مانند پست های گذشته، مهمترین نکته ای که باید بهش توجه کنیم تا جایی که میشه نیازمندی را با ناظر درونی (کتابخانه) پوشش بدیم نه یک نرم افزار جداگانه. چون نرم افزار جداگانه یعنی هزینه خیلی بیشتر و مصرف انرژی (در توسعه و اجرا) بیشتر برای هیچ و با رجوع به فرهنگ بسیار غنی ژاپنی ها این کار مغایر تفکر و فرهنگ #Lean هست.

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

#تفکر_طراحی / #تفکر_مهندسی / #طراح (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