برنامه نویسی هیلتن
13.6K subscribers
1.28K photos
1.86K videos
488 files
1.26K links
آموزش و انجام پروژه برنامه نویسی، طراحی سایت و سئو
تازه های #فناوری، #تکنولوژی و #انگیزشی

تعرفه تبلیغات وانجام پروژه:
t.me/HeiltonAds/205

اینستاگرام:
instagram.com/omidsotooni
Download Telegram
آرم وسط پرچم ایران چگونه طراحی شد


گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
This media is not supported in your browser
VIEW IN TELEGRAM
وقتی میرسیم شرکت میبینیم مشتری برای تحویل پروژه اش اومده ...



گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
اگر فقیر به دنیا بیایید شما مقصر نیستید ، ولی اگر فقیر از دنیا بروید مقصر خودتان هستید
#سخن بزرگان

گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
💥 بهترین روش طراحی سایت کدام است؟

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

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

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



گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
#طنز #سرگرمی
آینده شغلی من از نگاه خودم و دیگران 😢😂


گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
This media is not supported in your browser
VIEW IN TELEGRAM
#رابط_کاربری #ui #تجربه_کاربری #ux #ایده
رابط کاربری #ui و تجربه کاربری #ux جذابی برای وبسایت ، که شما هم می توانید از آن ایده بگیرید



گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
🔴 مراحل ساده برای پاک کردن فضای اشغال شده توسط تلگرام (نشردهید


گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
This media is not supported in your browser
VIEW IN TELEGRAM
وقتی یه لینوکسی میره یه ویندوزی و یه مکی رو از هم جدا میکنه😄😄😄
😎لینوکسی ها شوخی ندارن😎
🆔 @HeiltonProgramming
Forwarded from ModelDriven
معماری نرم افزار
معماری هر سیستم، مجموعه ای از ساختارهای مورد نیاز برای استدلال درباره ی آن سیستم است که شامل عناصر نرم افزاری، روابط بین آن-ها، و ویژگی های این دو می باشد 2. پیچیدگی و نیاز به مقیاس پذیری در سیستم های نرم افزاری امروزه به‌طور مداوم افزایش می یابد. در نتیجه ایجاد معماری های مطلوب و کارا برای برآورده کردن نیازمندی ها و ارضای محدودیت مدنظر کاربر، یک فرایند چالش ‌برانگیز است 4، چرا که این فرایند کاملاً از روی خلاقیت بوده و نمی توان آن را فرموله کرد، درحالی‌که می توان بعضی کارها را جهت بهبود پیشنهاد نمود 4. مهندسین نرم‌افزار به دنبال طراحی و پیاده سازی سیستم های امن، قابل ‌اعتماد و کارا می باشند که معماری های نرم افزار تا حدودی این نیازمندی ها را برطرف می کنند. کیفیت بالای معماری یک سیستم برای موفقیت دراز مدت یک محصول نرم‌افزاری، لازم و ضروری است . بدیهی است، تصمیمات معماری نرم افزار در بخش های دیگر نرم افزار نیز تأثیرگذار است . معماری باکیفیت یک سری ویژگی ها دارد از جمله این ویژگی ها سادگی درک، پیاده سازی، نگهداری و مقیاس پذیر است. مهم تر از آن این است که بتواند نیازمندی های سیستم را برآورده کند. البته برآورده کردن این نیاز ها و ویژگی ها با هم دور از واقعیت و در بیشتر حالت ها غیر ممکن است. درنتیجه بنا به نیاز و شرایط طراح یک سری ویژگی ها را از دیگر ویژگی های مهم تر دانسته و بر روی آن ها تمرکز دارد.


گروه پژوهشی مهندسی نرم افزار مدل رانده

@modeldriven
Exception در خیابان

عادت دارم برای پارک کردن در محلهایی که دستگاه اتوماتیک پرداخت وجود دارد هزینه پارک خودرو را با کارت مترو پرداخت کنم(همان علمک های کله زردی که 8 چراغ چشمک زن دارند). هفته پیش متوجه شدم کارت مترویم که شارژ کمی دارد. پس به یکی از دستگاههای شارژ کارت که در کیوسکهایی که با نام ezpay در سطج شهر راه اندازی شده اند رفتم، کارت بانکی را وارد کردم و بعد از گذاشتن کارت مترو در محل مشخص شده اش در دستگاه و وارد کردن رمزها مبلغ شارژ 50 هزار تومان را وارد کردم، دستگاه پیغام داد که بیش از 44 هزار تومان شارژ نمی توانی بخری، مبلغ جدید را همان 44 هزار تومان انتخاب کردم، ناگهان پنجره ای بر مانیتور دستگاه ظاهر شد که در هنگام debug برنامه های دات نتی در ویندوز با آن مواجه می شویم، گزینه ای هم داشت که «Debug»! معلوم بود Exception ی در سیستم رخ داده است که مدیریت نشده است و هیچ راهکاری هم برای این شرایط در نرم افزار مربوطه دیده نشده است. برای اولین بار بود که در نزدیکی یکی از اصلی ترین میادین شهر و در خیابان Exception ی را می دیدم.

من هم مبهوت که اگر یک کاربر غیر آی تی و نا آشنا با برنامه نویسی با این پنجره مواجه شود آن هم در دستگاهی که مخاطبش همه جامعه است چه باید بکند؟ چه میزان نگرانی به او وارد می شود که آیا ضرر مالی به او وارد شده یا نه؟ کارتش شارژ شده یا نه؟ اصلا دکمه های این پنجره انگلیسی عجیب و غریب را چگونه باید کلیک کند؟ و هزار سوال و علامت تعجب دیگر.

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

پویا بلاک


گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
This media is not supported in your browser
VIEW IN TELEGRAM
هر چندبارم دیده بشه بازم کمه 👆 از دست ندین
گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
10 واقعیت جالب درباره بنیان‌گذار فیس‌بوک
گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
برنامه نویسی هیلتن
10 واقعیت جالب درباره بنیان‌گذار فیس‌بوک گروه برنامه نویسی هیلتن👇 🆔 @HeiltonProgramming
10 واقعیت جالب درباره بنیان‌گذار فیس‌بوک
۱) مارک زاکربرگ به کوررنگی مبتلاست؛ کوررنگی قرمز و سبز. او در دیدن و تشخیص این دو رنگ مشکل دارد و احتمالا به همین خاطر است که رنگ غالب در پلت‌فرم فیس‌بوک٬ رنگ آبی است.

گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming

۲) وقتی او دبیرستانی بود کمپانی‌های مایکروسافت و AOL تلاش کردند تا او را استخدام کنند. او در آن روزها سینپس (Synapse) را راه‌اندازی کرده بود؛ برنامه‌ای که از هوش مصنوعی برای یادگیری از عادت‌های موسیقیایی کاربران بهره می‌گرفت.

۳) مارک تقریبا همه روزها همان تی‌شرت معروف خاکستری که لوگوی فیس‌بوک را هم دارد٬ بر تن می‌کند. او می‌گوید سرش به اندازه کافی شلوغ است و نمی‌تواند صبح‌ها وقت زیادی برای انتخاب لباس صرف کند.

۴) اگرچه او خیلی معمولی لباس می‌پوشد٬ اما گفته که در سال ۲۰۰۹ برای این‌که نشان دهد فیس‌بوک در روزگار رکود اقتصادی چقدر برای رشد و گسترش کار خود مصمم است٬ هر روز کراوات می‌زد.

گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming

۵) زاکربرگ گیاه‌خوار است و یک بار گفت که فقط در صورتی گوشت حیوانی را خواهد خورد که خودش آن حیوان را کشته باشد. اما در لیست صفحاتی که او در فیس‌بوک لایک کرده٬ نام «مک‌دونالد» را هم می‌توان دید.

۶) او با این‌که در طول ۴ سالی که عضو توییتر شده فقط ۱۹ توییت منتشر کرده٬ و آخرین توییتش هم مربوط به ۱۵ ماه پیش است٬ بیش از ۲۲۰ هزار دنبال‌کننده (فالوئر) در این شبکه اجتماعی دارد.
مارک زاکربرگ و همسرش پرسیلا چان

۷) در اکتبر ۲۰۱۰ به همراه گروهی از کارمندان فیس‌بوک رفت تا در سینما به تماشای فیلم "شبکه اجتماعی" بنشیند. پس از دیدن فیلم در ابراز نظرهای عمومی او از تصویری که در این فیلم از او ارائه شده انتقاد کرد و گفت ماجرا طوری روایت شده که انگار او فیس‌بوک را صرفا به این خاطر به وجود آورده که منزلت اجتماعی کسب کند.

۸) مارک یک سگ پاکوتاه سفید و مشهور دارد که اسم Beast را برایش انتخاب کرده. سگ او در فیس‌بوک بیش از ۱/۵ میلیون فن دارد.

۹) سال گذشته بعضی‌ها از او انتقاد کردند که چرا موقع ازدواج با همسرش٬ پرسیلا چان٬ هدیه‌ای گران‌بهاتر از حلقه یاقوت ۲۵ هزار دلاری به وی نداده٬ اگرچه خودش همان زمان ثروتی ۱۹ میلیارد دلاری داشت.

۱۰) هر جای فیس‌بوک اگر این کاراکترها [4:0]@ را در کامنتی وارد کنید و اینتر را بزنید٬ نام او ظاهر خواهد شد.

گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
صفحه بندی paging آموزش کار با دستورات linq

http://www.aparat.com/v/8JzDp




لینک دانلود
goo.gl/bbA0Tm


@HeiltonProgramming

www.Heilton.com
Forwarded from ModelDriven
Empirical Software Engineering
مقالات زیادی در مورد کارهای تجربی در مهندسی نرم‌افزار وجود دارد که بعضی از آن ها حاوی اخبار و نظرات جدید و مناسب برای انتشار می باشد. مهندسی نرم افزار تجربی مانند آموخته های تجربی فیزیک، پزشکی، معماری و بسیاری از رشته های دیگر، روشی مناسب برای توسعه نرم افزار براساس مولفه های تجربی است، مهندسی نرم افزار نیاز به روش های سطح بالا برای مدلسازی و آزمایش دارد و نمی‌تواند فقط با مشاهدات و تکیه بر تفکر منطقی به چرخه تولید برسد]5[. مهندسین نرم افزار با انتخاب متدولوژی درست و با استفاده ازقدرت تجربه می تواند یک پروژه را مدیریت و با موفقییت به پایان برسانند. متدولوژی فقط یک چارچوب و پوشش برای مدیریت فرایند تولید یک نرم افزار است و به تنهایی نمی تواند در موفقیت یک پروژه نقش به سزای داشته باشد. موفقیت در یک پروژه همانند پرواز یک پرنده است که برای این پرواز دوبال( متدولوژی و تجربه) لازم است. به عبارت دیگر وجود هریک از متدلوژی و تجربه برای اجرای موفقیت آمیز یک پروژه لازم بوده ولی کافی نمی باشد. بر این اساس باید با استفاده از تکنیک ها و آزمایش ها مشخص شود در یک بازه زمانی خاص، چه ابزاری و به چه نحوی کار می‌کند، و با تجربه ای که در اختیار داریم و با درک محدودیت‌ها و چگونگی عمکرد محصول‌ها، برای بهبود روند انجام پروژه و یادگیری بهتر، طراحی و ارئه طریق نماییم. هدف از مهندسی نرم افزار تجربی استفاده از تجربه افراد در مدیریت و توسعه نرم افزار و بهبود بخشیدن آن است و متدلوژی یک الگوریتم برای سازماندهی این فرایند می باشد. متدولوژی به عنوان فعالیت های پایدار در خدمت فعالیت های توسعه قرار می‌گیرد و در تمام مراحل فرایند تولید نرم افزار وجود دارد و از نمادهای مختلف برای بیان مقاصد متفاوت و روند فرایند تولید در سطح ناهمگون استفاده می کند

گروه پژوهشی مهندسی نرم افزار مدل رانده

@modeldriven
Forwarded from ModelDriven
بررسی میزان تاثیر انتخاب متدلوژی و تجربه درموفقیت یک نرم افزار

متدولوژی فقط یک چارچوب و پوشش برای مدیریت فرایند تولید یک نرم افزار است. لذا در اجرای فرایند توسعه نرم افزار نمی-تواند آنچنان که لازم وضروری است خود را نشان دهد و یا نقش بسزایی داشته باشد. البته این سخن بیانگر این نیست که همه متدولوژی ها با هم برابر و یک روند را دارند. به عنوان مثال برای توضیح بیشتر این قضیه، اگر یک شرکت با متدولوژی مانند Incremental پروژۀ خود را با موفقیت به پایان برساند یقیناً با متدولوژی های مانندSpiral هم می تواند تا حدودی موفق باشدو یا شرکتی با متدلوژی Incremental موفق هست وشرکتی دیگر با همان متدولوژی Incrementalناموفق است. این بیانگر این نیست که انتخاب متدولوژی سهمی در موفقیت پروژه ندارد بلکه عامل مهمتری که می تواند نقش بسزایی در مدیریت و کنترل روند توسعه یک نرم افزارداشته باشد تجربه و چگونگی ارزیابی ریسک ها ونحوه پاسخ به آنهاست چون توسعه نرم افزار یک فرایند کاملاً پویاست و ما نمی توانیم در چارچوب ایستا انجام دهیم. به همین دلیل است که متدولوژی های Agile (چابک) موفق تر از متدولوژی های سنگین وزن به نظر می رسند. چون متدولوژی های Agile انعطاف پذیرتر و پویاتر هستند. با درنظرگرفتن ویژه‌گی‌ها و روش‌های چابک و ارتباط آن ها با روش‌های تجربی در تیم های بزرگ و کوچک متوجه رابطه بسیار زیاد بین این دو موضوع می‌شویم. متخصصان و کارشناسان برای بهبود روش‌های توسعه نرم‌افزارگرد هم آمدند و باجمع آوری مجموعه‌ای از تجربه ها و استفاده از آنها باعث به وجود آمدن متدلوژی های چابک شدند. به بیان دیگر متدلوژی چابک مجموعه‌ای از قواعد و روش‌های توصیه شده توسط متخصصان با تجربه می باشد . از این رو قلب متدلوژی های چابک تجربه است و براساس تجریه بنا شده است. و بیشتر به جای این که قانون‌مند و بر طبق برنامه عمل کنند تجربه و شرایط را محور اصلی قرارداده‌اند، استفاده از تجربه برای موفقیت در متدلوژی‌های چابک مهم است اما تولید محصول از آن مهم‌تر است. متدلوژی های چابک براساس "بازخورد" و "تغییرات" ساخته شده‌اند]11[ . به هر حال متدلوژی‌های چابک نیازمند دسترسی سریع(فوری) به پایگاه دانش از تجربه‌ها می باشد و تجربه ها به صورت دانش در پایگاه دانش قرار دارند، استفاده و آزمایش این تجربه‌ها باعث پالایش تجربه ها قبلی از نواقص و به وجود آمدن تجربه‌های جدید می‌باشد. از این رو متدلوژی چابک محیط مفیدی برای پژوهش‌های تجربی فراهم می‌کند و براساس مطالعات متدلوژی‌های چابک کارگاه ارزان و کارآمدی برای نشان دادن دانش‌های تجربی است. این بدان معنا نیست که ما احتیاجی به متدولوژی سنگین وزن نداریم بلکه بدیهی است درپروژه های بزرگ استفاده از متدولوژی سنگین وزن اجتناب ناپذیر است و یا اینکه به متدولوژی نیازی نیست . بطوری که میتوان گفت که برای هر فرد یا هر پروژه یک متدولوژی لازم است.این جمله نشان دهنده این است که هیچ متدولوژی خاصی را نمی توان برای افراد و پروژه ها به صورت ثابت تعریف کرد،چون هر پروژه و افراد تیم توسعه نرم افزار شرایط خاص خود را می طلبد که بعضی از مهندسین به اشتباه یک متدولوژی را انتخاب کرده و روند آن متدولوژی را دنبال می کنند. تا مراحل متدولوژی کامل شود. در واقع آن ها به جای این که با روند پروژه هم گام شوند با گام های متدولوژی همراه می شوند که در بیشتر مواقع با شکست روبه رو شده و منجر به بحران توسعه نرم افزاری می شوند این نظریه به این معنا نمی باشدکه مهندسن نرم افزار لازم نیست متدولوژی ها را بشناسند و یا گام های آن را نادیده بگیرند بلکه شناخت متدولوژی های متعددی (Rup, Agile, Incremental …..) به مهندسین، دیدگاهی باز برای مدیریت پروژه می دهد وحتی تولید نسخه-های مختلف از یک نرم افزار می تواند متدولوژی ها و شرایط خاص خود را بطلبد. چون توسعه نرم افزار یک فرایند کاملاً پویاست و ما نمی توانیم آن را محدود به یک متدولوژی خاص کنیم .همان طور که گفتیم متدولوژی با نیروی تجربه کامل می شود. متدولوژی مانند اسکلت بدن و تجربه روح آن است. چه بسا افراد و شرکت های هستند که از متدولوژی (Y) استفاده کرده ودر پروژه های خود نیز موفق می شوند اما افراد و شرکت های دیگری هستند که از همان متدولوژی (Y) استفاده می کنند ولی با شکست مواجه می شوند.این جمله بیانگر این است که متدولوژی برای کامل شدن نیازبه چیزی دارد که تجربه مکمل آن است .انتخاب متدولوژی مهم است اما نه به اندازۀ توسعه یک نرم افزار .در این مقاله یک رویکرد جدید را برای حل این مشکل به شما پیشنهاد می کنیم:

گروه پژوهشی مهندسی نرم افزار مدل رانده

@modeldriven
اولین صفحهٔ اصلی گوگل که ظاهری ساده دارد در آن از کدهای HTML استفاده نشده‌است. این صفحه مربوط به سال ۱۹۹۸ می‌باشد


گروه برنامه نویسی هیلتن👇
🆔 @HeiltonProgramming
William_Stalling(Heilton.com).pdf
12.2 MB
کتاب سیستم عامل ویلیام استالینگ
Operating Systems William Stalling
گروه برنامه نویسی هیلتن👇
🆔 https://telegram.me/HeiltonProgramming