https://virgool.io/feed/@sorousht fa 2026-06-07 14:30:04 https://files.virgool.io/upload/users/5091/avatar/q2h3D9.png?height=120&width=120 https://virgool.io/@sorousht https://virgool.io/@sorousht/%D9%85%D8%B4%D8%A7%D8%B1%DA%A9%D8%AA-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA-%D8%AC%D8%A7%D9%85%D8%B9%D9%87-%D8%AA%D9%88%D8%B3%D8%B9%D9%87%D8%AF%D9%87%D9%86%D8%AF%DA%AF%D8%A7%D9%86-%D9%81%D8%A7%D8%B1%D8%B3%DB%8C-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B1%DB%8C%D8%A7%DA%A9%D8%AA-adxkdpgigilt به ندرت کتابخانه‌ها و تکنولوژی‌هایی که توسعه‌دهندگان نرم‌افزار استفاده می‌کنند، اسنادشان را به صورت رسمی به زبان فارسی عرضه کرده‌اند. اما جامعه reactjs.org از یک ماه پیش پروژه ترجمه اسناد ری‌اکت را کلید زد و در حال حاضر ۳۸ تیم از کشورهای مختلف درحال ترجمه اسناد به زبان خودشان هستند.تیم فارسی هم تشکیل شده اما اپتدای راه قرار دارد!چرا باید ترجمه شود؟شاید بعضی افراد فکر کنند ترجمه به زبانی مثل فارسی کار بیهوده‌ای هست، مادامی که زبان دانش فنی توسعه نرم‌افزار انگلیسی است! اما برای من، مشارکت در توسعه اسناد ری‌اکت به زبان فارسی یکی از با ارزش‌ترین فرصت‌هایی است که به من داده شده‌است. چون:تطبیق با روش فکری ری‌اکت و مفاهیم اولیه آن در شروع کمی سخت است. اسناد فارسی راه ورود تعداد بیشتری از علاقه‌مندان به توسعه وب را هموار می‌کند.اگر حرکتی در راستای یافتن معادل‌های مناسب برای عبارات فنی این حوزه و باعث فراگیری آن‌ باشد، هر چند هم کوچک، بسیار با ارزش است.فرصتی است برای تبادل نظر درباره مفاهیم عمیق ری‌اکت و یافتن دوستانی است که دغدغه‌هایی مشابه دارند.کسی که ترجمه می‌کند، خودش بهتر یاد می‌گیرد!چه کسانی می‌توانند مشارکت کنند؟فقط کافیست به این کار علاقه‌مند باشید و به زبان انگلیسی آشنایی داشته باشید. اگر برنامه نویس هستید، تجربه شما خیلی به کمکتان می آید. اما اگر تازه می خواهید وارد دنیای هیجان‌انگیز نرم‌افزار شوید، فرصتی طلایی برای شماست! مشارکت کنندگان با تجربه‌تر هنگام شروع به شما کمک خواهند کرد و به سوالات شما پاسخ خواهند داد.از کجا شروع کنم؟به صفحه گیت‌هاب پروژه fa.reactjs.org بروید. در توضیحات موضوع 1# لیست صفحاتی که نیاز به ترجمه دارد آورده‌ شده‌است. اولویت ما شروع از صفحات Core Pages، با ترتیبی است که مشخص شده‌است. یکی از صفحاتی را که به موضوع آن علاقه‌مند هستید را برای شروع انتخاب کنید.نکته:ترجمه صفحاتی که ✅ دارند انجام شده‌‌است.اگر شناسه کاربری گیت‌هاب شخصی کنار عنوان صفحه درج شده‌است، آن شخص ترجمه را برعهده گرفته‌است.با نوشتن یک کامنت روی موضوع 1#، به نگاه‌دارندگان اطلاع دهید که تمایل دارید روی ترجمه چه صفحه‌ای کار کنید. پس از تایید، نام‌کاربری گیت‌هاب شما روبروی آن درج و به ترجمه آن صفحه به شما واگذار می‌شود.لیست صفحه‌هایی که نیاز به ترجمه دارند. شخصی که به عهده گرفته و وضعیت انجام آن را می‌توانید مشاهده کنید.تمامی اسناد با فرمت Markdown نوشته شده‌است. پس نیازی به دانستن زبان برنامه نویسی یا خواندن کد ندارید. فقط کافی است با استاندارد نگارش آن آشنا شوید. صفحه معرفی هوک‌ها مثال خوبی از یک صفحه ترجمه‌شده است که در اپتدای کار می‌تواند الهام‌بخش شما باشد.جزئیات بیشتر برای مشارکت‌کنندگان نوشته شده‌است که مطالعه آن‌ها پیش از دست‌به‌کار شدن، به ترتیب زیر پیشنهاد می‌شود:۱. راهنمای مشارکت‌کنندگان۲. شیوه نگارش۳. واژه‌نامهیادداشت:تا امروز یکی از چالش‌های تیم در این مسیر، انتخاب واژه و معادل‌های مناسب برای عبارات فنی بوده‌است. یافتن معادل فارسی مناسبی که تقریبا در جامعه توسعه‌دهندگان نرم‌افرار پذیرفته شده‌باشد و همچنین از خوانایی و اعتبار متن نکاهد، بسیار دشوار است. به همین منظور، تصمیم بر این شد که گروهی از واژه‌ها یا عبارات ترجمه نشود و دقیقا عین آن در متن استفاده شود.مشارکت شما در تکمیل و تصحیح واژه‌نامه بسیار مورد نیاز تیم است و ما بسیار قدردان آن خواهیم بود.بیشتر ارتباطات و هماهنگی‌ها در گیت‌هاب پروژه انجام می‌شود. برای مواردی که نیاز به بحث دارد از اسلک استفاده می‌کنیم. ما خوشحال می‌شویم که شما همراه جمع ما باشید، پس اگر تمایل دارید، آدرس ایمیل خود را برای ما ارسال کنید تا دعوت‌نامه‌ای از طرف تیم ترجمه فارسی ری‌اکت دریافت کنید. سروش ترک‌زاده سروش ترک‌زاده Sun, 03 Mar 2019 20:34:16 +0330 https://virgool.io/Software/%D8%AD%D8%B1%D9%81%D9%87-%D8%A7%DB%8C-%D9%87%D8%A7-%D9%BE%DB%8C%D8%A7%D9%85-%DA%A9%D8%A7%D9%85%DB%8C%D8%AA-%D8%B1%D8%A7-%DA%86%D8%B7%D9%88%D8%B1-%D9%85%DB%8C-%D9%86%D9%88%DB%8C%D8%B3%D9%86%D8%AF-ouopo27oknul پیامی که برای یک کامیت گیت می نویسید بسیار ارزشمند است! توسعه‌دهندگانی که در تولید پروژه‌های بزرگ سهیم هستند، می دانند که بهترین راه انتقال مفاهیم فضای آن پروژه به یک تازه وارد یا حتی برای آینده خودشان، همین توضیحاتی است که درباره تغییرات کد نوشته می‌شود. اگر برای پیدا کردن یک تغییر قدیمی در کد‌ها، تجربه‌ی ساعت‌ها کار با `git log` و ابزار‌های جانبی را داشته باشید، قطعا قدر همکاری که پیام کامیت‌ها را با دقت نوشته‌است را به خوبی می دانید و برعکس!کامیت‌هایی از جهنم: نمونه‌ای از پیام‌های ناکارآمد در یک پروژه شخصیچرا پیام کامیت مهم است؟موفقیت یک پروژه در بلندمدت به نگهداری و مدیریت آن بستگی دارد که به عهده‌ی مشارکت‌کنندگان اصلی آن است. مهم‌ترین ابزاری که آن‌ها در اختیار دارند، لاگ تغییرات کدها است. تنها با وجود پیام‌‌های دقیق و استاندارد است که دستور‌های `revert`، `blame`، `git rebase` و `log` کاربرد پیدا می‌کنند و بررسی کامیت‌های دیگر مشارکت‌کنندگان ممکن می‌شود. حتی فهمیدن تغییری که ماه‌ها یا سال‌ها پیش افتاده است نه تنها ممکن، بلکه به شکل بهینه‌ای انجام خواهد شد.در بیشتر زبان‌های برنامه‌نویسی و پلتفرم‌ها اسنادی تهیه شده‌است که چگونگی نوشتن کد‌، نامگذاری متغییرها، فاصله‌ها و ... را به عنوان قراردادهایی (codding style) بیان می‌کند. حتی میان اعضای یک تیم کوچک هم قراردادهایی برای حفظ یکپارچگی کد در نظر گرفته می‌شود. شیوه‌ی نوشتن پیام کامیت‌ هم از این قاعده پیروی می‌کند. برای داشتن یک تاریخچه‌ی موثر از کامیت‌ها، وجود یک قالب استاندارد که سه ویژگی زیر در آن رعایت شده‌باشد، ضروری است:۱. ساختار: شامل قواعد دستوری، فاصله، حاشیه و نشانه‌گذاری است.۲. محتوا: چه اطلاعاتی به عنوان توضیح یک کامیت مورد نیاز است؟۳. متادیتا (metadata): اطلاعات اضافه‌ای که برای ارجاع به ایشیو (issue)، پول ریکوست (pull request) یا یک کامیت دیگر ذکر می‌شود.هفت قانون طلاییقواعد نوشتن پیام استاندارد برای یک کامیت در ۷ مورد خلاصه می‌شود۱. حرف اول عنوان بزرگ نوشته شودSimplify PCM open/close callbacks۲. طول عنوان بیشتر از ۵۰ حرف نباشدامکان نوشتن عنوان بیش از ۵۰ حرف وجود دارد، اما عایت این قانون برای اطمینان از نوشتن یک عنوان کوتاه و خوانا است.Change resized buffers atomically Avoid superfluous usb_set_interface() calls Check PCM state at xfern compat ioctl۳. عنوان به صورت امری نوشته شودنوشتن عنوان به صورت امری در نگاه اول عحیب به نظر می رسد! اما خود گیت هم از این شکل برای نوشتن پیام‌ها استفاده می‌کند:Merge pull request #123 from someone/somebranch۴. یک خط فاصله میان عنوان و متن باشدFix races at MIDI encoding in snd_virmidi_output_trigger() The sequencer virmidi code has an open race at its output trigger callback: namely, virmidi keeps only one event packet for processing while it doesn't protect for concurrent output trigger calls. snd_virmidi_output_trigger() tries to process the previously unfinished event before starting encoding the given MIDI stream, but this is done without any lock. Meanwhile, if another rawmidi stream starts the output trigger, this proceeds further, and overwrites the event package that is being processed in another thread. This eventually corrupts and may lead to the invalid memory access if the event type is like SYSEX.۵. در انتهای عنوان نیازی به نشانه‌گذای نیستحتی یک حرف هم ارزشمند است و نیازی به استفاده از نشانه‌هایی مانند `!?.` نیست۶. طول خطوط در متن کمتر از ۷۲ حرف باشدبرای اطمینان از خوانا بودن و نمایش یکسان متن کامیت، پیشنهاد می‌شود که خود نویسنده در هر خط با رسیدن تعداد حروف به حدود ۷۲، با زدن کلید enter به خط بعد برود. نرم‌افزارهای ویرایشگر متن در این مورد دارای تنظیمات مختلفی هستند و حتی خود گیت هم محدودیتی در نمایش طول خطوط متن در نظر نمی‌گیرد.۷. در متن پیام به جای توصیف چگونگی انجام تغییرات، دلیل کامیت را توضیح دهیدبا مشاهده تغییرات فایل‌ها در یک کامیت و صرف کمی وقت، چگونگی انجام تعییرات مشخص می‌شود. اما چیزی که پس از گذشت زمان فراموش خواهد شد، دلیل انجام آن تعییرات است! jfs: Fix usercopy whitelist for inline inode data Bart Massey reported what turned out to be a usercopy whitelist false positive in JFS when symlink contents exceeded 128 bytes. The inline inode data (i_inline) is actually designed to overflow into the "extended area" following it (i_inline_ea) when needed. So the whitelist needed to be expanded to include both i_inline and i_inline_ea (the whole size of which is calculated internally using IDATASIZE, 256, instead of sizeof(i_inline), 128). $ cd /mnt/jfs $ touch $(perl -e 'print "B" x 250') $ ln -s B* b $ ls -l >/dev/null [ 249.436410] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'jfs_ip' (offset 616, size 250)! Reported-by: Bart Massey <bart.massey@gmail.com> Fixes: 8d2704d ("jfs: Define usercopy region in jfs_ip slab cache") Cc: Dave Kleikamp <shaggy@kernel.org> Cc: jfs-discussion@lists.sourceforge.net Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>متادیتاگیت‌هاب با دیدن یک کلمه کلیدی و شماره ایشیو مانند `close #123` در متن پول ریکوست یا کامیت، به صورت خودکار بین پول ریکوست و ایشیو ارتباط برقرار می‌کند و با تایید تغییرات و ادغام شدن آن در مخزن کد، به صورت خودکار ایشیو مربوطه را با برچسب closed نشانه‌گذاری می‌کند. لیست عبارت‌هایی که گیت‌هاب در پیام کامیت به دنبال آن‌ها می‌گردد، در زیر آمده‌است:close closes closed fix fixes fixed resolve resolves resolvedدر مثال قانون شماره ۷، از یک نمونه متادیتا برای بستن ایشیو شماره `8d2704d` استفاده شده‌است.و در آخر، مشتاقانه منتظر شنیدن دیدگاه شما هستم...منابعhttps://chris.beams.io/posts/git-commit/https://github.com/torvalds/linux/commits/masterhttps://help.github.com/articles/closing-issues-using-keywords/ سروش ترک‌زاده سروش ترک‌زاده Fri, 10 Aug 2018 19:03:52 +0430