راستی یادم رفت
تشکر از:
امیرحسین فرانت اند پروژه با فلاتر
@Awmirsn
طراحی خفن UI/UX توسط محمد
@FalahiDevPV
همچنین سحر هم تو UI/UX کمک زیادی کرده
@shariws
بک اند جنگو با اون یکی امیرحسین و خودم
@the_aech

مجموعه‌ای از داده‌های ساختاریافته فوتبال ،لیگ برتر ایران(لیگ خلیج فارس)، شامل نتایج مسابقات، جدول نهایی، داوران و آقای گل‌ها در قالب CSV.
ایده‌آل برای پردازش با Pandas، SQL و مدل‌سازی با Machine Learning.

https://github.com/Abbasmo72/PersianGulfLeagueIran-Stats/blob/main/Persian.md

@DevTwitter | <Arzhan/>

توهم کنترل کامل، یکی از بزرگ‌ترین سوءتفاهم‌ها در برنامه‌نویسی Concurrent است.
می‌توان Concurrency نوشت و تصور کنید برنامه‌تان هم‌زمان اجرا می‌شود، اما Parallelism واقعی تحت کنترل شما نیست.
این OS و Scheduler هستند که تعیین می‌کنند چه زمانی و چگونه وظایف به‌طور موازی اجرا شوند.

@DevTwitter | <Amin Badin/>

YouTu.be/hD-AlSiPFwI

شایعه و چرت‌وپرت به سرعت برق‌وباد پخش می‌شه. این پیکان «هوشمند» هم روش.
کسی که فرستاده به کنار، فقط یکم فکر و تحلیل زمان لازم داره.

#note #موقت

اگه به هوش مصنوعی بگین یه پرامپت برام راجع به فلان موضوع بساز بعد همونو بدین به خودش قطعا نتیجه بهتری نمی‌گیرین...

اصل پایستگی خلاقیت


@Linuxor

صحبت نوستالژی شد، یه کتابی رو اخیرا یکی از دوستانم بهم معرفی کرد و شروع کردم به خوندنش (البته هنوز تموم نشده) و برام جالب بود. حالا که باز هم صحبت از نوستالژی شد، بد نمیبینم اینجا هم معرفی کنم.

«خلاف زمان» کتاب کوتاهیه از نشر اطراف که به نظرم ترجمه‌ی روونی داره هرچند با ارجاعات زیاد به روایت‌هایی که شاید چندان به نظر من خواننده آشنا نبود و ارجاعات متعدد به نظر فیلسوف‌های مختلف که خب من هیچ‌ایده‌ای از این که کی هستند نداشتم. یکی تو گودریدز تو بخشی از کامنتش نوشته بود:

نویسنده همینطور از سر و کولِ فیلسوفای بزرگ بالا رفته چون خودش "احتمالا" اعتماد به نفس کافی نداشته تا تئوری‌هاشو از سمت خودش بگه.

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

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

برای کاری نیاز بود که بیشتر راجع‌به DynamoDB بدونم و خب رسیدم به White Paper‌ای که تیمی از توسعه‌دهنده‌های Dynamo تو آمازون تو سال ۲۰۰۷ نوشتن راجع‌بهش که یک دیتابیس Key-Value‌ـه با هدف بیشینه کردن Availability با ضعیف‌تر کردن Consistency. البته نکته اینجاست که این ابزار، تنها برای استفاده‌ی داخلی در آمازون توسعه داده شد. DynamoDB اما چند سال بعد از این وایت‌پیپر، تو سال ۲۰۱۲، به‌عنوان یکی از سرویس AWS توسط آمازون معرفی شد و خب این‌طور استنباط می‌شه که از Dynamo و وایت‌پیپرش الهام گرفته.

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

For systems prone to server and network failures, availability can be increased by using optimistic replication techniques, where changes are allowed to propagate to replicas in the background, and concurrent, disconnected work is tolerated. The challenge with this approach is that it can lead to conflicting changes, which must be detected and resolved.

This process of conflict resolution introduces two problems: when to resolve them and who resolves them. Dynamo is designed to be an eventually consistent data store; that is, all updates reach all replicas eventually. An important design consideration is deciding when to perform the process of resolving update conflicts—whether conflicts should be resolved during reads or writes.

Many traditional data stores execute conflict resolution during writes and keep read complexity simple. In such systems, writes may be rejected if the data store cannot reach all (or a majority of) the replicas at a given time. On the other hand, Dynamo targets the design space of an “always writable” data store (i.e., a data store that is highly available for writes). For a number of Amazon services, rejecting customer updates could result in a poor customer experience.

For instance, the shopping cart service must allow customers to add and remove items from their shopping cart even amidst network and server failures. This requirement forces us to push the complexity of conflict resolution to the reads to ensure that writes are never rejected.

🔶 آموزش پروژه محور ساخت وب سایت شرکتی با لاراول

قیمت دوره ۱,۴۹۹,۰۰۰ تومان با تخفیف ۶۰ درصد ۵۹۹,۰۰۰ تومان

https://rayium.ir/course/?p=1613

به زودی این دوره ضبط می کنیم.

#لاراول

@TheRaymondDev

تست ستون پروژست!
و همونطور که خونه هایی هم هستن که قدیمی و کاه گلی اند و ستون ندارن، و یه بارون بزنه هم سقفشون میریزه، یا نمیشه به راحتی یا کلا بهشون طبقه اضافه کرد، پروژه هایی هم هستن که تست (ستون) ندارن،‌ و یه فیچر جدید بخوای اضافه کنی تمام فیچر های قبلی میترکه!

زیاد میشنوم که میگن تست به دیباگ کردن کد کمک میکنه، اما این ممکنه یکم گمراه کننده باشه.

این نکته کلیدی فراموش نشه که در خیلی از مدل های تست از جمله unit و integration، ما برای سناریو هایی تست مینویسیم، که سناریو اش رو میدونیم!
در این مدل تست ها، اگه باگی رو با تست دستی نتونیم پیدا کنیم، تست اتومات هیچ کمکی به ما نمیکنه.
پس در واقع با تست اتومات داریم استحکام چیزی که داریم رو تضمین میکنیم.

ولی خب، تو یه سری مدل تست ها مثل e2e و load test هم مجددا سناریو رو میدونیم، با اینحال ممکنه قسمتی از فلو (flow)، مطابق انتظار پیش نره، لود تست که کلا داستان خاص خودشو داره،
ولی تو e2e هم مجددا اگه ایراد پیش‌بینی نشده ای پیدا بشه، احتمالا در نقاط اتصال هست، و e2e هم تو پیدا کردن باگ لاجیکی غیرمنتظره، کمکی به ما نمیکنه.

<--×-->

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

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

<--×-->

راجع به دست و پا گیر بودن تست تو فاز های اولیه توسعه، عده ای معتقدن که اگه نیازمندی بیزنس شفاف نباشه، ما هم خود‌ کد و هم تست هاشو باید مدام تغییر بدیم، ولی سوال اصلی اینجاست که چرا نیازمندی بیزنس انقدر باید متغیر (و گنگ) باشه که ورودی و خروجی سیستم بارها، به کل تغییر کنه؟

غیر منطقی به نظر میاد،
اما منم بارها شاهدش بودم!
ولی مسئله اینجا تست نیست،
باید به خیلی قبل ترش نگاه کنیم،
همون جایی که نیازمندی بیزنس داره مشخص میشه.

<--×-->

از خوبی های جانبی تست هم میشه به "مثال بودن" اش اشاره کرد. با فرض دنیای ایده آل، خوندن تست های یه پروژه خیلی ساده تر از خوندن کد خود پروژست، و از رو تست هاش میشه به سادگی فهمید که چیکار میکنه و ورودی و خروجی مورد انتظار سیستم چی هست.
البته خب تو دنیای واقعی و غیر ایده آل، ممکنه یه دولوپر تازه کار مدعی سینیوریتی همین تست هارو فراپیچیده (over complex) کنه.

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

<--×-->

ولی خب در کل نظر شما راجع به تست چیه؟
مزایا؟ معایب؟ پیشنهاد؟ انتقاد؟ به من، به پست، به کانال و... 🙂🙌🏼

سعدی | دیوان اشعار | قطعات | قطعه شمارهٔ ۱۵ - تو از سنگ سخت‌تری!

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

#سعدی | گنجور
📍@iipoem