jay's old blog

this blog will be deleted soon - please visit my new blog - https://thesanguinetechtrainer.com

Project TD - Day 41 update – Core Tech For The First Batch of APIs for the API Engine


[Ongoing series of blog posts to inform potential developers, users and (hopefully investors) about this new app ecosystem I am architecting, designing, developing and deploying. More details at this page]

Earlier, I have written extensively about the design technique that I plan to follow to build the API Engine. The API Engine itself is a collection of APIs. For the last few days, I have been analysing the APIs that will make up the first batch of contribution towards the engine. I noticed that there are some essential tech components that they need to use to make it work.

Going by the design that I put in place, this is the second bubble from the API design titled as ‘Identify all Tech’.

So, here is the full list of tech’s that are identified to make this happen. The blog post image above lists it.

  • Build and Deploy an API
  • POST and GET to the API
  • PUSH and PULL from the API to the Data Service
  • Google Maps API on Android, Web and iOS
  • Facebook Login API on Android, Web and iOS 

I will of course, follow the design plan, and repo the above stuff, tutorial it. After that (these steps will take a few weeks to complete), I will finally have some serious unit testing to work upon.

As they say in the good books (mostly, there are no good books that I refer to. It simply me using them as proxy :P), exciting times lie ahead!

Follow me on twitterfacebook and instagram for more updates. Thanks

Facebook and Oculus Rift and Doing the Wall E Future



It has been over 3 years since Facebook purchased the current big name in VR, Oculus VR, who make the Oculus Rift headsets. My experience with VR has been limited to Google Cardboard, which is a decent approximation of what to expect from actual VR. Of course, I still have that Google Cardboard thing, but after the initial few hours, I never used it.

The VR makes us (the user) part of the action, to the extent that video and audio can. This is in contrast with a regular movie or TV. The fourth wall is strictly in front you, and clearly defined. With VR you are inside the four walls, and that means, you can look around and depending on the technology (and the capability of the technology used to develop the VR media, interact and perhaps even change the virtual reality world. VR will put you in the driver’s seat of a formula 1 car for instance, or make you one of the characters in a movie or allow you to roam around in a (virtual) Jurassic park with huge dinosaurs and totally insecure and untested security systems that are designed ensure that all humans will die once these beasts escape from their cages.

Now, that’s VR.

Then there is Facebook. At it’s core Facebook is essentially a place to share media (photos, videos, links and of course text) and allow others to interact with it. It plays on the essential human instinct to show the world what you are, and just may be, tell them that you are doing something they are not. Essentially, it’s an ego feeding machine that also has some peripheral uses like networking and business development and (actually) keeping in touch with people we care about.

So, why would Facebook bother having Oculus as on of its subsidiary? It is essential to understand that Facebook has always been a platform to get things done. It’s like the operating system that powers your phone or PC. It’s like a (virtual) home or house in which you live. If your Facebook account is your house (filled with memories, the joys and sorrows, the events and milestones and all things that cover), the interesting thing is that you cannot live in it. You are essentially operating from outside the fourth wall. It’s like when you go to the zoo. Sure you paid for the ticket and you are here to see the Lion but you cannot go and roam around with the Lions or pat them or take selfies with them.

I think the idea here for Facebook is to break that fourth wall and put you in the middle of your facebook account, which is by default your digital home. I am sure that VR is at least 5 years away from becoming mainstream. I wrote about the many problems with VR in an earlier blog post. Many of the problems I talked about earlier are solvable. They are mostly engineering issues (like processing power, displays, battery capacity, user comfort) which will be fixed because the march of technology does not stop for anybody. People (and the world is filled with people who are constantly coming up with innovative solutions) will always figure things out.

While talking about VR, its hard not to think of the quick growth and death of 3D. I think what killed 3D was the same thing that killed 3D 30 years ago, as well. The lack of content. Imagine you buy a food processor that makes fantastic fruit juice in like 5 seconds. Unfortunately, lets imagine a scenario where you live in a time and world where it is impossible to get fruits. You want to use your processor but there is no way to get fruits. The television companies were selling 3D television sets like they were the next greatest thing for the living room but other than promotional videos, there was literally nothing else that was available in 3D. Streaming companies never really embraced 3D in a big way. User generated content also never happened. So, every possible producer of 3D video declined to generate 3D video. There was no supply, and there was no consumption and by default, there was no demand for 3D hardware. Everything just fizzled out. It’s Economics 101.

This time though, I have a feeling that perhaps VR medium will grow. If Facebook gets it right and figures out a way to convert the trillions of GB of data it is sitting into a VR format (and ensures that users don’t have to jump through hoops to create VR content for consumption), supply is ensured. Once there is a steady supply, consumption will happen and demand for VR devices will grow. This will circle itself into the expected never ending cycle that will lead to mainstream VR adoption, lower prices, easier access and stuff like that. Obviously adult entertainment (as it has done with VHS tapes, streaming media and Blu Ray adoption) and gaming entertainment have a big role to play in this.

My job allows me to interact a lot of people (like 1000s every year) and each year I notice that the younger generation is becoming more and more digital social, less and less real life social. Obviously there are some serious negative consequences in the long term because of this, but I don’t see how this can communicated. As we consume more and more digital services, and use digital tools for everyday communication, I can see that people will embrace VR as part of their lives. Mostly because they don’t have a choice, but sometimes because they really want to.

Eventually (perhaps even in our own lifetimes) we might see some version of the life depicted in Wall E. You know people just sitting on chairs and everything being done for them, and happening from where they sit. Hopefully, at least some people will get up and get things done. Or, we might have to abandon our planet, just like in Wall E.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Project TD - App Ecosystem – Day 16 – Designing the App Engine and API Development Status Dashboard and User Account


[Ongoing series of blog posts to inform potential developers, users and (hopefully investors) about this new app ecosystem I am architecting, designing, developing and deploying. More details at this page]

I have learnt (perhaps the hard way) that a project without a deadline, is not a project at all! Sure, the deadline may get extended, and the project may die away. That’s the negativity in me speaking. Of course, the deadline could be met, and the project may actually reach something that resembles completion. 

Project TD needs to hit beta phase in less than 10 months. The official launch is less than 6 months after that. I am racing towards a deadline, and that means, I need to pick up a starting point. The requirements planning is all good and fine, but at the end of day, some programming needs to be done. The more I think about it, the more I feel that the API Engine is where it all starts. 

That brings up the question -  what is the API Engine? Everything and anything that works with some service is an API. For instance, the app ecosystem will use the Facebook provided login system on the end user side. The admin folks will use a Microsoft Identity library. I do not think I will bother with providing alternate login systems for end users. This does limit access to some extent. For instance, users who don’t have a facebook account might choose not to be part of Project TD. 

That should be okay. As I have already mentioned, this entire project will be open source non-commercial usage. So, if someone wants to include some other login system, the design is modular enough to allow another developer to latch on Google or Twitter or email registration based system. I must understand my limitations here. For the foreseeable future, this entire ecosystem will be built by me. If there is an opportunity that can be exploited and work load can be reduced. The login system, at least for the end user, I am going to limit myself to Facebook. I like Facebook. The Graph API is simple to use, works on almost any platform and it has the color blue. 

That’s the story with the login system. And the above Facebook login system is made possible because of the extensive login API’s that the Graph API (Facebook branding for their API stuff) provides.

Anyway coming back, the API Engine will be the collection of all the API calls, the entire ecosystem will make. That includes the many apps that will be used by the restaurant patrons and the owners, the admins, the ops folks and other roles that might be included as the design evolves. The API Engine is the only way the users can interact with the database, which stores the data. Now, the API engine (which is essentially server that listens and responds to calls from the users) is the store front for all the apps. On the other side, the API Engine interacts with the database, processing all the stuff that the calls are asking for. 

This allows for a breakdown of responsibilities, which is essentially, the whole point of modularity. Thanks to this, it is possible for me to design redundancy around the database. Build backups, replace when data goes corrupt (or gets hacked) and replace, hopefully on the fly. Since everything is broken up into pieces and connected with bridges. The source and destination don’t really care where the bridges actually go on the other side. All they care is that, on their side, the bridge is fine. 

This API Engine, is like an island at the very center. A huge island that has everything. Below the island (the API Engine) is the underwater volcano. Think of this as the database. Now, this huge island is surrounded by small water things like tiny islands, ships, ports and boats. All of these folks need something but they cannot talk to each other directly (that is whole point because boats die over time. We don't want the bridges to die with them, bringing the entire system down with them). They are all connected to the island, and everything goes through it. The island, on its own is nothing without the underwater volcano (the database). 

Thinking backwards, the center of this whole ecosystem would be the island and the volcano under it. Once these two are in place, the rest – boats, ships, sea gulls, ports, sharks and dolphins – will start settling around it. Everything in the system can be replaced of course. The island, volcano, the hundreds of boats, ships and sharks. Redundancy is the name of the game man!

As a consequence, I am now spending all my time designing the list of APIs that will from the first set of API calls, which together will become the API engine. As with the island-volcano thing from above, the API engine is useless without a database. So, along with the API engine, I will also have to design the data storage system. For both the database and the server that will respond to API calls, I am going with Microsoft Azure services. I have enough experience dealing with Microsoft Azure, and it has every possible thing imaginable to build and deploy pretty much every aspect of the ecosystem. There are alternatives (Amazon comes to my mind) but I simply have had better exposure to Microsoft services, and despite their higher charges, I will go with that. 

As I design (and then build the API Engine and the database), I figure that I will need an API dashboard that will keep track of the API calls currently being designed, developed, tested, deployed and available. This should become extremely useful to allow the stakeholders to keep track of what is happening, and obviously, what is not happening. 

The dashboard will be the choice of tool for the operations team whose job is to make sure that the system is working as designed. This also means, they need to be provided with the necessary information to deal with problems when they occur. Then, when the issues are fixed, the data should reflect the resolution. This also, will be routed through the API calls, and will be part of the API engine. The smart thing to do would be to separate the API Engine to multiple parts. However, if the entire system is backed up (and it is simple enough) then it makes sense to maintain just one engine, and then have backup engines ready to go when things go bad. 

The interesting thing here is that, the island and volcanos are separate. Each of them have copies of them, waiting in the pipeline if disaster should strike. If I split the engine into multiple parts, the redundancy maintenance factor will go up by that much. For now, it seems wiser to simply have one system to maintain, instead of multiple specialised systems. 

Next up, I must pick up the design tools which is where my new iPad and the pre-owned printer comes into the picture. I will talk about that in the next blog post. 

Follow me on twitter, facebook and instagram for more updates. Thanks!