Good Problems

As we hurtle through the beginning of this year toward our release date, I'm forced to contemplate the challenges Dyn-IT will face after launch.  All startups face the same administrative challenges: setting up legal entities, organizational infrastructure, funding, project management, budgeting, evaluating costs, online infrastructure, etc.

All businesses also have some type of marketing plan (even if that plan is not to market).  You have to have some way to attract attention and make your product or service desirable.  What happens when marketing organically starts happening for your product before you attempt to generate it?  This is what is known as a "good problem." 

At Dyn-IT, we seem to be having a rash of good problems.  Let me give you a little breakdown of the past 12 months:

• In March of last year, we started writing software for a startup.  The company never went anywhere, but we gained an amazing jump start toward the idea of EdgeVault™.

• In late September, we received an offer to work with a group of former co-workers to develop an application for their startup.  This also did not work out, but we put in a good deal of work and got ourselves that much closer to our goal.

• In December, we were approached by a company that wanted to build a new software platform.  Not only did they come to us with an idea, but also a customer base just waiting for a new platform.

• In January, Richard presented at the EPIConference.  As a result, we have had a steady stream of interest in EdgeVault™.  This totally blows our mind each and every day.

• Now it's late February and we have a goal in sight, clients lined up, and a launch date in mind.

We are extremely grateful for this, but I feel its important to point out that we have tasted our share of failures to this point.  Each time we learned valuable lessons that propelled us onward.  Every business owner will face their share of failures.  For those opportunities, I offer you the words of Ray Kroc:

"Press on.  Nothing in the world can take the place of persistence.  Talent will not; nothing is more common than unsuccessful men with talent.  Genius will not; the world is full of educated derelicts.  Persistence and determination alone are omnipotent."

Now we only have to live up to the hype and reputation that is building!

About The Architecture

Good Morning!

My business partner, Adam, asked me about the basic architecture of our application.  I proceeded to explain MVC, from an operational perspective.  Not how the code is organized, but how the operation of the application works.  How actions begin with the user, cycle through the system, and come back!

So, here goes...

• When the application loads up, all the js are loaded, and the menus
• So.. When you click a menu item. You run a public function in a name-spaced JavaScript file. An example would be clients.js. (clients.load)
• clients.load hides whatever is on the screen and fetches the index page for clients.  It does that by calling a URL, and post the response to a div on the page.
• All URL calls end up in the routes table.
• Thats defined in the routes directory in the application code.   (Web.php, I believe.)
• The route for /clients gets sent to the resource client route entry.
• Which goes to the client controller. 
• ClientController.php is in the controllers, and that particular endpoint triggers the show call.
• Resource routes have a standard base set of calls it handles. (Table is not standard.... That is why it has its own routes table entry.

Anyway... If you look... The way things work is that a user action:

1. triggers a JavaScript function, 
2. which calls a URL, 
3. which gets routed to PHP, 
4. which accepts the call and returns, 
5. either HTML or JSON, depending.

Several loops can happen... Then it all waits for the user to start some other action.

Notable exceptions include:

• Tables loads:  All table loads (/table) happen as separate cycles, and return JSON.  This is so the table load can return a single page, and can request sort, filter and page changes without redrawing the table.
• Select-list loads:  Where select-list options are either volatile, or long, the select list load is done as a separate (/selectlist) call, allowing for filtering.
• Table headers:  The table tool we're using requires the data to be mapped in the JavaScript, and we do this by attaching JavaScript blocks to the index page HTML.  
• Our application is multilingual at the user level, so only the server knows what language the header label should be in. 
• Some of our screens are user-configurable, so the table layout is only defined at run-time.

Adam expressed a concern about whether this was proprietary, and whether we should even do this as a blog post.  I said no... not only is this the proper way to do this kind of thing, but anyone who is not using this methodology isn't actually building a web application... Just a series of pages!
There are no secrets here... we even include the technologies we're using on our website:  Laravel and jQuery

Compromising With Your Platform

I don't like compromise.  Especially with my platform.  The whole idea is that, as a developer, my work stands above the competition with better ways to get things done.  Faster, smarter, more secure.

But, if I'm using a framework, I'm suddenly restricted by what I can do.  I either have to change my design concept to fit in the framework, or I have to bend the framework to my will.  Oftentimes, I can get the desired result, but I really HATE it when I can't get it to give me what I want.

Using a framework suddenly makes accomplishing my goal harder, rather than easier.

So, using a framework can make your project easier to develop up to a point.  Once you pass that point, using a framework can challenge you.

Don't compromise.  Force that framework to do your bidding. That's why its there.  And if time constrains, never accept your compromised design as a final design...  Plan to move to your original concept at some point in the future.

If you compromise on your design, then your design is compromised.  Keep that in mind.  That is not a word with two different definitions... that's a truism.

Development Timeline and A Developer's Axiom

Development Timeline

Software projects, like movies, are never finished, they're just released.  But unlike movies (unless you are George Lucas) software can be updated!

I write that, to write this...  The recombination exercise is completed, and the development team here at Dynamic Iterations is now writing new code to finish the initial feature set for EdgeVault.

And, that feature list is set.  Version 1.0.0 will have the Document Manager, the Contact Manager, and two components of the communications module, namely internal chat and email.

The bug reporting module will come out in an early future release, which we will be doing often.

Our Beta Testers and early adopters will have priority in deciding what features are needed, and which existing features can be improved.

Developer's Axiom

 Just because you can do a thing, 

doesn't mean you should!

Our customization effort includes form-building tools that involve using draggable screen elements to define a blank form.  This is also used to do the contact module designer.  Heady stuff, and we put some hours into getting it just right...  we couldn't find a plug-in that did what we wanted, so we made our own.

There was so much time invested in the draggable plug-in that I wanted to use if for other things, too.  In this circumstance, for the assignment of roles, users, tokens, etc.

But after the conference, after talking to people from hospitals, large practices, and other service providers, I realize that scalability, so much part of what we're building here, is going to kill this drag-and-drop interface that showed all the users in the system.

A visible screen element for each of up to several hundred users is  the very definition of cool and unusable.  We're talking Facebook Business Manager bad.
So, as cool as it is to use, when dealing with 6 users, 2 departments, 4 roles, and so on, when theres 200 users, 14 departments, and 26 roles, its unusable crap.

Oh well.  This is how software development works, and often, the simplest method is usually the best.

Lessons from the Heathcare Security Conference

Good Morning!

Its Monday morning, and all is well in the world.  The sun will be shining, once it rises, the birds will be chirping, once they wake up, and the first cup of coffee is already delivered!

Had a fascinating weekend with fellow Healthcare Information Security professionals, discussing the legal, technological, and professional issues surrounding the constantly changing landscape of Healthcare Security, HIPAA, MACRA, and so on.

Regulations, Policies, Procedures, Reviews, Breaches, Assessments, Analyses.  Lots of information thrown about... all of it critically important.

An important change to the rules is that the mandated "Business Associate Agreements" that are required of business associates of "Covered Entities" (Physicians, Hospitals, etc) are now required down-chain, through technology providers, hosting services, etcetera.  Anyone that ever hosts, moves, or otherwise touches the secured data must be contractually connected to the Doctor or Hospital that collects the data from the patient.

This is a new requirement, and as it turns out, not all cloud providers are up-to-date on this.  Because of this, we've had to change our deployment protocol for EdgeVault.  We're going to have to purchase application hosting from a different provider that originally intended.

Our original choice for this was attractive because of the low-cost for an initial deployment, and the seamless scalability.  That allowed our deployment plan to include a separate instance for each client that desires to resell their configuration, as well as a retail instance that Dynamic Iterations would manage directly, for Single-Client customers.  (That may be a little inside-baseball... but if you want to know more, feel free to reach out.  we love talking about our architecture!)

Now, with this change, we're going to incur a much higher initial-deployment cost for instance  deployment, but will be getting similar buck-bang.  So, we are able to turn the problem into a solution, by adjusting our architecture to support multiple reseller clients on a single server.  Now, we can have everyone be in the same universe, and can scale upwards without limit.  If we really get into a resource pinch, we can engage load-balancing solutions, but that would be at a much hire level.

Also, by making another minor change, we can create "core clients", too.  So, as a consultant asked "how many levels can your architecture support?"  we can now say "Yes!"

In conclusion, or TL;DR:  A architecture challenge, analyzed properly, results in a solution that actually INCREASES flexibility.  TIAGT!