jay's old blog

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

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!

Project TD - App Ecosystem – Day 5 – Requirements Planning



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

It all starts with an idea, and I seem to already have one. Then, comes the requirements planning. In many ways, requirements planning is a catch all term. It is sort of like a trip plan that one makes before leaving the house. The app ecosystem will consume a lot of my (and anybody else who might join hands with me in the future) time, energy and of course, money. This document will record all the many different components that need to be built.

Obviously, this is just a blog. I would eventually need to look at a more efficient tracking system (I have my eyes on Atlassian’s offering for planning and tracking software development, JIRA) as the code grows. However, the more professional tracking solutions cost a bunch of money, and I must justify the cost before I can jump into it. Cost Benefit Analysis is the key here.

Right then, here are the many components of this project. This list only encompasses the things I have thought of and jotted down for the last two months. As the project progresses, I am sure much of the below will evolve (not change. The below notes will evolve) over time. Each of them will link to their own pages, with additional details.

Delivery Date (When It’s Done but with beta access)

Open Source or Closed

Hardware

References

Design Tools

Version Control and Project Management

Back up and Redundancy

Technologies Involved (modular approach)

Native or Xamarin

Choice of API technology

User Types – Operations and Administrators and Consumers

Accessibility, Multi Language Support and Natural Interfaces

Choice of Cloud Platform

Supported Platforms – End Users

Error and Logging

[Last Updated February 22nd 2017]


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


App Ecosystem – Day 1 – Naming the project and beginning things



Yesterday, I wrote about finally beginning to work on not just an app, but an entire app ecosystem. As with anything, everything starts with giving it a name. A name is everything isn’t it. In my earlier post, I spoke about the relevance of meaningful names making code. If I am the kind of guy who spends so much time simply naming a basic variable in a simple piece of code, I should give a proper name to this app ecosystem as well.

While naming, there are two types of name. There is the placeholder name, and there is the actual name that you use for marketing. As an independent businessman, I must appreciate and more importantly respect the value that marketing brings into day to day business activities. So, for now, I don’t have an actual marketing name for my ecosystem. However, a placeholder name, I will go with would be ‘Project TD’.

What TD stands for, should remain in my own head for now. I am weird that way ;)

Moving on, any app ecosystem, especially a technology system, should and must follow the Software Development Life Cycle. Sure, a guy like who hate using established systems such as SDLC. It’s boring, and it sounds dull because some folks designed such things, and they were probably not cool. I almost always take the road less taken, the uncharted island attracts me more than an established. However, I admire and respect what others have done, cool or not cool. Respect must be given, where it is due, no matter how much I might not like on a personal level.

So yes, TD will also follow the SDLC cycle, but I will make changes as necessary. A development model that does not adapt to changing scenarios is a dead one. I don’t want my development model to die, obviously. Here is the standard life cycle that I will be using.

  • Prep work – includes risk analysis
  • Design – loads and loads of drawings and diagrams. Also includes presentation, mostly to non-tech people.
  • Development – Loads and loads of typing. Referencing external sources, books, mentors. 4 monitors, with simultaneous coding on at least 2 computers.
  • Testing – Engaging with lots of different types of users, everybody from tech savvy users to folks who are turning on computer for the first time. A true architect and developer never forgets his users because that is where the money comes from.
  • Deployment – Including a lot of security stuff, discussing encryption systems and networking realities.
  • Repeat and Rinse.

While all this cycle stuff is happening (or will happen), perhaps the most important question is why do all this? More importantly, why do this at all?

The answer, it boils down, to the simple life concept of ‘show, don’t tell’. Even when I was a kid, I preferred to show stuff, rather than explaining stuff. Interacting with the five senses is perhaps the best way to get some work done. This blog (and all the other things I have done and shown for the past five years) has helped some score some serious amount of deals, and that means colour green. While I am already designing end to end solutions for clients, I am yet to train people on end to end solutions.

Posts such as this one, and many more that will follow, will help me keep track of progress. As always, I also hope that some of the things that I write on blog will help others who need information. Hopefully, at least one of these goals will be achieved.

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

Evolving from App to App Ecosystem



Few years ago, when I was building my android portfolio, I worked on some essential apps which can be found here, here and here. Obviously, the servers related to them are currently switched off, and the app themselves removed or not function in the google play store. Of course, those apps helped me get the assignments I was looking, so the investment made in those (now) defunct apps have been recovered many times over.

However, some benefits much deeper than just return on investment, both time and money. As I was building those apps (2 to 3 years ago), I felt that something was missing. I was developing apps, but the bigger question was this. Where do these apps live? If apps were people, then where do people live. Earth is where we live, and we thrive because of the ecosystem.

Of course, this is something which is known to most of us, but I realize that now, back then, I always thought of myself as an app developer. Obviously, even back then, I never thought of myself as a lowly programmer, so I was always thinking of ahead of many of peers. Now, as the years have gone by (hopefully, a little more mature) and over the last few months, I have been thinking about updating my portfolio. Replacing them with newer, and hopeful better (but not necessarily useful apps, because, that is not really the industry I am in) apps.

However, I realized over time that (and this thinking process is what has allowed to work as a solution consultant instead of a simply being a trainer or a developer) that when I rebuild these apps, the focus should be on building an ecosystem rather the apps themselves. Apps don’t work alone. They interact with the user. They interact with other apps installed on the phone. They interact with the operating system that acts as the platform on which they run. Not to forget that apps also interact with the hardware underneath the operating system, and there is the issue of performance and optimization. Then, there is the part about data. There is data storage which happens (or should happen) online as well locally. When it comes to online data, it could be cloud services that enable the app to do its own job, while also integrating with cloud services that provide additional facilities.

As I took time off from android to work on dot net, these thoughts have been consistent. Whether it is a web app or a mobile app or a desktop app, all apps (big and small, huge and tiny) are part of an ecosystem. Interacting with elements that have come before them and with items that come after them. The keyboard I am typing on was probably designed before computers even properly invented. Yet, here we are, living in a magical world where I can talk to a person literally on the other side of the universe.

It’s a wonderful world we live in, and it is finally time for me to absorb this understanding into any and all things I develop. No, I am not a app developer. In fact, I haven’t been an app only developer for a few years now. I am now an ecosystem developer and that is what I should do.

Of course, all talk and no walk is not something anybody will appreciate. Going back to what I said (and have done years ago) about those three projects, the app related to restaurant tipping is the one that is closest to my heart. Mostly because I eat out a lot, and love leaving generous tips. That is where I will start. If all goes well, in a few months from now, I would have built a proper tipping eco system. If not, I would have learnt some really cool stuff and would be even more prepared to restart the eco system building process.

Either way, it will be awesome and win-win situation for me.

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