Forwarded from Software Philosophy
فریمورک Bootstrap به عنوان یکی از محبوبترین فریمورکهای CSS شناخته میشود. این فریمورک به حدی محبوب شدهاست که آشنایی با آن در بسیاری از جلسات مصاحبه فنی برای موقعیت Front-End Developer حیاتی است.
لینک زیر سوالات متداولی که در جلسات مصاحبه با نیروهای جدید در مورد این فریمورک پرسیده میشود مطرح شدهاند.
https://www.c-sharpcorner.com/article/top-bootstrap-interview-questions-and-answers
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
لینک زیر سوالات متداولی که در جلسات مصاحبه با نیروهای جدید در مورد این فریمورک پرسیده میشود مطرح شدهاند.
https://www.c-sharpcorner.com/article/top-bootstrap-interview-questions-and-answers
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
C-Sharpcorner
Top Bootstrap Interview Questions And Answers
In this article you will learn about the top Bootstrap interview questions and answers.
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
امروزه استفاده از فریم ورکهای css برای برنامه نویسان front end بسیار رایج است.
فریم ورکهای زیادی در این راستا وجود دارد ولی تعداد محدودی از آنها به عنوان فریم ورک خوب شناخته شده اند.
مقاله زیر به صورت خلاصه به معرفی و بررسی 5 فریم ورک برتر پرداخته است و نقاط قوت و ضعف آنها را بیان کرده است.
این 5 فریم ورکها عبارتند از:
• Bootstrap
• Fundation by ZURB
• Semantic UI
• Pure by Yahoo
• Ukit by YOOtheme
https://www.sitepoint.com/5-most-popular-frontend-frameworks-compared
#مریم_داودی
لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a
کانال تلگرام:
@SoftwarePhilosophy
___
فریم ورکهای زیادی در این راستا وجود دارد ولی تعداد محدودی از آنها به عنوان فریم ورک خوب شناخته شده اند.
مقاله زیر به صورت خلاصه به معرفی و بررسی 5 فریم ورک برتر پرداخته است و نقاط قوت و ضعف آنها را بیان کرده است.
این 5 فریم ورکها عبارتند از:
• Bootstrap
• Fundation by ZURB
• Semantic UI
• Pure by Yahoo
• Ukit by YOOtheme
https://www.sitepoint.com/5-most-popular-frontend-frameworks-compared
#مریم_داودی
لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a
کانال تلگرام:
@SoftwarePhilosophy
___
SitePoint
The 5 Most Popular Front-end Frameworks Compared — SitePoint
Ivaylo Gerchev looks at the most downloaded front-end frameworks available today, and offers some suggestions on how to choose one that's right for you.
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
ابزارهای TFS و JIRA از ابزارهای معروف Issue Tracking در پروژههای نرمافزاری هستند. با اینکه این ابزارها قابلیت استفاده مستقل از تکنولوژی دارند اما عمدتا در پروژههای با تکنولوژیهای مایکروسافت از TFS و در پروژههایی با تکنولوژیهای Java از JIRA استفاده میشود.
مقاله زیر خلاصهی نتیجهی یک تحقیق عملی دربارهی قابلیتهای این دو ابزار ارائه شدهاست. تحقیق به این صورت بوده که یک تیم چهارنفره به دو گروه تقسیم شدهاند و یکی از گروهها با JIRA و دیگری با TFS کار کرده و در پایان قابلیتها را با هم مقایسه کردهاند. در این مقاله به صورت خلاصه واژههای مرتبط مانند CI و ALM هم توضیح داده شدهاند. هدف این مقاله معرفی معیارهایی است که کمک کند در هر شرایطی بهترین انتخاب اتفاق بیافتد.
https://blog.beolle.com/2014/01/research-around-jira-vs-tfs.html
#سمیه_کرمی
لینکدین :
https://ir.linkedin.com/in/skarami
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر خلاصهی نتیجهی یک تحقیق عملی دربارهی قابلیتهای این دو ابزار ارائه شدهاست. تحقیق به این صورت بوده که یک تیم چهارنفره به دو گروه تقسیم شدهاند و یکی از گروهها با JIRA و دیگری با TFS کار کرده و در پایان قابلیتها را با هم مقایسه کردهاند. در این مقاله به صورت خلاصه واژههای مرتبط مانند CI و ALM هم توضیح داده شدهاند. هدف این مقاله معرفی معیارهایی است که کمک کند در هر شرایطی بهترین انتخاب اتفاق بیافتد.
https://blog.beolle.com/2014/01/research-around-jira-vs-tfs.html
#سمیه_کرمی
لینکدین :
https://ir.linkedin.com/in/skarami
کانال تلگرام:
@SoftwarePhilosophy
___
Beolle
Research around JIRA vs TFS - Beolle Ideas
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آزمونی برای سنجش سلامت یک تیم مهندسی (Iran Agile)
#softwareprocess #sdlc
https://t.iss.one/SoftwarePhilosophy/702
۲. مفهوم Computer Vision یا «بینایی کامپیوتری» و مثالهایی از C#
#csharp #computervision #ai
https://t.iss.one/SoftwarePhilosophy/704
۳. اس کیو ال سرور برای لینوکس (High Tec SQL)
#sqlserver #linux
https://t.iss.one/SoftwarePhilosophy/705
۴. سوالات متداولی جلسات مصاحبه نیروهای جدید در مورد فریمورک Bootstrap
#bootstrap #css
https://t.iss.one/SoftwarePhilosophy/707
۵. آشنایی با ۵ فریمورک برتر CSS
#css #framework
https://t.iss.one/SoftwarePhilosophy/709
۶. آشنایی و مقایسه ابزارهای TFS و JIRA
#tfs #jira
https://t.iss.one/SoftwarePhilosophy/711
ـــــــــــ
@SoftwarePhilosophy
۱. آزمونی برای سنجش سلامت یک تیم مهندسی (Iran Agile)
#softwareprocess #sdlc
https://t.iss.one/SoftwarePhilosophy/702
۲. مفهوم Computer Vision یا «بینایی کامپیوتری» و مثالهایی از C#
#csharp #computervision #ai
https://t.iss.one/SoftwarePhilosophy/704
۳. اس کیو ال سرور برای لینوکس (High Tec SQL)
#sqlserver #linux
https://t.iss.one/SoftwarePhilosophy/705
۴. سوالات متداولی جلسات مصاحبه نیروهای جدید در مورد فریمورک Bootstrap
#bootstrap #css
https://t.iss.one/SoftwarePhilosophy/707
۵. آشنایی با ۵ فریمورک برتر CSS
#css #framework
https://t.iss.one/SoftwarePhilosophy/709
۶. آشنایی و مقایسه ابزارهای TFS و JIRA
#tfs #jira
https://t.iss.one/SoftwarePhilosophy/711
ـــــــــــ
@SoftwarePhilosophy
فرایند آموزش در تکنولوژیهای جدید بسیار موضوع مهمی است. از آنجایی که تکنولوژیها و زبانهای جدید به شدت در حال رشد و تغییر هستند وجود فرایندها و محیطهای آموزشی مناسب یکی از دغدغههای خالقان این تکنولوژیها است.
یکی از روشهای مرسوم ساخت ابزارهایی به نام Play Ground برای آزمایش زبانها و تکنولوژیها است. پروژه Xamarin Workbooks و یا بهتر است بگوییم .Net Workbook یکی از پروژههای جذابی است که یک Play Ground فوقالعاده برای آزمایش و یادگیری C#, iOS, Android, Azure, Kinect و ... مهیا کرده است.
در این پروژه میتوان ترکیبی از مستند و کد را ایجاد کرد که قدرت آموزشی بالایی دارد. این پروژه آنقدر جذاب است که Scott Hanselman تصمیم گرفته که در جلسات آموزشی از آن برای آموزش مفاهیم استفاده کند.
اسکات هانسلمن در بلاگ خود کمی در مورد آن توضیح دادهاست. پیشنهاد میکنم حتما Xamarin Workbooks را دانلود کنید و turotial آن را دنبال کنید.
https://www.hanselman.com/blog/XamarinNETWorkbooksInteractiveComputingIsAStellarLearningTool.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/qJR1309lG26
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
یکی از روشهای مرسوم ساخت ابزارهایی به نام Play Ground برای آزمایش زبانها و تکنولوژیها است. پروژه Xamarin Workbooks و یا بهتر است بگوییم .Net Workbook یکی از پروژههای جذابی است که یک Play Ground فوقالعاده برای آزمایش و یادگیری C#, iOS, Android, Azure, Kinect و ... مهیا کرده است.
در این پروژه میتوان ترکیبی از مستند و کد را ایجاد کرد که قدرت آموزشی بالایی دارد. این پروژه آنقدر جذاب است که Scott Hanselman تصمیم گرفته که در جلسات آموزشی از آن برای آموزش مفاهیم استفاده کند.
اسکات هانسلمن در بلاگ خود کمی در مورد آن توضیح دادهاست. پیشنهاد میکنم حتما Xamarin Workbooks را دانلود کنید و turotial آن را دنبال کنید.
https://www.hanselman.com/blog/XamarinNETWorkbooksInteractiveComputingIsAStellarLearningTool.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/qJR1309lG26
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Hanselman
Xamarin .NET Workbooks - Interactive Computing is a stellar learning tool
I've been thinking a lot about how to best teach .NET and C#/F# to folks who are new to the space. We've added an ...
Forwarded from Iran .Net
چیزی که شرکت ها را ورشکست می کند، بدهی فنی است نه بدهی مالی
اصطلاح بدهی فنی (Technical Debt) اساسا برای این به وجود آمد تا افراد حوزه بیزینس و مدیران را متوجه آسیبی کند که با فرامین نابجا، زمان بندی های تنگ و ترش و دید غیرواقعی و غیرمهندسی شان می توانند به نرم افزارها وارد کنند. از آنجایی که این دسته از افراد نسبت به بدهی مالی حساس هستند و درک بسیار خوبی از آن دارند، از عبارت بدهی فنی استفاده می کنیم تا بتوانیم حساسیت آن ها را جلب کنیم.
برای توسعه نرم افزار و هر جزیی از آن، همواره دو راه پیش روی ماست. یکی توسعه ای تمیز و ساختارمند و اصولی و دیگری راه حل های کثیف و میانبر. مزیت روش دوم بر روش اول آن است که زمان توسعه به شدت کوتاه تر می شود و خیلی سریع تر می توانیم محصول را به بازار برسانیم. در صورتی که در پیش گرفتن روش دوم، زمان بیشتری برای توسعه نیاز خواهد داشت.
مشکل آنجاست که افراد حوزه بیزینس عمدتا به چیزی جز رساندن سریع تر محصول به بازار فکر نمی کنند. آن ها نمی دانند که با در نظر گرفتن زمانبندی های کوتاه و تحت فشار قرار دادن برنامه نویس ها، اگر چه کارشان زودتر اماده می شود ولی زیر بار بدهی سنگینی رفته اند که اگر هرچه زودتر پرداخت نکنند، تمام کسب و کار و نیروی انسانی نخبه شان را از دست خواهند داد. آن ها با گرفتن وام ( کاهش زمان و تحت فشار قرار دادن توسعه دهندگان و کدهای کثیف و میانبر و ابهامات باقی مانده در کد) کارشان انجام شده ولی این وام باید با سود بسیار بالایی بازپرداخت شود. نکته آنجاست که هر چقدر این بدهی دیرتر پرداخت شود، نرخ بهره چندین برابر خواهد شد و در نهایت سازمان را به جایی می رساند که توان تکان خوردن و اصلاح و بازپرداخت نخواهد داشت.
بازپرداخت بدهی فنی یعنی refactor کردن کد و تر و تمیز کردن نرم افزار و قطعا هر چه زمان بیشتری گذشته باشد، این امر به تدریج غیرممکن خواهد شد. در نتیجه دیگر در این کد نمی توان ویژگی ها را به سرعت اضافه کرد و هر تغییری منجر به شکست سایر نقاط خواهد شد و عواقب پیشبینی نشده خواهد داشت. کد به تدریج به کدی کهنه تبدیل می شود که از اصول و روش های مدرن فاصله خواهد گرفت. توسعه محصولی که به سرعت وارد بازار شده بود، به شدت کند خواهد شد و باگ هایش و سرویس دهی پایین اش سازمان را دچار بحران اعتبار در میان مشتریان اش خواهد کرد که بزرگ ترین آسیب می باشد.
از سوی دیگر سازمان در تعامل با نیروهای برنامه نویس اش به مرور درمانده خواهد شد. آن ها با کدی کهنه و بد درگیر خواهند شد و اشتیاقی به ادامه کار نخواهند داشت. از دوستان و رقبای شان عقب خواهند افتاد، سازمان به دلیل کندی کارها و عدم پیشرفت مناسب از آن ها ناراضی است و هر کسی کار را به دوش دیگری می اندازد و دیگری را مقصر می دانند و به مرور کد بدتر و بدتر خواهد شد، کیفیت پایین می آید و برنامه نویس ها به دلیل نارضایتی از سازمان می روند و یا تنش بین آن ها ایجاد خواهد شد و در نهایت هم بیزینس ضربه سنگینی از این موضوع خواهد خورد.
همه این ها هم به خاطر بدهی فنی ایی است که هیچگاه توسط مدیریت سازمان دیده و بازپرداخت نشده است.
اصطلاح بدهی فنی (Technical Debt) اساسا برای این به وجود آمد تا افراد حوزه بیزینس و مدیران را متوجه آسیبی کند که با فرامین نابجا، زمان بندی های تنگ و ترش و دید غیرواقعی و غیرمهندسی شان می توانند به نرم افزارها وارد کنند. از آنجایی که این دسته از افراد نسبت به بدهی مالی حساس هستند و درک بسیار خوبی از آن دارند، از عبارت بدهی فنی استفاده می کنیم تا بتوانیم حساسیت آن ها را جلب کنیم.
برای توسعه نرم افزار و هر جزیی از آن، همواره دو راه پیش روی ماست. یکی توسعه ای تمیز و ساختارمند و اصولی و دیگری راه حل های کثیف و میانبر. مزیت روش دوم بر روش اول آن است که زمان توسعه به شدت کوتاه تر می شود و خیلی سریع تر می توانیم محصول را به بازار برسانیم. در صورتی که در پیش گرفتن روش دوم، زمان بیشتری برای توسعه نیاز خواهد داشت.
مشکل آنجاست که افراد حوزه بیزینس عمدتا به چیزی جز رساندن سریع تر محصول به بازار فکر نمی کنند. آن ها نمی دانند که با در نظر گرفتن زمانبندی های کوتاه و تحت فشار قرار دادن برنامه نویس ها، اگر چه کارشان زودتر اماده می شود ولی زیر بار بدهی سنگینی رفته اند که اگر هرچه زودتر پرداخت نکنند، تمام کسب و کار و نیروی انسانی نخبه شان را از دست خواهند داد. آن ها با گرفتن وام ( کاهش زمان و تحت فشار قرار دادن توسعه دهندگان و کدهای کثیف و میانبر و ابهامات باقی مانده در کد) کارشان انجام شده ولی این وام باید با سود بسیار بالایی بازپرداخت شود. نکته آنجاست که هر چقدر این بدهی دیرتر پرداخت شود، نرخ بهره چندین برابر خواهد شد و در نهایت سازمان را به جایی می رساند که توان تکان خوردن و اصلاح و بازپرداخت نخواهد داشت.
بازپرداخت بدهی فنی یعنی refactor کردن کد و تر و تمیز کردن نرم افزار و قطعا هر چه زمان بیشتری گذشته باشد، این امر به تدریج غیرممکن خواهد شد. در نتیجه دیگر در این کد نمی توان ویژگی ها را به سرعت اضافه کرد و هر تغییری منجر به شکست سایر نقاط خواهد شد و عواقب پیشبینی نشده خواهد داشت. کد به تدریج به کدی کهنه تبدیل می شود که از اصول و روش های مدرن فاصله خواهد گرفت. توسعه محصولی که به سرعت وارد بازار شده بود، به شدت کند خواهد شد و باگ هایش و سرویس دهی پایین اش سازمان را دچار بحران اعتبار در میان مشتریان اش خواهد کرد که بزرگ ترین آسیب می باشد.
از سوی دیگر سازمان در تعامل با نیروهای برنامه نویس اش به مرور درمانده خواهد شد. آن ها با کدی کهنه و بد درگیر خواهند شد و اشتیاقی به ادامه کار نخواهند داشت. از دوستان و رقبای شان عقب خواهند افتاد، سازمان به دلیل کندی کارها و عدم پیشرفت مناسب از آن ها ناراضی است و هر کسی کار را به دوش دیگری می اندازد و دیگری را مقصر می دانند و به مرور کد بدتر و بدتر خواهد شد، کیفیت پایین می آید و برنامه نویس ها به دلیل نارضایتی از سازمان می روند و یا تنش بین آن ها ایجاد خواهد شد و در نهایت هم بیزینس ضربه سنگینی از این موضوع خواهد خورد.
همه این ها هم به خاطر بدهی فنی ایی است که هیچگاه توسط مدیریت سازمان دیده و بازپرداخت نشده است.
Forwarded from Software Philosophy
اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرمافزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.
این پیغام را برای آنها Forward کنید.
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
نرمافزار Continuous یک IDE سریع و قوی برای C# و F# است که مستقیما روی iPad و iPhone بدون نیاز به شبکه اجرا می شود. با استفاده از این IDE می توانید اپ ها و بازیها را روی دیوایس خود کد بزنید و اجرا کنید. نحوه عمکرد Continuous به صورت تعاملی است به این معنا که دائما کد شما را اجرا می کند و می توانید به محض تغییر در کد تاثیر آن را در اجرای برنامه ببینید.
https://continuous.codes/
#سپیده_قنبری
لینکدین:
https://ir.linkedin.com/in/sepideh-ghanbari-584ba25a
کانال تلگرام:
@SoftwarePhilosophy
https://continuous.codes/
#سپیده_قنبری
لینکدین:
https://ir.linkedin.com/in/sepideh-ghanbari-584ba25a
کانال تلگرام:
@SoftwarePhilosophy
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
اضافه کردن فیچر به نرمافزار غالبا ویژگی مثبتی به نظر میرسد. ولی وقتی تیمی دارید که قدرت بسیار بالایی دارد اضافه کردن فیچرها با سرعت خیلی زیاد خودش میتواند نکات منفی داشته باشد. وقتی قدرت اضافه کردن امکانات با سرعت زیاد دارید باید محتاط باشید که امکانات جدید راهحلهایی جدید برای یک مسئله حل شده نباشند. داشتن تیم قدرتمند این قدرت را به مدیران میدهد که بتوانند سریع ایدههای ذهنی خود را پیادهسازی کنند. در این حین باید مراقب بود این امکانات با هم، همپوشانی نداشته باشند.
مثال زیر از تیم توسعه C# آورده شدهاست که در مورد کاربرد دو امکان این زبان که در نسخههای ۵ و ۶ اضافه شد صحبت میکند.
https://mehrandvd.me/2016/05/02/steady-consistent-flow-features/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
مثال زیر از تیم توسعه C# آورده شدهاست که در مورد کاربرد دو امکان این زبان که در نسخههای ۵ و ۶ اضافه شد صحبت میکند.
https://mehrandvd.me/2016/05/02/steady-consistent-flow-features/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Forwarded from Iran .Net
قابلیت Always Encrypted در SQL Server 2016
این ویژگی که در آخرین نسخه SQL Server 2016 پیاده سازی شده است، کمک می کند تا اطلاعات به صورت رمز شده در پایگاه داده قرار بگیرند. در نتیجه مثلا در سازمان ها بین کسانی که مالک داده هستند و کسانی که داده ها را مدیریت (dba ها) می کنند می توانیم تفاوت قائل شویم و مطمئن باشیم اطلاعات حساس مالی، شخضی، هویتی، تجاری و اسناد ... توسط افرادی که به پایگاه داده دسترسی دارند خوانده نخواهد شد.
در این روش شما مشخص می کنید که چه ستون هایی از چه جداولی لازم است رمزنگاری شوند. پس از انجام رمزنگاری، داده ها به صورت رمز شده در دیتابیس قرار خواهند گرفت و خواندن شان غیر ممکن خواهد بود. در این روش، داده ها به صورت رمز شده به اپلیکیشن فرستاده می شوند و این مسئولیت درایورِ ارتباطیِ کلاینت می باشد که داده ها را به محض دریافت رمزگشایی کرده و به اپلیکیشن تحویل دهد. در واقع تنها سیستمی که کلاینت در آن مستقر هست می تواند داده ها را باز کند و نه دیتابیس.
این روش رمزنگاری مستقل از لایه نرم افزار خواهد بود و نیازی به پیاده سازی روش های پیچیده و من درآوردی و ... در کد نخواهیم داشت.
این روش علی رغم مزیت هایش دارای محدودیت هایی هم می باشد که مهم ترین شان به نظر من موارد زیر می باشند:
1. در حال حاضر قابلیت Replication را بر روی ستون های رمز شده نخواهیم داشت.
2. در مورد Index گذاری، Join و عملگرهای مقایسه ای دارای محدودیت هایی هستیم.
در این روش دو نوع کلید به منظور انجام رمزنگاری ساخته خواهد شد، قطعا فهم مکانیزم کارکرد این کلید ها، مراقبت و نگهداری از آن ها برای حفظ امنیت داده ها ضروری است. در غیر این صورت هر کس با داشتن کلید ها می تواند داده ها را بخواند. این کلید ها باید بر روی هر سرور یا کامپیوتری که قرار هست نرم افزار بر روی آن ها قرار داده باشد، موجود باشد. نرم افزار با داشتن این کلید ها می تواند داده ها را رمز گشایی کند.
1. معرفی ویژگی Always Encrypted:
https://msdn.microsoft.com/en-us/library/mt163865.aspx
2. تشریح کلید ها و نکاتی جهت نگهداری آن ها:
https://msdn.microsoft.com/en-us/library/mt708953.aspx
3. مثالی عملی و ساده از کانفیگ دیتابیس، کلید ها و برنامه:
https://www.databasejournal.com/features/mssql/exploration-of-sql-server-2016-always-encrypted-part-1.html
4. توضیح محدودیت ها:
https://www.infoq.com/news/2015/06/SQL-Server-Always-Encrypted
https://www.sqlchamp.com/2016/07/limitations-always-encrypted/337
@irandotnet
این ویژگی که در آخرین نسخه SQL Server 2016 پیاده سازی شده است، کمک می کند تا اطلاعات به صورت رمز شده در پایگاه داده قرار بگیرند. در نتیجه مثلا در سازمان ها بین کسانی که مالک داده هستند و کسانی که داده ها را مدیریت (dba ها) می کنند می توانیم تفاوت قائل شویم و مطمئن باشیم اطلاعات حساس مالی، شخضی، هویتی، تجاری و اسناد ... توسط افرادی که به پایگاه داده دسترسی دارند خوانده نخواهد شد.
در این روش شما مشخص می کنید که چه ستون هایی از چه جداولی لازم است رمزنگاری شوند. پس از انجام رمزنگاری، داده ها به صورت رمز شده در دیتابیس قرار خواهند گرفت و خواندن شان غیر ممکن خواهد بود. در این روش، داده ها به صورت رمز شده به اپلیکیشن فرستاده می شوند و این مسئولیت درایورِ ارتباطیِ کلاینت می باشد که داده ها را به محض دریافت رمزگشایی کرده و به اپلیکیشن تحویل دهد. در واقع تنها سیستمی که کلاینت در آن مستقر هست می تواند داده ها را باز کند و نه دیتابیس.
این روش رمزنگاری مستقل از لایه نرم افزار خواهد بود و نیازی به پیاده سازی روش های پیچیده و من درآوردی و ... در کد نخواهیم داشت.
این روش علی رغم مزیت هایش دارای محدودیت هایی هم می باشد که مهم ترین شان به نظر من موارد زیر می باشند:
1. در حال حاضر قابلیت Replication را بر روی ستون های رمز شده نخواهیم داشت.
2. در مورد Index گذاری، Join و عملگرهای مقایسه ای دارای محدودیت هایی هستیم.
در این روش دو نوع کلید به منظور انجام رمزنگاری ساخته خواهد شد، قطعا فهم مکانیزم کارکرد این کلید ها، مراقبت و نگهداری از آن ها برای حفظ امنیت داده ها ضروری است. در غیر این صورت هر کس با داشتن کلید ها می تواند داده ها را بخواند. این کلید ها باید بر روی هر سرور یا کامپیوتری که قرار هست نرم افزار بر روی آن ها قرار داده باشد، موجود باشد. نرم افزار با داشتن این کلید ها می تواند داده ها را رمز گشایی کند.
1. معرفی ویژگی Always Encrypted:
https://msdn.microsoft.com/en-us/library/mt163865.aspx
2. تشریح کلید ها و نکاتی جهت نگهداری آن ها:
https://msdn.microsoft.com/en-us/library/mt708953.aspx
3. مثالی عملی و ساده از کانفیگ دیتابیس، کلید ها و برنامه:
https://www.databasejournal.com/features/mssql/exploration-of-sql-server-2016-always-encrypted-part-1.html
4. توضیح محدودیت ها:
https://www.infoq.com/news/2015/06/SQL-Server-Always-Encrypted
https://www.sqlchamp.com/2016/07/limitations-always-encrypted/337
@irandotnet
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آشنایی با Xamarin Workbooks
#xamarin #dotnet
https://t.iss.one/SoftwarePhilosophy/713
۲. بدهی فنی چیست؟ (ایران دات نت)
#softwareengineering #technicaldept
https://t.iss.one/SoftwarePhilosophy/714
۳. محیط برنامهنویسی Continuous، یک محیط جذاب روی iPad و iPhone برای برنامهنویسی به زبانهای C# , F#
#crossplatform #csharp #fsharp #iphone
https://t.iss.one/SoftwarePhilosophy/717
۴. کنترل سرعت اضافه کردن فیچر به نرمافزار
#softwareengineering
https://t.iss.one/SoftwarePhilosophy/719
۵. قابلیت Always Encrypted در SQL Server 2016 (ایران دات نت)
#sqlserver
https://t.iss.one/SoftwarePhilosophy/720
ـــــــــــ
@SoftwarePhilosophy
۱. آشنایی با Xamarin Workbooks
#xamarin #dotnet
https://t.iss.one/SoftwarePhilosophy/713
۲. بدهی فنی چیست؟ (ایران دات نت)
#softwareengineering #technicaldept
https://t.iss.one/SoftwarePhilosophy/714
۳. محیط برنامهنویسی Continuous، یک محیط جذاب روی iPad و iPhone برای برنامهنویسی به زبانهای C# , F#
#crossplatform #csharp #fsharp #iphone
https://t.iss.one/SoftwarePhilosophy/717
۴. کنترل سرعت اضافه کردن فیچر به نرمافزار
#softwareengineering
https://t.iss.one/SoftwarePhilosophy/719
۵. قابلیت Always Encrypted در SQL Server 2016 (ایران دات نت)
#sqlserver
https://t.iss.one/SoftwarePhilosophy/720
ـــــــــــ
@SoftwarePhilosophy
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
فلسفه Spacive Design جایگزینی برای Responsive Design
چند سالی است که طراحی Responsive به عنوان یکی از مهمترین فلسفههای طراحی برنامههای جدید شناخته میشود. اگر به علت ظهور این مدل تفکر در طراحی فکر کنید ظهور دستگاههایی با اندازههای مختلف و با امکانات شبیه هم باعث خلق چنین تفکری شده، نوعی طراحی که بتوان کاربری مناسبی روی دستگاههای با اندازه مختلف داشته باشد.
بنابراین ظهور یک دستگاه میتواند باعث ایجاد فلسفههای جدید طراحی شود. در یک سال اخیر به نظر میرسد یک مدیای جدید در راه است. دستگاههایی که امکان ایجاد واقعیت مجازی دارند. شرکتهای بزرگی مانند گوگل، سونی و مایکروسافت در حال هدایت این بازار هستند. به نظر من ورود این دستگاهها به بازار باعث ایجاد فلسفههای جدیدی در طراحی میشود.
هنوز خیلی زود است که بتوان در مورد آینده طراحی UI/UX اظهار نظر کرد. ولی به نظر من یکی از آینده های محتمل برای طراحی UI/UX نسل آینده نرمافزارها طراحی «فضاگرا» است. طراحی فضاگرا نوعی طراحی نرمافزار است که به آن این امکان را میدهد تا قسمتهای مختلف خود را در فضای اطراف کاربر پخش کند. برای مثال فرض کنید هنگام کار با فیسبوک، تایملاین را روی دیوار روبروی خود ببینید و نوتیفیکیشنها رو روی ساعد خود ببینید. به این ترتیب نرمافزار فیسبوک توانسته در فضای اطراف شما مستقر شود.
https://mehrandvd.me/2016/07/12/hololens-spacive-design-new-era-uiux/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
چند سالی است که طراحی Responsive به عنوان یکی از مهمترین فلسفههای طراحی برنامههای جدید شناخته میشود. اگر به علت ظهور این مدل تفکر در طراحی فکر کنید ظهور دستگاههایی با اندازههای مختلف و با امکانات شبیه هم باعث خلق چنین تفکری شده، نوعی طراحی که بتوان کاربری مناسبی روی دستگاههای با اندازه مختلف داشته باشد.
بنابراین ظهور یک دستگاه میتواند باعث ایجاد فلسفههای جدید طراحی شود. در یک سال اخیر به نظر میرسد یک مدیای جدید در راه است. دستگاههایی که امکان ایجاد واقعیت مجازی دارند. شرکتهای بزرگی مانند گوگل، سونی و مایکروسافت در حال هدایت این بازار هستند. به نظر من ورود این دستگاهها به بازار باعث ایجاد فلسفههای جدیدی در طراحی میشود.
هنوز خیلی زود است که بتوان در مورد آینده طراحی UI/UX اظهار نظر کرد. ولی به نظر من یکی از آینده های محتمل برای طراحی UI/UX نسل آینده نرمافزارها طراحی «فضاگرا» است. طراحی فضاگرا نوعی طراحی نرمافزار است که به آن این امکان را میدهد تا قسمتهای مختلف خود را در فضای اطراف کاربر پخش کند. برای مثال فرض کنید هنگام کار با فیسبوک، تایملاین را روی دیوار روبروی خود ببینید و نوتیفیکیشنها رو روی ساعد خود ببینید. به این ترتیب نرمافزار فیسبوک توانسته در فضای اطراف شما مستقر شود.
https://mehrandvd.me/2016/07/12/hololens-spacive-design-new-era-uiux/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
یکی از تکنیک ها برای ایجاد عمق یا برجستگی، استفاده از shadow-box است. اطلاع از تمام امکانات و ویژگی هایی که این پروپرتی در اختیار ما قرار می دهد، می تواند به خلق طرح های جذاب به ما کمک کند. این ویژگی ها عبارتند از:
• Horizontal Length
• Vertical Length
• Blur Radius
• Spread Radius
• Shadow Color
• Opacity
• Outline/Inset
بطور کلی در پروپرتی box-shadow می توان لیستی از سایه ها را ( که هر کدام شامل ویژگی های بالاست) مشخص کرد. هر قسمت این لیست که با کاما از هم جدا شده است مربوط سایه یک قسمت از element مربوطه خواهد بود. به این ترتیب می توان ترکیب های متنوع و خلاقانه ای از سایه های داخلی یا خارجی با میزان و غلظت های مختلف ایجاد کرد.
لینک زیر به شرح کامل box-shadow با مثال پرداخته و دید کاملی برای استفاده از تمام ویژگی های ارائه کرده است.
https://www.css3.info/preview/box-shadow/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/MdiE309B7Jm
#مریم_داودی (https://ow.ly/HGkG309B7de)
کانال تلگرام:
@SoftwarePhilosophy
___
• Horizontal Length
• Vertical Length
• Blur Radius
• Spread Radius
• Shadow Color
• Opacity
• Outline/Inset
بطور کلی در پروپرتی box-shadow می توان لیستی از سایه ها را ( که هر کدام شامل ویژگی های بالاست) مشخص کرد. هر قسمت این لیست که با کاما از هم جدا شده است مربوط سایه یک قسمت از element مربوطه خواهد بود. به این ترتیب می توان ترکیب های متنوع و خلاقانه ای از سایه های داخلی یا خارجی با میزان و غلظت های مختلف ایجاد کرد.
لینک زیر به شرح کامل box-shadow با مثال پرداخته و دید کاملی برای استفاده از تمام ویژگی های ارائه کرده است.
https://www.css3.info/preview/box-shadow/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/MdiE309B7Jm
#مریم_داودی (https://ow.ly/HGkG309B7de)
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
پیاده سازی Owin Authorization در برنامههایی که از Owin WebApi استفاده میکنند معمولا بسیار کاربردی است. استفاده از Owin در معماری برنامههای تحت وب مزایای زیادی دارد. مفهوم Middleware در این معماری باعث خوانایی بسیار زیادی در معماری میشود. در معماری Owin فضاهای بسیار مشخصی برای نوشتن کدها تعریف شدهاست.
مقاله زیر به خوبی نشان میدهد چطور Claim based authentication را با استفاده از Owin روی ASP.NET WebApi تنظیم کنید.
https://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر به خوبی نشان میدهد چطور Claim based authentication را با استفاده از Owin روی ASP.NET WebApi تنظیم کنید.
https://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Microsoft
ASP.NET Core, an open-source web development framework | .NET
Build web apps and services that run on Windows, Linux, and macOS using C#, HTML, CSS, and JavaScript. Get started for free on Windows, Linux, or macOS.
Forwarded from Iran Agile
انگیزش تیمها
تازه وارد یک شرکت شده اید بسیار شوق و ذوق دارید، میخواهید همه چیز را درست کنید، میخواهید دنیا را جای بهتری کنید، ولی بعد از مدتی شبیه بقیه میشوید، شاید بی انگیزه تر از بقیه. ولی چرا این اتفاق می افتد؟
یکی از بهترین روش های انگیزش تیمها، دیدن تاثیر کار بر روی مشتریان است.
یعنی این تسک من چه تاثیر بر زندگی مشتری ها دارد؟
@iranagile
یکی از مثال های معروف قدیمی، اگر از آبدارچی ناسا بپرسید چه کاری انجام می دهی، احتمالا خواهد گفت "من به پرتاب شاتل کمک می کنم" ولی از آبدارچی شرکتهای خودمان بپرسیم خواهند گفت، "از صبح تا شب دارم حمالی می کنم ..."
یکی از مثالهای اخیر که بیاد دارم، در شرکتی که یک فروشگاه اینترنتی است، یک باگ مربوط به پرینت لیبل وجود داشت. درخواست دهنده این بخش انبار بود و بشدت انتظار رفع این باگ را داشتند. لیبلهایی که چاپ می شدند قابل اسکن نبودند و این روند انبارداری را بسیار کند میکرد.
ولی این باگ برای برنامه نویس ها اهمیتی نداشت، "بابا اینکه باگ مهمی نیست، دستی دارن کار رو انجام یمدهند دیگه، برای چی باید روش وقت بگذاریم، اصلا مهم نیست...". ولی زمانی که باگ رفع شد، از برنامه نویس ها خواسته شد که در محل انبار حضور داشته باشند و خوشحالی کل کارمندان را دیدند که چقدر از رفع این باگ خوشحال شده بودند، خودشان دیدند این چقدر به راحتی کار آنها در انبار کمک می کرد، و دیالوگ جدیدشان این بود که "چرا ما این رو سریع تر درست نکردیم..."
یا مثال دیگر در پروژه بانکداری الکترونیکی که در آن هستم، ویژگی با عنوان "پرداخت مستمر" پیاده شده است، در جلسه برنامه ریزی یکی از برنامه نویس ها گفتند "یک مورد دیدم که عنوان پرداخت مستمر رو زده بود، پرداختی ماهانه برای مامان، شما تصور کنید یک پسر داره ماهانه یک مبلغی برای مادرش واریز میکنه، حالا فکر کنید این از کار بیفته و پول به دست مادر نرسه، چه حالی می شوید...".
یکی از تفاوت های اصلی روش های چابک در این است که شما واسط تیم ها با بازار-مشتریان نشوید، اجازه بدهید تیم ها مشکلات مشتری ها را لمس کنند، اجازه بدهید اهمیت و تاثیر خروجی کارشان بر مشتری ها را ببینند.
https://blog.scrum.ir/2017/03/team-motivation
تازه وارد یک شرکت شده اید بسیار شوق و ذوق دارید، میخواهید همه چیز را درست کنید، میخواهید دنیا را جای بهتری کنید، ولی بعد از مدتی شبیه بقیه میشوید، شاید بی انگیزه تر از بقیه. ولی چرا این اتفاق می افتد؟
یکی از بهترین روش های انگیزش تیمها، دیدن تاثیر کار بر روی مشتریان است.
یعنی این تسک من چه تاثیر بر زندگی مشتری ها دارد؟
@iranagile
یکی از مثال های معروف قدیمی، اگر از آبدارچی ناسا بپرسید چه کاری انجام می دهی، احتمالا خواهد گفت "من به پرتاب شاتل کمک می کنم" ولی از آبدارچی شرکتهای خودمان بپرسیم خواهند گفت، "از صبح تا شب دارم حمالی می کنم ..."
یکی از مثالهای اخیر که بیاد دارم، در شرکتی که یک فروشگاه اینترنتی است، یک باگ مربوط به پرینت لیبل وجود داشت. درخواست دهنده این بخش انبار بود و بشدت انتظار رفع این باگ را داشتند. لیبلهایی که چاپ می شدند قابل اسکن نبودند و این روند انبارداری را بسیار کند میکرد.
ولی این باگ برای برنامه نویس ها اهمیتی نداشت، "بابا اینکه باگ مهمی نیست، دستی دارن کار رو انجام یمدهند دیگه، برای چی باید روش وقت بگذاریم، اصلا مهم نیست...". ولی زمانی که باگ رفع شد، از برنامه نویس ها خواسته شد که در محل انبار حضور داشته باشند و خوشحالی کل کارمندان را دیدند که چقدر از رفع این باگ خوشحال شده بودند، خودشان دیدند این چقدر به راحتی کار آنها در انبار کمک می کرد، و دیالوگ جدیدشان این بود که "چرا ما این رو سریع تر درست نکردیم..."
یا مثال دیگر در پروژه بانکداری الکترونیکی که در آن هستم، ویژگی با عنوان "پرداخت مستمر" پیاده شده است، در جلسه برنامه ریزی یکی از برنامه نویس ها گفتند "یک مورد دیدم که عنوان پرداخت مستمر رو زده بود، پرداختی ماهانه برای مامان، شما تصور کنید یک پسر داره ماهانه یک مبلغی برای مادرش واریز میکنه، حالا فکر کنید این از کار بیفته و پول به دست مادر نرسه، چه حالی می شوید...".
یکی از تفاوت های اصلی روش های چابک در این است که شما واسط تیم ها با بازار-مشتریان نشوید، اجازه بدهید تیم ها مشکلات مشتری ها را لمس کنند، اجازه بدهید اهمیت و تاثیر خروجی کارشان بر مشتری ها را ببینند.
https://blog.scrum.ir/2017/03/team-motivation