مؤتمر 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.

Object’s Concept In OOP

Programming has the two well-known paradigms, Object-Oriented Programming, and Procedural Programming.

 

So, what Object concept being developed to, through OOP, is to be the root of everything that has a value to be stored in the memory, So as long as you are defining an object from (Class, Variable, Enum, …etc), then you are creating an “Object”.

 

Why it goes through that?

 

Root Of Everything

 

In OOP, every data or value to be stored in memory, it has to get an address and to get that address it must be defined as a root to “Object”,  which means it can be casted to Object.

 

Referencing 

 

Well, “Object” in OOP,  has nothing to do but storing an address in the memory, So if you are defining a “String”, then its root came from “Object”, Which means you have a reference for your variable in the memory 🙂   (Expected Concept).

 

How does that work with classes?

 

Classes have objects, variables, and functions inside, where all of these inner objects have addresses, which make things more complicated for the compiler, but it’s already an advantage.

 

The advantage is, when you have many operations are being done to an Object, then that object ( Will Be Stored Again But With Another Address Of The Updated Object After Operations Are Applied To ).

 

So, the object keeps dynamically scaling, getting linked to objects and unlinked to others.

 

Traversing

 

As we are able to link/unlink objects to each other through ( Referencing Concept), this will lead to the ability to traverse between the linked objects, making paths from an object ending to another, e.g. (Object.secondObject.thirdObject … etc).

This will lead to a dynamic lifetime execution, where the objects are being called, unlinked (deleted for certain time), and linked to other objects, separating the execution of different parts of the program, and execute them in certain situations.

 

Finally, the object concept is very strong in making complex systems, with multiple internal structures, and with dynamic execution behaviors.

Application Development Future

It seems that, there is no clear vision of the future of app development, that the most developers can see.

Even if we keep thinking of “WHAT NEXT”, the only thing that comes in mind is, Ok we write codes, using libraries or SDKs, combining those text/script files in order to get something executable to the end-user.

Well, That’s fine, we have been into this for decades, stuck in “OOP” text implementation concept along the way.

Now most of developers will say..

Hay, this is the best we can reach, and it’s satisfying, It’s the only way to build a real structure of a “Software Solution” of whatever problem, big or small, Is by using that concept (OOP) with its only way of implementing it, which is as “TEXT”.

 

Now here is the issue (implementation as text).

 

Writing codes is being a challenge to most of developers in terms of business, Now we can see business is being growing rapidly, and it requires to be a bit smarter(if we can say), and with continous skills improvment, to be able to place your releases in a good compatetive levels in business, which absolutely will lead to better profits earning.

So, will the computer scientists, keep the definite way of app development?.

 

I think business competition in app development, will make some companies and scentists, think of an alternative solution, which will help in the market as well as in solving varies problems.

 

So, What the alternative way will be?

 

Building apps as writing texts, is nothing but a way of “representation” the app structure in order to be understood and able to be manipulated by the compiler.

 

So, we are not destroying the concept of OOP,  we just identify the real issue (the representation).

 

We know that, the alternative way of representation (rather than texts), is by diagrams.

Diagrams, are found in software engineering as theoretical, but what if we can get compilers those can understand diagrams, with making outer packages for the involvement as dependecies.

This will help in making the brainstorming and design of the software more flexable and easily achievable.

 

 

 

About The Blog

Hi, I am Saeed AlMufadhali, i am gonna write here some “general” topics, which i think is good to put here.

I will focus on my major (Computer Science), trying to give some ideas, solutions or theories, in order to give more knowledge or contribution.

Also, may release some of app-solutions, and to make this blog as the reference to.

Finally, I hope that i can provide some helpful stuff out here,

Regards.