jay's old blog

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

Back up and Redundancy



[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 lifetime of working with computers has taught me a couple of things, and one of the thing I learnt is the amount of issues that are raised because of poor supply in, well, in the cities we live in. For reasons that are beyond the scope of this document, it is essential to focus a lot on backup systems, and power management is the first big topic on backups.

Power Backup

One must assume from the word go that we cannot always rely on continuous power supply, where we live. Power cuts can go from 10 minutes to an hour to 8 hours to a day. It is simply impossible to assume that something will be available without interruptions. That means, if an essential project is at hand, then, it is best to prepare for every eventuality.

That is why having multiple computing devices (as explained in the hardware section) with at least some of them powered by portable battery becomes essential to keep work proceeding without any issues. That is why, I recommend at least two battery powered computing devices, and not to forget general backup supply to the main workstation PC.

Further, it would also be a good idea to invest in a home power backup system, although, I must admit that those things cost a bomb. If the task at hand is critical enough, investing in a diesel power generator is also a good option, and if the supply of money is good, even essential.

Redundancy

Computing devices can break down for a number of reasons. They could get stolen. Parts could simply stop working, and input devices in particular can die without any warning. All in all, redundancy takes on a brand new meaning because of this.

That is why, multiple computing devices must be hand. Also, don’t skimp out on the quality. If necessary, pay more for less (buy lower spec’d machine but go for the expensive warranty) so that what you have will work no matter what.

Developed code must be backed up in multiple online locations, in servers located all around the world. Offline backup must be made multiple times, and must be stored in multiple locations. Obviously, backup restore must be tested, and disaster plans must be exercised and recovery plans tested and verified when the worst happens.

A recovery plan (tied to a backup plan) that does not work means, you are effectively walking around without a helmet.

Redundancy also means that all the work (at least the one’s that are currently being worked on) are cloud enabled. That way when disaster strikes, you should be able to setup a completely new work machine into your own, assuming superfast internet access. This is perhaps, the most essential redundancy plan there should be.

Other Thoughts

When it comes to backup and redundancy, a certain amount of patience and planning becomes essential. The idea behind having a backup and redundancy plan is not because you expect something to go wrong. In fact, many projects go just fine without any issues. That makes the entire activity related to backup and redundancy an exercise of wastage. This is similar to how some people don’t want to pay for warranty extension because, well, most of the time, the hardware simply works. However, errors are part of any system and such a system manufactured the hardware. So, yes, having warranty makes sense.

Remember this. You might as well have something and not use it, than need it, and not have it.

[Last Updated February 10th 2017]

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

Hardware



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

No development can happen without the necessary hardware in place. Often, perhaps the most overlooked part of any software project would be not having the necessary hardware. This might probably look silly but I am writing this mostly as a guide to other folks who may end up joining hands with me.

While this will be silly, it’s amazing how many engineering students cannot tell the important of having a higher RAM when compared to a slower processor. So yes, from experience alone, I can tell that a section on hardware would be most useful in a world filled with the uninitiated. I am dividing the hardware stuff into multiple sections. That’s because there are so many different hardware units used on this, and they each deserve a separate section. Obviously, I am not using any physical servers, with all the online data storage and processing handled by cloud based services, from Microsoft Azure. More details can be found at this location.

Project Related Hardware

This is something that applies to the entire project. Whoever is in charge of managing the entire project’s hardware must be aware of the following stuff.

Individual Developer Hardware

This is something that is required by the developer to hang on to. A developer who is poorly equipped is a developer who is worthy enough to code is what I believe.

Personal Computing

I recommend at least three different computing machines. A main machine that will do the real heavy lifting. A second machine that is reasonably powerful, and good enough to act as emergency development machine. Lastly, a simple device for basic stuff like documentation and doing administrative tasks. We are looking at minimum of three machines, with each of them acting as a backup to each other. Three is not the final number, but it is a good number to start with.

Here are the essential hardware specs for developer.

Main Work Horse PC (not laptop)

Display of 27 inch + Display of 15 inch. If possible, an additional third monitor if the computer can support it.

RAM of 16 GB. 32 GB RAM, if the motherboard can support it.

Processor, any of the i3, i5 and i7 processors. Any generation is alright. Newer the better.

Onboard graphics card is good enough. Dedicated graphics card is simply a drag on the power supply, especially when you have to live with constant power cuts.

Power Backup. At least 4 hours of backup, for the entire setup (at least two monitors).

Wireless Keyboard and Mouse. No wires for us please.

The Second Machine (the actual laptop)

Standard 15 or 14-inch display. Not FULL HD, not a problem.

8 GB at least. i3 or i5 processor (don’t go for i7 because that will be a power hog) is alright. If you can get Core M, that is even better.

Dedicated graphics card won’t do. Onboard are powerful enough these days and an extra graphics card can consume more power.

Optional wireless keyboard and mouse, although most developers do just fine with the built in keyboard and trackpad. If you are a touch typist, you know you should go for the former.

The Third Machine (a hybrid laptop, touch screen)

Bare bones 2 in 1 laptop running windows with detachable keyboard. Yeah, this will be mighty useful for administration tasks, presentations and even some emergency web development stuff. The cheaper the better. Further, these devices can run for over 8 hours for sure.

Mobile Computing

Two android mobiles, hopefully with a FULL HD display and 3 GB of RAM. These can be extremely useful for testing and even some emergency presentations and general productivity.

[Last Updated February 10th 2017]

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

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



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

Right now, I don’t have a proper estimate as to how long this project would take to reach conclusion. In fact, until I finish working on the use cases, I won’t have a clear idea. Further, I am still building my team, so until I have a grip on the head count, the deadline will not be that obvious.

Despite all these reservations, one cannot work without a deadline. Luckily for all of us, unlike an actual physical product, a software service is built as, well, a service. We can always have variable goals with variable features. The basic nature of software ensures that software evolves, like life itself. With that in mind, here are the dates I have given myself for now.

First Beta – Version 0.5.1 – December 5th 2017

First Release – Version 1.0.1 – June 25th 2018

The idea is to work on the two channels – beta and release – separately. That means, there would be two ecosystems running parallel. The beta eco system which will be pretty unstable, and unfit for everyday consumption. This becomes a playground for enterprising individuals – developers, testers and idea women and men – to experience cool stuff, fail and get up. The release channel is the end product of hundreds of testing hours and ready for regular people use.

While I make these grand plans, I understand that the project itself may never come to fruition. I once spent 4 years working on something, only for it collapse over a matter of weeks. Still, no work goes unrewarded and if this project also should face a similar defeat, some gains are always there to be made.

Besides we all remember Duke Nukem Forever.  

[Last Updated February 10th 2017]

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

Open Source or Closed



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

Code development always brings up the question of code visibility. Should it be open sourced or closed source?

This Project TD could be a complete waste of everybody who is involved. Or it could be something really cool. Or somewhere in between. Yet, as I enter my fifth year of being a trainer, I have proof to show that at least some of my stuff has become useful to others. This project (and all its related resources) might become useful to at least one other person. Perhaps more if I am lucky.

Then, there are the personal benefits I have enjoyed, thanks to open source software. I use Firefox extensively. VLC player, another software that has really made my life better. Back when I could not afford Office products from Microsoft, I used OpenOffice as well as LibreOffice. Then, there are all those free code that is available online which has helped me greatly.

All in all, at this point, the decision to go open source is obvious, as long as all materials related to project TD is used for non-commercial purposes, and the user links back to project TD related resources. I may add some more conditions, but for now, this is all there is to it.

[Last Updated February 10th 2017]

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

Project TD - Day 7 update - Requirements Planning updated



Project update.

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

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

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!

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!