تبلیغات
آکنده
آکنده ،،،،
در اندیشه پرواز هم نباش، پرنده هم مردنی است

خداحافظی[عمومی , ]

خبر تازه اینكه : وبلاگ تعطیل شد.

چون هیچ دلیلی برای نوشتن وبلاگ وجود ندارد، من هم دیگر نمی نویسم.

خداحافظ

تاریخ فرستادن:دوشنبه 30 مرداد 1385، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

كشور اسلامی ما[عمومی , ]

چند سال بعد از ۱۳۸۵ سال پیش اعراب با یك دین جدید به ایران وارد میشوند و با استقبال گرم مردم ایران كه از اون موقع تا حالا هیچ فرقی نكردند مواجه میشوند و درصد بالایی از مردم ایران مسلمان میشود و فرهنگ ایرانی اسلامی و بعد فرهنگ اسلامی ایرانی در كشور ایران شكل میگیرد به گونه ای كه مثلاً امروزه در ایران روز مادر، روز تولد فاطمه دختر پیامبر اسلام است.

قوانین ایران كه به گمانم پایه آن از كشورهای اروپایی مانند بلژیك گرفته شده است تماماً با قوانین اسلامی سازگار شده اند و ادامه ماجرا

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

تو این وبلاگ از همه انتقاد كردم و میكنم واینبار نوبت خودمه:

از خودم متنفرم، از حقارت خودم بدم می آید، از اینكه نمیتونم هیچ غلطی بكنم از این كه تو این كشور زندگی میكنم و هرروز شاهد این قبیل مسائل هستم و باز هم بی تفاوت هستم دلم میگیره. واقعاً قضیه همینه من یه آدم خودخواه هستم كه حتی برای نوشتن همین حرفهای میترسم وبلاگم را با اسم واقعی خودم منتشر كنم.

تاریخ فرستادن:یکشنبه 8 مرداد 1385، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

reusability[توسعه نرم‏افزار , ]

reusability  در كوتاهترین شكل قابل فهم "قابل استفاده مجدد بودن" معنی میدهد. این فارسی عجب زبان توپی است وقتی میخواهید یك مفهوم را به كار ببرید به جای اینكه نام آن مفهوم را ذكر كنید، شرحش را بیان میكند.(مثلاً تو انگلیسی برای مفهومی كه در ادامه میخواهم توضیح بدهم چنین آن را شرح میدهد : "be able to be used again" و اگر بخواهند از نام آن مفهوم استفاده كنند همان resusability را بكار میبرند.)
البته اگر دوست دارید از یك واژه ای مانند "بازكاربردی بودنی" استفاده كنید تا موجب انبساط خاطر همكارانتان شوید.
قابل استفاده مجدد بودن به این موضوع اشاره میكند كه فرایند انجام كاری را تدوین میكنیم و یا محصولی را  ایجاد میكنیم، طوری تدوین كنیم و یا تولید كنیم كه اگر دوباره در آینده احتیاج داشتیم همان كار را انجام دهیم و یا همان محصول را داشته باشیم، از همان تدوین فرایند قبلی و یا از همان محصول قبلی استفاده كنیم.
قابل استفاده مجدد بودن یك مفهوم مهندسی است كه مختص مهندسی نرم افزار نیست یعنی یك مهندس كسی است كه در انجام كارهایشان قابل استفاده مجدد بودن را در نظر میگیرد. البته توجه داشته باشید كه استفاده مجدد از یك محصول تقریباً مختصص مهندسی نرم افزار است و در سایر رشته ها من نمونه ای سراغ ندارم.

برای مثال یك شركت خودروسازی برای تولید هر خودرو از روشی مشابه برای خودروهای قبلی استفاده میكند، یعنی یكبار روش تولید خودرو(در این مثال تولید خودرو فرایند ما است.) را تدوین و مشخص میكند و سپس برای تولید بقیه خودروها از همین روش استفاده میكند.

در نرم افزار به دلیل ماهیتش، محصول تولید شده نیز میتواند قابل استفاده مجدد باشد. به محصولات تولید شده قابل استفاده مجدد asset(من دارائی نامجسم ترجمه میكنم) میگویند. با این حساب این یك وظیفه مهندس نرم افزار میشود كه طوری طراحی كند كه محصول تولید شده قابل استفاده مجدد باشد. و بدین ترتیب مفهموم component ها شكل میگیرند، component اجزا یك نرم افزار هستند كه یك ویژگی مهم آنها قابل استفاده مجدد بودن است.
مفهوم قابلیت استفاده مجدد دربرنامه نویسی، در قدم اول منجر به پیدایش برنامه نویسی procedural شد، همانطور كه میدانید در این روش به جای اینكه كدی كه یك رفتار را ارائه میكند هر بار كه به آن رفتار احتیاج پیدا شد از اول نوشته شود، یك بار نوشته میشود و هر بار كه رفتار مورد نیاز بود آن تكه كد فراخوانی میشود، به این تكه كد method یا procedure میگویند.
مفهوم قابلیت استفاده مجدد دربرنامه نویسی، در قدم اول دوم درمفاهیم شیگرائی ارائه شد. اگر خواستید بعداً بیشتر توضیح میدهم.
و سوم اثر از مفهوم قابلیت مجدد در بحث نسبتاً جدیدتر AOP است. اگر خواستید بعداً بیشتر توضیح میدهم.

.نكته آخر: اینكه یك سازمان علاوه بر فرایند ها و محصولات دارای عنصر سومی است به نام دانش كه دانش همواره قابل استفاده مجدد است و بحث زیادی درباره آن ندارم.

تاریخ فرستادن:چهارشنبه 28 تیر 1385، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

نمایشگاه الکامپ دوازدهم[عمومی , ]

با بازگشایی نمایشگاه الکامپ دوازدهم همچنان سایت نمایشگاه الکامپ به روز نشده است و اخبار مربوط به نمایشگاه دهم را نشان میدهد. راستی اگر باور ندارید میتونید به آدرس زیر مراجعه کنید: http://www.elecompfair.com/

.

.

داشتم پست میکردم که این لینک را پیدا کردم:  http://www.elecomp12.ir/farsi/index.asp

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

حالا طراحی به کنار دقت کنید که چقدر امکانات و قابلیتهای سایت پیشرفت کرده است؟ 

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

تاریخ فرستادن:چهارشنبه 28 تیر 1385، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

روش Design By Code (قسمت سه)[توسعه نرم‏افزار , ]

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

تو محل كارم هم روشهایی برای دور زدن طراحی كردن ها دارم، یه بار به عنوان طراحی component ای كه باید مینوشتم كه در واقع سرویسهای جهانی سازی(globalization) بود به عنوان طراحی مستند راهنمای برنامه نویسان آن component را آنطور كه در ذهنم در نظر داشتم، نوشتم و به مدیرم ارائه دادم و قرار شد كه همان را پیاده سازی كنم. برای نوشتن مستند راهنما ساختار بعضی از كلاسها را نیز نوشتم ولی متودهایش را پیاده سازی نكردم تا بتوانم تصوری از اینترفیس آن component و همچنین نحوه عملكرد آن و تعامل اشیا آن با یكدیگر بدست آورم.

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

در هر iteration ساده ترین رفتار ممكن را پیاده سازی كنید.

اصول low coupling و high cohesion و دیگر اصول class normalization را به شدت مورد توجه قرار دهید. چون همانطور كه در نرمالسازی رابطه ها در پایگاه داده بارها تجربه كرده ایم، عدم تبعیت از این نوع اصول مشكلات اساسی و وحشتناكی را به بار می آورند.

هرگز كاری را به آینده موكول نكنید، كل یك تكه از كد - كلاس، كامپوننت،متود،... - را به طور كامل یكجا و در یك مقطع زمانی بنویسید.

كد را مستند كنید، اگر در مورد عملكرد كدی كه خودتان نوشته اید به راحتی مستندات همراه را اضافه كنید، احتمالاً منطق مورد استفاده در كدتان غلط است و به همین دلیل نمیتوانید در مورد آن توضیح بنویسید.

من حدود 8 -9 ماه است كه بر روی یك ORM (ابزار نگاشت شیگرایی-رابطه ای) كار میكنم، در تمام مدت پیاده سازی iteration اول كارم كه به 15 هزار خط كد رسید و مدت 4 ماه طول كشید، حتی یكبار هم آن را تست نكردم و این ORM شامل مولفه های گوناگون بودند كه باید با هم كار میكردند، بعضی از آنها مربوط به پایگاه داده بودند و بعضی مربوط به ریموتینگ و دسته ای نیز مربوط به سرویسهای رابط كاربر و همچنین مولد كد(به خاطر type-safety مجبور شدم مولد كد داشته باشم.). بعد از حدود 4 ماه تصمیم گرفتم برای تست آن یك برنامه حسابداری شخصی مختصر با تقلید از Microsoft Money به طور آزمایشی بنویسم تا هم اجرای چارچوپ ORM را تست كنم و هم كارائی آن را در افزایش سرعت تولید بررسی كنم. این كار فقط حدود 2 هفته طول كشید كه البته حدود نصف آن مربوط به افزودن چیزهایی بود كه تاكنون به آنها توجه نداشتم. نمیتونید تصور كنید كه چه حسی داشتم، از اینكه بعد این مدت طولانی تونستم كدهایم را در حال اجرا میدیم فوق العاده لذت میبردم و برای خودم ذوق میكردم، از اینكه تمام مشكلاتش را تنها در مدت 1 هفته حل كردم فوق العاده خوشحال بودم، حتی یك شب تا صبح از فرط خوشحالی خوابم نبرد.

راستی هیچ دقت كردید با وجود اینكه اسم وبلاگم را random انتخاب كردم ولی به غرورم میخورد.)

الان دارم یك مستند در مورد CAB میخونم، خیلی دوست دارم كه در مورد پیچیدگی(complexity) و سادگی(simplicty) و ساده ارائه كردن(simplexity) دیدگاهم را ارسال كنم.

به امید خدا تا فردا...

تاریخ فرستادن:سه شنبه 27 تیر 1385، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

anti patterns[عمومی , ]

آنتی پاترن به الگوهایی میگویند كه درباره عدم اتخاذ یك تصمیم و یا مراقبت كردن از چیزهایی است كه ممكن است شما را در مسیر اشتباه قرار دهد. برخلاف pattern ها كه قالب كلی آنها شرایط اطلاق مساله و پاسخ مناسب برای آن شرایط است آنتی پاترنها شامل شرایط هستند ولی در مورد برخورد با مساله توضیح میدهند چه كاری در این شرایط نامناسب است چه دامهایی معمولاً در این شرایط وجود دارند.

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

تاریخ فرستادن:شنبه 9 اردیبهشت 1385، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

[توسعه نرم‏افزار , ]

چند تا نکته کوچک در مورد performance :

قبل از cast کردن از is استفاده نکنید.

احتمالاً گاهی اوقات برای cast یک شی به یک نوع دیگر از is استفاده کرده باشید و بعد از اینکه مطمئن شدید که قابل cast است شی را cast کرده باشید.

مثال فرض کنید یک شی به نام myObject دارید و میخواهید در صورتی که از نوع AClass باشد با آن کار کنید، معمولاً چنین مینویسیم:

if ( myObject is AClass)

{

    AClass aObject = (AClass)myObject;

    // using aObject

}

اما روشی که توصیه میشود اینگونه است:

AClass aObject = myObject as AClass;

if ( aObject != null )

{

   // using aObject

}

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

البته همانطور که میدانید عمل cast در performance تاثیر منفی میگذارد، پس بطور کلی باید از اضافه cast کردن یک شی صرف نظر کرد. برای مثال بعضیها به جای تعریف یک متغییر جدید برای نسخه cast شده شی، هر بار که نیاز به شی دارند آن را مجدداً cast میکنند:

غلط:

((RequiredType)object).Method1();

((RequiredType)object).Method2();

((RequiredType)object).Method3();

درست:

RequiredType objectAsRequiredType = objectAsRequiredType;

objectAsRequiredType.Method1();

objectAsRequiredType.Method2();

objectAsRequiredType.Method3();

در تکه کد غلط شی چندین بار cast شده است، اما در تکه کد درست، فقط یکبار cast شده است.

همچنین یک اشتباه متداول دیگر:

غلط:

for(int i=0;i<sourceDataList.Count;i++)

{

    ((RequiredType)object).DoJob(sourceDataList[i]);

}

درست:

RequiredType objectAsRequiredType = objectAsRequiredType;

for(int i=0;i<sourceDataList.Count;i++)

{

    objectAsRequiredType.DoJob(sourceDataList[i]);

}

در تکه کد غلط در هر بار اجرای حلقه شی شما cast میشود ولی در تکه کد درست cast کردن شی قبل از ورود به حلقه انجام میشود.

در مورد عملگر as نیز گفتنی است که برای cast کردن بکار میرود منتها با عملگر () این فرق را میکند که در صورتی که شی شما قابل cast نباشد مقدار null را برمیگرداند، اما عملگر () در صورتی که شی شما قابل cast نباشد و بخواهید با آن شی را cast کنید exception در میکند. همچنین as در صورتی که متغییر شما حاوی شی ای نباشد(مقدارش null باشد) باز هم خروجی null است.

 

برای ساختن متن از + استفاده نکنید، StringBuilder اکیداً توصیه میشود.

اگر دو متن را با + به هم متصل کنید در مقایسه با اینکه از StringBuilder استفاده کنید و همچنین عملیات با متن در برنامه شما متدوال باشد، به شدت سرعت برنامه پائین خواهد آمد. برای مثال اگر یک عملیات ساخت متن با StringBuilder به طور مثال 4 ثانیه طول بکشد معادل آن با استفاده از + و String.Concat چندین روز طول خواهد کشید.

 

در مورد اشیا IDisposable حتماً از using استفاده کنید. یک نکته مهم که در مورد using وجود دارد اینست که using یک بلاک try/catch به کد اضافه میکند و حتی در صورتی که در بلاک using شما یک exception رخ دهد، باز هم شی شما Dispose خواهد شد. اما اگر اصرار دارید که متود Dispose را خودتان مستقیم صدا کنید حتماً صدا زدن متود Dispose را در قسمت finally یک بلاک try/catch/finally قرار دهید تا حتماً صدا زده شود.

تاریخ فرستادن:شنبه 29 بهمن 1384، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

[عمومی , ]

تاریخ فرستادن:چهارشنبه 19 بهمن 1384، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

شی گرایی :‌ رفتارها[توسعه نرم‏افزار , ]

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

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

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

انواع روشهای اجرای یک رفتار: همزمان، غیر همزمان

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

در روش غیرهمزمان شی فرستنده پیام منتظر میماند تا شی گیرنده پیام رفتار درخور را انجام دهد. روش غیرهمزمان ساده تر است و جزئیات و پیچدگیهای کمتری دارد.

اینکه یک رفتار همزمان اجرا شود یا ناهمزمان به دو صورت میتواند مشخص شود، درهنگام تعریف رفتار نوع اجرای آن مشخص شود، در هنگام صدا زدن رفتار نوع اجرا مشخص شود. در حال حاضر صرفاً میتوان در هنگام صدا زدن رفتار نوع اجرا را مشخص کرد اما در آینده در C#3.0 این امکان اضافه شده است که در هنگام تعریف متود(رفتار) نوع اجرای آن را همزمان معین کرد.

دو نکته مهمی که در طراحی رفتارها وجود دارد اینست که

یک : تا انجایی که امکان دارد از ساختن رفتارهایی که در محیط اطراف(اشیا دیگر) تغییر ایجاد میکنند پرهیز کنید در غیر اینصورت یک اصل نرمال سازی کلاس(class normalization) به نام کم جفت شدگی (low coupling) را زیر پا خواهید گذاشت.

دو : از ساختن رفتارهایی که هم در ساختار داخلی خود و هم در اشیا دیگر تغییر ایجاد میکنند پرهیز کنید.

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

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

 بحث پیامها را در ادامه مفصلتر ادامه میدهم، صرفاً در اینجا این یک توضیح کوچولو دادم تا اشتباهاً رفتار را با پیام اشتباه نگیرید مهم است بین رفتار و پیام تفاوت قائل شویم.

تاریخ فرستادن:چهارشنبه 19 بهمن 1384، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

کنترل تغییر مقدار ویژگی - پاسخ[توسعه نرم‏افزار , ]

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

یعنی برای ویژگی که در دو پست پیشتر نوشتم، از متغیری به نام propertyValue_Name استفاده میکنم و این نام به قدر کافی تابلو است و اشتباهاً آن را در کدهایم دستکاری نخواهم کرد:

// variable to store value of property Name
private string propertyValue_Name ;
public string Name
{
  get
  {
     return propertyValue_Name ;
  }
  set
  {
     if ( propertyValue_Name != value )
       OnNameChanged(this,EventArgs.Empty);
     propertyValue_Name = value;
  }
}

تاریخ فرستادن:شنبه 8 بهمن 1384، نویسنده: فرشید کزازی (همیشه همینه)
تعداد بازخوردها: ، شما هم دیدگاه خود را ارائه کنید

 

درباره فرشیدکزازی

 
 

هیچ چیز قابل گفتنی درباره خودم وجود نداره.
کاری داشتید به farshidkazazi@gmail.com پیام بفرستید.

 

 

درباره آکنده

 
 

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

** اسم وبنوشت هیچ معنای خاصی ندارد، اولین کلمه ای بود که موقع ثبت نام به ذهنم رسید.

دسته بندی نگاره ها:
عمومی (7)
توسعه نرم‏افزار (13)

 

 

وبنوشتهای دیگر

 
  زیر چتر باران
واژگان مدیریت دانش
 

 

ابزارها

 
 
جستجو در بلاگ


برای دریافت نگاره ها از طریق email با وارد کردن آدرس email نام‏ نویسی کنید:
بایگانی گذشته
مرداد 1385 (2)
تیر 1385 (3)
اردیبهشت 1385 (1)
بهمن 1384 (4)
آذر 1384 (1)
آبان 1384 (4)
مهر 1384 (5)