محبوبترینها
چگونه با ثبت آگهی رایگان در سایت های نیازمندیها، کسب و کارتان را به دیگران معرفی کنید؟
بهترین لوله برای لوله کشی آب ساختمان
دانلود آهنگ های برتر ایرانی و خارجی 2024
ماندگاری بیشتر محصولات باغ شما با این روش ساده!
بارش‌های سیل‌آسا در راه است! آیا خانه شما آماده است؟
بارش‌های سیل‌آسا در راه است! آیا خانه شما آماده است؟
قیمت انواع دستگاه تصفیه آب خانگی در ایران
نمایش جنگ دینامیت شو در تهران [از بیوگرافی میلاد صالح پور تا خرید بلیط]
9 روش جرم گیری ماشین لباسشویی سامسونگ برای از بین بردن بوی بد
ساندویچ پانل: بهترین گزینه برای ساخت و ساز سریع
خرید بیمه، استعلام و مقایسه انواع بیمه درمان ✅?
صفحه اول
آرشیو مطالب
ورود/عضویت
هواشناسی
قیمت طلا سکه و ارز
قیمت خودرو
مطالب در سایت شما
تبادل لینک
ارتباط با ما
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
آمار وبسایت
تعداد کل بازدیدها :
1845764083
مصاحبه با قهرمان جاوا
واضح آرشیو وب فارسی:ايتنا: مصاحبه با قهرمان جاوا
چيزي كه در طول ساليان آموختهام به من ميگويد كه قبل از عمليات تست كارآيي (Profile) هرگز نبايد به موضوع بهينهسازي كد پرداخت. برنامهنويس عموما از پرداختن به مسائلي همانند استفاده از حافظههاي مياني (Caching)، تفكيك لايه‌ها و از اين گونه به دردسر مي‌افتد در حالي كه اين موارد اصولاً تاثير قابل ملاحظه‌اي در كارآيي نهايي كد نخواهد داشت و فقط عمليات خطايابي (Debugging) را مشكل‌تر مي‌كند.
مصاحبه با قهرمان جاوا
جاوا از بهبود تا يادگيري
شهرام انسان- دنياي كامپيوتر و ارتباطات
در سال نو و با نگاهي به گذشته جاوا كه در مقاله شماره قبل ارائه شد، در اينجا از گفت‌وگويي دوستانه با «كِي هورستمن» (Cay Horstmann) از بزرگان جاوا بهره خواهيم برد و با نقطه نظرات وي در زمينه‌هاي مختلف جاوا آشنا خواهيم شد. اگرچه ممكن است بحث به نقاط فني سركي بكشد، اما شنيدن اين گفت‌وگو براي كم آشنايان با جاوا نيز خالي از لطف نخواهد بود.
«كي هورستمن» در شمال آلمان متولد و در دانشگاه آلبرخت شهر كيل تحصيلات خود را آغاز و نهايتاً از دانشگاه ميشيگان آمريكا به درجه PHD رسيد. وي هماكنون در دانشگاه ايالتي سنجوز در كاليفرنيا در رشته علوم كامپيوتر به تدريس مشغول است و در سال 2005 ميلادي به درجه قهرمان جاوا! (Java Champion) رسيد. هورستمن عضو گروه نويسندگان هسته جاوا و هسته JSF بوده و هم اكنون در پروژه Enterprise Java for Elvis مشغول بوده و نقش به سزايي در گنجاندن دروس برنامهنويسي جاوا در دوره‌هاي درسي دبيرستاني علوم كامپيوتر در آمريكا داشته است. هورستمن علاوه بر آن كار مشاوره در زمينه راهكارهاي مبتني بر اينترنت را نيز به صورت حرفه‌اي ادامه مي‌دهد. در زير گفت‌وگوي «جانيس هيس» خبرنگار java.sun.com را با هورستمن مي‌خوانيم.
• زماني كه از هانس كابوتز (Heinz Kabutz) يكي از بزرگان جاوا در مورد بزرگ‌ترين اشتباه برنامه‌نويسان جاوا پرسيده شد، وي به نقص در تست واحد (Unit test) اشاره نمود. هانس بيان داشت كه در كنفرانسي متشكل از برنامه‌نويسان جاوا پرسيدم كه چند نفر از شما تست واحد را به درستي و كامل انجام مي‌دهيد و هيچ دستي بلند نشد! نظر شما چيست؟
البته من هم اگر در آن جمع بودم حتماً دست خودم را بلند نمي‌كردم! من تست واحد را به صورت اتفاقي آن هم براي مواردي كه خطايي رخ داده باشد و براي جلوگيري از تكرار آن انجام مي‌دهم. البته جاي شگفتي است كه گروه بزرگي از برنامه‌نويسان تست واحد را انجام نمي‌دهند. شايد آنها به قدري متخصص هستند كه كدشان هرگز به خطا برنمي‌خورد. به نظر من نقطه صحيح جايي بين استفاده كامل يا بدون استفاده از تست واحد است.
• در سوالي از برايان گوتز (Brian Goetz) كليد برنامهنويسي سريع كد جاوا پرسيده شد. به نظر وي برنامهنويس بايد به توليد كدي ساده بسنده كند. بنا بر اعتقاد وي كد تميزي كه دنباله‌رو اصول اوليه شي‌گرايي بوده و بتواند به صورت بهينه در كمپايلر (Compiler) جاوا كمپايل شود، مطلوب است. از آنجايي كه كمپايلر با بهترين الگوها بهينه شده است براي دستيابي به بهترين نتيجه، كدي مطلوب است كه ساده‌تر بوده و در الگوهاي عمومي كدنويسي بگنجد. به نظر گوتز كدهاي پيچيده و هوشمندانه، هكرانه و از اين قبيل؛ خروجي مناسبي از كمپايلر نخواهند داشت. شما چه فكر مي‌كنيد؟
من با برايان موافق هستم. چيزي كه در طول ساليان آموختهام به من ميگويد كه قبل از عمليات تست كارآيي (Profile) هرگز نبايد به موضوع بهينهسازي كد پرداخت.
برنامهنويس عموما از پرداختن به مسائلي همانند استفاده از حافظههاي مياني (Caching)، تفكيك لايه‌ها و از اين گونه به دردسر مي‌افتد در حالي كه اين موارد اصولاً تاثير قابل ملاحظه‌اي در كارآيي نهايي كد نخواهد داشت و فقط عمليات خطايابي (Debugging) را مشكل‌تر مي‌كند. گذشته از آن من مخالف آن هستم كه تمام تيم توليد در هر سطح از دانش به فراگيري الگوهاي طراحي و برنامهنويسي بپردازند.
الگوهاي برنامهنويسي مسلما جزء با ارزشي از دانش يك برنامهنويس محسوب مي‌شود اما برنامه‌نويسان مبتدي مي‌بايست به تدريج با اين الگوها آشنا شده تا هنر بكارگيري آنها را در جاي صحيح بياموزند. الگوها به تنهايي كليد جادويي موفقيت نيستند و استفاده صحيح از آنها به مراتب نتايج بهتري را در پي خواهد داشت.
• وخيم‌ترين اشتباهاتي كه برنامه‌نويسان در توليد كد JSF (Java Server Faced) و در مقوله توليد وب انجام مي‌دهند، كدام است؟
من قصد ندارم برنامه‌نويسان را در ضعف‌هاي چارچوب توليد وب JSF يا در قسمت برپاسازي آن (Deployment) مقصر بدانم. عمده‌ترين مطلب در زمينه توليد با JSF شايد مشكل دنبال نمودن خطا در آن باشد. اگر برنامهنويس يك خطاي تايپي ساده در قسمت‌هاي مختلف كد پروتوتايپ يا صفحات JSF مرتكب شود، محيط برنامهنويسي وي (IDE) ممكن است قادر به پيدا كردن اين اشتباه نباشد. علت آن عدم طراحي JSF براي بررسي خطاهاي موجود در صفحات و پروتايپ‌ها در زمان كمپايل است. به همين ترتيب زمان برپاسازي برنامه ممكن است حجم بالايي از stack-trace خطا ظاهر شود كه وضعيت Application Server شما را بيان مي‌كند. در اين زمان نياز به كمي غيب‌گويي (!) وجود دارد كه برنامهنويس تشخيص دهد خطا مربوط به كدام قسمت از كد پروتوتايپ يا صفحه JSF بوده‌است. نياز فوق فراتر از انتظار از حد يك برنامهنويس ساده است.
اما مقصر كيست؟ در مرحله اول توليدكنندگان كتابخانه‌هاي JSF كه stack-trace مناسب و مشخصي از حالت‌هاي رويداد خطا طراحي و توليد نكرده‌اند.
در مرحله دوم نويسندگان Application Serverها مقصر هستند. آنها با بيان اين توجيه كه محصول آنها براي برپاسازي است نه گذراندن موفق مراحل توليد، در هنگام رخداد خطاي ناشي از اشتباه برنامهنويس، فقط stack-trace كلي خطا را بيرون داده و هيچ راهي براي شناسايي فايل مربوط به توليد خطا يا شماره خط رخداد خطا در كد را به دست نمي‌دهند. البته اين امر در محيط برنامهنويسي Netbeans با ارائه سرنخ‌هايي از رخداد خطا كمي تسهيل شده است. البته اگر فرض كنيم كه كمپايلر هم در وضعيت Application Server قرار مي‌گرفت و برنامهنويس كم دقت خطاهاي بسياري در كد صفحات به جاي مي‌گذاشت. در آن صورت با رخداد هر كدام از آن خطاها، اجراي برنامه خاتمه يافته و در نهايت محصولي توليد نمي‌شد. اين مورد، مشكلي اساسي در JSF است.
• بنابراين برنامهنويس با JSF به گمراهي كشيده نمي‌شود؟!
من در اينجا دو مشكل مي‌بينم. اول اينكه در توليد برنامه‌هاي تحت وب، راه ديگري براي جداسازي كد از نمايش وجود ندارد. در JSF با كمي مشكلات مي‌توان كد را به صفحات JSP ربط داد. تجربه نشان مي‌دهد كه هر زمان كد جاوا به صورت مستقيم (اسكريپلت) يا حتي به صورت JSTL در JSP وارد شود، نتيجه يك كد ناخوانا و بسيار مشكل‌ساز است.
پيشنهاد من بكارگيري صفحات خالص JSF با تكنيك‌هاي خاص خود، بدون وارد نمودن كد مستقيم جاوا در آنهاست. دوم اينكه معمولاً بيشتر دردسرها از قسمت ارتباطي لايه وب با ساير لايه‌ها مانند كد مربوط به ارتباط با بانك اطلاعاتي مانند Session Beanها در EJBهاست. پيشنهاد من بكارگيري جايگزين‌هاي ساده‌تر به جاي آنها همانند Seam است.
• خطرناك‌ترين اشتباهاتي كه برنامه‌نويسان جاوا در كد زدن با تِرِدها (Thread) مي‌كنند در كدام قسمت است؟
مجددا تاكيد مي‌كنم، اين درست نيست كه برنامهنويس را در مواردي كه نقص در ذات طراحي نهفته است مقصر دانست. به قول برايان گوتز جاوا به ابزاري شبيه به Garbage collector كه پاكسازي حافظه را انجام مي‌دهد، براي برنامهنويسي تردها نياز دارد. شايد گروهي از برنامه‌نويسان رنج مديريت حافظه در كد C و C++ را به خاطر بياورند. بنابراين بزرگ‌ترين اشتباه اين است كه در برنامهنويسي ترد، به صورت عادي از منابع سيستم استفاده كنيم. از به اشتراك گذاري داده‌ها بپرهيزيم، از ساختارهاي مطمئن داده در ارتباطات بين تردها استفاده كنيم و از اين قبيل. برايان كتاب كاملي در اين زمينه نوشته است.
• چه نصيحتي براي مبتديان داريد؟
اول اينكه وحشت‌زده نشوند! معمولاً دانش‌آموزان در ابتدا رابط برنامهنويسي پيچيده‌اي با هزاران كلاس مي‌بينند. من به آنها تاكيد مي‌كنم كه نكته مهم در اين است كه جاوا، زباني بسيار آسان است. مسئله دوم خود كد است. بيشتر برنامه‌نويسان حرفه‌اي فراموش مي‌كنند كه چقدر كد زدن براي مبتديان مشكل است. كد زدن برخلاف فعاليت‌هاي عادي روزمره است. كامپيوتر جايي براي بخشش در كد خطادار باقي نمي‌گذارد! در صورت نوشتن كد خطا بلافاصله با پيام خطاي مربوط به آن مواجه خواهيد شد. پس با هر خطا متوقف شده و نياز به فكركردن وجود دارد و راه‌حل‌هاي تصادفي كمتر به نتيجه خواهد رسيد. دعوت به سخت‌كوشي در دانش‌آموزان امروزي تاثير چنداني ندارد. با رخداد خطاهاي پي در پي ممكن است برنامهنويس به مرزي از افسردگي برسد و تنها در صورت رفع مشكل و به هدف رسيدن كد است كه افسردگي فوق برطرف مي‌گردد. در اين حالت بايد به مبتديان كمك نمود از مرحله سختي‌ها بگذرند.
• بزرگ‌ترين اشتباهاتي كه معلم‌هاي برنامهنويسي جاوا مرتكب مي‌شوند، چيست؟
سمينارهاي آموزشي خيلي طولاني هستند. به نظر من آموزش، بيش از مدت 50 تا 75 دقيقه بدون فرصت دادن به دانش‌آموز براي بررسي و مرور آموخته خود بيهوده است. اين روزها تمام شاگردان من لپ‌تاپ دارند، در ابتدا 15 تا 20 دقيقه آموزش داريم، بعد يك كار عملي با كامپيوتر؛ سپس يك آموزش كوتاه ديگر و يك آزمايش عملي مجدد و در نهايت 5 دقيقه زمان براي جمع‌بندي مطالب صرف مي‌كنيم.
• دوست داريد كه در نسخه آينده جاوا، يعني 7 چه چيزهاي جديد ببينيد؟ آيا شما به مخفف‌سازي (closures) در زبان اعتقاد داريد؟
بله من دوست دارم مخفف‌ها را ببينم. زماني كه من مخفف‌ها را در كلاس آموزش جاوا تدريس مي‌كنم، به روشني مي‌بينم كه ساختار املايي كد رابطه مناسبي با برنامهنويس برقرار نمي‌كند. دانش‌آموزان از اينكه متغيرهاي محلي گرفته شده با مخفف‌ها در طول كار معتبر باقي مي‌مانند بسيار شگفت‌زده مي‌شوند. در حالت كلي مخفف‌ها اين قدرت را به برنامه‌نويسان كتابخانه‌هاي جاوا مي‌دهد كه كد راحت‌تري براي برنامه‌نويسان نهايي فراهم سازند كه اين امر در امكانات گسترده‌اي كه در جاوا 5 به وجود آمد اضافه شد. به كمك آنها مي‌توان به طرز سحرانگيزي در كد، حاشيه‌نويسي (annotation) انجام داد. به نظر من بحث generic كارها را در جاوا بهتر نموده است ولي متاسفانه اين امر ممكن است تمام توجه يك برنامهنويس را به جزئيات كار جلب كند. اما در بيشتر موارد genericها راحت هستند و كارها را آسان مي‌كنند.
به نظر من خيلي بهتر است كه به جاي يك ليست ساده List يك ليست از جنس معين List داشته باشيم. اما چيزي كه دوست دارم در جاوا 7 يا 8 ببينم، تغييرات در نحوه تعامل در كنترل خطاهاست. به عنوان مثال كدي مشابه اين كد:
شكل 1
ديگر اينكه از نوشتن كلاس‌هاي Java Bean ساده و setter, getter براي تمام خصوصيات آنها خسته شده‌ام. گرامر مورد نظر من به جاي الگوي معمول چيزي شبيه به كد زير خواهد بود:
شكل 2
• چه كلاسي در زبان جاواست كه بدون آن نمي‌توانيد زندگي كنيد؟!
java.lang.Object ... !
• چه تغييراتي در چارچوب جاوا زندگي شما را شيرين‌تر مي‌كند؟
در حالت كلي generic، اما در حالت خاص من از بهبودهايي در گرامر كد كه به ساده‌تر شدن برنامهنويسي كمك مي‌كند خوشم مي‌آيد، مانند تغيير در ساختار كد مربوط به حلقه for در نسخه‌هاي اخير جاوا.
• ديدگاه شما در مورد تولد رو به ازدياد زبان‌هاي اسكريپ‌نويسي همانند Perl، PHP، Python، Groovy و Ruby چيست؟ آيا هر كدام از آنها كاربرد مخصوص به خود دارند؟
شما به درستي دست بر روي نقطه حساسيت‌هاي من گذاشتيد! به نظر من جالب است كه افراد به مقاصد آموزشي پژوهشي زبان‌هاي جديدي را بيافرينند و بياموزند. اما اين زبان‌ها در نهايت محكوم به نابودي هستند. چه مزيتي در بكارگيري همزمان زبان‌هايي كه نام برديد وجود دارد؟ من به عنوان يك برنامهنويس نياز به فراگيري و البته استفاده از يك زبان اسكريپت‌نويسي دارم، پرداختن به سايرين به نظر من وقت تلف كردن است. از ديدگاه زبان جاوا، Groovy بهترين كانديدا براي يادگيري است. Groovy ساختار گرامري شبيه به زبان جاوا دارد و يك پروتكل شبيه به اشياي جاوا كه دسترسي به Grails را ممكن مي‌سازد. با وجود آنكه طراحان آن زمان زيادي را براي طراحي صرف نموده‌اند، اما قسمت‌هاي فراواني از آن ضعف دارند يا حتي در حال تغيير هستند. به عنوان مثال فلسفه وجود Groovy MOP را به جز براي دسترسي به سورس كد Grails درك نمي‌كنم.
• در پايان، اگر موردي به نظرتان مي‌رسد كه در سئوالات عنوان نشده است، بفرماييد.
البته، مقايسه لحن موجود در وبلاگ‌هاي اختصاصي زبان C# با لحن جاري در وبلاگ‌هاي جاوايي غصه من شده است! بيشتر برنامه‌نويسان C# راجع به موهبتي دوست‌داشتني صحبت مي‌كنند كه از ردموند (مايكروسافت) برايشان نازل شده است كه آنها استفاده كنند و لذت ببرند. اما در دنياي جاوا دوستان برنامهنويس هميشه از ناقص بودن چيزي يا نياز به بهبود چيزي ديگر مي‌نويسند. اما آيا C# واقعاً آنچنان مخلوقي است كه هيچ كاربري از آن شكايت نمي‌كند؟ البته كه من اينطور فكر نمي‌كنم. اگر اينطور بود بيشتر مردم در يك انتخاب به استفاده از C# مي‌رسيدند!! به نظر من انجمن برنامه‌نويسان جاوا داراي يك فرهنگ سالم از گزارش ايرادات در جهت بهبود كار است.
همه اعضا در اين انجمن داراي خواسته و انگيزه براي بهبود اوضاع هستند، زيرا هر كدام در آن نقشي براي خود مي‌بينند، بر خلاف بي ارادگي موجود در C# براي پذيرش آنچه كه به آنها ديكته مي‌شود. در اينجا كسي منتظر Sun يا شركتي شبيه به آن براي برطرف‌سازي ايرادات نمي‌نشيند. ما در حال استفاده و اتصال هزاران پروژه و كتابخانه و چارچوب در جهت بهبود آنها و حتي ساختن زباني كامل‌تر هستيم. حركت جاوا به سوي سورس باز، گامي در جهت تحقق اهداف فوق براي سال‌هاي آينده است.
دوشنبه 30 ارديبهشت 1387
این صفحه را در گوگل محبوب کنید
[ارسال شده از: ايتنا]
[مشاهده در: www.itna.ir]
[تعداد بازديد از اين مطلب: 333]
-
گوناگون
پربازدیدترینها