شماره بیست: Networking
برخی از کتاب‌خانه‌های مفید جاوا در زمینه #شبکه عبارتند از #Netty و Apache #MINA. اگر در حال نوشتن اپلیکیشنی هستید که نیاز به کارهای شبکه‌ای سطح پایین دارید، می‌توانید از این کتاب‌خانه‌ها استفاده کنید.
#معرفی_کتاب‌خانه‌های_مفید_جاوا
@JavaCupIR
برخی از کتاب‌خانه‌های مفید جاوا در زمینه #شبکه عبارتند از #Netty و Apache #MINA. اگر در حال نوشتن اپلیکیشنی هستید که نیاز به کارهای شبکه‌ای سطح پایین دارید، می‌توانید از این کتاب‌خانه‌ها استفاده کنید.
#معرفی_کتاب‌خانه‌های_مفید_جاوا
@JavaCupIR
#مقاله
در این مقاله دو پیاده‌سازی مختلف از واسط Map یعنی HashMap و TreeMap با یکدیگر مقایسه می‌شوند.
هر دو پیاده‌سازی، بخش جدایی‌ناپذیری از چارچوب Java Collections هستند و داده‌ها را به صورت زوج‌های کلید-مقدار ذخیره می‌کنند.
https://goo.gl/4hgnGq
@JavaCupIR
در این مقاله دو پیاده‌سازی مختلف از واسط Map یعنی HashMap و TreeMap با یکدیگر مقایسه می‌شوند.
هر دو پیاده‌سازی، بخش جدایی‌ناپذیری از چارچوب Java Collections هستند و داده‌ها را به صورت زوج‌های کلید-مقدار ذخیره می‌کنند.
https://goo.gl/4hgnGq
@JavaCupIR
در کانال IGTV جاواکاپ ببینید:
نگاهی گذرا بر آنچه که در پنجمین دوره از مسابقات جاواکاپ گذشت
https://www.instagram.com/tv/BsAkWLzArG3
@JavaCupIR
نگاهی گذرا بر آنچه که در پنجمین دوره از مسابقات جاواکاپ گذشت
https://www.instagram.com/tv/BsAkWLzArG3
@JavaCupIR
#مقاله
به نظر شما، در پروژه‌های جاوایی از کدام سطح دسترسی بیش از سایرین استفاده می‌شود؟ public یا protected یا private و یا default؟ آیا هنگام کد زدن، به سطح دسترسی متدها و کلاس‌هایتان توجهی می‌کنید و برای انتخاب مناسب‌ترین سطح دسترسی، فکر می‌کنید؟
در این مقاله ابتدا می‌بینیم که میزان استفاده از هر یک از این سطوح دسترسی در پروژه‌های جاوایی توسط توسعه‌دهندگان چقدر است و سپس با هم می‌بینیم که چرا توجه به سطوح دسترسی مهم است.
https://goo.gl/QgfTHU
@JavaCupIR
به نظر شما، در پروژه‌های جاوایی از کدام سطح دسترسی بیش از سایرین استفاده می‌شود؟ public یا protected یا private و یا default؟ آیا هنگام کد زدن، به سطح دسترسی متدها و کلاس‌هایتان توجهی می‌کنید و برای انتخاب مناسب‌ترین سطح دسترسی، فکر می‌کنید؟
در این مقاله ابتدا می‌بینیم که میزان استفاده از هر یک از این سطوح دسترسی در پروژه‌های جاوایی توسط توسعه‌دهندگان چقدر است و سپس با هم می‌بینیم که چرا توجه به سطوح دسترسی مهم است.
https://goo.gl/QgfTHU
@JavaCupIR
انجمن جاواکاپ
#دستگرمی #جاوا۹
#پاسخ_دستگرمی
هر دوی #takeWhile و #dropWhile در واقع نوعی فیلتر برای #stream هستند با این تفاوت که باعث قطع‌شدن stream می‌شوند:
📌 متد takeWhile آیتم‌های stream را به ترتیب بررسی می‌کند و تا زمانی که شرط ورودی‌اش برقرار باشد، آن آیتم‌ها را بر می‌دارد (take می‌کند). به محضی که به آیتمی برسد که شرط ورودی را نقض کند، متوقف می‌شود. بنابراین آیتم‌های بررسی‌شده از آن عبور می‌کنند.
📌 متد dropWhile آیتم‌های stream را به ترتیب بررسی می‌کند و تا زمانی که شرط ورودی‌اش برقرار باشد، پیش رفته و آیتم‌های بررسی‌شده را دور می‌ریزد (drop می‌کند). به محضی که به آیتمی برسد که شرط را نقض کند، متوقف شده و آیتم‌های باقی‌مانده (بررسی‌نشده) از آن عبور می‌کنند.
🔸 و اما پاسخ دستگرمی
✔️ اولین stream نکته‌ی خاصی ندارد و طبق توضیحات بالا، خروجی‌اش برابر با 7 است.
✔️ دومین stream بر روی یک Set اجرا می‌شود و از آنجا که اعضای Set ترتیب ندارند، با هر بار اجرای برنامه ممکن است اعضای آن با ترتیب‌های متفاوتی به stream داده شده و به همین دلیل، نتیجه متفاوتی هم گرفته شود. بنابراین برای مثال:
✔️✔️ اگر اعضای Set با ترتیب 89657 به stream داده شوند، خروجی برابر با 657 خواهد بود و
✔️✔️ اگر اعضای Set با ترتیب 56789 به stream داده شوند، خروجی برابر با 56789 خواهد بود.
به این ترتیب، از میان گزینه‌های داده‌شده، گزینه‌های ۲ و ۶ از خروجی‌های ممکن این برنامه هستند و در نهایت گزینه ۷ پاسخ صحیح این دستگرمی است.
@JavaCupIR
هر دوی #takeWhile و #dropWhile در واقع نوعی فیلتر برای #stream هستند با این تفاوت که باعث قطع‌شدن stream می‌شوند:
📌 متد takeWhile آیتم‌های stream را به ترتیب بررسی می‌کند و تا زمانی که شرط ورودی‌اش برقرار باشد، آن آیتم‌ها را بر می‌دارد (take می‌کند). به محضی که به آیتمی برسد که شرط ورودی را نقض کند، متوقف می‌شود. بنابراین آیتم‌های بررسی‌شده از آن عبور می‌کنند.
📌 متد dropWhile آیتم‌های stream را به ترتیب بررسی می‌کند و تا زمانی که شرط ورودی‌اش برقرار باشد، پیش رفته و آیتم‌های بررسی‌شده را دور می‌ریزد (drop می‌کند). به محضی که به آیتمی برسد که شرط را نقض کند، متوقف شده و آیتم‌های باقی‌مانده (بررسی‌نشده) از آن عبور می‌کنند.
🔸 و اما پاسخ دستگرمی
✔️ اولین stream نکته‌ی خاصی ندارد و طبق توضیحات بالا، خروجی‌اش برابر با 7 است.
✔️ دومین stream بر روی یک Set اجرا می‌شود و از آنجا که اعضای Set ترتیب ندارند، با هر بار اجرای برنامه ممکن است اعضای آن با ترتیب‌های متفاوتی به stream داده شده و به همین دلیل، نتیجه متفاوتی هم گرفته شود. بنابراین برای مثال:
✔️✔️ اگر اعضای Set با ترتیب 89657 به stream داده شوند، خروجی برابر با 657 خواهد بود و
✔️✔️ اگر اعضای Set با ترتیب 56789 به stream داده شوند، خروجی برابر با 56789 خواهد بود.
به این ترتیب، از میان گزینه‌های داده‌شده، گزینه‌های ۲ و ۶ از خروجی‌های ممکن این برنامه هستند و در نهایت گزینه ۷ پاسخ صحیح این دستگرمی است.
@JavaCupIR
خوشحال می‌شیم زیر آخرین پست اینستاگرام، نظراتتون رو در خصوص آزمون کتبی جاواکاپ که مهرماه امسال برگزار شد، بشنویم.
قطعا نظرات، انتقادات و پیشنهادات شما برای دست‌اندرکاران جاواکاپ بسیار باارزشه و باعث رشد جاواکاپ می‌شه😊
https://www.instagram.com/p/BssrPDjg65V/?utm_source=ig_share_sheet&igshid=665s92wqczb6
@JavaCupIR
قطعا نظرات، انتقادات و پیشنهادات شما برای دست‌اندرکاران جاواکاپ بسیار باارزشه و باعث رشد جاواکاپ می‌شه😊
https://www.instagram.com/p/BssrPDjg65V/?utm_source=ig_share_sheet&igshid=665s92wqczb6
@JavaCupIR
#مقاله
«قرارداد برابری اشیا» (Object Equality Contract) بیان می‌کند، زمانی که دو شی با هم برابرند، کد درهم‌سازی (hash code) آن دو شی هم باید با هم برابر باشد.
این قرارداد، برای تمام اشیای جاوایی مورد استفاده در مجموعه‌های مبتنی بر درهم‌سازی (مانند HashMap و HashSet) صدق می‌کند و هدف اصلی آن، بهینه‌سازی کارایی هنگام کار با این مجموعه‌ها است.
احتمالا شنیده‌اید که توصیه می‌شود زمانی که متد ()equals را برای کلاس خود پیاده‌سازی می‌کنید، باید متد ()hashCode را هم پیاده‌سازی کنید.
این کار، یک رویکرد عملی برای پایبندی به «قرارداد برابری اشیا» است. اگر می‌خواهید بدانید که چرا پایبندی به این قرارداد مهم است، مطالعه این مقاله را از دست ندهید.
https://goo.gl/3jaJf1
@JavaCupIR
«قرارداد برابری اشیا» (Object Equality Contract) بیان می‌کند، زمانی که دو شی با هم برابرند، کد درهم‌سازی (hash code) آن دو شی هم باید با هم برابر باشد.
این قرارداد، برای تمام اشیای جاوایی مورد استفاده در مجموعه‌های مبتنی بر درهم‌سازی (مانند HashMap و HashSet) صدق می‌کند و هدف اصلی آن، بهینه‌سازی کارایی هنگام کار با این مجموعه‌ها است.
احتمالا شنیده‌اید که توصیه می‌شود زمانی که متد ()equals را برای کلاس خود پیاده‌سازی می‌کنید، باید متد ()hashCode را هم پیاده‌سازی کنید.
این کار، یک رویکرد عملی برای پایبندی به «قرارداد برابری اشیا» است. اگر می‌خواهید بدانید که چرا پایبندی به این قرارداد مهم است، مطالعه این مقاله را از دست ندهید.
https://goo.gl/3jaJf1
@JavaCupIR
#جاواویژن
فیلم سخنرانی‌های همایش جاواویژن ۹۷ منتشر شد.
https://javacup.ir/java-vision-97-lectures/
@JavaCupIR
فیلم سخنرانی‌های همایش جاواویژن ۹۷ منتشر شد.
https://javacup.ir/java-vision-97-lectures/
@JavaCupIR
#مقاله
حتما نام #Lombok به گوشتان خورده است. Lombok ابزاری است که اخیرا توسط توسعه‌دهندگان جاوا به میزان زیادی استفاده می‌شود و کسانی که از این ابزار استفاده می‌کنند، پس از مدتی، کد زدن بدون Lombok را نمی‌توانند تصور کنند.
جاوا زبان فوق‌العاده‌ای است، اما گاهی اوقات مجبور می‌شوید برای کارهای معمول خود یا سازگاری با برخی چارچوب‌ها، مجموعه‌کدهایی تکراری را به کدهای خود اضافه کنید.
این مجموعه‌کدها، معمولا ارزشی برای منطق برنامه شما ایجاد نمی‌کنند اما به هر حال ناگزیر به ایجاد آن‌ها هستید و این‌جا، جایی است که Lombok کار شما را راحت می‌کند.
از جمله مجموعه‌کدهای تکراری، می‌توان به setterها و getterها، constructorهای متعدد، متدهای equals و hashCode، تولید خودکار کدهای برخی الگوهای طراحی و … اشاره کرد.
ممکن است تصور کنید همه این کارها امروزه توسط IDEهای مدرن انجام می‌شوند، اما عجله نکنید! Lombok فراتر از این حرف‌هاست.
برای آشنایی با Lombok، مطالعه این مقاله را به شما توصیه می‌کنیم:
https://javacup.ir/introduction-to-lombok/
@JavaCupIR
حتما نام #Lombok به گوشتان خورده است. Lombok ابزاری است که اخیرا توسط توسعه‌دهندگان جاوا به میزان زیادی استفاده می‌شود و کسانی که از این ابزار استفاده می‌کنند، پس از مدتی، کد زدن بدون Lombok را نمی‌توانند تصور کنند.
جاوا زبان فوق‌العاده‌ای است، اما گاهی اوقات مجبور می‌شوید برای کارهای معمول خود یا سازگاری با برخی چارچوب‌ها، مجموعه‌کدهایی تکراری را به کدهای خود اضافه کنید.
این مجموعه‌کدها، معمولا ارزشی برای منطق برنامه شما ایجاد نمی‌کنند اما به هر حال ناگزیر به ایجاد آن‌ها هستید و این‌جا، جایی است که Lombok کار شما را راحت می‌کند.
از جمله مجموعه‌کدهای تکراری، می‌توان به setterها و getterها، constructorهای متعدد، متدهای equals و hashCode، تولید خودکار کدهای برخی الگوهای طراحی و … اشاره کرد.
ممکن است تصور کنید همه این کارها امروزه توسط IDEهای مدرن انجام می‌شوند، اما عجله نکنید! Lombok فراتر از این حرف‌هاست.
برای آشنایی با Lombok، مطالعه این مقاله را به شما توصیه می‌کنیم:
https://javacup.ir/introduction-to-lombok/
@JavaCupIR
از آن جایی که کد هیچ کس بی‌نقص نیست، لازم است با روش‌های مختلف بازبینی کد (#code_review) آشنایی داشته باشید و با استفاده از آن‌ها، کدهای خود و هم‌تیمی‌هایتان را در معرض بازبینی قرار دهید.
هر توسعه‌دهنده حرفه‌ای نرم‌افزار، می‌داند که بازبینی کد باید حتما بخشی جدی و مهم از یک فرآیند توسعه باشد. اما چیزی که بیشتر توسعه‌دهندگان نمی‌دانند، این است که روش‌های مختلفی برای بازبینی کد وجود دارد و هر روش، بسته به ساختار تیم پروژه، می‌تواند مزایا و معایب به خصوصی داشته باشد.
در ادامه، روش‌های مختلف بازبینی کد را با هم مرور می‌کنیم و توضیح می‌دهیم که هر روش دقیقا به چه صورت عمل می‌کند.
هدف ما این است که در انتها، قدرت تشخیص اینکه در چه زمانی، از چه روشی باید استفاده کنید را به دست آورید.
در بالاترین در سطح، انواع بازبینی کد را می‌توان به دو دسته
۱-بازبینی صوری (Formal) و
۲-بازبینی ملایم (Lightweight)
دسته‌بندی کرد.
با ما همراه باشید.
@JavaCupIR
هر توسعه‌دهنده حرفه‌ای نرم‌افزار، می‌داند که بازبینی کد باید حتما بخشی جدی و مهم از یک فرآیند توسعه باشد. اما چیزی که بیشتر توسعه‌دهندگان نمی‌دانند، این است که روش‌های مختلفی برای بازبینی کد وجود دارد و هر روش، بسته به ساختار تیم پروژه، می‌تواند مزایا و معایب به خصوصی داشته باشد.
در ادامه، روش‌های مختلف بازبینی کد را با هم مرور می‌کنیم و توضیح می‌دهیم که هر روش دقیقا به چه صورت عمل می‌کند.
هدف ما این است که در انتها، قدرت تشخیص اینکه در چه زمانی، از چه روشی باید استفاده کنید را به دست آورید.
در بالاترین در سطح، انواع بازبینی کد را می‌توان به دو دسته
۱-بازبینی صوری (Formal) و
۲-بازبینی ملایم (Lightweight)
دسته‌بندی کرد.
با ما همراه باشید.
@JavaCupIR
بازبینی صوری
بازبینی‌های صوری (Formal Code Review)، بر مبنای یک فرآیند صوری هستند. در حال حاضر، Fegan inspection محبوب‌ترین پیاده‌سازی از چنین فرآیندهایی است.
در این پیاده‌سازی، با یک فرآیند بسیار ساختارمند که سعی در پیدا کردن نواقص و مشکلات کد دارد، روبرو هستیم.
همچنین برای پیدا کردن نواقص specificationها و طراحی‌ها هم مورد استفاده قرار می‌گیرد.
فرآیند Fegan inspection شامل شش مرحله است: برنامه‌ریزی، مرور اجمالی، آماده‌سازی، جلسه بازرسی، بازنگری و پیگیری.
ایده اصلی این است که نیازمندی‌های خروجی را برای هر مرحله به صورت از پیش تعیین‌شده تعریف کنیم و هنگام اجرای فرآیند، خروجی هر مرحله را بازبینی کرده و آن را با نتیجه مطلوب مقایسه کنیم. سپس تصمیم بگیریم که به مرحله بعدی برویم یا همچنان باید بر روی مرحله فعلی کار کنیم.
چنین رویکرد ساختارمندی، چندان مورد استفاده قرار نمی‌گیرد و احتمالا به دلیل سربار زیادی که دارد، تیم‌های زیادی از آن استفاده نمی‌کنند.
به هر حال، اگر باید نرم‌افزاری را توسعه دهید که در صورت وجود نقص و مشکل، هزینه جانی داشته باشد، در این صورت استفاده از چنین رویکرد ساختارمندی برای پیدا کردن نواقص و مشکلات، معنادار و مفید خواهد بود.
برای مثال، اگر در حال توسعه نرم‌افزاری برای نیروگاه هسته‌ای هستید، احتمالا باید از چنین روشی استفاده کنید تا تضمین شود که هیچ باگی در کد تحویل‌داده‌شده وجود ندارد.
اما اکثر ما، توسعه‌دهندگانی هستیم که بر روی چنین نرم‌افزارهای حیاتی‌ای کار نمی‌کنیم و بنابراین، به جای روش صوری، از یک روش ملایم‌تر برای بازبینی کد استفاده می‌کنیم.
در مطالب بعدی، به معرفی انواع روش‌های بازبینی ملایم می‌پردازیم.
@JavaCupIR
بازبینی‌های صوری (Formal Code Review)، بر مبنای یک فرآیند صوری هستند. در حال حاضر، Fegan inspection محبوب‌ترین پیاده‌سازی از چنین فرآیندهایی است.
در این پیاده‌سازی، با یک فرآیند بسیار ساختارمند که سعی در پیدا کردن نواقص و مشکلات کد دارد، روبرو هستیم.
همچنین برای پیدا کردن نواقص specificationها و طراحی‌ها هم مورد استفاده قرار می‌گیرد.
فرآیند Fegan inspection شامل شش مرحله است: برنامه‌ریزی، مرور اجمالی، آماده‌سازی، جلسه بازرسی، بازنگری و پیگیری.
ایده اصلی این است که نیازمندی‌های خروجی را برای هر مرحله به صورت از پیش تعیین‌شده تعریف کنیم و هنگام اجرای فرآیند، خروجی هر مرحله را بازبینی کرده و آن را با نتیجه مطلوب مقایسه کنیم. سپس تصمیم بگیریم که به مرحله بعدی برویم یا همچنان باید بر روی مرحله فعلی کار کنیم.
چنین رویکرد ساختارمندی، چندان مورد استفاده قرار نمی‌گیرد و احتمالا به دلیل سربار زیادی که دارد، تیم‌های زیادی از آن استفاده نمی‌کنند.
به هر حال، اگر باید نرم‌افزاری را توسعه دهید که در صورت وجود نقص و مشکل، هزینه جانی داشته باشد، در این صورت استفاده از چنین رویکرد ساختارمندی برای پیدا کردن نواقص و مشکلات، معنادار و مفید خواهد بود.
برای مثال، اگر در حال توسعه نرم‌افزاری برای نیروگاه هسته‌ای هستید، احتمالا باید از چنین روشی استفاده کنید تا تضمین شود که هیچ باگی در کد تحویل‌داده‌شده وجود ندارد.
اما اکثر ما، توسعه‌دهندگانی هستیم که بر روی چنین نرم‌افزارهای حیاتی‌ای کار نمی‌کنیم و بنابراین، به جای روش صوری، از یک روش ملایم‌تر برای بازبینی کد استفاده می‌کنیم.
در مطالب بعدی، به معرفی انواع روش‌های بازبینی ملایم می‌پردازیم.
@JavaCupIR