Saturday, July 16, 2016
Herding Cats, or Managing Complexity
Determined to find a rational web based development environment, something stable, that works, has support and is flexible enough to deal with future demands, as well has minimal html involved, I ended up using Angular 2 on a Meteor base.
Yes it is alpha, now rc, not yet released. That hasn't caused many problems, as I'm early and still banging out the basic structure and development strategy.
A few things I've figured out.
Yes it is alpha, now rc, not yet released. That hasn't caused many problems, as I'm early and still banging out the basic structure and development strategy.
A few things I've figured out.
- Javascript on browser has all the characteristics of multithreaded programming without the tools and api to deal with it. Once you get above a certain level of complexity it falls over a cliff, and your application can easily do the same. The frameworks such as Angular and React are an attempt, very good ones, at imposing order on the chaos.
- Tracking down timing and essentially race conditions takes hours of time, time I don't have. Squiggly brackets nested deep are the devils work.
- Angular 2 is quite remarkable in it's power and simplicity. I have found that if I have something that requires figuring out some deep in the weeds function of the framework or platform, I'm making a mistake. Back out of the hole, and I find that there is a two line call that does exactly what I need. The paths are well trodden, almost all the issues I'm figuring out have been already, so learn the framework. There are bugs of course, and a few shortcomings, but each release candidate seems to sort a few of them out.
- ngrx/store and /effects is very interesting. It takes the ideas of Redux, adds Observables and ties it all to Angular 2. The idea of Redux, having the state defined and stored, changed by dispatching an event, having reducers which are pure functions to change the state, is brilliant in it's simplicity. It is similar to an event handler in gui application frameworks, but different.
- It's power is in what it forces you as a developer to do. Start by defining any and all of the states your application will enter into. Each component will have different states, describing all the stages of fetching, waiting for, showing, editing the data. Each state gets set in a reducer function. This forces a level of simplicity, even the pure functions and the secondary effects get separated, again forcing you as the developer to break the process down into discrete steps that can be represented by a data structure containing the state. It seems repetitive; my mind is screaming at the almost identical functions, but keeping the simple structure makes it easier to find mistakes and bugs. And ngrx/store along with other redux implementations allow you to capture a step and return to it to sort out bugs.
- Observables are strange, confusing, wonderful and powerful. We tend to think of our applications as a point in time being represented on screen. Something happens, we react to it, getting to the state at another point in time. Observables describe a stream of data. The stream might have only one piece, or it may have many. My contact information for a customer streams forth from the data source, into an observable which is displayed. If there is a change from any source, the change flows the same way, showing the change on the display. That flow can be altered in many ways with the Observable methods. The flows go the other way as well; editing, keystrokes, selections, all the user input flows, is altered or used in some way leading to a change in some aspect of the state.
- All this stacked up with discrete state reducers and observables exposing the state makes for traceable flows of events and data that can be debugged and fixed. One state of each component is when there is no data, gracefully handled it removes the source of lots of bugs. Each error state can be defined as well allowing for graceful failure.
I've set some parameters for the application. Everything is autosaved. It is a design parameter that in any and all situations the user could leave and come back without losing data and easily getting back to where they were. The well defined states are really helpful here. There are some instances where some distinct confirmation is required; an invoice posted, sending something. That is a different action from saving the state.
A second one is that data entry is a pain in the neck. Some of it needs doing, but it should be only for situations where the experience and thought of the user is required. Otherwise the idea is to present the user with decisions that need to be made, data that needs to be entered, and a place or slate where the experience and knowledge of the user gets applied.
A third one is to whenever possible have the data structured and entered in a way that doesn't require distinct fields. Sometimes it is necessary, but that should be determined by the data and it's use rather than the application structure. Something entered once with care and verified, then reused by selection or other methods reduces the scope for error. The characteristics of our business is that much of the time careful data entry is impossible or impractical, so the idea is to choose times or contexts where careful data entry is done, the rest of the time isn't necessary.
I'm enjoying Material design, which is in alpha development for Angular 2. It makes it trivial to construct nice looking and smooth operating applications, and it enforces a certain simplicity and elegance that makes an application useful.
Subscribe to Posts [Atom]
