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

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

#چالش_عضویت

نیازمندی:
جایگزینی ساختار 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 و ...