چه چیزهایی یاد بگیریم: انتخاب پلتفرم (Platform)

حتما اینجا و اینجا را مطالعه کنید.

StockfreshDecisions

موضوع پر مناقشه و مورد علاقه من همیشه همین بوده! درگیری های زیادی با دوستان داشتیم که ویندوز بهتر است یا لینوکس، مک ارزش سرمایه گذاری دارد یا ویندوز. مدت ها درگیر این موضوع بودیم که قدم گذاشتن در چه راهی برای ما بیشترین سود را خواهد داشت. با این که بررسی کردن موضوعاتی که در آنها شک داریم کاری کاملا منطقی و عقلانی است، ولی همیشه در نظر داشته باشید که خود همین بررسی و تصمیم گرفتن ممکن است به ضرر شما تمام شود. همین دو دلی باعث می شود که به هیچ موضوع و پلتفرمی مسلط نشوید حتی بعد از مدت ها کار کردن در بخش های مختلف.

کلا تصمیم جدی نگرفتن در این موضوع باعث می شود که شما بعد از مدتی همه کاره و هیچ کاره بشوید.

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

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

در هر زمینه ای تلاش و جدیت به خرج دهید حتما موفق خواهید شد

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

همیشه اولویت اصلی را علایق خود بگذارید

در دنیای برنامه نویسی دو دسته طرز فکر در مورد پلتفرم خاصی می تواند وجود داشته باشد.

  • طرز فکر طرفداری (fan)
  • طرز فکر اقتصادی

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

مشورت فراموش نشود

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

و همیشه در نظر داشته باشید که در نهایت هیچ تفاوتی نخواهد کرد که شما لینوکس کار هستید، یا ویندوز کار، یا مک و هر چیز دیگری… مهم تاثیرگذاری شما است و بس.

چه چیزهایی یاد بگیریم؟

حتما بعضی از شما هم مانند من خیلی وقت ها درگیر این موضوع بوده اید که چه تکنولوژی یا زبان برنامه نویسی یا پلتفرمی را باید یاد بگیرید که درامد بیشتر یا موفقیت های بیشتری را کسب کنید. بچسبید به ویندوز یا بروید سراغ لینوکس، برای برنامه نویسی وب ASP.net بهتر است یا php؟، #C بهتر است یا جاوا؟

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

whatsouldilearn

در هرم بالا هر تصمیمی که به راس آن نزدیک تر باشد تصمیمات و مسائل پایین تر از خود را تحت تاثیر قرار خواهد داد.

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

انتخاب زمینه فعالیت

انتخاب پلتفرم سخت افزاری و نرم افزاری

زبان برنامه نویسی

انتخاب بین کتابخانه ها و ابزارهای مختلف

 

چه چیزهایی یاد بگیریم: انتخاب زمینه فعالیت

اول اینجا را مطالعه کنید.

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

شاید محاسبه کنید که درخواست بازار در زمینه فلان زیاد است و بهتر است آن تکنولوژی را یاد بگیرید. همیشه از این محاسبات خواهید کرد. درست هم هست. ولی در نظر داشته باشید که در بلند مدت تفاوت آنچنانی نخواهد داشت. اگر شما فردی خلاق و پر تلاش و حرفه ای باشید در هر زمینه ای درامد خوبی در انتظار شما خواهد بود. در انتخاب زمینه فعالیت ۱۰ سال آینده خود را ببینید. بسنجید که در این زمینه خاص امکان پیشرفت تا چه حدی وجود دارد. آیا احتمال می دهید که شما از حد نهایت پیشرفت در زمینه خاص راضی خواهید بود یا نه؟

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

همیشه آماده تغییر باشید

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

فیلتر ها در AngularJs

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

برای استفاده و فراخوانی یک فیلتر روی یک مقدار خاص از کاراکتر | (pipe) در درون کاراکتر های data binding ({{}}) استفاده می شود.

مثال زنده آن به صورت زیر است:

Basic AngularJs Filters | Farid Bekran

در تکه کد بالا lowercase نام یکی از چندین فیلتر موجود در خود AngularJs است. تعداد قابل توجهی فیلتر به همراه این کتابخانه در اختیار برنامه نویس قرار می گیرد. با توجه به این که آموزش نحوه استفاده از تمامی این فیلتر ها از عهده این مطلب خارج است، به صورت اجمالی لیست این فیلتر ها ذکر می شود.

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

برای ساختن فیلتر، یک راه خوب (best practice) این است که آن را در module مربوط به خودش ایجاد کنیم تا بتوانیم در module ها مختلف از آن استفاده کنیم.

module مربوط به تعریف فیلتر

 module اصلی برنامه

 و به صورت زنده:

JS Bin

در تکه کد بالا ما ابتدا یک module برای فیلتر مورد نظرمان ایجاد کردیم و در آن module فیلتر را تعریف کردیم. سپس یک module اصلی ساختیم که module فیلتر را نیاز داشت (مطلب مربوط به module را مطالعه نمایید) .

خروجی دستور ساخت فیلتر یک function است که در واقع روی مقادیر ما اجرا خواهد شد. روش استفاده از این function توسط AngularJs بسیار ساده است: به ترتیبی که شما ذکر کرده اید به صورت زنجیر وار تمام فیلتر ها را روی مقدار مربوطه اجرا می کند. به طوری که خروجی فیلتر اول به عنوان ورودی فیلتر دوم پاس می شود و الی آخر.

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

نکته بسیار مهمی که در چند خط قبل هم ذکر کردم را دوباره تکرار می کنم. همیشه به یاد داشته باشید که فیلتر ها قابلیت زنجیره شدن در اجرا را دارند و ترتیب نیز در فراخوانی آن ها مهم است. 

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

Expression Scope Controller در AngularJs

مطالب قبلی در این زمینه را می توانید از این جا مطالعه نمایید.

به تصویر زیر توجه کنید:

scope_Expression_controller

Scope:

Scope و یادگیری نحوه کار آن و چگونگی استفاده از آن یکی از اولین مهارت هایی است که یک برنامه نویس Angular به آن نیاز دارد.

Scope در واقع یک context برای اجرای تمام دستورات expression های AngularJs است.

همان طور که از مطالب گذشته هم خاطرتان هست scope در واقع یک شی ساده  است. پس قابلیت تعریف المان های مختلفی را روی آن داریم. که به صورت خلاصه به دسته های زیر تقسیم بندی می شوند.

  • تمام property های مورد استفاده در view
  • تمام function ها مورد استفاده در view
  • تمام رویه های business ای مورد نیاز برنامه client ای ما

از یک زاویه دید دیگر، scope چسبی بین view و controller است. به صورتی که درست قبل از render شدن کامل view، AngularJs به اصطلاح scope مورد نظر ما را به view لینک می کند. که موتور مربوط به render کردن view ها با استفاده از data موجود در scope و expression ها و directive های استفاده شده در view، نسخه نهایی HTML مربوط به view ما را تولید کند. همچنین این موتور یک سری watch به هر property ای که ما در view استفاده کردیم می چسباند که بتواند تغییرات اتفاق افتاده در  view را به اطلاع controller مربوط به آن برساند.

نکته: همان طور که مطرح شد، scope با استفاده از دستور  watch$   قادر به عکس العمل در برابر تغییرات property های استفاده شده در view خواهد بود.

rootScope$: این شی به نوعی پدر تمام scope های ایجاد شده در یک برنامه AngularJs ای است. به طوری که همه controller ها موجود در یک برنامه (ng-app) قادر به دسترسی به آن هستند. به همین صورت هر property و function ای که در rooteScope$ تعریف شده باشد در تمام view های آن برنامه قابل دسترسی است.

Scopes in AngularJs – Farid Bekran

در مثال بالا از دستور run که در module تعریف شده است استفاده کردیم تا بخش مربوط به نوشتن مقدار در name را انجام دهیم. همچنین از مفهومی به اسم inject کردن استفاده کردیم تا reference ای به rootScope$ را به درون function نوشته شده مان پاس بدهیم. AngularJs به طور اتوماتیک reference شی مورد نظر ما را به function پاس خواهد داد. نکته: به طور کلی روش درستی نیست که در rootScope$ المان های زیادی مانند property ها و function ها ایجاد کنیم. در واقع فرض کنید که این شی همان global scope خود JavaScrip است. رفتار شما با این شی همان گونه باشد بهتر است. Controller: استفاده اصلی controller در AngularJs افزودن property و function به scope خودش است.

نکته: بهتر است نام controller به صورت Controller* باشد. به طور مثال userController

ایجاد یک controller ساده.

وقتی با استفاده از ng-controller یک controller موجود را به یک DOM Element می چسبانیم، AngularJs در زمان اجرا یک scope$ مخصوص به آن controller می سازد و به function ما پاس می دهد. و از آن به بعد می توانیم از شی  scope استفاده کنیم. در واقع این همان scope ای است که ما در درون controller و view به آن دسترسی داریم. سطوح درختی controller ها: همه scope ها در یک برنامه AngularJs یک scope پدر دارند. این حالت درختی در scope ها با استفاده از امکان controller ها تو در تو ایجاد می شود. استثنا: scope هایی که در درون directive ها ایجاد می شوند اصطلاحا isolated scope هستند و هیچ پدری ندارند. بودن در نظر گرفتن استثنا بالا، همه scope ها در AngularJs با استفاده از prototypal inheritance ایجاد می شوند. این همان امکانی است که scope ها را قادر می سازد به خصوصیات پدر خود دسترسی داشته باشند. نحوه کار این نوع ارث بری به طور خلاصه این گونه است: اگر یک property مورد درخواست در expression در scope خودش وجود نداشت، AngularJs یک سطح بالاتر رفته و مقدار آن property را از پدر آن جویا می شود، این عمل را تا یافتن مقدار property مورد نظر ادامه می دهد تا حدی که دیگر پدری وجود نداشته (در همان rootScope)  اگر هیچ مقداری برای property مورد درخواست پیدا نکرد آن property را رها کرده و هیچ خطایی هم صادر نمی کند. Controller Hierarchy In AngularJs – Farid Bekran

نکته: همیشه دقت کنید که هیچ گونه دستکاری در DOM را در controller خود انجام ندهید.

Expression:

Expression ها را در مثال های مختلفی که تا کنون دیده اید استفاده کرده ایم. Expression های در AngularJs در درون {{/*expression*/}} دیده می شوند.

در مورد expression ها به نکات زیر توجه کنید:

  • همه expression ها به اصطلاح در context یک scope اجرا می شوند و به تمام متغیر های آن scope دسترسی دارند.
  • expression ها هیچ وقت خطاهایی از قبیل Type Error و Reference Error نمی دهند.
  • هیچ گونه دستور کنترلی در expression ها قابل استفاده نیست.

تجربه ای در مورد ارتباط در تیم ها

چند روز پیش به واسطه یکی از دوستان ویدئویی با عنوان A Cannon In C sharp دیدم.

حدود ۳۰ دقیقه صحبت در مورد C Sharp و net. توسط  Jon Skeet بود. پیشنهاد اکید دارم که این ویدئو را ببینید.

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

WDWDWC البته من عنصر چهارمی هم به این عناصر اضافه می کنم.

WDWDWPWC

موضوع برنامه و به موقع رساندن یک پروژه موضوع بسیار مهمی است و حتی بعضی وقت ها مهمتر از کیفیت کار نیز می شود.

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

ارتباط سالم و حرفه ای بین تیم های تولید محصولات و تیم تولید زیرساخت یکی از نشانه های بلوغ حرفه ای تک تک اعضای تیم ها و در کل یک سازمان است.

این ارتباط می تواند از طریق راههای زیر اتفاق افتد.

در لیست بالا هر چه قدر از آیتم های بالا به پایین بیاییم سهولت و تاثیر ارتباط بیشتر خواهد شد. ولی وابستکی به افراد خاص نیز بیشتر می شود.

یکی از نکته های جالب در مورد اعضای تیم تولید زیر ساخت به نظر من این است که سعی کنند بعضی وقت ها در دسترس نباشند!!! همیشه در دسترس بودن افراد ذهن بقیه همکاران را تنبل خواهد کرد.

دید کلی یا همان Big Picture داشتن در مورد معماری و زیرساخت یک پروژه نقش اساسی در تصمیم گیری های استراتژیک اعضای تیم های محصولات دارد

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

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

در پاسخ به این دوستان باید بگویم اگر ارتباط سالمی بین اعضای تیم ها برقرار نشود پروژه هر چه که باشد و هر پشتوانه ای هم که داشته باشد بالاخره شکست خواهد خورد و همه بیکار خواهند شد. (باور کنید! تجربه دارم!)

اگر دقت کنید زیر ساخت و تیم مربوط به آن سرویس دهنده هستند. سرویس دهنده به محصولات نهایی یک شرکت یا سازمان. پس اگر محصولات نهایی یک سازمان به نتیجه نرسند دیگر به تیم زیرساختی نیاز نخواهد بود! و محصولات نهایی دست چه کسانی هستند؟ همان دوستان تیم های تولید محصولات!

Module در AngularJS

به طور کلی برنامه نویسی Modular در javascript یکی از pattern های خوب برنامه نویسی است. مطالعه این pattern بدون در نظر گرفتن استفاده آن در AngularJs بسیار مفید است. برای مطالعه بیشتر این pattern به اینجا مراجعه کنید.

در برنامه مثالی که در سلام AngularJs مطرح کردم همان طور که دیدید function ای که به عنوان controller استفاده کرده بودیم در هیچ Module ای قرار نداشت و اصطلاحا در global scope بود. global scope بودن به طور ساده و خلاصه یعنی این که این function یا متغیر یا هر چیزی که باشد از تمام نقاط برنامه قابل دسترسی است.

مثال سلام AngularJs

JS Binاین نحوه کد نویسی در javascript یک روش بد برنامه نویسی یا anti pattern  است. راه حلی که AngularJs برای برنامه نویسی بهتر و مدیریت بهتر controller ها و دیگر فاکتورها دارد module است. نحوه تعریف یک module به صورت زیر است  

این متد اصطلاحا متد setter است و کارش ایجاد کردن یک module در برنامه ما است. برای دسترسی به یک module از متد getter همین api استفاده می شود.

 با دسترسی به شی  یک module امکان ایجاد controller و service و directive و دیگر کامپوننت ها با استفاده از دستورات خاص خودشان، بوجود خواهد آمد. پارامتر ورودی اول دستور setter مربوط به ایجاد یک module نام module مورد نظر ما است. که به صورت camel case نیز خواهد بود. پارامتر دوم ورودی دستور setter مربوط به ایجاد یک module لیستی از module ها مورد نیاز این module است که injector موجود در AngularJs قبل از load شدن module ما آن module ها را load کرده و آماده استفاده می کند. با استفاده از امکان module مربوط به AngularJs، تکه کرد برنامه ما به صورت زیر تغییر می کند. Module In AngularJs

نتیجه کد جدید با کد قبلی تفاوتی ندارد ولی استفاده از امکان module تغییراتی به کد مثال جدید ما داده است.

اول: در ng-app باید نام module ای که میخواهیم load  و استفاده شود را ذکر کنیم.

دوم: از دستور controller که روی شی  module تعریف شده است برای ایجاد controller استفاده کرده ام. که پارامتر اول آن نام controller و پارامتر دوم آن function بی نام مربوط به controller است.

data binding در AngularJs

اول رفع مسئولیت را بخوانید!

Binding در AngularJs یکی از اولین نکات مورد توجه هر برنامه نویسی است. در واقع نوع binding ای که در این کتابخانه وجود دارد کمی با نوعی که شاید خیلی از ما آشنایی داشته باشیم متفاوت است. AngularJs بر خلاف بیشتر کتابخانه های client side به صورت پیش فرض two way data binding را پشتیبانی می کند.

AngularJs روش متفاوتی از اکثر کتابخانه های فعلی MVC موجود در بازار را برای ایجاد view در نظر گرفته است.

در اکثر کتابخانه های فعلی اتفاقی مانند ASP.NET MVC (فقط سمت client) برای view ها می افتد. با این روش که شما یک سری اطلاعات تحت نام  model به الگویی به نام view می دهید و یک موتور با استفاده از این اطلاعات و زبان خاص view در نهایت HTML به شما تحویل می دهد. در این حالت binding ای اتفاق نیفتاده است و اصطلاحا view مرده ای خروجی این کار بوده است. (تصویر پایین)

 

view-model-html

روش بیشتر کتابخانه ها برای تولید view

AngularJs روش متفاوتی در پیش گرفته است که اصطلاحا به آن two way data binding گفته می شود. علاوه بر این که به صورت داخلی engine ای برای ترکیب view و model برای تولید HTML دارد. امکان ارتباط دو طرفه نیز برای model که اینجا همان scope$ است و view ارائه می دهد. (با استفاده از syntax مربوط به خود) این view را اصطلاحا view زنده بنامیم!

همان طور که در مطلب سلام AngularJs گفتم این امکان را می توان خیلی ساده تعریف کرد.

پس از تولید نهایی HTML مربوط به view مورد نظر ما، اگر هر property از scope$ از طریق controller تغییر کند، تغییرات به صورت اتوماتیک به view اعمال می شوند. و بلعکس اگر در view تغییری در property ای از scope$ اتفاق افتد controller می تواند بر اساس تغییرات کار خاصی انجام دهد. (با استفاده از همان watch$)

روشی که angularJs برای ارتباط view و model دارد

روشی که angularJs برای ارتباط view و model دارد

با در نظر گرفتن مثال سلام AngularJs

JS Bin

ng-model: در این مثال دستوری که به view می گفت اطلاعات چه property ای از scope$ را در درون input قرار بدهد و هنگام تغییر در مقدار input تغییرات را در چه property ای اعمال کند ng-model بود. (scope.name$)

{{name}}: این دستور امکان استفاده از one way data binding در AngularJs است. این دستور به view می گوید مقدار name از scope$ را در مکان مورد نظر اعمال کند و این کار نیز هر زمان که name تغییر کرد تکرار خواهد شد.

watch$: این دستور همان بخشی را ایجاد می کند که گفتم model را قادر به observe کردن تغییرات اتفاق افتاده در view می کند. ورودی دستور watch$ می تواند نام property مورد نظر ما برای بررسی تغییر، باشد. در همان مثال ما به ازای هر تغییر در name عبارت “changed” را به انتهای property مورد نظرمان اضافه می کنیم.

مهم : روش متداول خوب برای data binding

با توجه به این که در AngularJs از prototypical inheritance برای پیاده سازی controller ها و scope$ های تو در تو استفاده می شود. (در مورد این موضوع بیشتر بحث خواهیم کرد) نیاز است که همیشه در نظر داشته باشید که به طور مستقیم در scope$ یک property ایجاد نکنید.

به طور مثال به جای ایجاد یک property به صورت زیر

یک شی جاواسکریپتی ایجاد کرده و property مورد نظر خود را در آن ایجاد کنید

بدیهی است وقتی می خواهیم مقدار این property را به جایی bind کنیم باید از {{person.name}} استفاده کنیم.

 

یک مقدار مهندسی – به بهانه AngularJs 2.0

چند روز پیش شنیدم که تیم AngularJs تصمیم به رها کردن نسبی پروژه AngularJs 1.x گرفته و نسخه بعدی این کتابخانه AngularJs 2.0 خواهد بود. (این موضوع مربوط به ماهها قبل می شود ولی من دیر شنیدم) موضوع اصلی این نوشته تغییرات احتمالی این کتابخانه نیست. از آن جایی که با بررسی هایی که کردم به این نتیجه رسیدم که نسخه دوم این کتابخانه بسیار بسیار در کاربری و مفاهیم و پیاده سازی با نسخه اول آن فرق دارد. چند نکته به نظرم رسید.

در اولین نگاه به موضوع برای من قابل درک نبود و نیست که کتابخانه ای به طور کلی از رده خارج شود و تیم اصلی تولید کننده آن پشتیبانی زیادی به آن ندهند. آن هم با در نظر گرفتن مدت کمی که از ایجاد و فراگیر شدن این کتابخانه گذشته است. من از فضای خارج از ایران اطلاعی ندارم ولی در ایران بسیار برنامه نویسان و مدیران پروژه ای دیده ام که بسیار مشتاق استفاده کردن از این کتابخانه بود و هستند.

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

همیشه در تصمیمات برنامه نویسی ام (یا شاید هر تصمیمی!) یک مثلث را در نظر می گیرم، که سه ظلع با عنوان های هزینه، زمان، کیفیت  دارد. در تصمیمات مدیریتی مهندسی همیشه باید توازنی بین این سه ظلع ایجاد شود. اگر این سه فاکتور اصلی را به صورت نا متوازن پیاده کنیم به احتمال خیلی بیشتری پروژه ما با شکست مواجه خواهد شد. در استفاده از AngularJs هم همین نکته را باید در نظر داشته باشیم.

cost-time-quality

اما مشکل اصلی من با پروژه های فعلی ای است که از این کتابخانه استفاده عظیم می کنند. این ها باید چکار کنند.

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

اگر سازمان شما مشکلی با این مسئله نداشته باشد که تیم های تولید به مدت ۶ ماه دست از پیاده سازی امکان جدید و پشتیبانی بکشند و وقت خود را صرف تغییر و بروزرسانی کدهایشان کنند، خیلی خوب است. و مشکلی وجود نخواهد داشت. ولی به احتمال زیاد هیچ مدیری یا حدااقل هیچ مشتری ای این موضوع را درک نخواهد کرد.

از آن جایی که این پروژه متن باز است یکی از گزینه های به صرفه برای کوتاه مدت fork کردن این پروژه و ایجاد نسخه های داخلی برای این پروژه خواهد بود. ولی این گزینه هم در طولانی مدت هزینه های بسیاری به همراه خواهد داشت. فرض کنید شما می خواهید زیرمجموعه ای از تیم تولید AngularJs در سازمان خود داشته باشید!!!

ولی کسانی که در حال یادگیری AngularJs هستند چه کنند؟!

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

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