یکی از کتاب هایی که درباره sql و anti-patternهاش هست و ریویهای مثبت خوبی داره این کتابه

SQL Antipatterns: Avoiding the Pitfalls of Database Programming (Pragmatic Programmers) 1st Edition

by Bill Karwin (Author)
4.5 out of 5 stars
189 ratings

https://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557

مزیت این کتاب اینه که نکات کوچیک و ساده رو practical مثال زده و توضیح داده علت اینکه anti-pattern هست چیه

کتاب از ابعاد مختلف به دیتابیس نگاه کرده، تو فصل های مختلف نکاتی رو گفته که متنوع هست، مثلا درباره طراحی جداول دیتابیس صحبت کرده، درباره کوئری ها صحبت کرده، در مورد ایندکس دیتابیس، در مورد نکاتی که از سمت اپلیکیشن باید در مورد دیتابیس رعایت بشه صحبت کرده و غیره

@gocasts

یه ویدیوی تازه و داغ که یه کتابخونه جدید رو هم معرفی میکنه برای event stream processing

Processing Millions of Events Per Second Reliably Using Generics
https://youtu.be/tedFyfKqKeI?si=HoWXARoDv0BRbQRo

A blazingly fast event stream processing library powering the reveald event processing daemon.
https://github.com/runreveal/kawa

Kawa: The Event Processor for the Grug Brained Developer
https://blog.runreveal.com/kawa-the-event-processor-for-the-grug-brained-developer/


تعداد مشارکت کنندگاه دوره از ۵۰۰ نفر گذشت 🔥
به همین مناسبت، تخفیف ۵۳ درصدی دوره در نظر گرفتیم
جزییات بیشتر در این پست 👇
https://news.1rj.ru/str/gocasts/572


@gocasts

دو برنامه نویس کهنه کار و خفن ۲۵ سال پیش یه کتاب جمع و جور و خوب نوشتن که کلی نکته کوچیک و مفید در مورد practiceهای برنامه نویسی داره.


مثلا در فصل اول برای style همین یک پاراگراف کلی نکته داره
اولا اینکه style یه common sense هست، پس براش دنبال استاندارد و قانون نگردید.
کد باید واضح و ساده باشه و نباید clever tricks داشته باشه
خیلی Consistency مهمه که یک style در کل کد رعایت بشه

The principles of programming style are based on common sense guided by expe- rience, not on arbitrary rules and prenoscriptions. Code should be clear and simple- straightforward logic, natural expression, conventional language use, meaningful names, neat formatting, helpful comments- and it should avoid clever tricks and unusual constructions. Consistency is important because others will find it easier to read your code, and you theirs, if you all stick to the same style.


من چند تا از نکات فصل اول رو مینویسم اینجا

Use denoscriptive names for globals, short names for locals.
Programmers are often encouraged to use long variable names regardless of context. That is a mistake: clarity is often achieved through brevity.
نوشته شده که global variables باید اسم های طولانی و توصیف کننده داشته باشن و local variables ها باید short name داشته باشن.
نکته جالبی که میگه اینه که برنامه نویس ها علاقه دارن اسم های طولانی انتخاب بکنن بدون در نظر گرفتن context، در حالیکه clarity خیلی وقت ها با استفاده از اختصار بدست میاد.

Be consistent
در انتخاب اسم ها باید سیاست consistent داشته باشیم، اگه یه جا برای نامگذاری یه متغیر مرتبط با صف از Queue استفاده کردیم، برای یه متغیر دیگه از Q استفاده نکنیم…

Consistency and Idioms: Use a consistent indentation and brace style
این چیزیه که در گولنگ خیلی دغدغه ش رو نداریم، چون rob pike یکی از نویسندگان این کتاب خودش گولنگ رو نوشته 🙂

Give names to magic numbers
بهتره اگه تو کد مقادیر ثابت استفاده میکنید براشون constant تعریف کنید، مثلا اگه در گولنگ از لینتر استفاده کنید میتونید این لینتر رو نصب کنید go-mnd که بهتون بگه کجاها رعایت نکردید

خلاصه این کتاب کلی نکته مفید و کوچیک و خفن داره که هنوز هم خیلی هاش کاربردیه

The Practice of Programming (Addison-Wesley Professional Computing Series) 1st Edition
https://www.amazon.com/Practice-Programming-Addison-Wesley-Professional-Computing/dp/020161586X
by Brian Kernighan (Author), Rob Pike (Author)


@gocasts

یه کتابی که خیلی فیدبک های خوبی داره برای ساختمان داده و الگوریتم، کتاب
A Common-Sense Guide to Data Structures and Algorithms, Second Edition: Level Up Your Core Programming Skills 2nd Edition
هست که ریویوهاش رو اینجا میتونید بخونید
https://www.amazon.com/Common-Sense-Guide-Structures-Algorithms-Second/dp/1680507222

مزیت اصلی کتاب اینه که خیلی از تصویرسازی کمک گرفته برای آموزش دادن مفاهیم و این کمک بزرگی میکنه به مخاطب.


قبلا تو کانال در مورد مزایای یادگیری مصور صحبت شده بود
https://news.1rj.ru/str/gocasts/155


@gocasts

یکی از چیزایی که از rust خیلی دوست دارم pattern matching هست، خیلی تر و تمیز و انعطاف پذیر هست.
اینجا بیشتر میتونید در موردش بخونید.
https://doc.rust-lang.org/book/ch06-00-enums.html

مثلا استفاده کردن match در کنار Result ENUM خیلی practice خوبی برای بررسی خروجی یک تابع یا متد هست.

اینطوری مجبور نیستی همه توابع رو طوری بنویسی که خروجی آخرشون error باشه (در گولنگ اینطوریه)

به کمک pattern matching هم خیلی خوانایی کد کمتر نمیشه بنظرم.

let greeting_file_result = File::open("hello.txt");

    let greeting_file = match greeting_file_result {
        Ok(file) => file,
        Err(error) => match error.kind() {
            ErrorKind::NotFound => match File::create("hello.txt") {
                Ok(fc) => fc,
                Err(e) => panic!("Problem creating the file: {e:?}"),
            },
            other_error => {
                panic!("Problem opening the file: {other_error:?}");
            }
        },
    };

از نظر error handling فکر میکنم نگاه مشترکی با گولنگ داره، از این نظر که خطاهارو دو دسته recoverable و unrecoverable میبینه که یکی رو با Result مدیریت میکنه و یکی رو با panic که فکر میکنم خیلی شبیه نگاه گولنگ هست.
Most languages don’t distinguish between these two kinds of errors and handle both in the same way, using mechanisms such as exceptions. Rust doesn’t have exceptions. Instead, it has the type Result<T, E> for recoverable errors and the panic! macro that stops execution when the program encounters an unrecoverable error.


@gocasts

#rust #golang

مصاحبه های طراحی سیستم نقش مهمی تو خیلی از مصاحبه های فنی دارن. من با چند برنامه نویس از سطوح مختلف با تجربه های ۴، ۵ سال و کمتر بصورت ناشناس مصاحبه های mock فنی طراحی سیستم انجام دادم که ۶ تا از این مصاحبه ها در دوره قرار گرفته. موضوع مصاحبه ها در مورد سیستم های مختلفی هست از جمله سرویس های پرداخت، بورس، فایل و غیره ست.
الحمدلله که این مصاحبه ها به دوستان کمک کرده تو فرآیند مصاحبه های طراحی سیستم عملکرد بهتری داشته باشن و به استخدام شون کمک کرده.

دوره +‌ تیمسازی بکند و گولنگ Go Casts
لینک خرید دوره + تیمسازی با ۵۰ درصد تخفیف به مبلغ ۴ میلیون و ۵۰۰ هزار تومان
https://gocasts.ir

همه چیز در مورد دوره و تیمسازی در این پست توضیح داده شده
https://news.1rj.ru/str/gocasts/434

تو این پست هم میتونید فیدبک های دوره و تیمسازی و استخدام بچه هارو بخونید
https://news.1rj.ru/str/gocasts/441

دوستانی که در خرید دوره تردید دارند میتونن برای مشاوره کوتاه تلفنی، فرم زیر رو پر کنند که باهاشون تماس بگیرم
https://survey.porsline.ir/s/ATeQL4b4


@gocasts

شاید تعجب کرده باشید که چرا در خیلی از کنفرانس های JavaScript جای این عبارت از js و ecmanoscript استفاده میکنن..
دلیلش اینه که آقای oracle که sun microsystems رو خرید تریدمارک JavaScript رو هم در نتیجه ش صاحب شد.
حالا آقای ryan dahl که سازنده nodejs و deno هست چند وقتی هست گیر داده به oracle که تریدمارک JavaScript رو کنسل کنه که دیگه به عنوان یه کلمه عمومی همه بتونن ازش استفاده کنن. سفت و سخت پیگیره..

https://x.com/deno_land/status/1873615998324203591


@gocasts

دوستان سنیور گولنگ که دنبال کار دلاری هستید، اگه مهارت مکالمه زبان خوبی دارید لطفا فرم زیر رو پر کنید، یکی از دوستان به دنبال نیروی سنیور گولنگ هست.
https://survey.porsline.ir/s/O1pXpEzr


کانال تلگرام
@gocasts

دوستان اگه اپلیکیشن رو بصورت مونولیت مینیوسید، کار خوبی میکنید، اما aggregation pattern رو جدی بگیرید، کمک بزرگی میکنه به حفظ loosely coupled بودن ماژول و سرویس هاتون.

یه اشتباه رایجی که باعث میشه خیلی راحت همه چیز در هم تنیده و coupled بشه نیازهای بیزینسی ای هست که دیتای aggregate شده از چند domain مختلف رو میخواد از شما. تو حالت مونولیت خیلی ساده ست که شما در هر domain به دیتابیس یه domain دیگه درخواست بزنی و یا حتی تو interactor/service دیگه یه متد جدید تعریف کنی که دیتای مد نظر رو بده. که معمولا باعث در هم تنیده شدن و چاق شدن سرویس هاتون میشه.

بهتره سرویس یا همون interactorهاتون کارهای خیلی کوچیک و well-definedی رو انجام بدن و اگه نیازمندی های aggregationطور دارید، یه سری service دیگه بسازید که وابستگی خواهد داشت به سرویس های مختلف و دیتاهای raw رو میگیره و پردازش میکنه که دیتای نهایی رو آماده کنه.

بعضی وقت ها از طریق gateway هم ممکنه بتونید aggregate کنید. بعضی وقت ها ممکنه تو همون لایه دلیوری (کنترلر) تون بتونید دو تا سرویس رو فراخوانی کنید و کار رو در بیارید، گاهی هم پیچیده تر میشه و لازمه یه سرویس(interactor) بنویسید که کار aggregation رو انجام بده
https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation

باز خود aggregate کردن حالت های مختلفی داره، اینجا میتونید بیشتر بخونید در موردش
https://medium.com/geekculture/design-patterns-for-microservices-aggregation-pattern-1b8994516fa2

@gocasts

ملت از چی پول در میارن 😁

طرف ۹۹ دلار میگیره که ruby رو روی سیستم عامل مک نصب کنه :)
تا الان بیش از ۲ هزار نفر هم بهش پول دادن

https://www.rubyonmac.dev/

حالا من از کجا پیداش کردم؟ برای یه پروژه قدیمی داشتم ruby نصب میکردم که به مشکل خوردم، واقعا هم بعضی وقتا دردسر داره نصبش، مخصوصا اینکه نسخه ۳ هم اومده...

من حاضرم رو سیستم تون کامپایلر گولنگ نصب کنم به همراه همه وابستگی هاش، ۹ دلارم بیشتر نمیگیرم 😄


@gocasts

سلام دوستان
بالاخره سایتمون بروز شد :)

فکر کنم بعد از چند سال لازم بود از یه صفحه خیلی ساده کمی بهتر بشه

زحمت پیاده سازی ش رو دوستان فرانت کشیدن، و من با دخل و تصرف در کارشون صرفا یه سری قسمت هارو خراب کردم :)

اگه مشکلی داشت بدونید کار خودمه، مثلا کلی کلنجار رفتم که بتونم یه سری button رو به وسط صفحه منتقل کنم نشد که نشد 😟😁

از یه برنامه نویس بکند بیشتر از این انتظار نداشته باشید…

فعلا فقط لندینگ اصلی تغییر کرده. سعی کردیم توضیحات خوبی در مورد دوره و تیمسازی تو این صفحه قرار بدیم.

https://gocasts.ir

دمتون گرم ❤️

@gocasts

اگه برای یادگیری گولنگ یه دلیل خیلی موجه میخوای، این پست رو با دقت مطالعه کن

آخرش رو اولش بخوام بگم میشه: یادگیری برنامه نویسی بدون فریمورک
حالا این قضیه چرا مهمه؟

درک practiceهای برنامه نویسی و ترکیب کردن اونا کار سختیه. ولی وقتی درکشون کنی و تجربه به کارگیری شون رو داشته باشی، یه دریچه ای به روت باز میشه که خیلی ارزشمند هست و بهت این قدرت رو میده که با انتخاب خودت و با تحلیل خودت انواع ترکیب الگوهارو در کنار هم برای سیستم خودت بسته به نیازت به کار بگیری.

خیلی از الگوهای برنامه نویسی رو فریمورک ها استفاده میکنن و کار رو برای شما خیلی راحت میکنن. اما این راحت شدنه یه هزینه ای داره، اونم اینه که اجازه نمیده به شما برنامه نویسی و کار با الگوهارو تجربه کنی.

گولنگ مزیت بزرگش یادگیری بدون فریمورک همین الگوهاست. بعد از یه مدت که الگوهای مختلف رو خودت تو گولنگ به کار میگیری با خیلی هاشون به اندازه کافی آشنا میشی و برای پروژه های جدیدت با خیال راحت تر و دست باز تصمیم میگیری چه ترکیبی از practiceهارو استفاده کنی.
گولنگ زبان جمع و جوریه و این خودش باز باعث میشه خیلی نتونی تو پیاده سازی الگوها شیوه های مختلفی رو به کار بگیری که انتخاب شیوه پیاده سازی وسواس برات ایجاد کنه.

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

@gocasts

اجازه بدید برای پست دیروز یه مثال بزنم که شاید به درک بهتر موضوع کمک کنه.

از زیبایی های گولنگ اینه که پکیج ها و building blockهای سطح بالا ارائه میده، که سرعت توسعه برنامه نویس خوب باشه.
حالا مثلا برای یه web framework چه building blockهایی لازمه؟
اگه با گولنگ کار کنی بعد از مدتی میتونی blockهای مهمی که بخواد functionality یه فریمورک وب رو ارائه بده بشناسی، از جمله: یه http listener میخوای که درخواست هارو accept کنه، یه multiplexer میخوای که بر اساس request path درخواست هارو توزیع کنه، یه سری handler لازم داری که درخواست هارو مدیریت کنه، این وسط ممکنه یه سری middleware لازم داشته باشی، ممکنه تو handlerت validation لازم داشته باشی، بعدش نوبت به بیزینس لاجیک ت میرسه و بعدش هم به database driver احتیاج داری که ارتباط با دیتابیس رو مدیریت کنه.

قشنگی کار اینجاست که تو هر building block شما علاوه بر یک سری انتخاب از std packageها میتونی third-party پکیج هارو هم استفاده کنی و به ترکیب های مختلفی این building blockهارو با هم compose کنی و این flexibility فوق العاده ای میده.

علاوه بر همه این ها، برنامه نویس بعد از یه مدت به خودش میاد و میفهمه که نسبت به المان های فریمورک وب شناخت خوبی پیدا کرده و کارایی هر بلاک رو درک کرده و دیگه براش black box نیست. بعدش میتونه خودش هر بلاک رو تحلیل کنه و از بین انتخاب هاش اونی که براش بهتره رو انتخاب کنه.

@gocasts

یه تعریف خیلی ساده و شسته و رفته برای Stack و Heap

تو مستندات آموزش rust قبل از اینکه ownership رو توضیح بده در مورد heap و stack صحبت کرده، توضیح کوتاه و خوبیه، یادآوری خوبی میتونه باشه
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

چقدر این مثالش قشنگه برای اینکه چرا دسترسی به heap کندتر از stack هست

Accessing data in the heap is slower than accessing data on the stack because you have to follow a pointer to get there. Contemporary processors are faster if they jump around less in memory. Continuing the analogy, consider a server at a restaurant taking orders from many tables. It’s most efficient to get all the orders at one table before moving on to the next table. Taking an order from table A, then an order from table B, then one from A again, and then one from B again would be a much slower process. By the same token, a processor can do its job better if it works on data that’s close to other data (as it is on the stack) rather than farther away (as it can be on the heap).

@gocasts

تجربه یه incident با رعایت نکردن اصول ساده

خیلی وقت ها پیش میاد که ما یه سری نکته ساده رو رعایت نمی کنیم و همین موضوع باعث میشه که مشکلات بزرگی در سیستم رخ بده.

من سعی میکنم نکات کوچیکی که طبق تجربه خودم داشتم یا اطرافیانم داشتند رو گاه به گاه منتشر کنم. امروز در مورد یکی از این موارد که باعث incident هم شد صحبت می کنم.

قبل از اینکه شرح بدم incident چی بود در مورد root cause صحبت می کنم که تابع Get از پکیج net/http بود. خیلی هاتون ممکنه برای ارسال درخواست های http در گولنگ از این تابع استفاده کنید و خیلی کار رو هم ساده می کنه.

https://pkg.go.dev/net/http#Get


اسم سرویس ها یه چیز دیگه ست من ساده سازی کردم.
یه سرویس اصلی رو در نظر بگیرید که وقتی درخواست بهش میرسه، ابتدا یه سری اطلاعات رو از طریق یه درخواست http از یه سرویس خارجی دریافت میکنه و بعد پاسخ درخواست کاربر رو پس میده.
حالا تصور کنید این سرویس کارهای دیگه ای هم انجام میده، مثلا همین سرویس برای انجام paymentها یه ماژول پرداخت داره که باز هم از درخواست های http استفاده میکنه که با ipgها صحبت کنه و پرداخت هارو انجام بده.

این سرویس با همین مشخصات روی پروداکشن زیر لود بود که فهمیدیم سرویس خارجی ای که اطلاعات رو ازش میگیریم خیلی latency بالایی داره و همین باعث شده درخواست های زیادی باز بمونن برای مدت طولانی و مصرف رم و cpu سرویس بالا رفته و پاسخ ها دچار response time بالا شدن.

اولین نکته ای که به ذهن میرسه اینه که خب بهتره از context timeout استفاده کنیم برای درخواست ها که مثلا یه درخواست http به سرویس خارجی بیشتر از ۳۰ ثانیه باز نمونه.
که خب تابع Get خودش ورودی context نمیگیره، پس باید به فکر راه دیگه ای بود.
برنامه نویس فهمیده بود که تابع Get داره از http.DefaultClient استفاده میکنه و این client یه فیلد timeout داره، پس خیلی سریع تایم اوت رو ست کرد، به این صورت

http.DefaultClient.Timeout = time.Second * 5

کد دیپلوی شد و رفت روی پروداکشن، اتفاقی که افتاد این بود که دیگه مشکل response time وجود نداشت برای سرویس خارجی و اگه درخواست بیشتر از ۵ ثانیه طول میکشید کنسل میشد.

اما یه مشکل جدید خیلی بد بوجود اومده بود، ماژول پرداخت به فنا رفته بود و نمیتونست پرداخت هارو درست مدیریت کنه.

علت چی بود؟‌ علت این بود که اونم داشت از http.Get استفاده میکرد و با تنظیم شدن تایم اوت ۵ ثانیه، اونم درخواست های بیشتر از ۵ ثانیه رو کنسل میکرد.

خب خیلی ها شنیدید که الگوی singleton خیلی جاها میتونه bad practice باشه و یکی از اون جاها همین default http clientی هست که پکیج net/http ارائه میده.

درست ش این بود که هر ماژول برای درخواست های خودش یه http client مجزا داشته باشه که تایم اوت خاص خودش رو ست کنه. حتی میشه از این تابع NewRequestWithContext
استفاده کرد که context رو هم پشتیبانی کنه.

https://pkg.go.dev/net/http#NewRequestWithContext


مشکل singleton اینه که side effectهای تغییر singleton object مبهم میشه، شما میای برای درخواست های سرویس خارجی تایم اوت ست کنی، ولی عملا درخواست های پرداخت رو به فنا میدی..

پکیج net/http و پکیج های دیگه گولنگ برای راحتی استفاده خیلی وقت ها یه default object ارائه میدن، ولی واقعا باید برای استفاده از این objectها احتیاط کرد. بهتره instance خاص خودت رو بسازی که مدیریت stateش فقط خودت رو تحت تاثیر بذاره و side effect نداشته باشه.

@gocasts

ابزار جالبیه برای کار با docker و docker-compose در ترمینال

A simple terminal UI for both docker and docker-compose, written in Go with the gocui library.

https://github.com/jesseduffield/lazydocker

@gocasts