Forwarded from CodeForFood
Machine Learning Engineering.pdf
37.9 MB
این ها گلچین رفرنس ها و کتابهاییه که من دارم میخونم و از مهم هاست، حول محور طراحی ها، معاری، استفاده از تکنیک ها، پرابلم، سولوشن ها و مسائل فنی میچرخه ( سرتون گیج نره)
اصول دین میدونین چیه؟ همونه. شب اول قبر ازتون میپرسن، منتها اینجا تاا شب اول قبر ازتون میپرسن.
نرید بگید مدیریت حافظه و allocation خودکاره ولش کن مگه c عه،
نرید efcore بندازین تنگ پروژه ولی پارتیشن و ایندکس گذاری و cascade و best practice هارو بلد نباشین (همون کارایی که بابتش باید گریه میکردیم ارشد یادمون بده بعد چندماه دیتابیس طراحی کنیم تو مثلا sql server بعد بدیمش دست سازمانا 🤭)،
نرید rest api بنویسید شبیه وب سرویس های soap خدابیامرز asmx و wcf (ره)، نگید swagger چیه open api چیه، زنگ میزنم ممد توضیح میده وظیفشه،
نرید زرت و زرت async await و task بزنین تو پروژه، از باباش که thread نمیاره cpu،
این سرویس ها، کلاس ها، مدل ها و کوئری هایی که مینویسین رو خودتون یه نگاه بکنین ( من که شرمسارم، کاش یکی زود تر اینارو بهم میگفت تا به نادانی خود بیشتر پی ببرم).
Clean Code و Onion و آنکل باب و Solid
پیشکش.
من که میرم دوباره OOP یاد بگیرم اگه کسی هست که ترجیحا مجردم هست که با هم یاد بگیریم 🤭😁 با اون سیبیلاتون ادم یادش میره قبلیارم.
اصول دین میدونین چیه؟ همونه. شب اول قبر ازتون میپرسن، منتها اینجا تاا شب اول قبر ازتون میپرسن.
نرید بگید مدیریت حافظه و allocation خودکاره ولش کن مگه c عه،
نرید efcore بندازین تنگ پروژه ولی پارتیشن و ایندکس گذاری و cascade و best practice هارو بلد نباشین (همون کارایی که بابتش باید گریه میکردیم ارشد یادمون بده بعد چندماه دیتابیس طراحی کنیم تو مثلا sql server بعد بدیمش دست سازمانا 🤭)،
نرید rest api بنویسید شبیه وب سرویس های soap خدابیامرز asmx و wcf (ره)، نگید swagger چیه open api چیه، زنگ میزنم ممد توضیح میده وظیفشه،
نرید زرت و زرت async await و task بزنین تو پروژه، از باباش که thread نمیاره cpu،
این سرویس ها، کلاس ها، مدل ها و کوئری هایی که مینویسین رو خودتون یه نگاه بکنین ( من که شرمسارم، کاش یکی زود تر اینارو بهم میگفت تا به نادانی خود بیشتر پی ببرم).
Clean Code و Onion و آنکل باب و Solid
پیشکش.
من که میرم دوباره OOP یاد بگیرم اگه کسی هست که ترجیحا مجردم هست که با هم یاد بگیریم 🤭😁 با اون سیبیلاتون ادم یادش میره قبلیارم.
C# Friends pinned «این ها گلچین رفرنس ها و کتابهاییه که من دارم میخونم و از مهم هاست، حول محور طراحی ها، معاری، استفاده از تکنیک ها، پرابلم، سولوشن ها و مسائل فنی میچرخه ( سرتون گیج نره) اصول دین میدونین چیه؟ همونه. شب اول قبر ازتون میپرسن، منتها اینجا تاا شب اول قبر ازتون میپرسن.…»
از شاهکارای موسیقی هستن اینا خداییش ( به مولا؟! :)، روحتون رو بعد پاپ و رپ و اتل متل تتل با اینا بشورین. :(مدیونین اگر فکر کنین صدا و سیمای مملکت خودش آهنگاشو نمیسازه و از کفار و بیگانه استفاده میکنه ها :))
میزارم گروه مثل همیشه.
https://news.1rj.ru/str/csharpfriendsgroup/293
این سبک هم گوش کنین عشق کنین.
https://news.1rj.ru/str/csharpfriendsgroup/313
https://news.1rj.ru/str/csharpfriendsgroup/343
میزارم گروه مثل همیشه.
https://news.1rj.ru/str/csharpfriendsgroup/293
این سبک هم گوش کنین عشق کنین.
https://news.1rj.ru/str/csharpfriendsgroup/313
https://news.1rj.ru/str/csharpfriendsgroup/343
Telegram
C# Friends Group
🎧 جستجوی موزیک در آهنگیفای
سریع و کوچیک، سازگار و منعطف
حتما اسمشو شنیدین، تو کنفرانس ها، مقاله ها، کاربرد هاش در میکروسرویس ها و کلاود. وقتی صحبت از Service میشه وب سرویس و api های soap و rest میاد تو ذهنمون. تو خیلی از استفاده ها web api یا همون restful api design نیاز هامون رو مرتفع میکنه. پروتکل http با قواعد و ساختار استاندارد، راحت و سازگار با همه. مهم نیست چه کلاینتی یا زبانی استفاده میکنین، فقط با ارسال یک http request میتونین با api ها ارتباط بگیرین.
دیگه تشریحش نمیکنم همه http و rest و api رو بلدین و از مزایا و محدودیت هاشم مطلعین. در کنار این گرامی وب سوکت هم هست. پروتکل Http2 هم با امکانات بیشتر قویتر از http1 عه. حالا چی میشه که میریم سمت سوکت؟ مثلا مهمترین کاربرد signalr و signalgo و مشابه هاشون ارتباطات بلادرنگ، دو طرفه و سریعه؛ دارای سربار کمتر نسبت به یک درخواست http معمولی که دارای قاعده خاصیه ( شما لایه نیتیوش رو نمیبینید، چون توسط فریم ورک و کتابخونه انجام میشه، ولی میتونین دربارش تحقیق کنین که چطوری یک http request/response پردازش و ارسال میشه). کار ندارم خلاصه همینقدر گفتم که بارز ترین مفاهیمشون رو داشته باشین.
حالا اگر شما بخواید یک برنامه چت، استریم موسیقی/ویدئو، یا در کل ارتباط real time و همیشه برخط داشته باشین با api نمیتونین کار کنین. چون بر پایه درخواست و پاسخ کار میکنه یعنی باید درخواستی باشه تا پاسخی داده بشه و در انتها همه چیز بسته و فراموش میشه. برعکسش تو سوکت، ارتباط شما با مقصد میتونه همیشه باز بمونه مثل سیم یا لوله همه چی داخلش در رفت و امده)
اگر یکی پیام بفرسته همون لحظه همه میتونن پیام رو دریافت کنن ui شون رو اپدیت کنن یا هر عمل دیگه ای در سمت کلاینت و سرور انجام بدن. در مقابل rest api های مرسوم که باید مثلا هر ده ثانیه هی برن از سرور بپرسن سلام چه خبر پیام جدیدی هس؟! قطعا این روش هزینه زیادی برای هر دو طرف داره، ممکنه تا چندساعت دیگه هم هیچ اتفاقی رخ نده ولی کلاینت ها یکسره باید ریکوئست بزنن. اصلا ممکنه بعد درخواست کلاینت برای چک کردن پیام ها سریع یه پیام جدید ثبت شه ولی کلاینت تا interval مشخص شده بعد هیچی نميدونه! (مثلا ده ثانیه یا چند دقیقه بعد که دوباره درخواست چک کردن بفرسته به سرور)
خلاصه این روش خیلی ضایعه، منابع و یکپارچگی داده تو همچین سیستمی از دست میره.
یه فرآیند رو مثال میزنم، مثلا شما زنگ میزنی سامانه نوبت دهی یا پشتیبانی x، میگه وایستا تو صف تا نوبتت شه، یا میگه هنوز جواب درخواستتون نیومده. حالا، یا باید تا صبح هی زنگ بزنی بگی سلام چی شد؟ اومد؟ نیومد و ..، یا بهت بگن هر موقع نوبتتون شد یا جوابی اومد بهتون اطلاع میدیم( مثلا تماس یا پیام میفرستیم). قطعا سیستم دومی بهتره نه؟ میری سراغ زندگیت تا اونا وظیفشونو انجام بدن.
همین سیستم رو ببرید سمت برنامه نویسی، کلاینت ها به شما وصل میشن و متصل میمونن تا هر وقت بخوان. میتونن باهاتون صحبت کنن هر دفعه هم نیاز نیست از اول خودشونو معرفی کنن. ضمن اینکه هر موقع باهاشون کاری داشته باشید این شما هستین که بهشون اطلاع میدین، دقیقا مثال بالا. فلانی درخواستی داده هر موقع این درخواست تغییر وضعیت پیدا کرد یا نتیجه ای بود شما بهش اطلاع میدین دیگه لازم نیست خودش هی بپرسه، فقط کافیه گوش به زنگ باشه. شبیه سیستم messaging اگر اشنا باشین.
همه اینا رو با داستان سرایی گفتم که برسم به دست پرورده گوگل، حضرت GRPC یا جی آر پی سی. اینجا شما بهتره از یه سیستم بلادرنگ استفاده کنین، پس معمولا میرن سراغ signalr و grpc؛ یا سوکت نویسی native که خیلی سخته و زیاد عاقلانه نیست مجدد اختراع شه وقتی اینهمه کتابخونه خوب هست. بحث پیام رسانی بین سرور ها و کلاینت ها میتونه json باشه، binary باشه، text باشه و ...
یعنی دیتاها به چه فرمتی رد و بدل بشن، خوب json و text خوانا تر و ساده تره برای انسان ولی اینجا بحث ماشین به ماشین بیشتر مهمه. انقدر مهمه که اومدن سریالایزر باینری نوشتن تا دیتا خیلی کوچیک و کم حجم بشه که طبعا سرعت و پرفورمنس کلی سیستم رو به نسبت json چند برابر بیشتر میکنه. به هر حال یک چیزی این دیتا رو موقع ارسال و دریافت باید تبدیل کنه حالا json یا binary. هم signalr و هم grpc سریالایزر های مختلفی دارن پراستفادشون باینریه.
منتها چند تفاوت مهم بین grpc با مثلا signalr هست، اولیش کامپایلره. grpc از protobuf استفاده میکنه یه سری فایل هستن که به عنوان قرارداد شناخته میشن. متد ها و مدل ها و فیلد ها همه میشن قرارداد های سرور و کلاینت. سینتکس زبان خودشم داره یعنی تو c# اگر مینویسیم list اونجا اسمش میشه repeater. یا dictionary میشه map. نوع داده خودشه که کامپایلر میتونه کدهاشو برای بقیه generate کنه.
تو این پست سعی کردم به زبون خودمونی توضیح مقدماتی ای بدم، تو یه پست دیگه فنی تر میشیم.
حتما اسمشو شنیدین، تو کنفرانس ها، مقاله ها، کاربرد هاش در میکروسرویس ها و کلاود. وقتی صحبت از Service میشه وب سرویس و api های soap و rest میاد تو ذهنمون. تو خیلی از استفاده ها web api یا همون restful api design نیاز هامون رو مرتفع میکنه. پروتکل http با قواعد و ساختار استاندارد، راحت و سازگار با همه. مهم نیست چه کلاینتی یا زبانی استفاده میکنین، فقط با ارسال یک http request میتونین با api ها ارتباط بگیرین.
دیگه تشریحش نمیکنم همه http و rest و api رو بلدین و از مزایا و محدودیت هاشم مطلعین. در کنار این گرامی وب سوکت هم هست. پروتکل Http2 هم با امکانات بیشتر قویتر از http1 عه. حالا چی میشه که میریم سمت سوکت؟ مثلا مهمترین کاربرد signalr و signalgo و مشابه هاشون ارتباطات بلادرنگ، دو طرفه و سریعه؛ دارای سربار کمتر نسبت به یک درخواست http معمولی که دارای قاعده خاصیه ( شما لایه نیتیوش رو نمیبینید، چون توسط فریم ورک و کتابخونه انجام میشه، ولی میتونین دربارش تحقیق کنین که چطوری یک http request/response پردازش و ارسال میشه). کار ندارم خلاصه همینقدر گفتم که بارز ترین مفاهیمشون رو داشته باشین.
حالا اگر شما بخواید یک برنامه چت، استریم موسیقی/ویدئو، یا در کل ارتباط real time و همیشه برخط داشته باشین با api نمیتونین کار کنین. چون بر پایه درخواست و پاسخ کار میکنه یعنی باید درخواستی باشه تا پاسخی داده بشه و در انتها همه چیز بسته و فراموش میشه. برعکسش تو سوکت، ارتباط شما با مقصد میتونه همیشه باز بمونه مثل سیم یا لوله همه چی داخلش در رفت و امده)
اگر یکی پیام بفرسته همون لحظه همه میتونن پیام رو دریافت کنن ui شون رو اپدیت کنن یا هر عمل دیگه ای در سمت کلاینت و سرور انجام بدن. در مقابل rest api های مرسوم که باید مثلا هر ده ثانیه هی برن از سرور بپرسن سلام چه خبر پیام جدیدی هس؟! قطعا این روش هزینه زیادی برای هر دو طرف داره، ممکنه تا چندساعت دیگه هم هیچ اتفاقی رخ نده ولی کلاینت ها یکسره باید ریکوئست بزنن. اصلا ممکنه بعد درخواست کلاینت برای چک کردن پیام ها سریع یه پیام جدید ثبت شه ولی کلاینت تا interval مشخص شده بعد هیچی نميدونه! (مثلا ده ثانیه یا چند دقیقه بعد که دوباره درخواست چک کردن بفرسته به سرور)
خلاصه این روش خیلی ضایعه، منابع و یکپارچگی داده تو همچین سیستمی از دست میره.
یه فرآیند رو مثال میزنم، مثلا شما زنگ میزنی سامانه نوبت دهی یا پشتیبانی x، میگه وایستا تو صف تا نوبتت شه، یا میگه هنوز جواب درخواستتون نیومده. حالا، یا باید تا صبح هی زنگ بزنی بگی سلام چی شد؟ اومد؟ نیومد و ..، یا بهت بگن هر موقع نوبتتون شد یا جوابی اومد بهتون اطلاع میدیم( مثلا تماس یا پیام میفرستیم). قطعا سیستم دومی بهتره نه؟ میری سراغ زندگیت تا اونا وظیفشونو انجام بدن.
همین سیستم رو ببرید سمت برنامه نویسی، کلاینت ها به شما وصل میشن و متصل میمونن تا هر وقت بخوان. میتونن باهاتون صحبت کنن هر دفعه هم نیاز نیست از اول خودشونو معرفی کنن. ضمن اینکه هر موقع باهاشون کاری داشته باشید این شما هستین که بهشون اطلاع میدین، دقیقا مثال بالا. فلانی درخواستی داده هر موقع این درخواست تغییر وضعیت پیدا کرد یا نتیجه ای بود شما بهش اطلاع میدین دیگه لازم نیست خودش هی بپرسه، فقط کافیه گوش به زنگ باشه. شبیه سیستم messaging اگر اشنا باشین.
همه اینا رو با داستان سرایی گفتم که برسم به دست پرورده گوگل، حضرت GRPC یا جی آر پی سی. اینجا شما بهتره از یه سیستم بلادرنگ استفاده کنین، پس معمولا میرن سراغ signalr و grpc؛ یا سوکت نویسی native که خیلی سخته و زیاد عاقلانه نیست مجدد اختراع شه وقتی اینهمه کتابخونه خوب هست. بحث پیام رسانی بین سرور ها و کلاینت ها میتونه json باشه، binary باشه، text باشه و ...
یعنی دیتاها به چه فرمتی رد و بدل بشن، خوب json و text خوانا تر و ساده تره برای انسان ولی اینجا بحث ماشین به ماشین بیشتر مهمه. انقدر مهمه که اومدن سریالایزر باینری نوشتن تا دیتا خیلی کوچیک و کم حجم بشه که طبعا سرعت و پرفورمنس کلی سیستم رو به نسبت json چند برابر بیشتر میکنه. به هر حال یک چیزی این دیتا رو موقع ارسال و دریافت باید تبدیل کنه حالا json یا binary. هم signalr و هم grpc سریالایزر های مختلفی دارن پراستفادشون باینریه.
منتها چند تفاوت مهم بین grpc با مثلا signalr هست، اولیش کامپایلره. grpc از protobuf استفاده میکنه یه سری فایل هستن که به عنوان قرارداد شناخته میشن. متد ها و مدل ها و فیلد ها همه میشن قرارداد های سرور و کلاینت. سینتکس زبان خودشم داره یعنی تو c# اگر مینویسیم list اونجا اسمش میشه repeater. یا dictionary میشه map. نوع داده خودشه که کامپایلر میتونه کدهاشو برای بقیه generate کنه.
تو این پست سعی کردم به زبون خودمونی توضیح مقدماتی ای بدم، تو یه پست دیگه فنی تر میشیم.
Forwarded from شجاعت تغییر
اکثر ما به دانش و تخصص مان افتخار می کنیم و خیلی دوست داریم پای باورها و عقایدمان بمانیم. در یک دنیای باثبات، چنین طرز فکری منطقی خواهد بود و ثبات عقیدهٔ ما عواید قابل توجهی را به همراه خواهد داشت. اما مشکل اینجاست که دنیای ما به سرعت تغییر می کند و باید معادل زمانی که صرف تفکر می کنیم، برای بازنگری و اصلاح تفکرات مان هم وقت بگذاریم.
آدام_گرانت
از کتاب" دوباره فکر کن"
__
@TheCourageToChange
آدام_گرانت
از کتاب" دوباره فکر کن"
__
@TheCourageToChange
این کتابای pdf هم اصلا صفا نداره ها، نمیشه بچینیشون تو قفسه ات و یه عینک بزنی با ژست یه فنجون قهوه فوری 3 هزارتومنی از خودت سلفیش بگیری. فعلا چیدمشون رو دسکتاپم تا بعد ببینم چی میشه دیگه. دیروزم دستم خورد یکیشون باز شد اصلا فهمیدم pdf reader ندارم رو سیستم.
تازه همه ام فکر میکنن داری فیلمای مثلا رزمی عاطفی نولان رو نگاه میکنی با اون قیافه. همسایه پر رو اومده میگه شبا چی فیلم میبینی به مام آهااا، میبینمت چند ساعت زل زدی تو مانیتور من ساختمان روبرو ام.
تازه همه ام فکر میکنن داری فیلمای مثلا رزمی عاطفی نولان رو نگاه میکنی با اون قیافه. همسایه پر رو اومده میگه شبا چی فیلم میبینی به مام آهااا، میبینمت چند ساعت زل زدی تو مانیتور من ساختمان روبرو ام.
سیستم احراز هویت و مدیریت کاربری مینویسید؟ jwt بیس و حاوی نقش و دسترسی های پویا و سرویس های کاستوم؟ خب دست خوش به خودتون مربوطه، لابد در امنیت سر رشته کافی دارین و owasp و top 10 رو کامل پیاده کردین و مطلعین، ضمن اینکه با مصائب روز سیستم های احراز هویت و کلاینت های مختلف اشنایید.
ولی اگر نکردین و نمیدونین و فکر کردین با چهارتا جدول user و role و این چیزا الان ایدنتیتی مایکروسافت رو فیتیله پیچ کردین باید بگم چند وقت دیگه با صورتی برافروخته و چشمانی قرمز ( اون قرمز نه، شایدم اره بالاخره فشاره دیگه) میاین میگین سیستم داینامیک پرمیشن و multi device و امنیت و شصت تا فیچر و principle دیگه رو چطوری پیاده کنم که هم یک ترابایت کد و کوئری ننویسم هم استاندارد ها و پروتکل های امنیتی رو رعایت کنم پرفورمنس هم ساییده نشه، که پس فردا از روزنه هاش رو نمایی بکنن حیثیتمون به گاراج بره. شاید بعضیا فکر کنن یه کوکی و jwt میدل ویر و چارتا جدول و سرویسه دیگه این شامبورتی بازیا چیه در میاری مخی بگی بلدی؟! نه اتفاقا به جدم نیستم در حدم که ممبر شیپ و auth سرور بنویسم و چهار روز دیگه مشتری رو به چوخ بدم بعدم فکر کنم، ها دیدی سخت نبود تازه طراحی اختصاصی بود پول بیشتریم گرفتم همینو میکنم تو استین بعدیا( ولی حالا مثلا میشه بگی owasp top10 چیه؟ @_@).
عین مرد میرم از ساختار و دکون دستگاه دو پروژه Identity و Identity server استفاده میکنم و بسته به نیاز روی پروتکل oauth2 و openid connect کاستومایز انجام میدم رو هر چیزی که بخوام، چون میدونم چطوری کار میکنن چی به چیه و نیاز های اینده رو چه سولوشن هایی براش دارم. ولی تکرار مکررات و واضحات نمیکنم، متن بازم که هستن.
اینارو گفتم چون یک عده یا خیلی تعصب دارن که این بده یا خیلیاش نوشته شده و نمیخوام به چیزی وابستگی داشته باشم ( خدایا ببخش)، یا میگن این که خیلی سوسولیه بابا هیچی نداره منم کشش یادگیری ندارم همونا که بلدم رو، هم میزنم. بماند که یک عده خیلی کمی واقعا میدونن که چی میخوان بنویسن و چی به چیه، مثلا تو سیستمای دولتی یا خیلی بسته، اون هیچ من مخلصشون هم هستم. ولی به اون دو دسته اساتید نایاب عرض کنم که شما میزاری و میری یه روز و بیلی میمونه و شصتش واسه بعدی ها. ینی یه چیز میخوای اضافه کنی همه چوب کبریتا میریزه، یه جاهایی هم که معلوم نیست چجوری پروتکل و استاندارد ساخته شده این وسط. بعد خبر میاد پکیج x سکیوریتی پچ برای cve سطح high خورده و تا ناموس سیستم در خطره. سپس رو به کارفرما کرده و با غرور خاصی میگن ما که ازوناها استفاده نکردیم. ما خودمون نوشتیم یه جوریم نوشتیم که خودمونم نمیتونیم بفهمیم چه برسه هکررر ررر.
نکنید تو رو خدا لطفا خواهش میکنم مارو دور نندازین. دورم انداختین عیب نداره، ولی تو این مملکتی که به لطف چندتا ارگان دولتی که تازه سیستم های به قول خودشون خیلی امن، بسته و در خلا با بودجه های قطوری داشتن، دیتاهامون به کل کف اینترنت ریخته، شما دیگه یکم حرفه ای تر عمل کن منت بزار بده یکی review کنه حداقل.
ولی اگر نکردین و نمیدونین و فکر کردین با چهارتا جدول user و role و این چیزا الان ایدنتیتی مایکروسافت رو فیتیله پیچ کردین باید بگم چند وقت دیگه با صورتی برافروخته و چشمانی قرمز ( اون قرمز نه، شایدم اره بالاخره فشاره دیگه) میاین میگین سیستم داینامیک پرمیشن و multi device و امنیت و شصت تا فیچر و principle دیگه رو چطوری پیاده کنم که هم یک ترابایت کد و کوئری ننویسم هم استاندارد ها و پروتکل های امنیتی رو رعایت کنم پرفورمنس هم ساییده نشه، که پس فردا از روزنه هاش رو نمایی بکنن حیثیتمون به گاراج بره. شاید بعضیا فکر کنن یه کوکی و jwt میدل ویر و چارتا جدول و سرویسه دیگه این شامبورتی بازیا چیه در میاری مخی بگی بلدی؟! نه اتفاقا به جدم نیستم در حدم که ممبر شیپ و auth سرور بنویسم و چهار روز دیگه مشتری رو به چوخ بدم بعدم فکر کنم، ها دیدی سخت نبود تازه طراحی اختصاصی بود پول بیشتریم گرفتم همینو میکنم تو استین بعدیا( ولی حالا مثلا میشه بگی owasp top10 چیه؟ @_@).
عین مرد میرم از ساختار و دکون دستگاه دو پروژه Identity و Identity server استفاده میکنم و بسته به نیاز روی پروتکل oauth2 و openid connect کاستومایز انجام میدم رو هر چیزی که بخوام، چون میدونم چطوری کار میکنن چی به چیه و نیاز های اینده رو چه سولوشن هایی براش دارم. ولی تکرار مکررات و واضحات نمیکنم، متن بازم که هستن.
اینارو گفتم چون یک عده یا خیلی تعصب دارن که این بده یا خیلیاش نوشته شده و نمیخوام به چیزی وابستگی داشته باشم ( خدایا ببخش)، یا میگن این که خیلی سوسولیه بابا هیچی نداره منم کشش یادگیری ندارم همونا که بلدم رو، هم میزنم. بماند که یک عده خیلی کمی واقعا میدونن که چی میخوان بنویسن و چی به چیه، مثلا تو سیستمای دولتی یا خیلی بسته، اون هیچ من مخلصشون هم هستم. ولی به اون دو دسته اساتید نایاب عرض کنم که شما میزاری و میری یه روز و بیلی میمونه و شصتش واسه بعدی ها. ینی یه چیز میخوای اضافه کنی همه چوب کبریتا میریزه، یه جاهایی هم که معلوم نیست چجوری پروتکل و استاندارد ساخته شده این وسط. بعد خبر میاد پکیج x سکیوریتی پچ برای cve سطح high خورده و تا ناموس سیستم در خطره. سپس رو به کارفرما کرده و با غرور خاصی میگن ما که ازوناها استفاده نکردیم. ما خودمون نوشتیم یه جوریم نوشتیم که خودمونم نمیتونیم بفهمیم چه برسه هکررر ررر.
نکنید تو رو خدا لطفا خواهش میکنم مارو دور نندازین. دورم انداختین عیب نداره، ولی تو این مملکتی که به لطف چندتا ارگان دولتی که تازه سیستم های به قول خودشون خیلی امن، بسته و در خلا با بودجه های قطوری داشتن، دیتاهامون به کل کف اینترنت ریخته، شما دیگه یکم حرفه ای تر عمل کن منت بزار بده یکی review کنه حداقل.
Mr.Grayhat [Saeed.R]
Photo
خودمون انتخاب کردیم که این باشیم😔. گوشه ایش رو در ترند ها میتونین برین ببینین.