ارائه توسط: Michael Plöd
مترجم: محمد علی بزرگ زاده 1393/04/20
در این اپیزود، Arno با Michael Plöd در ارتباط با Object Relational Mappers یا OR Mappers مصاحبه می‌‌کند.
Michael لطفاً خود را معرفی کنید.
سلام، از اینکه به این مصاحبه SE Radio گوش می‌دهید ممنونم. نام من Michael Plöd است. من برای شرکت Senacor Technologies در نورمبرگ آلمان کار می‌کنم. نقش من توسعه‌دهنده ارشد یا معمار (هر چه اسمش را بگذارید) است. معمولاً بر روی پروژه‌های طولانی‌مدت تر کار می‌کنم. چند سال پیش کار با نگاشت‌گرهای OR را آغار کردم. بیشتر با نگاشت‌گرهای مبتنی بر جاوا از قبیل Hibernate و JDO و امروزه JPA کار کرده‌ام. خوشحال می‌شوم که سئوالات شما را بشنوم و امیدوارم بتوانم به آنها جواب دهم.
بیایید با این سئوال شروع کنیم که نگاشت‌گر OR چیست؟ درباره چیست؟
اساساً نگاشت‌گر OR چیزی است که به مسأله عدم تطابق بین اشیاء با روابط می‌پردازد. بین یک نرم‌افزار شیء‌گرا و پایگاه‌های داده یک عدم تطابق طبیعی وجود دارد. بعنوان مثال اگر به نحوه گروه کردن اشیاء یک حوزه (Domain) در مقابل نحوه تعریف کردن شِمای رابطه‌ای (Schema) نگاه کنید، بوضوح می‌بینید که از یک طرف با کلاس‌ها و خواص (Attribute) کار می‌کنید و نوع‌های داده‌ای دارید که یا مربوط به زبان برنامه‌نویسی است یا انواع داده‌ای است که خودتان داخل زبانی که با آن کار می‌کنید، تعریف می‌کنید. اما در طرف دیگر با جداول و ستون‌ها کار می‌کنید و این چیزها را داخل شِماها، گروه می‌کنید. در یک پایگاه داده رابطه‌ای نیز یک سیستم انواع داده دارید. اما در غالب پایگاه‌های داده این سیستم انواع داده خیلی استاتیک است. البته برخی از پایگاه‌های داده، گونه‌هایی از پشتیبانی انواع‌های داده تعریف شده توسط کاربر را دارند. اما اغلب این پشتیبانی خیلی پیشرفته نیست.
مطلب دیگر، جابجا شدن (Navigation) است. وقتی در گرافی از اشیاء جابجا می‌شوید، در یک نرم‌افزار شیء گرا یا کلاً در نرم‌افزار می‌دانید که چطور از یک موجودیت (Entity) مثلاً موجودیت A به سمت موجودیت B جابجا شوید. اما در طرف دیگر (در پایگاه‌های رابطه‌ای)، جابجایی، جهت ندارد. می‌توانید از جدول مشتریان به جدول صورتحساب‌ها جابجا شوید اما در همان حال می‌توانید از طریق کلید خارجی (Foreign Key) از جدول صوتحساب‌ها به جدول مشتریان هم جابجا شوید. بنابراین می‌بینید که یک مسیر جابجایی وجود ندارد.
بسیار خوب، اما برای دسترسی به داده‌ها، زبان برنامه‌نویسی SQL را دارید. چرا به نگاشت‌گر OR نیاز دارید؟ مزیت استفاده از یک نگاشت‌گر OR بر روی SQL نسبت به استفاده از تکنولوژی‌هایی که برای دسترسی مستقیم به پایگاه داده در زبان‌های برنامه‌نویسی وجود دارد، چیست؟
اساساً از یک نگاشت‌گر OR برای کپسوله کردن پایگاه داده استفاده می‌کنید. خیلی از شرکت‌ها می‌گویند که با استفاده از نگاشت‌گر OR می‌توانید بسادگی بین پایگاه‌های داده مختلف سوییچ کنید. بله، این درست است. اما من می‌گویم که در اکثر پروژه‌های شرکت‌های بزرگ، سوییچ کردن به یک پایگاه داده دیگر، چیز خیلی نادری است. فکر می‌کنم مورد کاربرد و مزیت اصلی استفاده از یک نگاشت‌گر OR این است که توسعه‌دهندگان با اشیاء کار کنند و مقدار زیادی کدهای منطق کسب و کار (Business Logic) ننویسند که اغلب مربوط به پردازش دستورات SQL باشد.
بعلاوه، کتابخانه‌هایی که تعامل با SQL را پیاده‌سازی می‌کنند، خیلی سطح پایین هستند. بعنوان مثال اگر به JDBC، دقت کنید، یک کتابخانه سطح پایین است که در آن با دستورات و ResultSet ها کار می‌کنید و می‌بایست بر روی نتایج حرکت کنید و خیلی از امور مربوط به مدیریت منابع (Resource Management) را انجام دهید. از این منظر، نگاشت‌گر OR کاملاً این چیزها را کپسوله می‌کند. (در آنجا) با فایل‌های XML، یا Annotation ها یا حتی از طریق قراردادهای نامگذاری (Code Convention)، گونه‌هایی از متادیتا را دارید که بوسیله آنها، توضیح می‌دهید که چطور کلاس‌هایتان را به جداول‌ نگاشت می‌کنید و توضیح می‌دهید که چطور ارث‌بری و روابط یا چیزهای دیگر را نگاشت می‌کنید.
ادامه مطلب ...

ارائه توسط: Rich Hickey
مترجم: جهانگیر زین‌الدین 1393/04/01
این بار ما می‌خواهیم در مورد Clojure صحبت کنیم. مهمان ما آقای Clojure، ریچ هیکی است.
لطفاً قبل از صحبت در مورد آنچه که ساخته اید، در مورد خودتان حرف بزنید.
خوب من ریچ هیکی هستم و Clojure را نوشته‌ام. این زبان، یک زبان برنامه نویسی دینامیک است که روی JVM و CLR (ماشین مجازی مایکروسافت برای اجرای کدهای دات نت) اجرا می‌شود. Clojure چهار ویژگی اصلی دارد: اول اینکه یک زبان مبتنی بر Lisp است. دیگر اینکه طوری طراحی شده که توسط یک ماشین مجازی میزبانی شود بنابراین رابطه صمیمانه‌ای با پلتفرم میزبان دارد. ویژگی دیگر این است که عمدتاً Functional (مبتنی بر توابع) است و روی تغییر ناپذیری و توابع محض و ساختمان داده‌های تغییر ناپذیر تاکید دارد. ویژگی بعدی این است که روی همزمانی متمرکز است و تمام جنبه های زبان طوری طراحی شده‌اند که در متن یک برنامه همزمان، معنای (Semantic) درستی داشته باشند.
بعداً در مورد آن بیشتر کنکاش خواهیم کرد اما قبل از آن می‌خواهم خوانندگان بدانند که ما قبلاً برنامه‌ای در مورد Lisp داشته ایم: برنامه شماره ۸۴ با گابریل. در اینجا ممکن است در مورد مقدمات Lisp به صورت مختصر صحبت کنیم، اما به خاطر ضیق وقت بنا نداریم معرفی کاملی از Lisp ارایه کنیم. اگر با Lisp، لااقل به صورت کلی آشنا نیستید می‌بایست به برنامه ۸۴ رجوع کنید. ریچ، علیرغم این به نظرم فکر خوبی است اگر Lisp را به صورت اجمالی معرفی کنید. مبانی اصلی Lisp چه هستند؟ چه تفاوتی با زبانهای برنامه نویسی دیگر دارد که به خاطر آن از نظر بسیاری افراد یک زبان خاص تلقی می‌شود؟
خوب، سوال آخر احتمالاً بهترین سوال است. بسیاری از چیزها که Lisp ابداع کرده است در زبان های دیگر نیز به صورت گسترده وجود دارد. فکر می کنم آنچه که Lisp رامنحصر به فرد می‌کند، این است که برنامه به صورت ساختمان داده به کامپایلر عرضه می‌شود، پس کامپایلر Lisp، متن را کامپایل نمی‌کند بلکه ساختمان داده‌ها را کامپایل می‌کند، و زمانی که شما با Lisp یا Clojure برنامه ای می‌نویسید در واقع با ساختمان داده‌ها و از طریق آنها برنامه می‌نویسید. اگر شما متنی را در فایلی ذخیره می‌کنید در واقع داده‌های عینی زبان، را ذخیره می‌کنید.
پس تفاوت این با زبانهایی که برنامه را ترجمه می‌کنند و از روی آن AST می سازند (که به نوعی یک ساختمان داده است که به کامپایلر عرضه می‌شود) چیست؟
این موضوع خیلی مرتبط است با اینکه آیا آن AST از چیزهایی ساخته شده که برنامه شما معمولاً با آن سر و کار دارد یا خیر. در یک برنامه Lisp و به طور خاص در Clojure، داده‌های عینی زبان، چیزهایی هستند که شما به صورت روزمره از آنها استفاده می‌کنید: vector، map و list. پس کتابخانه بزرگی برای کار با آنها وجود دارد. آنها کتابخانه های معمولی متعلق به زبان هستند و اینطور نیست که کتابخانه‌های خاصی برای کار با AST داشته باشید و لازم نیست برنامه خاص یا عجیبی برای دستکاری AST بنویسید.
پس می‌توان گفت برنامه نویسی و فرا-برنامه نویسی (Meta programming) هر دو یک چیز هستند!
دقیقاً، تفاوتی وجود ندارد، و این بسیار مهم است، اگر شما قبلاً با کتابخانه ای مربوط به AST کار کرده باشیدکه شیءگرا بوده باشد، می‌فهمید که دارید یک API خاص را می خوانید، اما زمانی که کد مربوط به یک ماکرو را در Lisp یا Clojure می‌خوانید کدهای کاملاً معمولی برای پردازش دادها هستند.
خوب شما از چه ساختمان داده‌های دیگری که پیشتر در مورد آنها صحبت کردید، استفاده کرده‌اید؟ چون Lisp به نظر فقط لیست های تو در تو است، درست است؟
این برای Lisp به صورت سنتی درست است، اما در Clojure چندین ساختمان داده دیگر وجود دارد که همگی در اولویت بالایی قرار دارند و مانند لیست درجه یک محسوب می شوند. این ساختارها، vector و map (که مشابه جداول درهم سازی (hash table) است) هستند. در نحو زبان فرم‌هایی وجود دارند که بر مبنای همین ساختمان داده‌ها ساخته شده‌اند، گاهی مبتنی بر vector ها و گاهی mapها.
شما می دانید و در برنامه ۸۴ هم آمده که Lisp زبان جدیدی نیست و یک رویکرد قدیمی است و در زمینه های خاصی با موفقیت مورد استفاده قرار گرفته است اما هیچگاه یکی از زبانهای اصلی مورد استفاده عموم نبوده است. شما چه فکری می‌کنید،‌ چرا این اتفاق نیافتاده است؟ و سوال بعدی اینکه چرا شما در سال ۲۰۰۹ یا ۲۰۱۰، Lisp خودتان را ساختید؟
(با خنده!) اینها دو سوال مجزا هستند. من مطمئن نیستم که Lisp برای استفاده عموم طراحی شده باشد، آن زمان که بوجود آمده برای کاربران ارشد طراحی شده مانند محققین و افراد بسیار باهوش که سعی می کردند مسایل بسیار سخت را حل کنند و Lisp اهرم کاملاً مناسبی برای تلاشهای آنها بود. به عنوان یک فرد شما قدرت باورنکردنی ای به واسطه Lisp داشتید.
ادامه مطلب ...

ارائه توسط: Christof Ebert
مترجم: محمد علی بزرگ زاده 1393/03/04
در این اپیزود با Christof Ebert در مورد Lean و 5 اصل آن یعنی «ارزش‌آفرینی»، «حذف هدررفت‌ها»، «بهینه‌سازی زنجیره ارزش»، «قدرت‌بخشی به افراد» و «بهبود مستمر» گفتگو می‌شود. او مقاله‌نویس مجله مهندسی‌ نرم‌افزار IEEE است و از مدیران شرکت خدمات مشاوره Vector است.
Christof، آیا ممکن است خود را معرفی کنید.
سلام. من Christof Ebert هستم. من یکی از مدیران شرکت خدمات مشاوره Vector هستم. ما به مشتریان‌مان درسراسر دنیا کمک می‌کنیم که بصورت پایدار، استراتژی‌های مربوط به محصول، توسعه محصول و مدیریت تغییرات سازمانی را بهبود دهند. خدمات مشاوره Vector بخشی از گروه Vector است که در کل جهان، 1100 کارمند دارد و در همه قاره‌ها خدمات دارد. پیش از کار کنونی‌ام، من چندین سمت در مدیریت‌های جهانی داشتم.
من در تعدادی از مشاوره‌های صنعتی شرکت داشته‌ام و درس‌هایی هم در دانشگاه Stuttgart و دیگر دانشگاه‌ها ارائه کرده‌ام. در سال‌های گذشته چند مورد کتاب پرفروش نیز داشته‌ام. آخرین کتابم، Global Software & IT است که توسط WILEY و IEEE انتشار یافته است. در این گفتگو، نگاهی به توسعه Lean خواهیم داشت و اینکه چطور Lean در نرم‌افزار و IT به خدمت گرفته شده است. اغلب Lean، به تولید کارخانه نسبت داده می‌شود. ما قواعد آن و اینکه چطور در پروژه‌های نرم‌افزاری و IT بکار گرفته می‌شوند را بیان می‌کنیم. برای این منظور، به آخرین شماره مجله نرم‌افزار IEEE ارجاع می‌دهیم. در آنجا ما تعدادی مطالعه موردی درباره به خدمت گرفتن Lean در نرم‌افزار و IT داشته‌ایم.
بسیار خوب. من فکر می‌کنم خیلی از شنوندگان ما با موضوع Agile در حوزه مهندسی نرم‌افزار آشنا هستند. اما شاید خیلی با موضوع توسعه نرم‌افزار با رهیافت Lean آشنا نباشند. آیا می‌توانید خصوصاً برای کسانی که با Agile آشنا هستند، ارتباط Lean و Agile را تصویر کنید؟ آیا خیلی مشابه هم هستند؟ تفاوت‌ها و مشترکاتشان چیست؟
اخیراً Lean، توجه زیادی را جلب کرده است زیرا بخوبی توانسته است بین نیاز به ارزش‌آفرینی و نیاز به قدرت بخشیدن به افراد و تیم‌ها و حرکت کردن در جهت یک محصول خلاقانه، تعادل برقرار کند. توسعه به روش Lean یک اصل مهم برای کمک به شرکت‌هایی است که گهگاه در بهبود بازده خود مشکل دارند.
منظورتان این است که Agile برای پروژه‌های خاص است اما Lean بیشتر یک فلسفه و یک امر کلی است؟
فکر می‌کنم مناسب باشد برخی نقاط تمایز را ببینیم. من نمی‌خواهم برای مجزا کردن این دو تکنیک روش خیلی سیاه و سفیدی داشته باشم. این دو با هم مرتبط هستند و همدیگر را تقویت می‌کنند. قطعاً متضاد یکدیگر نیستند. اینطور نیست که یا می‌بایست Lean باشیم یا Agile. در ادامه Lean را تعریف خواهیم کرد و به تکنیک‌های کلیدی آن نگاهی می‌اندازیم. آن زمان، ساده‌تر می‌توانیم مسأله را متوجه شویم. اما فعلاً می‌توانم بگویم که این دو تکنیک همدیگر را تقویت می‌کنند و همانطور که پیش از این گفتم، ارزش‌آفرینی، یک فصل مشترک این دو است.
شما اگر بخواهید می‌توانید ارزش را به روش پایین به بالا ایجاد کنید. نگاه می‌کنید که کارها را چطور انجام می‌دهید و چطور می‌توانید آنها را بهتر انجام دهید. مثلاً اینکه چطور می‌توانید در کد زدن، کارایی بیشتری داشته باشید یا چطور می‌توانید از همان ابتدا از خطاها جلوگیری کنید. شما می‌دانید برای این منظور، چیزی با عنوان TDD داریم که یک تکنیک Agile است که قبل از آنکه کد را بنویسید فکر می‌کنید که چطور آن را تست خواهید کرد. با این نوع روش فکر کردن در مورد ارزیابی قبل از نمونه‌سازی، جلوی خیلی از خطاها را می‌گیرید.
همین تکنیک در سطح محصول هم استفاده می‌شود مثلاً اینکه آیا این ویژگی را در چنین بازاری نیاز داریم یا اینکه فقط یک سربار ایجاد می‌کند؟ این همان چیزی است که آن را توسعه Lean می‌نامیم. اینجا می‌خواهم بصورت شفاف تأکید کنم که این دو تکنیک همدیگر را تقویت می‌کنند و اینطور نیست که مسأله، انتخاب یکی یا دیگری باشد.
ادامه مطلب ...