معرفی Oracle Forms
- همه مردان استیو جابز | www.caffecinema.com
- تقویم فارسی جاوا اسکریپت | amib.ir
- چک لیست شکست در RUP | hamidreza.info
- سیر تکاملی Delegate ها - قسمت چهارم، Func and Action | www.persiadevelopers.com
- مجله کامپیوتر - دانلود کتاب آموزش نرم افزار Microsoft Word 2007 | pcmagblog.blogfa.com
- مدرسه هوشمند ایرانی - مقایسه مدارس ژاپن با مدارس ایران | smartschool-ir.blogfa.com
- Dark Pastel Visual Studio Theme | www.servicestack.net
- مدلی دیگر از refactoring یک عبارت if | blog.drorhelper.com
اندکی به روز رسانی
مفاهیم برنامه نویسی ـ آشنایی با سازندهها
در اینجا غیر از مورد زمانبندی انجام پروژه سعی شده است به دیگر موارد غیره از قبیل شناخت نیازمندیها، نحوه بستن قرارداد، نحوه قیمت دهی و ... اشاره نشود.
در ابتدا در مورد موضوعات کلی و عمومی بحث میکنیم.
1- انتخاب فریمورک، فریمورکهای فراوان و مختلفی برای کار با زمینههای مختلف نرم افزاری در جهان وجود دارند که هرکدام مزایا و معایبی دارند. این روزها استفاده از فریمورکها به قدری جای افتاده است و به اندازهای امکانات دارند که حتی ممکن است امکانات یک فریم ورک باعث شود از یک زبانی که در تخصصتان نیست استفاده کنید و آنرا یاد بگیرید.
2- زمانبندی انجام پروژه، به نظر خود بنده، سختترین و اساسیترین مرحله، برای هر پروژهای، زمانبندی مناسب آن است که نیازمندی اساسی آن، شناخت سایر مواردی است که در این متن بدانها اشاره میشود. زمانبندی دقیق، قرار ملاقاتها و تحویل بهموقع پیش نمایشهای نرم افزار، ارتباط مستمر با کارفرما و تحویل حتی زودتر از موعد پروژه باعث رضایت بیشتر کارفرما و حس اطمینان بیشتر خواهد شد. اگر در تحویل پروژه دیرکرد وجود داشته باشد، باعث دلسردی کارفرما و نوعی تبلیغ منفی خواهد بود. حتی زمانبندی و تحویل به موقع پروژه برای کارفرما بیشتر از کیفیت اهمیت دارد.
3- انتخاب معماری نرم افزار، معماری نرم افزار در اصل تعیین کننده نحوه قطعه بندی و توزیع تکههای نرم افزار، نحوه ارتباط اجزاء،، قابلیت تست پذیری، قابلیت نگهداری و قابلیت استفاده مجدد از کدهای تولید شده میباشد. یکی از اهداف اساسیای که باید در معماری نرمافزار بدان توجه کرد، قابلیت استفاده مجدد از کد است. در یک معماری خوب ما قطعاتی درست خواهیم کرد که بهراحتی میتوانیم از آن در نرمافزارهای دیگر نیز استفاده کنیم. البته قابلیت تست پذیری و قابلیت نگهداری نیز حداقل به همان اندازه اهمیت دارند. در این سایت موارد بسیار زیاد و کاملی جهت ساخت معماری مناسب و design patterns وجود دارد که میتوانید در اینجا یا اینجا مشاهده کنید.
4- قابلیت اجرا بر روی پلتفرمهای مختلف، هرچند این مورد ممکن است بیشتر به نظر کارفرما بستگی داشته باشد، اما در کل اگر کارفرما بتواند سیستم را در پلتفرمهای مختلفی اجرا کند، راضیتر خواهد شد. اگر قصد فروش نرمافزار طراحی شده را داشته باشیم، در اینصورت نیز میتوانیم کاربران پلتفرمهای مختلف را مورد هدف قرار دهیم یا سیستم را در سرورهای مختلفی میزبانی کنیم.
5- انتخاب سیستم بانک اطلاعاتی و نحوه ارتباط با آن. باید تصمیم بگیرید که از چند سیستم بانک اطلاعاتی، چگونه و به چه منظوری استفاده خواهید کرد. مواردی وجود دارند که سیستم را طوری طراحی کردهاند تا در زمان بهره برداری امکان انتخاب بانکهای اطلاعاتی یا نحوه ذخیره اطلاعات برای مدیر سیستم وجود دارد. مثلا در BlogEngine.net میتوان انتخاب کرد که اطلاعات در SQL Server ذخیره شوند یا در سیستم فایل مبتنی بر XML . بحثهای بسیار زیادی در این سایت و کل فضای وب پیرامون نحوه انتخاب و استفاده از ORM ها، چگونگی معماری مناسب آن وجود دارد. بطور مثال همیشه بحث سر اینکه از الگوی Repository استفاده شود یا نشود وجود دارد! باید به خودمان پاسخ دهیم که آیا واقعاً نیاز است که سیستم را برای امکان استفاده از Ormهای مختلف طراحی کنیم؟
6- نحوه ماژول بندی سیستم و امکان افزودن راحت ماژولهای جدید به آن. امروزه و با افزایش کاربران محصولات انفورماتیک که باعث بیشتر شدن سواد مصرف کننده در این زمینه و بالطبع افزایش نیازهای وی شده، همیشه احتمال اینکه کارفرما موارد جدیدی را بخواهد وجود خواهد داشت. باید سیستم را طوری طراحی کرد که حتی بتوان بدون توقف اجرای آن موارد جدید (پلاگینهای جدید) را بدان افزود و اجرا کرد.
7- میزان مشارکت دیگران در رفع نیازمندیهای کابران. ممکن است این گزینه در درجه اول زیاد با اهمیت جلوه ندهد، اما با تعمق در وبسایتها و نرمافزارهای بزرگ که هم اکنون در دنیا صاحب نامی شدهاند میبینیم همه آنها تمهیداتی اندیشیدهاند تا با وجود کپسوله کردن موارد پس زمینه، امکاناتی را در جهت مشارکت دیگران فراهم کنند. اکثر شبکههای اجتماعی api هایی را مهیا کرده اند که افراد ثالث میتوانند از آنها استفاده کنند. اکثر سیستمهای مدیریت محتوا و ابزارهای e-commerce تمهیداتی را برای راحتی ساخت plugin و apiهای برای راحتی برقراری ارتباط اشخاص ثالث اندیشیدهاند. از نظر این جانب موارد 6 و 7 برای ادامه حیات و قابلیت رقابت پذیری پروژه از درجه اهمیت زیادی برخوردار است.
8- معماری Multi tenancy بلی یا خیر؟ Multi tenancy یک از بحثهای مهم رایانش ابری است. در این حالت فقط یک نمونه از نرم افزار در سمت سرور در حال اجراست ولی کاربر یا گروهی از کاربران دید یا تنظیمات متفاوتی از آنرا دارند.
در ادامه به موارد فنیتری خواهیم پرداخت:
9- بحث انتخاب ابزار Dependency injection مناسب و مهیا سازی امکاناتی جهت هرچه راحتتر کردن امکان تنظیم و register کردن اشیا بدان. نحوه پیکربندی مناسب این مورد میتواند کد نویسی را برایتان بسیار راحت کند. دات نت تیپس مطالب بسیاری را در این مورد ارائه داده است میتوانید اینجا را ببینید.
10- کشینگ. استفاده از یک سیستم کشینگ مناسب در ارتباط با بانکهای اطلاعاتی و یا سایر سیستمهای ذخیره و بازیابی اطلاعات میتواند کمک بسیاری در پرفرمنس برنامه داشته باشد. سیستمها و روشهای مختلفی در مورد کشینگ وجود دارند. میتوانید برای اطلاعات بیشتر اینجا را مطالعه فرمایید.
11- Logging. یک سیستم لاگر مناسب میتواند وارنینگها و خطاهای بوجود آمده در سیستم را در یک رسانه ذخیره سازی حفظ کند و شما به عنوان توسعه دهنده میتوانید با مطالعه آن نسبت به رفع خطاهای احتمالی و بهبود در نسخههای آتی کمک بگیرید.
12- Audit logging یا Activity logging و Entity History. میتوانید کل یا برخی از فعالیتهای کاربر را در یک رسانه ذخیره سازی، ذخیره کنید، از قبیل زمان ورود و خروج، آیپی مورد استفاده، سیستم عامل، مرورگر، بازبینی از صفحه وغیره. همچنین در audit logging میتوانید زمانهای دقیق تغییرات مختلف موجود در موجودیتهای سیستم، فرد انجام دهنده تغییرات، سرویس انجام دهنده تغییرات، مدت زمان سپری شده و ... را ذخیره کرد. Entity History : ممکن است تصمیم بگیرید که کل اتفاقاتی را که برای یک موجودیت در طول زمان حیاتش در سیستم میافتد، ذخیره کنید.
13- Eventing ، Background Workerها و Backgroudn jobs ( Scheduled tasks ). باید سیستم را طوری طراحی کرد که بتواند به تغییرات و اتفاقات افتاده در سیستم پاسخ دهد. همچنین این مورد یکی از نیازمندیهای معماری بر اساس پلاگین است. Background Workerها در واقع کارهایی هستند که در پس زمینه انجام میشوند و نیازی نیست که کاربر برای اتمام آن منتظر بماند؛ مثلاً ارسال ایمیل خوش آمدگویی را میتوان با آن انجام داد. Background jobs کمی متفاوت هستند در واقع اینها فعالیتهای پس زمینهای هستند که ممکن است در فواصل زمانی مختلف اتفاق بیافتند، مثل پاکسازی کش در فواصل زمانی مناسب. در سیستمهای مختلف تمهیداتی برای ذخیره سازی فعالیتهایی که توسط background jobs انجام میشود اندیشیده میشود.
14- پیکربندی صحیح نحوه ذخیره و بازیابی تنظیمات سیستم. در یک سیستم ممکن است شما تنظیمات متعددی را در اختیار کاربر و یا حتی خودتان قرار دهید. باید سیستم را طوری طراحی کنید که بتواند با راحتترین و سریعترین روش ممکن به تنظیمات موجود دستیابی داشته باشد.
15- خطاهای کاربر را در نظر بگیریم، باید یادمان باشد کاربر ممکن الخطاست و ما برای رضایت مشتری و قابلیت اتکای هرچه بیشتر برنامه باید سیستم را طوری طراحی کنیم که امکان برگشت از خطا برای کاربر وجود داشته باشد. مثلاً در SoftDelete مواردی که حذف میشوند در واقع به طور کامل از بانک اطلاعاتی حذف نمیشوند بلکه تیک حذف شده میخورند. پس امکان بازگردانی وجود خواهد داشت.
16- Mapping یا Object to object mapping. در توسعه شیءگرا مخصوصاً در معماریهایی مثل MVC یا Domain driven در موارد بسیاری نیاز خواهید داشت که مقادیر اشیاء مختلفی را در اشیای دیگری کپی کنید. سیستمهای زیادی برای این کار موجود هستند. باید تلاش کرد ضمن اینکه یک سیستم مناسب انتخاب کنیم، باید تمهیدی بیاندیشیم که تنظیمات آن شامل کد نویسی هرچه کمتری باشد.
17- Authorization یا تعیین هویت. باید با مطالعه و بررسی، سیستم و ابزار مناسبی را برای هویت سنجی اعضاء، تنظیم نقشها و دسترسیهای کاربران انتخاب کرد. باید امکان عضویت از طریق شبکههای اجتماعی مختلف را مورد بررسی قرار داد.
18- سرویسهای Realtime. کاربری یکی از مطالب شما را میپسندد و شما نوتیفیکشن آنرا سریع در صفحهای که باز کردید میبینید. این یک مورد بسیار کوچکی از استفاده از سرویسهای realtime هست. ابزارهای مختلفی برای زبانها و فریمورکهای مختلف وجود دارند؛ مثلاً میتوانید اینجا را مطالعه کنید.
19- هندل کردن خطاهای زمان اجرا، در سیستمهای قدیمی یکی از کابوسهای کاربران، قطعی سیستم، هنگ کردن با کوچکترین خطا و موارد این چنینی بود. با تنظیم یک سیستم Exception handling مناسب هم میتوانیم گزارشاتی از خطاهای بوجود آمده را تهیه کنیم، هم میتوانیم کاربر را در جهت انجام صحیح کارها هدایت کنیم و هم از کرش بیجای نرمافزار جلوگیری کنیم.
20- استفاده از منابع ابری یا توزیع شده، امروزه برای بسیاری از کارها تمهیداتی از طرف شرکتهای بزرگ به صورت رایگان و یا غیر رایگان اندیشیده شده است که به راحتی میتوان از آنها استفاده کرد. برای نمونه میتوان از سرویسهای Email به عنوان سادهترین و معمولترین این سیستمها یاد کرد. اما امروزه شرکتها حتی امکاناتی جهت ذخیره سازی دادههای blob (مجموعه ای از بایتها با حجم زیاد) را ارائه میدهند؛ امکانات دیگری نظیر کم کردن حجم تصاویر، تبدیل انواع mime typeها و ...
21- امنیت، فریمورکها اغلب موارد امنیتی پایهای را به صورت مطلوب یا نسبتا مطلوبی رعایت میکنند؛ ولی با اینحال باید در مورد امنیت سیستمی که توسعه میدهیم مطالعه داشته باشیم و موارد امنیتی ضروری را رعایت کنیم و همیشه مواظب باشیم که آنها را رعایت کنیم.
GitHub هم ایران را تحریم کرد
{"Data":[{"id":1,"Title":"گوشی موبایل تی پی-لینک مدل Neffos C5 دو سیمکارت","categories":[{"Name":"م وبایل","Id":1},
WebDAV استانداردی است بر روی پروتکل HTTP که Requestها و Responseهای مدیریت یک فایل را بر روی سرویس دهنده وب، تشریح میکند.
برای درک چرایی وجود این استاندارد بهتر است ذهن خود را معطوف به نحوهی عملکرد سیستم فایل در OS کنیم که شامل APIهای خاص برای دسترسی نرم افزارهای گوناگون به فایلهای روی یک سیستم است.
حال فکر کنید یک سرور Cloud راه اندازی نمودهاید که قرار است مدیریت فایلها و پروندههای Office را بر عهده داشته باشد و چون امکان ویرایش اسناد Office بر روی وب را ندارید، نیاز است تا اجازه دهید نرم افزارهای Office مستقیما فایلها را از روی سرور شما باز کنند و بعد از تغییرات، به جای ذخیره در سیستم local، محتوا را به فایل روی سرور ارسال کنند.
در مفهوم web عملا این کار غیر استاندارد و نادرست است. همه درخواستها و جوابها باید بر روی پروتکل Http باشند. خوب حال تصور کنید نرم افزارهای Office قابلیت آن را داشته باشند که به جای تحویل محتوا به سیستم عامل برای ذخیرهی آن بر روی سیستم local، محتوا را به یک آدرس ارسال نمایند و پشت آن آدرس، متدی باشد که بتواند به درخواست رسیده، به درستی پاسخ دهد.
این یعنی باید سمت سرور متدی با قابلیت ارسال پاسخهای درست و در سمت کلاینت نرم افزاری با قابلیت ارسال درخواستهای مناسب وجود داشته باشد.
WebDAV استاندارد تشریح محتوای درخواستها و پاسخهای مربوط به مدیریت فایلها است.
خوشبختانه نرم افزارهای Office و بسیاری از نرم افزارهای دیگر، استاندارد WebDAV را پشتیبانی میکنند و فقط لازم است برای سرورتان متدی با قابلیت پشتیبانی از درخواستهای WebDAV پیاده سازی نمایید و البته متاسفانه کتابخانههای سورس باز چندانی برای WebDAV در سرور دات نت وجود ندارد. من ماژولی را برای کار با WebDAV نوشتم و سورسش را در Git قرار دادم. برای این مثال هم از همین کتابخانه استفاده میکنم.
ابتدا یک پروژهی وب MVC ایجاد نمایید و پکیج xDav را از nugget نصب کنید.
PM> Install-Package xDav
اگر به web.config نگاهی بیاندازیم میبینیم یک module به نام xDav به وب سرور اضافه شده که بررسی درخواستهای WebDAV را به عهده دارد.
<system.webServer> <modules> <add name="XDav" type="XDav.XDavModule, XDav" /> </modules> </system.webServer>
همچنین یک Section جدید هم به config برای پیکربندی xDav اضافه شده است.
<XDavConfig Name="xdav"> <FileLocation URL="xdav" PathType="Local"></FileLocation> </XDavConfig>
خاصیت Name برای xDav نشانگر درخواستهایی است که باید توسط این ماژول اجرا شوند. در اینجا یعنی درخواستهایی که آدرس آنها شامل "/xdav/" باشد، توسط این ماژول Handle میشوند. عبارت بعد از مقدار Name در URL هم طبیعتا نام فایل مورد نظر شماست.
FileLocation آدرس پوشه ای است که فایلها در آن ذخیره و یا بازخوانی میشوند. اگر FileType با مقدار Local تنظیم شود، یعنی باید یک پوشه به نام خاصیت URL که در اینجا xdav است در پوشهی اصلی وب شما وجود داشته باشد و اگر با Server مقدار دهی شود URL باید یک آدرس فیزیکی بر روی سرور داشته باشد . مثل "c:\webdav"URL=
ما در این مثال مقادیر را به صورت پیشفرض نگه میداریم. یعنی باید در پوشهی وب، یک Folder با نام xdav ایجاد کنیم.
در ادامه چند فایل word را برای تست در این پوشه کپی میکنم.
می خواهیم در صفحه Index، لیستی از فایلهای درون این پوشه را نمایش دهیم طوری که در صورت کلیک بر روی هر کدام از آنها، آدرس WebDav فایل مورد نظر را به Word ارسال کنیم.
بعد از نصب Office، در registry چند نوع Url تعریف میشود که معرف اپلیکیشنی است که آدرس به آن فرستاده شود. این دقیقا همان چیزیست که ما به آن نیاز داریم. کافیست آدرس WebDav فایل را بعد از عبارت " ms-word:ofe|u| " در یک لینک قرار دهیم تا آدرس به نرم افزار Word ارسال شود. یعنی آدرس URL باید این شکلی باشد:
ms-word:ofe|u|http://Webaddress/xdav/filename
Webaddress آدرس وبسایت و filename نام فایل مورد نظرمان است. عبارت /xdav/ هم که نشان میدهد درخواست هایی که این آدرس را دارند باید توسط ماژول xDav پردازش شوند.
کلاسی با نام DavFile در پوشهی Model ایجاد میکنم:
public class DavFile { public string Name { get; set; } public string Href(string webAddress) { return string.Format("ms-word:ofe|u|http://{0}/xdav/{1}", webAddress, Name); } }
اکشن متد Index را در Home Controller، مانند زیر تغییر دهید:
var dir = new DirectoryInfo(XDav.Config.ConfigManager.DavPath); var model = dir.GetFiles().ToList() .Select(f => new DavFile() { Name = f.Name }); return View(model);
یک لیست از فایل هایی که در پوشهی webDav قرار دارند تهیه میکنیم و به View ارسال میکنیم. View را هم مثل زیر بازنویسی میکنیم.
@model IEnumerable<WebDavServer.Models.DavFile> <h1> File List </h1> <ul> @foreach (var item in Model) { <li> <a href="@Html.Raw(item.Href(ViewContext.HttpContext.Request.Url.Authority))"> @Html.Raw(item.Name) </a></li> } </ul>
قرار است به ازای هر فایل، لینکی نمایش داده شود که با کلیک بر روی آن، آدرس فایل به word ارسال میشود. بعد از ثبت تغییرات، word محتوا را به همان آدرس ارسال میکند و ماژول xDav محتوا را در فایل فیزیکی سرور ذخیره خواهد کرد.
برنامه را اجرا کنید و بر روی فایلها کلیک نمایید. اگر نرم افزار Office روی کامپیوترتان باز باشد با کلیک بر روی هر کدام از فایلها، فایل word باز شده و میتوایند محتوا را تغییر داده و ذخیره نمایید.
نرم افزار کلاینت (word) درخواست هایی با verbهای مشخص که در استاندارد WebDav ذکر شده به آدرس مورد نظر میفرستد. سرور WebDav درخواست را بر اساس Verb آن Request پردازش کرده و Response استاندارد را ایجاد میکند.
نرم افزار word پس از دریافت یک URL، به جای فرمت فیزیکی فایل، درخواست هایی را با تایپهای Option, Head, lock, get, post و unlock ارسال میکند. محتوای درخواست و پاسخ هر کدام از تایپها در استاندارد webDav تعریف شده و ماژول xDav آن را پیاده سازی نموده است.