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

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

#چالش_عضویت

نیازمندی:
جایگزینی ساختار map (hash table) استاندارد زبان #گو با نوع دیگری از table ها برای نیاز "ثبت و پیدا کردن" مقادیر با کلید و محتوای ثابت و مشخص poolByID map[uint64]protocol.Service در زمان کامپایل که برای نیازمندی route سرویس ها استفاده خواهد شد.

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

اطلاعات تکمیلی:
- مقدار آیدی یک آرایه 8 بایتی معادل uint64 هست. که انتخاب type عددی یا آرایه با حل کننده چالش هست.
- تعداد آیدی ها در ابتدایی ترین نقطه کامپایل و اجرای نرم افزار مشخص نیست ولی پس از فراخوانی متد RegisterService توسط سرویس های مختلف و آمادگی نرم افزار به شروع فعالیت خود، عملا تعداد مشخص و ثابت میشه. عملا در طول اجرای برنامه هم چیزی کم یا زیاد نمیشه ولی این فرضیه قطعی نیست.
- همونطور که در بخش قبل هم به صورت غیر مستقیم مشخص هست، ما تقریبا همیشه صرفا در حال پیدا کردن از table مورد نظر هستیم و آیدی جدیدی به table اضافه نمیشه. یعنی ما فقط یکبار یک ساختار داده ای ایجاد می کنیم و میلیون ها بار ازش استفاده می کنیم و قطعا map با مدل استفاده از hash برای ساخت مکان یکتا برای اینکار بهینه نیست.
- راهکارهای سخت افزاری برای نیازمندی مشابهی در سوییچ های لایه دو شبکه برای کشف port مربوط به یک MAC address مثل cam-table یا tcam ها می تونه ایده خوبی برای پیاده سازی بهینه نیازمندی باشه.

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

منابع کمکی:
https://ddcode.net/2019/06/30/learn-more-about-go-map-initializing-and-accessing-elements/
https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/
https://deepu.tech/memory-management-in-golang/
http://jmoiron.net/blog/go-performance-tales/
https://boltandnuts.wordpress.com/2017/11/20/go-slice-vs-maps/

#چالش_عضویت

نیازمندی:
طراحی سیستم اعتبارسنجی مالی فردی با در نظر گرفتن یکسری پیش فرض و در صورت نیاز معرفی فرض های خوب دیگر. این سیستم یکی از اعضای نظام پولی یک جامعه هدف با پول بر پایه بدهی می باشد ولی خلق پول صرفا توسط اعتبارسنجی اشخاص حقیقی انجام میشه نه ساختار حاکم فعلی بر نظام پولی دنیا که از چند لایه مثل بانک مرکزی، حکومت ها و بانک های خصوصی شکل گرفته است.
انتظارات:
در دو بعد علم اقتصاد و علوم کامپیوتر می تونه نیازمندی تبدیل به پیشنهادات و محصول مورد نظر بشه. تکمیل اطلاعات مورد نیاز برای پیاده سازی در هر بخش قابل قبول می باشد.
اطلاعات تکمیلی:
- هر فردی در جامعه صرفا اعتبار خود را می تواند در چند حالت مشخص به دیگری انتقال دهد. خرید و فروش اوراق بهادار (سهام، اوراق قرضه، ...) یا خدمات یا کالا ها. لذا ساختار مرسوم اجاره دادن پول (نرخ بهره ثابت بانکی) در سیستم وجود ندارد.
- عملا هنوز در سیستم نرخ بهره (اوراق قرضه) وجود داره و این نرخ در بازار جامعه در میاد ولی ذاتا مبنا و نقطه خلق پول نخواهد بود.
- هدف از این سیستم استفاده از #هوش_جمعی در سطوح بزرگ بجای هوش گروهی و فردی در سطح های کوچک مانند هییت مدیره بانک ها و هییت های بانک مرکزی جهت کنترل پول می باشد.
- هر چند چرخه های خطرناکی (death loop) مانند "خرید سهام <> اخذ اعتبار جدید <> خرید سهام جدید <> اخذ اعتبار جدید" در این سیستم نمی تونه توسط اعضا پیاده سازی بشه چون عملا با کاهش میانگین ارزش اوراق در مالکیت فرد، فرد مجبور به فروش (خودش یا توسط سیستم) میشه تا کسری اعتبارشو جبران کنه، ولی باعث نمیشه چرخه های خطرناک دیگر شناسایی نشن و باید طبق اصول Zero-day threat راه کارهای بررسی و ترجیحا اتوماتیک برای موارد fraud detection در سیستم دیده شود.
- قاعدتا این نظام نیاز به تغییراتی در جزییات دیگه جامعه هدف داره. مثلا در این جامعه هیچ فرد حقیقی نمی تونه مالک مستقیم دارایی هایی مثل زمین، ساختمان، ... باشه و صرفا باید سهام دار یک سازمان باشه.
- باز بنظر میرسه نیاز هست یکسری استانداردهای فرا سیستمی تعریف بشه. مثلا سازمان های عضویت فعال خواهند داشت و برای دادن اعتبار به افراد قابل قبول می باشند که یکسری API سرویس استاندارد را حتما پیاده سازی کنند و به صورت برخط جزییاتی را به اجبار در اختیار سیستم کلی جامعه بذارن.
- مقدار اعتبار یک فرد به صورت لحظه ای (قابل گفتمان) توسط نظام پولی مدنظر رصد میشه و پایین و بالا شدن اعتبار یک فرد باعث عکس العمل سیستم و ابطال اعتبار اعطایی به فرد توسط مانده حساب فرد یا با دادن فرصتی مشخص از فروش دارایی های فرد انجام خواهد شد.
- سیستم و نظام مدنظر کاملا با هوش جمعی خود جامعه کنترل میشه. مثلا کسی نمی تونه الکی اعتبار بگیره و بره یک سهام را گران بخره (چه بازار اولیه و چه بازار ثانویه) چون با پایین آمدن ارزش واقعی آن سهام از دیگر دارایی ها خودش باید اعتبار را پس بده. یعنی مثلا اگر قراره یک مجتمع ساختمانی بزرگ مثل ایران مال ساخته بشه یک فرد یا نهایت چند نفر محدود نمی تونن بگن این طرح خوبه و از اعتبار ساخته بشه و باید هوش یک جمع بزرگ تایید کنند این طرح را عملا با خرید سهام از بازار اولیه.
- آیا همچنان این جامعه به بانک های خصوصی نیاز داره و یا اصلا در ساختار قابل جاسازی هستند؟
- بنظر میرسه کل نیازمندی های انتقال پول را نرم افزار جامعه باید پوشش بده.
اهداف فردی و تیمی:
- یادگیری نحوه تفکر در خارج از ساختار های بسیار رایج شکل گرفته در مغز. در بسیاری از جزییات نیازه کاملا out of box فکر بشه به موضوعات.
- به دلیل ماهیت سیستم افراد با دیدگاه های مختلف مجبور به همفکری های زیادی برای پایخ گویی به جزییات هستند، لذا مهارت تیم سازی به شدت مهم خواهد بود.

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

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

#مقاله ای مرتبط و در ادامه موضوع پست قبل (reply شده) و به صورت جامع تر در لینکدین منتشر کردم، که اگر از خوندن این پست لذت بردید، خالی از لطف نیست، آن را هم نگاهی بیاندازید.
https://www.linkedin.com/feed/update/urn:li:ugcPost:6878715247625166848/

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

❗️ همین امروز❗️

💠 جلسه‌ی چهاردهم: آینده‌ی تولید نرم‌افزار (۱)
💠 ارائه دهنده: امید حکایتی
💠 تاریخ: ۸ دی | ساعت ۱۹ الی ۲۰:۳۰

👉 t.me/FrontChapter 👈

فرانت چپتر؛ محیطی صمیمی برای گفت‌وگوی تخصصی
@FrontChapter - #frontChapter

#پروژه_تیمی

نیازمندی:
پیاده سازی بخش های مورد نیاز پروتکل tcp از صفر درون userspace و دور زدن کامل سیستم عامل برای هندل کردن این پروتکل برای استفاده در سیستم عامل های معمول ولی با هدف استفاده در سیستم عامل های بر پایه unikernel ها. هدف اینکار در جلسات به مفصل گفته خواهد شد.
انتظارات:
- تسلط نسبی به اصول کارکرد سخت افزار و سیستم عامل
- تسلط کافی به جزییات compiler و runtime زبان گو
اطلاعات تکمیلی:
- در دنیایی که سرویس ها به صورت API پیاده سازی می شوند و طبق آمار میانگین داده رد و بدل شده در سرویس ها کمتر از سایز داده ای که یک پاکت tcp می تواند با توجه به MTU فعلی شبکه ها هندل کنند یعنی چیزی حدود 1500 بایت می باشد، عملا ساختار و تفکر گذشته نسبت به نحوه پیاده سازی جزییات مختلف ارتباط نرم افزار دیگر جواب نیازمندی ها را نخواهد داد
- عموما در هندل کردن استریم های tcp در گو به ازای هر استریم فعال یا idle یک goroutine ساخته و نگهداری میشه که حداقل هزینه حافظه هر کدام 2KB هست که عموما باز در اکثر اوقات با در نظر گرفتن هزینه فعال بودن یک بافر خواندن 4KB هزینه کلی صرفا در سمت userspace به بیشتر از 6KB هم به راحتی میرسه. با داشتن تعداد زیاد مثلا یک میلیون استریم باز که عموما اکثر اوقات idle هستند عملا هزینه زیادی (صرفا در مصرف رم در کل اپ به بیش از 6GB ) برای اجرا بودن یک اپ داده میشه. که با هزینه سمت کرنل حتی به موقعیت های چند برابری خواهیم رسید و محدودیت تعداد فایل باز نیز وجود دارد.
- نحوه انتقال اطلاعاتی مثل keyboards events یا mouse events در کرنل های یونیکس بیس می تونه ایده هایی بده.
- پیشنهاد کتابخانه ای بدون بررسی دقیق آن باعث امتیاز منفی درعضویت این کار تیم خواهد بود. مثلا کتابخانه FastHTTP یک سو تفاهم بزرگ در نحوه برخورد با context switch هست و عملا راه کار worker ارائه شده هیچ مزیت خاصی نخواهد داشت به جز ایجاد محدودیت در ساخت goroutine ها و عدم رسیدن به اهداف اصلی! یا تغییر رویه به epool چیزی به جز پاک کردن صورت مسیله نیست.
- بررسی پروتکل QUIC که بر روی UDP می باشد به شدت کمک کننده هر دو پروتکل خواهد بود و در آینده می توان با درس از پیاده سازی TCP پروتکل UDP را نیز به همین شکل پیاده سازی کنیم.
- تمام جزییات پیاده سازی این پروتکل در لینوکس نیاز به پیاده سازی در اینجا نخواهد بود چون تفکر در unikernel ها کمی متفاوت می باشد.
مزیت شرکت در این کار تیمی:
- پس از انجام این کار تیمی فرد با اشتراک دانش زیادی در حوزه سیستم عامل و شبکه برخورد کرده که می تواند دانش عمیقی را بدست آورد.
- نتیجه کار به صورت متن باز در دسترس همه خواهد بود، لذا قطعا در توسعه نرم افزارهای افراد مشارکت کننده با دید عمیق ایجاد شده، کمک شایانی خواهد کرد.
ظرفیت تیم:
حداکثر 5 نفر ولی دیگر دوستان علاقه مند می توانند در حداقل دو جلسه در ماه با این موضوع که در سرور دیسکور (آدرس در channel info) برگزار می شود حضور داشته باشند.
زمان انجام پروژه:
پیش بینی می شود از زمان شروع حداکثر 12 ماه کار توسعه با حداقل دو جلسه دو ساعته در ماه طول خواهد کشید.
منابع کمکی:
https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency
https://github.com/golang/go/issues/15735
https://github.com/xtaci/gaio
https://github.com/lesismal/nbio
https://github.com/google/gopacket
https://stackoverflow.com/questions/8509152/max-number-of-goroutines

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

اگر قبول کنیم که لایه منطق ماهیت داده مورد نیاز سازمان را مشخص می کند و لایه رابط کاربر نحوه تعامل و جمع آوری آن داده ها از کاربران داخلی و خارجی با سازمان را، شروع به توسعه اگر از لایه رابط کاربر اتفاق بیافتد، معمولا باعث خطاهای شناختی فردی و جمعی بسیاری خواهد شد، زیرا ما از لایه ای شروع کردیم که اول باید سوالات لایه دیگر را پاسخ دهد و بعد به سوالات لایه خود پاسخگو باشد. و اگر در هر بخش کار بخش دیگر پوشش داده شود، عموما باعث ایجاد مشکلات فراوان در توسعه و هزینه بسیار زیاد در نگهداری نرم افزار و تمایل زیاد افراد جدید به دوباره نویسی بخش های مختلف نرم افزار خواهد شد.
پس در شروع طراحی و پیاده سازی نرم افزار در سازمان خود به ترتیب به سوالات زیر پاسخ دهید:
- ابتدا از این سوال شروع کنید که سازمان شما چه داده هایی را برای پیشبرد اهداف خود نیاز دارد.
- پس از آن پاسخ دهید که آن داده باید به عنوان #داده_اکتسابی از کاربر اخذ شود یا به عنوان #داده_اکتشافی بایستی از داده های کاربر استخراج شود.
- پس از آن باید پاسخ دهید که داده کسب شده در طول زمان دارای اعتبار (Time Series Data) می باشد یا خیر. که در اکثر اوقات جواب این پاسخ مثبت هست و هنوز اکثرا افراد و تیم های توسعه به این موضوع توجه کافی ندارند و دیتاهای باارزش سازمان ها را به اشتباه با عملیات Update در سطح بخش ذخیره سازی داده ها عملا پاک می کنند.
- کدام یک از داده هایی که در سوالات قبل جمع آوری شده، واقعا به یکدیگر ارتباط معنایی دارند؟ یعنی اگر داده زمان محور هست و کدام داده در صورت تغییر با یکدیگر بایستی تغییر کنند؟ با پاسخ به این سوال ساختار ذخیره سازی داده ها مشخص می شود. به عنوان مثال اگر کاربری، username خود را تغییر داده آیا این داده ارتباطی با داده هایی مانند Legal Name او دارد؟ اگر خیر پس بایستی طراحی به گونه صورت پذیرد که صرفا داده های مرتبط در کنار یکدیگر مجموعه شکل دهند.
- با پاسخ به سوالات قبل عموما شما پاسخ به سوال اینکه چه سرویس هایی (کلمه API استفاده نمی کنیم چون خیلی درست نیست) نیاز به پیاده سازی دارد را مشخص کرده اید و با کمی دقت براحتی می توانید عملیات های مختلف روی ساختارهای داده ای را مشخص کنید.
- ... (مسیر توسعه و پاسخ به پرسش ها دیگر همچنان ادامه دارد ولی تا همین جا برای این مطلب کافی می باشد)

در نهایت اشاره کنیم توسعه نرم افزار برای هر سازمانی نیاز به درک خوبی از اهداف آن سازمان دارد. در صورت عدم وجود هدف شفاف و مشخص در ابتدای کار برای سازمان هایی که هنوز دارای برنامه تجاری مشخص نیستند. تا جای امکان سعی کنید داده های اکتسابی از کاربر را با روش های #کاربر_پسند(Good UX) جمع آوری کنید تا بتواند به افراد دیگر سازمان بینش کافی برای طراحی طرح تجاری مناسب کمک کند.

#ایده_استارت_آپی
چند نفر از دوستان از من پرسیدن هدف گروه توسعه نابغه ها از جلب مشارکت دوستان در توسعه یک کتابخانه برای هندل کردن tcp در سطح user space چی هست وقتی خیلی از شرکت های بزرگ هم ممکنه حتی فکر ورود به این حوزه را در ذهن خودشون هم نمیارن. خوب ما از این کار سه هدف را دنبال می کنیم
- نشون بدیم خیلی از موضوعات آکادمیکی که در #گرایش_نرم افزار رشته #مهندسی_کامپیوتر در دانشگاه ها تدریس میشه همیشه بلا استفاده نیستند و میشه جریان تجاری روی تک تک این موضوعات ایجاد کنیم و لازم نیست به خودمون و دیگران القا کنیم موضوعات آکادمیک موضوعات نه جذابی هستند و نه در کسب و کارها بدرد می خورند.
- بعد نشون بدیم شرکت ها (حتی بزرگان) بدلیل نبود نیروی متخصص کافی مجبور هستند حتی خیلی از پروژه های داخلی خودشون را #متن_باز کنند تا بتوانند به آن پروژه انرژی کافی بدن برای ادامه مسیر توسعه. پس باید قبول کنیم خیلی از پروژه ها که اپن سورس میشن قطعا نیاز داخلی خیلی از پروژه ها بوده و خواهد بود و ما نیز به دلیل غیر مستقیم هدف بعدی نیاز هست یکسری افراد با تخصص در سطوح پایین توسعه نرم افزار را شناسایی و جذب کنیم
- و هدف اصلی ما به واقعیت تبدیل کردن ایده تجاری ارائه خدمات اتصال افراد به شبکه اینترنت بدون نیاز به اینکه کاربر بخواد برای اتصال در نقاط مختلف با شرکت ها و راه کارهای مختلف سروکله بزنه. قطعا این ایده در سطح ایران هم حتی جدید نیست مانند سرویس "وای فای اول متعلق به همراه اول mci.ir" و در سطح جهان هم کارهایی شده ولی با توجه به بررسی ما بدلیل عدم وجود دید مهندسی دقیق و عدم امکان توسعه زیرساخت خوب برای این نیازمندی، اکثر پروژه ها به شکست منجر شده اند. اجرایی کردن این ایده نیاز داره افرادی با دید کافی در توسعه سرویس هایی که با لایه ای به جز لایه اپلیکیشن هم سروکله داره، در تیم توسعه آن حضور داشته باشند.
ولی در همین حین با بررسی میدانی (اطلاعات رسمی منتشر نشده است) شرکت هایی مانند cloudflare.com متوجه میشیم چقدر دقیق و زیر پوستی دارن این موضوع را دنبال می کنند و زیرساخت مناسب را توسعه می دهند و با ارایه خدمات رایگان مانند https://1.1.1.1/ در حال تست زیرساخت خود هستند و در آینده نزدیک این شرکت یکی از بازیگران بزرگ اتصال افراد به اینترنت خواهد بود.
لذا برای رسیدن به تیمی منسجم نیاز هست افرادی با توانایی توسعه نرم افزار در زیرساخت ها را کنارمون داشته باشیم یا افرادی را برای این منظور آموزش دهیم. و با توجه به بررسی تصمیم گرفتیم این موضوع را از توسعه tcp on userspace جلو ببریم.

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

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

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

#چالش_عضویت #فرانت_اند #نرم_افزار_رابط_کاربر #HTML #CSS

👈 نیازمندی:
توسعه بیشتر این کتابخانه به عنوان یک کتابخانه Classless library (No-Class CSS) در جهت نیازمندی های مطرح در معماری های low|no code که شروع به توسعه شده ولی هنوز خیلی کار داره. نیاز هست فرد مورد نظر منابع مختلف مانند مستندات زبان طراحی متریال را بررسی کنه و نتیجه را به ما اعلام کنه تا همکاری (مسلما با پرداخت هزینه) را با این تسک و تسک های دیگه شروع کنیم.
لازم به ذکر است تقریبا 99% از کدهای فعلی کتابخانه مدنظر از رپو استاندارد متریال استفاده شده با صرفا تغییر نام کلاس ها به تگ. پس اگر ایرادای به کتابخانه مورد نظر مطرح هست قابل حل هست و ربطی به توسعه اولیه ما نداره.

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

📌 اطلاعات تکمیلی:
✅ چون نیازمندی مطرح شده عموما در اکوسیستم توسعه نرم افزار مطرح نیست و با نگاه سخت گیرانه نوعی تفکر رادیکال محسوب میشه ولی با نگاه کمی منطقی صرفا یک #پارادایم_شیفت هست، پس نیاز هست فرد به خودش فرصت بده که اول شناخت کافی به اهداف پیدا کنه و طبق عرف انسانی سریع نسبت به این موضوع گارد نگیره.
✅ مسلما جزییاتی هست که نیاز هست فرد روی آنها کار کنه. مثلا ما در حال حاضر طبق پروتکل html فقط یک مدل دکمه داریم ولی در عمل دکمه ها واقعا یک مدل نیستند و حتی در دنیای فیزیکی هم ما انواع مختلفی دکمه داریم، مثل دکمه فشاری، دکمه دو حالته، ... پس نیازه حتی تغییرات مورد نیاز را به گوش توسعه دهنده های پروتکل html برسونه. مثلا بنده در رپو اصلی توسعه html یک موضوع مرتبط را مطرح کردم که ما برای تگ dialog نیاز به یک attribute به نام type داریم که انواع مختلف دیالوگ را نه بر اساس یک تابع در js به نام showModal() فقط مشخص کنیم، بلکه نشان دادن این تفاوت نوع باید در زمان توسعه محتوا مشخص شود.
✅ شناخت جزییات ریزی همانند Media Query با بخش هایی درونی مثل Pointer باعث میشه با عمق بهتری جزییات پیاده سازی بشه.
✅ مفهوم سمانتیک مخصوصا در html که توی README رپو هم اشاره شده موضوع بسیار مهمی در توسعه این کتابخانه می باشد. میشه از سه مدل معروف یعنی microdata vs rdfa vs JSON-LD در این زمینه نام ببریم. فرد مورد نظر باید تفاوت ها و نسبتا درک عمیقی به این موضوع داشته باشه.
✅ هر چند توسعه مورد نظر صرفا نیاز به دید عمیق در html,css می خواد ولی داشتن دانش کافی در منطق زبان های برنامه نویسی کامپیوتری می تونه در سرعت توسعه کمک کنه. در نهایت همونطور که مشخصه از کتابخانه یا فریم ورک خاصی استفاده نخواد شد و صرفا دید عمیق نسبت به خود این سه زبان مد نظر می باشد.
✅ نمونه مشابه کم و بیش وجود داره که لیست از آن را اینجا می تونید ببینید ولی در گوگل هم موارد بیشتری مثل این موجود هست ولی چندان کامل و مخصوصا بر اساس زبان های طراحی معروف چیزی من یافت نکردم
💥 تخصص های مورد نیاز
🔸تسلط پایه ای به html,css,js
🔸 آشنایی کافی به یکی از استانداردهای Semantic Data ترجیحا rdfa
🔸 آشنایی کافی به مفاهیم و اصول زبان های طراحی - Design Langiuages
🔸 ترجیحا آشنایی با یکی از زبان های طراحی شناخته شده مانند Material , fluent , IBM , ANT
🔸 آشنا به اصول و پیش نیازهای توسعه نرم افزار مانند GIT و ...

#پروژه_تیمی

نیازمندی:
توسعه چارچوب قوی و کامل شامل قراردادهای توسعه #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