jay's old blog

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

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!

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!

Technologies Involved



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

App ecosystem won’t build itself, because developers don’t actually write all the code necessary for the software. A lot of times, it boils down to utilizing libraries that are already developed. If I am building a mobile optimized site, it is simpler and cheaper to simply integrate bootstrap into the code than writing my own mobile optimized stuff.

In this page, the idea is to list out all the technologies, libraries and anything else that we are using. For now, this is all we are using. As more time is spent developing this project, we will update this to list all the stuff we are using.

Windows Desktop App

XAML

C Sharp

Web

Bootstrap

HTML, CSS, JS

jQuery

Android Mobile App

Java

XML

Libraries

Currently none to be mentioned.

[Last Updated February 10th 2017]

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

Choice of Technology for API



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

At the core of any ecosystem is the API system. The API is consumed by the apps, that are in turn used by the users. They could be the apps used by the operations team. Apps used by the administration team that oversees user content that is pushed. Apps that are used by the restaurant owners and of course restaurant patrons. All of them will interact with the cloud storage that actually serves and takes data over a collection of API calls.

That is why, the choice of technology used to build the API is important. As much as possible, the whole eco system will take a modular approach to development. If some technologies should die (which happens more often than you might think), we should be able to remove things and replace them without affecting the rest of the components in the ecosystem.

Although the API system is also modular (at the end of the day API calls are but simple web routes) and follow the remove and replace principle. Still though, rewriting the API itself will be a huge task. That is why, if I am going to choose an API technology it must be something that I will keep for a long time and only replace it if I have no other choice.

There are quite a few technologies out there that can be used build RESTful API’s – Node.js, PHP, Python, Rails, Dot Net and Java.

First up, I am not a big fan of PHP. Because, with all due respect, PHP HELL.

That leaves other technologies of which I am not going for Java because, I have already invested a lot on c sharp and I am not going to spend an equal amount of time on Java, unless it is a matter of survival.

Python, Node.js and Rails are things that I am familiar with but it makes sense for me to leverage on my existing dot net skills, which is where DOT NET based API building comes into the picture. As it is, the project uses a lot of Microsoft technologies (except for the android mobile, almost everything else depends heavily on Microsoft related technologies) and using the same thing for API reduces total effort time.

However, as far as planning goes, if it comes down to using an alternative, I would side with node.js. It seems to be the one that is much more modern and well document among other alternatives. So, that would be the alternative. Yeah.

[Last Updated February 10th 2017]

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

Native or Xamarin



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

With the way mobiles are taking over everywhere, it is a given that if some service is not accessible on mobile – either through a mobile optimized website or an app – then such a service might as well not exist. I once went without paying my home power bill because my utility provider did not have a mobile payment option. Folks may not be able to afford a PC but they can afford a basic mobile. Look no further than my experience with the Micromax P290, right here.

Now, the problem with Android is also a good thing about Android. There are so many ways to develop apps for android. You can use the native development tools. You can use web technologies to build the apps. You can also use c sharp to build apps on visual studio / Xamarin. There are just so many options. The thing about using non-native development tools is that, they allow for multi-platform deployment. For instance, I could (mostly) use the same web based code and then eventually deploy on android, iOS, windows phone, windows desktop and of course in a browser.

As the architect of this project, I must make a choice here. Do I go hybrid and target multiple platforms? Or, do I go native and code using native tools and code. If I choose the latter, then, the apps will only end up on android on nowhere else. In an ideal world, sure, I would love to have my apps running on all mobile platforms. Unfortunately, I must look at my target market and I notice that almost all of them are using android devices. Right now, the way things are, mobile = android.

So yes, going cross platform is not really an option. It simply increases cost. Besides, most of our apps will have an equivalent website anyway, which is mobile optimized anyway. All things considered, it’s Native and not hybrid via Xamarin.

[Last Updated February 10th 2017]

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

User Types – Operations and Administrators and Consumers



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

There are different types of users who will be using the app ecosystem. I can broadly divide them into two categories.

Front Line Users (Someday I must come up with a better name for this)

These are users who actually use the service. Rather, these are the consumers, everyday folks who visit restaurants and those who own the restaurants. We must make the (hopefully correct) assumption that their choice (or rather, their only computing device) of device would be an android smartphone. I must also assume that tablets are dead. I wrote about it earlier. That means, optimizing or building a separate android version optimized for tablets is an unnecessary effort. I would like that, building a version for tablets would be nice. They have a much larger real estate which opens up many possibilities.

That actually brings up the issue of accessibility. This is something I have decided to take rather seriously, and that is why, there is a separate article on this. We will revisit this topic later.

Returning back, so yes, right now, I only envision two types of users.

Restaurant Patrons – These are the folks who visit the restaurants and pay for food and stuff.

Restaurant Owners – These are the restaurant owners, who then proceed to see what the patrons are doing at their restaurant.

In both cases, I am looking at an android app itself, and then proceeding to build a web version of the same. In all probability, the web version of the app may never be released because it’s easier to manage users via app than via the site. It reduces workload and also just makes sense. People love apps, although they don’t love updating it as much. Then, there is the magic of notifications.

Behind the Line Users (yes, definitely a better name is required)

Behind the line users are those that are sitting at the offices, and that means, they do have full access to a working computer. That means, we can assume access to an actual computer, with a screen, keyboard and mouse. Here, I have two options – a desktop app (it needs to be installed) or a web app with no mobile optimization.

If it is going to be a desktop app, then it will be built as a UWP that will run only on windows 10. I don’t see any reason why an app needs to be targeted for anything below windows 10. At the same time, what if the user is using a Linux (yes, it happens) or Mac (yes, this can happen too. Some folks insist on paying twice of what something is worth, if only to get the apple shaped light :P). Going by that logic, it is prudent to start off with a web only app. If it comes to it, it is possible to wrap that web thing into a desktop app, which should solve the challenge of having an actual desktop app.

That is the cool thing about windows app development. Things are a lot more open lately, making life easier. With that in mind, there are three types of users.

Operation Users – These are the folks who will monitor the service status of the cloud service, which acts like the back end for the whole thing. These are also the folks who will look at Error reporting system.

User Administrator for Restaurant Patrons – These are the folks who manage restaurant patron accounts.

User Administrator for Restaurant Owners – These are the folks who manage restaurant user accounts.

As work on the project continues, more user types might be created. However, I think these are the users where it all starts. I will see soon enough. Using the available tools of asp.net with MVC, it is possible to simply build one web app destination and customize the views based on user privileges. Yeah, I think I should dunk the entire desktop app thing, and build one single app that runs in a browser. That will bring in true compatibility across windows, Linux and Mac. Heck, if I play my cards right, it could also be mobile optimized.

[Last Updated February 10th 2017]

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

References



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

There are some places which act as reliable online and offline resources for development. In this section, I will list out all the links and books and everything else that we are using. This will others who might follow.

MSDN

Perhaps the very first link that we will use extensively would be MSDN. Everything we need to build APIs and Azure related stuff is all available right here. Years of using it also means, it is that much easier for me to navigate this huge library of knowledge, sorted and arranged for easy consumption.

Stack Overflow

Ah, the second best site for developers online. Anything and everything is available here. I usually start at MSDN, and then head over to stack overflow, and then keep shifting between them until a solution is obtained.

[Last Updated February 10th 2017]

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

Design Tools



[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 tools make or break anything that we are building. Even the best developer can build almost nothing without access to the right tools. Without tools, man = monkey.

Visual Studio

My most favorite tool of all, and hence the very first place. Visual Studio is literally (with Microsoft’s efforts to go cross platform over the last two years) the only IDE one needs to build almost anything. If you are crazy enough, you can even build iOS apps, with some caveats. If you have been a developer for a while, you either love it or you don’t.

In this project, I would be using this mostly for building the APIs and the Cloud portion of the app. I suspect that I will be building the web based admin interfaces also through this IDE.

I love it.

Visual Studio Code

While Visual Studio is awesome, it is also heavy. Like seriously heavy. Building simple stuff, and simply viewing code from a file that came online or from a colleague takes a while in Visual Studio. Most importantly, for web development, we need a simple editor that is superfast. That is what Visual Studio Code is. Fast, light and awesome!

I will probably use this for building and maintaining the user facing sites that will mostly be general information.

Android Studio

I started off by not really loving this (although it is a huge improvement over Eclipse based android development) but the new version is actually better even if it has some insane RAM requirements. Man, it’s not the most efficient IDE is it.

This will be used to build the android apps. However, I will explore the option of building the android app via Visual Studio and if that works, its hasta la vista Android Studio.

Filezilla

For all the FTP related action.

Snipping Tool

Bread and butter of basic documentation that involves screen grabs. Works best with Irfan View.

Microsoft Office

For all the documentation needs, writing and reviewing and generating all the documentation that keeps this project on track.

7 Zip

Yeah, compression and decompression is an everyday activity.

Git – Desktop and non-GUI Tools

For essential version control stuff. More details about version control can be found at these blog posts.

Slack, LAN Messenger and Skype

Yeah, these are the essential communication tools, for outsiders, teams and locally organized folks in a group environment.

[Last Updated February 10th 2017]

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