PyAction is released! 🔥✨

پای‌اکشن، یه تمپلیت کوکی‌کاتره که بهتون قابلیت نوشتن اکشن گیت‌هاب به زبان پایتون رو میده. خود گیت‌هاب بصورت پیشفرض، نوشتن اکشن بصورت Composite، Js و داکر رو ساپورت میکنه که این پیاده‌سازی برپایه داکر و پایتون هست. جدیدا یه اکشن هم به کمک این ابزار نوشتم که میاد و از سرویس کاوه‌نگار استفاده می‌کنه و توی ورکفلوهاتون، قابلیت ارسال SMS بهتون میده!

PyAction: github.com/lnxpy/cookiecutter-pyaction

Kavenegar Action: github.com/marketplace/actions/kavenegar-action

ادامه..

❇️ فیچرهای اولیه PyAction:

- ساپورت از پایتون ۲ و ۳
- ساپورت نصب دپندنسی ها از requirements.txt

- دسترسی به IO اکشن گیت هاب و قابلیت مقداردهی متغیر ها در هر Workflow

- تمپلیت آماده License و README
- آماده‌سازی اکشن واسه رلیز و پابلیش در GitHub Marketplace

برای استفاده از این ابزار، کافیه که cookiecutter رو نصب کنید و تمپلیت رو بسازید.

pip install -U cookiecutter

cookiecutter gh:lnxpy/cookiecutter-pyaction

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

استار یادتون نره :) ✨

یک پلاگین pytest نوشتم برای integration test که ممکنه به دردتون بخوره

تو اینتگریشن تست بعضا fixture هایی که استفاده میکنیم بسیار سنگین هستند. مثل مرورگر. برای ریست کردن اون fixture شما یک راه حلی که دارین اینه که اسکوپ تستون رو به فانکشن تغییر بدید که سر هر تست یک بار fixture تون مجدد نصب شه. ولی واقعا کاربردی نیست. چون fixture باید به اون استیت برسه دوباره که بتونه اون تست رو پرفوم کنه. مثلا میخواین چک ۱۰ تا اکشن تو یک صفحه view فرانتتون رو تست کنید. پس باید ۱۰ بار مروگر بالا بیارین و هر بار مرورگر بالا اوردن ۴ ثانیه طول میکشه. تستون ۴۰ ثانیه میشه فقط setup اش!

راه حل دوم چیه؟‌اینه که تو هر فایل شما کلی تست وابسطه به هم بنویسید. بعد با استفاده از پلاگین من اگه یکی از تستاتون fail شد بقیا تستای اون فایل رو xfail میکنه و اسکیپشون میکنه.
یعنی شما ۴ ثانیه یک مرورگر بالا میاری. بعد تو اون فایل واسه هر اکشن یک تست مینوسید. بعد مرورگر رو تو تست اول میبرین تو view ای که باید بره. بعد اکشن هارو تست میکنید. هرجایی هم fail شد مشکلی نداره دیباگ میکنیم فرانتو و دوباره تستو ران میکنیم. اینطوری ران تایم تست به شدت کاسته میشه.


البته این تو unit test اصلا توصیه نمیشه. تو unit test تو یک فایل نباید تستاتون به هم دیگه dependency داشته باشن.

کد پلاگین:

@pytest.fixture(scope="module", autouse=True)
def failure_marker(request: FixtureRequest):
    request.node._has_failures = False
    yield
    del request.node._has_failures


@pytest.fixture(autouse=True)
def check_failure(request: FixtureRequest, failure_marker):
    if getattr(request.node.parent, "_has_failures", False):
        pytest.xfail("Previous test failed")


@pytest.hookimpl(tryfirst=True, hookwrapper=True)
def pytest_runtest_makereport(item: Item, call):
    outcome = yield
    report: TestReport = outcome.get_result()
    if report.when == "call" and report.failed:
        parent: Node = item.parent
        parent._has_failures = True

@ManiFoldsPython

GitHub Actions in Python ✨✨

PyAction (cookiecutter): https://github.com/lnxpy/cookiecutter-pyaction

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

https://github.com/lnxpy/cookiecutter-pyaction/issues

کور دولوپرهای تیم Pydantic ✨

واقعا باعث افتخاره که حسن رمضانی هم عضوی از این تیمه. :) ❤️

یک سوال دارم از همتون,

چرا تو کامینیتی پستایی مثل دیزاین و کلین کد و اصول کد نویسی engage خیلی کمتری دارن؟‌ به جاش مثلا دیدم یک پستی راجب یک موضوع تخصصی تر تو پایتون خیلی engage بیشتری داره! یا مثلا پستم راجب sqlalchemy و tortoise که یک نصیحت و نظر شخصی ساده بود.

من تو دو کامینیتی روس هستم و میبینم ۲۴ ساعته حوزه سوالاتشون رو همین مباحث میچرخه. ولی احساس میکنم این تو بحثا تو کامینیتی ایران خیلی طرفدار نداره چون تاحالا هیچ پستی ازکانال که راجب این چیزا بوده engage نگرفته. البته هدف من engage گرفتن نیست ولی میخوام دلیلشو بدونم؟

نظره شخصیم اینه که هممون قرار نیست magic code بنویسیم. هممون قرار نیست اینترنال cpython رو خوب بلد باشیم. هممون قرار نیست پروژه big data داشته باشیم که مثلا یک جایی یک خطه کد efficient نبود پروداکشن زیر بار و فشار بره.

ولی هممون داریم رو یک پروداکت کار میکنیم که خیلی مهمه راحت بتونیم بهش فیچر اضافه کنیم و بیزنس fail نشه بخاطر دیزاین بدمون. هممون تست مینویسیم ولی حتی پستای تست نویسی منم engage خوبی نداشتن!

دلیل engage تو این بحثا نداشتمون چیه؟

@ManiFoldsPython

"من فکر میکنم بخاطر اینه که سطح usecase کامیونیتی پایتون فارسی در همین حد هست. کدی بنویسن که در درجه اول کار بکنه، در درجه دوم با پرفرمنس شوآف بکنن حتی اگه بهش نیاز نداشته باشن. درجه سوم هم نداره!😅"

چقدر حق بود این کامنت بابی!

من شخصا ترجیح میدم ۱۰۰ ساعت رو دیزاین وقت بذارم و بهتر یاد بگیرم تا اینکه ۱ ساعت رو cpython internal وقت بذارم. اونا هم فانه و قطعا دوست داشتنیه. ولی حقیقتا کاربرد کاری نداره براتون مگه maintainer لایبری اوپن سورس هستین.

من تو کانالم هر مطلبی نوشتم صرفا "یادداشت روزانم" بود. اینطور نیست که این مطالب رو همیشه بلد بودم. خیلیاشو همون روز یاد گرفته بودم. یادداشت میکنم چون بازنویسی و توضیحش به بقیه باعث میشه خودتون یک مبحث رو بهتر یاد بگیرین. و البته بحث کردن راجبش که باعث میشه ایده و نظرات بقیه رو بشنوید و یاد بگیرین. من واقعا دوست دارم پست میذارم ایرادی داره کلی کامنت و engage ببینم که به اون ایراد پرداخته شده. تو همون کامینیتی روسی پایتون که من هربار ریپویی یا کدی گذاشتم ترور شدم :)) و همون ترورا باعث شده که پیشرفت کنم.

مثال ‍DIP رو زدم امروز چون واقعا با پوست و گوشت حس کردم چقدر خفنه! تسک این هفته من این بود که admin role بنویسم برای بک اندمون, و کل این کار فقط با ۴۰ خط کد انجام شد. اضافه کردن یک implementation در راستای پروتکل authorization ای که داریم برای هر role. و return True تو همه حالت ها. حالا همون روتر هایی که داشتیم رو میتونیم با admin صدا بزنیم و بدون اینکه یک queryجدید هم اضافه کرده باشم دسترسی super user رو implement کردم. ولی تو کامینیتی ایران این خودش یک تسک چند هفته ایه :)) .

من این پستا رو ادامه میدم حتی اگه engage زیادی نداشته باشه ولی امیدوارم این کالچر توی کامینیتی پایتون ایران نفوذ کنه.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" - Martin Fowler

@ManiFoldsPython

بچه‌هایی که پکیج پایتون می‌نویسید و در pypi منتشر می‌کنید، دوست دارید چنین نمودارهایی از وضعیت دانلود و نرخ پکیجتون توی README قرار بدین؟

یه آپدیت خفن دادم روی بورد!

سنسور حرکتی، شتاب سنج بود که تغییرش دادم به ژیروسکوپ. الان مثل دسته VR عمل می‌کنه. کلیک چپ اضافه کردم. (دکمه پایینی)

مکانیزم کنترل اضافه کردم. باید دکمه بالا رو نگه داری تا کرسر حرکت کنه.

قابلیت scroll اضافه کردم. باید دوتا دکمه رو نگه داری، بورد رو به هر سمت متمایل کنی، اسکرول میشه به اون سمت.

یه فیچر دیگه هم اضافه کردم که بشه بصورت داینامیک، سنس کرسر رو تغییر بدی. همون پتانسیومتر که مشخص کردم توی تصویر.

می‌خواستم وایرلسش کنم که ماژولش دم دست نبود. اگه تایمی بود، شاید وایرلسش کردم و آوردمش روی دستکش. 🧤✨

Live coding assignment: School Student App

لینک گوگل میت:
https://meet.google.com/mum-umcx-qwt

یک شنبه ساعت ۲۰ تا ۲۱:۳۰

۱۵ دقیقه اول فقط تسک رو میخونم. خیلی مهمه این موضوع. سعی کنید miss نکنید ۱۵ دقیقه اولو.

مفاهیمی که تو ۱۵ دقیقه اول توضیح داده میشه:

طریقه خواندن یک assignment

Software Requirements
Software Test Scenarios
Software Test Cases
Software Test Runs
Technology Requirements
Explicit ACL Design
Database Table Design

فرقی نمیکنه بک اند کار هستین یا نه ولی حداقل تا قبل از ACL Design باید بلد باشین چون مفاهیم software development lifecycle(SDLC) هست.

@ManiFoldsPython

Tell where you live without telling where you live:


💔

از مدل رگرسیون mindsdb استفاده کردم و با ۵۰۰ رکورد از دیتای pypi ترینش کردم.

الان یه پردیکشن زدم، تخمین زده مجموع تمام دانلود های یه پکیج پایتون تا فردا فلان قدر خواهد بود. نایس. :)) ❤️

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

نوشتن گیت‌هاب اکشن با پایتون!

در این مقاله ۵ دقیقه‌ای، از PyAction استفاده کردیم تا یه اکشن Hello World خیلی ساده بنویسیم. اکشنمون به این صورته که یه اسم بهش می‌دیم و اون اکشن در محیط اجرایی Workflow، یه مسیج Greeting بهمون نمایش میده.

مطالعه مقاله: https://imsadra.me/writing-github-actions-in-python
پای‌اکشن: https://github.com/lnxpy/cookiecutter-pyaction

امیدوارم مفید باشه :) ❤️

چطوری با ابزار PyAction کار کنیم ؟

خب قبل از همه باید یه اکشن بسازیم . به دلیل اینکه PyAction از cookiecutter برای تولید تمپلیت استفاده میکنه. پس اول از همه باید cookiecutter را نصب کنیم با استفاده از دستور زیر:

pip install -U cookiecutter

بعد از نصب برای اینکه مطمئن بشید درست نصب شده دستور زیر را اجرا کنید:

cookiecutter -V

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

cookiecutter gh:lnxpy/cookiecutter-pyaction

بعد از اجرای این دستور یه سری سوالاتی از شما میپرسه .
Action name: نام اکشن شما
Project slug : آدرس فولدر یا ریپو
Python version: نسخه ی پایتون
Include dependencies: دپندسی های مورد نیاز
Branding Icon: Feather icons (وارد سایت بشید و اسم آیکون مورد نظر را توی این فیلد بنویسید. این آیکون را گیت هاب نشون میده)
Branding color: رنگ آیکون

> اگه قصد دارید اکشنتون رو توی GitHub Marketplace منتشر کنید مطمئن بشید که Action name ای وارد نکنید که تکراری باشه

بعد از اینکه به سوالات جواب دادید . یه فولدر جدیدی به نام چیزی که توی Project slug بهش دادید براتون میسازه .
تنها چیزی که باید تغییر بدیم فایل های action.yml، main.py و README.md هستند.
بعد از اینکه کار ستاپمون رو تموم کردیم وقت اینکه اولین اکشن خودمون رو بسازیم :)‌

توی این گیت هاب اکشن ما میخوایم به کاربر ها این امکان رو بدیم که متغیری بنام ‍‍name را به workflow ما بفرستند و و پیامی با محتوای :
Hello {name}
را ببینند

ادامه پست بعدی:

🆔 @MdDaily

برای این کار فایل action.yml ما باید دو بخش inputs و outputs را ویرایش کنیم:

...
# == inputs and outputs ==

inputs:
  name:
    required: false
    description: the person/thing you want to greet
    default: World

outputs:
  phrase:
    description: output message

با این روش کاربر ها میتونند موقع استفاده از اکشن ما مقدار name را تنظیم کنند و بعدش از طریق متغیر phrase خروجی پیام را ببینه.

و اما میریم سراغ main.py :

import os
import sys
from typing import List

from actions import io


def main(args: List[str]) -> None:
    """main function

    Args:
        args: STDIN arguments
    """

    # reading the name variable from `with`
    name = os.environ["INPUT_NAME"]

    # writing to the buffer
    io.write_to_output({"phrase": f"Hello {name}"})

    # now, people can echo `phrase`


if __name__ == "__main__":
    main(sys.argv)

کارما تقریبا تمومه و الان وقت تسته . برای تست فقط کافیه توی ریپوی گیت هابتون یه workflow بسازید . محتوای فایل main.yml:

# .github/workflows/main.yml
name: Testing My hello-world Action

on: workflow_dispatch

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - id: greetings
        name: Using نام اکشن شما
        # use the action that's inside the same repository
        uses: ./
        with:
          name: @MdDaily

      - name: Echo phrase
        run: |
          echo ${{ steps.greetings.outputs.phrase }}

و تمام :)
بعد از ذخیره میتونید به تب Actions ریپوی گیت هابتون برید روی Run Workflow کلیک کنید و تا تموم شدن بیلد اکشن منتظر بمونید.
توی لاگ های build میتونید بخش Echo phrase را باز کنید و خروجی echo و پیام مورد نظر را ببینید.


لینک های مفید:
https://github.com/lnxpy/cookiecutter-pyaction
https://github.com/lnxpy/pyaction-hello-world
https://haya14busa.github.io/github-action-brandings/

🆔 @MdDaily

دم کاکام سید مهدی گرم. ❤️
براتون ترجمه کرد به فارسی. چی بهتر از این. 😍😘

سید اینجاست:
@seyedmahdidiary

ترجمه اصلی از ماهان هست:
@MdDaily

این پست Falsehood رو یادتونه؟‌این سبک یاد گیری بنظرم خیلی خوبه. حالا بریم راند دو :))

1. If the code works, it is clean.
2. Comments are unnecessary if the code is written clearly.
3. Clean code is always easy to understand, regardless of the complexity of the problem.
4. Writing clean code will always take more time than writing quick-and-dirty code.
5. Clean code means having no duplication whatsoever.
6. Adhering strictly to a particular coding standard or style guide guarantees clean code
7. Clean code is only about readability and has nothing to do with maintainability
8. Refactoring a working codebase to make it cleaner is usually a waste of time.
9. Using many design patterns guarantees that the code is clean
10. Clean code can only be achieved by senior developers; beginners cannot write clean code
11. Testing is a separate concern from writing clean code and doesn't contribute to it
12. A piece of code is clean if it passes all linters and automated style checkers.
13. Following SOLID principles blindly, without understanding the context, will always result in clean code
14. Clean code doesn't need documentation outside of the code itself
15. Clean code is a fixed goal, not an ongoing process; once the code is clean, it will stay that way without continuous effort.

اونایی که مهم تر بودن رو بولد کردم. کلش بولد شد :))
@ManiFoldsPython