jay's old blog

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

Project TD - Day 19 update – Designing the Design Process

[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]

Now that the requirements planning is all done (at least to an acceptable level), it’s time to finalize the design process. The design process is crucial. I have always believed that being a developer (which include being a designer) is always better than being a programmer. I have spent considerable ink on that topic while discussing Uber and self-driving cars. That means, a good design is the only way to ensure that the idea leads to become an usable service.

That means, I need to first design the actual design process. My design for the design process would include the following four components.


Technologies To Be Used



Everything in software development is a cyclical process. The more time you spend revising stuff, the more you find flaws in it. The less flaws one finds, the more confident one becomes at its design. A solid design means less flaws during actual development (where the actual app ecosystem is coded. I always make sure that I run my design through a lot of people. God has blessed with access to individuals from varied backgrounds, and most of them are people who know the techie kind of person that I am. So, when I approach them with what I want, they don’t get weirded out or act surprised. In other words, I can collect an endless amount of feedback from folks who are tech wizards to those who technical achievement is forgetting their personal phone’s PIN LOCK.


It all starts with illustrations, drawings, doodles and anything else one might call creations. I have given myself access to a lot of drawing tools. I have got the good old fashion pen and paper. The premium notebook for scribbling. Of course, I have my iPad with a nice Amazon Basics stylus. In the future, I will probably invest in more expensive drawing tools but I must balance my ambitions with the budget for this project.

One reason to start with sketches is the universalness of visual things. My mother can understand. My students can understand it. My tech mentor can understand it. Random people I meet on the road can understand it. Anybody can understand it. Over the years, I have learnt that no feedback is less important. Sure, some feedback might be useless, but then again, the greatest products have been built by the silliest of inspirations.

I have already concluded that the app ecosystem has the API Engine at its heart. The API Engine is but a collection of APIs, and each API would have a design connected to it.

Technologies To Be Used

Once a sketch has been finalized, the next step is to start adding real technology to reflect the corresponding actions. I mentioned earlier that that each API would have a sketch attached to it. Once that is done, it would be essential to connect the different components of the sketch to the technologies that are used.

For instance, at its simplest, I would need to build an API service that would take some data, and push it to the database. For this, I would need to code the API, put it on a server, design the database and then connect the two. I would need to list out all this, and code the stuff out of it.


Me just learning how to convert the sketches into actual technology components is not enough. I must write tutorials related to it. While I am an architect, I still make a huge a chunk of money through training. I must have a collection of tutorials that will help me bolster my tutorial portfolio. Otherwise, one of the main benefits of this thing will be lost on me.


Of course, all code must be pushed into a public repository that supports tutorials. A tech tutorial without supporting code is not that cool. I will be the first to admit that I myself have written multiple tutorials that don’t link to a code on the repo. It’s a fault I am trying to fix going forward.  

Each design will go through the above steps, and hopefully there is enough for room for all possible flaws to show up. The end result of the above process will be modules, which I would like to consider as ‘ready to use module templates’ or RTUMT. The actual development process (which comes after the design is over) will utilize these RTUMTs. Hopefully, since the RTUMTs have already been vetted at the design stage and the coding stage, the actual development will put a lot of focus on integration of these modules, continuing my efforts to keep the entire design modular. This will allow me to remove and replace modules as newer and better technology should become available if the app ecosystem survives the first year of operation.

Of the five stages of the app ecosystem development, I imagine that the design stage to be the most extensive. I have vowed not to start the actual development (which will eventually lead to the beta launch) until the entire design is completed. That means, if necessary I am happy to spend an additional 6 months fine tuning the design rather than jump to development with a half-baked design.

It’s going to be a long ride man.

Genius is eternal patience - Michelangelo

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

Xiaomi makes its own SOC, so does Samsung Huawei and of course Apple

There is a truck load of money in mobile hardware and the proof is the thick, hard core battle that is still raging among the many, many makers of Android phones.

What makes mobile phones different (like how they are always ‘awake’ unlike say a PC) is what is under the hood. PCs are powered by a Motherboard to which a lot of things like Processor, slots, wireless card, Bluetooth card, sound card, power supply socket and so on are available. That is why we tend to use the word ‘assembled PC’ or ‘off the shelf PC’. That is also why PC hardware enthusiasts exist (but there are no mobile hardware enthusiasts exist, at least not amongst the tech crowd) because it is possible swap out and swap things in. This is also why PCs cannot be ‘awake’ like how phones.

So, unlike PCs, mobile phones have under the hood, what is called as ‘System On Chip’ or SOC. As the name indicates, a SOC has everything (except for RAM and hard drive) already plugged into it. In most cases, the RAM and HDD is probably sealed on to the SOC by the phone manufacturer. That would explain why you cannot just upgrade the RAM on your phone, like how you would on the PC. Thanks to a tight integration, SOCs manage to improve power efficiency and make everything work real smooth. Less nuts and bolts equals less replicability but also more efficiency. Thank god for SOCs because I cannot imagine mobile phones being awesome as they are now without them.

While all this is good, there is a small problem. At least for the phone makers. The big dog in SOC making is of course Qualcomm. As mobile phones have grown in popularity, so has Qualcomm revenue, with they are now big enough take on companies such as Intel. This causes a lot of problems for phone manufacturers their fortunes are tied to what Qualcomm can do. Good or bad, this did not happen with the PC market. Probably because, the PC market was fairly well divided. In terms of processors, there was Intel and AMD. Motherboard manufacturers were like so many. Wireless chip makers were so many. Power supply makers were so many. The power, so to speak, did not rest in one hand.

With SOC, a lot of things are welded in. The SOC maker, hence, wield a lot of power. Qualcomm is already pretty big and it can only get bigger as the android market grows. Of course, a company like Qualcomm would continue to innovate and add new features because alternates are readily available, but again, Qualcomm is big because they make excellent SOCs. There is that.

Other than the ‘being held hostage’ scenario, there is another problem. A problem that android makers suffer from greatly. That has to do with being unable to differentiate themselves. With the kind of maturity that we see in the android market, despite being a tech guy, I myself wonder what exactly is the difference between a mid-range phone and a high-end phone.

The phone I have right now, Oppo F1, meets all my needs and it only cost 15000 bucks. It runs all my productivity apps and it helps me take great pictures, and social apps like Instagram compress the photos to such an extent that all photos look like they were taken by a 5-megapixel camera from the late 2010s. A slightly more expensive phone that I might want to buy is OnePlus 3, and then there is the Galaxy S7 and then the Pixel phones by Google.  I like expensive things, but I am unable to justify the purchase of a more expensive phone because I am unable to tell the difference between a basic Oppo F1 and a OnePlus3 or S7 or Pixel. Sure, a more expensive phone means bragging rights, and I could show off. However, there are other things you can use to show off, and a phone is hardly the device to brag about.

All in all, mobile manufacturers are struggling to tell their customers, why their phone is different from the others. That is where SOCs come into the picture. The SOC will allow – to some extent – certain unique features to be included with the phone. It could allow better integration of digital assistants, better power saving features, better photo taking, hardware customizations. A combination just might allow phone makers to differentiate them from each other. It will also save licensing fees that needs to be paid to Qualcomm, and also reduce the power that Qualcomm might wield if everything is buying matchsticks from them.

This is perhaps why Xiaomi is following along the footsteps of Samsung and Huawei. Samsung has its Exynos SOC (which powers a huge percentage of the Galaxy S7 phones they sell, and almost all phones sold in India are Exynos driven and not Qualcomm powered), Huawei has its Kirin series of SOC. Obviously, Apple has its own ‘A’ series of SOCs. Given these reasons, it is good that Xiaomi is hedging its bets in a meaningful way. I have had mixed experiences with Xiaomi and I hope they fix their supply chain issues (it’s almost impossible to actually buy a Xiaomi product when you want it. I don’t know how a company like this can survive with such an inefficient supply chain) so they can actually compete in the big league. They have a good design team, and talented engineers. I wish them all the best.

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

Error and Logging

[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]

A system, no matter how good it, should be capable of giving the right communication. This applies to people too. If there are two individuals, one of them an excellent work person with poor communication skills, and the other with average skills but excellent communication. On my best day or the worst day, I will always go with the person who has excellent communication skills (and medium work skills). That’s because a person with good communication is the one who will keep me informed about the good and the bad stuff, no matter how comfortable/uncomfortable the truth is.

On the outset, this all seems like common sense. However, in all the years I have been working, common sense is perhaps the rarest of commodities. People do stupid things, and then hide behind a veil of ego and false claims and losing touch with reality. That is why, as I continue to work on my app ecosystem, I realized that it is essential that it has a proper error and logging system.

From a strictly programming perspective, error and logs, both do the exact same thing. When something happens as expected, it is ‘logged’. When something unexpected happens, it is also logged, but shows up as a ‘error’. For instance, when a user signs in successfully, that is a ‘log’. A user signs in but it does happen for some reason, that would be an ‘error’.

A collection of logs is useful for making decisions related to performance optimization. For instance, if every user in the system is taking 10 seconds to sign in, and I discover that there is a new library that allows signs in to happen in 5 seconds, I know I need to implement that. There by saving 5 seconds for every user on the system. Logs are more of a proactive measure at making a system better. We use the collection of, the collection of (two repeated collections, not typo here), logs to find out what about the system can be improved.

A collection of errors is useful for finding out what is going wrong. This, unlike the logs, are about reacting to something that is going wrong. Let’s use the sign in example. If 10% of users are having difficulty signing in, then that is a problem. A problem that needs to be fixed as soon as possible, and the system should automatically trigger when the error percentage rises. Inform the operation folks and established documentation should also be automatically triggered allowing emergency response to start working.

In fact, if possible, the system should not only diagnose the issue on its own but also, if possible, fix it on its own. I could be throwing darts in the dark here but I think this is what machine learning is all about. The machine learns from its own mistakes and then starts doing things. Like say, fix problems with no intervention from anybody. I think this is practical and even possible. By my own experience, mistakes are like wheels. Some wheels need to be invented, while others have already been invented, and hence need not be reinvented.

Let’s say, the system logs an error system for the first time. This is the first time, so a human is involved in fixing it. Once the issue has been fixed, programming is done so that next time, when the same error is triggered, the system will attempt this fix. That means, no human need to be involved. The human can now focus on fixing new issues, instead of reinventing a wheel that already has been wheeled out last time. Machines are good at repetitive tasks, and that means, if something has been repeated, I don’t quite understand why humans should be involved? The time spent by the human re-fixing what has already been fixed could be used for something else. That time could be spent fixing new issues. That time could be spent improving the system, like making it faster or better. For all I know, the human can use the same time to watch a movie or fall asleep on the couch or go for a walk. The idea is to avoid reinventing the wheel, let the machine do what is already done and the human do something new and exciting.

So yes, my app ecosystem will have a machine learning enabled error and logging system.

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

Project TD - Day 17 update - Requirements Planning updated

Project update.

So, I went ahead and have updated the following stuff in relevant pages.

Accessibility, Multi Language Support and Natural Interfaces
Choice of Cloud Platform
Supported Platforms – End Users
Error and Logging

Obviously, the main Requirements Planning post has also been updated, with the above links for future reference.

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

Choice of Cloud Platform

[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]

The app ecosystem has many components but it can be broken down into two essential parts. There are the user apps (all types of users) and the API engine (which also includes the data storage system). The user apps live on the web, android and iOS. The API engine and the data storage system live on the cloud.

For almost a decade now, we have been hearing about this cloud. We hearing about it so much, sometimes, it’s almost funny to talk about it. However, the cloud is very real, and it really does make life simpler. For a developer, the cloud technology is a god send. It reduces costs, allows new features to become immediately available and mostly makes life better for end users as a consequence. It is only obvious that my app ecosystem runs all its processing in the cloud.

For cloud, I can only think of two choices – Azure and Amazon Web Services. I understand that Google also provides cloud services, and there are a lot of many smaller companies that provide cloud services. It is also possible to utilize cloud software to build our cloud services.

For those who are unclear about this concept of cloud, I will put a simple definition here. Cloud is about a service that can be scaled up and down as per requirements. Almost instantly. That is the cloud. For instance, I am running a server on a VM and I realize that I need additional 16 GB of RAM instantly. With a conventional VM, I will have to go through a series of steps and wait till it gets provisioned. This is just for RAM increase. What if I only needed the processing power increase for one day (perhaps I was launching some huge sale which only lasts one day) and no more. What if I wanted a bigger hard drive for a week only. Or perhaps, I don’t know what I need, and I wish to increase or decrease or perhaps I just wish to experiment and find the ideal combination. All this will lead to a flexible solution that will allow reduction of cost.

In a non-cloud scenario, there are people who have to do things manually. I am all for working with people (one cannot get anything done without people) but sometimes, they can be a hindrance rather than help. It is in human nature to make mistakes. That is why, when possible, we use machines. Cloud removes that human factor almost entirely. Without going through the IT team (or not have an IT team at all) I can provision stuff that are required to allow my service to work.

Now that I have discussed what the cloud is, time to decide the choice of cloud provider. For extremely obvious reasons, I will go with Microsoft, with the only alternative I would recommend being Amazon Web Services. Compared to Amazon, Microsoft services are expensive, and they have reduced trial periods. For instance, Microsoft is generous enough to give a month or at most 3 months of trial services. Amazon though, can give a year worth of free services in some cases. Clearly Microsoft is expensive.

However, for one thing, I have been using Azure for almost 5 years now and so far, it has not disappointed me. Their service is excellent, and Azure keeps getting better with new services being added constantly. They met my needs 5 years ago, and I am sure they will meet all my IT needs for years to come. It is possible I am a little biased here, but I am yet to come across a simple reason (other than low price, which is not really a priority for me) why I must explore Amazon Web Services, or some other cloud service.

So yes, the app ecosystem Project TD will be powered by Azure cloud.

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

Accessibility, Multi Language Support and Natural Interfaces

[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]

For some reason, lately, I have become obsessed with the concept of making sure that folks (like my mother) who are unable to enjoy the fruits of what modern technology has to offer should at least enjoy what my ecosystem has to offer. I will admit, my interactions with my mother is the motivation for all this, and as a consequence, I have blogged my thoughts on that here, and here.

I understand that there is already a lot of work done in this domain. Accessibility features have always been included in every operating system. However, I am beginning to feel that they are mostly designed for western audiences and don’t really apply to someone like my mother. The idea here is to find out what is already being done in terms of accessibility, and figure out how I can improve upon them (if it is possible at all) and ensure that my mother user the cloud services and the apps that are going to part of this ecosystem.

One area where I am particularly interested in are natural interaction systems. This word has many meanings I am sure. To clarify, here is a simple example. Every morning, my mother takes over her empire which is her kitchen. While she is working, she likes to listen to music. She has already turned down my offer to get her a modern device such as the iPad for music listening and continues to insist that she wants to use the old knob based, button based radio that has been wedged in her kitchen for years.

These knobs and buttons (physical stuff) is what I define as natural interfaces or natural interaction systems. I have been observing the way she interacts with this radio and have been drawing some conclusions. I understand that she prefers the feedback it provides and also simplicity of it. Despite all these years of using touch screen devices, I still find it easier to type on my physical keyboard. If someone like me prefers the convenience of manual feedback, I can imagine how it must be for someone like her.

That means, I must design and probably build an interaction system that incorporates some kind of a physical feedback thing. At this point, all I have is an idea, or more like a target, an end game. Of all the things in my app ecosystem, the UI is the one thing that excites me the most. If I can make this happen, and I can figure out a way for my mother (and by extension mothers everywhere) utilize the benefits of modern cloud services, that would be my greatest achievement.

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

Supported Platforms – End Users

[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]

An ecosystem is worthless if people cannot use it on the platform of their choice. A few years ago (like say 2 years ago) deciding on the supporting end user platforms was tricky. The major platforms were windows desktop, windows touch enabled stuff – windows 8 and windows 10, then there was windows phone, the web browser on desktop, the web browser on mobiles, the web browser on tablets, and then of course android on phone, android on tablet and lastly, ios on phone and ios on tablets.

Phew! That is a lot of platforms. That would drive any developer crazy! It sure did drive me crazy.

Today, and during the year in which this blog post was written, I would say the tech revolution has reached its satisfactory conclusion. That’s good because, now things are simpler. As I continue my work on project TD, I must confess that life is a lot simpler now. With that knowledge, I know now that to reach to the widest audience, I only have to reach out to the following three platforms – Web Browser on desktop, android on phone, and iOS on phone.

Web Browser on desktop

At the end of the day, any machine with a keyboard plugged into it can run a web browser. I recently wrote about the appeal of web development. Web browsers have reached that maturity where they can support full-fledged applications. They also work well with touch enabled devices. A few years ago, I would have no choice but to build a traditional windows desktop application, the touch enabled and so called ‘modern’ or ‘metro’ apps for windows 8 / windows 10, and do the same for Mac and Linux.

Now, I don’t need to target any of these desktop platforms with native apps. The browser based app will take care of all this. Imagine the amount of effort I am able to save here. More importantly, we are now entering an era where a lot of people no longer think running applications in a browser is odd or weird. For someone who grew up in the 90s and early 00s, not using native desktop applications is odd. However, for those who grew up in the late 00s and onwards, using web app comes naturally. That means, having zero native apps will not hurt my ecosystem if it should go wide.

Android and iOS on phone

Intentionally, I have decided to leave out tablets entirely out of the picture. Perhaps, five years ago, we thoughts that tablets might go mainstream and even replace PCs and smartphones. Unfortunately, that did not happen, and I pretty much concluded my own observations in this post. Just this morning, I found out that the iPad version of the Instagram app is but a blown up iPhone app. This does not imply that a large company such as Instagram is lazy. On the contrary, it is a reflection of reality. Tablets are not a major platform and any time/money spent on it is not going to give returns.

Besides, phones have been getting bigger and have become ubiquitous. Thanks to improving infrastructure, it is not that expensive to download apps anymore. Phones also have better SD card support now, and most of them come with decent onboard storage as well. All in all, the mobile platforms have achieved a certain maturity which I should exploit.

Previously, I was of the opinion that I don’t wish to touch iOS. I assumed that developing for the apple platform can be pretty expensive. I also assumed that there are very few iPhones running around. However, I re-did some research, and see if perhaps the passage of time has changed the situation. I found out that at least some things have changed. A cheap Mac and a cheap iPhone can be obtained at prices slightly more than android development gear. The developer license continues to be expensive but that is a business cost. Further, I noticed that there are a small chunk of folks who are indeed using the older generation iPhones such as the 5c and 6, so perhaps there is indeed a user base to target.

All things considered, I decided that when it comes to mobile, I should target both android and iOS.

While I am writing about this, I must also mention the state of mobile optimization of the web apps, which are anyway being developed. I would say no. I am not going to go out of my way to optimize the above mentioned web apps to work on the small screen. Folks who want to use the site on their mobile browser should simply install the available mobile apps. Either that or live with poorly optimized web app. That, I am afraid, would be there choice.

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

Developer Tips – Sticky Notes and One Note and Word to Augment Documentation

I am always going on and on about documentation. That’s my jam because I know and have experienced how much things get delayed and messed up when there is no documentation. I have worked on projects large and small, and one thing is for certain. For years now, we are living in an economy where rarely do enterprising individuals will go through at least five employers in their career. Further, people like, work for at least five different employers in any given year. That means, folks who work are constantly on the move. Work gets paused, and then it gets resumed, and that is how it works.

On an individual level, this happens a lot as well. I myself am juggling half a dozen projects – work and personal – at any given point of time. There is no possible way I can remember what I was doing on project A 2 days ago because I am now neck deep in Project B and Project C. The human brain is not designed for memory storage. It is designed for processing.

To that effect, today, I thought I will blog about the many note taking tools I use for my own work, to keep things documented for efficient work flow for myself and for others.

Sticky Notes

All windows computers come built in with sticky notes. The concept of sticky notes (just like the real sticky notes, which is also something I use in my daily life) is simply. Open up a quick note taking page, and start typing anything and everything. Prior to discovering sticky notes, I was using notepad, but notepad has some problems. The problem is that it was designed in an era when everything had to have a menu bar, and it has extremely poor formatting and it does not auto save.

The sticky notes, in some ways, is like a more advanced version of notepad. It auto saves. It is quick to launch and retains formatting. It also has some neat colors, which I don’t know, brightens up my day.

I normally use sticky notes when I am researching something, developing something or working out a problem. Here, the priority is quick note taking, copy pasting and such.

One Note

Sticky Notes is nice, but if it has one flaw, it is that it does sync with other devices. I love working across multiple devices. Even as I write, I have like at least 6 devices around me, which are all cloud enabled. At a given point of time, I may decide to read or write something on any of those devices. I don’t wish to have that uncertainty where something I wanted to mull over is not available.

That is where OneNote comes into the picture. OneNote is like a book binder, which holds multiple books and each book can have unlimited sections, and unlimited pages. It’s also free. It is available on every platform imaginable.

However, I wont trust OneNote to do quick note taking. For that, I exclusively use sticky notes. OneNote is more long term where in all the research is already done and now I want to push it to the cloud. Usually, stuff that is to be stored permanently will move from sticky notes to OneNote. Quick Note taking is not an option on OneNote because it is heavy, and hence slow. For long term note storage, OneNote is excellent because it has excellent syncing, formatting, organizing and sharing features.


Microsoft (who also make OneNote) makes another entry in my documentation tools via their productivity extraordinaire, Microsoft Word. Together – sticky notes and OneNote – take care of all my note taking needs. So, where does Word come into the picture?

Sometimes (actually a lot of times) a lot of stuff needs to be shared, in a proper format with others. Sometimes, it simply makes sense to have something in an easily readable format. This actually happens more often than you think. Most importantly, it is impossible to assume that other people (or unknown devices) have sticky notes or OneNote. However, most of the time folks will have Microsoft Word (or something similar) installed on their work machine.

Along with this, Microsoft has made an excellent job of integrating the cloud with its flagship productivity software. So, it all syncs up on OneDrive, which itself comes with simple version of Word in the browser. To me, that is the best of both worlds. When these conditions are satisfied, it is best to use Word over sticky notes and OneNote.


Obviously, there are alternatives available for those who don’t wish to use the above. There are quite a few replacements available for sticky notes and they all probably have better tools. Much of them free, and they integrate with windows, mac or linux, no problem.

For OneNote, the only alternative I would recommend is Evernote. I have used Evernote, but they are a paid service for advanced features. So, I am not using that. Not when OneNote gives me everything Evernote can give and I don’t have to create one more account.

For Word, there is LibreOffice which is quite good. Google Docs is also okay, but it runs in a browser and I really don’t want to tie my productivity to a browser based app all the time. It simply does not gel well with me. For the cloud, I have recommended OneDrive above. Alternatives are Google Drive and Dropbox, and here, I would rather you go with the latter.

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!

Mom Mode – Trying to Figure User Interaction Part Out

I recently wrote about an issue with user interaction. Since I wrote (and that thought entered my mind) that, I have been unable to get it out of my head. I keep thinking of a few questions.

Can the issue be fixed?

If it can be fixed, what kind of solutions are available?

Which of those are feasible, not just for my mom, but other mom’s (and their sons) who are in the same spaceship as me?

Like a lot of people, I try and look at a problem with an approach that there is usually a solution. At least, some amount of time must be dedicated tackling the issue, document the steps taken and then arrive at a conclusion. One conclusion is that there is no solution. Another conclusion is that there is a solution. It’s not blind positivity. I like to call it, pragmatic positivity. In other words, assume a positive output and then dedicate sufficient time to prove or disprove the assumption.

Going back to the first question, I would like to start off by assuming that the issue can be fixed. A future blog post will either prove my theories or disprove it. Now that I have assumed that the issue can be fixed, I need to look at what I know about the person of interest. In this case, the POI is my own mother. That means, I have years of experience observing her. All the data is in my head. The things I did before I was 4 is completely a blur to me, but I remember most of the important events in my life since I turned 5. Obviously, almost all the important moments have a mom component in them.

In other words, deep within the confines of my mind, I have data about my mom unconsciously logged away. All I need to do is go back in time – inside my head – and look at her interactions with the variety of technology things that she has used. Perhaps I have mentioned this before, but our family comes from a rather poor background. Things like going to the movies was a luxury, as recently as 8 years ago to me. To my mom, even today, she is convinced that only the rich people go to the multiplex or take a taxi cab (something that is part of my daily life since 4 years). That means, she has interacted with things that are low tech, and thanks to my choice of career (computer science, of course), she has interacted some pretty high end stuff too. I remember her reaction when I told her that I have paid roughly 7500 bucks for a keyboard and mouse. It took me quite a while to convince her that the purchase was indeed essential for my work, and I am not some kind of deranged spend thrift.

While recollecting the data about my mom’s interaction with technology will take a while, I know that she is a fast learner. The good book of biology says that genes are passed on from our parents. All through my life, I have noticed that my classmates, my fellow engineers, my work colleagues have always taken longer than me to learn something new. Somehow, my reflexes and my ability to learn new things are just as sharp as they were when I was a teenager. Sure, I may have worked on it but mostly, I think, it’s in my genes, and I got these attributes from my mother. After all, she is the one who taught me English despite herself being a Kannada medium student who did not finish her 10th standard schooling.

All this brings me to a conclusion. To solve the problem of her interaction with cloud services, I must understand that kind of interactions she is currently able to do. At this point, I must already agree that the current interfaces – touch screen and their small sizes – are simply not an option for her. This is a woman who grew up watching a black and white television (with huge knobs for changing channels), which had to thumped on the sides, and the antenna bent and shaped to see something, and now, she has to watch her kids use a tiny smart device that can happily show almost any video on the planet. She has lived through multiple eras of technology and used all of them (and taught me how to use them). Now, I guess, she is at the end of her learning curve.

All in all, till now, the horse would go to the well. Now, I must bring the well to the horse.  

You can get more details about Project TD, right here.

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