DenoGres 2.0 منتشر شد
DenoGres 2.0 اکنون فعال است! در این نسخه مجموعه جدیدی از ویژگی های ساخته شده بر روی DenoGres 1.0 گنجانده شده است که به توسعه دهندگان ابزارها و دلایل بیشتری برای کار در DenoGres می دهد.
سایت سفارش طراحی سایت با بهترین طراحان سایت
رابط کاربری گرافیکی کاربرپسند، همگام سازی پایگاه داده دو جهته، بذر پایگاه داده، و گزارش مهاجرت تنها تعداد انگشت شماری از ویژگی های موجود در DenoGres 2.0 هستند!
مقدمه
امروز ما نسخه بعدی DenoGres، نسخه 2.0 را منتشر می کنیم. نسخه 2.0 با تعداد قابل توجهی بهبود در عملکرد اصلی ارائه می شود که DenoGres را نه تنها آسان تر می کند، بلکه یک راه حل ORM جامع تر را ایجاد می کند که PostgreSQL را به زمان اجرا Deno پیوند می دهد.
نکات برجسته در این نسخه عبارتند از:
همگام سازی دو جهته پایگاه داده/مدل
بذردهی پایگاه داده
یک رابط مرورگر پرس و جوی گرافیکی
گزارش مهاجرت پایگاه داده
همگام سازی پایگاه داده دو جهته
طراحی لوگو با بهترین طراح لوگو و طراحی لوگو حرفه ای
یکی از ویژگی های اصلی که به عنوان بخشی از نسخه 2.0 پیاده سازی شده است، افزودن همگام سازی پایگاه داده دو جهته است. پس از فراخوانی فرمان "-db-pull"، DenoGres یک فایل model.ts ایجاد می کند. این فایل طرحواره پایگاه داده کاربر را از PostgreSQL به شکل شی TypeScript نشان می دهد. هر تغییری که در PostgreSQL رخ می‌دهد را می‌توان با فراخوانی « — db-pull» به دایرکتوری پروژه کاربر کشید، که فایل مدل فعلی را در DenoGres بازنویسی می‌کند. یکی دیگر از قابلیت‌هایی که در این ویژگی وجود دارد، توانایی همگام‌سازی تغییرات در طرح پایگاه داده PostgreSQL از طریق مدل ORM (model.ts) در DenoGres است. اگر کاربر بخواهد تغییراتی را در طرح PostgreSQL خود ایجاد کند، می‌تواند این کار را در IDE خود با تغییر فایل model.ts و فراخوانی فرمان « — db-sync» انجام دهد. فراخوانی « — db-sync» سپس از model.ts به عنوان پایه آن استفاده می کند و طرح پایگاه داده PostgreSQL را برای مطابقت با Models از فایل model.ts همگام می کند.
تصویر فایل model.ts
model.ts
توجه داشته باشید! همه تغییرات طرحواره پایگاه داده را می توان یکی یکی همگام سازی کرد، با این حال، بسیار کارآمدتر است که همه تغییرات خود را به یکباره انجام دهید و سپس آن تغییرات را با هم همگام سازی کنید.
پس از ایجاد تغییرات در مدل، دستور " — db-sync" را اجرا کنید و تمام تغییرات ایجاد شده در مدل شما با طرح پایگاه داده PostgreSQL شما همگام سازی می شود.
بذریابی پایگاه داده
متلب انجام پروژه متلب با متلب دانان
با جدیدترین افزوده ما از بذردهی پایگاه داده، اکنون می توانید داده های آزمایشی را مستقیماً از طریق DenoGres در پایگاه داده PostgreSQL خود وارد کنید! برای شروع، ابتدا باید فایلی به نام seed.ts در داخل دایرکتوری ریشه ایجاد کنید. در مرحله بعد، آرایه ای از اشیاء ایجاد کنید و آن را به برچسبی که با نام جدولی که می خواهید در پایگاه داده PostgreSQL ایجاد کنید، اختصاص دهید. در متغیر تازه ایجاد شده شما، هر شی در آرایه یک رکورد (ردیف) را نشان می دهد که باید به پایگاه داده PostgreSQL اضافه شود.
توجه: مطمئن شوید که هر یک از آبجکت های داده مطابق با طرحی که در فایل model.ts آمده است.
نمونه ای از فایل seed.ts به شکل زیر است:
قطعه کد نمونه ای از فایل seed.ts را نشان می دهد.
مثال: مدل seed.ts
اکنون، تنها کاری که باید انجام دهید این است که اجرا کنید: denogres - db-seed
مرورگر GUI Query
صفحه ورود به سیستم DenoGres
نسخه 2.0 یک مرورگر پرس و جو بصری را معرفی می کند که می تواند از طریق رابط خط فرمان باز شود. پیش از این، تمام قابلیت‌های DenoGres باید با اجرای اسکریپت‌ها قابل دسترسی بودند و کاربران به تجزیه داده‌های SQL از داخل خط فرمان محدود می‌شدند. مرورگر پرس و جو برای رسیدگی به چنین چالش هایی طراحی شده است و امکان گردش کار کارآمدتر و کارآمدتر را فراهم می کند.
افزودن یک اتصال
انجام پروژه با بهترین متخصصان پروژه
به عنوان بخشی از نسخه مرورگر پرس و جوی رابط کاربری گرافیکی، دو بخش اصلی معرفی شده است: مدیر اتصالات و جستجوگر پرس و جو. در مدیر اتصالات، کاربران می‌توانند اعتبار پایگاه داده را ایجاد/به‌روزرسانی/حذف کنند که در حسابشان ذخیره می‌شود. در مدیریت اتصال، کاربران همچنین می توانند به پایگاه داده(های) انتخابی خود متصل شوند. هنگامی که کاربر به یک پایگاه داده متصل شد، رابط کاربری گرافیکی کاربران را به جستجوگر جستجو هدایت می کند.
اتصال به یک اتصال ذخیره شده
در جستجوگر پرس و جو، کاربران می توانند کلاس های Model مرتبط با یک پایگاه داده مشخص را ببینند. آنها همچنین می توانند پرس و جوهایی را در برابر مدل های خود ایجاد و اجرا کنند.
تعریف و ذخیره پرس و جو
گزارش مهاجرت پایگاه داده
DenoGres 1.0 فاقد توانایی ردیابی یا ذخیره مهاجرت های پایگاه داده بود. اگر کاربر تصمیم گرفت که شکل مدل خود را تغییر دهد و بعداً یک هفته بعد تصمیم گرفت که آن را تغییر دهد، هیچ راهی برای بازگشت به طرح قبلی خود وجود نخواهد داشت. DenoGres 2.0 این مشکل را حل می کند.
Denogres Log همه مهاجرت ها را ردیابی می کند
قبل از DenoGres 2.0، زمانی که کاربر دستور CLI "-db-pull" را وارد می کند، یک مدل ORM واحد بر اساس طرح PostgreSQL فعلی آنها ایجاد می شود. اگر کاربر تغییراتی در مدل داده ایجاد کند و متعاقباً بخواهد به مدل اصلی خود برگردد، جزئیات مربوط به مدل اصلی برای همیشه از بین می‌رود. اکنون، زمانی که کاربر طرح پایگاه داده خود را به فایل model.ts خود می کشد، DenoGres به طور خودکار یک نسخه پشتیبان از آن مدل ایجاد می کند و آن را برای استفاده بعدی ذخیره می کند.
با افزودن همگام سازی پایگاه داده دو جهته، هر زمان که دستور « — db-sync» اجرا شود، DenoGres به صورت خودکار
y یک نسخه پشتیبان از مدل ORM پس از همگام سازی ایجاد کنید. این به کاربر این امکان را می دهد که مدلی برای همگام سازی مجدد شکل طرحواره پایگاه داده PostgreSQL خود در صورت نیاز به بازگشت به هر مدل ذخیره شده در هر نقطه از زمان داشته باشد.
در حال توسعه
با گسترش پشتیبانی از DenoGres، تیم امیدوار است تغییرات زیر را با نسخه بعدی DenoGres اعمال کند:
پشتیبانی بیشتر از dbSync - در نهایت برای چندین ارتباط و کلیدهای منحصر به فرد ترکیبی در مدل DenoGres در نظر گرفته شود.
دستور جدید «مقایسه» - تفاوت‌های مدل‌های قبلی (در صورت وجود) را در کنار هم نمایش دهید.
به روز رسانی های بیشتر برای گزارش مهاجرت - گزارش در رابط کاربری گرافیکی قابل مشاهده خواهد بود تا کاربران بتوانند نسخه های مدل را ردیابی/مشاهده/مقایسه کنند.
نمودارهای به سبک ERD - در رابط کاربری گرافیکی ایجاد می‌شوند، بنابراین کاربران می‌توانند دید جامعی از مدل داده‌های خود داشته باشند.
پشتیبانی اضافی برای MySQL، SQL Server و غیره
مقیاس پذیری: Kubernetes دقیقاً در تلاش است به چه چیزی دست یابد؟
درک انتزاع پشت گره ها و غلاف ها
من مطمئن هستم که در مورد آن شنیده اید، اما اگر هرگز از آن استفاده نکرده اید، یا تازه شروع کرده اید، Kubernetes می تواند بسیار قوی و گیج کننده باشد. البته که همه چیز در چشم بیننده است، اما این همان چیزی است که من در ابتدای شروع کارم احساس کردم و مطمئنم که در این مورد تنها نیستم.
انجام پروژه در فریلنس پروژه
در کارهای اخیرم، تمرکز زیادی روی مقیاس پذیری داشته ام. من سعی کرده‌ام راه‌حلی برای پخش جریانی پیکسلی ایجاد کنم، که اصطلاحی جذاب برای برنامه‌های کاربردی-۳ بعدی-ابر است. توصیف هدف ساده است: اجرای شبیه‌سازی‌های غیرواقعی بر روی رایانه‌های بسیار قدرتمندی که در فضای ابری میزبانی می‌شوند و پخش آنها در زمان واقعی به دستگاه شخصی افراد، بنابراین نیاز به داشتن سخت‌افزار گران قیمت را از بین می‌برد. در حالی که پیاده‌سازی می‌تواند متفاوت باشد، اما در اصل آن یکسان است: هر فردی که در تلاش است وارد یک تجربه شود، باید یک نمونه اختصاصی ارائه شود.
منبع: Unreal Engine 5 Pixel Streaming Overview
سفارش طراحی سایت با بهترین طراحان سایت
در این مقاله، راه حل معماری مورد استفاده مورد نظر را بررسی خواهم کرد. علاوه بر چند نکته، من سعی خواهم کرد از استفاده از اصطلاحات Kubernetes اجتناب کنم و تا زمانی که خواندن این مقاله را به پایان برسانید، شما یک متخصص Kubernetes نخواهید بود. هدف من این است که زمینه مناسبی را برای خوانندگان فراهم کنم تا سریعتر به APIهایی مانند Kubernetes نزدیک شوند و به طور بالقوه متخصص شوند.
با در نظر گرفتن این موضوع، بیایید شروع کنیم!
تجسم ابر
من همیشه به Kubernetes به عنوان یک ابزار مشتری فکر می کردم. در حالی که این تا حدودی درست است، زیرا دارای یک جزء مشتری است، من در واقع از جهت دیگر به آن نگاه می کردم. Kubernetes به‌عنوان چارچوبی برای مدیریت منابع شما، معمولاً به‌عنوان یک ارائه‌دهنده خدمات بک‌اند ساخته شده است. توضیح خواهم داد.
تصور کنید که شما مزرعه ای از کامپیوترها دارید که احتمالاً هزاران عدد از آنها را شامل می شود. رایانه‌ها از نظر قابلیت‌ها و سخت‌افزار متفاوت هستند - برخی از آنها هسته‌های بیشتری نسبت به بقیه دارند و برخی حافظه بیشتری دارند. اما در طرح بزرگ، شما منابع زیادی دارید. هدف شما این است که این منابع را به مستاجران مختلف اجاره دهید - می خواهید مردم برای قدرت محاسباتی به شما پول بدهند، مانند املاک و مستغلات که در آن فضاهای خالی را اجاره می کنید تا مردم بتوانند هر کاری که می خواهند انجام دهند. اما اگر شما فقط آپارتمان های 4 خوابه دارید و اکثر مستاجران به یک اتاق خواب علاقه مند هستند چه؟ البته، شما به هر مستأجر یک اتاق خواب تک نفره اجاره می‌دهید و اجازه می‌دهید در یک آپارتمان مشترک باشند. این کاری است که Kubernetes فقط با رایانه انجام می دهد.
متلب انجام پروژه متلب با متلب دانان
Kubernetes مجموعه ای از ابزارها است که ارکستراسیون را روی شبکه ای از رایانه ها پیاده سازی می کند. به عبارت دیگر - این یک مدیر املاک و مستغلات برای رایانه ها است. در اینجا برخی از موارد استفاده Kubernetes برای مقابله با آنها طراحی شده است:
پیگیری همه منابع - ببینید چه چیزی در دسترس است، چه چیزی در دسترس نیست و چه چیزی نادرست است.
اگر یک کامپیوتر به طور ناگهانی کار نمی کند، شاید به دلیل اتصال کوتاه، به دنبال جایگزینی برای جا دادن مستاجرینی باشید که روی آن کامپیوتر میزبانی شده اند.
اطمینان حاصل کنید که چیزها از هم جدا شده اند، بنابراین مستاجران به منابعی که به آنها تعلق ندارد دسترسی پیدا نکنند.
همه چیز را ایمن نگه دارید، تا مهمانان ناخواسته به شبکه های مستاجران دسترسی نداشته باشند، مشابه کاری که فایروال انجام می دهد.
تکرار برنامه‌های مستاجر و تقسیم ترافیک ورودی بین چندین رایانه به شیوه‌ای کارآمد، که به عنوان «تعادل بار» نیز شناخته می‌شود.
همه موارد فوق مستلزم سیستمی است که بتواند همه چیز را با پشتکار پیگیری و مدیریت کند. Kubernetes چندین مؤلفه را ارائه می دهد که در کنار هم قرار گرفتن آنها می تواند به هدف مورد نظر دست یابد. در اینجا برخی از این مؤلفه ها وجود دارد که به نظر من درک آنها از نظر مفهومی ساده تر از سایرین است:
kube-apiserver - یک سرور API REST که می تواند توسط مستاجرین برای ارسال درخواست های استقرار برنامه به ابر استفاده شود.
kubelet - عاملی که بر روی هر کامپیوتری نصب شده است و اساساً آن را به بخشی از شبکه Kubernetes تبدیل می کند. این مسئول استقرار برنامه های مستاجر و اجرای بررسی های سلامت بر اساس مجموعه ای از دستورالعمل های ارسال شده از apiserver است.
etcd - یک پایگاه داده کلید-مقدار که متغیرهای مربوط به ابر Kubernetes را ذخیره می کند، به عنوان مثال، پیکربندی ها، و وضعیت هر رایانه و برنامه هایی که باید در آنها اجرا شوند. برای هماهنگی وظایف در سطح سیستم استفاده می شود. به عبارت دیگر - این منبع حقیقت ابر در هر نقطه است.
طراحی لوگو با بهترین طراح لوگو با طراحی لوگو حرفه ای
اگر می‌خواهید به لیست کامل اجزای Kubernetes بروید، نمودار رسمی را به شما ارائه می‌دهم که در وب‌سایت رسمی Kubernetes قابل مشاهده است:
لیست کامل اجزای Kubernetes، از وب سایت رسمی Kubernetes
همانطور که می بینید، مشخصات Kubernetes دوست دارد از انتزاعات در بالای چیزهایی استفاده کند که قبلاً با آنها آشنا هستیم. خوشه به معنای مزرعه یا استخر و گره به معنای رایانه یا ماشین است. در مقطعی از تاریخ، یک گره حتی مینیون نامیده می شد (همانطور که در این شماره GitHub از سال 2014 بحث شد). برای من، نام ها یکی از گیج کننده ترین چیزها در مورد Kubernetes هستند، زیرا تعداد زیادی از آنها وجود دارد، و لزوما معنی زیادی ندارند. اما زمانی که فهمیدم Kubernetes چیزی بیش از یک چارچوب برای مدیریت نیست
مجموعه ای از منابع - همه چیز سریعتر کلیک می کرد. برای مرجع، می‌توانید به این فرهنگ لغت نگاهی بیندازید که فهرست کاملی از اصطلاحات Kubernetes و تعاریف آنها را دارد.
ذخیره سازی یک مشکل کاملا متفاوت است
مشابه شبکه کامپیوترهای Kubernetes، وقتی صحبت از فضای ذخیره‌سازی به میان می‌آید، شبکه‌ای از هارد دیسک‌ها وجود دارد و استراتژی‌های مختلفی برای استفاده از آنها وجود دارد. قبل از توضیح بیشتر، اجازه دهید به چند مورد لبه در مورد ذخیره سازی فکر کنیم:
یک مستاجر دوست دارد یک بازی با حجم 120 گیگابایت آپلود کند، اما فقط هارد دیسک‌هایی با حداکثر 100 گیگابایت در دسترس هستند.
یکی از هارد دیسک‌ها کار نمی‌کند و ممکن است شامل فایل‌های مهمی باشد که برای برخی از مستاجران بسیار حیاتی است.
گسترش / حذف / جایگزینی هارد دیسک بدون وقفه در عملیات روزانه توسط مستاجران.
همه موارد فوق، در حالی که فضای ذخیره سازی را بین رایانه ها به اشتراک می گذارند و دسترسی مناسب خواندن / نوشتن را حفظ می کنند.
حل این مشکلات بی‌اهمیت نیستند و نیاز به تخصص ویژه در زمینه ذخیره‌سازی و نحوه عملکرد آن دارند. برخی از ارائه دهندگان ابر راه حل های ذخیره سازی مدیریت شده اختصاصی مانند AWS EBS، GCE Disk و Azure Disk را ارائه می دهند. اما اگر برای لحظه‌ای تصور کنیم که شما یک اتاق کامل پر از هارد دیسک دارید و می‌خواهید آنها را به مستاجران بالقوه اجاره کنید - احتمالاً می‌خواهید این کار را با یک راه‌حل منبع باز داده‌های بزرگ مانند Ceph انجام دهید.
Ceph شبیه Kubernetes است به این معنا که دسته ای از هارد دیسک ها را مانند یک املاک و مستغلات مدیریت می کند. در اینجا نموداری است که من از صحبت شگفت انگیز راس ترک در مورد Ceph گرفتم، که نشان می دهد چگونه Ceph داده ها را با تقسیم کردن آنها به قطعاتی مانند قطعات لگو و ذخیره آن در چندین دستگاه مدیریت می کند. من نمی‌خواهم در مورد نحوه عملکرد آن به صورت فنی صحبت کنم، زیرا سوراخ خرگوش می‌تواند بسیار عمیق باشد، اما شما می‌توانید در آن شیرجه بزنید:
منبع: Ceph Intro and Architectural Review by Ross Turk
ممکن است متوجه شده باشید که Ceph چگونه با سخت افزار به عنوان یک گراف از گره ها برخورد می کند که بسیار شبیه به Kubernetes است. این بدان معنی است که هنگام استفاده از یک بک‌اند Kubernetes، ما به احتمال زیاد با چند خوشه و نه تنها با یکی از آنها ارتباط برقرار می‌کنیم، این درک باعث شد که درک بهتری از نحوه مدیریت سخت‌افزار در همه ابعاد داشته باشم.
این فقط یک سرور HTTP است
برای شروع یک تماس API Kubernetes، باید یک درخواست به kube-apiserver ارسال کنیم. همانطور که قبلا ذکر شد، kube-apiserver یک مؤلفه است که توسط ارائه دهنده ابر نصب شده است و یک سرور REST است. بر این اساس، هر کلاینت HTTP را می توان برای پرس و جو از back-end استفاده کرد، به عنوان مثال، cURL یا axios. با این حال، درخواست‌ها باید مجاز باشند، و پاسخ‌ها باید تجزیه شوند، بنابراین، بسته به زبان و محیطی که استفاده می‌کنید، بسیاری از پیاده‌سازی‌های مشتری Kubernetes را مشاهده خواهید کرد. یکی از واضح ترین و محبوب ترین مشتریان Kubernetes ابزار CLI آن است - kubectl.
با kubectl می‌توانید به راحتی تماس‌های API مجاز برقرار کنید، و پاسخ‌ها همیشه در قالبی قابل خواندن بر روی صفحه نمایش داده می‌شوند، که هنگام کار با ترمینال عالی است. ما حتی می‌توانیم از kubectl در حالت کلامی استفاده کنیم تا جزئیات تماس HTTP اساسی را ببینیم:
kubectl دریافت pods --v=6
در حال حاضر، می توانید به pods به عنوان برنامه های کاربردی فکر کنید (خوب، به نوعی). اگر مقاله را مرور کرده باشید، احتمالاً متوجه خواهید شد که آنها می توانند بر روی هر رایانه ای که خودسرانه انتخاب شده است، بسته به آنچه در دسترس بوده اجرا شود.
شبیه سازی درخواست Kubernetes
بنابراین بازگشت به مشکل اصلی که شروع کل این مقاله بود – ما می‌خواهیم کاربران را به رایانه‌های روی ابر متصل کنیم تا بتوانند بدون داشتن سخت‌افزار گران‌قیمت بازی کنند. هنگامی که یک کاربر تمام شد، سخت افزار اشغال شده دوباره برای میزبانی کاربر بعدی در صف در دسترس خواهد بود. بیایید سعی کنیم با این موضوع مقابله کنیم!
موارد زیر به ما داده می شود:
یک صف از کاربران.
یک خوشه Kubernetes.
یک تصویر Docker با یک بازی نصب شده است.
مشخصات پیشنهادی برای اجرای بازی به شرح زیر است:
4 هسته.
رم 16 گیگابایت.
50 گیگابایت فضای ذخیره سازی.
RTX A4000.
بر این اساس، می‌توانیم از آنچه آموخته‌ایم استفاده کنیم و فرآیند استقرار را به شرح زیر توصیف کنیم. این یک توصیف بسیار احمقانه و فرضی است، پس لطفا آن را با کمی نمک بخوانید:
هنگامی که کاربر به انتهای صف می رسد، درخواستی را با URL تصویر و مشخصات سخت افزاری مورد نظر به kube-apiserver ارسال کنید.
Kube-apiserver از etcd برای جستجوی رایانه ای با منابع کافی برای میزبانی تصویر استفاده می کند.
اگر چیزی پیدا شد، kube-apiserver از شناسه گره برای ارسال درخواست استقرار به kubelet مربوطه خود استفاده می کند.
هنگامی که استقرار با موفقیت انجام شد، kubelet یک پورت را برای اتصال به جریان بازی باز می‌گرداند.
Kube-apiserver پورت بازی را به همراه آدرس IP رایانه مورد نظر به کاربر باز می گرداند.
کاربر می تواند از http://{IP}:{port} برای اتصال به جریان بازی از طریق مرورگر وب استفاده کند.
شبیه سازی درخواست Kubernetes ساده شده
امیدوارم از مقدمه من برای Kubernetes و اصول زیربنایی آن لذت برده باشید. اگر تصمیم به یادگیری یا استفاده از آن دارید، من را خبر کنید
مایکروسافت تقریباً جاوا اسکریپت را از بین برد
مایکروسافت در تلاش خود برای تسلط بر وب، یک بار سعی کرد جاوا اسکریپت را از بین ببرد.
در اوایل دهه 2000، مایکروسافت اینترنت اکسپلورر پر استفاده ترین مرورگر جهان بود. رقیب آن، Netscape Navigator چندین درصد عقب افتاد. این دو مرورگر از زبان های برنامه نویسی سمت کلاینت مشابه برای تقویت تعامل استفاده می کردند، جاوا اسکریپت و جی اسکریپت برای شکل دادن به وب در دهه های آینده مبارزه می کردند.
انجام پروژه در فریلنس پروژه
مایکروسافت با در اختیار داشتن تقریباً 96 درصد از سهم بازار، نیازی به پیشبرد ابتکاری که استفاده همگانی از جاوا اسکریپت را در مرورگرها از طریق یک استاندارد ترویج می کرد، احساس نمی کرد. در یک سری اتفاقاتی که منجر به اتهامات ضد تراست در سال 1998 و استعفای بیل گیتس شد، مایکروسافت تقریباً باعث مرگ جاوا اسکریپت شد.
مسابقه
اولین مرورگر وب با رابط کاربری گرافیکی، Mosaic، در سال 1993 منتشر شد. این مرورگر که برای افراد غیر فنی قابل دسترسی بود، نقش برجسته ای در رشد سریع وب جهانی نوپا - ویکی پدیا داشت.
هنگامی که پروژه Mosaic خاتمه یافت، مایکروسافت مجوز نرم افزار را صادر کرد و اینترنت اکسپلورر را در بالای آن ساخت. برخی از مهندسانی که روی مرورگر Mosaic کار کرده بودند، شرکت جدیدی به نام نت اسکیپ را تأسیس کردند. این دو شرکت در مبارزه برای تسلط بر بازار یکدیگر را پیدا کردند. که عواقب آن مدت ها محسوس خواهد بود.
سفارش ساخت سایت در فریلنس پروژه
تقریباً زمانی که رایانه‌ها به طور منطقی پیچیده و تعاملی بودند، وب‌سایت‌ها در سال 1995 ثابت و غیرقابل دعوت بودند. چالش افرادی که روی مرورگرها کار می‌کردند، توسعه ابزارهایی بود که به طراحان وب امکان انعطاف‌پذیری بیشتری برای ایجاد سایت‌هایی با پویایی می‌داد.
در سال 1995، نت اسکیپ شروع به فکر کردن در مورد راه حل برای مشکل یک وب استاتیک کرد. رویکرد آنها دو گونه بود: از یک طرف، آنها به Sun Microsystem رسیدند تا در مورد استفاده از جاوا به عنوان یک زبان برنامه نویسی در ناوبر خود مذاکره کنند. از سوی دیگر، برندان آیخ را استخدام کردند تا زبان جدیدی را برای همین هدف ابداع کند. مدیریت ارشد در مورد مسیر دوم تصمیم گرفت و یک نمونه اولیه با موفقیت در طول سال توسعه یافت.
در همان سال مایکروسافت اینترنت اکسپلورر را راه اندازی کرد. یک سال بعد، آنها نسخه مهندسی معکوس جاوا اسکریپت به نام JScript را منتشر کردند. توسعه این دو مرورگر به قدری از هم دور می‌شد که در برخی مواقع، ایجاد وب‌سایت‌هایی که در مرورگرهای مختلف یکسان به نظر می‌رسند بسیار دشوار شد. برچسب هایی مانند "بهترین مشاهده در نت اسکیپ" و "بهترین مشاهده شده در اینترنت اکسپلورر" در وب سایت ها رایج شد.
محاصره بی رحمانه
در اوایل دهه 2000، مایکروسافت برنده آشکار بود. از هر 10 نفر 9 نفر از اینترنت اکسپلورر استفاده می کردند. اگرچه نت اسکیپ در اواسط دهه 90 با یک سهم راحت شروع به کار کرده بود، اما این مایکروسافت بود که 96 درصد از بازار را در آغاز دهه 2000 در اختیار داشت. مایکروسافت چگونه چنین شاهکار خارق العاده ای را مدیریت کرد؟
انجام پروژه متلب با بهترین متخصصان
دلایل زیادی چنین دستاوردی را نشان می دهد، تعدادی از آنها بعداً در دادگاه مورد مناقشه قرار گرفتند. به عنوان یک چیز، مایکروسافت قبلاً یک شرکت سهامی عام با منابع مالی گسترده بود که نت اسکیپ در سال 1995 عمومی شد. ارزش بازار مایکروسافت در مقطعی در سال 1996، 10 برابر نت اسکیپ بود.
دو حرکت مهم از طرف مایکروسافت انجام شد که موقعیت صفحه شطرنج را به طرز چشمگیری تغییر داد. یکی از آنها زمانی بود که مایکروسافت تصمیم گرفت هر نسخه از ویندوز را با نصب اینترنت اکسپلورر جمع کند. و دوم، با اعطای استفاده رایگان از مرورگر نه تنها به کاربران ویندوز، بلکه به کسانی که از مکینتاش اپل استفاده می کنند.
به نقل از جیم بارکسدیل، مدیرعامل وقت نت اسکیپ، گفته می‌شود که «در زمان‌های بسیار کمی در جنگ، نیروهای کوچک‌تر بر نیروهای بزرگ‌تر غلبه کرده‌اند...». مبارزه آنها برای بقا به جای استثنا، یک هنجار بود. نت اسکیپ که قادر به ادامه مبارزه نبود، در سال 2002 توسط AOL خریداری شد.
ضربه ای که قرار بود کشنده باشد
عکس یوهان والتر بانتز در Unsplash
در سال 1996، یک سال پس از راه اندازی جاوا اسکریپت، نت اسکیپ پیشنهادی را برای استانداردسازی این زبان به ECMA International ارائه کرد. مایکروسافت در روزهای اولیه به این تلاش پیوست. در اواخر دهه 90 و اوایل دهه 2000، مایکروسافت در وضعیت کاملاً متفاوتی نسبت به سال 1996 قرار داشت.
نادرست نیست اگر بگوییم جاوا اسکریپت یک فناوری اختصاصی شرکت مایکروسافت در اوایل دهه 2000 بود.
در مقطعی، مایکروسافت تمام تلاش‌های خود برای استانداردسازی جاوا اسکریپت را کنار گذاشت و به جای آن بر گسترش دسترسی اینترنت اکسپلورر متمرکز شد. منطقی که در پس تصمیم برای توقف هرگونه پیشرفت به سوی استانداردسازی وجود دارد، کاملاً منطقی اقتصادی است. از آنجایی که مایکروسافت از قبل کنترل کاملی بر بازار داشت، هرگونه تلاش برای یکسان سازی جاوا اسکریپت در بین مرورگرها بیشتر از هر مرورگر دیگری به اینترنت اکسپلورر آسیب می رساند.
نادرست نیست اگر بگوییم جاوا اسکریپت یک فناوری اختصاصی شرکت مایکروسافت در اوایل دهه 2000 بود. مایکروسافت کنترل مطلق بر آن داشت. منبع باز تحت سانسور شرکتی شکوفا نمی شود، تعداد بسیار کمی ابزارهایی را با این زبان توسعه می دادند، و به همین دلیل رشد کافی نبود.
مسیر جاو