https://virgool.io/feed/@taha طاها یک مبتدی جاودانه است. دریانورد بوده، بعدها برای شهرنشین شدن بیمه‌های دریایی را انتخاب کرده، برنامه‌نویسی هم ظاهراً کمی بلد است. fa 2026-04-14 15:10:24 https://files.virgool.io/upload/users/332/avatar/XmOAgC.png?height=120&width=120 https://virgool.io/@taha https://virgool.io/@taha/scrum-planning-k3uiffrxltk1 کرونا مرگبار و جدی است و باید از آن ترسید. اما این نوشته، به اسکرام مربوط است.کرونا مرگبار و جدی است و باید پیش‌گیری کنید. اما این پست درباره کرونا نیست.تصور کنید در جلسه‌ی اسکرام تیم خود نشسته‌اید تا برای اسپرینت پیش رو برنامه‌ریزی کنید. بک‌لاگ را هم بدون ورود به جزئیات مرور کرده‌اید و حالا نشسته‌اید و مالک محصول، کارها را یکی یکی در می‌آورد و توضیح می‌دهد و شما و بقیه‌ی تیم اسکرام، به آن وزن عملیاتی می‌دهید (Story Point).اول صبح به نظر می‌رسید که پای کار عجیب و غریبی در میان نباشد. اما وقت مرور جزئیات یکی از کارها، و احتمالاً سؤال یکی از هم‌تیمی‌ها و پاسخ مالک محصول، معلوم می‌شود با کاری طرفید که هیچ ایده‌ای برای انجامش ندارید و در حد ظاهر کردن یک فیل وسط اتاق، مبهم و ترسناک به نظر می‌رسد!همیشه این طور بود که اگر شما ایده‌ای نداشتید، یک نفر دیگر در تیم داشت و همین که کلمه‌ای درباره‌اش سخن می‌گفت سرنخ را به دست می‌گرفتید و در ذهنتان تا انتها می‌رفتید و بعد می‌توانستید بزرگی آن کار را تخمین بزنید و این سرنخ دادن، جمعاً یک دقیقه هم وقت نمی‌گرفت.همیشه این طور بوده که اگر تیم فنی کاری را بسیار زمان‌گیر و دشوار تشخیص می‌داد، مالک محصول نیز کمی عقب‌نشینی می‌کرد و آن ویژگی را تعدیل می‌کرد یا به زمان دیگری موکول می‌کرد که فرصت فکر کردن فراهم شود.اما این بار هیچ کدام از آن «طور»ها پیش نیامده. هیچ کس ایده‌ای ندارد و بعضی‌ها هم که سرنخی دارند، نمی‌دانند چقدر ممکن است کار ببرد. مالک محصول هم بار دیگر خاطرنشان می‌سازد که بچه‌ها، این را حتماً لازم داریم و بیشتر بخش‌های بعدی به آن وابسته هستند.همه با هم مشغول بحث می‌شوید و ایده‌هایتان را می‌گویید. اسکرام مستر هم که می‌بیند اوضاع خوب نیست، مدارا می‌کند و چیزی نمی‌گوید. دو دقیقه می‌گذرد و به دقیقه‌ی سوم می‌رسید و بعد هم چهارم و پنجم، و نهایتاً صدای اسکرام مستر که تا همین جا هم خیلی خیلی ارفاق کرده درمی‌آید و خواهش می‌کند بحث فنی نکنید!خب چه کار کنید؟ بحث فنی نکنید؟ پس چطور در مورد چیزی که نمی‌دانید چطور انجامش دهید تخمین بزنید؟ بعدی‌هایش چه می‌شوند که تا شب همین بساط است؟به تجربه دیده‌اید و دیده‌ایم که احتمالاً اگر تیم فنی نیم ساعت وقت داشته باشد فکری می‌کند و راه‌حلی می‌یابد، اما نمی‌شود جلسه را نیم ساعت به تعویق انداخت، چون آدم‌های فنی عاشق بحث فنی هستند و تا ابد می‌توانند حرف بزنند و کاری نکنند. پس بهتر است جلسه را ادامه بدهید. اما کارهای بعدی به این کار دشوار و مبهم وابسته هستند و ذهن شما و همکارانتان را درگیر می‌کند. حق هم دارید. فرض کنید به شما گفته باشند فیلی ظاهر کنید و از آن عکس بگیرید. وقتی نمی‌توانید فیل را ظاهر کنید، عکس گرفتن هم منتفی است.این جور وقت‌ها یک نفر باید پیدا شود و بگوید بچه‌ها، الآن که قرار نیست عکس را بگیریم. در این جلسه فقط قرار است ببینیم عکس گرفتن چقدر سخت و پیچیده است. ذهن‌های ما باید با تمرین به جایی برسند که فرض کنند کاری انجام شده و بر اساس آن فرض، برای کارهای بعدی برنامه‌ریزی کنند. طبیعتاً «فرض کرده‌ایم» که آن کار انجام شده و اگر پای عمل رفتیم و دیدیم که واقعاً نشدنی است، اجرای کارهای وابسته هم منتفی است و تمرین ذهنی هم به درد نمی‌خورد. اما شاید هم فرضمان درست از آب درآمد.این جور وقت‌ها نترسید و به برنامه‌ریزی ادامه دهید. اول باید فیل را ظاهر کنید و بعد از آن عکس بگیرید و تا فیلی ظاهر نشده، عکسی در کار نیست. اما فرض کنید فیل را ظاهر کرده‌اید و حالا می‌خواهید دربارهٔ عکس گرفتن تخمین بزنید.این کار شدنی است و برنامه‌ریزی‌ها را هم به خطر نمی‌اندازد. جلسه را پیش ببرید و بعداً سر وقت فیل‌ظاهرکن‌های تیم را دور هم جمع کنید و چاره‌ای بیاندیشید.نگران کمی تغییر در پیش‌بینی‌ها هم نباشید. خوبی اسکرام همین است که از اشتباه کردن نمی‌ترسید، چون مطمئن هستید که زود به اشتباه پی می‌برید و چیزی دامنه‌دار نمی‌شود. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Thu, 27 Feb 2020 13:50:07 +0330 https://virgool.io/@taha/laravel-workshop-rxvzhw5zrx8o به نظرم یک کارگاه کوچک یک روزه، به خیلی‌ها کمک می‌کند با فریمورک لاراول آشنا شوند و بفهمند که به کارشان می‌آید یا نه. من چند سال تجربه‌ی هدایت تیم‌های کوچک بیش از پنج نفر را داشته‌ام و تصور می‌کنم تجربه‌های اندکم به درد خیلی‌ها بخورند.قرار نیست تشریفاتی در کار باشد. فایدهٔ خودمانی بودن این است که هم هزینه‌ها پایین می‌آید و هم احتمالاً بازدهی بالاتر می‌رود.ایده خیلی ساده است که عرض می‌کنم.چه می‌کنیم؟صبح با لپتاپ‌هایمان دور هم جمع می‌شویم و شروع می‌کنیم.اول همان جا در جمع، یک پروژه‌ی ساده و آشنا انتخاب می‌کنیم؛ چیزی مثل یک سرویس سادهٔ پشتیبانی، یا نوبت‌دهی آنلاین، یا حتی یک وبلاگ معمولی.بعد نقشهٔ کلی طرح را می‌کشیم و به سبک اسکرام کار را به user-storyهای کوچک می‌شکنیم و مرتب می‌کنیم و به دیوار می‌چسبانیم.بعد یکی یکی شروع به انجام دادن کارها می‌کنیم. گاهی همزمان کد می‌نویسیم و گاهی هر کدام جدا جدا می‌نویسیم و مرور می‌کنیم و خلاصه خوش بگذارنیم.در این بین سعی می‌کنیم اصول کدنویسی تمیز را رعایت کنیم، وفاداری به قوانین PSR را بیاموزیم، برای کدهای خود داکیومنت بنویسیم، و حسابی هم از گیت استفاده کنیم.از کجا شروع می‌کنیم؟طبعاً شرکت‌کننده‌ها باید لپتاپ داشته باشند، با php آشنا باشند و این زبان و نیازمندی‌هایش روی کامپیوترهایشان نصب و آماده‌ی استفاده باشد. از این که بگذریم، دو سناریو در ذهن دارم.یکی این که فرض کنیم همه فقط پی‌اچ‌پی بلد هستند و پروژه‌مان را با لاراول اجرا کنیم، دیگر آن که فرض کنیم همه لاراول بلد هستند و پروژه‌مان را با معماری ماژولار روی همان لاراولی که همه بلدیم اجرا کنیم.انتخاب، با شرکت‌کنندگان خواهد بود.چه هزینه‌ای دارد؟این کارگاه رایگان خواهد بود و باید روی قول کسانی که می‌گویند شرکت می‌کنند حساب باز کنیم تا واقعاً شرکت کنند و حقی از کسانی که نتوانسته‌اند بیایند ضایع نشود و ظرفیت بی‌استفاده نماند. غیر از این هزینهٔ مالی که وجود ندارد، شما از وقت خود برای یک روز هزینه می‌کنید و احتمالاً پول ناهاری که میل می‌کنید را می‌پردازید. خوبی یک روزه بودن،‌ این است که اگر هیچ فایده‌ای هم نداشته باشد، فقط یک روز تلف شده است:‌ یک شکست زودهنگام!کجا برگزار می‌کنیم؟شرکت ما در تهران، امکانات لازم را برای نشستن و کار کردن شش تا هفت نفر، مانیتوری بزرگ و یک تخته‌ی وایتبرد دارد و می‌توانیم از همان استفاده کنیم. اگر در تهران جای بهتری را می‌شناسید که می‌توانید بدون هزینه هماهنگ نمایید، به من پیام بدهید.در شهرهایی غیر از تهران هم اگر چند نفر شوید و فضایی با امکاناتی که گفتم فراهم کنید، می‌توانم بیایم و یک روز با هم باشیم. مانیتور بزرگ (یا ویدیوپروژکتور) و تخته‌ی وایتبرد هم زیاد اجباری نیست. همین که برق و اینترنت داشته باشد و بتوانیم چند ساعت پیاپی بلند بلند با هم حرف بزنیم، کافی به نظر می‌رسد.چطور ثبت نام کنیم؟این کارگاه لزوماً یک بار برگزار نمی‌شود، و با توجه به زمان و وقتم، و بازخوردی که می‌گیرم، سعی می‌کنم ادامه بدهم.فرم کوتاه زیر را پر کنید و منتظر بمانید تا شرایط دیگر جور شود و تماس بگیرم. همین.طبعاً ظرفیت من محدود است و اولویت با آن‌هاست که زودتر فرم را پر کرده باشند. (:https://forms.gle/rXsCkmfZvHAx8s1PAلینک فرم طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Mon, 03 Feb 2020 15:22:21 +0330 https://virgool.io/@taha/%D9%85%D8%B1%DA%AF-%DB%8C%DA%A9-%D8%B4%D8%BA%D9%84-tkzt7fjxjayy زیاد می‌شنوم و می‌خوانم که می‌گویند و می‌نویسند «اینترنت بین‌المللی» در ایران قطع شده است. چیزی با این نام وجود ندارد. آنچه در ایران قطع شده، «اینترنت» است. شبکه‌ای که هنوز به آن وصلیم و «اینترنت ملی» خوانده می‌شود، شبکهٔ ملی اطلاعات است که خیلی شبیه اینترنت عمل می‌کند، اما اینترنت نیست. کسب‌وکارهای زیادی هستند که به طور مستقیم از این قطعی اینترنت آسیب می‌بینند و تقریباً هر شغلی که تصور کنیم، از این راه به طور غیر مستقیم آسیب می‌بیند.ولی چه باک؟ صاحب ما صلاح دیده که قطع شویم، و قطع می‌شویم.حداقل یک شغل را می‌شناسم که با ادامهٔ این روند، خواهد مُرد. برنامه‌نویسان گزینه‌های زیادی پیش رو ندارند. یا باید کار جدیدی یاد بگیرند و به آن بپردازند، یا همچون بسیاری دیگر که زودتر به فکر افتاده‌اند، رنج هجرت را به جان بخرند و ترک خانه و خاندان کنند، یا سر فرود آورند و جیره‌خواری پیشه کنند تا به تشخیص نگهبان‌ها، کمی از آب حیات اینترنت، هر قدر که صلاح بدانند، در گلویشان ریخته شود.این راه آخری، چیزی شبیه همان «اینترنت ملی» است که وجود ندارد و سایه‌ای و اندک نامی از آنچه که دیگر وجود ندارد را با خود یدک می‌کشد.به این ترتیب، خیلی راحت و آسان، با تصمیم یک عده‌ی محدود که تعدادشان ده نفر هم نیست، شغلی که دست بر قضا یکی از امیدوارکننده‌ترین کسب‌وکارها در این بیابان ناامیدی بود، به حال مرگ و احتضار افتاده است.شما که در یک شرکت برنامه‌نویسی شخص تصمیم‌گیرنده‌ای هستید، بیشتر از آن که به فکر استوری‌های این اسپرینت و اسپرینت بعدتان باشید، به یکی از سه راه بالا فکر کنید. با تداوم شرایط فعلی، شما در حال مرگید.نه کسی دست شما را می‌گیرد و نه کسی باقی می‌ماند که وصیت شما را بخواند.این را بفهمید. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Thu, 21 Nov 2019 10:47:30 +0330 https://virgool.io/@taha/being-lazy-xthgt4j10nre برنامه‌نویس‌ها، بنا بر تعریف، موجوداتی هستند که ترجیح می‌دهند به جای این که وظایفشان را خودشان انجام دهند، کامپیوترهایشان را به کار وا دارند. آن‌ها خوب می‌دانند هر کجا که کاری زیاد و تکراری انجام می‌دهند، بدون شک راه را اشتباه گرفته‌اند.این را از باب مقدمه عرض کردم تا اخطاری داده باشم که آنچه در پی می‌آید، یک نوشتهٔ مرتبط با برنامه‌نویسی است و از گیت خواهم گفت. مراقب باشید.احتمالاً بیل گیتس هرگز چنین چیزی نگفته و تصویرش کنار این جمله جنبهٔ زینتی دارد.ماجرا از آنجا شروع شد که به خودم آمدم و دیدم هر بار که چیزی را، هرچند کوچک، به مخزن پروژه پوش می‌کنم، باید بین سه تا چهار دقیقه، درست روی نقطهٔ ۱۶ درصد، منتظر بمانم و در این زمان هم حوصله‌ام سر می‌رود و هم تمرکز کاری‌ام را از دست می‌دهم.دستوری به نام gpush که ملاحظه می‌فرمایید، میانبر کوچکی است برای پوش کردن.فرهنگ بازنگری کد در سازمان ما، ایجاب می‌کند که روزی چند بار کارهایمان را با یکدیگر ترکیب کنیم و برای هر کار کوچکی برنچ کوچکی بسازیم و این موضوع، زمان‌های انتظار را سخت‌تر می‌کرد.با میثم مشورت کردم و گفت مخزن ما بزرگ شده و تاریخچهٔ سنگینی پیدا کرده و ساخت دلتا، حتی برای یک تغییر کوچک، زمان‌بر است و ما می‌توانیم این تاریخچه را حذف کنیم و دوباره سبک شویم.گفتم اگر نخواهیم پاک کنیم، چه راه دیگری داریم؟ گفت باید قبل از هر بار پوش کردن، شاخهٔ خودمان را با شاخهٔ dev ترکیب کنیم. این جوری:git checkout dev git pull git checkout YOURBRANCH git merge devاین همه کار کنیم؟ و تازه بعد هم لازم باشد نام برنچی که در آن هستیم را دوباره تایپ کنیم؟برای من که حتی حوصلهٔ تایپ دستور پوش کردن معمولی را هم نداشتم و برایش میانبر تعریف کرده بودم، این یکی دیگر خیلی خارج از طاقت بود.گفت خب بیا و تابعی مثل این را در bashrc خودت تعریف کن.function gupdate() { git checkout dev git pull git checkout $1 git merge dev }تصور می‌کرد که حال آن را دارم که هر بار اسم برنچی که در آن کار می‌کنم را تایپ کنم، اما این طور نبود.سرتان را درد نیاورم.یکی من گفتم و یکی او، و دست آخر به این ترکیب رسیدیم:function gpush() { current=`git branch | grep \* | cut -d ' ' -f2` git checkout dev git pull git checkout $current git merge dev -m "merge branch dev into $current" git push origin $current }در خط اول نام شاخه‌ای که در آن هستیم را به دست می‌آوریم. در خط دوم به شاخهٔ dev (که default-branch در مخزن ماست) می‌رویم. در خط سوم شاخهٔ dev را به‌روزرسانی می‌کنیم. در خط چهارم به شاخهٔ خودمان برمی‌گردیم و برای این بازگشت از نامی که در خط اول به دست آورده بودیم استفاده می‌کنیم.در خط پنجم شاخهٔ به‌روزشدهٔ dev را در شاخهٔ کاری خودمان ترکیب می‌کنیم و یک commit message مناسب و حرفه‌ای را هم به طور خودکار بر آن می‌گذاریم که اسم شاخهٔ ما را هم به طور دینامیک، از آنچه در خط نخست یافته‌ایم، بخواند و بنویسد.در خط ششم ترکیب حاصل را به گیتهاب می‌فرستیم و باز هم نام شاخهٔ خودمان را تایپ نمی‌کنیم. خودش از آنچه در خط اول به دست آورده استفاده می‌کند.حالا دیگر برای پوش کردن، کافی است این دستور را در خط فرمان تایپ کنم و با لبخند آپلود سریع آن را ببینم.gpushهمین (:پی‌نوشت ۱: خیلی وقت بود که برای نوشتن سراغ ویرگول نیامده بودم. دلم تنگ شده بود.پی‌نوشت ۲: فایل bashrc خودم را اینجا منتشر کرده‌ام. شاید چیزهایی در آن باشد که به کارتان بیاید، یا ایده‌هایی بدهد. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Thu, 21 Feb 2019 23:57:50 +0330 https://virgool.io/yasnateam/we-are-hiring-ssdnrcnk6vph اگر برنامه‌نویس پی‌اچ‌پی هستید و به فریمورک لاراول مسلطید، و یا اگر دوست دارید چنین باشید، در جریان باشید که دو صندلی خالی داریم؛ یکی برای دومی و یکی هم برای اولی. https://jobinja.ir/companies/sourena-1/jobs/LsK سعی می‌کنم خیلی کوتاه توضیح دهم و اول دومی را می‌گویم.فرصتی برای کارآموزی...منصب کارآموزی برای کسی مناسب است که شغل آینده‌اش را انتخاب کرده، دانش تئوری کافی برای انجام کارهای مربوط به آن شغل را دارد، اما بی‌تجربه است و راه و چاه را نمی‌شناسد. تجربه‌ها و دانش‌های ضمنی، چیزهایی نیستند که در کتاب‌ها و کلاس‌ها فراگرفتنی باشند و کارآموزی،‌ برای یاد گرفتن همین‌هاست.دورهٔ کارآموزی در شرکت کوچک ما، یسناتیم، به گونه‌ای طراحی شده که هیچ کدام از دو طرف تعهدی مالی در برابر یکدیگر نداشته باشند و هر زمان که مایل باشند، بتوانند همکاری را خاتمه دهند. اما قضیه به این راحتی و بی‌مزگی نیست. انگیزهٔ ما از قبول کارآموز و صرف وقت و انرژی آن است که همکار خوبی برای خود دست و پا کنیم و نگاه به آینده داریم و بر این اساس دوست داریم کسانی را به عنوان کارآموز انتخاب کنیم که مثل ما فکر کنند و برنامه‌ای هم‌راستا با برنامهٔ ما برای زندگی خود داشته باشند.بنابراین اگر ساکن شهر تهران هستید و آیندهٔ شغلی خود را برای چند سال آینده در توسعهٔ وب می‌بینید، بشتابید.مدت زمان کارآموزیما چک‌لیستی از مهارت‌ها و توانایی‌هایی که باید کسب شوند داریم و مهلتی سه ماهه برای فرا گرفتنشان در نظر می‌گیریم. اگر کسی در زمانی کمتر از این مهلت به هفتاد درصد آن‌ها دست یافت، قدمش زودتر از سه ماه بر چشم ما خواهد بود و فوراً از قرارداد و بیمه برخوردار خواهد شد.ایمیل بزنیدضرر که ندارد. فوقش این است که صحبت می‌کنیم و یکدیگر را برای همکاری نمی‌پسندیم، اما با هم دوست می‌شویم. ایمیل خود را به نشانی taha در yasna.team بفرستید.... و فرصتی برای کار حرفه‌ایاگر به فریمورک لاراول مسلط هستید و تجربه دارید، از همین جا به بعد شروع به خواندن کنید.ما تیم کوچک پانزده نفره‌ای هستیم که برنامه‌های بزرگی داریم. روی پای خود ایستاده‌ایم و از رانت‌ها و سرمایه‌های عجیب و غریب بی‌بهره‌ایم، اما قرارداد حرفه‌ای و بیمهٔ تأمین اجتماعی را از همان ابتدای همکاری راه می‌اندازیم و حقوقی که توافق کرده‌ایم را مرتب و منظم، پرداخت می‌کنیم.عکس‌هایی از محیط کار ما را در وبسایت نوپای ما که هنوز کلی جای کار دارد، یا صفحهٔ اینستاگرام تماشا کنید. شمارهٔ تلفن و نشانی ایمیل هم هست، اگر بخواهید تماس بگیرید.چطور کار می‌کنیم؟همهٔ کدهای ما روی گیتهاب است و پروژه‌ها را به صورت تیمی و کاملاً ماژولار جلو می‌بریم.تسک‌ها را فعلاً بر روی سرویس تسکولو توزیع می‌کنیم، اما در همین یکی دو هفتهٔ آینده ابزار اسکرام را راه‌اندازی خواهیم کرد و مدیریت پروژهٔ علمی‌تر و مدرن‌تری را برپا خواهیم ساخت.رویهٔ سختگیرانه‌ای روی نظارت متقارن بر کدهایمان داریم که اینجا کمی درباره‌اش گفته‌ام: فرهنگ بازنگری کدرویهٔ سختگیرانه‌ای برای تمیزی و خوانایی کدهای منتشرشده داریم که اینجا کمی درباره‌اش گفته‌ام: کمتر کثیف کد بزنیماز نظام انگیزشی نوپا، اما جذاب و منظم و قاعده‌مندی برخورداریم که هیچ تلاشی را بی‌پاداش نگذاریم. مفاد این نظام انگیزشی که هم شامل تشویق است و هم تنبیه، توسط همهٔ همکاران و در قالب جلساتی شاد تهیه شده و همیشه با نظر جمیع همکاران قابل تغییر است.در طول هفته از ساعت نه صبح تا شش بعدازظهر سر کار هستیم و پنج‌شنبه‌ها و جمعه‌ها به تعطیلات می‌رویم. همین جا تأکید کنم که این یک موقعیت کاری تمام‌وقت و حضوری است.هیچ تفاوتی میان زن و مرد قائل نیستیم و کسانی که غیر از این فکر می‌کنند را از خودمان نمی‌دانیم.نوع پوشش در محیط کار ما تنها یک قانون دارد که خیلی جدی از آن پاسداری می‌کنیم: به پا داشتن کفش ممنوع است و حتما باید یک صندل یا دمپایی شکیل و زیبا برای خود داشته باشید.در مصاحبه چه می‌پرسیم؟خبری از سؤال‌های هوشی عجیب و غریبی که آدم باید از قبل آنها را شنیده باشد و تمرین کرده باشد نیست. مصاحبهٔ شغلی ما، گفت‌وگویی کوتاه و نیم ساعته است که گاهی تا یک ساعت به درازا می‌کشد. از مهارت‌ها و توانایی‌هایمان می‌گوییم، مسیر ایده‌آل پیشرفت حرفه‌ای خود را برای یکدیگر توضیح می‌دهیم، از برنامه‌هایمان برای آینده صحبت می‌کنیم، و وارد مسائل خانوادگی و خصوصی نمی‌شویم.سه چهار سؤال چالشی هم داریم که به تناسب گفتگو و تجربه‌های هر کس، یکی دو تا از آن‌ها را مطرح می‌کنیم تا ایده‌های اولیه را ببینیم. طبیعتاً به دنبال پاسخ نهایی و قطعی نیستیم، ولی بعید نیست همان ایده‌های خام اولیه را کمی به چالش بکشیم و به کمک هم پخته‌تر کنیم.رزومه بفرستیداگر ساکن شهر تهران هستید و بر فریمورک لاراول تسلط دارید و دنبال کار تمام‌وقت می‌گردید، می‌توانید به نشانی من (taha در yasna.team) ایمیل بزنید، یا از طریق آگهی جابینجا اقدام نمایید. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Wed, 20 Jun 2018 13:32:39 +0430 https://virgool.io/@taha/happiness-dhwxsnkfmeiy ظاهراً شکی نیست که شادی مردم آزاردهنده است و مشکلاتی به بار می‌آورد.نمی‌توان دست روی دست گذاشت و کاری نکرد.وقتی رئیس نباشیم و زور نداشته باشیم، می‌توانیمبه عکس‌هایی که مردم از برف‌بازی‌هایشان در شبکه‌های اجتماعی می‌گذارند گیر بدهیم و مسخره کنیم؛به شادی‌هایی که مردم به زور از خودشان اختراع می‌کنند و با آن‌ها خوش هستند گیر بدهیم و مسخره کنیم؛شبکه‌های اجتماعی مردم را رصد کنیم و ببینیم چه کار می‌کنند که شاد می‌شوند و همان کار را مسخره کنیم؛شادها را در جمع با نیش و کنایه ضایع کنیم که از دماغشان دربیاید؛کاری کنیم یا چیزی بگوییم که یاد غم و غصه‌هایشان بیافتند و دوباره شاد نباشند.وقتی رئیس باشیم و زور داشته باشیم، می‌توانیمقانونی بسازیم که خیلی‌ها نتوانند به کنسرت موسیقی مورد علاقه‌شان بروند و شاد شوند؛قانونی بسازیم که نصف مردم نتوانند به تماشای مسابقه‌های ورزشی بروند و شاد شوند؛قانونی بسازیم که زوج‌ها نتوانند با هم به تفریحات آبی بروند و شاد شوند؛قانونی بسازیم که مردم نتوانند مثل آدم عروسی‌هایشان را جشن بگیرند و با خانواده‌هایشان کمی شاد باشند؛قانونی بسازیم که میهمانی‌های خانوادگی و دوستانه را محدود کنیم که به این راحتی‌ها کسی شاد نشود؛با اجرای موسیقی خیابانی به بهانهٔ سروصدا و سد معبر مقابله کنیم اما به وانت‌های دوره‌گرد و صافکاری‌هایی که پیاده‌رو را به کثافت می‌کشند کاری نداشته باشیم؛ترتیبی بدهیم که رسانه‌هایمان چیزهای شاد پخش نکنند و اگر هم می‌کنند لابه‌لایش کمی حرصشان بدهیم؛مراقب باشیم که اگر آهنگ یا کلیپ شادی به صورت خودجوش ساخته شد عواملش را مجازات کنیم؛مراقب باشیم که اگر کودکان و نوجوانان به پارکی رفتند و آب‌بازی کردند و شاد شدند حسابشان را برسیم؛نهادهایی بسازیم که به صورت فعالانه شادکننده‌های جدید را گزارش کند تا فوراً فکری به حالشان کنیم؛با آداب و رسومی قدیمی که مردم را شاد و خوشحال می‌کند مقابله کنیم؛هزینهٔ شادی‌های دور از قلمرو خود را تا می‌توانیم زیاد کنیم، که کسی زیرابی نرود؛اگر هم می‌بینیم که بعضی‌ها باز از دستمان فرار می‌کنند تا کمی شاد باشند و زورمان نمی‌رسد، به آن‌ها بگوییم که باید این عادت را ترک کنند.این حرف‌ها را گفتیمولی آخر چرا شادی‌های مردم این قدر آزاردهنده‌اند؟به خدا اگر بدانم! طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Sat, 16 Jun 2018 09:41:46 +0430 https://virgool.io/@taha/laravel-after-otwell-mhkki4lqclin لاراول فریمورکی است که به صورت یک نفره توسعه داده می‌شود.از استخدام نخستین نفر در لاراول بیشتر از یک سال می‌گذرد و تازه حدود سه ماه پیش حضور یک نفر دیگر هم لازم شد (+) که با نفر قبلی می‌شوند دو نفر! جالب آن که این دو نفر در توسعهٔ لاراول نقش خاصی ندارند و کارشان این است که ایشوهای پروژهٔ لاراول را مدیریت کنند، ایده‌های جدید را بررسی کنند، در فروم‌ها بچرخند و با کاربران دمخور شوند، و اگر عمری باقی بود و فرصتی حاصل شد در توسعهٔ ویژگی‌های جدید هم (پروتوتایپ) کمی کمک کنند. (همان منبع)پس چه کسی لاراول را با این سرعت پیش می‌برد؟تیلور آتول، تنهایی!این طور که پیداست، نگاه‌ها و امیدها همه به سوی اوست!معمولاً کسی به توسعهٔ یک نفرهٔ لاراول اعتراضی ندارد. می‌توان گفت همه قبول دارند جمع این همه فضایل در کنار یکدیگر، مدیون ایده‌آل‌گرایی خالق آن است و چابکی و گسترش سریع آن دلیلی جز همین تصمیم‌های متکی به شخص او ندارد. نگرانی‌ها از آنجا شروع می‌شوند که خالق لاراول آدمیزاد است و حالا که از کار تیمی خوشش نمی‌آید، مخلوقش دیر یا زود یتیم می‌شود.سؤال این است:اگر بلایی سر تیلور آتول آمد، یا اصلا یک روز صبح در برابر دیدگان متعجب اطرافیانش ناپدید شد، چه بر سر لاراول می‌آید و از آن مهم‌تر، پروژه‌های ما که با لاراول نوشته شده‌اند چه می‌شوند؟ این پرسش بارها در فروم‌های بزرگ مطرح شده (مثلا اینجا) است. مجید فتحی هم مطلبی در همین زمینه نوشت و لطف کرد و مرا پای گفت‌وگویی که در کامنت‌های یکی دیگر از پست‌های من با عنوان «حالا چرا لاراول: یک شاهد دیتابیستی» پیش می‌رفت، در جریان نوشته‌اش گذاشت. https://virgool.io/@webus.us/%D9%84%D8%A7%D8%B1%D8%A7%D9%88%D9%84-%D8%A8%D8%B9%D8%AF-%D8%A7%D8%B2-%D8%AA%DB%8C%D9%84%D9%88%D8%B1-%D8%A2%D8%AA%D9%88%D9%84-wsatq8as1ke2 این یادداشت، پاسخی است به آن یادداشت.جواب کوتاه من به پرسشی که چند خط بالاتر آوردم، این است:طوری نمی‌شود!و اگر بیشتر بحث کنید، احتمالاً می‌گویم:حالا یک طوری می‌شود!وی انسانی‌ست مثل انسان‌های دیگر. ما انسان‌ها یک روز می‌آییم و یک روز هم می‌رویم. لاراول یک پروژهٔ متن‌باز استدر حال حاضر ایده‌آل‌گرایی خالق لاراول مجال خیلی کمی به نظرهای دیگران می‌دهد و چون واقعاً موشکافانه و ظریف پیش می‌رود، کسی به فکر چنگال زدن در مخزن لاراول و توسعهٔ ایده‌های خودش نیافتاده و اگر هم افتاده مورد توجه واقع نشده است. اما این (به اصطلاح) مانع، با ناپدید شدن تیلور خودبه‌خود بی‌معنی می‌شود و کسی یا گروهی پیدا می‌شود که همان راه را ادامه دهد. همین روزها هم در دنیای خارج از پی‌اچ‌پی عده‌ای به همین کار مشغولند؛ مثل مایکروفریمورک Orator برای پایتون، که حتی در استایل صفحات راهنما نیز پا جای پای لاراول گذاشته است.با این اوصاف، اطمینان دارم اگر در دنیای بعد از لاراول، پی‌اچ‌پی هنوز زنده باشد و سر و کلهٔ ابزاری بهتر از لاراول پیدا نشده باشد، نهضت ادامه دارد، ولی از منبعی بیرون از شخص تیلور آتول.آپدیت نشود هم طوری نمی‌شودآپدیت که سهل است. اگر روزی از خواب بیدار شویم و لاراولی وجود نداشته باشد و نسخه‌های فعلی هم غیب شده باشند، چه بلایی سر پروژهٔ برپاشدهٔ ما می‌آید؟ هیچ!کارهای اجراشده همان جا که هستند می‌مانند و قابل توسعه هم هستند و نهایتش این است که دیگر از آپدیت‌های امنیتی و رفع اشکال‌های خرد که می‌توانستند برخوردار شوند محروم می‌شوند و زحمتش را باید خودمان بکشیم. شما که غریبه نیستید. همین حالا هم کمتر کسی پیدا می‌شود که دردسر آپدیت کردن وابستگی‌های پروژه‌ای که تحویل شده را به خود بدهد و خطراتش را بپذیرد. انتقال از یک نسخهٔ اصلی لاراول به نسخهٔ بعدی که از این هم نادرتر است.لاراول یک ابزار استابزارها می‌آیند و می‌روند. دلیلی ندارد که از بیم رفتن یک ابزار از آن استفاده نکنیم. زبان‌های برنامه‌نویسی بسیار جذاب‌تر و بهینه‌تر از پی‌اچ‌پی روزبه‌روز گسترده‌تر می‌شوند و همچنان کسی از به کار بردن پی‌اچ‌پی در پروژه‌های بزرگ نگران نمی‌شود، چه برسد به لاراول که فریمورکی داخل این زبان است.مگر یک نرم‌افزار چقدر قرار است عمر کند؟فرض کنیم نگرانی ما در مورد پروژه‌های بزرگی است که پیوسته در حال توسعه‌اند، نه آن‌ها که یک بار برپا می‌شوند و می‌روند پی کارشان.باز هم جای نگرانی نیست. هیچ پروژهٔ بزرگی نیست که در طول زمان نیاز به بازنویسی کد نداشته باشه؛ یا لااقل من نمی‌شناسم. با این سرعت پیشرفت فن‌آوری، واقعاً عجیب است که ما پروژهٔ بزرگی روی یک زبان و یک فریمورک (هر زبان و هر فریمورکی که تصور کنید) داشته باشیم و با اطمینان بگوییم که پنج سال دیگر هم مثل حالا بهینه و خوب کار می‌کند، یا بر همان بستری که روز نخست برپا شده برقرار می‌ماند. هر چند سال یک بار، نیاز مخاطبین ما و دانش خود ما و تکنولوژی‌های موجود و حتی قوانین آن قدر تغییر می‌کنند که ارزش دوباره‌کاری داشته باشد. به همین قوانین اخیر جی‌دی‌پی‌آر نگاه کنید که چطور بسیاری را مجبور کرد دست به چاقوی جراحی ببرند و تغییراتی بنیادین در ساز و کار پروژه‌هایشان بدهند.جان کلاماگر نظر مرا بپرسید، به شما می‌گویم که برای فردایی که لاراول باشد و آتول نباشد بد به دل راه ندهید. هیچ طوری نمی‌شود. ابزارها ابزارند و به فراخور توانشان مورد استفادهٔ ما قرار می‌گیرند و کار ما همین است که در هر زمان ابزاری را برگیریم که هم کارمان را بهتر و ساده‌تر راه بیاندازد و هم استفاده‌اش لذت‌بخش باشد و حالش را ببریم. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Fri, 08 Jun 2018 23:32:48 +0430 https://virgool.io/yasnateam/no-bad-code-foftsbr2vkvg تمیز کد نوشتن، دغدغه‌ای بود که از دومین روزهایی که برنامه‌نویسی را آموختم، درگیرش بودم. دروغ چرا؟ اولین روزها عین خیالم نبود و هر طور که کارم را راه می‌انداخت می‌نوشتم و چون استاندارد خاصی را هم رعایت نمی‌کردم، هر بار که فاصلهٔ زمانی می‌افتاد دیگر حوصله نداشتم ببینم چه کرده‌ام و تمام کار را از اول انجام می‌دادم! (روزگار بدی بود، نازنین.)رهنمودها و راهکارهای مرسوم به ما می‌گویند که برای قطعه‌های کد خود کامنت‌هایی بگذاریم تا بعداً چیزهایی را به یادمان بیاورند، و این که تلاش کنیم از یک الگوی طراحی (مثل MVC که اینجا درباره‌اش نوشته‌ام) تبعیت کنیم، و این که نام‌های خوبی برای متغیرها و تابع‌ها انتخاب کنیم و چیزهایی کلی از این قبیل.کامنت گذاشتن کار خوبی است، اما همیشه هم جالب و راهگشا نیست. قول معروفی است که می‌گوید «بکوش کامنت در متن کد تو باشد...»هنوز هم که هنوز است، در مصاحبه‌های شغلی، از متقاضیان می‌پرسم که معیارهایشان برای تمیز نوشتن کد چیست و اغلب پاسخ‌هایی که می‌شنوم حاکی از آن است که تاکنون به این پرسش برنخورده‌اند و در بهترین حالت، همان چیزهای مرسوم را بازگو می‌کنند.واضح است که معیارهای شخصی (اگر اساساً وجود داشته باشند)، به درد کار تیمی نمی‌خورد. همه معتقدند که خودشان تمیز کد می‌نویسند و کار بقیه کثیف است و همه هم به یک میزان حق دارند و حق ندارند.طرحی از ادوبی: من کد بد نمی‌نویسم، همکارم می‌نویسد.حضرت جفری وی، بنیان‌گذار لاراکستز، کتابی دارد با این عنوان: https://leanpub.com/laravel-testing-decoded در فصل نخست این کتاب، آنجا که نشانه‌های «تست‌ناپذیر بودن» یک برنامه را برمی‌شمارد، گریزی هم به کدنویسی تمیز زده و نکته‌هایی را آورده که بسیاری از آن‌ها را می‌دانستم یا ناخودآگاه رعایت می‌کردم، و بسیاری دیگر به مخیله‌ام هم خطور نکرده بود.در هر حال، دیدن یک‌جای این نکته‌ها برایم بسیار آموزنده بود و بد نیست خلاصه‌ای از آن‌ها را به اشتراک بگذارم، شاید به کار کس دیگری نیز بیاید.جفری وی در این نکته‌ها،‌ علامت‌هایی را نشان می‌دهد که نشان از کدنویسی کثیف دارند.یک دست و چند هندوانهاصل تک‌وظیفگی را تقریباً همه می‌دانیم، اما خوب رعایت نمی‌کنیم. جفری وی پیشنهاد می‌کند کاری را که کلاس یا متد یا تابع ما انجام می‌دهد، با زبان آدمیزاد، به صورت یک جمله برای خودمان بگوییم و اگر کلمهٔ «وَ» را زیاد از زبان خودمان شنیدیم، بدانیم که راه را اشتباه رفته‌ایم.هر کلاس یا متد فقط باید یک کار را انجام دهد و بس.شک در انتخاب نامتردید در گزینش یک نام خوب برای متد یا کلاسی که نوشته‌ایم، زنگ خطر است. اگر بنا بر قاعدهٔ تک‌وظیفگی جلو رفته بودیم و کلاس یا متد ما فقط یک کار را می‌کرد، انتخاب نام نباید دشوار می‌بود.سازندگان همه‌کارهمتدهای Constructor در هر کلاس، فقط به این درد می‌خورند که وابستگی‌های (Dependencies) آن کلاس را فراهم کنند و بس. اگر داخل این متد کاری غیر از تزریق وابستگی‌ها انجام دادیم، بهتر است تا دیر نشده، کد را بازنویسی کنیم.وی در ادامه خاطرنشان می‌سازد که دیگر شورش را هم درنیاوریم. اگر کلاس ما به بیشتر از مثلاً چهار وابستگی احتیاج داشت، زیاده‌خواهی می‌کند و باید به کلاس‌های کوچک‌تر خرد شود.جفری وی برای این عدد «چهار»، به روایتی که از تیلور اوتول (خالق لاراول) نقل کرده، استناد می‌کند:معمولاً کلاس‌هایی که بیش از چهار وابستگی دارند را دوباره طراحی می‌کنم.و خودش می‌افزاید:یکی از اصول ابتدایی برنامه‌نویسی شیءگرا آن است که میان تعداد پارامترهای یک کلاس یا یک متد، و میزان انعطاف‌پذیری (و در اینجا آزمون‌پذیری) آنها رابطه‌ای معکوس برقرار است. با حذف هر پارامتر یا نیازمندی، کد خود را اندکی بهتر کرده‌اید.بلندتر، بدتراجازه ندهید متدها طولانی شوند. بهترین متدها آن‌هایی هستند که چند خط بیشتر ندارند. حتی اگر می‌شد که یک‌خطی باشند، چه بهتر!پیمان چه می‌گوید؟جفری وی پیشنهاد می‌کند کد کلاس یا متدی که نوشته‌ایم را به یکی از دوستان برنامه‌نویسمان نشان بدهیم. اگر بدون نظر انداختن به کامنت‌ها و مستندات، فوراً متوجه وظیفهٔ آن قطعه از کد نشد، راه را اشتباه رفته‌ایم و بهتر است به فکر بازنویسی کد خود باشیم.شرطی‌های بسیارحضرت در ادامه می‌فرماید که از ifهای تو در تو بترسیم و در گامی محافظه‌کارانه‌تر، از به کار بردن ساختار switch به‌شدت پرهیز کنیم. او معتقد است این شرطی‌های تو در تو، برنامه‌نویسان را به اشتباه می‌اندازند و سر و کلهٔ باگ‌ها پیدا می‌شود. در عوض پیشنهاد می‌کند اسلوب نگارش متدهای یک‌خطی و الگوهای چندریختی را جایگزین این همه اما و اگر کنیم.باگ‌ها موجوداتی اجتماعی هستند!جفری وی با اشاره به این که حشره‌ها و انگل‌ها دوست دارند با هم زندگی کنند و «باگ» هم در زبان انگلیسی به معنای «حشره» است، می‌گوید که اگر متوجه باگ در جایی از کد شدیم، یا باید منتظر بروز باگ‌های بعدی در حوالی همان نقطه بمانیم و یا دست به کار شویم و آن قطعه را به طور کامل ضدعفونی (=بازنویسی) کنیم.البته برای نزدیکی فیزیکی باگ‌ها، استدلال غیرجانورشناسانه‌ای هم ارائه می‌کند که ترجمهٔ عین عبارت‌ چنین است:دلیل وجود باگ‌ها آن است که شما نتوانسته‌اید کد خودتان را در وهله‌ی اول به‌درستی بشناسید. حتماً بیش از حد پیچیده بوده که چنین شده است! و کیست که نداند کد پیچیده، اغلب پیام‌آور کد ناپایدار هم هست.و این یکی:وقتی اشکال‌های زیادی را می‌بینید که از یکی از کلاس‌های شما سر می‌زنند، به این معنی است که آن کلاس، برای شکسته شدن به قطعات کوچک‌تر فریاد التماس سر داده است.پانوشت ۱:این حرف‌ها را قبلاً در توییتر نقل کرده بودم (اینجا) و سمانه هم در کانال تلگرامیِ خوب و پرمحتوایش (اینجا) یکجا کنار هم آورده بود و که از نشانی‌اش برای ارجاع به دوستانم استفاده می‌کردم.پانوشت ۲:نقل‌قول‌هایی که در متن می‌بینید، حاصل ترجمهٔ ویراست‌نشدهٔ خودم از کتاب جفری وی هستند که نیمه‌کاره رهایش کردم. داستان این است که برای ترجمهٔ فارسی کتاب با ارسال یک پیام به نویسنده اجازه گرفتم و بلافاصله شروع به کار کردم و پنج فصل (نزدیک سی درصد) هم پیش رفتم و باقی را گذاشتم برای هر زمان که اجازه داد. چون جوابی نگرفتم، کار را رها کردم و طبعاً در جایی هم منتشرش نمی‌کنم، اما استفاده به این شکل، قاعدتاً در محدودهٔ Fair-Use می‌گنجد و نیازی به کسب اجازه ندارد. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Fri, 04 May 2018 20:26:53 +0430 https://virgool.io/@taha/weekend-1-hhtnskyylqgo به نظرم رسید شاید بد نباشد هر آخر هفته، آنچه را که در طول هفته خوانده‌ام یا دیده‌ام و برایم جذاب بوده، با مختصری توضیح به اشتراک بگذارم شاید به درد دیگران هم بخورد.می‌دانم که عکس لوس و بی‌ربطی است، اما ظاهر نوشتهٔ آدم در فهرست‌های ویرگول، بدون حداقل یک عکس، خوب درنمی‌آید.برای همهنه هر که سر بتراشد...با حسن فتاحی بیست سال است که دوست هستم. هم‌کلاسی هر سه سال دبیرستان هم بودیم و بعد از این که بزرگ شدیم، بر خلاف من برای خودش کسی شد و چندین کتاب تألیفی و ترجمه‌ای در کارنامه‌اش دارد و برای روزنامه‌های معتبر قلم می‌زند و این آخری هم با اصرار من و یک نفر دیگر از دوستان مشترک، پا به دنیای وبلاگ‌نویسی و فضای زیبا و روان ویرگول گذاشت. https://virgool.io/@science.fattahi/%D9%86%D9%87-%D9%87%D8%B1-%DA%A9%D9%87-%D8%B3%D8%B1-%D8%A8%D8%AA%D8%B1%D8%A7%D8%B4%D8%AF-%D9%82%D9%84%D9%86%D8%AF%D8%B1%DB%8C-%D8%AF%D8%A7%D9%86%D8%AF-frvnwvvt8uoj این نوشته، به نظر خودش در باب عارضهٔ خودنخبه‌باوری این روزهای خیلی‌های ماست و از نظر من در باب تصور تباهی است که برای هر کاری و هر هدفی و هر موفقیتی به دنبال میانبرهای عجیب و غریب است، حالا چه آن هدف پولدار شدن باشد، چه لاغر شدن باشد و چه دانشمند شد.کمک به پروژه‌های آزاداین نوشته قدیمی هست، اما کهنه نیست. عنوانش به اندازهٔ کافی گویاست و فرود در مورد برخی از برداشت‌های غلطی در باب کمک به پروژه‌های آزاد رواج دارند توضیح داده که هنوز هم بعد از دو سال، کاملاً رواج دارند. http://fzero.rubi.gd/post/donation/ فارغ از خود این مطلب، یکی از جذابیت‌های وبلاگ فرود این است که می‌توانیم به گیتهاب برویم و نوشته‌اش را تغییر بدهیم تا ببیند و اگر تأیید کرد در نوشتهٔ اصلی اضافه شود. به این می‌گویند برنامه‌نویس واقعی.برای برنامه‌نویسانشاید لاراول برای شما مناسب نباشدبهزاد شعبانی با این نوشته، مستقیم به بازار داغ کوچ برنامه‌نویسان پی‌اچ‌پی به دنیای لاراول پرداخته و دو کلام حرف حساب زده است. کار با لاراول آسان است و هر روز هم آسان‌تر می‌شود و هر کسی خیلی ساده اصول ابتدایی آن را یاد می‌گیرد و ناگهان بدون فرا گرفتن منطق‌های پشت پرده، رزومه‌اش را آپدیت می‌کند. http://behzad.shabani.me/post/%D8%B4%D8%A7%DB%8C%D8%AF-%D9%84%D8%A7%D8%B1%D8%A7%D9%88%D9%84-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B4%D9%85%D8%A7-%D9%85%D9%86%D8%A7%D8%B3%D8%A8-%D9%86%D8%A8%D8%A7%D8%B4%D8%AF کد ملی تصادفیسجاد پورعلی، گوشه‌ای از سایت شخصی خود (+) را به ابزارهایی اختصاص داده که خودش ساخته و مفید تصور می‌کرده. یکی از این‌ها، ابزاری است که کد ملی تصادفی می‌سازد و تحویل می‌دهد. با هر بار بازخوانی این صفحه، یک کد ملی شانسی تحویل می‌گیرید که می‌تواند برای آزمایش برنامه‌هایی که می‌سازید به کارتان بیاید.خیلی مختصر عرض کنم که کدهای ملی (مثل شناسهٔ ملی شرکت‌ها) طوری طراحی شده‌اند که با دستکاری شانسی یکی دو رقم، کد ملی معتبر دیگری به دست نمی‌آید. ساختار اعداد این کد طوری طراحی شده که جمع و تفریق آن‌ها با فرمولی خاص، رقم آخر را می‌سازد و بنابراین احتمال آن که یک عدد تصادفی ده رقمی، یک کد ملی واقعی از آب دربیاید زیاد نیست. (روزی از روزها آستین بالا می‌زنم و با چند خط کد میزان این احتمال را خواهم سنجید.)آموزش گیتاگر با گیت آشنا نیستید، یا آشنا هستید و دوست دارید بیشتر یاد بگیرید، ابزار جدیدی که گیتهاب معرفی کرده را از دست ندهید. https://lab.github.com/ با این روبات کوچک، دستورات گیت را مثل یک بازی، گام به گام بیاموزید و امتیازهایی به دست بیاورید و به مرحلهٔ بعد بروید. خودم، پس از تکمیل این پست به سراغش خواهم رفت.در پایانمی‌خواستم در ادامهٔ این نوشته، کمی دربارهٔ پروژهٔ کتاب آزاد «لاراول، از صفر تا شصت» بنویسم که مفصل است و می‌گذارم برای بعد. همچنین می‌خواستم چیزمیز را به شما معرفی کنم که در طول هفته، وقتی کمی کامل‌تر شد این کار را می‌کنم. بعد هم می‌خواستم بگویم که تنظیمات ویرایشگر PHPStorm خودم را که با قوانین PSR سازگار است و همهٔ کد را قشنگ و تمیز تراز می‌کند، نشان بدهم (اینجا) تا اگر به کارتان می‌آمد و دوست داشتید استفاده کنید، که حوصله‌اش را ندارم.تداوم آخر هفتهٔ خوبی را برایتان آرزو می‌کنم. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Fri, 27 Apr 2018 15:00:04 +0430 https://virgool.io/@taha/no-news-xrwohtk95b6u در این چند ماه که خودم را از اخبار دور نگه داشته‌ام، زندگی بهتری دارم، پوستم صاف‌تر شده، اخلاقم بهتر شده، و خارش کف پای راستم هم تا حد زیادی خوب شده است. حتی در این مدت سیگار هم نکشیدم (که البته قبلاً هم نمی‌کشیدم، ولی احتمالاً به پی‌گیری اخبار مربوط‌تر باشد).از یک طرف خبرهای ایران و جهان، همه در ذات خود خبرهای بدی هستند. نه‌تنها بوی بهبود ز اوضاع جهان به مشام نمی‌رسد، بلکه بوهایی با مضامینی به‌کلی برعکس بیداد می‌کنند. از طرف دیگر، نان خبرگزاری‌ها هم عموماً از پر و بال دادن به خبرهای جنگ و تهدید به جنگ، انفجار و تهدید به انفجار، تخریب و تهدید به تخریب، فشار و عمل به فشار، و هزار موضوع ناجور و ناراحت‌کنندهٔ دیگر درمی‌آید که حالا این دومی می‌تواند به جبر نظام عرضه و تقاضا باشد یا هر چیز دیگری که نمی‌دانم و حوصلهٔ فکر کردن به آن را هم ندارم.حالا اشاره به دروغ‌های رسانه‌ای که از هر چهار گوشهٔ جهان سرازیرند و برخی حرفه‌ای و خوش‌ساخت هستند و برخی آبکی و صداوسیماطور، نمی‌کنم.این بزرگواران، و همکارانشان در سراسر جهان، هیچ وقت چیز خوبی برای گفتن در آن چهارچوب لعنتی خبر فلان‌گاهی را نداشته و نخواهند داشت.راه حل عمومی این است که وقتی کاری از دستمان برنمی‌آید، حرص بخوریم و ملامت کشیم و خوش باشیم. من راه حل بهتری پیدا کردم و اخبار را نمی‌خوانم و نمی‌بینم. حتی وقتی جنجالی در جریان است، در شبکه‌های اجتماعی نیز (مخصوصاً توییتر) آفتابی نمی‌شوم.در عوض، هر روز، حداکثر پانزده دقیقه به مرور اخبار می‌پردازم و آن هم نه در اوایل صبح که تکاپوی روزانه‌ام را آغاز می‌کنم و نه در اواخر شب که برای آرامش شبانه آماده می‌شوم. بهترین زمانی که یافته‌ام، ساعتی‌ست که قصد ترک محیط کار و عزیمت به منزل را دارم که فضای خانه حال خراب حاصل را تا حد امکان بشوید و ببرد.این رویکرد آن قدر برایم سازنده و خوب بوده که به دیگران هم (حتی شما دوست عزیز) توصیه می‌کنم اگر شغلتان و کارتان مستقیماً به دنیای خبر مربوط نیست، از پی‌گیری رویدادها بپرهیزید و فقط آن دسته مطالبی را دنبال کنید که قرار است مستقیماً (حضرت دو بار از این کلمه استفاده کردند) ملاک تصمیم‌گیری‌هایتان قرار گیرند.پخش مستقیم کنفرانس خبری رؤسای جمهور اینجا و آنجا، گرهی از مشکلات ما نمی‌گشاید. بعداً می‌توانیم عصارهٔ آنچه به سرمان می‌آید را در یک تیتر ده کلمه‌ای بخوانیم و بدانیم. مشروح مذاکرات پارلمان آنجا و اینجا هیچ فایده‌ای ندارد و خلاصه‌اش هم همان اندازه کافی‌ست که بدانیم چه بلایی سرمان خواهد آمد.هیچ فرقی ندارد که در این عکس چه نوشته و این آقا چه می‌گوید. به هر حال به زیان ماست و کاری هم از دستمان ساخته نیست.به جای این چرندیات که با آب و تاب فراوان در گوش‌هایمان و مغزهایمان و جان‌هایمان و جان‌های جان‌هایمان و جان‌های جان‌های جان‌هایمان فرو می‌روند، می‌توانیم به کارمان برسیم، می‌توانیم با خانواده‌مان وقت بگذارنیم، می‌توانیم ورزش کنیم، فیلم ببینیم، بازی کنیم،‌ استراحت کنیم و دراز بکشیم،‌ می‌توانیم حتی هیچ کاری نکنیم و ول باشیم و وقت تلف کنیم. پی‌گیری مداوم اخبار، بدترین بلایی است که می‌توانیم سر خودمان بیاوریم. کردم اشارتی و مکرر نمی‌کنم. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Sun, 22 Apr 2018 09:31:22 +0430 https://virgool.io/yasnateam/code-review-xpsqi6i5qmsh اواخر سال گذشته که شماره‌اش (به روایتی) ۱۳۹۶ بود، با ورود میثم، از مجموعهٔ شرکت‌های «زیر ده نفر» بیرون آمدیم و برای نخستین بار ده نفری شدیم. (در ابتدای همان سال، با ورود اولین همکار غیرِ شریک، سه نفره شده بودیم و در این مدت کوتاه، دو خداحافظی هم داشتیم.)ده نفره شدن، تغییراتی را در ساختار سازمانی می‌طلبید که برایش برنامه‌ریزی کردیم و گام به گام جلو آمدیم و هنوز هم تمام نشده است. به عنوان یک شرکت برنامه‌نویسی، یکی از این تغییرات، بلکه چالشی‌ترین آن‌ها، اجرای قانونی بود که در آن، هر قطعه از کد، پیش از ترکیب با مخزن اصلی، می‌بایست توسط حداقل دو نفر از همکاران بازنگری شود. این کارها را از فرود یاد گرفتیم و شرحش طولانی‌ست که خوشبختانه خودش در صدد تدوین و نشر آن است.اجرای چنین قانونی، در ذات خود، خطرناک است، به هزار و یک دلیل. اول آن که ممکن است باعث شود همکاران رو در روی هم قرار گیرند و پا به رقابت ناسالم بگذارند و هر فایده‌ای که متصور بود، یکجا و دو چندان، بدل به زیان شود.میثم که سکان‌دار این تغییرات در سازمان کوچک ما بود، گشت و از میان چندین و چند مقاله و نوشته، متنی کوتاه در راهنمای گیت‌لب یافت که سخت به کار ما می‌آمد (+). از همکاران خواستیم که آن را مطالعه کنند و با این که زبانشان خوب است، تصمیم گرفتم بیشترِ راهکارهای آن را ترجمه کنم که هم به کار آنان بیاید و هم به کار هر کس دیگری که پا به این عرصه می‌گذارد.آنچه که بین این چهار نقطه و چهارنقطهٔ بعد می‌بینید، ترجمه‌ای آزاد است، با کمی خلاصه‌سازی از متن اصلی.برای همهقبول کنید که بسیاری از تصمیم‌های برنامه‌نویسی، تابع نظرات شخصی افراد هستند. راه‌کارهای خود را سبک‌سنگین نمایید ولی برای رسیدن به نتیجهٔ مشترک زیاد معطل نکنید.به جای دستور دادن، سؤال کنید. («حالا اگه اسم این متغیر رو بذاریم فلان چی؟»)برای شفاف شدن موضوع، سؤال کنید. («این تیکه رو نمی‌فهمم. چه جوریه؟»)از ضمایر ملکی در ارتباط با متن برنامه استفاده نکنید. («کد من»، «کد تو»...)از عبارت‌هایی که ممکن است شامل برداشت شخصی شوند («احمقانه»، «مسخره»...) پرهیز کنید [هرچند که واقعاً منظوری نداشته باشید]. در نظر بگیرید که همه آدم‌های خوب و جذاب و باهوشی هستند و قصد بدی ندارند.صریح باشید و از یاد نبرید که مردم در فضای آنلاین، همیشه متوجه منظور کناییِ شما نمی‌شوند.فروتن باشید. («مطمئن نیستم، بذار یه سرچی بکنم.»)اغراق نکنید. («همیشه»، «هرگز»، «هیچ»...)در طعنه زدن احتیاط کنید. همه‌چیز عمومی‌ست. ممکن است رفتاری که بین شما و همکارهای قدیمی شما عادی شده، برای غریبه‌ها و تازه‌واردها مؤدبانه به نظر نرسد.حرف‌هایتان را، وقتی «متوجه نشدم»‌ها و «به نظر من»ها زیاد می‌شود، دو نفری [در چت‌های خصوصی] دنبال کنید و دستِ آخر، نتیجه را یک‌کاسه کنید و در یک کامنت خلاصه نمایید.کامنت خود را، وقتی با شخص خاصی صحبت می‌کنید، همیشه با منشن به او شروع کنید. با این کار در صورت روشن بودن اعلان‌هایش حتماً پیام شما را می‌بیند و بقیه هم متوجه می‌شوند که لازم نیست بخوانند و جواب بدهند.وقتی کد شما بررسی می‌شودتوجه کنید که بررسی کد فرآیندی است که ممکن است چندین بار تکرار شود و چه بسا بررسی‌کنندگان متوجه نکته‌ای شوند که در بررسی اول متوجه آن نشده باشند.اولین بررسی‌کنندهٔ کد شما، خود شما هستید. قبل از آن که چیزی را از بالا بفرستید، یک بار تمام تغییرات را مرور کنید و ببینید که آیا همه چیز در جای خودش هست؟ آیا چیزهای بی‌ربطی هم این وسط وجود دارند؟ کدهای خطایابی را حذف کرده‌اید؟سپاسگزار پیشنهادهای بررسی‌کنندهٔ کدهای خود باشید. («دمت گرم. ردیفش می‌کنم.»)به خودتان نگیرید. آن‌ها کد شما را بررسی کرده‌اند، نه خودِ شما را.توضیح دهید که چرا این کار را کرده‌اید. («این جوری نوشتم که فلان طور بشود»، «اگر اسم این تابع را عوض کنم درست می‌شود؟»)تغییرات بی‌ربط و تمیزسازی‌های کد خود را در برنچ‌های دیگری انجام دهید.سعی کنید از چشم بررسی‌کننده به موضوع نگاه کنید.سعی کنید به تک‌تک کامنت‌ها پاسخ دهید.کامیت‌های مربوط به بازخوردهای اولیهٔ خود را جدا ارسال کنید. بررسی‌کننده‌ها باید بتوانند نتیجهٔ نظرات خود را به صورت جداگانه ببینند.وقتی کد دیگران را بررسی می‌کنید قبل از هر چیز بدانید که این تغییرات در پی چه هستند (مشکلی را برطرف می‌کنند؟ تجربه‌ٔ کاربری را بهتر می‌کنند؟ کدی را بهینه‌سازی می‌کنند؟). سپس:سعی کنید همه چیز را در همان بررسی اول ببینید و مطرح کنید تا از تکرار مکررات جلوگیری شود.بین ایده‌هایی که در مورد آن‌ها کاملاً مطمئن هستید و آن‌هایی که نیستید، تفاوت ایجاد نمایید.راه‌هایی که کد را ساده‌تر می‌کنند و همچنان از پس حل مسأله برمی‌آیند را شناسایی نمایید.راه‌های جایگزین را پیشنهاد بدهید، اما فراموش نکنید که شاید نویسندهٔ کد از قبل به آن‌ها فکر کرده باشد.سعی کنید از چشم نویسنده به موضوع نگاه کنید.اگر متوجه بخشی از کد نمی‌شوید، تعارف نکنید و مطرح نمایید. ممکن است اشخاص دیگری هم به مشکل شما برخورده باشند.بد نیست بعد از نوشتن یک کامنت طولانی، خلاصه‌ای از آن را هم طرح کنید.در پایانهمهٔ آنچه ترجمه کردم، به کار شرکت کوچک ما نمی‌آید و این در حالی‌ست که همهٔ آنچه در متن اصلی آمده بود را هم ترجمه نکردم.مثلاً ما در این مراحل ابتدایی از همکارانمان خواسته‌ایم که تنها به بررسی ظاهری کدها اکتفا کنند و پیشنهادهای بهبود را جداگانه مطرح نمایند.به هر حال خیلی مهم است که بدانیم هدف اولیه از فرآیند بررسیِ کد، هم‌افزایی و همگرایی میان افراد تیم است و نه برعکس. جایگاه‌ها مدام تغییر می‌کنند و بررسی‌کننده و بررسی‌شونده با هم جابه‌جا می‌شوند و قرار نیست تلافی نقد یکدیگر را سر هم دربیاورند. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Sat, 21 Apr 2018 11:20:54 +0430 https://virgool.io/laravel-community/laravel-0-to-60-puysjvpr7tud اینجا در ویرگول گفته بودم که کتابی برای آموزش لاراول در دست نگارش دارم و تصمیم گرفته‌ام آن را، به تدریج و همین طور که هر درس نوشته می‌شود، به صورت آزاد در گیت‌هاب منتشر کنم. (اینجا)اگر هم نگفته بودم و ندیده‌اید، حالا می‌گویم.لاراول، از صفر تا شصت: راهنمایی گام به گام برای ورود به دنیای لاراولحالا چرا شصت؟هیچ کتاب و نوشته‌ای در دنیا وجود ندارد که همه چیز را به کسی آموزش دهد. این کتاب نیز با چنین هدفی نگاشته نشده و از آن مهم‌تر، خود من هم ادعای دانستن همه چیز را درباره‌ی لاراول ندارم. کاملاً مطمئن هستم که در خلال نوشتن، چیزهای تازه‌ای یاد خواهم گرفت.اگر بتوانید شصت درصد از آنچه که در دنیای لاراول می‌گذرد را به واسطه‌ی این کتاب بیاموزید، کلاهِ نداشته‌ام را به آسمان می‌اندازم و در پوستِ داشته‌ام نمی‌گنجم که توانسته‌ام چنین چیزی بنویسم.با این حال، در «لاراول، از صفر تا شصت» به (تقریباً) تمام سرفصل‌های مرتبط با لاراول سرک خواهیم کشید و سعی می‌کنیم پوششی حداقل شصت درصدی از هر یک داشته باشیم.آپولو هوا می‌کنیم!«لاراول، از صفر تا شصت»، یازده فصل دارد که برای همه‌ی درس‌های آن برنامه‌ریزی کرده‌ام و حالا که این نوشته را می‌نویسم، در میانه‌ی فصل سوم هستم.از آنجا که کتاب هنوز به طور کامل نوشته نشده، هیچ بعید نیست تغییراتی در تعداد و جاگذاری درس‌ها روی دهد، اما فصل‌ها، به احتمال زیاد، همین هستند که در نمودار زیر برای خودم ترسیم کرده‌ام. نقشه فصل‌های کتاب «لاراول، از صفر تا شصت»اغلب کتاب‌ها و دوره‌های برنامه‌نویسی وب، فرآیند آموزش را با ایجاد یک سرویس وبلاگ جلو می‌برند که هرچند آموزنده است، اما حوصله‌ی آدم را از شدت تکراری بودن سر می‌برند. ما اما در «لاراول، از صفر تا شصت»، می‌خواهیم نرم‌افزار ساده‌ای برای مدیریت یک برنامه‌ی فضایی کوچک بسازیم و سعی کنیم از همه‌ی ویژگی‌های لاراول در آن استفاده کنیم.مجوز انتشارنسخه‌ی وب کتاب، توسط نرم‌افزار میرا در بستر Perl و به صورت مجموعه‌ای از فایل‌های Markdown مهیا شده و توسعه‌دهنده‌ی آن،کیاوش، زحمت زیادی برای آغاز این راه متحمل شد.متن کتاب «لاراول، از صفر تا شصت»، را با مجوز CC-BY-NC-SA 4.0 International، به صورت رایگان منتشر می‌کنم که استفاده از آن برای دیگران سخت نباشد. هرچند که نسخه‌ی وب کتاب و متن آن رایگان است، اما طبیعتاً از پول بدم نمی‌آید و بسیار خوشحال می‌شوم که نگاهی به صفحه‌ی «حمایت از کتاب» بیاندازید و در صورت امکان، به صورت مادی یا غیرمادی، از این پروژه حمایت نمایید.نسخه‌ی قابل چاپ نیز، به محض تکمیل، تسلیم استارتاپ خوب چاپخانه آنلاین می‌شود تا در قامت یک ناشر حرفه‌ای، نسبت به اخذ مجوزهای لازم نشر و چاپ کاغذی آن اقدام کند. طبیعتاً انتشار نسخه‌ی کاغذی و ارسال آن هزینه هایی در پی دارد و رایگان نیست، اما سعی می‌کنم فقط بهای تمام‌شده را روی جلد آن بنویسم.لینک کتاباگر هیچ یک از ده ـ دوازده لینکی که در این پست به صفحات کتاب در حال انتشار کتاب داده‌ام توجه شما را جلب نکرده، مجبوریم راه سرراست‌تر را برگزینیم. (: روی لینک زیر کلیک کنید:مطالعه‌ی کتاب «لاراول، از صفر تا شصت»توجه بفرمایید که کتاب در حال کامل شدن است و ممکن است با هر مرتبه مراجعه، چیزهایی تغییر کرده باشند. اگر در خبرنامه‌ی آن عضو شوید، تغییرات مهم و اضافه شدن درس‌های جدید را اطلاع‌رسانی می‌کنم.قالب نمایش در حالت موبایل کمی مشکل دارد، اما خوشبختانه فعلاً مزاحم خواندن درست مطالب نمی‌شود.بازخوردویرگول را در کنار صفحه‌ی گیت‌هاب کتاب و حساب توییتر خودم، به عنوان فضایی برای دریافت بازخوردها، نقدها و پیشنهادها، و احتمالاً بد و بیراه‌های مرتبط با کتاب در نظر گرفته‌ام. بر من منت می‌گذارید اگر در این راه یاری‌ام کنید و برای جبران این لطف، تعدادی از نسخه‌های چاپی کتاب را به عنوان تشکر، به دوستانی که با مرور متن و تذکر اشتباه‌ها کمک کرده‌اند، تقدیم خواهم نمود. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Wed, 21 Feb 2018 01:06:55 +0330 https://virgool.io/apieco/mvc-i06wbpjwatco مشغول نوشتن کتابی با موضوع آموزش لاراول هستم که تصمیم دارم آن را به شکل آزاد و به صورت تدریجی در صفحه‌ی گیتهابم منتشر کنم. کارهای مقدماتی را انجام داده‌ام، اما پیش از رونمایی، چند ایراد کوچک هست که باید برطرف شوند. از آنجا که لاراول فریمورکی‌ست که با نگاهی به معماری MVC پیاده‌سازی شده، لازم است که پیش از شروع تصوری از این معماری وجود داشته باشد. در محتوای فارسی وب، نوشته‌ی جذاب و خوانایی نیافتم که به آن ارجاع دهم. صفحه‌ی ویکی‌پدیا آن قدر گنگ نوشته شده که برخی جاها به زحمت مرزهای جمله را تشخیص می‌دهم و نیازمند اصلاح است، اما خودم معمولاً از این اصلاح طفره می‌روم، به هزار و یک دلیل. اول آن که تنبلم و ویکی‌نویسی پیچیدگی زیادی دارد و از حوصله‌ام خارج است.خلاصه آن که امروز نشستم و درسی از کتاب را که به معرفی معماری MVC اختصاص داشت، نوشتم و آنچه در ادامه خواهید، همان نوشته است که به‌زودی در کتاب نیز ظاهر خواهد شد.ورود به مطلبمعماری سه لایه‌ی MVC، ایده‌ای از ساخت برنامه‌ها است که در آن، فرآیند اجرایی برنامه به سه بخش متفاوت و مستقل از یکدیگر تقسیم می‌شوند. حرف M، ابتدای واژه‌ی Model است که ما آن را «مدل» می‌خوانیم.حرف V، ابتدای واژه‌ی View است که ما آن را «نمایش» می‌خوانیم.حرف C، ابتدای واژه‌ی Controller است که آن را «کنترل» می‌خوانیم.لایه مدلمدل، لایه‌ای از برنامه است که به ذخیره‌ی دائمی داده‌های برنامه مربوط است و به بیانی شفاف‌تر، با دیتابیس در ارتباط است. پردازش داده‌ها، چه پیش از ذخیره‌ی داده‌ها و چه پس از آن، هنگام استفاده، بر عهده‌ی لایه‌ی مدل است.مهم است که بدانیم لایه‌ی مدل در این معماری، نسبت به آنچه در بیرون از آن اتفاق می‌افتد، نابینا است. این که داده‌هایی که ذخیره می‌شوند از کجا و به چه طریقی به دست آمده‌اند و این که داده‌هایی که استخراج می‌شوند قرار است به چه کار آیند، به لایه‌ی مدل ارتباطی ندارد. لایه‌ی مدل نه این چیزها را می‌داند و نه در طلب دانستن آن‌ها، ارتباطی با دیگر لایه‌ها برقرار می‌کند. لایه‌ی مدل را نباید دیتابیس یا دروازه‌ی ارتباط با سامانه‌ای دیگر در نظر گرفت. لایه‌ی مدل، محلی است برای کار با داده‌ها، به معنای عام کلمه، بدون آن که از دلیل استفاده از داده‌ها بپرسد و اما و اگری بیاورد.از آنجا که داده‌ها قلب هر نرم‌افزاری هستند، مدل‌های یک برنامه، اغلب پیچیده‌ترین قسمت هر برنامه قلمداد می‌شوند که فرآیندهای اصلی در آنجا روی می‌دهد.لایه نمایشدرک لایه‌ی نمایش، از همه ساده‌تر است. این لایه همان است که رابط کاربری را رقم می‌زند و ابتدا و انتهای چرخه‌ی برنامه است. در واقع کاربران از این لایه با برنامه ارتباط برقرار می‌کنند و داده‌هایی را وارد می‌کنند و سپس در همین لایه نتیجه را مشاهده می‌نمایند. در نرم‌افزارهای تحت وب، همچون محصولاتی که با پی‌اچ‌پی خلق می‌شوند، لایه‌ی نمایش همان است که با تگ‌های html ساخته می‌شود و با استفاده از استایل‌های css زیبا می‌شود.تأکید می‌کنم لایه‌ی نمایش، آنچنان که از نامش برمی‌آید، تنها به خروجی برنامه اختصاص ندارد و شامل ورودی نیز می‌شود. لایه کنترللایه‌ی کنترل، رگ حیاتی برنامه است که اجزای آن را به یکدیگر متصل می‌سازد. درخواستی که کاربران از طریق لایه‌ی نمایش صادر کرده‌اند، در لایه‌ی کنترل وصول می‌شود، به مسیر درست هدایت می‌شود، اعتبارسنجی‌های لازم (به کمک لایه‌ی مدل) روی آن صورت می‌گیرد، و اگر مشکلی نباشد نهایتاً برای ذخیره‌سازی یا استخراج به لایه‌ی مدل ارسال می‌شود و نتیجه‌ها یا بازخوردهای آن دوباره به لایه‌ی نمایش بازگردانده می‌شود تا به اطلاع کاربر برسد.باید توجه داشت که در یک برنامه‌ی تحت وب، همه‌ی درخواست‌های کاربران لزوماً از لایه‌ی نمایش عبور نمی‌کنند. اگر از APIها که اساساً لایه‌ای به عنوان لایه‌ی نمایش ندارند نیز بگذریم، بسیاری اوقات شما با کلیک بر لینکی که از قبل و توسط شخصی دیگر مهیا شده وارد برنامه می‌شوید و به این صورت، بدون عبور از لایه‌ی نمایش، درخواست خود را مستقیماً به لایه‌ی کنترل می‌فرستید.ارتباط بین لایه‌هاپرسشی که بی‌درنگ پس از مشخص شدن وظیفه‌ی هر لایه مطرح می‌شود این است که لایه‌ها چگونه و در چه شرایطی می‌توانند با یکدیگر ارتباط برقرار نمایند. فابیو چِواسکو در مقاله‌ی خود با عنوان نخستین لقمه از کیک‌پی‌اچ‌پی، می‌گوید:پیاده‌سازی درست معماری MVC، مستلزم آن است که هیچ ارتباطی بین لایه‌های مدل و نمایش وجود نداشته باشد و تمام پردازش‌های منطقی توسط لایه‌ی کنترل انجام شود.آنچه چواسکو از ارتباط میان لایه‌ها در نظر دارد چیزی شبیه این شکل است:این نظر او، مخالفین سفت و سختی دارد. بسیاری معتقدند که نه‌تنها لایه‌ی نمایش می‌تواند با لایه‌ی مدل ارتباط برقرار کند و آنچه مایل است را دریافت نماید، بلکه این تنها لایه‌ی نمایش است که اجازه‌ی چنین کاری را دارد.طرفداران دیدگاه دوم معتقدند که درخواست‌ها از طریق لایه‌ی کنترل مسیریابی می‌شوند و به لایه‌ی مدل می‌رسند و نتیجه‌ی کار در لایه‌ی نمایش به دست کاربر می‌رسد.منتقدان نظریه‌ی دوم می‌گویند که این ایده، ناقض اصلی است که طی آن مدل باید چشم و گوش بسته به فرمان‌ها عمل کند و بدون توجه به مرجع و منبع درخواست‌ها، نسبت به برآورده ساختن دستورات اقدام کند، چرا که در این طرح ارتباطی، مدل‌ها دستور خود را از جایی (کنترلر) می‌گیرند و پاسخ را به جای دیگری (نمایش) می‌فرستند و به این ترتیب، خودشان جزئی از مسیر برنامه می‌شوند.اختلاف‌نظرها پایان‌ناپذیرنداجازه دهید ادامه‌ی این دعوا و نظریه‌های دیگر را به اهل فن واگذار کنیم و شما هم اگر کنجکاو شده‌اید، قدر کنجکاوی خود را بدانید و تحقیق در این زمینه را در منابع تخصصی‌تر پی‌گیری کنید. آنچه مسلم است، آن است که نرم‌افزار ما در معماری MVC، به سه لایه‌ی مستقل تقسیم می‌شود که هر لایه کار مربوط به خود را در فضایی تقریباً مستقل از دیگران به انجام می‌رساند و خوشبختانه در مورد ماهیت هر یک از این لایه‌ها اختلاف نظری وجود ندارد.این اندازه بدانید که لاراول، به عنوان یک فریمورک (تقریباً) MVC، در مورد ارتباط لایه‌ها چندان سخت‌گیر نیست و به لایه‌ها اجازه‌ی ارتباط با یکدیگر را می‌دهد، اما ایده‌آل همان است که فابیو چواسکو می‌گوید. در یک مثال واقعیمعماری نرم‌افزار با سبک MVC، در ابتدا از زبان برنامه‌نویسی اسمال‌تاک آغاز شد و در برنامه‌های وب به اوج رسید، اما باید بدانیم تقسیم کار به این نحو، محدود به این نرم‌افزار و آن نرم‌افزار، و یا حتی محدود به دنیای نرم‌افزار نیست. ابهام‌ها با یک مثال خوب روشن‌تر می‌شوند. مطمئنم برای کارهای مختلف گذارتان به بانک‌ها افتاده است. بانک مثال ما ممکن است کمی با بانک‌های واقعی متفاوت باشد، اما مراد ما را برآورده می‌سازد.پرده اولفرض کنید برای مسدود کردن کارت عابربانکتان به یکی از شعبه‌های بانک خود می‌روید. از در شعبه وارد می‌شوید و شماره‌ای می‌گیرید و وقتی نوبتتان فرا رسید به یکی از باجه‌ها می‌روید. این درست مانند آن است که به سایتی بروید و روی یکی از گزینه‌های منو کلیک کنید و به صفحه‌ای که مرتبط با کار شماست هدایت شوید. در این‌جا تقاضای خود را در لایه‌ی نمایش (دستگاه نوبت‌دهی) ثبت کرده‌اید و سپس از طریق لایه‌ی کنترل (فرآیند پشت پرده‌ی نوبت‌دهی) به باجه‌ی مربوطه هدایت شده‌اید.پرده دومپشت باجه روی صندلی می‌نشینید و درخواستتان را مطرح می‌کنید و یک فرم به شما می‌دهند تا تکمیل کنید. این درست مانند آن است که در صفحه‌ای که هدایت شده‌اید با یک فرم اینترنتی روبه‌رو شوید. در این جا بار دیگر تقاضای خود را به لایه‌ی کنترل (متصدی باجه) گفته‌اید و او بدون نیاز به مراجعه به لایه‌ی مدل (سوابق اطلاعاتی شما) ، لایه‌ی نمایش را فراخوانی کرده است (فرم).پرده سومفرم را پر می‌کنید و همراه با کارت ملی به متصدی باجه تحویل می‌دهید و او شروع به بررسی می‌کند تا همه‌ی موارد را پر کرده باشید، تاریخ درست درج کرده باشید، و اطلاعاتی که روی فرم نوشته‌اید با کارت ملی شما مطابقت داشته باشد و تصویر روی کارت با چهره‌ی شما وفق کند و سپس شروع به درج اطلاعات در کامپیوترش می‌کند و اگر همه چیز مرتب باشد و کار انجام شود، رسیدی به شما می‌دهد. در این‌جا پس از عبور از لایه‌ی نمایش (فرم و مدارک)، لایه‌ی کنترل شروع به اعتبارسنجی اطلاعات موجود می‌کند (بررسی تکمیل فرم) که ممکن است دو حالت پیش بیاید:اگر مشکلی وجود داشته باشد دوباره لایه‌ی نمایش فراخوانی می‌شود (فرم را به شما بازمی‌گردانند تا اصلاح کنید) اگر همه چیز مرتب بود، اطلاعات توسط متصدی باجه روانه‌ی لایه‌ی مدل می‌شوند (همان درج در کامپیوتر) و نتیجه‌ای که لایه‌ی مدل می‌دهد توسط لایه‌ی کنترل (آقا یا خانم متصدی باجه) به شما تحویل می‌شود و این همان رسیدی (لایه‌ی نمایش) است که تحویل گرفته‌اید.یک بار مرور کنیم... لایه‌ی نمایش همان فرم‌هایی بود که پر کردیم و رسیدهایی که تحویل گرفتیم. نقش لایه‌ی کنترل را متصدی باجه بر عهده داشت که بدون دسترسی به اطلاعات ما، با شنیدن درخواستمان فرم درست را در اختیارمان گذاشت و بعد پس از اطمینان از صحت تکمیل فرم، سراغ درج اطلاعات (لایه‌ی مدل) رفت.لایه‌ی مدل مثال ما، در کامپیوتر جلوی روی متصدی باجه نهفته بود. ما به عنوان کاربر به آن دسترسی نداشتیم و خود متصدی باجه نیز اجازه نداشت مستقیماً به بایگانی بانک برود و اطلاعات را استخراج کند یا چیزی به پرونده اضافه نماید. او متدی از متدهایی که لایه‌ی مدل در اختیار او گذاشته بود را فراخوانی کرد و نتیجه‌ی آن را به ما گفت. به این نکته هم توجه کنید که لایه‌ی مدل، بدون توجه به دلیل مسدودی کارت، این کار را انجام داد. برای لایه‌ی مدل همین کافی بود که چنین درخواستی داده شده است تا اجرا کند. این چه وضعی است؟اگر عابری در خیابان همین فرمان را به لایه‌ی مدل می‌فرستاد باز هم کارت بانکی شما مسدود می‌شد؟ پاسخ مثبت است!لایه‌ی مدل کاری به هویت درخواست‌کننده ندارد و فرمان‌ها را اجرا می‌کند. تأمین امنیت بر عهده‌ی لایه‌ی کنترل است و دقیقاً به همین دلیل بهتر است معماری ما طوری پیاده‌سازی شود که لایه‌ی نمایش نتواند دستوری به لایه‌ی مدل بدهد و اگر به هر دلیل راهی پیدا کرد و این دستور را صادر کرد، درست مانند آن است که رخنه‌ای امنیتی روی داده باشد.لایه‌ی کنترل، ممکن است برای اجرای وظیفه‌ی امنیتی خود از لایه‌ی مدل کمک بگیرد. مثلاً متصدی باجه، اطلاعات مراجعه‌کننده را با آنچه در پرونده‌ی اوست مطابقت دهد. در این صورت هم خود به سراغ اطلاعات نمی‌رود و از متدی دیگر در لایه‌ی مدل کمک می‌خواهد.قضاوت در مورد MVCاستفاده از معماری MVC در برنامه‌ها مزیت‌هایی به همراه دارد:بخش‌های مختلف نرم‌افزار می‌توانند توسط برنامه‌نویسان مختلفی تکمیل شوند.برنامه‌نویسان می‌توانند به طور هم‌زمان روی بخش‌های خود کار کنند.بخش‌های مرتبط با هم، انسجام بیشتری با یکدیگر دارند.وابستگی بخش‌ها به عملکرد یکدیگر در حداقل ممکن قرار می‌گیرد.ویرایش برنامه ساده‌تر انجام می‌شود.می‌توان بدون دست زدن به لایه‌های دیگر، چندین ظاهر مختلف (لایه‌ی نمایش) برای مشتری‌های مختلف تدارک دید. اما MVC نیز مثل هر چیز دیگر این دنیا، سراسر خیر نیست و مشکلاتی را هم به همراه می‌آورد.تمام کارهای مرتبط با یک موضوع، در یک واحد از برنامه در کنار هم اجرا نمی‌شوند. پیچیده‌تر شدن لایه‌ها و ارتباط آن‌ها، دنبال کردن کد را دشوار می‌کند.معماری مبتنی بر MVC، به چندین تخصص مختلف نیاز دارد که اغلب در یک نفر جمع نمی‌شوند.مزایای معماری MVC آن قدر زیاد هست که به دردسرهایش بیارزد و اگر بخواهیم آن را کنار بگذاریم، بهتر است با چیز بهتری جایگزین کنیم. عجالتاً لاراول، که در این کتاب در پی آموختن آن داریم، یک فریمورک تقریباً مبتنی بر معماری MVC محسوب می‌شود و بهتر است اصولی که باید بدان‌ها وفادار باشیم را پیش از ورود به این دنیا، بدانیم.(خوب است بدانیم که خالق لاراول، این فریمورک را MVC نمی‌داند، اما خوشبختانه به دستورالعمل این معماری در جداسازی لایه‌ها وفادار است و آن را قبول دارد.)نتیجهمعماری MVC در خلاصه‌ترین توصیف ممکن، به این شکل تعریف می‌شود:هیچ لایه‌ای غیر از مدل حق دسترسی به اطلاعات دیتابیس را ندارد.هیچ لایه‌ای غیر از نمایش حق ارتباط با کاربر را ندارد.هیچ لایه‌ی غیر از کنترل، اجازه‌ی مسیرسازی میان بخش‌های مختلف را ندارد. همان طور که می‌بینید، گاهی توصیف‌های سلبی بهتر از شرح مستقیم یک چیز عمل می‌کنند.این متن، به صورت Markdown نوشته شده بود و وقتی آن را در محیط ویرگول paste کردم، تیترها و لینک‌ها، بدون دستکاری من، به‌خوبی منتقل شدند. باید اعتراف کنم که انتظارش را نداشتم. (: طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Sat, 03 Feb 2018 01:02:46 +0330 https://virgool.io/@taha/proposal-headaches-drfcwshxy5ox به جز «طرح تفصیلی»، نام‌های دیگری هم دارد. بعضی‌ها اسمش را «سند فنی» می‌گذارند، بعضی‌ها که خارجی‌ترند به آن «پروپوزال»‌ می‌گویند، عده‌ای آن را خیلی ساده «طرح» می‌خوانند، و عده‌ی بیشتری هم اساساً اسمی روی آن نمی‌گذارند.این جور «پروپوزال»، مد نظر این نوشته نیست. عکس را نادیده بگیرید.اگر از آن دسته آدم‌هایی هستید که بدون مشخص شدن ابعاد کاری که باید انجام دهید وارد قراردادی می‌شوید و چیزی می‌سازید که «کار می‌کند»، به خواندن این نوشته ادامه ندهید. دردی که از آن می‌نالم را نچشیده‌اید و آنچه می‌گویم را نمی‌فهمید و فانتزی می‌پندارید.اگر از آن یکی دسته آدم‌هایی هستید که متخصص امر طرح نوشتن هستید و در ذهنتان مشغول برشمردن تفاوت‌های ساختاری این اسم‌هایی هستید که آن بالا ردیف کردم، رها کنید و به خواندن ادامه دهید. می‌دانم که درست می‌گویید، اما موضوع این نیست. نامش هرچه که باشد، همین که از جنس طرح باشد، با درد و رنج عجین است.نوشتن طرح‌ها حیاتی است. با همین طرح‌هاست که سنگ میان مجری و کارفرما وا کنده می‌شود و هر دو مطمئن می‌شوند که از یک چیز واحد سخن می‌گویند. نگارش یک طرح خوب و با جزئیات کافی، تنها راه تخمین زمان اجرا و محاسبه‌ی درست و منصفانه‌ی قیمت تمام‌شده‌ی کار است و نقشه‌ی پیشرفت کارها با همین طرح‌ها میسر می‌شود. سنگ بنای معماری آنچه که قرار است ساخته شود بر همین طرح استوار می‌شود. نگارنده‌ی این سطور (همیشه دوست داشتم از این عبارت استفاده کنم) می‌داند که بسیاری از مجریان، تا هنگامی که مجبور نباشند، از نوشتن و شفاف کردن کاری که قرار است انجام دهند طفره می‌روند، محصول را بر نقشه‌ای که در ذهنشان است جلو می‌برند و در انتها هم از کارفرمای (به قول خودشان) زیاده‌خواهی که از اول نگفته که دقیقاً چه می‌خواسته گلایه می‌کنند. تازه وقتی هم مثلاً از ناحیه‌ی کارفرمایی دولتی مجبور به نوشتن طرح می‌شوند، به‌خوبی می‌دانند آنچه می‌نویسند جنبه‌ی زینتی دارد و هیچ گاه مورد استناد و استفاده قرار نمی‌گیرد و بنابراین خیلی برای دخیل کردن جزئیات به خودشان زحمت نمی‌دهند.نگارنده‌ی این سطور همچنین می‌داند که این گونه مجریان، هرگز درس نمی‌گیرند و دنبال نوشتن سند فنی دقیق و طرح اجرایی کارشان نخواهند رفت. چرا؟چون درد دارد. چرا درد دارد؟عرض می‌کنم.خودِ نوشتن سخت است، چه برسد به طرح نوشتن!در زمانه‌ای زندگی می‌کنیم که آدم‌های تحصیل‌کرده‌ی آن نمی‌توانند آنچه را در ذهن دارند با الفبای زبان مادریشان روی کاغذ بنویسند یا با کیبورد تایپ کنند. باور نکنید که وقت ندارند یا حوصله‌شان نمی‌رسد. آن‌ها نمی‌توانند. هرچقدر هم که به آن‌ها پول بدهید و تطمیعشان کنید، هرچقدر هم که از قدرت مدیریتی‌تان مایه بگذارید و تهدیدشان کنید، آن‌ها توانش را ندارند که چند خط بنویسند و منظورشان را برسانند.نوشتن همیشه سخت بوده و گویا در این روزگار سخت‌تر هم شده است.طرح را نمی‌شود سرسری نوشتکدها را می‌شود سرسری نوشت و بعد در فرصتی مناسب اصلاح کرد. اما طرحی فنی که قرار است ضمیمه‌ی قرارداد شود شوخی‌بردار نیست. تعهدآور است و برای هر خط و هر کلمه‌اش باید جواب‌گو بود. آنچه به عنوان طرح نوشته می‌شود، باید تمام موانع پیش رو را در نظر آورده باشد. در زمان اجرا نمی‌شود بهانه آورد و گفت انجام این کار ممکن نیست و نیازمند صرف هزینه‌ی بیشتر است. باید همان اول حسابش را می‌کردید.طرح‌ها در زمانی نوشته می‌شوند که هنوز هیچ قراردادی در کار نیست. اگر کافرما بعد از نوشتن شدن طرح پشیمان شود، دست مجری به هیچ جا بند نیست. زمانی که برای نوشتن طرح صرف کرده، برای همیشه روانه‌ی زباله‌دان می‌شود و این کابوس که حالا همین طرح حاضر و آماده در قراردادی دیگر و با مجری دیگی مورد استفاده قرار می‌گیرد، هرگز رهایش نخواهد کرد. بدتر از همه آن که طرح‌هایی که برای کاری نوشته شده‌اند، معمولاً به درد کار مشابه دیگری نمی‌خورند، چرا که بیشتر این طرح‌ها (لااقل در حوزه‌ی برنامه‌نویسی که من به آن مشغولم) بر ایده‌ای اولیه از کارفرما استوار شده‌اند و استفاده از آن ایده‌ها برای مشتری دیگر، اخلاقی نیست. (بله، آدم‌هایی که به اخلاقیات اعتقاد داند هنوز اینجا و آنجا به زندگیشان ادامه می‌دهند؛ مثلاً همین حقیرِ سراپا تواضع!)طرح‌ها به وجب نمی‌آیندسرانجام پس از صرف چهار روز کاری، طرحی می‌نویسید که همه‌ی جوانب مشهود را در آن لحاظ کرده‌اید و حاصل کار در یک فایل متنی پانزده صفحه‌ای گرد آمده است. انتظار چه بازخوردی دارید؟توقع دارید برایتان هورا بکشند؟ یک نوبت ناهارتان را گرم کنند؟ خسته‌نباشیدی بگویند؟زهی خیال باطل.«چهار روز طول کشید؟ مگه ساعتی چند کلمه تایپ می‌کنی مهندس؟ می‌دادی فلانی دو ساعته می‌نوشت دیگه!»و بعد در حالی که لبخند می‌زنند و کاغذهای چاپ‌شده را در هوا تکان می‌دهند ادامه می‌دهند:«خداییش نوشتن این ۹۶ ساعت وقت می‌بره؟»خواندنش هم درد داردفکر می‌کنید فقط نوشتن سخت است؟ خواندنش هم برایشان سخت است. طرح را پس از چهار روز می‌نویسید و در اختیار همکارانتان قرار می‌دهید. همه می‌دانیم عبارتی که در پاراگراف بالایی نوشتم و از لحاظ شدن همه‌ی جوانب مشهود سخن گفتم بلوفی بیش نیست. هیچ آدم معمولی غیرنابغه‌ای نمی‌تواند در چهار روز، همه‌ی جوانب کاری که هنوز اجرایی نشده و تنها در ذهنش است را ببیند و طرحی بی‌اشکال بنویسد. یک طرح خوب، بعد از نوشته شدن باید نقد شود، اما به همان‌ها که می‌گفتند دو ساعته هم می‌توان نوشت، دو ماه وقت بدهید. آن را نمی‌خوانند و اگر آدم‌های مؤدبی باشند (که خوشبختانه معمولاً هستند)، به صراحت نمی‌گویند:«مهندس نمی‌شد خلاصه‌ترش بکنی؟»کار اصلی چه می‌شود؟طرح نوشتن به چشم هیچ کس نمی‌آید. همکاران از شما انتظار دارند کار چند روز را در چند ساعت انجام دهید و در عین حال، از روند کار روزانه‌ی معمول خود نیز عقب نمانید.دقت بفرمایید که این انتظار همیشه از سوی رئیس‌ها و بالادست‌ها نیست. حتی شرکا و همکاران هم‌سطح شما نیز تنها روی آن بخش از کارتان ارزش‌گذاری می‌کنند که مستقیماً به کسب درآمد و پیشبرد پروژه منجر شده باشد. بنابراین ساعت‌های نازنینی که به نوشتن طرح پرداخته‌اید، نه‌تنها باعث افتخار نیست، بلکه در حساب بدهکاری شما به شرکت منظور می‌شود.حالا چه شده که یاد این حرف‌ها افتادم؟مدت‌هاست که می‌خواهم به سراغ ویرگول بیایم و «حالا چرا لاراول» را ادامه دهم، و از آن مهم‌تر،‌ روی کتابی که نوشتنش را آغاز کرده‌ام کار کنم. اما برای نوشتن طرح‌هایی که لازمه‌ی کار من و شرکتم هستند، مجبورم ساعت‌های استراحت و غیرکاری خود را اختصاص دهم.برنامه‌ی امروز من این بود که در این روز تعطیل، دو طرح ناتمام را به سرانجام برسانم و بعد دو مطلب برای دو وبلاگم (اینجا و چرکنویس) بنویسم. اما در ساعت نه شب، وقتی تازه یکی از طرح‌ها تمام شد و می‌خواستم از لاراول بنویسم، به فکرم رسید که چرا از «طرح» ننویسم که داغش هم تازه‌تر است.حالا در انتهای آدینه‌ی زیبا، به جای دو مطلب وبلاگ به خودم و دو طرح به مشتری، دو مطلب وبلاگ به خودم و یک طرح به مشتری بدهکارم. (:پیشرفت کمی نیست، اما جایش درد می‌کند. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Fri, 29 Dec 2017 22:24:14 +0330 https://virgool.io/laravel-community/why-laravel-pagination-a6kexyi9tcjz فرض کنید وبلاگی ساخته‌ایم که چیزی حدود سیصد پست دارد که باید در صفحه‌ای نمایش داده شود، ولی هر صفحه، جای حداکثر ده نوشته دارد.با لاراول و بی لاراول چه کنیم؟به دنبال مطالبی که با عنوان «حالا چرا لاراول» نوشتم، امروز می‌خواهم از صفحه‌بندی بگویم.اینجا یک وبلاگ آموزشی نیست و نوشته‌ها هم قرار نیست آموزشی باشند. صرفاً می‌خواهم دوستانم را به همه معرفی کنم.باز هم تکرار می‌کنم:لاراول، دنیایی است با ابزارهایی رنگ و وارنگ و اسم‌های جذاب، که اغلب از قبل وجود داشته‌اند و حیاتشان را مدیون لاراول نیستند، اما زیبایی در کنار هم بودنشان را چرا.اول، بدون کمک لاراول با استفاده از یک کوئری ساده، ده رکوردی که قرار است نمایش دهیم را جدا می‌کنیم. (برای این کار لازم است بدانیم اکنون در صفحه‌ی چندم هستیم تا شمارش را از جای درست شروع کنیم که زیاد سخت نیست.)ده رکورد انتخاب‌شده را در صفحه نمایش می‌دهیم.پایین یا بالای صفحه را به یک شمارشگر صفحه اختصاص می‌دهیم که مردم بتوانند به صفحه‌ی قبل و بعد بروند و تعداد کل صفحات را ببینند و بدانند که اکنون در کدام صفحه هستند. استایل مربوط به این کار را هم لابد از قبل حاضر کرده‌ایم و داریم.از آنجا که شمارشگر تعداد صفحات را نشان می‌دهد، باید با کوئری دیگری تعداد کل رکوردها را بشماریم تا بتوانیم آن را بر عدد ده تقسیم کرده و تعداد صفحات را بیابیم.لینک‌های شمارشگر را طوری می‌سازیم که شماره‌ی صفحه‌ای که به آن اشاره می‌کنند را با متد GET از سرور درخواست کنند.شمارشگر ما صفحه‌ی فعلی را باید از همان متد GET که دستور قبلی فرستاده بفهمد و آن را متمایز بسازد تا مردم بفهمند که در کدام صفحه هستند.شمارشگر ما باید دکمه‌هایی برای پرش سریع به اولین و آخرین صفحه داشته باشد. این هم زیاد سخت نیست و انجامش می‌دهیم.برنامه‌ی ما باید پرت و پلاهایی که کاربران شیطان وارد می‌کنند را هضم نماید؛ مثل وقتی که یک نفر در شش صفحه اطلاعات، دنبال صفحه‌ی هفتادم یا صفحه منفی سوم می‌گردد.تمام شد. به همین راحتی (؟!) یک صفحه‌بندی خوب و بی‌منت درست کرده‌ایم.حالا، با کمک لاراولگام اول، در کنترلر...در انتهای همان دستوری که برای فراخوانی پست‌های وبلاگ داده‌ایم، یک فلش می‌گذاریم و متدی به نام paginate را صدا می‌زنیم و به او می‌گوییم که گنجایش صفحه‌ی ما چقدر است. به این صورت:$posts = Post::where('category','folan')->paginate(10) ;مرحله دوم، هنگام نمایش...در فایل view، پس از آن که ده پست وبلاگی که با متغیر posts$ به دستمان رسیده را هر جور دلمان خواست نمایش دادیم، شمارشگر خود را قرار می‌دهیم.به این صورت:{!! $posts->render() !!}مرحله سومی وجود ندارد!تمام شد و رفت.لاراول یک شمارشگر باوقار و شیک بوت‌استرپ، با تمام خصوصیاتی که برشمردیم را برایمان می‌سازد، لینک‌های آن را می‌سازد و متغیرهای مورد نظر را به سمت سرور ارسال می‌کند و خودش هم آنجا حی و حاضر است و تجزیه و تحلیلشان می‌کند و متوجه می‌شود که اکنون در کدام صفحه قرار داریم و صفحه‌ی مورد نظر را متمایز می‌سازد. لاراول، حتی استایل‌های مورد نظر را از پیش حاضر کرده و مادامی که نخواهیم تغییری در ظاهر آن دهیم، واقعاً هیچ کار دیگری نیست که لازم باشد انجام دهیم.نمایی از یک صفحه‌بندی ساده لاراولی، با داده‌های آزمایشی که تصادفی در جدول ریخته شده‌انددر اینجا اگر انتقادی به لاراول باشد، این است که دل یک برنامه‌نویس خسته، به همین کارهای ساده‌ی بدون چالش خوش است که لاراول ترجیح می‌دهد خودش انجام بدهد!پیش از پایاناگر به ادامه‌ی این نوشته‌ها علاقه‌مندید و عضو ویرگول نیستید که مستقیم پی‌گیر شوید، از فید آراس‌اس استفاده کنید یا در توییتر بنده را فالو بفرمایید.اگر دستی بر قلم دارید، با همین هشتگ «چرا لاراول» در همین سایت معظم ویرگول، نیز می‌توانید شروع به نوشتن درباره‌ی خوبی‌ها و بدی‌های این فریمورک کنید تا همه استفاده نماییم.پایان (: طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Sat, 21 Oct 2017 23:47:32 +0330 https://virgool.io/laravel-community/why-laravel-artisan-v6clt4sipkom این روزها هر تکنولوژی‌ای دستیاری را به کاربرانش می‌دهد و لاراول هم از قافله عقب نمانده است.به دنبال مطالبی که با عنوان «حالا چرا لاراول» نوشتم، امروز می‌خواهم دستیار زیبای کدنویسی در لاراول را معرفی کنم. اینجا یک وبلاگ آموزشی نیست و نوشته‌ها هم قرار نیست آموزشی باشند. صرفاً می‌خواهم دوستانم را به همه معرفی کنم. دوباره تکرار می‌کنم:لاراول، دنیایی است با ابزارهایی رنگ و وارنگ و اسم‌های جذاب، که اغلب از قبل وجود داشته‌اند و حیاتشان را مدیون لاراول نیستند، اما زیبایی در کنار هم بودنشان را چرا.با این مقدمه‌ی کوتاه، این بار به سراغ دوست عزیزی می‌روم به نام Artisan.چطور صدایش کنیم؟حرف S در زبان انگلیسی، اغلب با صدای «س» و گاهی هم با صدای «ز» خوانده می‌شود، هرچند «ش» و «ژ» و چیزهای دیگری هم از آن شنیده شده است. حرف A را هم که به هزار و یک جور شناخته و ناشناخته می‌خوانند.اصولاً در زبان انگلیسی از روی املای کلمات نمی‌توانیم حدس درستی درباره‌ی قرائتشان بزنیم.با گوش دادن به فیلم‌های آموزشی نظیر مجموعه‌ی ارزشمندی که جفری وی در لاراکست عرضه می‌کند، چیزی شبیه «آرتیسِن» یا «آرتیزِن» (با یک کسره‌ی خیلی ریز و زیرپوستی) می‌شنویم. اما من ترجیح می‌دهم به جای اعتماد به گوش‌هایم، تلفظ درست را از دیکشنری ببینم و کجا بهتر از لانگمن.دیکشنری لانگمن، دو تلفظ ˌɑːtɪˈzæn و ˈɑːrtɪzən را به ترتیب برای گویش‌های انگلیسی و آمریکایی این کلمه معرفی کرده که به فارسی می‌توانیم «آتیزَن» و «آرتیزِن» بنویسیم.القصه، من «آرتیزان» می‌نویسم، چون هم برای مخاطب فارسی‌زبان آشناتر است و هم از تلفظ‌های درست آن دور نیست. اسم قحط بود؟آرتیزان، به روایت همان دیکشنری که عرض کردم، به کسی می‌گویند که محصولی را ماهرانه، با دست‌های خویش خلق می‌کند. صنعتگری و هنر،‌ دو مفهومی است که در این کلمه در هم آمیخته‌اند. هیچ واژه‌ی فارسی‌ای نمی‌شناسم که حق مطلب را در مورد این کلمه ادا کرده باشد و برای همین، از ترجمه‌ی شعاری که خالق لاراول برای مخلوقش انتخاب کرده، درمی‌مانم:Laravel: PHP Framework for Web Artisansلاراول، بستری برای «آرتیزان»هاست و نام دستیارش را هم که در واقع یک کنسول خط فرمان (CLI) است، «کنسول آرتیزان»‌ گذاشته.از کجا نصبش کنیم؟آرتیزان نیازی به نصب ندارد. در لاراول، همه چیز خیلی ساده‌تر از این حرف‌هاست.فایل‌های یک پروژه‌ی لاراولی را از یک جایی (گیت هاب، یا کامپیوتر دوستتان) کپی کنید و در لوکال هاست خودتان بریزید و ملاحظه بفرمایید که آرتیزان هم همان جاست. کافی است با کنسول خط فرمان خود (ترمینال، کامندلاین، یا هرچه که اسمش هست)، به فولدری که فایل‌ها در آنجاست بروید و آرتیزان را فرا بخوانید. به این شکل:php artisan listبخشی از امکانات ریز و درشتی که آرتیزان در اختیار ما می‌گذارد، به روایت خودش!آرتیزان چه گلی به سرمان می‌زند؟در مطلب قبل این مجموعه، از اهمیت مایگریشن‌ها و سیدرها نوشتم و عرض کردم که ما لازم نیست سرمان را برای ساخت این فایل‌ها در جای درستشان درد بیاوریم و بعد هم به خاطر بسپاریم که هر کدام باید از کدام کلاس اکستند شده باشد و تازه ساختار کلاس را در آن بنویسیم و namespace درست را تعریف کنیم و تا یادمان نرفته، یک تگ باز شدن php هم اولش بگذاریم.آرتیزان ترتیب همه‌ی این کارها را می‌دهد.php artisan make:migration create_filans_tableو ناگفته پیداست که آرتیزان چیزهای دیگری را هم برایمان می‌سازد. اسکرین شات بالا را عمداً طوری بریدم که دستورهای خانواده‌ی make، یعنی آن‌ها که برایمان چیزی می‌سازند، در مرکز توجه باشند. اگرچه دستورهای خانواده‌ی make، پرکاربردترین دستورهای آرتیزان هنگام نوشتن پروژه هستند، اما این تمام ماجرا نیست.فرض کنید می‌خواهیم فایل‌هایی را در یک پروژه‌ی آنلاین جابجا کنیم و لازم است سایت را موقتاً از دسترس خارج نماییم. اگر میزبان سایت از پروتکل SSH پشتیبانی کند، می‌توانیم این دستور را اجرا کنیم:php artisan downو با این کار، سایت را موقتاً به حالت تعمیرات ببریم و هر گاه کارمان تمام شد،‌ با یک دستور برعکس، دوباره به زندگی بازگردانیم.php artisan upدستورات آرتیزان، راهنما هم دارند که هر الگوی دستور یادمان رفت، به داد ما برسند.php artisan tinkerاگر دستوری را با اشتباه املایی تایپ کنیم، خط فرمان آرتیزان با یک پیام خطا خیال خودش را راحت نمی‌کند و در عوض، سعی می‌کند حدس بزند که منظورمان چه بوده است.یک پینه‌دوز معرکه، در قلب آرتیزان!دستورهای خاندان make را به عنوان پرکاربردترین دستورهای آرتیزان معرفی کردم، اما اگر لازم باشد حرفم را پس می‌گیرم.وقتی پای تینکر به میان بیاید، لازم هم هست.تینکر (Tinker) به معنی وصله‌بند است و از پینه‌دوز استفاده کردم، چون بامزه‌تر بود. تینکر، ابزاری بسیار کارآمد است که همراه با آرتیزان می‌آید و می‌تواند دستورهای یک‌خطی php را، در محیط برنامه‌ی ما اجرا کند. php artisan tinkerمثال‌هایی برای استفاده از تینکر، در کنسول آرتیزانملاحظه می‌فرمایید که در کنسول تینکر، می‌توانیم دستورهایی را اجرا کنیم و نتیجه‌اش را فوراً ببینیم، بدون این که نیاز باشد بخشی از خط‌های برنامه را خراب کنیم.در تینکر، می‌توانیم هلپرهای خودمان را اجرا کنیم، می‌توانیم از توابع بومی php استفاده کنیم، متغیری را ست کنیم و آزمایشی را روی آن انجام دهیم، یا حتی چیزی را وارد سشن کنیم و دوباره آن را بخوانیم تا خیلی زیرپوستی به خواننده‌ی وبلاگ خود نشان دهیم که سشن‌ها در لاراول چقدر راحت کار می‌کنند.اگر ناامید شدیم چه؟هر وقت از زندگی ناامید شدید، آرتیزان را صدا بزنید تا جمله‌ی الهام‌بخشی برایتان بگوید!php artisan inspireآرتیزان با دیدن این دستور، کلمات قصاری را از آدم‌های بزرگی مثل ادیسون برایمان می‌گوید!نمی‌دانم این قابلیت دقیقاً به چه دردی می‌خورد. احتمالاً خالق لاراول می‌خواسته طبع شوخ خودش را راضی کند، یا شاید هم می‌خواسته اجرای دستور آرتیزان را در فهرست ده کاری که یک برنامه‌نویس قبل از خودکشی می‌کند جای دهد. یک به‌روزرسانی معرکه: به کامنت محمدحسین، ذیل همین پست، در مورد فایده‌ی Inspire توجه بفرمایید: «این طور که به نظر میاد، inspire تنها دستوری هست که شما می تونید توی routes/console.php نحوه‌ی register شدنش رو ببینید. بنابراین فکر می‌کنم سازنده‌ی لاراول قصد داشته نشون بده که شما هم به راحتی می‌تونید کامند های خودتون رو تو این قسمت register کنید.»در پایان...این نوشته‌ها قرار نیست مطالبی آموزشی باشند و یک عالمه نکات معرکه‌ی بی عیب و نقص به کسی یاد بدهند. یادتان نرود که نگارنده، یک مبتدی جاودانه است.کارهای جالبی هست که می‌توانید انجام دهید:اگر به ادامه‌ی این نوشته‌ها علاقه‌مندید و عضو ویرگول نیستید که مستقیم پی‌گیر شوید، از فید آراس‌اس استفاده کنید یا در توییتر بنده را فالو بفرمایید. اگر دستی بر قلم دارید، با همین هشتگ «چرا لاراول» در همین سایت معظم ویرگول، نیز می‌توانید شروع به نوشتن درباره‌ی خوبی‌ها و بدی‌های این فریمورک کنید تا همه استفاده نماییم. می‌توانید از جعبه‌ی کامنتی که این پایین هست، استفاده کنید و از کم و کاستی‌های این نوشته برایم بگویید،‌ یا مثلاً از آن تعریف کنید. (متأسفانه ویرگول فقط به اعضای ثبت‌نام‌کرده اجازه‌ی کامنت گذاشتن می‌دهد. تقصیر من نیست.)می‌توانید پیشنهاد کنید که به جای آرتیزان، چه کلمه‌ای در فارسی داریم که هم معنای «صنعت‌گری» و هم معنای «هنرورزی» را در خود نهفته داشته باشد.می‌توانید حدس بزنید که دستور inspire به چه دردی می‌خورد.می‌توانید پیشنهاد کنید که به جای نوشتن این چیزها، چه کارهای بهتر و مفیدتری می‌توانم در زندگی انجام دهم. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Fri, 22 Sep 2017 23:27:19 +0330 https://virgool.io/@taha/344e3-vtlyq8d32vox خوش و خرم نشسته بودم که یکی از مشتری‌ها تماس گرفت و گفت یکی از پست‌های وبلاگش را نمی‌تواند باز کند.مورد جالبی بود. برنامه همه‌ی پست‌های مشابه دیگر را باز می‌کرد، جز همین یکی! هرچه رکوردش را بررسی کردم، اختلاف سرنوشت‌سازی در کار نبود. حتی همه‌ی محتویات یک رکورد دیگر را هم در آن رکورد ریختم و باز هم باز نشد. و همه‌ی محتوای آن رکورد معیوب را در جای دیگر ریختم و باز شد!چند دقیقه‌ای طول کشید تا عامل مزاحمت را یافتم و چند دقیقه‌ی دیگر هم طول کشید تا بفهمم آخر چرا!ملاحظه بفرمایید:خودتان هم بروید و بعداً آزمایش کنید.شرح ماجرامی‌دانیم که در جداول بانک اطلاعاتی، هر رکورد یک id دارد که با آن شناخته می‌شود و اگر این شناسه را داشته باشیم، راحت می‌گردیم و رکورد مورد نظر را برمی‌داریم و استفاده می‌کنیم.این را هم می‌دانیم که نمایش id واقعی یک رکورد در آدرس‌های url فکر خوبی نیست. هر کسی با دیدن یک عدد در نشانی بالای براوزر، ممکن است به سرش بزند که آن را عوض کند و عدد دیگری را امتحان کند و این وسط، هزار اتفاق پیش‌بینی‌نشده ممکن است بیافتد. مثل این ماجرا که یک سال و نیم پیش برای بانک ملت رخ داد و باعث شد ظرف دو ساعت بعد از توییت من، سایت بانک را برای اصلاح پایین بیاورند و شب هم در تلویزیون داشتند شایعه‌ی مطرح‌شده در فضای مجازی را تکذیب می‌کردند.الان دیگر امتحانش نکنید. قضیه مال همان موقع بود و فوراً اصلاح شد.من برای دفع این خطر، از ابزار Hashids استفاده می‌کنم که پکیجی برای تقریباً همه‌ی زبان‌های برنامه‌نویسی و فریمورک‌های معروف دارد و کارش این است که هر عدد مثل ۱۲۳ را به کد عجیب و غریب و بی‌ربطی مثل doe2Ez تبدیل کند که حضورش در url بی‌خطر باشد و بازگرداندنش به مقدار اصلی، نیازی به کوئری زدن و محاسبات پیچیده نداشته باشد، و در عین حال فقط شامل ارقام نباشد و کلمه‌ی معنی‌داری در زبان انگلیسی هم ساخته نشود.پکیج Hashids در لاراول، از تنظیماتی استفاده می‌کند که می‌توانید نمک تغییر و الفبای مورد استفاده و حداقل تعداد کاراکتر را برایش تعیین کنید. من از چیزی شبیه این استفاده می‌کردم: هشدار: پیش از انتشار عکس چنین صحنه‌هایی، حتماً کمی عوضش بکنید. آدم عاقل کلید رمزش را به بقیه نشان نمی‌دهد.طبیعتاً الفبای مورد استفاده را باید طوری تعیین کنیم که برای حضور در آدرس بالای براوزر مشکلی نداشته باشند. برای مثال، در چنین رشته‌ای نباید کاراکترهایی مثل علامت سؤال یا هشتگ را داشته باشیم که ممکن است مفهوم خاصی برای نشانی داشته باشند.بیان خودِ مشکلمن پیش از کوئری زدن، محض اطمینان چک می‌کردم که اگر کد دریافتی، یک هش‌آی‌دیِ مجاز نبود، یا اصلاً از نوع رشته‌ای (string) نبود، زحمت کوئری نکشیم و همان جا بگوییم چنین صفحه‌ای نیست.و مشکل هم از همین جا شروع شد.خیالم راحت بود که پکیج Hashids هیچ وقت خروجی‌ای فقط عددی به من نمی‌دهد، اما در این مورد اتفاقی افتاده بود که شاید شانس وقوع آن یک در میلیارد هم نباشد.خروجی Hashids چیزی شبیه 344E3 بود و تابع is_numeric در php، آن را عدد تشخیص می‌داد! (به عکس بالای صفحه مراجعه کنید. هر کاری کردم نتوانستم آن را دوباره اینجا بگذارم و ویرگول بعد از انتشار، آن را برمی‌داشت و می‌انداخت دور!)اما چرا؟!در ریاضی، مفهومی به نام «نماد علمی» داریم که به بیان ویکی‌پدیا، «روشی است برای نوشتن اعدادی که خیلی بزرگ یا خیلی کوچکند و نمی‌توان به سادگی آن‌ها را در نماد ده‌دهی نوشت».خودِ ریاضی‌دان‌ها به شکل زیر از نماد علمی استفاده می‌کنند: که معنا و مفهوم آن ۳۴۴ با سه تا صفر است، یا به عبارتی، ۳۴۴،۰۰۰. اما چون امکان نوشتن چنین قالبی در ماشین‌حساب‌های علمی قدیمی وجود نداشت و همین حالا هم در خیلی از ویرایشگرها نمی‌توانیم آن را درست تایپ کنیم و همه جا هم که مثل ویرگول نمی‌شود عکسش را آپلود کرد، صورت دیگری برای نمایشش اختراع شد،‌ و آن استفاده از نماد E بود که باید حواسمان باشد با عدد نپر اشتباه گرفته نشود. 344E3به عنوان یک قاعده‌ی اساسی در زندگی، هرچقدر هم که احتمال وقوع یک اتفاق کم باشد، برای من حتماً پیش خواهد آمد. با وجود ملاحظه‌ای که Hashids کرده بود تا هیچ گاه «عدد» تحویل ندهد و مراقبتی که من کرده بودم تا عدد تحویل نگیرم، هیچ کدام حساب این جای کار را نکرده بودیم.راه حلخیلی ساده، سراغ تنظیمات Hashids رفتم و الفبا را طوری تغییر دادم که برای ساخت هش‌آی‌دیِ مورد استفاده در این جور کارها، دیگر هیچ وقت از هیچ عددی استفاده نکند. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Tue, 19 Sep 2017 04:36:28 +0430 https://virgool.io/laravel-community/why-laravel-migrations-and-seeds-wvjmnbi8zmvx مایگریشن و سیدر، اولین ویژگی‌های لاراول هستند که در این مجموعه از نوشته‌ها به آن‌ها خواهم پرداخت.لاراول، دنیایی است با ابزارهایی رنگ و وارنگ و اسم‌های جذاب، که اغلب از قبل وجود داشته‌اند و حیاتشان را مدیون لاراول نیستند، اما زیبایی در کنار هم بودنشان را چرا.در نوشته‌ی قبل، که مقدمه‌ای بود بر نوشته‌هایی از این دست، کمی از زیبایی ظاهری لاراول گفتم و عرض کردم که ادامه خواهم داد. در این نوشته، شاهدی در بخش تولید دیتابیس یک پروژه را نشان می‌دهم.مایگرشن: کوچی بلندپروازانه به همین نزدیکی‌هایک درد مشترک...کدهای برنامه‌ی خود را روی یکی از سیستم‌های کنترل ورژن مثل گیت نگه می‌داریم و خوشحالیم که اگر اتفاق ناگواری افتاد، به عقب بازمی‌گردیم و دقیقاً می‌دانیم هر تغییر چه تأثیری بر مخلوق ما داشته، اما دیتابیس ما از این قافله جداست. هشدار جدی: اگر از هیچ سیستم ورژن کنترلی برای کارتان استفاده نمی‌کنید، از یکی از سیستم‌های ورژن کنترل برای کارتان استفاده کنید.داستان از این قرار است که ما باید دیتابیس خودمان را در یک برنامه و ابزار جداگانه بسازیم و مدیریت کنیم، و هر بار که می‌خواهیم فایل‌های پروژه را به کسی بدهیم، باید یک بکاپ دستی هم از دیتابیس بگیریم و برایش بفرستیم.بهتر نبود تهیه‌ی زیرساخت‌های اطلاعاتی را هم می‌توانستیم در ویرایشگر کد خود انجام دهیم و طراحی دیتابیس هم مثل بقیه چیزها، همان جا باشد تا هم انتقالش به دیگران راحت باشد و هم تحت نظارت گیت عمل کند؟... یک راه حل لاراولی داردمایگرشن لاراول برای همین روزهاست. الگوی دیتابیس خود را در جایی معرفی می‌کنیم، ایندکس‌ها و ارتباطات آن را با زبانی شبیه زبان آدمیزاد مشخص می‌کنیم، و فایل را که یک کلاس معمولی پی اچ پی است، لابه‌لای دیگر فایل‌های پروژه قرار می‌دهیم تا هم گیت کار خود را انجام دهد و هم ما بتوانیم با یک کپی ساده، کل پروژه را در اختیار دوست و همکار یا مشتریمان قرار دهیم.نگران خط‌های اخطار زیر عبارت nullable نباشید. ویرایشگر من آن متدها را تشخیص نداده، ولی جایشان امن است.بدبختی: «حالا فایل‌ها را ساختیم. از کجا کسی را پیدا کنیم که حوصله کند و برود و این فایل‌ها را پیدا کند و یکی یکی اجرا کند تا جداول اطلاعاتی ساخته شوند؟»پاسخ: کنسول آرتیزانphp artisan migrateهمین!لاراول جدولی با عنوان migration درست می‌کند و نام و نشان هر جدولی که به این روش ساخته را در آن اضافه می‌کند و یک شماره‌ی پشته به آن می‌دهد. ما نیازی نیست کاری به کارش داشته باشیم. ولی خودش می‌داند که چه می‌کند.مثلا اگر بخواهیم کل جدول‌ها را پاک کنیم و از نو بسازیم، چنین دستوری به کنسول آرتیزان می‌دهیم:php artisan migrate:refresh و یا اگر بخواهیم فقط یکی از پشته‌ها را به عقب بازگردانیم و بی‌خیالش شویم، از این دستور آرتیزان استفاده می‌کنیم:php artisan migrate:rollbackدحتما می‌گویید بدبختی که یکی دو تا نیست. خود آن فایل را کجا بسازیم که آرتیزان محترم پیدایش کند؟php artisan make:migration create_users_table --create=usersلاراول برای همه‌ی آنچه که «بدبختی لاراولی» می‌خوانندش، راه حلی لاراولی دارد. دستور بالا، همان طور که از وجناتش پیداست، یک فایل با عنوان create_users_table می‌سازد و کلاسی را در آن قرار می‌دهد و از کلاس والد اکستند می‌کند و حتی به خاطر وجود سوییچ انتهای خط، نام جدول ما را هم در آن می‌گذارد و فقط قرار است فیلدهایمان را داخلش بنویسیم و تمام!سیدر: بذرپاشی هوشمندانه داده‌هایک بدبختی جدید لاراولی... حالا با جدول‌های خالی حاصل از این کوچ بلندپروازانه‌ی مسخره چه کنیم؟ پروژه را به دوستمان یا به مشتری بدهیم و بگوییم برای این که محصول کار کند باید بروی و دستی این تنظیمات را داخل جدول‌هایش بگذاری و حداقل یک کاربر ادمین تعریف کنی که بتواند لاگین کند و یادت نرود که رمز کاربر ادمین را باید خودت یک جوری هش کنی و در دیتابیس بریزی؟ از همان اول یک بکاپ از دیتابیس می‌گرفتیم و به او می‌دادیم راحت‌تر نبود؟... یک راه حل لاراولی داردهمان طور که عرض کردم، لاراول برای همه‌ی آنچه که «بدبختی لاراولی» می‌خوانندش، راه حلی لاراولی دارد. ابزاری به نام سیدر، مال همین روزهاست.دستور تزریق داده‌هایی که زیربنای محصول ما هستند و بدون آن‌ها کاری جلو نمی‌رود (مثل تنظیمات، یا حداقل یک حساب کاربری)، و همین طور داده‌های تصادفی برای وقتی که فقط می‌خواهیم یک نسخه‌ی آزمایشی به کسی نشان دهیم، همه در فایل‌های سیدر قرار می گیرند.نمونه‌ای از بذرپاشی به سبک سیدر لاراول، برای تزریق اطلاعاتی که محصول بدون آن‌ها کار نمی‌کند.بدبختی‌ها را دریابیم...«این فایل‌های سیدر را از کجا بیابیم و یکی یکی اجرا کنیم؟»پاسخ: شما نگران این چیزها نباشید. کنسول آرتیزان زحمتش را می‌کشد: طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Fri, 15 Sep 2017 08:43:52 +0430 https://virgool.io/laravel-community/why-laravel-p42nsd0rw57z دغدغه‌ی هر برنامه‌نویسی که می‌خواهد برنامه‌نویس خوبی باشد، از همان لحظه‌ی آغاز هر پروژه، قابلیت توسعه‌پذیری آن است. تکلیف برنامه‌نویس‌هایی که تصمیمی برای خوب بودن ندارند، مشخص است. می‌سازند و پولش را می‌گیرند و می‌زنند بر بدن. و اگر فردای روزگار، کارفرمای بینوا ویژگی جدیدی برای محصولی که سفارش داده بخواهد، بالاخره یک جوری وصله پینه می‌کنند و می‌سازند و پولش را می‌گیرند و می‌زنند بر بدن.اخطار: این یک پست عمومی نیست و برای توسعه‌دهندگان وب نوشته شده و بر خلاف پست قبلی، هیچ چیز جالبی در انتهایش ندارد.من همیشه از شغل‌هایی که داشتم لذت برده‌ام و هر زمان که حس کردم حال مطلوب را نمی‌برم آن طور که باید و شاید نمی‌برم، به تدبیری، جریان کاریَم را عوض کرده‌ام. (این سبک زندگی را به شما پیشنهاد نمی‌کنم. نه مصلحتی در کار است و نه ثباتی و نه منفعتی. تنها لذت است و یک حس خوب از عمری که به پای کارمان می‌ریزیم.)بگذریم.لذت از کار برنامه‌نویسی، منوط به زیبا نوشتن و دوراندیش بودن است. هیچ دوست ندارم برای توسعه‌ی کاری که قبلاً انجام داده‌ام، با کدهای زشت خودم دست به گریبان شوم.فریمورک عجیب و غریب لاراول را از همین رو پسندیدم و به آن روی آوردم. نمی‌گویم لاراول تنها راه رسیدن به هدفی است که گفتم، اما لاراول کدهای زیبا را دوست دارد و زیباترین ابزارها را برای آفریدن محصولی با زیربنای زیبا، مهیا کرده است.شعار لاراول: از کد زیبا خوشتان می‌آید؟ ما هم همین طور.این فریمورک، به تمام جزئیات توجه دارد و برای هر چیز راه حلی در آستینش هست. به قول دوستم پیمان، برای هر کاری که می‌توان با دو خط کد نوشتن انجام داد، لاراول راه حلی یک خطی تدارک دیده است. لاراول، دنیایی است با ابزارهایی رنگ و وارنگ و اسم‌های جذاب، که اغلب از قبل وجود داشته‌اند و حیاتشان را مدیون لاراول نیستند، اما زیبایی در کنار هم بودنشان را چرا.در روزهای بعدی، هر زمان وقت و حوصله داشته باشم، یکی از این جذابیت‌هایی را که عرض می‌کنم، برایتان می‌گویم. فعلاً به این صحنه توجه بفرمایید.نمایی از فایل تنظیمات پروژهآنچه می‌بینید، نمایی از صفحه‌ی تنظیمات پروژه است. آنچه احتمالاً متوجه شده‌اید، کامنت‌هایی است که روی هر کدام از تنظیمات نوشته شده و البته چندان عجیب و غریب نیست. اما آنچه که بعید می‌دانم به آن دقت کرده باشید، آن است که در تمام فریمورک، هر کجا که کامنتی وجود دارد، مثل همین تصویر، دارای عنوانی است که بین دو خط محصور شده و بعد توضیحی سه خطی، که طول هر خط سه کاراکتر از خط پایینی بیشتر است.خودتان حدس بزنید کسی که چنین جزئیات شاعرانه‌ای را در کامنت‌های کم‌اهمیت رعایت کرده، در جاهای مهم‌تر چه وسواسی داشته است.با اندکی اغراق (دقت بفرمایید که فقط اندکی)، اگر هنگام کار با لاراول به خود آمدید و متوجه شدید که دارید بستری را می‌سازید، یک جای راه را اشتباه رفته‌اید. آن بستر را یا لاراول خودش ساخته و شما خبر ندارید، یا یک نفر در اکوسیستم بزرگ و بی‌کرانش پکیج بی‌دردسری برایش نوشته و باید پیدایش کنید. از همه جالب‌تر آن که لاراول، حاصل کار گروهی از برنامه‌نویسان باتجربه نیست. آقایی که در تصویر زیر می‌بینید، به تنهایی آن را خلق نموده و چنین اکوسیستم بزرگی را به دور خود جمع کرده است.تیلور اوتول، خالق تنهای لاراولبه تدریج در نوشته‌های بعدی، از ویژگی‌هایی خواهم نوشت که مرا مجذوب لاراول کرده‌اند و کم‌کم تجربه‌ها و اشتباه‌ها و ناکامی‌هایم را هم با شما در میان می‌گذارم. این نوشته‌ها قرار نیست مطالبی آموزشی باشند و یک عالمه نکات معرکه‌ی بی عیب و نقص به کسی یاد بدهند. یادتان نرود که نگارنده، یک مبتدی جاودانه است.اگر به ادامه‌ی این نوشته‌ها علاقه‌مندید و عضو ویرگول نیستید، که مستقیم پی‌گیرشان شوید، از فید آراس‌اس استفاده کنید یا در توییتر بنده را فالو بفرمایید. امیدوارم ویرگول اشتراک ایمیلی مطالب یک وبلاگ را نیز در امکاناتش بگنجاند.فهرست تدریجی نوشته‌های «چرا لاراول»لینک هر نوشته‌ای از این دست را که منتشر کنم، اینجا اضافه می‌کنم. مایگریشن و سیدر: شاهدهایی از نوع دیتابیسآرتیزان: یک دستیار معرکه، از نوع کنسول خط فرمانشاهدی به نام صفحه‌بندیهمه‌ی نوشته‌ها هشتگ «چرا لاراول» خواهند داشت که قاعدتاً می‌توانید آن را نیز دنبال کنید. شاید دیگران هم حرف‌هایی برای زدن داشته باشند. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Mon, 11 Sep 2017 15:09:54 +0430 https://virgool.io/laravel-community/larave5-5-and-a-happy-developer-ozztvjq6xbqx نسخه‌ی ۵/۵ فریم ورک عجیب و غریب لاراول این هفته منتشر شد. مژده: اگر برنامه‌نویسی و صحبت درباره‌ی آن حالتان را به هم می‌زند، پیش از بستن این صفحه سری به پایین نوشته‌ام بزنید. چیز جالبی هست که از دیدنش ضرر نمی‌کنید.طبیعتاً جرأت نکردم آن را روی سایت‌های در حال اجرا آزمایش کنم و به آزمایش روی پروژه‌ی جدیدی که مشغول پیکربندی‌اش بودم اکتفا کردم.دو اتفاق جالب افتاد.یک: مراقب پکیج‌های پابلیش‌شده نباشید!قاعدتاً آپدیت فریم ورک و وابستگانش باید هر کاری می‌خواهند بکنند در پوشه‌ی vendor پروژه بکنند و کاری به کار فایل‌های ما نداشته باشند.اما بعد از آپدیت متوجه شدم تنظیمات مربوط به رمزنگاری یکی از پکیج‌هایی که استفاده می‌کردم (این)، نیست که نیست. به کمک گیت، فرآیند را برگرداندم و دیدم که خط‌های مورد نظر بوده‌اند و حالا نیستند.فوراً به همه‌ی دوست و آشنا پیام دادم که مراقب باشند و وقتی آخرین نفر هم هشدار مرا دید و با تعجب تشکر کرد، متوجه شدم که اساساً آن تنظیمات را پابلیش نکرده بودم!همان قدر که آپدیت‌ها نباید چیزی را به جز پوشه‌ی vendor تغییر می‌دادند، من هم قرار نبود به آن بخش بروم و چیزی بنویسم و با حواس‌پرتی، تنظیماتم را مستقیماً در فایل منبع پکیج گذاشته بودم.قرار گذاشتیم!بدبختی اصلی اینجا بود که مجبور شدم برای تک‌تک گیرندگان پیام هشدار، توضیح دهم که مراقب نباشند و آن‌ها هم می‌خواستند بدانند چرا!دو: اشتباه‌هایتان را (گاهی) اصلاح نکنید!در تجهیزات ساخت کوئری در لاراول،‌ یا همان کلاس مدل که همه‌ی مدل‌های ما بچه‌های او هستند، متغیری منطقی وجود دارد به نام exists. به این صورت:DB::table('filans')->find(123)->existsقبلاً تصور می‌کردم اگر مدل مورد نظر پیدا شده باشد، مقدار این «درست» است و وگرنه «غلط». اما اشتباه فکر می‌کردم. این متغیر، مدل‌های داخل زباله‌دان (soft-deleted)ها را هم تشخیص می‌داد. این اشتباه که دیر هم متوجهش شدم، باعث شده بود بخش‌هایی از کد مطمئن نباشند و برای اصلاحشان هم امروز و فردا می‌کردم.به هر حال دیگر مهم نیست که قبلاً چطور بود و چه می‌شد. گذشته‌ها گذشته.مهم این است که توسعه‌دهنده‌ی لاراول، از نسخه‌ی ۵/۵ به بعد همان طور به این متغیر نگاه می‌کند که من نگاه می‌کردم. حالا دیگر حتی اگر چیزی داخل سطل آشغال هم پیدا کرد، «موجود» شمرده می‌شود و این عالی است. دیگر لازم نیست دستی به کدهای قبلی بزنم.متغیر منطقی exists، حالا خیلی منطقی‌تر از قبل شده است.چیز جالبو اما چیز جالبی که آن بالا مژده‌اش را داده بودم.زحمت بکشید و سری به سایت sagmeisterwalsh.com بزنید و از طراحی جالب آن لذت ببرید.طراح این سایت، دو تا از دوربین‌های داخل سالن شرکت را انتخاب کرده و فیلم آن را به صورت پخش زنده، در پس‌زمینه‌ی سایت گذاشته است. اگر حوالی عصر (به وقت ایران) سایت را باز کنید، شاهد تشریف‌فرمایی صبحگاهی کارمندان خواهید بود و در خلال روز کاری (عصر و شب ما) می‌توانید تماشایشان کنید.نمای زنده‌ی محیط کار یک شرکت، به مثابه‌ی پس‌زمینه‌ی سایت اطلاع‌رسانی همان شرکتنکته جالب‌تر: لینک‌هایی که داخل صفحه می‌بینید، مثلاً در قاب پنجره، واقعی هستند و می‌توانید رویشان کلیک کنید. از آنجا که با کاهش کیفیت فیلم، کیفیت آن‌ها هم کم می‌شود و با تغییر نور روز و شب، درخشش آن‌ها نیز تغییر می‌کند، حدس می‌زنم که دکمه‌ها واقعاً در محل حضور فیزیکی دارند. اگر از من می‌پرسید، این معرکه است.نکته باز هم جالب‌تر: پس‌زمینه‌ی این سایت، به شکل اسلایدشو درست شده و اگر روی کامپیوتر بازش کنید، می‌توانید نمایی دیگر از محیط کار این بزرگواران را هم تماشا کنید. (روی گوشی‌های اندرویدی و اپلی که دم دست من بود، این امکان وجود نداشت.)منوهایی که در تصویر می‌بینید واقعی هستند. ظاهراً حتی حضور فیزیکی در محل دارند.نکته بیشتر جالب‌تر: اسلایدشوی سوم را از دست ندهید. دوستان ما در حیاط محل کارشان میزبان حیوانی هستند که یک ظرف آب هم برایش گذاشته‌اند. می‌توانید زندگی او را هم به صورت پخش مستقیم تماشا کنید.اسلاید سومنکته نهایی:حریم خصوصی چیز خوبی است و خوب‌تر آن است که مراقب این چیز خوب، هم در زندگی خودمان و هم در زندگی دیگران باشیم. اما به زعم این حقیر، آنچه در سایتی که معرفی کردم می‌بینیم، حریمی را نقض نکرده. محیط کار، و مانیتورهای کاری در محیط کار، حریم خصوصی هیچ کس محسوب نمی‌شوند و مادامی که کارمندان از وجود آن دوربین‌ها مطلع باشند، قطعاً مراقب هستند که دست داخل دماغشان نکنند.هرچند بررسی اول ساعت کاری من نشان داد که خیلی هم دغدغه‌ی پنهان کردن این چیزها را ندارند و برایشان مهم نیست. طاها: همان مبتدی جاودانه طاها: همان مبتدی جاودانه Tue, 05 Sep 2017 19:06:53 +0430