روز هفتم – چالش ۱۰۰ روز کد زدن

درود بر شما عزیزان،

روز هفتم رو با یادگیری مفهوم Hook در کتابخانه React گذروندم. همانطور که در مطلب روز دوم چالش هم اشاره کردم ری اکت از نسخه ۱۶.۸ به بعد برنامه نویسی فانکشنال و قابلیت جدیدی به نام Hook رو اضافه کرد. این یعنی از نسخه مذکور به بعد می تونیم به جای استفاده از کلاس برای ایجاد کامپوننت، از توابع استفاده کنیم و در نتیجه به گفته توسعه دهنده های فیسبوک در این ویدیو ۹۰٪ کد تمیزتر و سبک تری داشته باشیم.

داکیومنت توضیحات Hook بسیار واضح و شفاف توضیح داده اما برای برخی از مسائل تکمیلی سری به وبسایت usehook زدم. داخل این وبسایت با مثال های کاربردی به طور کامل پیاده سازی هوک ها در پروژه رو به تصویر کشیده. یک کتابخونه تکمیلی هم برای پیاده سازی هوک های سفارشی سازی شده روی گیت هاب به این آدرس منتشر شده که می تونید برای پروژه هاتون ازش استفاده کنین.

تا درودی دیگر، بدرود.

نوشته روز هفتم – چالش ۱۰۰ روز کد زدن اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

آموزش ساخت سایت استاتیک به کمک فریمورک Hexo

سلام برای نوشتن مستندات یه کتابخونه نیاز بود تا یه وبلاگ ایجاد کنم، برای همین تصمیم گرفتم روش کار رو که با فریمورک hexo انجام میشه براتون بصورت فیلم آموزشی ضبط کنم.

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

توی این ویدئوی ۳۰ دقیقه ای با هم دیگه سیستممون رو کانفیگ میکنیم تا هگزو رو نصب کنیم چندتا مطلب تست میفرستیم رو وبلاگمون و در آخر وبلاگمون رو روی سایت گیتهاب منتشر میکنیم. بدون اینکه نیاز به تهیه هاست و دامنه باشه.

راستی من تو ویدئو فراموش کردم که بگم شما میتونید پوشه Public که شامل فایل های html و… هستش رو هرجا که دوست دارید اپلود کنید و استفاده کنید. محدودیتی نداره میتونید روی هاست شخصی بزارید یا روی گیتلب و…

خوشحال میشم نظراتتون رو بشنوم

https://www.aparat.com/v/Yfa84

نوشته آموزش ساخت سایت استاتیک به کمک فریمورک Hexo اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

بدهی فنی چیست و چطور باید آن را مدیریت کرد؟

در دنیای ایده‌آل من، همه پروژه‌ها همیشه به موقع تمام می‌شوند و هیچ وقت خرجشان از بودجه تخمینی بیشتر نمی‌شود. تازه با همان بودجه، تیم‌ها نه تنها می‌توانند Featureهای اضافه بسازند، که می‌توانند قبل از بیرون دادن نسخه نهایی همه چیز را چندین بار هم تست کنند. اما حیف، دنیای واقعی این‌قدرها هم دلنشین نیست؛ بلکه در فرآیند توسعه نرم‌افزار، با هر قدمی که می‌گذاریم مشکلات جدیدی از چپ و راست جلوی پایمان سبز می‌شوند. یکی از رایج‌ترین و همه‌گیرترین این مشکل‌ها، بدهی فنی (Technical Debt) است.

بدهی فنی چیست؟

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

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

اما همانطور که با وام گرفتن می‌شود سریع‌تر به اهداف بزرگ زندگی رسید، بدهی‌های فنی هم الزاماً بد نیستند. اگر آنها را درست مدیریت کنید، مزایای بی‌نظیری برای شرکت‌تان خواهند داشت؛ بخصوص اگر از آن شرکت‌هایی باشید که رشد سریع دارند. در چنین شرکتی باید محصولات را سریع و زودبه‌زود ارائه کنید تا بتوانید تناسب محصول/بازار را پیدا کرده، نیازهای مشتری را برآورده کنید، و از فرصت‌هایی که سر راهتان پیش می‌آید بهره ببرید. با مدیریت بدهی فنی، تضمین خواهید کرد که حرص دویدن، در بلندمدت زمینتان نخواهد زد.

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

دگ لیودن (Dag Liodden)، کوفاندر و CTO شرکت فناوری تبلیغاتی تپ‌اد (Tapad) بیشتر از ۱۴ سال است که دارد با بدهی فنی سر و کله می‌زند؛ در ادامه نگاهی می‌اندازیم به سه نوع اصلی بدهی فنی که توسعه‌دهندگان بیشتر از همه با آن‌ها سروکار دارند و استراتژی‌هایی که دگ لیودن برای روبه‌رو شدن با هر کدام پیشنهاد می‌کند را مرور می‌کنیم:

۱. بدهی فنی عامدانه

بدهی فنی و عواقب آن

مهندس‌ها معمولا خودشان می‌دانند که کدام راه، راه درست انجام کار است و کدام راه، راه سریع آن. خیلی وقت‌ها، راه سریع همان کار درست است (برای جلوگیری از Over-engineering)، اما بعضی وقت‌ها هم اعضای تیم عمداً کار «اشتباه» را انجام می‌دهند، چرا که باید محصول را به سرعت به بازار برسانند.

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

راه حل: شاید بگویید که این کار خیلی با فرهنگ چابک (Agile) تیم شما سازگار نیست! اما ایده خوبی است که وقت ایجاد این نوع از بدهی فنی، کارهایی که انجام نداده‌اید را در بک‌لاگ محصول (Backlog) یادداشت کنید. اگر این کارهای ناتمام به طور مشخص ثبت نشوند، بعید است که بدهی فنی در آینده پرداخت شود. بدون پرداخت بدهی‌ها، در گذر زمان بدهی فنی عامدانه تبدیل به بدهی ناشی از طراحی اتفاقی خواهد شد. مسئولیت به وجود آمدن این نوع بدهی‌ها بر عهده مالک محصول‌ (Product Owner) و ذی‌نفعان است؛ زیرا به خاطر تصمیمات تجاری است که به وجود می‌آیند.

۲. بدهی فنی ناشی از طراحی تاریخ‌گذشته یا اتفاقی

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

راه حل: اینکه چطور Refactor مفصلی بکنیم خودش چندین پست جدا می‌طلبد، اما نیاز به انجام آن یک چیز طبیعی است. هرچند وقت یک بار، مثلا هر دو سال یک بار یا هر وقت که سیستم در وضعیت باثباتی بود، لازم است که چنین کاری انجام شود. اگر نشود، آنوقت ممکن است Over-engineering کنید و باعث شوید سیستم به شکل غیر ضروری‌ای مرتباً کند باشد. رهبران تیم و مالک محصول‌ها باید اطمینان حاصل کنند که برای بازپرداخت این نوع بدهی در آینده زمان کنار می‌گذارند؛ چرا که علت به وجود آمدن آن، تصمیمات مربوط به طراحی سیستم و تغییر مداوم نیازهای سیستم است.

۳. بدهی فنی ناشی از فرسودگی نرم‌افزاری

فرسودگی سیستم و بدهی فنی متعاقب آن

بدهی فنی ناشی از فرسودگی نرم‌افزاری (Bit rot)، به مرور زمان به وجود می‌آید. تغییراتی که به تدریج در یک Component یا یک سیستم ایجاد می‌کنیم، باعث می‌شوند که کم‌کم سیستم پیچیدگی‌های غیرضروری‌ای پیدا کند. این پیچیدگی بخصوص زمانی تشدید می‌شود که چندین نفر بدون اینکه طراحی اولیه سیستم را درست فهمیده باشند، روی آن کار کنند. از جمله علایم چنین حالتی، برنامه‌نویسی کپی‌پیستی (یا به عبارتیCargo Cult Programming) است.

راه حل: این تنها نوع از بدهی‌های فنی است که باید با Refactor مداوم کدها، به کلی از آن اجتناب کرد. تیم‌هایی که قوی هستند، برای فهم طراحی سیستمی که رویش کار می‌کنند، وقت کافی می‌گذارند؛ حتی اگر طراحی اولیه آن کار خودشان نبوده باشد. آنها به مرور طراحی را بهبود می‌بخشند و در طول مسیر، کدهای بد را تمیز می‌کنند. مسئولیت جلوگیری از به وجود آمدن این نوع بدهی با تیم توسعه نرم‌افزار است، زیرا این تک‌به‌تک اعضای توسعه‌دهنده هستند که آن را به وجود می‌آورند.

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

ترجمه و اقتباس از:

کوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های کوئرامگ، می‌توانید اکانت توئیتر یا کانال تلگرام ما را دنبال کنید.

نوشته بدهی فنی چیست و چطور باید آن را مدیریت کرد؟ اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

توسعه دهنده های نرم افزار اندروید، بیاید یکم هاردمون رو خالی کنیم

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

در هر پروژه اندرویدی که با اندروید استودیو میسازیم چند دایرکتوری زائد داریم که بیلدسیستم آن ها را ایجاد میکند. این دایرکتوری ها عبارتند از:

۱- دایرکتوری gradle. که در روت دایرکتوری پروژه قرار گرفته است. ( با دایرکتوری gradle آن را اشتباه نگیرید)

۲- دایرکتوری build که داخل دایرکتوری app هست.

با حذف این دو دایرکتوری حجم یک پروژه ممکن است از حدود ۴۰ مگابایت به زیر ۱ مگابایت برسد.

اگر ۴۰ پروژه داشته باشیم، چیزی حدود ۱٫۶ گیگابایت فضا اشغال شده است. که میتوان با حذف دایرکتوری های زائد آن را به حدود ۴۰ مگابایت کاهش داد.

با هر بار build کردن پروژه، این دایرکتوری ها دوباره ایجاد می شوند.

قاعدتا برای ما حرام است که به صورت دستی وارد همه دایرکتوری ها بشویم و دایرکتوری های زائد را حذف کنیم.

پس یک بش اسکریپت می نویسیم که این کار را برایمان انجام دهد.


نوشتن اسکریپت

https://gist.github.com/oh-my-saeed/9d621d9dcd769d7344780279d3442a86

در این اسکریپت روی تمام دایرکتوری های موجود در دایرکتوری پروژه های اندرویدمان یک حلقه میزنیم و دایرکتوری های gradle. و build را در صورت وجود حذف میکنیم.

این اسکریپت خیلی خیلی ساده است. اما با این حال l اگر می خواهید از آن استفاده کنید ابتدا روی یک پروژه تست کنید تا مطمئن شوید مشکلی برای پروژه هایتان ایجاد نمی کند.


تصویر اجرا روی پروژه های خودم

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

گردآوری توسط ایده طلایی

مرتب سازی آرایه ها – تکنیک های برنامه نویسی

برنامه نویسی

مرتب سازی مقادیر یک آرایه در برنامه نویسی، احتمالا جزو سوالاتی است که برای هر برنامه نویسی پیش می‌آید! فارق از اینکه با چه زبانی و چه IDE یا Code Editorای کار می‌کنید، باید این رو در نظر داشته باشید که ساده نگاه کردن شما به مسئله هستش که براتون راه حل میسازه. نکته: همیشه موقع حل چنین چالیش هایی همه به دنبال این هستند که مثلا هر عدد رو با عدد بقلیش رو چک کنن! یا هر عدد رو با کل اعداد دیگه! اما این مدل راه حل ها باعث ایجاد سردرگمی میشه و بیش از پیش از جواب دور می‌شید.

توی بخش بعد ساده ترین راه ممکن توی عالم رو برای این مسئه بررسی می‌کنیم.


الگوریتم مرتب سازی مقادیر یک آرایه

  1. ابتدا کمترین و بیشترین مقدار در آرایه رو پیدا کنید.
  2. یک آرایه به طول آرایه اصلی بسازید.
  3. از کمترین مقدار به سمت بیشترین مقدار رفته و هر بار یکی به مقدار قبل اضافه کنید.
  4. در صورتی که مقدار حال حاضر در مرحله ۳ با یکی از خانه‌های آرایه اصلی برابر بود اولین خونه‌ خالی توی آرایه مرحله ۲ رو به عدد مورد نظر نسبت بده در غیر این صورت برگرد مرحله ۳
  5. آرایه دوم رو چاپ کن
  6. پایان

برای دسترسی به سورس کد نمونه به منبع مراجه کنید.

منبع: ایستگاه تکنیک در وبسایت علیرضا بازرگانی

نوشته مرتب سازی آرایه ها – تکنیک های برنامه نویسی اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

روز ششم – چالش ۱۰۰ روز کد زدن

درود بر شما عزیزان،

ششمین روز از چالش هم گذشت و در این روز با یاری خدا و با همتی مضاعف سرفصل های Advanced کتابخانه React هم تمام شد. از فردا پروژه اصلی خودم که به نوعی استارت آپ محسوب می شه رو استارت می زنم و به امید خدا تا پایان این چالش ۱۰۰ روزه به مرحله بهره برداری می رسونمش 🙂

طی سال های گذشته که به برنامه نویسی مشغولم،‌ یکی از دغدغه های دوستان و همکارانم که از نزدیک اون رو لمس کردم، خرید ابزارها و تجهیزات به روز برای برنامه نویسی است. به عنوان مثال فردی که هر روز در اینترنت جستجو می کنه تا آخرین مدل مک بوک رو خریداری کنه و باهاش کد بزنه. یا فردی که حتما باید مانیتور دوم و سوم و … داشته باشه تا موفق به تایپ یک خط کد بشه!
من ۱۰۰٪ مخالف این ایده نیستم و در اینکه ابزار مناسب هر حرفه ای می تونه سرعت رشد و بهره وری در اون حرفه رو بالا ببره شکی نیست، اما از طرفی باید در نظر داشت که آیا حد تعادل هم رعایت می شود؟ آیا در مدت زمانی که برای جستجوی فلان مدل لپ تاپ صرف شده نمی توانستیم ۱۰۰ خط بیشتر کد بزنیم؟ آیا هزینه ای که صرف خرید مانیتور دوم شده، نمی توانست خرج یک دوره آموزشی جذاب و کاربردی شود؟

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

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

نظر شما در این باره چیه؟

تا فردایی دیگر و روزی دیگر همه شما رو به خداوند بزرگ و منان می سپارم.

نوشته روز ششم – چالش ۱۰۰ روز کد زدن اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

برنامه نویسی به کمک Xamarin چطور سرعت کار را افزایش می دهد؟

شاید تا الان بارها مطالب مختلفی راجب برنامه نویسی اپلیکیشن های موبایل بوسیله زامارین رو خونده باشین و هردفعه با این کلمه مواجه شده باشین که زامارین سرعت توسعه رو زیاد میکنه! فکر کردین که چطور ممکنه سرعت کار زیاد بشه؟

بزارید با یه مثال بهتون توضیح بدم که ما چطور میتونیم با کمک زامارین برنامه هامون رو با سرعت بیشتری تولید کنیم!

فرض کنید که ما قرار هست یک لیست از اطلاعات رو به کاربر نشون بدیم برای این کار نیاز به یک Listview یا RecyclerView داریم همینطور نیاز هست که آیتم هارو شخصی سازی کنیم و طبق نیازمون اون هارو چینش بدیم.

اگر این برنامه رو با اندروید استودیو بصورت Native انجام بدیم باید این کار هارو انجام بدیم.

  • یه ویو برای RecyclerView یا Listview بسازیم
  • یه ویو دیگه برای آیتم های هر ردیف بسازیم
  • یه کلاس مدل بسازیم
  • یه کلاس آداپتور بسازیم و ردیف هارو متصل کنیم به ویو (کلی کد نویسی باید بکنیم…)
  • داخل ویو اصلی اداپتور رو مقدار دهی کنیم و…

حتی اگه بخوایم همه کدهارو کپی پیست کنیم یه ۵ تا ۱۰ دقیقه ای زمان میبره تا سرهم بشه!

حالا بزارید یه نگاه به زامارین بندازیم:

یه ListView میزاریم روی لایوت و همین لیست ویو رو براش Template تعریف میکنیم. تمام!

  
  
 
  
   
     
    
     
       
      
        
        
       
         
        
          
          
          

به همین راحتی قالب ItemTemplate رو خودمون هرطور که دوست داشته باشیم ایجاد میکنیم و با کمک Binding ها مقدار هارو متصل میکنیم به کنترل ها، برای نمایش داده ها تو لیست ویو هم کافیه داده هارو که بصورت List هستن وصلشون کنیم به ItemSource لیست ویو. در کمتر از ۳ دقیقه کامل میشه پیاده سازیش کرد (اگرم کدهارو کپی پیست کنید بیشتر از چند ثانیه نمیشه) !

دیگه نیاز نیست که آداپتور بسازیم، چندتا ویو جداگونه براش بسازیم و… حتی برای ایونت های کلیک و… هم نیازی به کدنویسی نیستش و از همون ایونت های پیشفرض میتونیم براحتی استفاده کنیم.

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

نوشته برنامه نویسی به کمک Xamarin چطور سرعت کار را افزایش می دهد؟ اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

روز پنجم – چالش ۱۰۰ روز کد زدن

درود بر شما عزیزان،

در آخرین لحظات شب درست نزدیک نیمه شب در حال آپلود پست امروز برای پنجمین روز از چالش مهیج و زیبای ۱۰۰ روز کد زدن هستم.

همچنان طبق برنامه در حال یادگیری کتابخانه React هستم و امروز موفق شدم با کمک و الهام گرفتن یکی از پروژه های موجود بر روی Codepen، همچنین مرور JavaScript و نگاهی کلی به تگ های HTML و CSS، پروژه کارت ویزیت الکترونیک رو به پایان برسونم و سورس کد اون رو برای شما عزیزان روی گیت هاب با این آدرس قرار بدم. امیدوارم بتونید در پروژه هاتون ازش استفاده کنید.

به افرادی که قصدشون شروع یادگیری و کار با کتابخانه React و فریمورک React Native هست، شدیدا توصیه می کنم از دوره JavaScript سایت موزیلا استفاده کنند. مزیت این دوره علاوه بر سادگی و روانی اون،
حذف موضوعاتی از سرفصل های جاوااسکریپت است که هرگز در برنامه نویسی React از آنها استفاده نمی شود.

تا فردایی دیگر همه شما رو به خداوند بزرگ و منان می سپارم.

نوشته روز پنجم – چالش ۱۰۰ روز کد زدن اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

دوراهی یک برنامه نویس

من یه برنامه نویسم,شش ساله دارم بین کدهام زندگی میکنم.روزا کد میزنم,شبا بهشون فکر میکنم و خوابشون رو میبینم.عاشق قهوه و چای هستم.وقتی به باگ میخورم دلم میخاد لم بدم بین کدها و سیگار بکشم و آهنگ داریوش گوش بدم!اونکه رفته دیگه هیچ وقت نمیاد…

فک میکنم کد مثل ترشی میمونه باید جا بیافته تا کار کنه.شب کار نمیکنه و صبح بلند میشی و میبینی در اوج ناباوری داره کار میکنه.

تصور اطرافیانم از من یک دختر باهوش با یک شغل شیک و باکلاس!لم دادم پای کامپیوترم و با زدن چند تا دکمه فورا یک سایت رو بالا میارم و به پول کلانی میرسم!دقیقا به همین راحتی…

نزدیکانم اما منو یک موجود عجیب می بینن که قادره ساعت ها و حتی تمام طول روز بدون پلک زدن ,حرف زدن و یا حتی بدون اینکه بشنوه و یا چیزی بخوره زل بزنه به صفحه ی سیاه مانیتورش…

کارفرمام اما منو یک ماشین میبینه بدون هیچ گونه احساس و یا حس خستگی…

درون گرایی و غیر اجتماعی بودن توی اکثر برنامه نویسا وجود داره!که همین دو مورد به مرور باعث کاهش اعتماد بنفس اونا میشه.یه جورایی رفتن به سمت یک پدیده ی روانی دیگه به اسم سندروم است که اکثر برنامه نویسا به اون دچار هستند.بر خلاف اینکه من تمام تلاش خودم رو در ارتباط با یک پروژه انجام دادم و شواهد نشون میده که من موفق بودم ولی همچنان احساس میکنم لیاقت این موفقیت رو ندارم!

من یک برنامه نویسم پرم از حس خستگی ذهنی و بی انگیزگی در مواجهه هر روزم با روش های جدید,تکنولوژی جدید,فریمورک جدید و …

من یک برنامه برنامه نویسم مثل همه تفریح رو دوست دارم اما تفریح من پر از استرسه و برام شادی آور نیست!

من یک برنامه نویسم پرم از ترس قضاوت از فیدبک های مختلف کارفرما

من یک برنامه نویسم ,پرم از حس سرزنش و نقد دائمی,پرم از حس مقایسه بین خروجی من و خروجی سایرین …

عاشق شغلم هستم و پرم از حس تردید بین ادامه دادن یا ندادن…

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

گردآوری توسط ایده طلایی

باگ اندروید استدیو ۳.۴.۱

چند روز پیش که با اندروید استدیو کار میکردم با این صحنه روبرو شدم😐🤦🏻‍♂ فک کردم که مشکل از کشه و باید پاک بشه، بعد از پاک کردن کش دوباره بازم همین مشکل بود🤦🏻‍♂ همه لایه ها باز میشن ولی به جز اون لایه ای که تازه طراحی کرده بودم😐

بعد که کمی دقت کردم، از کتابخونه متریال گوگل استفاده کرده بودم، نسخه های آلفای این کتابخونه با اندروید استدیو ۳.۴.۱ مشکل دارن و اگه در لایه خودتون از material button استفاده کنید، با این مشکل مواجه میشید.😤

ورژن کتابخونه:

۱٫۱٫۰-alpha06

خب حالا میرسیم به راه حل:

ازونجا که ورژن آلفای این کتابخونه امکانات زیادی داره و بهش نیاز دارم باید برم و اندروید استودیو ۳.۵ از چنل بتا دانلود کنم، مشکل در این نسخه حل شده😍

راه‌حل دوم اینه که ورژن کتابخونه رو دانگرید کنید به

۱٫۰٫۰

که اصلا پیشنهاد نمیکنم😐

جهت مطالعه بیشتر:

https://stackoverflow.com/questions/55791884/cannot-render-materialbutton-with-android-material1-1-x

نوشته باگ اندروید استدیو ۳.۴.۱ اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی