1C ওয়েব ক্লায়েন্ট সম্পর্কে

1C:Enterprise প্রযুক্তির একটি চমৎকার বৈশিষ্ট্য হল যে অ্যাপ্লিকেশন সলিউশন, পরিচালিত ফর্ম প্রযুক্তি ব্যবহার করে তৈরি করা হয়েছে, উইন্ডোজ, লিনাক্স, MacOS X-এর জন্য একটি পাতলা (এক্সিকিউটেবল) ক্লায়েন্ট এবং 5টি ব্রাউজারগুলির জন্য একটি ওয়েব ক্লায়েন্ট হিসাবে উভয়ই লঞ্চ করা যেতে পারে - ক্রোম, ইন্টারনেট এক্সপ্লোরার, ফায়ারফক্স, সাফারি, এজ এবং এই সবই অ্যাপ্লিকেশন সোর্স কোড পরিবর্তন না করে। তদুপরি, বাহ্যিকভাবে পাতলা ক্লায়েন্ট এবং ব্রাউজারে অ্যাপ্লিকেশনটি কাজ করে এবং প্রায় একই রকম দেখায়।
10টি পার্থক্য খুঁজুন (কাটার নিচে 2টি ছবি):

লিনাক্সে পাতলা ক্লায়েন্ট উইন্ডো:

ওয়েব ক্লায়েন্টে একই উইন্ডো (ক্রোম ব্রাউজারে):

কেন আমরা একটি ওয়েব ক্লায়েন্ট বানালাম? কিছুটা করুণভাবে বলতে গেলে, সময় আমাদের জন্য এমন একটি কাজ নির্ধারণ করেছে। ইন্টারনেটে কাজ করা ব্যবসায়িক অ্যাপ্লিকেশনের জন্য একটি পূর্বশর্ত হয়েছে। প্রথমত, আমরা আমাদের পাতলা ক্লায়েন্টের জন্য ইন্টারনেটের মাধ্যমে কাজ করার ক্ষমতা যুক্ত করেছি (আমাদের কিছু প্রতিযোগী, যাইহোক, এতেই থেমে গেছে; অন্যরা, বিপরীতে, পাতলা ক্লায়েন্টকে পরিত্যাগ করেছে এবং একটি ওয়েব ক্লায়েন্ট বাস্তবায়নে নিজেদের সীমাবদ্ধ করেছে)। আমরা আমাদের ব্যবহারকারীদের ক্লায়েন্ট বিকল্পটি বেছে নেওয়ার সুযোগ দেওয়ার সিদ্ধান্ত নিয়েছি যা তাদের জন্য সবচেয়ে উপযুক্ত।

ক্লায়েন্ট-সার্ভার আর্কিটেকচারে সম্পূর্ণ পরিবর্তন সহ পাতলা ক্লায়েন্টে ওয়েব-ভিত্তিক ক্ষমতা যুক্ত করা একটি বড় প্রকল্প ছিল। একটি ওয়েব ক্লায়েন্ট তৈরি করা একটি সম্পূর্ণ নতুন প্রকল্প, স্ক্র্যাচ থেকে শুরু করে।

সমস্যা গঠন

সুতরাং, প্রকল্পের প্রয়োজনীয়তা: ওয়েব ক্লায়েন্টকে অবশ্যই পাতলা ক্লায়েন্টের মতোই করতে হবে, যথা:

1. ইউজার ইন্টারফেস প্রদর্শন করুন
2. 1C ভাষায় লেখা ক্লায়েন্ট কোড চালান

1C-তে ইউজার ইন্টারফেসটি একটি ভিজ্যুয়াল এডিটরে বর্ণনা করা হয়েছে, তবে উপাদানগুলির পিক্সেল-বাই-পিক্সেল বিন্যাস ছাড়াই ঘোষণামূলকভাবে; প্রায় তিন ডজন ধরণের ইন্টারফেস উপাদান ব্যবহার করা হয় - বোতাম, ইনপুট ক্ষেত্র (টেক্সট, সংখ্যাসূচক, তারিখ/সময়), তালিকা, টেবিল, গ্রাফ ইত্যাদি।

1C ভাষায় ক্লায়েন্ট কোড সার্ভার কল, স্থানীয় সম্পদ (ফাইল, ইত্যাদি), মুদ্রণ, এবং আরও অনেক কিছু ধারণ করতে পারে।

পাতলা ক্লায়েন্ট (ওয়েবের মাধ্যমে কাজ করার সময়) এবং ওয়েব ক্লায়েন্ট উভয়ই 1C অ্যাপ্লিকেশন সার্ভারের সাথে যোগাযোগ করতে একই সেট ওয়েব পরিষেবা ব্যবহার করে। ক্লায়েন্ট বাস্তবায়ন, অবশ্যই, ভিন্ন - পাতলা ক্লায়েন্ট C++ এ লেখা হয়, ওয়েব ক্লায়েন্ট জাভাস্ক্রিপ্টে লেখা হয়।

ইতিহাস একটি বিট

ওয়েব ক্লায়েন্ট প্রকল্পটি 2006 সালে শুরু হয়েছিল, (গড়ে) 5 জনের একটি দল নিয়ে। প্রকল্পের নির্দিষ্ট পর্যায়ে, বিকাশকারীরা নির্দিষ্ট কার্যকারিতা (স্প্রেডশীট নথি, ডায়াগ্রাম, ইত্যাদি) বাস্তবায়নের জন্য জড়িত ছিল; একটি নিয়ম হিসাবে, এই একই বিকাশকারীরা যারা পাতলা ক্লায়েন্টে এই কার্যকারিতা করেছিলেন। সেগুলো. ডেভেলপাররা জাভাস্ক্রিপ্টে কম্পোনেন্ট পুনঃলিখেন যা তারা আগে C++ এ তৈরি করেছিল।

প্রথম থেকেই, দুটি ভাষার মধ্যে শক্তিশালী ধারণাগত পার্থক্যের কারণে আমরা জাভাস্ক্রিপ্ট ওয়েব ক্লায়েন্টে C++ পাতলা ক্লায়েন্ট কোডের যেকোনো স্বয়ংক্রিয় (এমনকি আংশিক) রূপান্তরের ধারণা প্রত্যাখ্যান করেছি; ওয়েব ক্লায়েন্ট স্ক্র্যাচ থেকে জাভাস্ক্রিপ্টে লেখা হয়েছিল।

প্রকল্পের প্রথম পুনরাবৃত্তিতে, ওয়েব ক্লায়েন্ট অন্তর্নির্মিত 1C ভাষায় ক্লায়েন্ট কোড সরাসরি জাভাস্ক্রিপ্টে রূপান্তর করেছে। পাতলা ক্লায়েন্ট ভিন্নভাবে কাজ করে - অন্তর্নির্মিত 1C ভাষায় কোডটি বাইটকোডে সংকলিত হয় এবং তারপরে এই বাইটকোডটি ক্লায়েন্টে ব্যাখ্যা করা হয়। পরবর্তীকালে, ওয়েব ক্লায়েন্ট একই কাজ করতে শুরু করে - প্রথমত, এটি একটি কর্মক্ষমতা লাভ করেছে এবং দ্বিতীয়ত, এটি পাতলা এবং ওয়েব ক্লায়েন্টদের আর্কিটেকচারকে একত্রিত করা সম্ভব করেছে।

1C এর প্রথম সংস্করণ: ওয়েব ক্লায়েন্ট সমর্থন সহ এন্টারপ্রাইজ প্ল্যাটফর্ম 2009 সালে প্রকাশিত হয়েছিল। সেই সময়ে ওয়েব ক্লায়েন্ট 2টি ব্রাউজার সমর্থন করেছিল - ইন্টারনেট এক্সপ্লোরার এবং ফায়ারফক্স। মূল পরিকল্পনায় অপেরার জন্য সমর্থন অন্তর্ভুক্ত ছিল, কিন্তু অপেরার অ্যাপ্লিকেশন বন্ধ হ্যান্ডলারগুলির সাথে সেই সময়ে দুর্লভ সমস্যার কারণে (এটি 100% নিশ্চিততার সাথে ট্র্যাক করা সম্ভব ছিল না যে অ্যাপ্লিকেশনটি বন্ধ হয়ে যাচ্ছে, এবং সেই মুহুর্তে সংযোগ বিচ্ছিন্ন করার প্রক্রিয়াটি চালান এই প্ল্যানগুলি থেকে 1C অ্যাপ্লিকেশন সার্ভার) পরিত্যাগ করতে হয়েছিল।

প্রকল্প কাঠামো

মোট, 1C:এন্টারপ্রাইজ প্ল্যাটফর্মে জাভাস্ক্রিপ্টে লেখা 4টি প্রকল্প রয়েছে:

1. WebTools – অন্যান্য প্রকল্প দ্বারা ব্যবহৃত শেয়ার্ড লাইব্রেরি (আমরাও অন্তর্ভুক্ত করি গুগল ক্লোজার লাইব্রেরি).
2. নিয়ন্ত্রণ উপাদান ফরম্যাটেড ডকুমেন্ট (পাতলা ক্লায়েন্ট এবং ওয়েব ক্লায়েন্ট উভয় ক্ষেত্রে জাভাস্ক্রিপ্টে প্রয়োগ করা হয়েছে)
3. নিয়ন্ত্রণ উপাদান সময়সূচী (পাতলা ক্লায়েন্ট এবং ওয়েব ক্লায়েন্ট উভয় ক্ষেত্রে জাভাস্ক্রিপ্টে প্রয়োগ করা হয়েছে)
4. ওয়েব ক্লায়েন্ট

প্রতিটি প্রকল্পের কাঠামো জাভা প্রকল্পগুলির কাঠামোর সাথে সাদৃশ্যপূর্ণ (বা .NET প্রকল্প - যেটি কাছাকাছি); আমাদের নামস্থান রয়েছে এবং প্রতিটি নামস্থান একটি পৃথক ফোল্ডারে রয়েছে। ফোল্ডারের ভিতরে ফাইল এবং নেমস্পেস ক্লাস আছে। ওয়েব ক্লায়েন্ট প্রকল্পে প্রায় 1000 ফাইল রয়েছে।

কাঠামোগতভাবে, ওয়েব ক্লায়েন্ট মূলত নিম্নলিখিত সাবসিস্টেমগুলিতে বিভক্ত:

• পরিচালিত ক্লায়েন্ট অ্যাপ্লিকেশন ইন্টারফেস
  • সাধারণ অ্যাপ্লিকেশন ইন্টারফেস (সিস্টেম মেনু, প্যানেল)
  • পরিচালিত ফর্মগুলির ইন্টারফেস, অন্যান্য জিনিসগুলির মধ্যে, প্রায় 30টি নিয়ন্ত্রণ সহ (বোতাম, বিভিন্ন ধরণের ইনপুট ক্ষেত্র - পাঠ্য, সংখ্যাসূচক, তারিখ/সময়, ইত্যাদি, টেবিল, তালিকা, গ্রাফ, ইত্যাদি)

• ক্লায়েন্টে ডেভেলপারদের জন্য অবজেক্ট মডেল উপলব্ধ (মোট 400 টিরও বেশি প্রকার: পরিচালিত ইন্টারফেস অবজেক্ট মডেল, ডেটা লেআউট সেটিংস, শর্তাধীন স্টাইলিং ইত্যাদি)
• অন্তর্নির্মিত 1C ভাষার দোভাষী
• ব্রাউজার এক্সটেনশন (জাভাস্ক্রিপ্টে সমর্থিত নয় কার্যকারিতার জন্য ব্যবহৃত)
  • ক্রিপ্টোগ্রাফি নিয়ে কাজ করা
  • ফাইল সঙ্গে কাজ
  • বাহ্যিক উপাদানগুলির প্রযুক্তি, তাদের পাতলা এবং ওয়েব ক্লায়েন্ট উভয় ক্ষেত্রেই ব্যবহার করার অনুমতি দেয়

নকশা বৈশিষ্ট্য

উপরের সবগুলো জাভাস্ক্রিপ্টে প্রয়োগ করা সহজ নয়। সম্ভবত 1C ওয়েব ক্লায়েন্ট হল জাভাস্ক্রিপ্টে লেখা সবচেয়ে বড় ক্লায়েন্ট-সাইড অ্যাপ্লিকেশনগুলির মধ্যে একটি - প্রায় 450.000 লাইন। আমরা সক্রিয়ভাবে ওয়েব ক্লায়েন্ট কোডে একটি অবজেক্ট-ওরিয়েন্টেড পদ্ধতি ব্যবহার করি, যা এত বড় প্রকল্পের সাথে কাজকে সহজ করে।

ক্লায়েন্ট কোডের আকার ছোট করার জন্য, আমরা প্রথমে আমাদের নিজস্ব অবফুসকেটর ব্যবহার করেছি এবং প্ল্যাটফর্ম সংস্করণ 8.3.6 (অক্টোবর 2014) দিয়ে শুরু করে আমরা ব্যবহার করতে শুরু করেছি গুগল ক্লোজার কম্পাইলার. সংখ্যায় ব্যবহারের প্রভাব – অস্পষ্টতার পরে ওয়েব ক্লায়েন্ট ফ্রেমওয়ার্কের আকার:

• নিজস্ব অবফুসকেটর - 1556 কেবি
• গুগল ক্লোজার কম্পাইলার – 1073 কেবি

গুগল ক্লোজার কম্পাইলার ব্যবহার করা আমাদের নিজস্ব অবাসকেটরের তুলনায় ওয়েব ক্লায়েন্টের কার্যক্ষমতা 30% উন্নত করতে সাহায্য করেছে। উপরন্তু, অ্যাপ্লিকেশন দ্বারা গ্রাস করা মেমরির পরিমাণ 15-25% কমেছে (ব্রাউজারের উপর নির্ভর করে)।

গুগল ক্লোজার কম্পাইলার অবজেক্ট-ওরিয়েন্টেড কোডের সাথে খুব ভাল কাজ করে, তাই ওয়েব ক্লায়েন্টের জন্য এটির দক্ষতা যতটা সম্ভব বেশি। ক্লোজার কম্পাইলার আমাদের জন্য কয়েকটি ভাল জিনিস করে:

• প্রজেক্ট বিল্ড স্টেজে স্ট্যাটিক টাইপ চেকিং (নিশ্চিত করে যে আমরা JSDoc টীকা দিয়ে কোড কভার করেছি)। ফলাফল হল স্ট্যাটিক টাইপিং, C++ এ টাইপ করার খুব কাছাকাছি। এটি প্রকল্প সংকলন পর্যায়ে একটি মোটামুটি বড় শতাংশ ত্রুটি ধরতে সাহায্য করে।
• অস্পষ্টতার মাধ্যমে কোডের আকার হ্রাস করা
• সঞ্চালিত কোডের অনেকগুলি অপ্টিমাইজেশন, উদাহরণস্বরূপ, যেমন:
  • ইনলাইন ফাংশন প্রতিস্থাপন. জাভাস্ক্রিপ্টে একটি ফাংশন কল করা একটি মোটামুটি ব্যয়বহুল অপারেশন, এবং প্রায়শই ব্যবহৃত ছোট পদ্ধতিগুলির ইনলাইন প্রতিস্থাপনগুলি উল্লেখযোগ্যভাবে কোডের গতি বাড়ায়।
  • কম্পাইল সময়ে ধ্রুবক গণনা. যদি একটি রাশি একটি ধ্রুবকের উপর নির্ভর করে, তবে ধ্রুবকের প্রকৃত মান এটিতে প্রতিস্থাপিত হবে

আমরা আমাদের ওয়েব ক্লায়েন্ট উন্নয়ন পরিবেশ হিসাবে WebStorm ব্যবহার করি।

কোড বিশ্লেষণের জন্য আমরা ব্যবহার করি সোনারকিউব, যেখানে আমরা স্ট্যাটিক কোড বিশ্লেষককে একীভূত করি। বিশ্লেষক ব্যবহার করে, আমরা জাভাস্ক্রিপ্ট সোর্স কোডের মানের অবনতি পর্যবেক্ষণ করি এবং এটি প্রতিরোধ করার চেষ্টা করি।

আমরা কি সমস্যা সমাধান করেছি/করছি?

প্রকল্পটি বাস্তবায়নের সময়, আমরা বেশ কয়েকটি আকর্ষণীয় সমস্যার সম্মুখীন হয়েছিলাম যা আমাদের সমাধান করতে হয়েছিল।

সার্ভারের সাথে এবং উইন্ডোজের মধ্যে ডেটা বিনিময় করুন

এমন কিছু পরিস্থিতিতে আছে যেখানে সোর্স কোডের অস্পষ্টতা সিস্টেমের অপারেশনে হস্তক্ষেপ করতে পারে। ওয়েব ক্লায়েন্টের এক্সিকিউটেবল কোডের বাহ্যিক কোড, অস্পষ্টতার কারণে, ফাংশন এবং প্যারামিটারের নাম থাকতে পারে যা আমাদের এক্সিকিউটেবল কোড আশা করে তার থেকে আলাদা। আমাদের জন্য বাহ্যিক কোড হল:

• ডেটা স্ট্রাকচার আকারে সার্ভার থেকে কোড আসছে
• অন্য অ্যাপ্লিকেশন উইন্ডোর জন্য কোড

সার্ভারের সাথে ইন্টারঅ্যাক্ট করার সময় অস্পষ্টতা এড়াতে, আমরা @expose ট্যাগ ব্যবহার করি:

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

এবং অন্যান্য উইন্ডোগুলির সাথে ইন্টারঅ্যাক্ট করার সময় অস্পষ্টতা এড়াতে, আমরা তথাকথিত এক্সপোর্ট করা ইন্টারফেস ব্যবহার করি (ইন্টারফেস যেখানে সমস্ত পদ্ধতি এক্সপোর্ট করা হয়)।

/**
 * Экспортируемый интерфейс контрола DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 * Перемещает выделение на 1 вперед или назад
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 * Перемещает выделение в начало или конец
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

মূলধারায় পরিণত হওয়ার আগে আমরা ভার্চুয়াল DOM ব্যবহার করেছি)

জটিল ওয়েব UI নিয়ে কাজ করে এমন সমস্ত বিকাশকারীদের মতো, আমরা দ্রুত বুঝতে পেরেছি যে DOM গতিশীল ব্যবহারকারী ইন্টারফেসের সাথে কাজ করার জন্য খারাপভাবে উপযুক্ত। প্রায় অবিলম্বে, ভার্চুয়াল DOM-এর একটি অ্যানালগ UI-এর সাথে কাজ অপ্টিমাইজ করার জন্য প্রয়োগ করা হয়েছিল। ইভেন্ট প্রক্রিয়াকরণের সময়, সমস্ত DOM পরিবর্তনগুলি মেমরিতে সংরক্ষণ করা হয় এবং, শুধুমাত্র যখন সমস্ত ক্রিয়াকলাপ সম্পূর্ণ হয়, জমাকৃত পরিবর্তনগুলি DOM ট্রিতে প্রয়োগ করা হয়।

ওয়েব ক্লায়েন্ট অপ্টিমাইজ করা

আমাদের ওয়েব ক্লায়েন্টকে দ্রুত কাজ করার জন্য, আমরা স্ট্যান্ডার্ড ব্রাউজার ক্ষমতা (CSS, ইত্যাদি) সর্বোচ্চ ব্যবহার করার চেষ্টা করি। এইভাবে, ফর্ম কমান্ড প্যানেল (অ্যাপ্লিকেশনের প্রায় প্রতিটি ফর্মে অবস্থিত) শুধুমাত্র ব্রাউজার টুল ব্যবহার করে, CSS-এর উপর ভিত্তি করে ডায়নামিক লেআউট ব্যবহার করে রেন্ডার করা হয়।

পরীক্ষামূলক

কার্যকরী এবং কর্মক্ষমতা পরীক্ষার জন্য, আমরা একটি মালিকানাধীন টুল ব্যবহার করি (জাভা এবং C++ তে লেখা), সেইসাথে উপরে নির্মিত পরীক্ষার একটি স্যুট সেলেনিউম্.

আমাদের টুল সার্বজনীন - এটি আপনাকে প্রায় যেকোনো উইন্ডোড প্রোগ্রাম পরীক্ষা করতে দেয়, এবং তাই একটি পাতলা ক্লায়েন্ট এবং একটি ওয়েব ক্লায়েন্ট উভয়েরই পরীক্ষা করার জন্য উপযুক্ত। টুলটি সেই ব্যবহারকারীর ক্রিয়া রেকর্ড করে যারা একটি স্ক্রিপ্ট ফাইলে 1C অ্যাপ্লিকেশন সমাধান চালু করেছে। একই সময়ে, স্ক্রিনের কার্যক্ষেত্রের চিত্র - মান - রেকর্ড করা হয়। ওয়েব ক্লায়েন্টের নতুন সংস্করণগুলি পর্যবেক্ষণ করার সময়, ব্যবহারকারীর অংশগ্রহণ ছাড়াই স্ক্রিপ্টগুলি চালানো হয়। যে ক্ষেত্রে স্ক্রিনশটটি যেকোন ধাপে রেফারেন্সের সাথে মেলে না, পরীক্ষাটি ব্যর্থ বলে বিবেচিত হয়, তারপরে একজন গুণমান বিশেষজ্ঞ এটি একটি ত্রুটি বা সিস্টেমের আচরণে পরিকল্পিত পরিবর্তন কিনা তা নির্ধারণ করার জন্য একটি তদন্ত পরিচালনা করেন। পরিকল্পিত আচরণের ক্ষেত্রে, মানগুলি স্বয়ংক্রিয়ভাবে নতুনগুলির সাথে প্রতিস্থাপিত হয়।

টুলটি 25 মিলিসেকেন্ড পর্যন্ত নির্ভুলতার সাথে অ্যাপ্লিকেশন কার্যকারিতা পরিমাপ করে। কিছু ক্ষেত্রে, আমরা সময়ের সাথে সাথে কার্যকর করার সময়ের অবনতি বিশ্লেষণ করতে স্ক্রিপ্টের অংশগুলি লুপ করি (উদাহরণস্বরূপ, অর্ডার এন্ট্রিটি কয়েকবার পুনরাবৃত্তি করি)। সমস্ত পরিমাপের ফলাফল বিশ্লেষণের জন্য একটি লগে রেকর্ড করা হয়।

আমাদের পরীক্ষার টুল এবং পরীক্ষার অধীনে অ্যাপ্লিকেশন

আমাদের টুল এবং সেলেনিয়াম একে অপরের পরিপূরক; উদাহরণস্বরূপ, যদি কোনও একটি স্ক্রিনের কিছু বোতাম তার অবস্থান পরিবর্তন করে থাকে, সেলেনিয়াম এটি ট্র্যাক নাও করতে পারে, তবে আমাদের সরঞ্জামটি লক্ষ্য করবে, কারণ স্ট্যান্ডার্ডের সাথে স্ক্রিনশটের একটি পিক্সেল-বাই-পিক্সেল তুলনা করে। টুলটি কীবোর্ড বা মাউস থেকে ইনপুট প্রক্রিয়াকরণের সমস্যাগুলিও ট্র্যাক করতে সক্ষম, যেহেতু এটি ঠিক এটিই পুনরুত্পাদন করে।

উভয় সরঞ্জামের (আমাদের এবং সেলেনিয়াম) পরীক্ষাগুলি আমাদের অ্যাপ্লিকেশন সমাধানগুলি থেকে সাধারণ কাজের পরিস্থিতি চালায়। 1C:Enterprise প্ল্যাটফর্মের দৈনিক নির্মাণের পরে পরীক্ষাগুলি স্বয়ংক্রিয়ভাবে চালু হয়। যদি স্ক্রিপ্টগুলি ধীর হয় (আগের বিল্ডের তুলনায়), আমরা তদন্ত করে ধীরগতির কারণটি সমাধান করি৷ আমাদের মানদণ্ড সহজ - নতুন বিল্ডটি আগেরটির চেয়ে ধীরগতিতে কাজ করবে না।

বিকাশকারীরা ধীরগতির ঘটনাগুলি তদন্ত করতে বিভিন্ন সরঞ্জাম ব্যবহার করে; প্রধানত ব্যবহৃত Dynatrace AJAX সংস্করণ সংস্থা উত্পাদন ডাইনাট্রেস. পূর্ববর্তী এবং নতুন বিল্ডে সমস্যাযুক্ত অপারেশন সম্পাদনের লগগুলি রেকর্ড করা হয়, তারপর লগগুলি বিশ্লেষণ করা হয়। একই সময়ে, একক ক্রিয়াকলাপগুলির সম্পাদনের সময় (মিলিসেকেন্ডে) একটি নির্ধারক ফ্যাক্টর নাও হতে পারে - আবর্জনা সংগ্রহের মতো পরিষেবা প্রক্রিয়াগুলি পর্যায়ক্রমে ব্রাউজারে চালু করা হয়, তারা ফাংশন সম্পাদনের সময়ের সাথে ওভারল্যাপ করতে পারে এবং ছবি বিকৃত করতে পারে। এই ক্ষেত্রে আরও প্রাসঙ্গিক পরামিতি হবে জাভাস্ক্রিপ্ট নির্দেশাবলীর সংখ্যা, DOM-এ পারমাণবিক অপারেশনের সংখ্যা ইত্যাদি। যদি একটি নতুন সংস্করণে একই স্ক্রিপ্টে নির্দেশাবলী/অপারেশনের সংখ্যা বৃদ্ধি পায়, তবে এর অর্থ প্রায় সবসময়ই কার্যক্ষমতা হ্রাস পায় যা সংশোধন করা প্রয়োজন।

এছাড়াও, কর্মক্ষমতা হ্রাসের একটি কারণ হতে পারে যে Google ক্লোজার কম্পাইলার কোনো কারণে ফাংশনের ইনলাইন প্রতিস্থাপন করতে পারেনি (উদাহরণস্বরূপ, কারণ ফাংশনটি পুনরাবৃত্তিমূলক বা ভার্চুয়াল)। এই ক্ষেত্রে, আমরা সোর্স কোড পুনরায় লেখার মাধ্যমে পরিস্থিতি সংশোধন করার চেষ্টা করি।

ব্রাউজার এক্সটেনশন

যখন একটি অ্যাপ্লিকেশন সমাধানের কার্যকারিতা প্রয়োজন যা জাভাস্ক্রিপ্টে উপলব্ধ নয়, আমরা ব্রাউজার এক্সটেনশন ব্যবহার করি:

• ফাইল নিয়ে কাজ করার জন্য
• ক্রিপ্টোগ্রাফি নিয়ে কাজ করার জন্য
• সাথে কাজ করে বাহ্যিক উপাদান

আমাদের এক্সটেনশন দুটি অংশ গঠিত. প্রথম অংশটিকে ব্রাউজার এক্সটেনশন বলা হয় (সাধারণত জাভাস্ক্রিপ্টে লেখা Chrome এবং ফায়ারফক্সের জন্য এক্সটেনশন), যা দ্বিতীয় অংশের সাথে ইন্টারঅ্যাক্ট করে - একটি বাইনারি এক্সটেনশন যা আমাদের প্রয়োজনীয় কার্যকারিতা প্রয়োগ করে। এটি উল্লেখ করা উচিত যে আমরা বাইনারি এক্সটেনশনের 3 টি সংস্করণ লিখি - উইন্ডোজ, লিনাক্স এবং ম্যাকওএসের জন্য। বাইনারি এক্সটেনশনটি 1C:Enterprise প্ল্যাটফর্মের অংশ হিসাবে সরবরাহ করা হয় এবং 1C অ্যাপ্লিকেশন সার্ভারে অবস্থিত। একটি ওয়েব ক্লায়েন্ট থেকে প্রথমবার কল করা হলে, এটি ক্লায়েন্ট কম্পিউটারে ডাউনলোড করা হয় এবং ব্রাউজারে ইনস্টল করা হয়।

সাফারিতে চলাকালীন, আমাদের এক্সটেনশনগুলি NPAPI ব্যবহার করে; ইন্টারনেট এক্সপ্লোরারে চলার সময়, তারা ActiveX প্রযুক্তি ব্যবহার করে। Microsoft Edge এখনও এক্সটেনশন সমর্থন করে না, তাই এটির ওয়েব ক্লায়েন্ট সীমাবদ্ধতার সাথে কাজ করে।

আরও বিকাশ

ওয়েব ক্লায়েন্ট ডেভেলপমেন্ট টিমের অন্যতম কাজ হল কার্যকারিতার আরও উন্নয়ন। ওয়েব ক্লায়েন্টের কার্যকারিতা পাতলা ক্লায়েন্টের কার্যকারিতার সাথে অভিন্ন হওয়া উচিত; সমস্ত নতুন কার্যকারিতা পাতলা এবং ওয়েব ক্লায়েন্ট উভয় ক্ষেত্রেই একই সাথে প্রয়োগ করা হয়।

অন্যান্য কাজের মধ্যে রয়েছে আর্কিটেকচারের উন্নয়ন, রিফ্যাক্টরিং, কর্মক্ষমতা এবং নির্ভরযোগ্যতা উন্নত করা। উদাহরণস্বরূপ, নির্দেশগুলির মধ্যে একটি হল একটি অ্যাসিঙ্ক্রোনাস কাজের মডেলের দিকে আরও গতিশীল। ওয়েব ক্লায়েন্টের কিছু কার্যকারিতা বর্তমানে সার্ভারের সাথে ইন্টারঅ্যাকশনের একটি সিঙ্ক্রোনাস মডেলের উপর নির্মিত। অ্যাসিঙ্ক্রোনাস মডেলটি এখন ব্রাউজারগুলিতে আরও প্রাসঙ্গিক হয়ে উঠছে (এবং শুধুমাত্র ব্রাউজারগুলিতে নয়), এবং এটি আমাদেরকে অসিঙ্ক্রোনাস কলগুলির সাথে সিঙ্ক্রোনাস কলগুলিকে প্রতিস্থাপন করে (এবং সেই অনুযায়ী কোডটি রিফ্যাক্টর করে) ওয়েব ক্লায়েন্টকে সংশোধন করতে বাধ্য করে৷ একটি অ্যাসিঙ্ক্রোনাস মডেলে ধীরে ধীরে রূপান্তর প্রকাশ করা সমাধানগুলিকে সমর্থন করার প্রয়োজনীয়তা এবং তাদের ধীরে ধীরে অভিযোজন দ্বারা ব্যাখ্যা করা হয়েছে।

উত্স: www.habr.com