امروزه، با افزایش بهره گیری از فناوری روز، کلید پیشرفت جوامع در دست سازمان هایی است که بیشترین بهره را از فناوری در ارائه خدمات بهتر می برند.

مجموعه روی خط مدیا در سال ۱۳۹۴ با هدف ایجاد بسترهای اطلاع رسانی و ارتباطی بر بستراینترنت و شبکه و بر پایه جدیدترین فناوری روز دنیا تاسیس شده است. ما بیشتر تمرکز خود را بر حوزه طراحی، برنامه نویسی و پشتیبانی نرم افزارهای ارتباطی و رسانه ای بر روی تلفن های همراه و رایانک های جیبی معطوف کرده ایم.

X

کلیه حقوق برای شرکت روی خط مدیا محفوظ است.

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

 

خانواده روی خط مدیا

شایان ذکر است که متخصصان و مشاوران زبده ی دیگری نیز ما را در تمامی مراحل یاری نموده اند.

با افزایش بهره گیری از فناوری روز، کلید موفقیت جوامع امروزی در دست سازمان­ هایی است که بیشترین بهره را از فناوری در جهت ارائه­ ی خدمات بهتر می­ برند. مجموعه­ ی روی خط مدیا در سال ۱۳۹۴ با هدف ایجاد بسترهای ارتباطی و اطلاع­ رسانی تأسیس شده است که بر پایه­ ی جدیدترین فناوری روز دنیا در حوزه­ ی اینترنت و شبکه تقویت می­ گردد. تمرکز عمده­ ی این مجموعه بر روی طراحی، برنامه نویسی و پشتیبانی نرم افزارهای ارتباطی و رسانه ­ای بر روی تلفن­ های همراه و رایانک­ های جیبی می­ باشد.

چشم انداز مجموعه ی روی خط مدیا

“ایده­ های نوآورانه در تکنولوژی” شعار ماست که به خوبی بیانگر چشم ­انداز و سیاست کلیِ مجموعه­ ی روی خط مدیا در عصر حاضر می ­باشد. این چشم انداز مبین تعهد این مجموعه در قبال سه نکته­ ی کلیدی از جمله ایده­ های جدید، نوآوری و فناوری­ های روز دنیاست.

مجموعه­ ی روی خط مدیا ضمن برخورداری از توانایی­ ها و پتانسیل­ های مطلوب افق­ های روشنی را پیش روی خود متصور می­ گردد و به موازات آن چشم انداز خود را تا سال ۱۴۰۰ مطابق ذیل ترسیم می کند:

  • ایجاد فراگیرترین جامعه ­ی کسب و کار آنلاین در کشور
  • کسب رتبه­ ی برتر در میان اپلیکیشن­ های پیام ­رسان بومی در کشور
  • ایجاد بسترهای لازم برای راه ­اندازی بزرگ ­ترین مرکز آنلاین بارگذاری و ذخیره­ سازی فایل در کشور
  • دستیابی به جایگاه مطلوب در بین ایستگاه­ های رادیویی فرهنگ- محور در کشور
  • افزایش اعتبار شرکت با تکیه بر نیروی انسانی ماهر، خلاق، با انگیزه، آگاه و دارای سابقه ­ی درخشان
  • انجام پژوهش‌های دانش­ بنیان، بهبود و حفظ ارتباط با مراکز علمی– پژوهشی به ویژه دانشگاه‌ها
  • سرعت بخشیدن به انجام برنامه­ های توسعه، افزایش بهره‌وری و سودآوری کلیه­ ی فعالیت‌ها ضمن پایبندی به حفظ سلامت روابط مالی و اقتصادی

در این راستا اعضای مجموعه­ ی روی خط مدیا می ­کوشند سهمی در کسب هر چه سریع ­تر و بهتر این اهداف داشته باشند.

 

توجه ويژه به نيازهاي واقعي مشتریان و کاربران، یکی از اصول اساسی در مجموعه روی خط مدیا است ارتباط مستمر و كارآمد به همراه ارائه مشاوره هاي كاربردي از ارزش هاي حاكم بر ماست.

چنانچه مایل به دریافت خدمات و مشاوره هستید، با ما در ارتباط باشید.

تلفن

تلفن : 28319-021

نمابر : 28319999-021

تلفن های مستقیم : 88175197-88524510

۹ صبح تا ۵ بعد‌‌ازظهر (شنبه تا چهارشنبه)

آدرس

ایران – تهران
خيابان مطهري ، خيابان مير عماد ، کوچه 11هم ، پلاک 13 ، طبقه چهارم
کد پستی : 1587748118
لطفا قبل از مراجعه حضوری هماهنگی های لازم را انجام دهید

ما همیشه به دنبال آشنایی های بیشتر هستیم . اگر علاقه دارید با تیم ما بیشتر آشنا شوید و یا از محیط کاری شرکت از نزدیک دیدن کنید ، از شما استقبال خواهیم کرد.

رمزنگاری ۲۰ شهریور ۹۵

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

یک پیام ساده

فرض کنیم شما پیام بسیار ساده ی زیر را تعریف می کنید:

message Test1 {
required int32 a = 1;
}

در یک اپلیکیشن،  پیام Test1 را ایجاد کرده و طول آن را از a تا 150 قرار می دهید. سپس، پیام را در قالب یک رشته ی خروجی سریال سازی می کنید. اگر بتوانید پیام رمزگذاری شده را بررسی کنید، سه بایت مشاهده خواهید کرد:

08  96  01

به نظر بسیار کوچک و عددی است. اما معنای این اعداد چیست؟

متغیرهای پایه ی 128

برای پی بردن به فرآیند رمزگذاری پروتکل بافر، بایستی ابتدا با varints یا متغیرها آشنا شوید. متغیرها، روشی برای مرتب سازی اعداد صحیح با استفاده از یک یا چند بایت هستند. اعداد کوچک تر، تعداد بایت های کم تری دارند.

در یک متغیر، هر بایت به جز بایت آخر، مهم ترین بیتی است که در عدد باینری بالاترین ارزش را دارد (msb).  این امر نشان می دهد که بایت های بعدی نیز وارد مجموعه خواهند شد. 7 بیت پایین تر هر بایت برای ذخیره سازی دو عنصر مکمل از اعداد در گروه های 7 بیتی استفاده می شود که در آغاز کم ترین ارزش را داشتند.

برای نمونه، در زیر، عدد 1 نشان داده شده که تنها از یک بایت مفرد تشکیل شده است. بنابراین msb نمی تواند یک مجموعه باشد:

0000 0001

عدد بعدی ،300 است. این عدد کمی پیچیده تر است:

1010 1100 0000 0010

چگونه می توانید نشان دهید که این عدد 300 است؟ ابتدا باید msb را از هر بایت بیرون کشید. زیرا تنها با این روش می توان فهمید که آیا به نقطه ی انتهایی یک عدد رسیده اید یا خیر (همان طور که می بینید، عدد مورد نظر شما در اولین بایت گنجانده شده، زیرا بیش از یک بایت در هر متغیر موجود می باشد).

1010 1100 0000 0010

→ 010 1100  000 0010

شما دو گروه هفت بیتی را وارونه کردید، زیرا همان طور که به خاطر دارید، متغیرها، ابتدا اعداد دارای کم ارزش ترین بیت را ذخیره می کنند. سپس برای رسیدن به مقدار پایانی آنها را وارد می کنید:

000 0010  010 1100

→  000 0010 ++ 010 1100

→  100101100

  300= 256 + 32 + 8 + 4 →

ساختار پیام

همان طور که می دانید، یک پیام پروتکل بافر مجموعه ای از جفت مقادیر کلیدی است. نسخه ی باینری یک پیام تنها از فیلدهایی همچون name استفاده می کند و نوع فیلد (type)، تنها با رمزگشایی و یا تعریف نوع پیام آشکار می شود (یعنی proto file).

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

انواع رشته های موجود در این مبحث به صورت زیر است:

موارد کاربرد مفهوم انواع
int32, int64, uint32, uint64, sint32, sint64, bool, enum Varint 0
fixed64, sfixed64, double 64-bit 1
string, bytes, embedded messages, packed repeated fields Length-delimited 2
groups (deprecated) Start group 3
groups (deprecated) End group 4
fixed32, sfixed32, float 32-bit 5

هر مقدار کلیدی در پیام،  یک متغیر دارای ارزش است (field-number≤3 |wire-type). به بیانی دیگر، سه بیت پایانی عدد نوع رشته را ذخیره می کند.

اکنون، دوباره نگاهی به همان مثال ساده ی خود می اندازیم. حالا شما می دانید که اولین عدد در یک رشته همواره متغیری کلیدی است و در این مثال منظور ما همان 08 است یا (با بیرون کشیدن msb):

000  1000

شما بایستی سه بیت آخر را داشته باشید تا به نوع 0 برسید. پس از آن، با کنار کشیدن آنها به سمت راست، به فیلد شماره ی 1 می رسید. بنابراین اکنون شما می دانید که “تگ” همان 1 و مقدار پس از آن همان “متغیر” است. با استفاده از دانش رمزگشایی خود از بخش پیش، خواهید دید دو بایت بعدی مقدار 150 را ذخیره می کند.

96 01 = 1001 0110  0000 0001
( msb را بیرون بکشید و گروه های 7 بیتی را برگردانید )       → 000 0001  ++  001 0110
→ 10010110
→ 2 + 4 + 16 + 128 = 150

انواع مقادیر بیشتر

اعداد صحیح علامت دار

همان گونه که در بخش پیش دیدید، تمامی انواع پروتکل بافرهای نوع 0، به عنوان متغیر رمزگذاری می شوند. با این وجود، زمانی که اعداد منفی رمزگذاری می شوند، تفاوت عمده ای میان انواع int های علامت دار (sint32 و sint64) و انواع int های “استاندارد” (int32 و int64) وجود دارد. اگر از int32 و یا int64 برای اعداد منفی استفاده کنید، متغیر حاصل همواره ده بایت طولانی تر خواهد شد- و به شکلی مؤثر عدد صحیح بدون علامت و بسیار بزرگی تلقی می شود.  چنانچه یکی از انواع علامت دار را به کار ببرید، متغیر حاصل از رمزگذاری ZigZag استفاده می کند که بسیار مؤثرتر است.

رمزگذاری ZigZag اعداد صحیح علامت دار را بدون علامت نشان می دهد. بنابراین اعدادی که ارزش های مطلق کم تری دارند (مثلاً 1)، مقادیر رمزگذاری شده ی کمتری نیز خواهند داشت. در این روشِ رمزگذاری، اعداد صحیح به عقب و جلو کشیده و مثلاً 1- به صورت 1، 1 به صورت 2، 2- به صورت 3 و … رمزگذاری می شوند. همان طور که در جدول زیر می بینید:

اعداد رمزگذاری شده اعداد اصلی علامت دار
0  0
1 -1
2  1
3 -2
4294967294  2147483647
4294967295 -2147483647

به عبارت دیگر، هر مقدار n به روش زیر رمزگذاری می شود:

(n << 1) ^ (n >> 31)

برای sint های 32، و یا

(n << 1) ^ (n >> 63)

برای نسخه ی 64 بیتی

در نظر داشته باشید که بخش تغییر یافته ی دوم یعنی بخش (n >> 31)، یک تغییر مکان محاسباتی است. بنابراین نتیجه ی این تغییر مکان یا عددی است با تمام بیت های صفر  (چنانچه n مثبت باشد) و یا عددی است با تمام بیت های 1 (چنانچه n منفی باشد).

زمانی که sint32 یا sint64 تجزیه می شوند، مقدار آنها به صورت همان نسخه ی علامت دار اصلی رمزگشایی می شود.

اعداد نامتغیر

اعداد نامتغیر ساده اند؛ مانند انواع double و fixed64 که رشته ی نوع 1 دارند و به تجزیه گر اطلاع می دهد توده ای از داده های ثابت 64 بیتی در نظر داشته باشد. به همبن ترتیب، انواع float و fixed32 دارای رشته های نوع 5 بوده و نشان می دهند که دارای توده داده های 32 بیتی هستند. این مقادیر، در هر دو مورد، به ترتیب بایت های کم ارزش ذخیره می شوند.

رشته ها

رشته ای از نوع 2 (با طول مشخص) یعنی این رشته مقدار متغیری است با طول رمزگذاری شده که تعداد مشخصی از  بایت ها در داده ها پس از آن قرار می گیرند:

message Test2 {
required string b = 2;
}

 

با جای گذاری مقدار b، به اعداد زیر خواهیم رسید:

12 07 74 65 73 74 69 6e 67

بایت های قرمز همان UTF8 هستند. در اینجا، کلید Key = 0×12 ،tag=2 و type=2 می باشد. طول متغیر 7 است و اینک 7 بایت پس از آن وجود دارد- یعنی رشته ی ما.

پیام های جاسازی شده

در اینجا با ارائه ی مثالی به تعریف یک پیام جاسازی شده در Test1 می پردازیم:

message Test3 {
required Test1 c = 3;
}

و در اینجا نسخه ی رمزگذاری شده ی آن را باز هم با استفاده از Test1، فیلدی که تا 150 جای گذاری شده، ارائه می دهیم:

1a 03 08 96 01

همان طور که می بینید، سه بایت پایانی دقیقاً مشابه همان مثال اول بوده (08 96 01) و پس از عدد 3 قرار گرفته اند- یعنی با پیام های جاسازی شده دقیقاً مانند رشته ها رفتار می شود ( wire type = 2).

عناصر اختیاری و تکراری

چنانچه پیامی از نوع proto2 عناصر تکراری داشته باشد (بدون عنصر [packed=true])، پیام رمزگذاری شده، یا هیچ جفت مقادیر کلیدی ندارد و یا بیش از چند جفت مقادیر کلیدی با تگ مشابه خواهد داشت. این مقادیر تکراری نباید به طور متوالی ظاهر شوند، بلکه ممکن است با سایر فیلدها جای گذاری شوند. در proto3، فیلدهای تکراری از رمزگذاری بسته بندی شده استفاده می کنند، که به این منظور می توانید مطالب زیر را مطالعه نمایید.

برای هر فیلد غیرتکراری در proto3 یا فیلدهای اختیاری در proto2، پیام رمزگذاری شده می تواند یک جفت مقادیر کلیدی با همان عدد تگ داشته و یا فاقد آن باشد.

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

MyMessage message;
message.ParseFromString(str1 + str2);

مشابه فرمت زیر است:

MyMessage message, message2;
message.ParseFOrmString(str1);
message2.ParseFormString(str2);
message.MergeForm(message2);

این روش بسیار کاربردی است، زیرا این امکان را به شما می دهد تا حتی بدون اطلاع از نوع پیام ها، بتوانید دو پیام را با هم ادغام کنید.

فیلدهای تکراری بسته بندی شده

نسخه ی 2.1.0 فیلدهای تکراری بسته بندی شده را معرفی می کند که در proto2، همانند فیلدهای تکراری اما با گزینه ی [packed=true] مشخص می شوند. در proto3، فیلدهای تکراری به صورت پیش فرض بسته بندی می شوند. درست است این فیلدها همانند فیلدهای تکراری هستند اما به روش متفاوتی رمزگذاری می شوند. یک فیلد تکراری بسته بندی شده شامل عناصر صفر است که در پیام رمزگذاری شده، نمایان نمی شود. در غیر این صورت، همه ی عناصر فیلد به صورت یک جفت مقدار کلیدی دارای رشته ی نوع 2 (با طول مشخص) بسته بندی می شوند. هر عنصر به همان صورت معمولی رمزگذاری می گردد، با این اختلاف که هیچ تگی پیش از آن قرار نمی گیرد.

برای نمونه، فرض کنید پیامی به صورت زیر دارید:

message Test4 {
repeated int32 d = 4 [packed=true];
}

حالا ضمن داشتن مقادیر 3، 270 و 86942 برای فیلد تکراری d، می توانید یک Test4 بسازید. سپس، فرمت رمزگذاری شما بدین صورت خواهد بود:

22       // tag (field number 4, wire type 2)

06       // payload size (6 bytes)

03       // first element (varint 3)

8E 02     // second element (varint 270)

9E A7 05 // third element (varint 86942)

تنها فیلدهای تکراری از نوع ارقام ابتدایی (فیلدهایی از نوع 32 بیت و 64 بیت) را می توان به صورت بسته بندی شده در نظر گرفت.

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

تجزیه گرهای پروتکل بافر باید قادر به تجزیه ی آن دسته از فیلدهای تکراری باشند که به صورت بسته بندی شده وارد می شوند، به گونه ای که گویی بسته بندی نشده اند، و برعکس. این امر منجر به افزودن [packed=true] به فیلدهای موجود به روش عقب و جلو خواهد شد.

ترتیب فیلد

با وجود این که می توان از فیلدهای یک proto با هر ترتیبی استفاده کرد، زمانی که پیامی سریال سازی می شود، فیلدهای شناخته شده ی آن بایستی با توجه به شماره ی فیلدها مرتب شوند؛ مثلاً در سریال سازی برنامه ی C++ ، Java و Python. بنابراین، با تکیه بر شماره ی فیلد که پی در پی قرار گرفته است، امکان کاربرد بهینه را برای کد تجزیه شده  فراهم می سازد. با این وجود، تجزیه گرهای پروتکل بافر باید قادر به تجزیه ی فیلدها با هر ترتیبی باشند زیرا تمام پیام ها با سریال سازی ساده ی یک آبجکت ایجاد نمی شوند؛ برای نمونه، گاهی اوقات ادغام دو پیام به روش مرتب کردن ساده ی آنها کاربردی تر است.

چنانچه پیامی فیلدهای ناشناخته دارد، مانند اجرای برنامه های C++ و  Java، آنها را به روش دلخواه پس از فیلدهای شناخته و مرتب شده قرار دهید. اجرای برنامه ی Python فعلی فیلدهای ناشناخته را دنبال نمی کند.


در این مقاله، فرمت رشته ای باینری را برای پیام های پروتکل بافر توصیف خواهیم کرد. برای استفاده از پروتکل بافرها در اپلیکیشن خود نیازی نیست به طور کامل از محتوای مقاله مطلع شوید، زیرا این مقاله جهت پی بردن به نحوه ی تأثیرگذاری فرمت پروتکل بافرهای مختلف بر اندازه ی پیام های رمزگذاری شده […]

پروتکل بافرها ۱۶ شهریور ۹۵

این مقاله درباره ی پروتکل بافرها- به عنوان زبانی خنثی و همچنین یک بستر نرم افزاری خنثی روشی قابل تعمیم جهت سریال سازی داده های ساخت یافته و مورد استفاده در پروتکل های ارتباطی، ذخیره ی داده ها و غیره می باشند.

هدف مقاله ی حاضر توسعه دهندگان برنامه ی C++ ، Java و Python می باشد که قصد دارند از پروتکل بافرها در اپلیکیشن های خود استفاده کنند. در این بررسی اجمالی پروتکل بافرها معرفی می شوند و آنچه برای شروع به کار نیاز است، مطرح می گردد.

پروتکل بافر چیست؟

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

نحوه ی عملکرد پروتکل بافرها:

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

[message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4]

همان طور که مشاهده می کنید، فرمت این پیام بسیار ساده است؛ هر پیام دارای یک یا چند فیلد مخصوص بوده و هر فیلد شامل یک نام و یا نوعی مقدار است که می تواند به صورت عدد (اعداد صحیح یا ممیزی)، بولین، رشته، بایت خام، یا حتی (مانند مثال بالا) دارای سایر انواع پیام های پروتکل بافر باشد که به شما این امکان را می دهد تا داده های خود را به صورت سلسله مراتبی بسازید. شما می توانید فیلدهای اختیاری، ضروری و تکراری را مشخص کنید.

زمانی که پیام های خود را تعریف می کنید، کامپایلر پروتکل بافر را برای زبان اپلیکیشن خود بر روی فایل proto، و به منظور تولید کلاس های دسترسی به داده ها اجرا می کنید. این ها دسترسی های ساده برای هر فیلد (مانند () name و () set_name) و همچنین روش هایی را جهت سریال سازی یا تجزیه ی کل ساختار آن به صورت بایت های خام فراهم می کنند. بنابراین، برای نمونه، اگر زبان انتخابی شما ++C باشد، اجرای کامپایلر بر روی نمونه ی بالا، کلاسی به نام Person را ایجاد می کند. پس از این شما می توانید از این کلاس به منظور همگانی کردن، سریال سازی کردن و بازیابی پیام های پروتکل بافر Person بر روی اپلیکیشن خود استفاده کنید و رمزی مانند نمونه ی زیر بنویسید:

[Person person;
person.set_name(“John Doe”);
person.set_id(1234);
person.set_email(“jdoe@example.com”);
fstream output(“myfile”, ios::out | ios::binary);
person.SerializeToOstream(&output)];

سپس، می توانید پیام خود را به صورت زیر بخوانید:

fstream input(“myfile”, ios::in | ios::binary);[
Person person;
person.ParseFromIstream(&input);
cout << “Name: ” << person.name() << endl;
cout << “E-mail: ” << person.email() << endl

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

چرا نباید فقط از XML استفاده کرد؟

پروتکل بافرها مزایای بیشتری نسبت به XML در سریال سازی داده های دارای ساخت دارند. پروتکل بافرها در مقایسه با XML:

ساده تر هستند

سه تا ده مرتبه کوچک تر هستند

بیست تا یک صد مرتبه سریع تر هستند

ابهام کم تری دارند

و کلاس های دسترسی به داده ها را  ایجاد می کنند که برای استفاده در برنامه نویسی آسان تر هستند.

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

<person>[    <name>John Doe</name>

    <email>jdoe@example.com</email> ]</person

در حالی که پیام پروتکل بافر آن (در فرمت نوشتاری پروتکل بافر) به صورت زیر است:

# [Textual representation of a protocol buffer.# This is *not* the binary format used on the wire.
person {
name: “John Doe”
email: jdoe@example.com]

زمانی که این پیام به صورت فرمت باینری پروتکل بافر رمزگذاری می شود (فرمت نوشتاری بالا نمونه ی قابل خواندن برای انسان جهت اشکال زدایی و ویرایش است)، احتمالاً 28 بایت طولانی تر است و تجزیه ی آن حدود 100 تا 200 نانوثانیه طول می کشد. اگر فضاهای خالی را حذف کنید، XML حداقل 69 بایت است و تجزیه ی آن حدوداً 5000 تا 10000 نانوثانیه زمان می بَرد. همچنین اجرای یک پروتکل بافر بسیار ساده تر است:

[cout << “Name: ” << person.name() << endl;
cout << “E-mail: ” << person.email() << end]l;

در حالی که با استفاده از XML باید مانند زیر عمل کرد:

cout << “Name:
<< person.getElementsByTagName(“name”)->item(0)->innerText()
<< end
cout << “E-mail: “
<< person.getElementsByTagName(“email”)->item(0)->innerText()
<< endl]];

با این وجود، پروتکل بافرها نسبت به XML ها همیشه بهترین راه حل  نیستند؛ برای نمونه، پروتکل بافرها، روش مناسبی برای طراحی یک سند متن- محور و دارای نشانه گذاری (مانند HTML) نیستند، زیرا نمی توانید به راحتی ساختاری را در متن قرار دهید. به علاوه، XML برنامه ای قابل خواندن و قابل ویرایش برای انسان است، در صورتی که پروتکل بافرها حداقل در فرمت اصلی خود این چنین نیستند. همچنین XML تا حدودی خود- توصیف است. یک پروتکل بافر تنها زمانی معنی دار است که شما تعریف پیام  را داشته باشید.

به نظر می رسد این راه حلی برای من است! از کجا شروع کنم؟

این بسته بندی را دانلود کنید. این بسته شامل رمز کامل منبع برای کامپایلرهای C++ ،Java و Python، و همچنین کلاس های مورد نیاز شما برای I/O و آزمون سازی می باشد. برای نصب و راه اندازی کامپایلر خود، مطابق دستورالعمل های آمده در README عمل کنید.

زمانی که همه ی موارد را تنظیم کردید، از بخش آموزش برای زبان انتخابی خود استفاده کنید؛ به این ترتیب شما در مسیر ایجاد اپلیکیشنی ساده قدم خواهید گذاشت که از پروتکل بافرها استفاده می کند.

معرفی Proto3

نسخه ی 3 جدیدترین نسخه ی منتشر شده ی ما می باشد که نسخه ی یک زبان جدید را معرفی می کند؛ و نام آن Protocol Buffers language version 3 (aka proto3) است. این نسخه شامل ویژگی های جدیدی در مقایسه با نسخه ی دوم (یعنی aka proto2) می باشد. Proto3، زبان پروتکل بافر را ساده تر می کند، تا هم استفاده ی آسان تری داشته باشد و هم در دسترس طیف گسترده ای از زبان های برنامه نویسی باشد. نسخه ی کنونی، این امکان را به شما می دهد که رمز پروتکل بافر را در برنامه های Java ،C++،Python ،C# ،Objective-C ،JavaScript ،Ruby و Java Lite ایجاد کنید. به علاوه، می توانید رمز proto3 را برای Go ایجاد کنید که از آخرین Go protoc plugin استفاده می کند و از بخش gollang/protobuf Github در دسترس قرار می گیرد. زبان های بیشتر در کانال اطلاعات وجود دارند.

اکنون، توصیه می شود تنها در موارد زیر از نسخه ی proto3 استفاده کنید:

– چنانچه قصد دارید از پروتکل بافرها در یکی از زبان های جدید برنامه نویسی مورد تأیید ما استفاده کنید.

– اگر مایل هستید برنامه ی RPC ما را اجرا کنید، توصیه می کنیم از نسخه ی proto3 برای تمام سرورها و کلاینت های جدید gRPC استفاده نمایید، زیرا این نسخه مانع ایجاد اختلال های همسان سازی می شود.

– توجه داشته باشید که دو نسخه ی زبانی API به طور کامل همسان نیستند. به منظور جلوگیری از بروز هر گونه اشکال برای کاربران، همچنان نسخه ی قبلی زبان را در پروتکل بافرهای تازه منتشر شده تأیید می کنیم.

 

مستندات کامل proto3 به زودی منتشر خواهد شد.

(چنانچه نام دو نسخه ی proto2 و proto3 کمی گمراه کننده است، به این دلیل است که وقتی ابتدا از نسخه ی proto2 رونمایی کردیم، این نسخه در گوگل با عنوان proto2 موجود بود. به همین دلیل است که نسخه ی منبع نیز به صورت v2.0.0 است.)

تاریخچه ی مختصری از پروتکل بافرها:

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

[if (version == 3) {

else if (version > 4) {
if (version == 5) {

}

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

پروتکل بافرها برای حل بسیاری از مسائل طراحی شده بودند، از جمله:

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

– فرمت ها بیشتر به صورت خود- توصیف بودند و با بسیاری از زبان های برنامه نویسی (همچون C++ ،Java و غیره) سر و کار داشتند.

با این وجود، کاربران همچنان مجبور به یادداشت رمز تجزیه ی خود به صورت دستی بودند.

به محض ارتقای سیستم، نیاز به برخی از ویژگی ها و کاربردهای دیگر نیز نمایان شد که عبارتند از:

– ایجاد سریال سازی و غیر سریال سازی خودکار رمز مانع تجزیه با دست شد.

– علاوه بر کاربرد آن در اجرای درخواست های کوتاه مدت RPC، افراد از پروتکل بافرها به عنوان یک فرمت خود- توصیف جهت ذخیره ی دائمی داده ها استفاده کردند (برای نمونه در Bigtable).

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

پروتکل بافرها، هم اکنون، به عنوان زبان میانجی گوگل برای ایجاد داده ها در نظر گرفته می شوند؛ هنگام نوشتن، 48,162 پیام مختلف وجود دارد که رمز آنها در گوگل به صورت 12,183 فایل proto تعریف می شوند. این ها هم در سیستم های RPC و هم برای ذخیره ی دائمی داده ها در سیستم های  مختلف ذخیره سازی به کار می روند.


این مقاله درباره ی پروتکل بافرها- به عنوان زبانی خنثی و همچنین یک بستر نرم افزاری خنثی روشی قابل تعمیم جهت سریال سازی داده های ساخت یافته و مورد استفاده در پروتکل های ارتباطی، ذخیره ی داده ها و غیره می باشند. هدف مقاله ی حاضر توسعه دهندگان برنامه ی C++ ، Java و Python می باشد که […]

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

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

در زیر به معرفی 5 اپلیکیشن استارتاپ می پردازیم که توانسته اند با پیام رسان هایشان زندگی را از چند جنبه آسان تر کنند.

XROS

اِیمی بن دیوید شرکت XROS را در سال 2015 در شهر لندن، انگلستان، با هدف معرفی یک پیام رسان به دنیای فناوری بنیان نهاد. ایمی بن دیوید، پیش از ساخت XROS، ابتدا در Aladdin Knowledge Systems – یک شرکت نرم افزاری در حوزه ی امنیت- که بعدها توسط Vector Capital تصاحب شد، تا اوایل سال 2000 فعالیت داشت. تا این که در سال 2010 در Doat Media Ltd مشغول شد، جایی که وی به همراه Rami Kasterstein و Joey Simhon شرکت Everething.me را تأسیس کرد. آنها در این شرکت، برنامه ی موبایل EverethingMe را معرفی کردند که با سیستم عامل اندروید سازگار بود. این پروژه در ماه دسامبر 2014 تعطیل شد و از آن پس اِیمی بن دیوید و همکارانش تصمیم گرفتند بر روی پروژه ی دیگری متمرکز شوند که از سال 2014 مشغول گسترش آن بودند– یعنی همان برنامه ی پیام رسان در حوزه ی بازرگانی.

اپلیکیشن های پیام رسانی همچون فیسبوک و واتس اپ به ابزاری برای ارتباط روزمره میان میلیون ها نفر تبدیل شده اند. اما در ارتباطات تجاری، نزدیک ترین مثال در اپلیکیشن های پیام رسان Slack app است که از آن تنها می توان برای ارتباط درون شرکت ها استفاده کرد. اپلیکیشن XROS اِیمی بن دیوید با امکانات عالی و در عین حال روش استفاده ی آسان به فعالیت های تجاری قوت می بخشد. این اپلیکشین هم بر روی موبایل و هم بر روی دسکتاپ قابل استفاده است و به کاربران این امکان را می دهد تا به صورت فردی و یا گروهی، بین شرکت ها با هم ارتباط برقرار کنند.

در اینجا مزایای XROS ارائه می گردد:

. دارای بستری چندگانه

. دارای ارتباطی منظم و مؤثر

. دارای امکان گفتگوی گروهی از طریق کانال ها

SportOn

جیت دتانی و جیدیپ تلاتیا شرکت SportON را در ژوئن 2014 در نیوجرسی آمریکا بنیان نهادند. انگیزه ی بنیان گذاران این استارتاپ، علاقه ی قلبی شان به ورزش بود. آنها قصد داشتند تا با ارائه ی این اپلیکیشن، تمامی ورزش دوستان این کره ی خاکی، هیجان فراز و نشیب های مسابقات ورزشی را در کنار هم تجربه کنند. بنیان گذاران این شرکت تمهیدی اندیشیدند تا بدون نیاز به جذب سرمایه گذار و از طریق مشاوره ی جانبی برای دیگر پروژه ها در بستر AppOn، شرکت خود را تأسیس کنند.

نوآوری این اپلیکیشن امکان پیام رسانی، مشاهده ی نتیجه ی مسابقات و اطلاعات مربوط به بازیکنان هر تیم، همگی تنها در یک اپلیکیشن برای ورزش دوستان است. در این برنامه، ورزش دوستان می توانند گروه هایی تحت عنوان “Crowds” ایجاد کنند و در آن به صحبت با یکدیگر بپردازند، ضمن این که نتایج مسابقات و دیگر اطلاعات به روزرسانی شده ی ورزشی در دستانشان است.

در اینجا مزایای SportOn ارائه می گردد:

. می تواند جایگزین چند برنامه باشد که اطلاعات واحدی را ارائه می دهد.

. اخبار دست اول مسابقات ورزشی را در اختیار ورزش دوستان قرار می دهد.

. از راهبردهایی یکپارچه در رسانه های اجتماعی برخوردار است.

Yik Yak

تایلر درال و بروکس هافینگتون شرکت Yik Yak را در اکتبر 2013 در آتلانتای آمریکا تأسیس کردند. این استارتاپ سعی دارد دنیا را کوچک کند و قدرت و آسایش یک پیام رسان را در اقصی نقاط جهان در اختیار کوچک ترین نهادهای اجتماعی نیز قرار دهد. در سال 2013، تایلر درال که دانشجوی سال اول دانشگاه فرمن بود، به همراه دوستش بروکس هافینگتون به ساخت یک اپلیکیشن قدرتمند منطقه ای پرداختند. سرمایه گذاری این شرکت در دو سال گذشته، 3 مرتبه و توسط 9 سرمایه گذار تغییر کرده است و در حال حاضر بیش از 10 نفر کارمند دارد.

تا به امروز، این اپلیکیشن به بیش از 1600 نفر در دانشگاه ها کمک می کند تا بتوانند صدایشان را در مناطق بومی خود به گوش یکدیگر برسانند. اپلیکیشن Yik Yak شباهت زیادی به تابلوهای اعلانات دارد. کاربران از طریق این اپلیکیشن مطالب و پست های دیگر افراد را مشاهده و با آنها ارتباط برقرار می کنند.

در اینجا مزایای Yik Yak ارائه می گردد:

. درک صحیح نیازهای ارتباطی و پیام رسانی منطقه ای

. راهبرد متفکرانه در حوزه ی تجارت با به کارگیری رسانه های اجتماعی

. رابط کاربری ممتاز (UI)

YellowMessenger

YellowMessenger یک شرکت پیام رسان است که کارآفرینانی هندی به نام های راف کومار و جایا کیشورردی در سپتامبر 2014 آن را تأسیس کردند. YellowMessenger شامل محل فروش کالا و یک اپلیکیشن گفتگوی اندروید می شود که با راهکاری قدرتمند توانسته میان خرید و فروش، و مصرف کننده پل ارتباطی برقرار کند. کاربران این برنامه می توانند با یک گفتگوی ساده رستوران مورد نظرشان را یافته و میز رزرو کنند، از فروشگاه های آنلاین و نزدیک به خود خرید کنند، تاکسی کرایه کنند و یا ده ها سفارش دیگر بدهند. هنگامی که راف کومار توانست از طریق اپلیکیشن واتس اپ آپارتمانی را از یک مالک بخرد، ایده ی این اپلیکیشن در ذهنش به وجود آمد.

مدل نهایی این پیام رسان بر اساس فراهم آوردن اشتراک دائمی برای کسب و کار در جهت ایجاد شبکه ی ارتباطی 24 ساعته با مشتریان موجود و مشتریان جدید است. منبع دیگر، کارمزد انجام معاملات در بستر سیستم عامل های وابسته به تجارت الکترونیک YellowMessenger از جمله Flipkart ،Myntra ،Snapdeal ،Amazon ،Jabong ،Print Venue ،Groupon و غیره می باشد. YellowMessenger به این بسترها جهت می دهد.

در اینجا مزایای YellowMessenger ارائه می گردد:

. بیش از 100 میلیون فروشگاه محلی و عنوان تجاری را پشتیبانی می کند.

. از NLP (پردازش طبیعی زبان) و AI  (هوش مصنوعی) در تشخیص قصد کاربران استفاده می کند.

Pro-a-Text

Pro-a-Text یک راهکار پیام رسان از فروشگاه Pro.com است که در تخمین و بررسی پروژه ی منازل کاربرد دارد. مت ویلیامز، دین فلکونر، گریگ میر، اریک ویلسون و گرگور پردی Pro.com را در سال 2014 در سیاتل ایالات متحده ی آمریکا تأسیس کردند. این شرکت با موفقیت توانست طی 2 دوره تأمین سرمایه توسط 10 سرمایه گذار، 17.5 میلیون دلار سرمایه جذب کند. مهم ترین ماموریت Pro.com این است که ضمن برقراری ارتباط میان مالکین و مستاجرین در ایالات متحده ی آمریکا به آنها خدمات تخمین هزینه ی پروژه های منازل را ارائه دهد. در اکتبر 2015، Pro.com خدمات پیام رسان خود را عرضه کرد تا مشتریان خدمات منازل از طریق اپلیکیشن Pro-a-Text با متخصصین این حوزه ارتباط برقرار کنند. معرفی این اپلیکیشن قدمی رو به جلو در روند فعالیت شرکت بود و مشکل یافتن خدمات تخصصی و مؤثر منازل را حل کرد تا مشتریان بتوانند در هر مرحله از انجام پروژه با آن ها ارتباط داشته باشند.

در اینجا مزایای Pro-a-Text ارائه می گردد:

  . در این اپلیکیشن نرخ های ثابت را می توان پیش از انجام پروژه مورد بحث قرار داد.

  . می توان پروژه ها را به کمک مدیر خدمات منازل در کم ترین زمان برنامه ریزی کرد.

  . این اپلیکیشن بر روی پیام رسان فیسبوک نیز وجود دارد.

سخن پایانی

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

نوشته  آرتیوم داجتیوف    http://www.businessofapps.com/5-app-startups-innovating-in-messaging/

 


یکی از پرطرفدارترین اپلیکیشن های سال ۲۰۱۵، مسنجر فیسبوک بوده است. اپلیکیشن های پیام رسان، در حال حاضر، بیشترین طرفدار را دارند. میلیون ها نفر اپلیکیشن هایی مانند واتس اپ، وایبر و اسکایپ را بر روی تلفن های همراه خود نصب و در آن ها ثبت نام می کنند. ارسال پیام متنی به یک شیوه […]

 

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

  • جذب و استفاده از نیروی انسانی کارآمد و متعهد، و اجرای برنامه­ های آموزشی
  • ایجاد ساز و کارهای انگیزشی جهت مشارکت مؤثر کارکنان در دستیابی به اهداف شرکت
  • بهبود، توسعه و به روزسانی زیرساخت­ های شرکت
  • افزایش و به روزرسانی دانش تخصصی شرکت از طریق پژوهش و توسعه (R & D)

اهدافی که در مجموعه ی روی خط مدیا درصدد تحقق بخشیدن به آنها هستیم، ارائه­ ی خدمات در زمینه ­های ذیل می­ باشد:

  • ارتباطات:

فرآیند انتقال پیام از فرستنده به گیرنده به شرط همسان بودن معنای میان آنها ارتباط نامیده می­ شود. در مجموعه­ ی روی خط مدیا مبنای تمامی پروژه­ ها ارائه­ ی خدمات در زمینه ی ارتباطات آنلاین می ­باشد.

  • هوش مصنوعی:

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

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

  • شبکه­ های اجتماعی :

شبکه ­ی اجتماعی، ساختاری اجتماعی متشکل از گره‌های فردی یا سازمانی است که توسط یک یا چند نوع خاص از وابستگی مانند ایده‌ها و تبادلات مالی، روابط دوستان و پیوندهای وب به هم متصل هستند. فراهم کردن زیرساخت ­ها و ایجاد شبکه­ های اجتماعی برای کسب محبوبیت و بالا بردن کارایی پروژه ­های شرکت یک اصل راهبردی در مجموعه­ ی روی خط مدیا محسوب می ­شود.

  • کلان­ داده:

کلان ­داده به مجموعه داده‌هایی گفته می‌شود که مدیریت، کنترل و پردازش آنها فراتر از توانایی نرم‌افزارها در یک زمان پذیرفته شده و مورد انتظار است. نـمونه‌هایی از کلان­ داده عبارتند از سامانه‌های بازشناسی با امواج رادیویی، شبکه‌های حس­گر، شبکه‌های اجتماعی، متون و اسناد اینترنتی در مقیاس بزرگ. از دیگر راهبردهای پیش ­بینی و رفع نیازهای کاربران در این مجموعه استفاده از جدیدترین سیستم­ های ذخیره ­سازی داده ­های بزرگ در پروژه­ هاست.

  • شبکه­ ی تحویل محتوا (CDN):

شبکه­ ی تحویل محتوا شبکه­ ی بزرگی متشکل از پروکسی سرورهای متعدد است که در چندین نقطه­ ی دنیا و با توجه به موقعیت جغرافیایی کاربران توزیع شده ­اند. با استفاده از CDN، محتوا از طریق نزدیک­ ترین سرور به کاربران تحویل داده می ­شود. این شبکه در افزایش سرعت تحویل محتوا و پهنای باند در وب سایت­ هایی با ترافیک بالا مانند گوگل، یاهو و فیسبوک بسیار تأثیرگذار است.

ما سعی داریم کلیه­ ی پروژه­ ها را با توجه به نیاز روزافزون دسترسی به اطلاعات محلی و پیش ­بینی­ های لازم جهت تسهیل ارتباطات کاربران خود بر پایه­ ی شبکه ­ی تحویل محتوا اجرا کنیم.

  • آمیختگی مذهب و فرهنگ، و بومی­ سازی فناوری:

استفاده ­ی مؤثر از فناوری زمانی امکان ­پذیر است که بتوانیم آن را با شرايط اقليمی، جغرافيايی و فرهنگ بومی خود سازگار نماییم. بدین معنا که فناوری را با فضای مذهبی، فرهنگی و اقليمی خود هماهنگ كنيم. ما در مجموعه­ ی روی خط مدیا سعی داریم کلیه­ ی پروژه­ ها را با توجه به فرهنگ ایرانی- اسلامی و حفظ ارزش­ های ملی- مذهبی با جدیدترین فناوری ­های عصر حاضر پیش ببریم و همواره می­ کوشیم با ایده­ هایی نوآورانه، اثری متفاوت پدید آوریم.

پیام تسلیت ۱۹ مهر ۹۵

فرارسیدن ماه محرم و ایام سوگواری شهادت امام حسین (ع) و یاران ایشان را به تمامی شیعیان جهان تسلیت عرض می نماییم. امید است به برکت ائمه ی معصومین (ع) سراسر جهان همواره عاری از ظلم، و سرشار از عدالت و آرامش باشد.

 

ششمین نمایشگاه کار دانشگاه صنعتی شریف در تاریخ 4 الی 6 مهر ماه 1395 برگزار خواهد شد. نمایشگاه کار، رویدادی است که تعداد زیادی از جویندگان کار و شرکت­ ها به منظور تبادل اطلاعات در رابطه با مشاغل مورد نیاز و معرفی شرکت­ هایشان در آن حضور می­ یابند. این نمایشگاه، به صورت فصلی و یا سالیانه برگزار می ­گردد و می ­توان از آن به عنوان نمایشگاه فرصت­ های شغلی یاد کرد؛ به نحوی که فرصت­ های فراوان کاری و کارآفرینی در اکثر زمینه­ های تحصیلی برای دانشجویان و تازه فارغ التحصیلان ارائه می­ شود. این گونه نمایشگاه­ ها فرصت مناسبی را برای شرکت­ ها و سازمان­ ها فراهم می ­آورد تا با تعداد زیادی از نیروهای جویای کار ملاقات کنند و در یک فضای رقابتی نسبت به جذب نفرات مورد نظر خویش اقدام نمایند. هدف این نمایشگاه و کارگاه ­های آموزشی، معرفی شرکت­ ها و کسب و کارهای جدید، ایده دادن به دانشجویان و تازه فارغ التحصیلان برای یافتن شغل، نحوه ­ی تعامل با صنعت و غیره می ­باشد. بازدید از نمایشگاه کار برای عموم در صورت ثبت نام در سایت نمایشگاه، رایگان است. همراه داشتن پرینت فرم ثبت نام در ایام برگزاری نمایشگاه، الزامی است.

مجموعه­ ی روی خط مدیا در کنار سایر شرکت­ های حاضر در این نمایشگاه، مفتخر است میزبان شما دانشجویان و کارجویان عزیز باشد. از شما دعوت می­ کنیم در روزهای برگزاری نمایشگاه، از غرفه­ ی شماره­ ی 53 دیدن فرمایید. بدون شک، سعی ما بر این است که بهترین خدمات و جامع­ ترین اطلاعات را به شما ارائه دهیم.

فهرست اسامی شرکت­ های حاضر در نمایشگاه تاکنون: http://jobfair.sharif.ir/cnf/exh

 

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

 

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