مثلاً قرار بود توی صفحۀ اصلی، پروداکتها بر اساس محبوبیت مرتب بشن. اون زمان یه فیلد popularity اضافه کردم که از تعداد فروشهای پروداکت گرفته میشد. حالا نیاز داریم همون رو توی صفحۀ محصول به عنوان تعداد فروش نشون بدیم.
ولی این popularity نیست، popularity کاربردی بود که ازمون خواسته شده بود. باید اسمش رو sales_count میذاشتیم.
درس اخلاقی: همیشه به اصل مفاهیم دقت کنید، نه کاربردی که ازتون خواسته شده.
ولی این popularity نیست، popularity کاربردی بود که ازمون خواسته شده بود. باید اسمش رو sales_count میذاشتیم.
درس اخلاقی: همیشه به اصل مفاهیم دقت کنید، نه کاربردی که ازتون خواسته شده.
👍3
درایو C که ویندوز روشه، 500 مگابایت فضای خالی داشت. چندتا اپ رو uninstall کردم، شد 448 مگابایت! 🤔😂
فکر کنم ویندوز کارش برعکسه، باید برای خالیکردن فضا چندتا اپ نصب کنم... 😂
فکر کنم ویندوز کارش برعکسه، باید برای خالیکردن فضا چندتا اپ نصب کنم... 😂
😁10
حالا پکیج laravel-scout میتونه با MySQL هم کار کنه و اینطوری میتونید هم سرچ سایتتون رو بهبود بدید، هم اینکه زمینه رو برای استفادههای بعدی از سرویسهای پیشرفته فراهم کنید:
https://laravel.com/docs/9.x/scout
https://laravel.com/docs/9.x/scout
🔥3👍1
فرض کنید میخوایید یه سرویس کوچیک بالا ببرید که به یه سری سرویس دیگه سرویس بده. (چه سرویس تو سرویسی شد)
قراره دیتابیس بین این سرویسها مشترک باشه یا هر کدوم دیتابیس خودشون رو داشته باشند؟
اگه جوابتون اینه که هر سرویس دیتابیس مستقل خودش رو داشته باشه، سوال بعدی اینه که برای هر سرویس، از چه دیتابیسی استفاده میکنید؟
بسته به نیاز و ماهیت دیتای هر سرویس، ممکنه سراغ دیتابیسی relational مثل MySQL و برای یه سرویس دیگه سراغ دیتابیسی مثل MongoDB بریم. حالا سؤال بعدی اینه که اینها سنگین در نمیان؟ سرویسی که دیتای خیلی کمی داره و به غالب فیچرهای MySQL یا MongoDB نیاز نداره، چرا باید از اینها استفاده کنه؟ وقتی ترنزکشن نمیخوام و شاید flat-file کارم رو راه بندازه، چرا گربه رو با RPG بکشم؟
اگه دنبال یه دیتابیس relational یا همون رابطهای باشیم، SQLite یه گزینۀ جالب و خیلی سبُکه که میشه بررسی کرد. حجم ایمیج فشردهشدهاش توی داکرهاب، حدود هشت مگابایته! از اون طرف RethinkDB رو داریم که در مقایسه با MongoDB حجم کمتری داره.
یه سری لینک:
https://relevant.software/blog/microservices-database-management
https://rethinkdb.com/docs/quickstart
https://stackoverflow.com/questions/63385922/is-it-bad-to-use-json-files-instead-of-real-databases
https://stackoverflow.com/questions/13899342/can-we-use-json-as-a-database
قراره دیتابیس بین این سرویسها مشترک باشه یا هر کدوم دیتابیس خودشون رو داشته باشند؟
اگه جوابتون اینه که هر سرویس دیتابیس مستقل خودش رو داشته باشه، سوال بعدی اینه که برای هر سرویس، از چه دیتابیسی استفاده میکنید؟
بسته به نیاز و ماهیت دیتای هر سرویس، ممکنه سراغ دیتابیسی relational مثل MySQL و برای یه سرویس دیگه سراغ دیتابیسی مثل MongoDB بریم. حالا سؤال بعدی اینه که اینها سنگین در نمیان؟ سرویسی که دیتای خیلی کمی داره و به غالب فیچرهای MySQL یا MongoDB نیاز نداره، چرا باید از اینها استفاده کنه؟ وقتی ترنزکشن نمیخوام و شاید flat-file کارم رو راه بندازه، چرا گربه رو با RPG بکشم؟
اگه دنبال یه دیتابیس relational یا همون رابطهای باشیم، SQLite یه گزینۀ جالب و خیلی سبُکه که میشه بررسی کرد. حجم ایمیج فشردهشدهاش توی داکرهاب، حدود هشت مگابایته! از اون طرف RethinkDB رو داریم که در مقایسه با MongoDB حجم کمتری داره.
یه سری لینک:
https://relevant.software/blog/microservices-database-management
https://rethinkdb.com/docs/quickstart
https://stackoverflow.com/questions/63385922/is-it-bad-to-use-json-files-instead-of-real-databases
https://stackoverflow.com/questions/13899342/can-we-use-json-as-a-database
🔥1
چطور چیزی مثل pluck رو توی JS داشته باشیم؟
let array = items.map(item => item['fieldName'])👍2🔥2
خروجی کد زیر چیست؟
$arr = ['foo' => null];
dd(Arr::get($arr, 'foo', 'x'));
$arr = ['foo' => null];
dd(Arr::get($arr, 'foo', 'x'));
Anonymous Quiz
47%
"x"
53%
null
😢2😁1
Philocode
#books
The problem with arrays is that their shape is undefined. Clients wouldn’t know how they can extract from it the information they need.
ادیت: این دو جملۀ نوباک رو با گوشت و خون حس کردم! وقتی شما از روی یه کلاس آبجکت بسازی، دقیقاً مشخصه که داخلش چه پراپرتیهایی داری، ولی ساختار آرایه مشخص نیست و هرچی فکرش رو کرده باشید یا نکرده باشید رو میشه داخلش گذاشت. البته توی Typenoscript میشه تایپهای محدودتری ساخت، ولی در نهایت آرایه ساختارش نامشخصه.
#MathiasNoback
ادیت: این دو جملۀ نوباک رو با گوشت و خون حس کردم! وقتی شما از روی یه کلاس آبجکت بسازی، دقیقاً مشخصه که داخلش چه پراپرتیهایی داری، ولی ساختار آرایه مشخص نیست و هرچی فکرش رو کرده باشید یا نکرده باشید رو میشه داخلش گذاشت. البته توی Typenoscript میشه تایپهای محدودتری ساخت، ولی در نهایت آرایه ساختارش نامشخصه.
#MathiasNoback
👍4
طراحیهای هزینهبر و غیر مؤثر از سه منبع ناشی میشوند:
■ یک راه حل پیچیده برای یک مشکل ساده
■ یک راه حل ساده ولی نادرست برای یک مشکل پیچیده
■ یک راه حل نامناسب و پیچیده برای یک مشکل پیچیده
#code_complete
■ یک راه حل پیچیده برای یک مشکل ساده
■ یک راه حل ساده ولی نادرست برای یک مشکل پیچیده
■ یک راه حل نامناسب و پیچیده برای یک مشکل پیچیده
#code_complete
🔥3
Philocode
طراحیهای هزینهبر و غیر مؤثر از سه منبع ناشی میشوند: ■ یک راه حل پیچیده برای یک مشکل ساده ■ یک راه حل ساده ولی نادرست برای یک مشکل پیچیده ■ یک راه حل نامناسب و پیچیده برای یک مشکل پیچیده #code_complete
در همین راستا:
قرار بود که یه سری دیتا رو از یه منبع دیگه وارد سیستم خودمون کنیم. مشکل این بود که اون یکی سرویس، webhook نداشت. حالا این یعنی چی؟ یعنی وقتی دیتای جدیدی اونجا ایجاد میشد، نمیتونستیم خبردار بشیم. راهحل ما این شد که در بازههای زمانی به اون سرویس ریکوست بزنیم، دیتا رو بگیریم و حالا یه چالش این بود که چهطور دیتای جدید رو از دیتای قدیمی تشخیص بدیم؟
اولین راهحل که به ذهنم رسید، این بود که آیدی آخرین موردی که توی دیتابیس خودمه و از اون سرویس اومده رو بیارم، بعد یه foreach بزنم روی ریسپانس و یکی یکی برم تا ته، هر وقت آیدی مطابقت داشت، متوقف بشه و از بعد اون صرف نظر کنم.
راهحل رفت روی پروداکشن و یه شکست مذبوحانه داشت. بعد از فیکسکردنش، این راهحل به ذهنم رسید:
به جای آیدی آخرین مورد، آیدیهای اخیر رو از دیتابیس گرفتم، بعد ریسپانس رو filter کردم! منطق شلوغی که پیاده شده بود، با چند خط ساده انجام شد.
راهحل اول، یه مثال خوب برای راهحل نامناسب و پیچیدهای بود که برای یه مشکل ساده در نظر گرفتیم!
قرار بود که یه سری دیتا رو از یه منبع دیگه وارد سیستم خودمون کنیم. مشکل این بود که اون یکی سرویس، webhook نداشت. حالا این یعنی چی؟ یعنی وقتی دیتای جدیدی اونجا ایجاد میشد، نمیتونستیم خبردار بشیم. راهحل ما این شد که در بازههای زمانی به اون سرویس ریکوست بزنیم، دیتا رو بگیریم و حالا یه چالش این بود که چهطور دیتای جدید رو از دیتای قدیمی تشخیص بدیم؟
اولین راهحل که به ذهنم رسید، این بود که آیدی آخرین موردی که توی دیتابیس خودمه و از اون سرویس اومده رو بیارم، بعد یه foreach بزنم روی ریسپانس و یکی یکی برم تا ته، هر وقت آیدی مطابقت داشت، متوقف بشه و از بعد اون صرف نظر کنم.
راهحل رفت روی پروداکشن و یه شکست مذبوحانه داشت. بعد از فیکسکردنش، این راهحل به ذهنم رسید:
به جای آیدی آخرین مورد، آیدیهای اخیر رو از دیتابیس گرفتم، بعد ریسپانس رو filter کردم! منطق شلوغی که پیاده شده بود، با چند خط ساده انجام شد.
راهحل اول، یه مثال خوب برای راهحل نامناسب و پیچیدهای بود که برای یه مشکل ساده در نظر گرفتیم!
👍3
آقای Michael Feathers میگه: از نظر من، Legacy Code یعنی کدی که تست نداشته باشه.
👍2😁1
Philocode
آقای Michael Feathers میگه: از نظر من، Legacy Code یعنی کدی که تست نداشته باشه.
جناب Robert Martin از اون طرف میگه: میدونم مسخره به نظر میاد، ولی قابل ملاحظهست که اگه کدهای پروداکشن شما یه جوری حذف بشه و فقط تستهاش بمونه، میتونید کل سیستم با کمی تلاش بازنویسی کنید!
بعد Noback توی کتاب Advanced Web Application Architecture که قبلاً معرفی کرده بودم، برعکسش رو میگه: اما اگه فقط کدهای پروداکشن رو داشته باشید، اینکه براش تست بنویسید خیلی سخته!
بعد Noback توی کتاب Advanced Web Application Architecture که قبلاً معرفی کرده بودم، برعکسش رو میگه: اما اگه فقط کدهای پروداکشن رو داشته باشید، اینکه براش تست بنویسید خیلی سخته!
👍3