راهنمای جیبی برای «خلق کردن»

تمامی دیزاینرها برای ارائه کارهای خوب، ‌محکومند به خلاق بودن. در کار ما، خلاقیت یکی از الزمات لذت‌بخش است که امروز درباره آن گفتگو می‌کنیم.
بسیاری از ما فکر می‌کنیم که آدم‌های خلاق آدم‌های شخلته‌ای هستند، یا برای خلاق بودن باید تمامی روندها و چارچوب‌ها را درهم کوبید، حتی در زندگی شخصی. به اعتقاد من و برخی دیگر که چند وقت پیش با آنها هم‌صحبت شده بودم، خلاقیت می‌تواند روند داشته باشد. یا شاید بهتر باشد بگوییم برای ایجاد «تکرار پذیری» و «تمرین و یادگیری» هرچیزی باید آن را بصورت یک Flow یا روند درآوریم. خلاقیت هم از این قاعده مستثنی نیست.

مقاله امروز بطور کامل به بررسی خلاق بودن می‌پردازد و نتیجه‌ای است از مطالعه نوشته‌های Mihaly Csikszentmihalyi (روانشناس) و Betty Edwards (مدرس هنر) در قالب روشی به نام ISIIVE. هر حرف از این نام معرف یکی از مراحل این روند است و مثل بسیاری روش‌های دیگر، با پرسیدن «سوال دُرست» شروع می‌شود.

اگر شما هم می‌خواهید خلاق باشید، این مقاله را از دست ندهید و نوشته‌های آن را همیشه در گوشه‌ای نگه دارید.
مثل لباس یک ابرقهرمان. ابرقهرمان خلاقیت.

https://uxplanet.org/pocket-creativity-d1868400ff1b

(زمان حدودی مطالعه، ۱۵ دقیقه)

#معرفی #تکنیک #خلاقیت
@Dexign فلسفه دیزاین

____

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. ضد الگوی «کد مرده» یا Dead Code چیست؟

https://t.me/SoftwarePhilosophy/1140

۲. قدم‌های مناسب برای رسیدن به تخمین موفق در پروژه

https://t.me/SoftwarePhilosophy/1142

۳. آشنایی با کانبان و نحوه کار بورد کانبان در پروژه‌های نرم‌افزاری

https://t.me/SoftwarePhilosophy/1144

۴. استفاده از JSON در SQL Server 2016 (SQL Server)

https://t.me/SoftwarePhilosophy/1145

۵. آشنایی با برنامه نویسی Blockchain و معرفی کتاب

https://t.me/SoftwarePhilosophy/1146

۶. راهنمای جیبی برای «خلق کردن» (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1147

ـــــــــــ

@SoftwarePhilosophy

🔻 عنوان: مالک محصول بزرگ در مقابل مالک محصول کوچک

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

🆔 @agileproduct

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

🔸 به عبارت دیگر، ایفای نقش به عنوان مالک محصول یک استارتاپ نوپا در مقایسه با یک سازمان نرم­افزاری بالغ با هم بسیارمتفاوت است. با این حال، مالکین محصول در سرتاسر دنیا در دو دسته قرار می­ گیرند. مالک محصول بزرگ و مالک محصول کوچک. تا حالا به این فکر کردید که شما در کدام دسته هستید؟ آیا سطح مالکیت محصول شما در جای درستی قرار دارد؟

👇👇👇👇
https://goo.gl/rXss2J

🆔 @agileproduct

#پست_مجدد این پست تا به حال بیش از ۳۸۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

قورباغه را دوباره اختراع نکنید!

در مهندسی نرم‌افزار، شناخت دقیق نیازمندیها و سپس ساخت محصولی مطابق نیازمندیها یکی از کارهای به ظاهر ساده ولی در عمل پیچیده است. مطلب زیر داستانی را تشریح می‌کند که در آن یک مهندس نرم‌افزار هنگام خلقت زمین پروژه طراحی «زنبور» را بر عهده گرفته‌است. ولی به دلایلی که در داستان توضیح داده شده اقدام به طراحی یک «وزغ» می‌کند که هیچ تناسبی با نیازمندیهای «زنبور» ندارد. این مهندس نرم‌افزار در حقیقت به جای خلق موجودی که نیازمندیهای زنبور را برآورده کند، یک حیوان جدید به نام وزغ خلق کرده که اتفاقا خدا قبلا آن را با نام «قورباغه» خلق کرده بوده!
اگر لینک زیر را کامل بخوانید ارتباط آن را با پروژه‌های نرم‌افزاری می‌بینید و خواهید دید که چگونه این خطا باعث شکست یک پروژه نرم‌افزاری می‌شود.


http://mehrandvd.me/2016/03/09/reinventing-the-frog/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۲۵۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

الگوی Async Retry Pattern یکی از الگوهایی است که در برنامه‌نویسی برنامه‌های نسل جدید بسیار مهم است. بسیاری دستگاه‌ها و بسترهای جدید شبکه مطمئنی ندارند. برای مثال اینترنت روی گوشی ممکن است بسته به موقعیت قطع و وصل شود و یا کیفیت پایینی داشته باشد. در این بسترها عملیات باید در صورت ناموفق بودن چند بار تکرار شوند و یا اصلاحا retry شود. ابزارهایی که برای retry طراحی شده‌اند این امکان را می‌دهند تا بتوان یک کار را با چند بار retry کردن انجام داد. برای مثال:
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);

RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);

کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.

مقاله زیر ضمن تشریح این الگو، توضیح داده‌است که چطور می‌توان با استفاده از async/await الگوی retry pattern را پیاده‌سازی کرد.

https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

معرفی کتاب‌های بی‌ربط به دیزاین

احتمالا می‌پرسید چرا باید در کانالی که از دیزاین حرف می‌زند کتاب‌های بی‌ربط به دیزاین معرفی شود؟
خب واقعیت این است که کتاب‌هایی که امروز به معرفی‌شان می‌پردازیم فقط «مستقیما» به دیزاین مربوط نیستند. این کتاب‌ها به نگاه و طرز تفکرمان مربوطند و همین نگاه و طرز تفکر می‌تواند یک دیزاین نسبتا خوب را به دیزاینی کاملا عالی تبدیل کند.
اگر کمی بیاندیشیم احتمالا موضوعات زیادی پیدا می‌کنیم که برای رسیدن به کمال در آن‌ها، به مهارت‌های مختلف، متفاوت و در نگاه اول کاملا بی‌ربط نیازمندیم.

آقای Daniel Burka، یکی از همکاران Google Ventures، در توییتی از دیزاینرها خواسته بود که بهترین کتاب دیزاینی که مربوط به دیزاین نیست را معرفی کنند. ایشان جواب‌های دریافتی‌شان را در قالب مقاله‌ای با ما به اشتراک گذاشته‌اند.

کتاب‌های این مجموعه را از دست ندهید.

https://medium.com/@dburka/the-best-design-books-that-arent-explicitly-about-design-74fc96ce115e

(زمان حدودی مطالعه، ۶ دقیقه)

#معرفی #کتاب #دیزاین
@Dexign فلسفه دیزاین

__

#پست_مجدد این پست تا به حال بیش از ۲۴۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

دنیای AR یا Augmented Reality باعث ایجاد مفاهیم جدیدی در UI/UX شده‌است. توان خلق موجودیت‌ها در فضای اطراف کاربر امکانی است که قبلا وجود نداشته و به همین دلیل ظهور AR باعث ایجاد تجربیات جدیدی در دنیای UX شده‌است.
برای مثال در لینک زیر یکی از طراحان ارشد هولوگرافیک توضیح می‌دهد که در نسخه‌های اولیه نرم‌افزار طراحی برای خلق اشیا سه بعدی، از یک «میز چهارگوش» مجازی استفاده شده بود که کاربر روی آن شروع به طراحی می‌کرد (مثلا طراحی یک اسباب‌بازی). پس از تست‌های UX متوجه شدند چهارگوش بودن میز باعث می‌شود کاربران بیشتر یک سمت میز بایستند و کمتر دور شیی که طراحی می‌کنند بچرخند. به همین دلیل در نسخه‌های بعدی از یک میز مجازی «گرد» استفاده شد. نتیجه عالی بود، کاربران دیگر یک جای ثابت نمی‌ایستند و تقریبا هر دفعه از یک زاویه جدید محصول خود را می‌بینند.

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

https://developer.microsoft.com/en-us/windows/holographic/case_study_-_3_holostudio_ui_and_interaction_design_learnings

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. مالک محصول بزرگ در مقابل مالک محصول کوچک (Agile Product Management)

https://t.me/SoftwarePhilosophy/1149

۲. قورباغه را دوباره اختراع نکنید!

https://t.me/SoftwarePhilosophy/1151

۳. الگوی Async Retry Pattern

https://t.me/SoftwarePhilosophy/1153

۴. معرفی کتاب‌های بی‌ربط به دیزاین (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1154

۵. تجربیات و درس‌های یک طراح ارشد پروژه‌های هولوگرافیک

https://t.me/SoftwarePhilosophy/1156

ـــــــــــ

@SoftwarePhilosophy

یکی از مهمترین چالش‌ها در الگوریتم‌هایی که با حجم زیادی از آرایه‌ها کار می‌کنند، کپی کردن قسمت‌هایی از آرایه برای انجام یک کار روی آن است. برای مثال وقتی می‌خواهید نصف دوم یک آرایه را به یک متد پاس بدهید، عموما مجبورید از نصف دوم آرایه یک کپی بگیرید و به متد پاس بدهید. سربار کپی همیشه یکی از مهمترین چالش‌های performance در الگوریتم‌ها بوده است.
یکی از امکانات جذابی که به C# 7.2 اضافه شده، مفهوم Span<T> است. با استفاده از این تایپ جدید که بر اساس مفاهیم پیچیده‌ای بنا شده، به راحتی می‌توانید یک قسمت از یک آرایه را بدون اینکه کپی کنید جدا کنید و از آن استفاده کنید.

در مقاله زیر Stephen Toub که یکی از معماران اصلی امکانات Parallel Programming در .Net است، بسیار مفید و دقیق در مورد Span<T> و Memory<T> صبحت کرده و حتی در مورد قسمت‌هایی از لایه‌های زیرین این تایپ‌ها توضیح داده که چطور کد آنها پیاده‌سازی شده‌است.

https://msdn.microsoft.com/en-us/magazine/mt814808.aspx


⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

http://ow.ly/oEWA30ik0Yp

#مهران_داودی (http://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

🔵 چرا کارها در انتهای اسپرینت تمام نمی‌شوند؟

سه دلیل عمده اینکه چرا کارها در انتهای اسپرینت تمام نمی‌شوند:

1- تسک سوییچ: اینکه فرد بین تسکهای مختلف خود مجبور به سوییچ کردن است و نمی تواند یک کار کامل انجام دهد و سپس کار بعدی را شروع کند.

2- افراد بنابر تخصص از همه جدا شده اند: مثلا فرانت اند، بک اند، تحلیل. در این صورت تسک های نفرات از همه جدا می شود، این روش برای مشغول نگه داشتن افراد عالی است ولی برای تمام شدن کلی کار و نتیجه گرفتن، میتواند خوب نباشد.

3- آیتم های اسپرینت بزرگ هستند: آیتم هایی که وارد اسپرینت می شوند خوب شکسته نشده اند و معمولا چند اسپرینت به طول می انجامند.

https://goo.gl/Fwx3c7

@iranagile

لاگ ها - یکپارچه سازی

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

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

1. قابلیت جستجوهای پیشرفته، گزارش سازی و کوئری زدن بر روی آن ها وجود ندارد.
2. در برنامه های پر ترافیک ثبت لاگ بر روی فایل ترافیک I/O زیادی را به سیستم تحمیل می کند.
3. اگر سامانه متشکل از چند سیستم جدا از هم باشد، لاگ های پراکنده ای خواهیم داشت که هر کدام در یک محل جدا و غیریکپارچه قرار گرفته اند.
4. برای خواندن لاگ ها نیاز به دسترسی به مستقیم به سرور خواهید داشت.

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

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

* ابزار SEQ توسط توسعه دهنده کتابخانه پرقدرت Autofac و Serilog توسعه داده شده است.

* دانلود ابزار SEQ
https://getseq.net/Download

*توضیحاتی در مورد SEQ
https://blog.getseq.net/hello-seq-4-0-dashboards-alerts-more-improvements/

https://blog.getseq.net/seq-4-2-rtm/

* پلتفرم ELK - پرقدرت ولی به نسبت پیچیده از حیث راه اندازی و نگهداری
https://www.elastic.co/webinars/introduction-elk-stack

@irandotnet

تصمیم دُرُست را دُرُست بگیریم

همه‌ی ما در تمام مراحل زندگی و تمام لحظاتش در حال گرفتن تصمیم‌های مختلفی هستیم. از انتخاب مسیر خانه به محل کار گرفته تا خرید خانه، برنامه‌ریزی برای آینده و …
یک «تصمیم» یا سلسله‌ای از تصمیم‌ها می‌تواند زندگی کاری، زندگی شخصی و همه‌چیز یک شخص را دگرگون کند. پس «تصمیم» اتفاق بسیار مهمی‌ست.
به نظرتان شما «تصمیم‌گیرنده» خوبی هستید؟

فارغ از اینکه جواب سوال بالا را چه چیزی می‌دهید، اگر به اصل سوال ایرادی نگرفته‌اید، نشان می‌دهد که قبول دارید «تصمیم گرفتن» یک مهارت است. بعضی در آن خوب هستند و بعضی هم نه.
کمی جزئی‌تر بحث کنیم و به دنیای خودمان، دنیای دیزاین برگردیم. بارها گفته‌ایم که محصولاتی که دیزاینرها می‌سازند تاثیر بسیاری در زندگی انسان‌ها دارد. از طرف دیگر تصمیمی که مدیر محصول می‌گیرد، تاثیر بسیاری در سرنوشت محصول و به تبع آن سرنوشت شرکت دارد.
امروز می‌خواهیم درباره تصمیم‌گیری صحبت کنیم. می‌خواهیم آن را بصورت یک چارچوب یا Framework درآورده و روندی قانون‌مند برای بهینه‌تر شدن نتیجه معرفی کنیم.

مقاله امروز از Brandon Chu، راهبر محصول در Shopify است. Brandon تصمیم‌ها را به دو دسته تقسیم کرده و برای گرفتن آن‌ها، در بهینه‌ترین زمان و با بهترین خروجی توضیحاتی می‌دهد.

چه مدیر محصول باشید چه نه، مقاله امروز برای شماست که روند تصمیم‌گیری خود را برای همیشه تغییر دهید.

https://blackboxofpm.com/making-good-decisions-as-a-product-manager-c66ddacc9e2b

(زمان حدودی مطالعه، ۱۴ دقیقه)

#بررسی #متد #تصمیم‌گیری
@Dexign فلسفه دیزاین

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. آشنایی با مفهوم Span<T> در C# 7.2

https://t.me/SoftwarePhilosophy/1158

۲. چرا کارها در انتهای اسپرینت تمام نمی‌شوند؟ (Iran Agile)

https://t.me/SoftwarePhilosophy/1159

۳. لاگ ها - یکپارچه سازی (Iran .Net)

https://t.me/SoftwarePhilosophy/1160

۴. تصمیم دُرُست را دُرُست بگیریم (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1161

ـــــــــــ

@SoftwarePhilosophy

یادگیری مفاهیم پایه یا تکنولوژی های جدید

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

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

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

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

* اسکات هنسلمن https://www.hanselman.com/blog/YouGotThisYouKnowTheFundamentalsYouAreALearnerPlusTheImpostersHandbook.aspx

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

* مَتیو جونز : همه کدها دورریختی اند

https://exceptionnotfound.net/all-code-is-disposable-just-like-it-should-be/

* مَتیو جونز : من از 9 تا 5 کار می کنم | شما هم می توانید

https://exceptionnotfound.net/i-am-a-9-to-5-developer-and-so-can-you/

* مطلبی در مورد سندروم Imposter و اینکه تحقیقات نشان می دهد برنامه نویسانی که مدام کار می کنند، دچار مشکلات روحی متعددتر و بازدهی پایین تری هستند. عاشق برنامه نویسی بودن به معنی هفته 100 ساعت کار کردن نیست.

http://www.businessinsider.com/syndromes-drive-coders-crazy-2014-3

@irandotnet

#پست_مجدد این پست تا به حال بیش از ۲۶۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.

گرفتن امتیاز ۴۰۰ در Telegram Lumberjack با استفاده یک بات برنامه‌نویسی شده!!!

https://www.youtube.com/watch?v=w3SsDhT7r2Y

کانال تلگرام:
@SoftwarePhilosophy

___

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

لینک زیر یکی از پیاده‌سازی‌های ممکن برای گرفتن امتیازهای بالا در Telegram Lumberjack را شرح داده‌است.

http://mehrandvd.me/2016/10/30/cheating-telegram-lumberjack/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy


___