Sonia Notes

Standard Go Project Layout

This is a basic layout for Go application projects. Note that it's basic in terms of content because it's focusing only on the general layout and not what you have inside. It's also basic because it's very high level and it doesn't go into great details in terms of how you can structure your project even further. For example, it doesn't try to cover the project structure you'd have with something like Clean Architecture.

https://github.com/golang-standards/project-layout #golang #golang_project_structure

زمانی که روی یک لینک کلیک می‌شود تا زمانی که جواب از سرور مورد نظر دریافت می‌شود، چندین مرحله در شبکه طی می‌شود. این مراحل عبارتند از: 🟢DNS Resolution مرورگر ابتدا باید آدرس IP متناظر با دامنه‌ای که کاربر روی لینک کلیک کرده است را بیابد. درخواست DNS از سرور DNS محلی (معمولاً سرویس دهنده اینترنت شما یا سرویس DNS داخلی در سازمان) ارسال می‌شود. سرور DNS پاسخی که شامل آدرس IP متناظر با دامنه است ارسال می‌کند. 🟢برقراری اتصال (Connection Establishment): مرورگر یک درخواست HTTP یا HTTPS برای دانلود صفحه وب (یا منبع مورد نظر) به سرور ارسال می‌کند. این درخواست به آدرس IP متناظر با دامنه ارسال می‌شود. اگر اتصال امن (HTTPS) باشد، مراحل handshake SSL/TLS انجام می‌شود. 🟢ارسال درخواست (Request Transmission): مرورگر درخواست HTTP یا HTTPS را به سرور ارسال می‌کند. درخواست شامل هدرهای HTTP مختلف مانند مرورگر، نوع درخواست (GET، POST و غیره)، و دیگر اطلاعات مورد نیاز است. 🟢پردازش در سرور (Server Processing): سرور درخواست را دریافت کرده و به پردازش آن می‌پردازد. این مرحله شامل دسترسی به پایگاه داده، اجرای کدهای سمت سرور، و سایر عملیات مورد نیاز است. 🟢ارسال پاسخ (Response Transmission): سرور پاسخ را به مرورگر ارسال می‌کند. پاسخ شامل هدرها، محتوا، و سایر اطلاعات مورد نیاز است. 🟢دریافت و نمایش محتوا (Content Rendering): مرورگر پاسخ را دریافت کرده و محتوای آن را نمایش می‌دهد. این شامل تجزیه و تحلیل HTML، CSS، و JavaScript و نمایش صفحه وب به کاربر است. این مراحل تنها یک خلاصه از فرآیند است که در هنگام کلیک بر روی یک لینک اتفاق می‌افتد و ممکن است با توجه به شرایط خاص، مراحل دیگری همچون استفاده از CDN، کش‌های مرورگر، و غیره نیز اضافه شود. ➖➖➖➖➖➖➖➖ 💚 Donate 🤍 @gopher_academy ❤️ @GolangEngineers

Be liberal in what you accept, be conservative in what you return.

Go's Declaration Syntax by Rob Pike https://go.dev/blog/declaration-syntax #golang_syntax #c

Build Web Application with Golang https://astaxie.gitbooks.io/build-web-application-with-golang/content/en/ در این گیت بوک مواردی از قبیل دانش پایه گولنک , معماری وب اپلیکیشن , کار با دیتابیس ها , کار با سیژن و کوکی و ... توضیح داده شده این کتاب به صورت اوپن سورس منتشر شده و موارد خوبی رو برای ساخت یک وب اپلیکیشن رو کاور میکنه. #golang #golang_books

داشتم یه مقاله در مورد ACID میخوندم بعد دیدم کدی که گذاشته همچین فورمتی داره :) خب آخه این کد رو کی میتونه بخونه که این مقال توی سرچ اوله گوگله :/

Microservice sidecar pattern :

the sidecar pattern decouples functionalities from a container for reasons like scalability and optimization. The decoupled processes are now separate containers that can be used by other containers.

https://medium.com/nerd-for-tech/microservice-design-pattern-sidecar-sidekick-pattern-dbcea9bed783

‏با این وضعیتی که در ایران از Jira استفاده می کنند که کرک می کنند و برای امنیت بیشتر پشت VPN و بعد غافلگیر می‌شوند که چرا هک شدیم، بهتر است از جایگزین‌های جیرا استفاده شود. برنامه huly.io‎ نه تنها جایگزین Jira است بلکه همزمان جایگزین Slack و Notion است! @DevTwitter | <Vahid Nameni/>

به دنبال ساختار باشید و نه چارچوب چند روز پیش یه مربی کودک یه حرف خیلی مهمی زد با این مفهوم: «ما اینجا برای بچه ها ساختار تعیین می کنیم نه چارچوب، چارچوب یعنی حد و مرز!» این جمله رو باید قاب کرد و زد رو دیوار، احتمالا در ابعاد خیلی زیادی از زندگی مهم باشه. در مهندسی نرم افزار و توسعه محصول هم خیلی حرف مهمیه. بیشتر اوقات ما دنبال چارچوب هستیم در مهندسی نرم افزار، به همین دلیل وقتی خودمون رو به یه چارچوب خاص محدود می کنیم با چالش های زیادی روبرو میشیم. در حالیکه بهتره ما برای توسعه محصول ساختار داشته باشیم و طبق اصول ساختاری کار رو پیش ببریم، اینطوری چالش مون کمتر میشه. اجازه بدید برداشت خودم از چارچوب و ساختار رو کمی بیشتر باز کنم. ساختار میشه مجموعه از قواعد رفتاری که باید سعی کنیم در توسعه محصول بهشون پایبند باشیم، در مقابل، چارچوب میشه تعیین کردن یه سری حد و مرز مشخص به شیوه ای سختگیرانه. مثلا اگه بخوام برای توسعه یک سرویس ساختار تعیین کنم احتمالا میگم: این سرویس باید توان پاسخگویی بالایی داشته باشه، در مقابل خطا مقاوم باشه، قابلیت مقیاس پذیری داشته باشه، یک قرارداد ساده و شفاف به کلاینت ها ارائه بده و مواردی از این دست. اما اگه بخوام چارچوب برای سرویس تعیین کنم احتمالا میگم: ما باید از ساختار کد مبتنی بر clean code یا ddd در فلان repository که خودمون یا دیگران اونو نوشتن پیروی کنیم، باید همه ورودی هارو تو پوشه port قرار بدیم، باید همه مدل هامون تو پوشه models باشه، باید از فلان روش ci/cd استفاده کنیم. در توسعه محصول تعیین کردن حد و مرز و چارچوب میتونه خوب باشه، اما بشرطی که تعیین این حد و مرز تنها زمان پیاده سازی سرویس باشه و متعهد بشیم که کورکورانه و سختگیرانه نخوایم این چارچوب رو به همه سرویس ها و محصولات تحمیل کنیم. خیلی از practiceهایی که معروف شدند مثل clean code و ddd و tdd و غیره هم از نظر من بیشتر به دنبال این هستند که به شما کمک کنند که برای کارتون ساختار تعیین کنید. در حالیکه اشتباهی که زیاد رخ میده اینه که ما با خوندن این مطالب احتمالا بیشتر به سمت درآوردن چارچوب میریم... همه ش به دنبال این هستیم که مثلا یه boilerplate داشته باشیم که از clean code پیروی کنه و همون رو همه جا استفاده کنیم. من گاها به دوستان متذکر میشم که خوندن این الگوها و منابع خیلی خوبه، به شرطی که شما سعی کنی جان کلام و دغدغه اصلی رو متوجه بشی، نه اینکه سعی کنی به دنبال یک راه حل فست فودی و چارچوب مشخص و معین باشی که کورکورانه همه جا ازش استفاده کنی. شما وقتی برای کارت ساختار داشته باشی میتونی انعطاف پذیر باشی و بسته به نیازت چارچوب تعیین کنی، اما اگه بخوای یه چارچوب معین رو همه جا رعایت کنی احتمالا یه جاهایی اصول ساختاری خودت رو مجبور میشی زیر پا بذاری چون هیچ چارچوب واحدی وجود نداره که برای همه نیازها مناسب باشه. @gocasts

اختلاف طبقاتی به روایت تصویر.