هل الـ Gmail والـ Outlook يطلعون على رسائل المستخدمين ؟

الجواب : بإمكانهم، ولكن في الغالب بشكل آلي
أي رسالة تصل إلى أي مستخدم، يجب فحصها أولا، والتأكد منها (بريد مزعج، تصيد، يحتوي على روابط، مصدر الرسالة، وهوية المرسل)، يتم هذا الشيء بشكل آلي
بالإضافة إلى تشفير الرسائل، لمنع كشف محتواها أثناء عملية الإرسال (نقل الرسالة)
ولكن في الأخير، تبقى الرسائل مخزنة في خوادم Gmail و Outlook ، وحتى لو تم تخزينها مشفرة، فهي مشفرة عن الأطراف الأخرى، وليست مشفرة عن الموظفين/المسؤولين عن الخدمة (فئة معينة من المسؤولين)
Google اعترفت في وقت سابق، أنها لازالت تسمح لشركات خارجية بقراءة رسائل البريد الإلكتروني للمستخدمين.
التفاصيل :

مؤتمر Google I/O 2019

التاريخ : من 7 مايو إلى 10 مايو

البدأ :

Pre-Keynote : البث المباشر، 7 مايو، 7:20 م (توقيت السعودية)

Keynote : البث المباشر، 7 مايو، 8:00 م (توقيت السعودية)


رابط الموقع :

https://events.google.com/io


التطبيقات :

Android :
https://play.google.com/store/apps/details?id=com.google.samples.apps.iosched

IOS :
https://itunes.apple.com/us/app/google-i-o/id1109898820?mt=8

حزمة SDK (الرسمية) للـ Firebase على الـ #C ؟؟

مطورو الدوت_نت ( #C أو VB.NET ) يلاحظون قلة الدعم في ما يخص المكتبات والخدمات، لم يعد أحد ينظر باهتمام إلى منصة التطوير للـ Windows بشكل عام.


ولكن فيما يخص قواعد البيانات !!

نلاحظ وجود حزم SDK رسمية للـ MongoDB و شبه رسمية MySQL Connectors أيضًا RethinkDB Connectors ، تدعم الدوت_نت.


فيما يخص قواعد بيانات Firebase :-

لايوجد حزمة SDK رسمية للـ Firebase على الـ #C، في حين أنهم أكدو أن إنشاء حزمة رسمية هي على خارطة التطوير الخاصة بهم منذ 2015 تقريبًا ولم يتم نشرها إلى الآن، نظرًا إلى ليست جاهزة إلى الإعتماد عليها بشكل رسمي.


ولكن يوجد بعض مكتبات REST الخاصة بالـ Firebase للـ #C ، غير رسمية

مثل :

1 – FireSharp
2 – FirebaseSharp


المصدر : https://medium.com/step-up-labs/firebase-c-library-5c342989ad18

Mongodb Joining Sample ($Lookup)

The case is that a website, where users can post topics under a certain section, so it provides a kind of classification for the posts, helping in the grouping, searching, … etc

I did normalize this NoSQL database, by separating Posts and Sections into two collections, So when loading sections it’s simpler, they are not embedded in the “Posts” Collection, So I don’t need to load all posts and bringing “Section” attribute, by projecting other attributes, this could lead to performance issues, due to the duplication of the same”Section” value in more posts, so add that you need to [ Project Other attributes, and skip duplicated values ], So we are not going to do this.

So, we have :


Two Collections:
Posts, Sections


Purpose: 
Fetching all Posts(Objects) from “Posts” collection, according to how many Section(Text) in “Sections” collection, and then arranging them into an object of structure :

{ Section : "" Section Name "" , A: "" array of posts have the same section name in their objects "" }
db.getCollection('Sections').aggregate([
{$lookup:{from:"Posts", localField:"Section",
foreignField:"Section", as:"A"}},
{$unwind: "$A"},
{$limit:2},
{$project:{"_id":0}},
{$group:{_id: "$A._id",Section:{$first:"$A.Section"},
"A":{$push:{logo:"$A.logo",PostTitle:"$A.PostTitle",
forwardUrl:"$A.forwardUrl",Desc:"$A.Desc"}}}},
{$project:{"_id":0}}])

Explanation :

$lookup

is the keyword for joining two collections based on local and foreign keys.

$unwind

is used to separate the result came from the joining which is an “Array”, into objects, ( each array element, becomes an inner object of a duplicated parent object ) as the following :

From :{Section : "ABC", A:[ {Name:"Post1"} , {Name:"Post2"} ]
To :{Section : "ABC" , A:{Name:"Post1"}},
{Section : "ABC", A:{Name:"Post2"}}

$limit

is to limit the results of the inner array ( after it’s “unwind“ed ), as e.g.  i need two inner posts for this specific “Section”.

$project

is to remove unwanted “key:value” object from the document ( discarding the fetching of it ).

$group

is to re-collect the documents fetched from the $lookup, into a different document format, where the document structure differs from its original structure.   e.g.  down there in the sample,  you are going to notice that $group is reforming the structure of the documents, “_id” is mandatory.

Results:

[{"Section":"Sports","A":[{"logo":"logo-1550809687524.png",
"PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]},{"Section":"Sports",
"A":[{"logo":"logo-1550809687524.png","PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]},{"Section":"Games",
"A":[{"logo":"logo-1550769840632.jpeg","PostTitle":"TicTacToe",
"forwardUrl":"1t0221k8m4kk93",
"Desc":"Playing TicTacToe"}]},{"Section":"Sports",
"A":[{"logo":"logo-1550809687524.png","PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]},
{"Section":"Games",
"A":[{"logo":"logo-1550769840632.jpeg","PostTitle":"TicTacToe",
"forwardUrl":"1t0221k8m4kk93",
"Desc":"Playing TicTacToe"}]},{"Section":"Sports",
"A":[{"logo":"logo-1550809687524.png","PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]},
{"Section":"Sports",
"A":[{"logo":"logo-1550809687524.png","PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]},{"Section":"Sports",
"A":[{"logo":"logo-1550809687524.png","PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]},{"Section":"Sports",
"A":[{"logo":"logo-1550809687524.png","PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]},{"Section":"Sports",
"A":[{"logo":"logo-1550809687524.png","PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]},{"Section":"Sports",
"A":[{"logo":"logo-1550809687524.png","PostTitle":"Football",
"forwardUrl":"1t0cc2khciars8"}]}]

Additional:

Change (_id: “$A._id”) in the sample above (inside $group ) to (_id: “$_id”), the reason is that you want to make all the inner objects inside the _id which is the id of the object itself not the id of each inner object.
by saying $A._id this means to take multiple duplicated section object and assign the A._Id to each one.
you will not get an array under one _id (parent id) , but you are going to get duplicated object each one of the duplicated is assign to one index of the array, so no array ( multiple unwind inner objects to single duplicated parent object )


Note, joining in MongoDB in some cases could lead to consumption of a lot of machine resources, depending on the complexity of your case.