Java EE Tutorials by Creativity on Youtube

Java Server Faces Tutorial 1 - Introduction / Setup

Java Server Faces Tutorial 2 - First Project

Java Server Faces Tutorial 3 - Simple Form / Navigation Rules

Java Server Faces Tutorial 4 - Managed Bean

Java Server Faces Tutorial 5 - Ajax in JSF

Java Server Faces Tutorial 6 - Calling Method in JSF

Java Server Faces Tutorial 7 - Including another JSF File

Java Server Faces Tutorial 8 - User Interface Components in JSF

Hibernate Tutorial 1 - Setup / First Project

Hibernate Tutorial 2 - Saving data into Database

Hibernate Tutorial 3 - Getting Records from Database

چرا به اپکس نه میگم ؟

یکی از دوستان وبلاگ انتقاد کردن که چرا واسه تولید اپلیکیشن از Oracle APEX استفاده نمی کنید و به Oracle ADF گیر دادین ؟

Oracle APEX واسه تولید اپلیکیشن خیلی سریع و عالیه ولی میدونی چیه ؟ همیشه اینجوری نیست که تو هر سازمان یا هر شرکتی که بری , کار اینقدر شسته و رفته باشه و بگن بیا از اول واسه ما یک سیستم جامع تولید کن. مثلاً اطلاعات پرسنلی رو باید از یک برنامه بگیری که بانکش اکسسه و یا اطلاعات فروش رو باید از یک برنامه بگیری که بانکش اس کیو اله . و شما قراره یک سیستم محاسبه پورسانت یا عملکرد بنویسی که قراره اطلاعاتش رو از این دو تا سیستم بگیره و به پرسنل امتیاز بده و پورسانت محاسبه کنه و در نهایت مبلغ پورسانت پرداختی به یک شخص رو به نرم افزار مالی مثل همکاران سیستم بفرسته .

Oracle APEX این جور جا ها کم میاره ومثل یک جعبه سیاه عمل میکنه و تو نمیدونی تویه این جعبه چه خبره . درحالیکه Oracle ADF :

1.در لایه بیزنس از Entity Object و View Object و Application Module استفاده میکنه  

2.در لایه کنترل task flow که اونم یک فایل xml است رو داریم .

3.در لایه ویو هم JSF رو داریم .

4.پس از تولید فایل ear و نصب آن در اپلیکیشن سرور وب لاجیک میشه برنامه رو در اختیار مشتری قرار دارد.

به خودم میگم , وقتی یک مسأله ای رو نمیفهمی نیا کل صورت مسأله رو پاک کن . این لایه بندی واسه اینه که Performance  اپلیکیشنی که قراره روی یک بانک مثل اوراکل بیاد بالا خیلی بهتر باشه . کاملاً مشخصه که این روش سخت تره و تکنولوژی بالاتری هم داره و هزینه تولید اپلیکیشن هم بالاتره .

برنامه نویسی ایرانی

یک از دوستان برنامه نویس من تویه انبار مرکزی شرکت ... کار میکرده و برای این انبار برنامه خیلی جالبی رو با ASP.NET و JAVASCRIPT و Telerik و MSSQL2008 نوشته بود و پروسه های ثبت سفارش , تخصیص سری ساخت به سفارش , صدور خروجی , الگوریتم FEFO و گزارشات متنوعی رو آماده میکنه .

بواسطه این برنامه تویه سازمان و در بین پرسنل انبار کلی اعتبار و امتیاز پیدا میکنه . مدت زمان اجرای این برنامه حدود 2 سال میشه و از دیتا برنامه مشخصه که در سال 2011 و ابتدای 2012 عملکرد خیلی خوبی داشته .

چندی بعد مدیر عامل سازمان صلاح می بینن که دوست من در جاهای دیگه سازمان هم مفید باشه ولی دوست من منافع خودش رو در خطر می بینه و همانطور که در تصویر ضمیمه به ایمیل مشخص شده است , از مورخ 12/04/2012 در بانک اطلاعاتی برنامه انبار خرابکاری های موجود در تصویر زیر صورت گرفته است .

 این خرابکاری در برنامه انبار باعث شده است که برنامه , فقط امکان نمایش اطلاعات و فرم ها را داشته باشد و امکان ایجاد رکورد جدیدی وجود نداشته باشد . در تصویر ضمیمه مشخص است که , پس از اضافه شدن هر 10 رکورد , یک میلیون به عدد سیستم اضافه میشود و پس از مدتی دوباره سیستم خراب میشود.

 

 

بعد از این که مشکلات انبار بواسطه خراب شدن برنامه زیاد میشه ارزش و اهمیت دوست برنامه نویس من خیلی بالا میره ولی به چه قیمتی ؟ به این قیمت که یکی از آقایان همکار قدیمی که نتونسته مشکل برنامه رو حل کنه از شرکت استعفاء میده . به این قیمت که یک خانم برنامه نویسی که نمیتونه مشکل برنامه رو حل کنه اعتبار خودش رو از دست میده .در تصویر زیر جداول این برنامه مشخص شده است . با خودم میگم چرا باید تو برنامه ای که 20 تا جدول بیشتر نداره یک همچین کاری انجام بشه .

 

دارم فرهنگ کاری خودمون رو با فرهنگ کاری مرحوم Jef Raskin که از برنامه نویس های شرکت اپل بود مقایسه میکنم . راسکین پس از آن‌که دریافت زندگیش دیری نخواهد پایید و بیماری به‌زودی او را از پا درخواهد آورد، به‌طور شبانه‌روزی به کار روی آرچی پرداخت و توانست طراحی‌های کلی، برنامه‌نویسی و ساخت موسیقی برای آن را به انجام برساند و ده روز قبل از فوت خود، به یکی از دوستانش گفت: اگر مردم شانس کار کردن با آرچی را بیابند و بدانند که کارکردن با آن چه‌قدر آسان است، بسیار آسان‌تر از چیزی که تاکنون وجود‌‌داشته، آن‌گاه مشتاقانه از آن حمایت خواهند کرد.