Softwaring

حرف Q

softwaring — Thu, 12 Nov 2009 23:21:53 GMT

آیا می دانستید در کلمات زبان انگلیسی همیشه پس از Q حرف U می آید؟

!?What are you sinking about

softwaring — Thu, 12 Nov 2009 07:35:27 GMT

http://www.youtube.com/watch?v=YRf9ooQ7qq8

زبان و تقلید

softwaring — Thu, 12 Nov 2009 07:24:25 GMT

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

باور کنید اگر کسی ۱۰ سال هم با همین روش تمرین کند نمی تواند روان صحبت کند!

مگر زمانی که یک کودک دو ساله به جان مادر خود می افتد که "برای من از آن شکلات ها بخر" می داند که فاعل و مفعول و قید جمله کدامند و آیا زمان حال ساده استفاده کرده است یا ماضی نقلی؟!

به نظر می رسد بهترین روش یادگیری زبان، تقلید از افرادی باشد که به آن زبان تکلم می کنند. اما این کار چندان هم آسان نیست. متاسفانه ذهن ما مملو از معلوماتی است که بسیاری از آنها به شکل نادرست در ما نهادینه شده اند.

بسیاری از کلماتی که برای بیان منظور خود از آنها استفاده می کنیم اگرچه نادرست نیستند اما دارای معادل متداول تر و عموما ساده تر هستند.

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

به این مشکل، عدم وجود برخی اصوات زبان خارجی در زبان مادری خود را اضافه کنید - به عنوان مثال ادای حروفی که در آنها TH وجود دارد که فارسی زبانان عموما یا آنرا به شکل T یا به شکل S تلفظ می کنند.

در مورد لهجه به توصیه زیر از همان شخصی که در مطلب پیشین از او نقل قول شد توجه کنید:

Listen carefully where they put the ‘stress’ when they say a word. When speaking to the natives, listen intensively, what kind of intonations they use, and again, where they put the ‘stresses’ in their words. (The placement of stress in different parts of a word plays a major roll in shaping up different accents).

زبان

softwaring — Thu, 12 Nov 2009 06:40:53 GMT

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

شخصا معتقدم که از میان چهار مهارت زبان (خواندن/نوشتن/شنیدن/تکلم) بزرگترین مشکل ما ایرانیان تکلم به زبان انگلیسی است و بعد شنیدن.

یکی از اقوام که سالهاست در کشور آمریکا زندگی می کند و در دوره ای از زندگی خود مدرس زبان انگلیسی نیز بوده علت آنرا این چنین بیان می کرد:

The problem among many language learners is that we sort of take the backward path for learning. Meaning, we learn how to write right off the bat before we even open our mouths to a word. That’s against the natural way of learning a language. Take a newly-born child per se; how does he learn his language? For a couple of years he just listens (first step). Then, he tries saying things and starts talking (second step). Only after commencing into these two steps, he then gradually begins the hard tasks of reading and writing (last steps). From here on, he continually works on all four skills simultaneously. And what do we do? The first thing they teach us is how to write lower case ‘a’ and upper case ‘A’! Then we learn how to make the ‘present perfect tense’, before we even are able to handle a simple greeting in English!

به اعتقاد او مشکل اینجاست که عموما زبان را سروته به ما یاد داده اند!

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

تفاوت ها و شباهت های محیط کاری - تهران تا سیدنی (4)

softwaring — Tue, 10 Nov 2009 11:18:53 GMT

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

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

در مورد پروژه های نرم افزاری نیز روش مشابهی را تجربه کرده ام. از تحلیل تا طراحی و پیاده سازی و تحویل همین تفکر دنبال می شود محصول پیشین به تدریج از دور خارج شده (Phase Out) و محصول جدید جایگزین آن می شود (Phase In).

دمی درنگ

softwaring — Tue, 10 Nov 2009 00:56:53 GMT

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

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

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

به عنوان یک نمونه ساده، "رسیدن به وزن مطلوب" را در قالب یک پروژه بررسی می کنیم:

۱. حوزه (Scope) هدف باید مشخص، واقع بینانه و قابل دستیابی باشد: "کم کردن وزن به میزان ۸ کیلوگرم"

۲. زمان ابتدا و انتهای پروژه (هدف) باید تعیین شده باشد: "شروع از فردا - پایان ۸۰ روز دیگر"

۳. فازهای رسیدن به هدف باید مشخص و دارای نقاط کنترلی (Check Point - Milestone) باشد: "هر ۱۰ روز ۱ کیلو از وزنم کم خواهد شد"

۴. منابع لازم برای رسیدن به هدف (هزینه، میزان تلاش لازم...) باید به شکل واقع بینانه تخمین زده شود: "میزان مصرف غذاهای پر چربی به نصف رسیده و میوه و سبزی جایگزین آن خواهد شد - N تومان برای ثبت نام در باشگاه ورزشی X هزینه خواهد شد"

۵. کیفیت مطلوب تعیین شده باشد: "کم کردن وزن نباید بر سلامتی من تاثیر منفی داشته باشد. در نتیجه طول مدت کم کردن وزن را خیلی کوتاه مدت تعیین نمی کنم و در صورت امکان برنامه غذایی خود را با یک متخصص تغذیه مورد مشورت قرار می دهم"

۶. ریسک ها و محدودیت ها باید تا حد امکان ارزیابی و تحلیل شود و روشهای کمینه ساختن آنها یا دستکم کاهش اثر آنها شناخته شود: "پیش از شرکت در مهمانی ها که غذاهای پرچربی و وسوسه برانگیز (!) وجود دارد خود را با غذاهای مناسبتر سیر می کنم - از ۱۰ روز دیگر به مدت ۲ هفته به دلیل مشغله کاری مجبور به اضافه کاری هستم و نمی توانم به باشگاه ورزشی بروم، در نتیجه در آن دوره میزان مصرف غذای خود کمی کاهش خواهم داد"

۷. از زمان آغاز تا انجام، مرتب مورد ارزیابی قرار گیرد و پیشرفت آن کنترل شود: "هر ۲ روز یکبار وزن خود را کنترل کرده و هر ۱۰ روز یکبار اطمینان حاصل می کنم که یک کیلو از وزن خود را از دست داده ام"

۸. در صورت لزوم برنامه تعیین شده بروزرسانی شود: "پس از گذشت یک ماه: قرار بوده پس از گذشت ۳۰ روز ۳ کیلوگرم از وزن کاسته شود اما ۲ کیلوگرم کم شده است. در نتیجه برنامه غذایی روزهای آینده کمی مشکل تر شده و یا طول پروژه به ۹۰ روز افزایش می یابد"

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

Separation of Concerns و اثر آن در تست نرم افزار

softwaring — Thu, 22 Oct 2009 06:21:23 GMT

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

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

نمونه ای نرم افزاری از این مفهوم، الگوی طراحی MVC است.

Separation of Concerns - به نظر من - یکی از مفاهیم زیر بنایی برای انجام موفق تست های مختلف نرم افزار است. معمولا یک سیستم نرم افزاری در حین تولید و پس از آن تحت تست های مختلفی قرار می گیرد که از آن جمله می توان به تست ماژول های برنامه (Unit Test)، تست فشار (Stress Test) و تست پذیرش (Acceptance Test) و بسیاری دیگر اشاره کرد.

در واقع انواع مختلف تستهای یک سیستم، خود گویای مفهوم (Separation of Concerns) است. اما هدف من از نگارش این مطلب طرفداری از ایده انجام تستهای مختلف به صورت مجزاست. هر چند با توجه به ماهیت برخی از گونه های تست اصولا نمی توان آنها را با هم اجرا کرد (مثل Unit Test و User Acceptance Test) اما برخی دیگر را می توان به صورت همزمان انجام داد (مثل تست عملکرد برنامه و واسط کاربری).

ایده اصلی این است:

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

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

تفاوت ها و شباهت های محیط کاری - تهران تا سیدنی (پاسخ به دوستان)

softwaring — Wed, 21 Oct 2009 06:06:14 GMT

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

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

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

مقایسه بازار کار Net. و Java در استرالیا و ایران:

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

تقسیم وظایف و سطح انتظار کارفرما از اعضای تیم:

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

نظر دو دوست دیگرم را اینجا و اینجا بخوانید.

روال کاری و متدولوژی مورد استفاده:
در این مورد نیز تفاوت زیادی احساس نمی کنم. در اینجا نیز بسیاری از امور شفاهی است و تنها موارد لازم مستند سازی می شود. مستندات زیر را بیشتر دیده ام: تعریف کار (Statement of Work) مشخصات نرم افزار (SRS)، مستند معماری، نصب و راه اندازی (Deployment) و راهنمای کاربر (User's Manual). البته هر شرکت و تیم نرم افزاری دیسیپلین های مخصوص خود را دارد و نمی توان قضاوت کلی داشت.

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

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

اخذ مدارک تخصصی نرم افزار (سوال در مورد مدارک Microsoft بود):

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

نسخه های جدید نرم افزارها:

در این مورد هم اطلاعات دقیقی پیدا نکردم اما با اطمینان می گویم در ایران بچه های نرم افزارچی (!) خیلی سریعتر آخرین نسخه های نرم افزارها را نصب و ته و توی آنرا در می آورند!

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

مهاجرت نامه

مهندس ارنست

تفاوت ها و شباهت های محیط کاری - تهران تا سیدنی (3)

softwaring — Tue, 20 Oct 2009 03:23:34 GMT

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

به عنوان یک نمونه واقعی: شرکت ما به عنوان پیمانکار، مسئول ایجاد لایه ای تحت عنوان گذرگاه سرویس های سازمانی (Enterprise Service Bus) برای یک شرکت حمل و نقل دریایی به عنوان مشتری است. وظیفه این گذرگاه ایجاد بستری است سرویس گرا که تقریبا کلیه نرم افزارهای سازمان (که چه از بعد تکنولوژی و چه از بعد فرآیندهای تجاری ناهمگون هستند) را به نوعی به هم متصل و قابلیت تعامل و حتی ایجاد چرخه کاری (Work Flow) را میان آنها فراهم سازد. جالب است بدانید که بودجه اجرای چنین پروژه ای بالغ بر چند میلیون دلار است و بیش از یک سال زمان لازم است که گذار به این معماری در چند فاز پیاپی به طول کامل انجام شود.

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

به عنوان مثال، نرم افزار تحت وب یکی از بانکهای معتبر استرالیا (ANZ) ظاهری بسیار ساده داشته و یا بسیاری از فرم های اینترنتی که تاکنون پر کرده ام در بسیاری از موارد از یک Text Box ساده و فاقد Validation های پیچیده بهره می برد.

به عنوان مثالی دیگر، یکی از نرم افزارهایی که در حال حاضر مشغول توسعه آن هستیم یک Desktop Application داخل سازمانی برای ثبت اطلاعات کشتی های باری و تخلیه و بارگیری آنهاست. گاهی تعجب می کنم که انتظار مشتری از خصوصیات ظاهری تا چه اندازه پایین است و حتی در مورد عملکرد نرم افزار (Functionality) تنها به نیازمندیهای اساسی و لازم نرم افزار اکتفا شده و از درخواست موارد جانبی پرهیز می شود. همان مفهوم "به قدر کفایت (Good Enough)"!

دمی درنگ

softwaring — Wed, 14 Oct 2009 13:37:38 GMT

تعبیر دیگری از مطلب پیشین:

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

(این جملات از خودم بود!)