Hackathon DevDays'19 (بخش 2): تجزیه کننده پیام صوتی برای بررسی تلگرام و گرامر در IntelliJ IDEA

ما همچنان در مورد پروژه های هکاتون بهاری DevDays صحبت می کنیم که دانشجویان برنامه کارشناسی ارشد در آن شرکت کردند. "توسعه نرم افزار / مهندسی نرم افزار".

به هر حال، ما می خواهیم از خوانندگان دعوت کنیم که به آن بپیوندند گروه VK از دانشجویان کارشناسی ارشد. در آن آخرین اخبار مربوط به استخدام و تحصیل را منتشر خواهیم کرد. ویدئویی از روز باز نیز در گروه موجود است. یادآوری می کنیم: جزئیات این رویداد در تاریخ 29 آوریل برگزار می شود آنلاین.

تحلیلگر پیام صوتی دسکتاپ تلگرام

نویسنده ایده
خروشف آرتیوم

به صف شدن

Khoroshev Artem – مدیر پروژه/توسعه دهنده/QA
Eliseev Anton - تحلیلگر تجاری / متخصص بازاریابی
ماریا کوکلینا – طراح/توسعه‌دهنده رابط کاربری
باخوالوف پاول – طراح UI/توسعه دهنده/QA

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

هدف پروژه ما در DevDays اضافه کردن قابلیت ترجمه پیام های صوتی دریافتی به متن به سرویس گیرنده دسکتاپ تلگرام (که از این پس به عنوان دسکتاپ تلگرام نامیده می شود) بود.

همه آنالوگ‌ها در حال حاضر ربات‌هایی هستند که می‌توانید به آنها پیام صوتی ارسال کنید و در پاسخ یک متن دریافت کنید. ما از این خیلی راضی نیستیم: ارسال پیام به یک ربات خیلی راحت نیست؛ ما دوست داریم عملکرد بومی داشته باشیم. علاوه بر این، هر ربات یک شخص ثالث است که به عنوان یک واسطه بین API تشخیص گفتار و کاربر عمل می کند و این حداقل ناامن است.

همانطور که قبلا ذکر شد، تلگرام دسکتاپ دو مزیت قابل توجه دارد: سهولت و سرعت کار. و این تصادفی نیست، زیرا به طور کامل در C ++ نوشته شده است. و از آنجایی که تصمیم گرفتیم قابلیت جدیدی را مستقیماً به مشتری اضافه کنیم، مجبور شدیم آن را در C++ توسعه دهیم.

در تیم ما 4 نفر حضور داشتند. در ابتدا دو نفر در حال جستجوی یک کتابخانه مناسب برای تشخیص گفتار بودند، یک نفر در حال مطالعه سورس کد تلگرام دسکتاپ و دیگری در حال پیاده سازی پروژه ساخت بود. Telegram Desktop. بعداً همه مشغول رفع UI و اشکال زدایی شدند.

به نظر می رسید که اجرای عملکرد مورد نظر دشوار نخواهد بود، اما، همانطور که همیشه اتفاق می افتد، مشکلاتی به وجود آمد.

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

هنگام انتخاب یک کتابخانه برای تشخیص صدا، بلافاصله مجبور شدیم همه APIهای آفلاین را کنار بگذاریم، زیرا مدل های زبان فضای زیادی را اشغال می کنند. اما ما فقط در مورد یک زبان صحبت می کنیم. مشخص شد که باید از API آنلاین استفاده کنیم. بعداً مشخص شد که خدمات تشخیص گفتار غول هایی مانند گوگل ، یاندکس و مایکروسافت به هیچ وجه رایگان نیست و ما باید به یک دوره آزمایشی بسنده کنیم. در نتیجه Google Speech-To-Text انتخاب شد زیرا به شما امکان می دهد برای استفاده از این سرویس یک رمز دریافت کنید که برای یک سال تمام طول می کشد.

دومین مشکلی که با آن مواجه شدیم مربوط به برخی از کاستی های C++ - باغ وحشی از کتابخانه های مختلف در غیاب یک مخزن متمرکز است. این اتفاق می افتد که دسکتاپ تلگرام به بسیاری از کتابخانه های خاص نسخه دیگر وابسته است. مخزن رسمی دارد دستور العمل برای مونتاژ پروژه و همچنین تعداد زیادی از مسائل باز در مورد مشکلات ساخت، به عنوان مثال زمان и два. معلوم شد تمام مشکلات مربوط به این واقعیت است که اسکریپت ساخت برای اوبونتو 14.04 نوشته شده است و برای ساخت موفقیت آمیز تلگرام تحت اوبونتو 18.04، باید تغییراتی ایجاد می شد.

مونتاژ خود دسکتاپ تلگرام زمان زیادی می برد: در یک لپ تاپ با Intel Core i5-7200U، مونتاژ کامل (flag -j 4) با همه وابستگی ها حدود سه ساعت طول می کشد. از این تعداد، حدود 30 دقیقه با پیوند دادن خود کلاینت صرف می شود (بعدها مشخص شد که در پیکربندی Debug، پیوند حدود 10 دقیقه طول می کشد) و با این حال، مرحله پیوند باید هر بار پس از ایجاد تغییرات تکرار شود.

علیرغم مشکلات، موفق به پیاده سازی ایده مطرح شده و همچنین به روز رسانی شدیم ساخت اسکریپت برای اوبونتو 18.04. نمایشی از کار را می توان در این آدرس مشاهده کرد پیوند. ما همچنین چندین انیمیشن را گنجانده ایم. دکمه ای در کنار همه پیام های صوتی ظاهر شده است که به شما امکان می دهد پیام را به متن ترجمه کنید. با کلیک راست می توانید زبان مورد استفاده برای پخش را نیز مشخص کنید. توسط پیوند مشتری برای دانلود در دسترس است.

مخزن.

به نظر ما، معلوم شد که اثبات خوبی از مفهوم عملکرد است که برای بسیاری از کاربران راحت است. امیدواریم در نسخه های بعدی تلگرام دسکتاپ شاهد آن باشیم.

پشتیبانی از زبان طبیعی پیشرفته در IntelliJ IDEA

نویسنده ایده

تانکوف ولادیسلاو

به صف شدن

Tankov Vladislav (سرپرست تیم، کار با LanguageTool و IntelliJ IDEA)
نیکیتا سوکولوف (کار با LanguageTool و ایجاد رابط کاربری)
Khvorov Alexander (کار با LanguageTool و بهینه سازی عملکرد)
Sadovnikov Alexander (پشتیبانی از تجزیه زبان های نشانه گذاری و کد)

ما یک افزونه برای IntelliJ IDEA ایجاد کرده‌ایم که متون مختلف (نظرات و مستندات، خطوط تحت اللفظی در کد، متن فرمت‌شده در Markdown یا نشانه‌گذاری XML) را برای دقت دستوری، املایی و سبکی بررسی می‌کند (در انگلیسی به این کار تصحیح می‌گویند).

ایده این پروژه این بود که چک املای استاندارد IntelliJ IDEA را به مقیاس Grammarly گسترش دهیم تا نوعی Grammarly در داخل IDE ایجاد شود.

می توانید ببینید چه اتفاقی افتاده است по ссылке.

خوب، در زیر با جزئیات بیشتری در مورد قابلیت های افزونه و همچنین مشکلاتی که در طول ایجاد آن به وجود آمد صحبت خواهیم کرد.

انگیزه

محصولات زیادی برای نوشتن متن به زبان‌های طبیعی طراحی شده‌اند، اما اسناد و نظرات کد اغلب در محیط‌های توسعه نوشته می‌شوند. در عین حال، IDE ها کار بسیار خوبی برای یافتن خطاها در کد انجام می دهند، اما برای متون به زبان های طبیعی مناسب نیستند. این باعث می شود که اشتباهات در گرامر، نقطه گذاری یا سبک بدون اینکه محیط توسعه به آنها اشاره کند بسیار آسان است. بسیار مهم است که در نوشتن رابط کاربری اشتباه کنید، زیرا این امر نه تنها بر درک کد، بلکه بر خود کاربران برنامه توسعه یافته نیز تأثیر می گذارد.

یکی از محبوب ترین و توسعه یافته ترین محیط های توسعه IntelliJ IDEA و همچنین IDE های مبتنی بر پلتفرم IntelliJ است. پلتفرم IntelliJ قبلاً دارای غلط‌گیر املای داخلی است، اما حتی از شر ساده‌ترین خطاهای گرامری خلاص نمی‌شود. ما تصمیم گرفتیم یکی از سیستم های رایج تجزیه و تحلیل زبان طبیعی را در IntelliJ IDEA ادغام کنیم.

اجرا

ما وظیفه ایجاد سیستم تأیید متن خود را تعیین نکردیم، بنابراین از یک راه حل موجود استفاده کردیم. مناسب ترین گزینه معلوم شد ابزار زبان. مجوز به ما این امکان را داد که آزادانه از آن برای اهداف خود استفاده کنیم: رایگان است، به زبان جاوا نوشته شده و منبع باز است. علاوه بر این، از 25 زبان پشتیبانی می کند و بیش از پانزده سال است که در حال توسعه است. با وجود باز بودن، LanguageTool یک رقیب جدی برای راه حل های تأیید متن پولی است و این واقعیت که می تواند به صورت محلی کار کند به معنای واقعی کلمه ویژگی قاتل آن است.

کد افزونه داخل است مخازن در GitHub. کل پروژه در Kotlin با افزودن کمی جاوا برای رابط کاربری نوشته شده است. در طول هکاتون، ما موفق شدیم از Markdown، JavaDoc، HTML و Plain Text پشتیبانی کنیم. پس از هکاتون، یک به‌روزرسانی بزرگ، پشتیبانی از XML، حروف الفبای رشته‌ای در جاوا، کاتلین و پایتون و بررسی املا را اضافه کرد.

مشکلات

خیلی سریع متوجه شدیم که اگر هر بار تمام متن را برای بازرسی به LanguageTool وارد کنیم، رابط IDEA روی هر متن کم و بیش جدی ثابت می‌شود، زیرا خود بازرسی جریان UI را مسدود می‌کند. مشکل از طریق بررسی «ProgressManager.checkCancelled» حل شد - اگر IDEA معتقد باشد که زمان لغو بازرسی فرا رسیده است، این تابع یک استثنا ایجاد می کند.

این یخ زدگی ها را کاملاً از بین برد، اما استفاده از آن غیرممکن است: پردازش متن به زمان بسیار زیادی نیاز دارد. علاوه بر این، در مورد ما، اغلب قسمت بسیار کوچکی از متن تغییر می‌کند و می‌خواهیم نتایج را به نحوی کش کنیم. این دقیقاً همان کاری است که ما انجام دادیم. برای اینکه هر بار همه چیز را بررسی نکنیم، متن را به طور قطعی به قطعات تقسیم کردیم و فقط آنهایی را که تغییر کرده بودند بررسی کردیم. از آنجایی که متون می توانند بزرگ باشند و ما نمی خواستیم حافظه پنهان را بارگیری کنیم، نه خود متن ها، بلکه هش های آنها را ذخیره کردیم. این به این افزونه اجازه می‌دهد حتی روی فایل‌های حجیم هم به خوبی کار کند.

LanguageTool از بیش از 25 زبان پشتیبانی می کند، اما بعید است که یک کاربر به همه آنها نیاز داشته باشد. من می‌خواستم در صورت درخواست (اگر آن را در UI علامت بزنید) امکان دانلود کتابخانه‌ها برای یک زبان خاص را فراهم کنم. ما حتی این را اجرا کردیم، اما معلوم شد که خیلی پیچیده و غیرقابل اعتماد است. به طور خاص، ما مجبور شدیم LanguageTool را با مجموعه جدیدی از زبان‌ها با استفاده از یک کلاس‌لودر جداگانه بارگیری کنیم و سپس آن را با دقت مقداردهی اولیه کنیم. در همان زمان، تمام کتابخانه ها در یک مخزن کاربر .m2 قرار داشتند و در هر شروع باید یکپارچگی آنها را بررسی می کردیم. در پایان تصمیم گرفتیم که اگر کاربران با اندازه افزونه مشکل داشتند، افزونه جداگانه ای برای چندین زبان محبوب ارائه کنیم.

بعد از هکاتون

هکاتون به پایان رسید، اما کار بر روی این افزونه با تیم محدودتری ادامه یافت. من می‌خواستم از رشته‌ها، نظرات و حتی ساختارهای زبانی مانند نام متغیرها و کلاس‌ها پشتیبانی کنم. در حال حاضر این فقط برای جاوا، کاتلین و پایتون پشتیبانی می‌شود، اما امیدواریم این لیست رشد کند. ما بسیاری از باگ‌های کوچک را برطرف کرده‌ایم و با غلط‌گیر املای داخلی Idea سازگارتر شده‌ایم. علاوه بر این، پشتیبانی از XML و بررسی املا ظاهر شده است. همه اینها را می توان در نسخه دوم که اخیراً منتشر کرده ایم پیدا کنید.

گام بعدی چیست؟

چنین افزونه ای می تواند نه تنها برای توسعه دهندگان، بلکه برای نویسندگان فنی نیز مفید باشد (اغلب، به عنوان مثال، با XML در یک IDE کار می کنند). آنها باید هر روز با زبان طبیعی کار کنند، بدون اینکه یک دستیار در قالب نکات ویرایشگر درباره خطاهای احتمالی داشته باشند. افزونه ما چنین نکاتی را ارائه می دهد و آن را با دقت بالایی انجام می دهد.
ما قصد داریم این افزونه را هم با افزودن زبان های جدید و هم با بررسی یک رویکرد کلی برای سازماندهی بررسی متن توسعه دهیم. برنامه های فوری ما شامل اجرای نمایه های سبکی (مجموعه قوانینی است که یک راهنمای سبک را برای متن تعریف می کند، به عنوان مثال، "مثلاً ننویسید، بلکه فرم کامل را بنویسید")، گسترش فرهنگ لغت و بهبود رابط کاربری (به ویژه، ما می خواهیم به کاربر این فرصت را بدهیم که نه تنها یک کلمه را نادیده بگیرد، بلکه آن را به فرهنگ لغت اضافه کند، که بخشی از گفتار را نشان می دهد).

منبع: www.habr.com