আপনি প্রবেশ করেন নি। দয়া করে নিবন্ধন অথবা প্রবেশ করুন
প্রজন্ম ফোরাম » তথ্য ও যোগাযোগ প্রযুক্তি » ওপেন সোর্স ও বাংলা কম্পিউটিং » সম্মিলিত কাজের জন্য একটি প্রস্তাবনা
বহুদিন আগে থেকে একটা ভাল বাংলা ডিকশনারীর অভাববোধ করছিলাম। চিন্তা করেছিলাম একটা বাংলা ডিকশনারী বানিয়ে ফেলবো। টার্গেট হিসেবে ছিল বাংলা একাডেমীর ডিকশনারী। একা একা করা অনেক সমস্যা তাই আগানো হয় নি। এবার মনে হয় কিছু একটা হবে। আশিফ শাহো ভাইকে প্রস্তাবটা উত্থাপন করার জন্য ধন্যবাদ। যে কোন প্রয়োজনে আমি আছি 
কিছুই তো বুঝি না ডাটাবেসের যাই হোক আমার কাজ এন্ট্রি দেবার সময়, ততক্ষন অফ যাই।
সবাইকে ধন্যবাদ এত গুরুত্তের সাথে নেবার জন্য।
দেখেন তো একটা গ্রাফিক্যাল ইউজার ইন্টারফেস বানালাম...। বানাইতে সময় লাগছে বাট বানাইয়া মজা পাইছি।
এইটা জাস্ট আপনাদের দেখানো... যেকোনো অংশ যখন তখন পরিবর্তন করা যাবে। আমি আপাতত ডিকশনারীর নাম দিলাম মুক্ত বাংলা অভিধান। নামটাও পরে চেঞ্জ করা যেতে পারে। আমি আগে কখনো গ্রাফিক্যাল ইউজার ইন্টারফেস বানাইনি। তাছাড়া ডিকশনারীর ইন্টারফেস কেমন হতে পারে সেব্যাপারে আমার কোনো ধারনাই নেই। তারপরও আন্দাজ করে একখান ডিজাইন করে ফেললাম। পছন্দ হইলে ভালো, না হইলে আরো ভালো... 
বড় করে দেখতে চাইলে নিচের থাম্বনেইল-এ ক্লিকান।
লেখাটি CC by-nc-nd 3. এর অধীনে প্রকাশিত
invarbrass
২৪-১০-২০১০ ১৩:৪৪ সর্বশেষ সম্পাদনা করেছেন invarbrass (২৪-১০-২০১০ ১৪:০৮)
ইনভারব্রাস, আমি আসলে সিকুয়েলে যেতে চাচ্ছি না। এখানে বেশ কিছু জিনিস ওভার-নরমালাইজড হয়ে গেছে। প্রচুর জয়েন করা লাগবে একটা কুয়েরি করতে। প্রথম থেকেই তাই নোসিকুয়েল মডেল বানিয়েছি আমি। partsofspeech, dictionary, synonyms, antonyms টেবিলগুলোর আসলে কোন প্রয়োজনই নাই। এগুলো অহেতুক জয়েনার বাড়াবে। ডাটা নরমালাইজ করা হয় যখন স্থানের সমস্যা থাকে। আজকাল মেমরি নিয়ে কোন সমস্যা নাই। তাই ছোটখাট কয়েকটা ফিল্ডের জন্য আলাদা টেবিল বানিয়ে জয়েন করে সিপিইউ খরচ করার কোন মানে নাই। word_translations আলাদা রাখার কোন সুবিধাও আমি দেখছি না।
এখানে ডেমো সাইটটা সবাই দেখতে পারেন - http://bengdict.appspot.com/
একটু আধটু নাড়াচাড়া শুরু করুন। তবে এখনই আসল ডাটা এন্ট্রি শুরু করবেন না। পরীক্ষামূলকভাবে নাড়াচাড়া করুন। উদ্বোধনের আগে সকল ডাটা মুছে ফেলা হবে। তাছাড়া এটা ফাইনালও না। সবার মন্তব্য জানা যাক আগে। গ্রাফিক্স ডিজাইন নিয়ে এখনই মাথা ঘামানোর সময় হয়নি। সেটা পরে আসবে।
দ্বিমত পোষণ করছি। SQL একটা DSL (domain specific language) মাত্র, আর কিছু না। আপনি সম্ভবত: RDBMS বনাম OODB-র ব্যাপারে বলতে চাইছেন। BigTable অবজেক্ট ডেটাবযে কিনা জানিনা, তবে নি:সন্দেহে নন-রিলেশনাল।
আপনি যদি কেবলমাত্র একটি জায়গায় (bengdict.appspot.com) ডিক্সনারীটি হোস্ট করতে চান তাহলে ঠিক আছে। কিন্তু ওয়াইড ডিপ্লয়মেন্টের কথা মাথায় রাখলে অবশ্যই রিলেশনাল ডেটাবেযে যেতে হবে - এবং ৯৯% ক্ষেত্রেই তা হলো mysql (আজকাল sqlite এবং pgsql-ও থাকে বেশিরভাগ ওয়েবহোস্টেই)
পেশাগত কারণে কিছুদিন ধরে InterSystems Caché নামে একটি অবজেক্ট ডেটাবেয নিয়ে ঘাঁটাঘাঁটি করছি। আগেও OODB নিয়ে হালকা নাড়াচাড়া করেছিলাম (db4o, Perst), তবে এখন ক্যাশে নিয়ে বেশ সিরিয়াসলী লেগে আছি। অবজেক্ট ডেটাবেযে কাজ করা বেশ সহজ, মজাও পাচ্ছি। তবে একটা ব্যাপার খেয়াল করেছি - অবজেক্ট ডেটাবেয সিস্টেমে এন্টিটি মডেলিং করা যত সোজা, রিলেশনাল সিস্টেম সেই কাজটি করা ততটাই ঝামেলার।
মশা তাড়ানোর অনেক পদ্ধতি আছে - এ্যারোসল দিয়েও তাড়ানো যায়, আবার কয়েল জ্বালিয়েও করা যায়। এ্যারোসল ব্যবহার করতে চাইলে আমাকে বোতাম চাপতে হবে, আগুন ধরালে হবে না। আবার কয়েলে আগুন ধরাতে হবে, টিপতে গিয়ে ভেংগে ফেললে হবে না।
তেমনি, বিজনেস প্রসেস একই হলেও - রিলেশনাল ডেটাবেয এবং অবজেক্ট ডেটাবেযের ডিজাইনের মধ্যে ভিন্নতা থাকবেই।
পাইথনে যখন ক্লাস লাইব্রেরী লিখি, সেটি আসলে লজিকাল এন্টিটি। আর একই কাজ ম্যানুয়ালী SQL দিয়ে যখন করি - সেটি হলো ফিজিকাল মডেল। আর SQL যেহেতু closer to the metal, স্বাভাবিকভাবেই জটিল এবং বিদঘুটে হবেই। 
রিলেশনাল ডিজাইনটা একটু কম্পলিকেটেড লাগছে কারণ এই মডেলটা প্রচুর extensibility এবং flexibility দিচ্ছে। যদি শুধুমাত্র ইংরেজী-বাংলার জন্য ডিজাইন করতাম তাহলে ১ টা টেবিল দিয়েই হয়ে যেত।
মডেলটা থার্ড নর্মালাইযড ফর্মে আছে। অপ্টিমাইজেশনের জন্য কিছুটা ডিনরমালাইয করা যেতে পারে। আর এমনিতেও ওটা একটা প্রোটোটাইপ, ফাইনাল ভার্সনে (যদি হয় আরকি) প্রায় পুরোটাই বদলে যাবে। তবে এই ব্যাপারে একমত: এটা যদি অবজেক্ট ডেটাবেয সিস্টেমে মডেল করতাম, তাহলে খুবই সহজভাবে করা যেত, সর্বোচ্চ ২-৩টি এন্টিটি/অবজেক্ট দিয়েই হয়ে যেত (স্বপ্নচারী ভাইয়ের বিগটেবল-বেইজড মডেলটার মতই হতো)। কিন্তু এখানে হাত পা বাঁধা - রিলেশনাল মডেলটাই এরকম
অনুপদার পোস্ট থেকে বুঝতে পারছি ডিজাইনটি একটু ব্যাখ্যা করার প্রয়োজন আছে।
ডেটাবেযটি এভাবে নরমালাইয করার কারণ আছে বেশ কয়েকটি। আগের পোস্টেই বলেছি, আমার টার্গেট ছিলো scalability এবং extensibility।
আমরা সবাই শুধু ইংরেজী - বাংলা নিয়ে চিন্তা করছি। কিন্তু দুনিয়ায় আরো তো ভাষা আছে। আমাদের দেশেই তো প্রচলিত আছে আরবী, উর্দু, হিন্দী ইত্যাদি, এদের সাথে আদিবাষী ভাষাও (যেমন চাকমা, সাওতাঁল) যোগ করুন। এছাড়া লক্ষ লক্ষ বাংলাভাষী বিদেশে থাকে; তাদের জন্য ফ্রেন্চ, স্প্যানিশ, জাপানী, চীনা, কোরিয়ান, মালয়, তাগালগ ইত্যাদি ভাষাও গুরুত্বপূর্ণ। এরা কি দোষ করলো?
ডায়াগ্রামটি আবার দিচ্ছি এখানে:
এই (রিলেশনাল) মডেলটিতে যেকোনো ধরণের ভাষা যোগ করার সিস্টেম আছে। dictionary টেবিলটি খেয়াল করুন - এটাতে ইংরেজী=>বাংলা, বাংলা=>ইংরেজী, আরবী=>বাংলা=>আরবী, হিন্দী=>বাংলা=>হিন্দী এরকম অসংখ্য ভাষার ডিক্সনারী যোগ করার সুযোগ আছে।
এবার words_main টেবলটি দেখুন -
`dict_id` INTEGER NOT NULL,
`original_word` VARCHAR(40) NOT NULL,এখানে খেয়াল করুন, original_word ফিল্ডে আমরা যেকোনো ভাষার শব্দ এন্টৃ করতে পারবো - হোক সেটি বাংলা, বা ইংরেজী, আরবী, ফ্রেন্চ কিংবা এমনকি বামবারা (আফ্রিকান একটি ভাষা ) শব্দ - the language doesn't matter। আমরা যাস্ট সঠিক dict_id ফিল্ডে উপযুক্ত ডিক্সনারীর আইডি নাম্বারটি দিয়ে দেবো। যেমন ধরি, বাংলা=>ইংরেজী ডিক্সনারীর আইডি নাম্বার হলো ১০১, আবার ফ্রেন্চ=>বাংলা ডিক্সনারীর আইডি হলো ৫০৫। তাহলে নীচের টেবিল থেকে নিশ্চয়ই বোঝা কঠিন হবে না কোন শব্দটা কোন ভাষায়:
dict_id original_word
------- -------------
101 car
505 voitureইনফ্যাক্ট, এই টেবিল দু'টো যদি SQL JOIN করি তাহলে আরো সহজ হয়ে যাচ্ছে:
dictionary original_word
---------- -------------
en-bn car
fr-bn voitureword_translations, word_usages, word_synonyms, word_antonyms এইসব টেবিলগুলোও একই রকম language agnostic।
একটা লাইভ উদাহরণ দেই:
bengdict.appspot.com-এ book শব্দের অর্থ দেয়া আছে এরকম:
Book
* [None] (Noun (বিশেষ্য)) বই
None
Synonyms:
Antonyms:
Commentsএটা একটা পৃলিমিনারী ডেমো অবশ্যই, তবুও একটি গুরুতর লিমিটেশন দেখা যাচ্ছে। এই মডেলে আমরা ধরেই নিচ্ছি Book শব্দটির একটিই মাত্র অর্থ আছে এবং অন্য কোনো অর্থ নেই।
obhidhan.org-এ এই স্ক্যানটি পেলাম:
দু'টোর মধ্যে পার্থক্য খেয়াল করুন (ডেটা ভলিউমের কথা বলছি না, মডেল/আরকিটেকচারের দিকে নির্দেশ করছি)। এই ধরণের ডিক্সনারী বানাতে গেলে আপনাকে অবশ্যই মডেল আপগ্রেড করতে হবে।
অবজেক্ট ডেটাবেযে করতে চাইলে হয়তো এরকম হতে পারে:
class Word(db.Model):
....
translated = db.ListProperty(unicode)
....একই কাজ রিলেশনাল ডেটাবেযে করতে চাইলে foreign key, SQL JOIN ইত্যাদি ব্যবহার করতে হবে। সাইটটা django with RDBMS backend (pgsql, mysql) করলেও তো মোটামুটি এই ভাবেই করতে হবে।
দু'টোর মধ্যে যেকোনো একটা পছন্দের কথা যদি বলেন, ৯৯% মানুষের মত আমিও নি:সন্দেহে অবজেক্ট ডেটাবেযই পছন্দ করবো। শুধু যে সিস্টেমটা বুঝতে বা ডেভেলপ করতে সহজ তাই না, OODB-র পার্ফর্ম্যান্সও অনেক ভালো।
তবে এখানে ডীলব্রেকার হলো: রিলেশনাল ডেটাবেয টেকনোলজী যত সহজলভ্য, অবজেক্ট ডেটাবেয ততই বিরল। (একই ক্রাইটেরিয়া মোংগো, টোকিও ক্যাবিনেট বা ক্যাসান্ড্রার মত নোসিকল ডেটাস্টোরের ক্ষেত্রেও খাটে)
ডিক্সনারীর মত ওপেনসোর্স কমিউনিটি প্রযেক্ট ডিসেন্ট্রালাইযড থাকা উচিৎ। আগামীকাল যদি GAE কমার্শিয়াল সার্ভিস করে দেয় (বা গুগলে মারা যায় ) তখন বিপদে পড়তে হবে। তবে রিলেশনাল সিস্টেমে থাকলে (mysql, sqlite) যেকোনো জায়গায় সহজে পোর্ট করা যায়।
অনেক উচ্চ পর্যায়ের কথা হচ্ছে, পুরাপুরি বুঝতেছি না। তাও একটু প্যাচাল পারি,
ইনভারব্রাস ভাইয়ের ডিবিটা ব্যাপক ফ্লেক্সিবল, এরকম ফ্লেক্সিবিলিটির দরকার আছে, তবে কমপ্লেক্সিটি কমানোর জন্য কিছু কিছু জিনিস রিমুভ করা যেতে পারে।
স্বপ্নচারী ভাইয়ের জিনিসটা কিছুই বুঝি নাই। পাইথনে আমি print ("hellow") ছাড়া আর কিছু পারি না। কাজেই ডিবি কিভাবে থাকতেছে কিছু বুঝতেছি না।
তবে ডাটাবেজটা একটা পরিচিত ফরেমেটে থাকা প্রয়োজন , যেমন SQL .
ল্যাংগুয়েজের ক্ষেত্রেও পাইথন অনেকেই জানে না, তবে সেটা সমস্যা হবে না কারন যে যার ইচ্ছামত তার ল্যাংগুয়েজে সফট বানাতে পারবে ডাটাবেজটা SQL হলে।
অ্যাপস্পটের ফিচার বা প্লাটফরম যদি ডিবি ডিজাইনের ওপর প্রভাব ফেলে তাহলে আমার তো মনে হয় অ্যাপস্পটের দরকার নাই।
একটা ডিকশনারির ডাটাবেজ তো মনে হয় না বিশাল বড় কিছু হবে যা আমরা হ্যান্ডেল করতে পারব না।
প্রয়োজনে প্রজন্ম বা রংমহলের সার্ভারেও হোস্টিং করা যায়।
শব্দ ইনপুট,
ইংরেজি টু বাংলা করলে ভালো হবে।
ভাগ ভাগ করে দেওয়া যেতে পারে, যেমন অমুক ভাই A করবে, আরেক ভাই B করবে ইত্যাদি ..............
লেখাটি CC by-nc-sa 3.0 এর অধীনে প্রকাশিত
েডটাবেস এক্সটেনসিবল, ক্সেলেবল ও কস্ট ইফেক্টিভ হলেই তো হল। কিভাবে ডেটাবেজ কাজ করছে তা আমাদের জানার কি দরকার। সবাই এপিআই দিয়ে ইন্ট্যারাক্ট করবে। ব্যাকএন্ড জানার তো দরকার দেখি না।
বুঝতে পারছি যে এই প্রজেক্টটা মেইনটেনেন্সটা একটু ঝামেলারই হবে হয়তো! কতদিন সবার আগ্রহ থাকে সেটাও একটা বড় চ্যালেঞ্জ। 
invarbrass
২৪-১০-২০১০ ১৪:২৬ সর্বশেষ সম্পাদনা করেছেন invarbrass (২৪-১০-২০১০ ১৫:০৪)অনেক উচ্চ পর্যায়ের কথা হচ্ছে, পুরাপুরি বুঝতেছি না। তাও একটু প্যাচাল পারি,
ইনভারব্রাস ভাইয়ের ডিবিটা ব্যাপক ফ্লেক্সিবল, এরকম ফ্লেক্সিবিলিটির দরকার আছে, তবে কমপ্লেক্সিটি কমানোর জন্য কিছু কিছু জিনিস রিমুভ করা যেতে পারে।স্বপ্নচারী ভাইয়ের জিনিসটা কিছুই বুঝি নাই। পাইথনে আমি print ("hellow") ছাড়া আর কিছু পারি না। কাজেই ডিবি কিভাবে থাকতেছে কিছু বুঝতেছি না।
তবে ডাটাবেজটা একটা পরিচিত ফরেমেটে থাকা প্রয়োজন , যেমন SQL .
ল্যাংগুয়েজের ক্ষেত্রেও পাইথন অনেকেই জানে না, তবে সেটা সমস্যা হবে না কারন যে যার ইচ্ছামত তার ল্যাংগুয়েজে সফট বানাতে পারবে ডাটাবেজটা SQL হলে।অ্যাপস্পটের ফিচার বা প্লাটফরম যদি ডিবি ডিজাইনের ওপর প্রভাব ফেলে তাহলে আমার তো মনে হয় অ্যাপস্পটের দরকার নাই।
একটা ডিকশনারির ডাটাবেজ তো মনে হয় না বিশাল বড় কিছু হবে যা আমরা হ্যান্ডেল করতে পারব না।
প্রয়োজনে প্রজন্ম বা রংমহলের সার্ভারেও হোস্টিং করা যায়।
synonyms এবং antonyms টেবিল দু'টো ফেলে দেয়া যেতে পারে - এগুলো সচরাচর ব্যবহৃত হয় না। (তবে কিছু লিখতে টিখতে গেলে তখন কাজে লাগে - ঐ ক্ষেত্রে প্রপার ডিক্সনারী ব্যবহার করাই শ্রেয়) এটা আসলে স্বপ্নচারী ভাইয়ের ডেটাবেযটারই রিলেশনাল ভার্সন (প্লাস কিছু এক্সট্রা ফীচার) - SQL-এর কারণেই একটু কঠিন এবং ঝামেলার মনে হচ্ছে। দুটোর মূল কন্সেপ্ট প্রায় একই।
ডেটাবেস এক্সটেনসিবল, ক্সেলেবল ও কস্ট ইফেক্টিভ হলেই তো হল। কিভাবে ডেটাবেজ কাজ করছে তা আমাদের জানার কি দরকার। সবাই এপিআই দিয়ে ইন্ট্যারাক্ট করবে। ব্যাকএন্ড জানার তো দরকার দেখি না।
এটা অত্যন্ত ভ্যালিড পয়েন্ট। তবে আমার মনে হচ্ছে এই প্রযেক্টটা সম্ভবত: ডিসেন্ট্রালাইযড ধরণের হবে (ওপেনসোর্স, কমিউনিটি প্রোযেক্টগুলো সাধারণত: এরকমই হয়ে থাকে)। স্বপ্নচারী ভাইয়ের ভার্সনটা এ্যাপস্পটে আছে, একটা ভার্সন হয়তো প্রজন্মে আপনি হোস্ট করলেন, আবার সারিম, অনুপ এ্যান্ড কোং হয়তো রংমহলেও আরেকটা ভার্সন হোস্ট করলেন। এরকম হেটেরোজেনাস ডিপ্লয়মেন্টের ক্ষেত্রে আল্টিমেটলী আপনাকে lowest common denominator খুঁজে বের করতে হবে - কোন টেকনোলজী সবচাইতে বেশি জায়গায় পাবেন? এ্যাপস্পটে মাইসিকল বা অন্য কোনো রিলেশনাল ডেটাবেয পাবেন না। আবার এ্যাপ এন্জিন ছাড়া দুনিয়ার আর কোথাও গুগলের বিগটেবল ডেটাবেয পাবেন না - এটা অত্যন্ত ক্লোজড এবং প্রোপ্রিয়েটরী টেকনোলজী। ইনফ্যাক্ট বিগটেবল যে আসলে কি জিনিস সেটাই কেউ জানে না - জিমেইল, গুগল সার্চ, ম্যাপস, ইউটিউব, অর্কুটের মত বিরাট বিরাট সার্ভিস বিগটেবলের উপর চললেও পুরো সিস্টেমটাই কোকাকোলার রেসিপির মত একদম কঠোর গোপনীয়তার মধ্যে রেখেছে গুগল! 
ডিপ্লয়মেন্টের সুবিধার কথা বলেছিলাম। আরেকটা ব্যাপার বলতে ভুলে গেছি, এখানে যোগ করি - পোর্টেবিলিটি: রিলেশনাল ডেটাবেযটা মাইসিকল বা যেকোনো সিস্টেমেই থাকুক না কেন, অন্য যেকোনো ডেটাবেয সিস্টেমে খুব সহজেই কনভার্ট করা যাবে।
যেমন, ধরুন আমার ইন্টারনেট নাই, আমি ডেস্কটপে একটি অফলাইন/লোকাল ডেটাবেইজের মাধ্যমে ডিক্সনারীটি ব্যবহার করতে চাই।
রিলেশনাল ডেটাবেযের ক্ষেত্রে খুব সহজেই mysql থেকে sqlite বা (embedded) firebird-এ এক্সপোর্ট করা যাবে। কিন্তু মূল ডেটাবেযটি যদি অবজেক্ট বা NoSQL সিস্টেম হয়, তাহলে রিলেশনাল মডেলে কনভার্ট করতে বেশ ঝামেলা হবে!
এটা শুধুই একটা উদাহরণ। RDBMS এবং OODB দু'টোই ম্যাচিউর টেকনোলজী। তবে আমার মতে, অনেক বেশি ঝামেলার, ডিজাইন এবং ডেভেলপ করা কঠিন, প্রচুর প্রসেসিং পাওয়ার লাগে এবং তুলনামূলকভাবে পার্ফর্ম্যান্স স্লো হলেও RDBMS-কে পছন্দ করলেই মনে হয় অধিকতর pragmatic (এই শব্দের বাংলা কি জানিনা, ডিক্সনারীটা আমার নিজেরই সবচাইতে বেশি দরকার ) সিদ্ধান্ত হবে।
(তবে আমি ব্যক্তিগতভাবে অবজেক্ট ডেটাবেযের ফ্যান 
)
আপডেট: কোডার ভাইয়ের পোস্টে আরেকটা ব্যাপার মাথায় আসলো। একটি সেন্ট্রালাইযড ডেটাবেয/ওয়েবসাইট থাকা দরকার - মূল ডেটাবেজটি এখানেই হোস্ট হবে। কন্ট্রিবিউটররা এই সাইটে ডেটা এন্টৃ করবে। ডেটাবেযটি ওপেন থাকবে - নিয়মিত CSV, SQL (বা বাইনারী ডাম্প) রিলিজ করা হবে। যার দরকার সে প্রয়োজনমত ডেটাবেইযটি ডাউনলোড করে অন্য কোথাও মিরর করতে পারবে।
এটা অত্যন্ত ভ্যালিড পয়েন্ট। তবে আমার মনে হচ্ছে এই প্রযেক্টটা সম্ভবত: ডিসেন্ট্রালাইযড ধরণের হবে (ওপেনসোর্স, কমিউনিটি প্রোযেক্টগুলো সাধারণত: এরকমই হয়ে থাকে)। স্বপ্নচারী ভাইয়ের ভার্সনটা এ্যাপস্পটে থাকবে, একটা ভার্সন হয়তো প্রজন্মে আপনি হোস্ট করলেন, সারিম, অনুপ এ্যান্ড কোং হয়তো রংমহলেও আরেকটা ভার্সন হোস্ট করলো। এরকম ক্ষেত্রে আল্টিমেটলী আপনাকে Common Denominator খুঁজে বের করতে হবে - কোন টেকনোলজী সবচাইতে বেশি জায়গায় পাবেন? এ্যাপস্পটে মাইসিকল বা অন্য কোনো রিলেশনাল ডেটাবেয পাবেন না। আবার এ্যাপ এন্জিন ছাড়া দুনিয়ার আর কোথাও গুগলের বিগটেবল ডেটাবেয পাবেন না - এটা অত্যন্ত ক্লোজড এবং প্রোপ্রিয়েটরী টেকনোলজী। ইনফ্যাক্ট বিগটেবল কিভাবে কাজ করে কেউ জানে না - জিমেইল, গুগল সার্চ, ম্যাপস, ইউটিউব, অর্কুটের মত বিরাট বিরাট সার্ভিস বিগটেবলের উপর চললেও পুরো সিস্টেমটাই একদম কড়া গোপনে রেখেছে গুগল!
ঠিক তাই। পুরো প্রজেক্ট যদি সবাই এভাবে ক্লোন করতে পারে তাহলে কমন কোন টেক ব্যবহার করাটাই সুবিধা জনক হবে। আবার যদি এরকম যে, যে কেউ শুধু ক্লায়েন্ট টা ব্যবহার করতে পারবে কিন্তু মূল ডেটাবেজ থাকবে এক জায়গায় তাহলে যারা মেইনটেন করবে তাদের সুবিধামত হলেও অসুবিধা দেখি না। কিন্তু যে টেক শুধু গুগলে আছে সেটা ব্যবহারে আমি অবশ্যই একাধিকবার চিন্তা করব। কারণ একটা নির্দিষ্ট (কিন্তু ওপেন নয়) টেক এ আমার যথেষ্ঠ খুঁতখুঁতি আছে। আবার যখন তখন তাদের এলাকা থেকে বিতাড়িত করার ভয়ও তো থাকে।
এটা অনেক ভাল উদ্যেগ যদি ভাল ভাবে এগিয়ে যেতে পারে তাহলে আমাদের অনেক উপকার হবে।
কোডার ভাইয়ের সাথে একমত হয়ে বলছি এটার আগ্রহ কত দিন থাকবে ? নাকি এটার কাজ শুরু হয়ে গেছে ?
লেখাটি CC by 3.0 এর অধীনে প্রকাশিত
বাপরে কত গিকি গিকি কথা! 
আপনি আরেকটি উদাহরণ দেখেননি আমার সাইটে। সেটি হচ্ছে ‘এক’। এখানে দুটি অর্থ দেয়া আছে। ইন্টাফেসে একবারে কেবল একটি শব্দ যোগ করা যাচ্ছে, তাই একটি শব্দার্থ দেখছেন। আপনি যদি Book-এর আরেকটি এন্ট্রি দেন। তাহলে দুটো দেখবেন।
একই শব্দের একাধিক অর্থ, পদ, আরও অনেক কিছুই থাকতে পারে। সেটা একই টেবিলে রাখলেও কোন সমস্যা নাই। অন্য টেবিলে রাখলে কোন লাভ আমি দেখি না। তবে ডিকশনারী টেবিলটা যোগ করেছি। এতে করে ডিকশনারি সম্পর্কিত মেটা-ডাটাও সেভ করা যাবে। আগের ডিজাইন কিন্তু শুধু একটা ডিকশনারির জন্য ছিল না, অনেকগুলো যোগ করা যেত।
ইনপুট সিস্টেমে ডাটাবেস কিসে আছে সেটা তো কোন সমস্যা না। সেটা SQL, noSQL যাই হোক না কেন, ক্লায়েন্ট কথা বলবে প্লেইন টেক্সট ডকুমেন্টে - এক্সএমএল, জেসন ইত্যাদিতে। কেউ যখন ডাটা নিয়ে নিজের স্বাধীন কিছু বানাতে চাইবে একবারে সব ডাউনলোড করে সেটা নিজের মত সাজিয়ে নিতে পারবে।
এ্যপইঞ্জিন কমার্শিয়াল হয়ে গেলেও কোন সমস্যা নাই। ওপেনসোর্স অল্টারনেটিভ আছে। যে কেউ সেটা নিজের সার্ভারে বসিয়ে এটা হোস্ট করতে পারবে। আসলে সফটওয়্যারটি আমাদের মূল টার্গেট নয়। আমাদের মূল টার্গেট হচ্ছে ডাটাবেস। ডাটাবেস একবার তৈরী হয়ে গেলে SQLite, MySQL, Oracle, MSSQL, Postgres ইত্যাদি যা খুশি তাতেই কনভার্ট করে নেয়া যাবে।
সারিম, ইংরেজী টু বাংলা এবং বাংলা টু ইংরেজী দুটোই এখন প্রধান লক্ষ্য। অন্য ভাষাও যোগ করা যাবে। তবে সেটা পরবর্তী প্রাধান্য।
শিমুল১৩, আপনি ওয়েবসাইটের জন্য একটা থিম বানিয়ে দেখান। ডেস্কটপ এ্যপ পরে বানানো হবে।
পড়ার সাহসই পাইলাম না।
লেখাটি CC by-nc-nd 3. এর অধীনে প্রকাশিত
আমি আছি আপনাদের সাথে। খুবই ভালো চিন্তা কিন্তু টিম গঠন কবে হবে ?আর টিমের ইনভাইট পাবো কবে ?
সাইটের কোডবেস এ্যপইঞ্জিন থেকে জ্যাঙ্গো-তে রূপান্তর করলাম। এবারে এই কোডে অনেক ধরণের ডাটাবেস সাপোর্ট পাওয়া যাবে - SQLite, MySQL, Postgres, Oracle, Appengine সরাসরি সাপোর্টেড। mongoDB, MSSQL- ও চলার কথা। ডাটাবেস ফরম্যাট নিয়ে এখন আর কোন সমস্যা নাই। যে কেউ যেকোন জায়গাতেই এটা হোস্ট করতে পারবেন - শুধু পাইথন, জ্যাঙ্গো থাকলেই হলো।
ডাটাবেস ডিজাইন নিয়ে আরও কোন আলোচনার দরকার না থাকলে সাইট ইনপুটের জন্য রেডি। অনুগ্রহ করে ডিজাইন সম্পর্কিত আরও মতামত থাকলে জানান। পয়লা নভেম্বর থেকে সাইট পুরোদমে চালু করার ইচ্ছা পোষণ করি। এডমিন ও মডারেশনের কিছু কাজ বাকি আছে।
শিমুল১৩, সাইটটি দেখে এখন ধারণা পাবেন কিভাবে গ্রাফিক্স ডিজাইন করবেন।
rubelbd, এখানে ইনভাইটেশনের কিছু নাই। লগইন করে ইনপুট দেয়া শুরু করবেন।
একটা টেস্ট ইনপুট দিলাম।
সাইট কিছুটা স্লো মনে হইল। এইটা একটু দেখবেন প্লীজ।
একটা টেস্ট ইনপুট দিলাম।
সাইট কিছুটা স্লো মনে হইল। এইটা একটু দেখবেন প্লীজ।
সাইটের ঠিকানা দিন তো দেখি।
আর কোন ডিকশনারী থেকে ইনপুট দিব কিছুই তো বুঝলাম না। আমাদের কাছে যদি একই ডিকশনারী না থাকে। ডিকশনারী একটু একটু করে স্ক্যান করে দিলে ভাল হত।
@একই ওয়ার্ড দুবার এন্ট্রি যাতে দেয়া না যায় সে ব্যাবস্থা কি আছে?
সাইটের ঠিকানা দিন তো দেখি।
আর কোন ডিকশনারী থেকে ইনপুট দিব কিছুই তো বুঝলাম না। আমাদের কাছে যদি একই ডিকশনারী না থাকে। ডিকশনারী একটু একটু করে স্ক্যান করে দিলে ভাল হত।
লিংকঃ http://bengdict.appspot.com/
@একই ওয়ার্ড দুবার এন্ট্রি যাতে দেয়া না যায় সে ব্যাবস্থা কি আছে?
এটা ডাইনামিক ডাটাবেজ। তাই এটার সম্ভাবনা নেই। আর যদি একই শব্দের দ্বিতীয় ইনপুট হয় তবে অর্থ আলাদা হলে দ্বিতীয় অর্থ হিসেবে কাউন্ট হবে।(এটা আমার মতামত।)
স্বপ্নচারী ভাই একটু ব্যাখ্যা করলে ভাল হয়।
টেকনিকাল সব দিকই গুরুরা ভালমতই সামলিয়ে নিয়েছেন। 
এখন মনে হয় ইনপুট নিয়ে আলোচনা করা উচিৎ।
এক্ষেত্রে দুটি উপায়ে কাজ করা যেতে পারে।
১ # যে কেউ লগইন করে ইনপুট দিতে পারবে।
# একই ইনপুট যেন দুবার না হয় সেজন্য নির্দিষ্ট অভিধানের পাতা স্ক্যান করে দেয়া হবে।
# মডারেটররা প্রতিটা ইনপুট যাচাই করে দেখবেন।
২ # নির্দিষ্ট সেচ্ছাসেবকদের ইনপুট দেয়ার অনুমতি দেয়া হবে।
# সবাই একটি পুর্বনির্ধারিত অভিধান থেকে ইনপুট দেবেন।
# অভিধানটি সকল সেচ্ছাসেবকদের কাছে লোকালি থাকবে।
# মডারেটরগন তাদেরকে অভিধানের বিভিন্ন পাতা প্রতি সপ্তাহে দেবেন ধারাবাহিকভাবে।
#মডারেটররা যথারীতি ইনপুট যাচাই করবেন।
২য় পদ্ধতিটা সবচেয়ে কার্যকর বলে আমার মনে হয়।
কারন ২য় পদ্ধতিতে একই শব্দ একাধিক জনের ইনপুট দেয়ার সুযোগ নেই। প্রত্যেকের জন্য সাপ্তাহিক একটা সীমা বেধে দেয়ায় কাজটি সুন্দরভাবে সমান তালে চলবে। মানে কখনও অনেক বেশী ইনপুট আবার কখনও ইনপুট এর অভাব হবে এমন
হবে না। ফলে মডারেটরদের কাজও সহজ হয়ে যাবে।
আর প্রথম পদ্ধতিটা আপাত দৃষ্টিতে সহজ মনে হলেও কাজ চলাকালীন সময় অনেক সমস্যার সৃষ্টি করবে বলে আমার মনে
হয়।
এইরকম একটা উদ্যোগ যে সফল হইতে যাইতেছে তা ভাবতেইত আমার নাচতে ইচ্ছা করতেছে। 
আমার মনে হয় কাজ নিদৃষ্ট করে দেওয়াই ভালো, কেউ তাই অভিধান স্কান করা শুরু করেন
লেখাটি CC by-nc-sa 3.0 এর অধীনে প্রকাশিত
প্রজন্ম ফোরাম » তথ্য ও যোগাযোগ প্রযুক্তি » ওপেন সোর্স ও বাংলা কম্পিউটিং » সম্মিলিত কাজের জন্য একটি প্রস্তাবনা
০.০৯১৯০৮৯৩১৭৩২১৭৮ সেকেন্ডে তৈরী হয়েছে, ৮৮.৯৩৪৬৯৮৯৩৬৯৪৮ টি কোয়েরী চলেছে
