ہم اسپرنگ ہیکاتھون DevDays کے منصوبوں کے بارے میں بات کرتے رہتے ہیں، جس میں ماسٹرز پروگرام کے طلباء نے حصہ لیا تھا۔ .
ویسے ہم قارئین کو شرکت کی دعوت دینا چاہیں گے۔ . اس میں ہم بھرتی اور مطالعہ کے بارے میں تازہ ترین خبریں شائع کریں گے۔ کھلے دن کی ایک ویڈیو بھی گروپ میں دیکھی جا سکتی ہے۔ ہم آپ کو یاد دلاتے ہیں: ایونٹ 29 اپریل کو ہوگا، تفصیلات .
ٹیلیگرام ڈیسک ٹاپ وائس میسج پارسر
خیال کے مصنف
خروشیف آرٹیوم
کمانڈ کا ڈھانچہ
خروشیف آرٹیم – پروجیکٹ مینیجر/ڈیولپر/QA
ایلیسیف اینٹن - کاروباری تجزیہ کار/مارکیٹنگ ماہر
ماریا کوکلینا - UI ڈیزائنر/ڈیولپر
Bakhvalov Pavel - UI ڈیزائنر/ڈیولپر/QA
ہمارے نقطہ نظر سے، ٹیلی گرام ایک جدید اور آسان میسنجر ہے، اور اس کا پی سی ورژن مقبول اور اوپن سورس ہے، جس کی وجہ سے اس میں ترمیم ممکن ہے۔ کلائنٹ کافی بھرپور فعالیت پیش کرتا ہے۔ معیاری ٹیکسٹ پیغامات کے علاوہ، اس میں وائس کالز، ویڈیو پیغامات، اور صوتی پیغامات شامل ہیں۔ اور یہ مؤخر الذکر ہے جو کبھی کبھی ان کے وصول کنندہ کو تکلیف پہنچاتا ہے۔ کمپیوٹر یا لیپ ٹاپ پر رہتے ہوئے صوتی پیغام کو سننا اکثر ممکن نہیں ہوتا ہے۔ ماحول میں شور ہو سکتا ہے، ہیڈ فون کی کمی ہو سکتی ہے، یا آپ نہیں چاہتے کہ کوئی بھی پیغام کے مواد کو سنے۔ اگر آپ اسمارٹ فون پر ٹیلی گرام استعمال کرتے ہیں تو اس طرح کے مسائل تقریباً کبھی پیدا نہیں ہوتے، کیونکہ آپ اسے لیپ ٹاپ یا پی سی کے برعکس اپنے کان تک پہنچا سکتے ہیں۔ ہم نے اس مسئلے کو حل کرنے کی کوشش کی۔
DevDays میں ہمارے پروجیکٹ کا ہدف موصول ہونے والے صوتی پیغامات کو ٹیلیگرام ڈیسک ٹاپ کلائنٹ (اس کے بعد ٹیلیگرام ڈیسک ٹاپ کے نام سے جانا جاتا ہے) میں متن میں ترجمہ کرنے کی صلاحیت کو شامل کرنا تھا۔
اس وقت تمام اینالاگ بوٹس ہیں جن پر آپ آڈیو پیغام بھیج سکتے ہیں اور جواب میں متن وصول کر سکتے ہیں۔ ہم اس سے زیادہ خوش نہیں ہیں: بوٹ کو پیغام بھیجنا زیادہ آسان نہیں ہے؛ ہم مقامی فعالیت کو حاصل کرنا چاہیں گے۔ اس کے علاوہ، کوئی بھی بوٹ ایک تیسرا فریق ہے جو اسپیچ ریکگنیشن API اور صارف کے درمیان ایک ثالث کے طور پر کام کرتا ہے، اور یہ، کم از کم، غیر محفوظ ہے۔
جیسا کہ پہلے بتایا گیا ہے، ٹیلیگرام ڈیسک ٹاپ کے دو اہم فوائد ہیں: آسانی اور کام کی رفتار۔ اور یہ کوئی اتفاق نہیں ہے، کیونکہ یہ مکمل طور پر C++ میں لکھا گیا ہے۔ اور چونکہ ہم نے نئی فعالیت کو براہ راست کلائنٹ میں شامل کرنے کا فیصلہ کیا ہے، ہمیں اسے C++ میں تیار کرنا پڑا۔
ہماری ٹیم میں 4 لوگ تھے۔ ابتدائی طور پر، دو لوگ تقریر کی شناخت کے لیے موزوں لائبریری کی تلاش کر رہے تھے، ایک شخص ٹیلیگرام-ڈیسک ٹاپ کے سورس کوڈ کا مطالعہ کر رہا تھا، دوسرا تعمیراتی منصوبے کو تعینات کر رہا تھا۔ . بعد میں، ہر کوئی UI کو ٹھیک کرنے اور ڈیبگ کرنے میں مصروف تھا۔
ایسا لگتا تھا کہ مطلوبہ فعالیت کو نافذ کرنا مشکل نہیں ہوگا، لیکن، ہمیشہ کی طرح، مشکلات پیدا ہوئیں۔
مسئلے کا حل دو آزاد ذیلی کاموں پر مشتمل تھا: ایک مناسب تقریر کی شناخت کے آلے کا انتخاب اور نئی فعالیت کے لیے UI کو نافذ کرنا۔
آواز کی شناخت کے لیے لائبریری کا انتخاب کرتے وقت، ہمیں فوری طور پر تمام آف لائن APIs کو ترک کرنا پڑا، کیونکہ زبان کے ماڈلز بہت زیادہ جگہ لیتے ہیں۔ لیکن ہم صرف ایک زبان کی بات کر رہے ہیں۔ یہ واضح ہو گیا کہ ہمیں آن لائن API استعمال کرنا پڑے گا۔ بعد میں پتہ چلا کہ گوگل، یانڈیکس اور مائیکروسافٹ جیسے بڑے اداروں کی تقریر کی شناخت کی خدمات بالکل مفت نہیں ہیں، اور ہمیں آزمائشی مدت کے ساتھ مطمئن ہونا پڑے گا۔ نتیجے کے طور پر، Google Speech-to-Text کا انتخاب کیا گیا کیونکہ یہ آپ کو سروس استعمال کرنے کے لیے ایک ٹوکن حاصل کرنے کی اجازت دیتا ہے، جو پورے سال تک چلے گا۔
دوسرا مسئلہ جس کا ہم نے سامنا کیا وہ C++ کی کچھ خامیوں سے متعلق ہے - مرکزی ذخیرہ کی عدم موجودگی میں مختلف لائبریریوں کا چڑیا گھر۔ ایسا ہوتا ہے کہ ٹیلیگرام ڈیسک ٹاپ کا انحصار بہت سی دوسری مخصوص لائبریریوں پر ہوتا ہے۔ سرکاری ذخیرہ ہے۔ منصوبے کو جمع کرنے کے لئے. اور مثال کے طور پر تعمیراتی مسائل کے بارے میں کھلے مسائل کی ایک بڑی تعداد и . تمام مسائل کا تعلق اس حقیقت سے نکلا کہ بلڈ اسکرپٹ اوبنٹو 14.04 کے لیے لکھا گیا تھا اور اوبنٹو 18.04 کے تحت کامیابی سے ٹیلی گرام بنانے کے لیے تبدیلیاں کرنا پڑیں۔
ٹیلیگرام ڈیسک ٹاپ کو خود جمع ہونے میں کافی وقت لگتا ہے: Intel Core i5-7200U والے لیپ ٹاپ پر، تمام انحصار کے ساتھ مکمل اسمبلی (پرچم -j 4) تقریباً تین گھنٹے لگتی ہے۔ ان میں سے تقریباً 30 منٹ کلائنٹ کو خود لنک کرنے میں لیے جاتے ہیں (بعد میں پتہ چلا کہ ڈیبگ کنفیگریشن میں، لنک کرنے میں تقریباً 10 منٹ لگتے ہیں)، لیکن تبدیلیاں کرنے کے بعد لنک کرنے کا مرحلہ ہر بار دہرانا پڑتا ہے۔
مسائل کے باوجود، ہم تصور شدہ خیال کو نافذ کرنے کے ساتھ ساتھ اپ ڈیٹ کرنے میں کامیاب ہو گئے۔ Ubuntu 18.04 کے لیے۔ پر کام کا مظاہرہ دیکھا جا سکتا ہے۔ . ہم کئی متحرک تصاویر بھی شامل کرتے ہیں۔ تمام صوتی پیغامات کے آگے ایک بٹن نمودار ہوا ہے، جس سے آپ پیغام کو متن میں ترجمہ کر سکتے ہیں۔ دائیں کلک کرکے، آپ اس کے علاوہ وہ زبان بھی بتا سکتے ہیں جو نشریات کے لیے استعمال کی جائے گی۔ کی طرف سے کلائنٹ ڈاؤن لوڈ کے لیے دستیاب ہے۔
ہماری رائے میں، یہ فعالیت کے تصور کا ایک اچھا ثبوت ثابت ہوا جو بہت سے صارفین کے لیے آسان ہوگا۔ ہم اسے ٹیلیگرام ڈیسک ٹاپ کی مستقبل کی ریلیز میں دیکھنے کی امید کرتے ہیں۔
IntelliJ IDEA میں قدرتی زبان کی بہتر سپورٹ
خیال کے مصنف
ٹینکوف ولادیسلاو
کمانڈ کا ڈھانچہ
Tankov Vladislav (ٹیم لیڈ، LanguageTool اور IntelliJ IDEA کے ساتھ کام کرنا)
نکیتا سوکولوف (LanguageTool کے ساتھ کام کرنا اور UI بنانا)
خواروف الیگزینڈر (LanguageTool کے ساتھ کام کرنا اور کارکردگی کو بہتر بنانا)
Sadovnikov الیگزینڈر (مارک اپ زبانوں اور کوڈ کو پارس کرنے کے لیے سپورٹ)
ہم نے IntelliJ IDEA کے لیے ایک پلگ ان تیار کیا ہے جو گرائمیکل، ہجے اور اسٹائلسٹک درستگی (انگریزی میں اسے پروف ریڈنگ کہا جاتا ہے) کے لیے مختلف متن (تبصرے اور دستاویزات، کوڈ میں لغوی لکیریں، مارک ڈاؤن یا XML مارک اپ میں فارمیٹ شدہ ٹیکسٹ) کو چیک کرتا ہے۔
پروجیکٹ کا خیال معیاری اسپیل چیک IntelliJ IDEA کو Grammarly کے پیمانے پر پھیلانا تھا، تاکہ IDE کے اندر ایک قسم کی گرامرلی بنائی جا سکے۔
آپ دیکھ سکتے ہیں کہ کیا ہوا۔ .
ٹھیک ہے، ذیل میں ہم پلگ ان کی صلاحیتوں کے ساتھ ساتھ اس کی تخلیق کے دوران پیدا ہونے والی مشکلات کے بارے میں مزید تفصیل سے بات کریں گے۔
پریرتا
قدرتی زبانوں میں متن لکھنے کے لیے بہت ساری مصنوعات تیار کی گئی ہیں، لیکن دستاویزات اور کوڈ کے تبصرے اکثر ترقیاتی ماحول میں لکھے جاتے ہیں۔ ایک ہی وقت میں، IDEs کوڈ میں غلطیاں تلاش کرنے کا بہترین کام کرتے ہیں، لیکن قدرتی زبانوں میں متن کے لیے ناقص موزوں ہیں۔ اس سے گرائمر، رموز، یا انداز میں غلطیوں کو ترقی کے ماحول کے بغیر ان کی نشاندہی کرنا بہت آسان ہو جاتا ہے۔ یوزر انٹرفیس لکھنے میں غلطی کرنا سب سے اہم ہے، کیونکہ یہ نہ صرف کوڈ کی سمجھ بوجھ کو متاثر کرے گا بلکہ خود تیار کردہ ایپلیکیشن کے صارفین کو بھی متاثر کرے گا۔
سب سے زیادہ مقبول اور ترقی یافتہ ترقیاتی ماحول میں سے ایک IntelliJ IDEA ہے، نیز انٹیلی جے پلیٹ فارم پر مبنی IDEs۔ IntelliJ پلیٹ فارم میں پہلے سے ہی ایک بلٹ ان سپیل چیکر موجود ہے، لیکن یہ گرامر کی سادہ ترین غلطیوں سے بھی چھٹکارا نہیں پاتا۔ ہم نے انٹیلی جے آئی ڈی ای اے میں مقبول قدرتی زبان کے تجزیہ کے نظام میں سے ایک کو ضم کرنے کا فیصلہ کیا۔
Реализация
ہم نے خود کو اپنا ٹیکسٹ تصدیقی نظام بنانے کا کام متعین نہیں کیا، اس لیے ہم نے ایک موجودہ حل استعمال کیا۔ سب سے موزوں آپشن نکلا۔ . لائسنس نے ہمیں اسے اپنے مقاصد کے لیے آزادانہ طور پر استعمال کرنے کی اجازت دی: یہ مفت ہے، جاوا میں لکھا گیا ہے اور اوپن سورس ہے۔ اس کے علاوہ، یہ 25 زبانوں کو سپورٹ کرتا ہے اور پندرہ سال سے زیادہ عرصے سے ترقی میں ہے۔ اپنے کھلے پن کے باوجود، LanguageTool ادا شدہ ٹیکسٹ تصدیق کے حل کے لیے ایک سنجیدہ حریف ہے، اور حقیقت یہ ہے کہ یہ مقامی طور پر کام کر سکتا ہے لفظی طور پر اس کی قاتل خصوصیت ہے۔
پلگ ان کوڈ اندر ہے۔ . پورا پروجیکٹ کوٹلن میں UI کے لیے جاوا کے ایک چھوٹے سے اضافے کے ساتھ لکھا گیا تھا۔ ہیکاتھون کے دوران، ہم مارک ڈاؤن، جاوا ڈاک، ایچ ٹی ایم ایل اور سادہ متن کے لیے سپورٹ کو نافذ کرنے میں کامیاب رہے۔ ہیکاتھون کے بعد، ایک اہم اپ ڈیٹ نے XML، جاوا، کوٹلن اور ازگر میں سٹرنگ لٹریلز، اور ہجے کی جانچ کے لیے تعاون شامل کیا۔
مشکلات
بہت جلد ہم نے محسوس کیا کہ اگر ہم ہر بار معائنہ کے لیے تمام متن کو LanguageTool میں فیڈ کرتے ہیں، تو IDEA انٹرفیس کسی بھی کم یا زیادہ سنگین متن پر جم جائے گا، کیونکہ معائنہ خود UI کے بہاؤ کو روکتا ہے۔ مسئلہ کو 'ProgressManager.checkCancelled' چیک کے ذریعے حل کیا گیا تھا - اگر IDEA کو یقین ہے کہ معائنہ کو ختم کرنے کا وقت آگیا ہے تو یہ فنکشن ایک استثناء دیتا ہے۔
اس نے جمود کو مکمل طور پر ختم کر دیا، لیکن اس کا استعمال ناممکن ہے: متن کو پروسیس ہونے میں کافی وقت لگتا ہے۔ مزید یہ کہ، ہمارے معاملے میں، اکثر متن کا ایک بہت چھوٹا حصہ بدل جاتا ہے اور ہم کسی نہ کسی طرح نتائج کو کیش کرنا چاہتے ہیں۔ بالکل وہی جو ہم نے کیا۔ ہر بار ہر چیز کی جانچ نہ کرنے کے لیے، ہم نے متعین طور پر متن کو ٹکڑوں میں تقسیم کیا اور صرف ان کو چیک کیا جو تبدیل ہو چکے تھے۔ چونکہ نصوص بڑی ہو سکتی ہیں اور ہم کیشے کو لوڈ نہیں کرنا چاہتے تھے، اس لیے ہم نے ٹیکسٹس کو خود نہیں، بلکہ ان کی ہیشز کو محفوظ کیا۔ اس نے پلگ ان کو بڑی فائلوں پر بھی آسانی سے کام کرنے کی اجازت دی۔
LanguageTool 25 سے زیادہ زبانوں کو سپورٹ کرتا ہے، لیکن اس بات کا امکان نہیں ہے کہ کسی ایک صارف کو ان سب کی ضرورت ہو۔ میں درخواست پر کسی مخصوص زبان کے لیے لائبریریوں کو ڈاؤن لوڈ کرنے کا موقع دینا چاہتا تھا (اگر آپ اسے UI میں ٹک کرتے ہیں)۔ ہم نے اس پر عمل درآمد بھی کیا، لیکن یہ بہت پیچیدہ اور ناقابل اعتبار نکلا۔ خاص طور پر، ہمیں ایک علیحدہ کلاس لوڈر کا استعمال کرتے ہوئے زبانوں کے نئے سیٹ کے ساتھ LanguageTool لوڈ کرنا تھا، اور پھر اسے احتیاط سے شروع کرنا تھا۔ ایک ہی وقت میں، تمام لائبریریاں ایک صارف .m2 ذخیرہ میں تھیں، اور ہر شروع میں ہمیں ان کی سالمیت کو جانچنا پڑتا تھا۔ آخر میں، ہم نے فیصلہ کیا کہ اگر صارفین کو پلگ ان کے سائز میں دشواری ہوتی ہے، تو ہم کئی مشہور زبانوں کے لیے الگ پلگ ان فراہم کریں گے۔
ہیکاتھون کے بعد
ہیکاتھون ختم ہوا، لیکن پلگ ان پر کام ایک تنگ ٹیم کے ساتھ جاری رہا۔ میں تاروں، تبصروں، اور یہاں تک کہ زبان کی تعمیرات جیسے متغیر اور کلاس کے ناموں کی حمایت کرنا چاہتا ہوں۔ فی الحال یہ صرف Java، Kotlin اور Python کے لیے تعاون یافتہ ہے، لیکن ہمیں امید ہے کہ یہ فہرست بڑھے گی۔ ہم نے بہت سے چھوٹے کیڑے ٹھیک کر لیے ہیں اور آئیڈیا کے بلٹ ان سپیل چیکر کے ساتھ مزید ہم آہنگ ہو گئے ہیں۔ اس کے علاوہ، XML سپورٹ اور ہجے کی جانچ پڑتال ظاہر ہوئی ہے۔ یہ سب کچھ دوسرے ورژن میں پایا جا سکتا ہے، جسے ہم نے حال ہی میں شائع کیا ہے۔
اس کے بعد کیا ہے؟
ایسا پلگ ان نہ صرف ڈویلپرز کے لیے، بلکہ تکنیکی مصنفین کے لیے بھی کارآمد ہو سکتا ہے (اکثر کام کرتے ہیں، مثال کے طور پر، IDE میں XML کے ساتھ)۔ ہر روز انہیں فطری زبان کے ساتھ کام کرنا پڑتا ہے، ممکنہ غلطیوں کے بارے میں ایڈیٹر کی تجاویز کی صورت میں اسسٹنٹ کے بغیر۔ ہمارا پلگ ان ایسے اشارے فراہم کرتا ہے اور اسے اعلیٰ درجے کی درستگی کے ساتھ کرتا ہے۔
ہم پلگ ان کو تیار کرنے کا ارادہ رکھتے ہیں، دونوں نئی زبانیں شامل کرکے اور متن کی جانچ کو منظم کرنے کے لیے ایک عمومی نقطہ نظر کو تلاش کرکے۔ ہمارے فوری منصوبوں میں اسٹائلسٹک پروفائلز کا نفاذ شامل ہے (قواعد کے سیٹ جو ٹیکسٹ کے لیے اسٹائل گائیڈ کی وضاحت کرتے ہیں، مثال کے طور پر، "مثلاً نہ لکھیں، لیکن مکمل فارم لکھیں")، لغت کو بڑھانا اور صارف کے انٹرفیس کو بہتر بنانا (خاص طور پر، ہم صارف کو نہ صرف ایک لفظ کو نظر انداز کرنے کا موقع دینا چاہتے ہیں، بلکہ اسے لغت میں شامل کرنے کا موقع دینا چاہتے ہیں، تقریر کے حصے کی نشاندہی کرتے ہوئے)۔
ماخذ: www.habr.com