Forwarded from فلسفه دیزاین
نمونهای جالب و جسورانه از تاثیر «مشاهده» در دیزاین gov.uk
محدودیتها و تعصبهای ذهنی، یکی از بزرگترین دشمنان دیزاینرها هستند. محدودیتهای ذهن به ما اجازه نمیدن که خرق عادت کرده و Out of box فکر کنیم، تعصبها بدتر هستن و حتی بعضا اجازه نمیدن که ما چیزی رو که میبینیم، باور کنیم.
بزرگترین دیزاینرهای دنیا این فرصت رو داشتند یا در خودشون پرورش دادند که بتونن «متفاوت» فکر کنند. خلاقانهترین راهحلها رو حتی به قیمت کاربردی نبودنشون، ببینن و بتونن بین چندین راهحلی که در نظرشون هست، بهترین و کاربردیترین رو انتخاب کنند.
یکی از تمرینهایی که خود من سالها پیش در راستای بهبود خلاقیتام انجام میدادم این بود که یه وسیله رو در نظر میگرفتم و سعی میکردم ۲۰ کاربرد غیرمتعارف برای اون مثال بزنم. پیشنهادم اینه که این تمرین رو گاهی توی تیمتون انجام بدید تا قدمی باشه برای کمک به خارج شدن از چهارچوبها و قالبهای فکری.
مقاله امروز یه مقاله گزارشی هست درباره بهبود Radio Buttonها و Checkboxها در سایت gov.uk.
این مقاله از دو جهت به نظرم بسیار بسیار هیجانانگیز هست. یک اینکه لزوم انجام بهبودهایی که اشاره میشه از طریق مشاهده کار کاربران بوده، و دو اینکه احتمالا دیزاین نهایی به سلیقه بسیاری از ماها خوش نمیاد ولی بسیار کاربردی هست.
در این مقاله مشاهدهای برای نحوه برخورد کاربران هنگام مواجهه با Radio Buttonها و Checkboxها انجام شده و متوجه شدند که کاربران برای انتخاب یک گزینه در یک لیست، بصورت ناخودآگاه به جای کلیک روی متن اون گزینه، اصرار دارند که روی Radio Button یا Checkbox کوچکی که در اول سطر قرار داره کلیک کنند.
دیزاینرهای پروژه، در دیزاین قبلیشون، با در نظر گرفتن قانون Fitts، متن گزینهها رو هم قابل کلیک کرده بودند. اونها حتی کادری دور گزینهها قرار داده بودند که بصورت ضمنی، ناحیه قابل کلیک رو مشخص میکرد. با این حال باز هم کاربران به کلیک روی Radio Button یا Checkbox علاقه بیشتری نشون میدادند.
جالبه نه؟ پیشفرضهای ذهنی ما دیزاینرها تاثیر بسیار زیادی در تجربه کاربران از سرویس ما و در نتیجه میزان موفق سرویس داره.
پیشنهاد میکنم برای مطالعه بیشتر این بحث و البته دیدن دیزاینی که دیزاینرهای gov.uk بعد از مشاهداتشون بهش رسیدن، به لینک زیر برید.
کامنتهای زیر پست هم برای مطالعه پیشنهاد میشه. :)
پ. ن.
قانون Fitts بصورت خلاصه میگه سرعت دسترسی به یک آیتم، تابعی هست از فاصله از اون آیتم و اندازه آیتم.
https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-radios-and-checkboxes-on-gov-uk/
(زمان حدودی مطالعه ۵ دقیقه)
#تجربه_کاربری #گزارش
@HamDesign هَم دیزاین
محدودیتها و تعصبهای ذهنی، یکی از بزرگترین دشمنان دیزاینرها هستند. محدودیتهای ذهن به ما اجازه نمیدن که خرق عادت کرده و Out of box فکر کنیم، تعصبها بدتر هستن و حتی بعضا اجازه نمیدن که ما چیزی رو که میبینیم، باور کنیم.
بزرگترین دیزاینرهای دنیا این فرصت رو داشتند یا در خودشون پرورش دادند که بتونن «متفاوت» فکر کنند. خلاقانهترین راهحلها رو حتی به قیمت کاربردی نبودنشون، ببینن و بتونن بین چندین راهحلی که در نظرشون هست، بهترین و کاربردیترین رو انتخاب کنند.
یکی از تمرینهایی که خود من سالها پیش در راستای بهبود خلاقیتام انجام میدادم این بود که یه وسیله رو در نظر میگرفتم و سعی میکردم ۲۰ کاربرد غیرمتعارف برای اون مثال بزنم. پیشنهادم اینه که این تمرین رو گاهی توی تیمتون انجام بدید تا قدمی باشه برای کمک به خارج شدن از چهارچوبها و قالبهای فکری.
مقاله امروز یه مقاله گزارشی هست درباره بهبود Radio Buttonها و Checkboxها در سایت gov.uk.
این مقاله از دو جهت به نظرم بسیار بسیار هیجانانگیز هست. یک اینکه لزوم انجام بهبودهایی که اشاره میشه از طریق مشاهده کار کاربران بوده، و دو اینکه احتمالا دیزاین نهایی به سلیقه بسیاری از ماها خوش نمیاد ولی بسیار کاربردی هست.
در این مقاله مشاهدهای برای نحوه برخورد کاربران هنگام مواجهه با Radio Buttonها و Checkboxها انجام شده و متوجه شدند که کاربران برای انتخاب یک گزینه در یک لیست، بصورت ناخودآگاه به جای کلیک روی متن اون گزینه، اصرار دارند که روی Radio Button یا Checkbox کوچکی که در اول سطر قرار داره کلیک کنند.
دیزاینرهای پروژه، در دیزاین قبلیشون، با در نظر گرفتن قانون Fitts، متن گزینهها رو هم قابل کلیک کرده بودند. اونها حتی کادری دور گزینهها قرار داده بودند که بصورت ضمنی، ناحیه قابل کلیک رو مشخص میکرد. با این حال باز هم کاربران به کلیک روی Radio Button یا Checkbox علاقه بیشتری نشون میدادند.
جالبه نه؟ پیشفرضهای ذهنی ما دیزاینرها تاثیر بسیار زیادی در تجربه کاربران از سرویس ما و در نتیجه میزان موفق سرویس داره.
پیشنهاد میکنم برای مطالعه بیشتر این بحث و البته دیدن دیزاینی که دیزاینرهای gov.uk بعد از مشاهداتشون بهش رسیدن، به لینک زیر برید.
کامنتهای زیر پست هم برای مطالعه پیشنهاد میشه. :)
پ. ن.
قانون Fitts بصورت خلاصه میگه سرعت دسترسی به یک آیتم، تابعی هست از فاصله از اون آیتم و اندازه آیتم.
https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-radios-and-checkboxes-on-gov-uk/
(زمان حدودی مطالعه ۵ دقیقه)
#تجربه_کاربری #گزارش
@HamDesign هَم دیزاین
designnotes.blog.gov.uk
We've updated the radios and checkboxes on GOV.UK
Last week we updated the styles for radio buttons and checkboxes on GOV.UK. This post explains why we’ve done this. Our old radios and checkboxes looked like this: The new ones look like this: We’ve removed the grey boxes and …
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. اشتباهاتی که همه ما دیزاینرها انجام میدهیم (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/598
۲. معرفی Dapper به عنوان یک Micro ORM
#orm #dapper
https://telegram.me/SoftwarePhilosophy/599
۳. معرفی و مقایسه session storage، local storage و cookie
#clientstorage
https://telegram.me/SoftwarePhilosophy/601
۴. قدمهای مناسب برای رسیدن به تخمین موفق در پروژه
#estimate
https://telegram.me/SoftwarePhilosophy/602
۵. نمونهای جسورانه از تاثیر مشاهده در دیزاین (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/603
ـــــــــــ
@SoftwarePhilosophy
۱. اشتباهاتی که همه ما دیزاینرها انجام میدهیم (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/598
۲. معرفی Dapper به عنوان یک Micro ORM
#orm #dapper
https://telegram.me/SoftwarePhilosophy/599
۳. معرفی و مقایسه session storage، local storage و cookie
#clientstorage
https://telegram.me/SoftwarePhilosophy/601
۴. قدمهای مناسب برای رسیدن به تخمین موفق در پروژه
#estimate
https://telegram.me/SoftwarePhilosophy/602
۵. نمونهای جسورانه از تاثیر مشاهده در دیزاین (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/603
ـــــــــــ
@SoftwarePhilosophy
Forwarded from Iran Agile
مدل اسپاتیفای را کپی نکنید
همیشه یاد گرفتن نحوه کار شرکت های معروف هیجان برانگیز است، اینکه آنها چگونه کار می کنند و چگونه محصول تولید می کنند، مدیریت به چه شکلی است? و ...
یکی از این شرکت های معروف که چابک کار می کند اسپاتیفای است، که مدل کار خود را منتشر کرده اند و بسیار مورد استقبال قرار گرفته است. اما اتفاقی که روی داد کپی بدون فکر همین مدل در شرکت های دیگر بوده است،
به یاد داشته باشیم که ⬇️⬇️
همه مدل ها بد هستند ولی بعضی از آنها کار می کنند
@iranagile
@Iranagile
☑️☑️☑️
https://www.infoq.com/news/2016/10/no-spotify-model
همیشه یاد گرفتن نحوه کار شرکت های معروف هیجان برانگیز است، اینکه آنها چگونه کار می کنند و چگونه محصول تولید می کنند، مدیریت به چه شکلی است? و ...
یکی از این شرکت های معروف که چابک کار می کند اسپاتیفای است، که مدل کار خود را منتشر کرده اند و بسیار مورد استقبال قرار گرفته است. اما اتفاقی که روی داد کپی بدون فکر همین مدل در شرکت های دیگر بوده است،
به یاد داشته باشیم که ⬇️⬇️
همه مدل ها بد هستند ولی بعضی از آنها کار می کنند
@iranagile
@Iranagile
☑️☑️☑️
https://www.infoq.com/news/2016/10/no-spotify-model
InfoQ
Don't Copy the Spotify Model
The Spotify model can help you to understand how things are done at Spotify, but you shouldn’t copy it in your own organization. It changes all the time as people at Spotify learn and discover new things. There is no one way in which software is developed…
الگوی 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
___
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
___
Alastair Crabtree
Implementing the retry pattern for async tasks in c#
This post is a follow on from Implementing a simple retry pattern in c#
[https://alastaircrabtree.com/implementing-a-simple-retry-pattern-in-c/].
Tasks, async and await are rapidly becoming be default API flavours in many
dotnet libraries and the performance…
[https://alastaircrabtree.com/implementing-a-simple-retry-pattern-in-c/].
Tasks, async and await are rapidly becoming be default API flavours in many
dotnet libraries and the performance…
Forwarded from Iran Agile
در اسکرام تاکید شده است که مالک محصول یک نفر است و او باید تصمیم های مهم تجاری را بگیرد، اما وقتی پروژه بزرگ می شود آیا یک نفر می تواند بر کل دامنه و تیم ها احاطه داشته باشد؟
در پروژه های بزرگ می توانیم، و باید، مسئولیت ها و عملکرد این نقش شکسته و توزیع شود.
برای درک بهتر، رستوران های بزرگ تجسم کنید، آشپز داریم و سر آشپز.
🍲🍲🍲
🏂🏂🏂
@iranagile
@iranagile
http://www.mountaingoatsoftware.com/blog/the-chief-product-owner-on-large-agile-projects
در پروژه های بزرگ می توانیم، و باید، مسئولیت ها و عملکرد این نقش شکسته و توزیع شود.
برای درک بهتر، رستوران های بزرگ تجسم کنید، آشپز داریم و سر آشپز.
🍲🍲🍲
🏂🏂🏂
@iranagile
@iranagile
http://www.mountaingoatsoftware.com/blog/the-chief-product-owner-on-large-agile-projects
Mountain Goat Software
The Chief Product Owner on Large Agile Projects
On a large agile project with multiple teams, the product owner role is too big for one person, so we must find ways of scaling it.
مدتیست کمپین #NoEstimates در توییتر توجه مهندسین نرمافزار را به خود جلب کردهاست. این کمپین فلسفه جالبی دارد، افراد در این فلسفه اعتقاد دارند story ها نباید estimate شوند!! در این فلسفه تنها تخمین درست این است که آیا یک story به اندازه کافی کوچک هست یا نه. اگر یک story هنوز به اندازه کافی کوچک نیست، باید به تکههای کوچکتر شکسته شود. در این تیمها به جای مجموع زمان باقیمانده یا point های باقیمانده از «تعداد» استوریهای باقیمانده استفاده میشود.
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کردهاست.
http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کردهاست.
http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Innolution
Blog: To Estimate or Not to Estimate – That is the Controversy | Innolution
Blog that discusses the controversy of whether estimates are useful on agile development projects.
Forwarded from Iran Agile
یکی از صحبت های ناتمام در دنیای چابک مسئله Code Review است؟
اصولا نیازی به Code Review داریم؟ آیا فقط یک نفر باید این کار را انجام دهد؟ چه زمانی باید انجام شود؟
تجربه تیم اطلسین استرالیا می تواند به این سوالات جواب دهد
🛠🛠
@iranagile
@iranagile
https://www.atlassian.com/agile/code-reviews
اصولا نیازی به Code Review داریم؟ آیا فقط یک نفر باید این کار را انجام دهد؟ چه زمانی باید انجام شود؟
تجربه تیم اطلسین استرالیا می تواند به این سوالات جواب دهد
🛠🛠
@iranagile
@iranagile
https://www.atlassian.com/agile/code-reviews
خلق تجربه کاربری خوب و مناسب برای تمام وسایل نمایش، فارغ از سایز آنها، هدف اصلی طراحی responsive است. خواه موبایل باشد یا تبلت یا رایانه شخصی و ....
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.
https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints
#مریم_داودی
لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a
کانال تلگرام:
@SoftwarePhilosophy
___
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.
https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints
#مریم_داودی
لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a
کانال تلگرام:
@SoftwarePhilosophy
___
ui.dev
Why you don’t need device specific breakpoints
With the ever growing number of different mobile, tablet, laptops, monitors, televisions, watches — and whatever else will communicate information to you visually — it’s finally time to put to rest those device specific breakpoints.
برنامهنویسی VR یا Virtual Reality و دنیای آن بسیار هیجانانگیز است. همچنین تجهیزات IoT یا Internet of Things برای برنامهنویسان بسیار جذاب است. در «استارتاپ ویکند مد و تکنولوژی» امکان استفاده از این تجهیزات مهیا شدهاست. در این رویداد یک دستگاه Gear VR و همچنین چند دستگاه Beacon برای برنامهنویسی مهیا شدهاست. شما میتوایند برنامههای خود را روی این دستگاهها نیز به داوران ارائه کنید.
با توجه به اینکه اعضای کانال @SoftwarePhilosophy عمدتا جز برنامهنویسان حرفهای و یا مدیران فنی شرکتها میباشند، امکان ثبتنام برنامهنویسان پر انرژی این کانال با تخفیف ۳۰.۰۰۰ تومانی در «استارتاپ ویکند مد و تکنولوژی» فراهم شدهاست. شما میتوانید از کد تخفیف زیر در هنگام ثبتنام استفاده کنید.
کد تخفیف: SoftwarePhilosophy
لینک ثبتنام: http://modotech.ir
ـ
با توجه به اینکه اعضای کانال @SoftwarePhilosophy عمدتا جز برنامهنویسان حرفهای و یا مدیران فنی شرکتها میباشند، امکان ثبتنام برنامهنویسان پر انرژی این کانال با تخفیف ۳۰.۰۰۰ تومانی در «استارتاپ ویکند مد و تکنولوژی» فراهم شدهاست. شما میتوانید از کد تخفیف زیر در هنگام ثبتنام استفاده کنید.
کد تخفیف: SoftwarePhilosophy
لینک ثبتنام: http://modotech.ir
ـ
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. مدل اسپاتیفای را کپی نکنید. (iranagile)
#srcum
https://telegram.me/SoftwarePhilosophy/605
۲. الگوی Async Retry Pattern
#async #csharp
https://telegram.me/SoftwarePhilosophy/606
۳. آیا در پروژههای بزرگ هم یک نفر تصمیم گیرنده است؟ (iranagile)
#srcum
https://telegram.me/SoftwarePhilosophy/607
۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimate
https://telegram.me/SoftwarePhilosophy/608
۵. پرسش و پاسخهایی در زمینه Code Review
#scrum #codereview
https://telegram.me/SoftwarePhilosophy/609
۶. طراحی responsive و نحوه انتخاب نقاط شکست
#responsive
https://telegram.me/SoftwarePhilosophy/610
۷. کد تخفیف «استارتاپ ویکند» برای اعضای کانال SoftwarePhilosophy
https://telegram.me/SoftwarePhilosophy/611
ـــــــــــ
@SoftwarePhilosophy
۱. مدل اسپاتیفای را کپی نکنید. (iranagile)
#srcum
https://telegram.me/SoftwarePhilosophy/605
۲. الگوی Async Retry Pattern
#async #csharp
https://telegram.me/SoftwarePhilosophy/606
۳. آیا در پروژههای بزرگ هم یک نفر تصمیم گیرنده است؟ (iranagile)
#srcum
https://telegram.me/SoftwarePhilosophy/607
۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimate
https://telegram.me/SoftwarePhilosophy/608
۵. پرسش و پاسخهایی در زمینه Code Review
#scrum #codereview
https://telegram.me/SoftwarePhilosophy/609
۶. طراحی responsive و نحوه انتخاب نقاط شکست
#responsive
https://telegram.me/SoftwarePhilosophy/610
۷. کد تخفیف «استارتاپ ویکند» برای اعضای کانال SoftwarePhilosophy
https://telegram.me/SoftwarePhilosophy/611
ـــــــــــ
@SoftwarePhilosophy
مفهوم Asynchronous Programming در Java تاثیر بسیار خوبی در عملکرد نرمافزارهای بزرگ و قابلیت Scale شدن آنها دارد. در این مدل thread های استفاده شده در عملیات I/O Blocking باعث میشود resource های ارزشمند سرور به هدر نرود و از آنها به درستی استفاده شود. یکی از مشکلات این سبک برنامهنویسی «سخت بودن» آن است. نوشتن این نوع کدها معمولا پیچیدهتر از کدهای معمولی است. مهمترین مفهوم در این سبک برنامهنویسی مفهوم Feature است که به معنی کاری است که در آینده انجام خواهد شد و نتیجه آن بعدا آماده میشود. برای مثال Feature<String> کاری است که در آینده یک نتیجه از نوع String خواهد برگرداند.
پست زیر در مورد این مفهوم و best practice های استفاده از آن توضیح دادهاست.
http://www.developer.com/java/data/best-practices-of-asynchronous-programming-with-java.html
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
پست زیر در مورد این مفهوم و best practice های استفاده از آن توضیح دادهاست.
http://www.developer.com/java/data/best-practices-of-asynchronous-programming-with-java.html
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Developer
Best Practices of Asynchronous Programming With Java - Developer.com
Become adept with using best practices that should be followed while writing code to perform asynchronous operations in Java.
تخفیف برای اعضای کانال @SoftwarePhilosophy
کد تخفیف: SoftwarePhilosophy
ثبتنام در: http://modotech.ir
این تخفیف تا روز دوشنبه اعتبار دارد و برای تعداد محدودی قابل استفاده است.
کد تخفیف: SoftwarePhilosophy
ثبتنام در: http://modotech.ir
این تخفیف تا روز دوشنبه اعتبار دارد و برای تعداد محدودی قابل استفاده است.
#پست_مجدد این پست تا به حال بیش از ۱۳۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
گرافیک سه بعدی کامپیوتری و ساخت بازیهای کامپیوتری جز تکنولوژیهای پیچیده محسوب میشود. اینکه یک ویدئو ساخته شده سه بعدی بتواند کاملا واقعی به نظر برسد کاری بسیار سخت است. در حقیقت ۳ عامل خیلی مهم وجود دارد که باعث واقعی شدن یک نمایش گرافیکی سه بعدی میشود.
۱. حرکتهای طبیعی (Motion)
۲. سایهها (Shadow)
۳. بافتها (Texture)
مفهوم سایه فقط به سایه جسم روی زمین ختم نمیشود. به عنوان مثال، برای اینکه موهای یک شخص طبیعی دیده شود سایه تک تک تارهای مو باید به درستی روی بقیه تارهای مو بیفتد و این یعنی حجم وحشتناکی از محاسبات در ثانیه! مفهوم بافت مفهومی است که به یک مدل سه بعدی معنای قابل لمس میدهد و آن را برای ما ملموس میکند.
ویدئوی زیر که توسط شرکت Method Studios ساخته شدهاست یکی از نمونههای فوقالعاده است که سه مفهوم بالا در آن به زیبایی نمایش داده شدهاست.
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
۱. حرکتهای طبیعی (Motion)
۲. سایهها (Shadow)
۳. بافتها (Texture)
مفهوم سایه فقط به سایه جسم روی زمین ختم نمیشود. به عنوان مثال، برای اینکه موهای یک شخص طبیعی دیده شود سایه تک تک تارهای مو باید به درستی روی بقیه تارهای مو بیفتد و این یعنی حجم وحشتناکی از محاسبات در ثانیه! مفهوم بافت مفهومی است که به یک مدل سه بعدی معنای قابل لمس میدهد و آن را برای ما ملموس میکند.
ویدئوی زیر که توسط شرکت Method Studios ساخته شدهاست یکی از نمونههای فوقالعاده است که سه مفهوم بالا در آن به زیبایی نمایش داده شدهاست.
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
نحوه تعریف متغییرها در یک برنامه می تواند تاثیر زیادی بر کارآیی برنامه داشته باشد. مقاله زیر با زبانی ساده نشان می دهد که چگونه boxing و unboxing می تواند بر بهینه سازی برنامه تاثیر داشته باشد و شش مفهوم Stack ، Heap ، Value type ، Reference Type ، boxing و unboxing را توضیح داده است. همچنین در این مقاله مشاهده میکنید که چگونه Cast کردنهای بیهوده میتواند سرعت برنامه ما را تحت تاثیر قرار دهد.
http://www.codeproject.com/Articles/76153/Six-important-NET-concepts-Stack-heap-value-types
#کاروان_جافی
لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027
کانال تلگرام:
@SoftwarePhilosophy
___
http://www.codeproject.com/Articles/76153/Six-important-NET-concepts-Stack-heap-value-types
#کاروان_جافی
لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027
کانال تلگرام:
@SoftwarePhilosophy
___
CodeProject
Six Important .NET Concepts: Stack, Heap, Value Types, Reference Types, Boxing, and Unboxing
An introduction to stack, heap, value types, reference types, boxing, and unboxing
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
کتابخانه Audit.Net کتابخانه فوقالعادهای است که امکان هندل کردن تمامی سناریوهای مربوط به لاگ کردن و Audit را با معماری بسیار زیبایی در اختیار معماران نرمافزار میگذارد. این کتابخانه از فلسفه Convenction over Configuration استفاده کرده و برای تنظیم کردن آن علاوه بر روشهای متداول، به زیبایی از Fluent API استفاده شدهاست.
مساله Audit کردن عملیات برنامه همیشه انرژی زیادی از برنامهنویسان سیستمهای بزرگ میگیرد. ساخت Audit در مکانهای مختلف برنامه میتوانید اتفاق بیافتد. برای مثال در بستر Object، EntityFramework، WebApi، WCF و بسترهای دیگر میتوان فرایند Audit را فعال کرد. پیچیدگی دیگر مربوط به نحوه ذخیرهسازی Audit است. میتوان آنها را در File، Event Log، Sql Database، NoSQL Database، Azure Blob Store و بسترهای مختلف دیگر ذخیره کرد.
https://github.com/thepirat000/Audit.NET
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
مساله Audit کردن عملیات برنامه همیشه انرژی زیادی از برنامهنویسان سیستمهای بزرگ میگیرد. ساخت Audit در مکانهای مختلف برنامه میتوانید اتفاق بیافتد. برای مثال در بستر Object، EntityFramework، WebApi، WCF و بسترهای دیگر میتوان فرایند Audit را فعال کرد. پیچیدگی دیگر مربوط به نحوه ذخیرهسازی Audit است. میتوان آنها را در File، Event Log، Sql Database، NoSQL Database، Azure Blob Store و بسترهای مختلف دیگر ذخیره کرد.
https://github.com/thepirat000/Audit.NET
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
GitHub
GitHub - thepirat000/Audit.NET: An extensible framework to audit executing operations in .NET and .NET Core.
An extensible framework to audit executing operations in .NET and .NET Core. - thepirat000/Audit.NET
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
انتخاب تکنولوژی درست برای طراحی لایه سرویس یکی از اولین مسائلی است که برنامه نویسان در شروع پروژههای بزرگ با آن روبرو میشوند و بیشتر برنامه نویسان سعی میکنند از تکنولوژی استفاده کنند که بیشتر با آن آشنا هستند که گاهی تصمیم درستی نیست. مطالعه مقاله زیر می تواند برای برنامه نویسان دات نت در انتخاب تکنولوژی مناسب کمک کننده باشد.
http://www.infoworld.com/article/2905918/microsoft-net/choosing-the-right-technology-for-building-your-service-layer-in-net.html
#کاروان_جافی
لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027
کانال تلگرام:
@SoftwarePhilosophy
___
http://www.infoworld.com/article/2905918/microsoft-net/choosing-the-right-technology-for-building-your-service-layer-in-net.html
#کاروان_جافی
لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027
کانال تلگرام:
@SoftwarePhilosophy
___
InfoWorld
Choosing the right technology for building the service layer in .NET
There are many different considerations you need to think over before you decide the right technology for the service layer in your application