با توجه به این که یک برنامه نویس حرفه یی بیش از ۱۰ الی ۱۵ ساعت در روز کدنویسی می کند، به نظر می‌رسد که تم های تیره رنگ نه تنها چشم آن‌ها را کمتر اذیت می کنند، بلکه مغز ایشان را نیز دیرتر خسته می‌کند. شاید پس از تغییر تم ویرایشگر کد از روشن به تیره، در چند روز اول کمی سردرگم و گیج شویم، اما پس از عادت کردن به تم تیره رنگ، سوئیچ کردن به تیم روشن دیگر غیر ممکن خواهد بود (امتحان آن ضرری ندارد!)

آنچه مسلم است این که اگر هم علاقمند به استفاده از بک گراندهای تیره هستید، هرگز نباید از بک گراندهای سیاه خالص (000#) با رنگ فونت سفید خالص (fff#) استفاده کنید چرا که بسیار آزار‌دهنده است زیرا در چنین تنظیماتی، کنتراست بسیار بالا است. رنگ تیره ی بک گراند باید خیلی آزار‌دهنده نباشد و شاید یکی از دلایلی که نرم افزارهایی همچون ویژوال استودیو، اندروید استودیو، فتوشاپ و … به جای رنگ تیره ی خالص، از نوعی خاکستری استفاده می‌کنند همین باشد.

http://bit.ly/1WgDQIT

#Ubuntu in our hearts

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

http://bit.ly/1OQ2KXU

شش ماه است که از سیستم کانتیتر استفاده می کنم. تاحالا ۵۱ سرویس که الان هم فعال هستند، روی کانتینترهای داکر تعریف کردم. اینجا تجربه استفاده را با شما به اشتراک می گذرام. به طور کلی مزایا و معایبی که در عمل با آنها مواجه بودم را برای شما می نویسم.

#داکر به عنوان یک سکوی تولید، نگهداری، به اشتراک گذاری و اجرای میکروسرویس ها در اواخر سال ۲۰۱۳ مورد توجه من قرار گرفت. در شرکتی که هم اکنون مسیولیت آن را به عهده دارم تعداد زیادی سرویس بر روی داکر ایجاد کردیم که شامل موتور جست و جو، پایگاه داده رابطه ای و NoSQL و همچنین وب سرویسها و بک اندهای json است. چند عدد سرویس ایمیل و مقابله با اسپم هم داریم.

ادامه متن در اینجا 👈 http://bit.ly/20I2lNs

در این مصاحبه که در تابستان 2014 ضبط شده و در ابتدای سال 2015 منتشر شده است چارلز اندرسون با جیمز ترنبل ، در مورد #Docker صحبت می‌کند. Docker ابزاری است که با وجود عمر کوتاه خود، خصوصاً در محیط‌های استقرار مستمر و در معماری‌های مبتنی بر ریزسرویس‌ها، توجه زیادی به خود جلب کرده است. جیمز ترنبل یک نویسنده مستقل نرم‌افزار‌های متن‌باز، متخصص امنیت و توسعه‌دهنده نرم‌افزار است. او هم‌اکنون، نایب‌رییس شرکت Docker است. او نقش‌های مشابهی در PuppetLabs و Venmo داشته است. او کتاب‌هایی در مورد Docker ، Puppet ، Logstash ، مدیریت سیستم‌های لینوکس و امنیت نوشته است.

ادامه متن در اینجا 👈 http://bit.ly/1TDlA6N

ثبت نام Coder Conf آغاز شد.

http://coderconf.org

@irphp #events

🌀 بقیه‌اش به من مربوط نیست!

از سخت‌ترین آدم‌هایی که می‌شود با آنها کار کرد کسانی هستند که می‌گن من کار خودم رو انجام دادم و باقی‌اش به من مربوط نیست!

احتمالا بین همکارانمون یا در اداره‌ها نمونه این افراد را دیده‌ایم یا کارمان پیششان گیر کرده.

این افراد عقیده دارند که مگر چقدر پول می‌گیرم که بخوام کار دیگه‌ای انجام بدم؟

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

همین افراد هم معمولا منتقدین بزرگ سیستم‌های کاری هستند و به همه چیز ایراد می‌گیرند.

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

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

اگر کسی به کارش علاقه داشته باشد برای آن مرز و محدوده قائل نیست.

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

#امیرمهرانی
@thecoach_ir

10 PHP functions and code snippets to work with dates http://www.catswhocode.com/blog/10-php-functions-and-code-snippets-to-work-with-dates

آشنایی با قوانین پنج گانه ی SOLID

اصول #SOLID دربرگیرنده ی اصولی در برنامه نویسی شیء گرایی است که در اوایل سال 2000 توسط مهندسی به نام Robert Martin که تحت عنوان Uncle Bob یا «عمو باب» شناخته می‌شود ابداع شد. وقتی این اصول به درستی در کنار یکدیگر به کار گرفته شوند، این امکان را به برنامه نویس یا توسعه‌دهنده می‌دهند تا با سهولت بیشتری به توسعه ی نرم افزارهای خود بپردازد. علاوه بر این، به کارگیری اصول SOLID این امکان را به برنامه نویسان خواهد داد تا با رویکردی چابک به توسعه ی نرم افزارهای خود پرداخته، از مرتکب شدن اشتباهات کوچک جلوگیری کنند و در صورت نیاز هم به سادگی اقدام به بازنویسی کدهای خود کنند.
http://bit.ly/28WJ3is

آموزش اصول برنامه نویسی

در این دوره ی آموزشی، با تاریخچه ی برنامه نویسی، تفاوت زبان های برنامه نویسی مختلف و همچنین اصول برنامه نویسی آشنا خواهیم شد. این دوره مناسب برای کاربرانی است که تازه قصد ورود به دنیای برنامه نویسی را دارند.
مقالات بسیار خوبی در این دوره وجود دارد که توصیه می‌شود حتی حرفه ای ها هم حتما نگاهی به آنها بیاندازند.
http://bit.ly/296bAWZ

مقالات مفید فارسی برای برنامه‌نویسان اندروید

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

http://www.kamalan.com/blog/

نود و هفت چیزی که هر برنامه نویسی باید بداند: بدهی فنی

پیش می‌آید که می بایست مابین «انجام اصولی یک پروژه» و «انجام سریع یک پروژه» یکی را انتخاب کنیم و در ابتدای کار سرعت بخشیدن به فرایند طراحی یک پروژه جذاب‌تر به نظر می‌رسد با این استدلال که بعداً هم می‌شود مجدد به کدها سر زد و اگر مشکلی داشت آن ها را از بین برد! اما تجربه نشان داده است زمانی که در بر گیرنده واژه ی بعداً است، خود حاوی بسیاری باگ ها و مشکلات خواهد بود که برنامه نویس مجبور است بیشتر تمرکز خود را روی آن‌ها بگذارد و از توجه به مشکلات -هرچند جزئی- گذشته باز می ماند.

چنین سیاستی در برنامه نویسی اصطلاحاً Technical Debt گفته می‌شود که به صورت تحت الفظی می‌توان آن را به «بدهی فنی» ترجمه کرد این بدهی فنی اصلاً چیز خوبی نیست و گاهی اوقات منجر به بوجود آمدن فجایعی در تولید نرم افزار می شود. برای روشن شدن این مسأله مثالی می زنیم. بدهی فنی همچون وام گرفتن است که در کوتاه مدت کار ما را راه می‌اندازد اما غافل از این که در آینده می بایست با بهره ای که روی آن می‌آید -مثلا 30 درصد بیشتر- قرض خود را پرداخت کنیم.

در برنامه نویسی هم قضیه دقیقاً به همین صورت است. اگرچه گاهی اوقات می‌توان از راه کارهایی استفاده کرد که به کدنویسی ما سرعت بخشند اما این در حالی است که در آینده اضافه کردن ویژگی‌های جدیدی به پروژه را دشوار می‌سازد و به اصطلاح نمی‌توان به سادگی کدهای خود را Refactor کرد. جالب اینجا است که هرچه از زمان ایجاد این دست مشکلات بیشتر می گذرد، یافتن راه‌کار هم برای آن‌ها دشوارتر خواهد شد. اما اگر ما از زمان بندی پروژه عقب باشیم و مجبور باشیم سرعت عمل را بر کیفیت ترجیح دهیم چطور؟ توصیه ما این است که هرگز سیاست فدا کردن کیفیت کار به خاطر سرعت بخشیدن به آن را دنبال نکنید اما اگر واقعاً مجبور هستید، پس این کار را انجام دهید اما حتماً به خاطر داشته باشید که شما با این کار یک بدهی فنی برای خود ایجاد کرده‌اید که می بایست در اولین فرصت این بدهی خود را صاف کنید. برای این منظور هم، حتماً در مستندات پروژه این قضیه را ذکر کنید تا فراموش نشود که در غیر این صورت ممکن است مجبور شوید بهای گزافی بابت آن پرداخت کنید.

📌 منبع: https://goo.gl/0GSHll