Brady Clifford

Upcoming entries

2022-09-09T00:00:00+00:00

Its been awhile since I have journaled my experiences in my profession; 7 years running.

I am rededicating myself to journal atleast once a quarter. I have experienced many different technologies, patterns, processes, logistics over the past 7 years that I will start to document.

I will probably start on my series of posts regarding my companies team reorganization and Gen2 transition experience:

Conway’s law and how we decided to reorganize teams and management to align with a verticle instead of horizontal structure.
Importance of architecture and strategy decision records
Context mapping exercise - company wide (all disciplines) to determine the true boundaries, subdomains, core domains, etc.
Method to keep the context map current and accessible to all. This includes a single place to document our ubiquitous lanages per context.
Breaking about a monolith site and database into boundaries, not all at once, little by little
Importance of a Design System and Component Library
Compose micro front-ends into a homogenous site with BFFs and web-components
Break down buildtime dependencies between teams by embracing runtime dependencies
Implement anti-corruption layers between boundaries (both internal and exterinal)
Utilize a feature toggle system to perform A/B testing in production
Embrace events over APIs for cross boundary communication
No monolith database - embrace the duplicate data across boundaries paradigm - on the bounded context can access directly its database. All other access must be performed through APIs or events.

Some other experiences I want to eventually document by priority:

Finish my Marten usage experience journal entry
Importance of a company repo used to start new projects. Documents architecture decisions.
React and how to manage state without complex libraries like Redux - i.e. react-query
Zero bug policy
Breaking work down in to small, managable, incremental parts
Improving the SDLC process and integrating it into automation.
Integrating SOC and EDE audit requiremnts into the SDLC process without constricting incremental improvements
Shifting left with QA engineers, product managers and UX designers.
Story mapping and coming up with a delivary plan while staying agile - focus on milestones / goals, not individual stories and story points
GitHub Actions experience - sharing standards functionality with multiple teams and repos
Production Support and alerting - integrating with PagerDuty and a public status page site
Load and Stress testing experience - k6, kubernetes, reusing Cypres tests and pseudo services for 3rd party integrations
CloudEvents, Azure Functions, CosmosDB streams, Azure Event Hub and the Outbox pattern
Terraform + Azure experience
Integrating a demo environment
Integration a failover environment
Integrating with a 3rd party both at the API level and UI level - the good, the bad the ugly and how to mitigate risk through contractual tests
Distributed tracing with AppInsights & FullStory experience - how to ingegrate multiple AppInsight instances from micro front-ends
Home automation experience

Revamp blog

2022-09-09T00:00:00+00:00

Plan to re-create this blog into a React app demonstrating my abilities. Debating on using Next.js or Remix as a base.

Will integrate some of the micro front-end abilties and web-component isolations.

I want to also experiement more with webservice workers and progressive apps. I don’t have much experience yet with those two topics

Details to come…

Marten + Postgres

2018-01-20T00:00:00+00:00

I have finished up a project where we replaced the use of RavenDB with that of Marten + Postgres. The transition came from the issues we were having with RavenDB, maily its chaotic, random indexing process. We needed a more robust solution that not only resloved our index issues but also allowed us to mix our usage with that of a relational database.

Details to come…

My first look at HTTP/2.

2015-12-09T00:00:00+00:00

Great podcast by .NetRocks on the upcoming HTTP/2 with Robert Boedigheimer. The main browsers support it. Waiting for the servers to get up to speed.
Windows 10’s IIS already supports it. Need to wait for Windows Server 2016 release and will hopefully see it on Azure.

It is basically resolving the issue that we currently have how many requests a browser can do in parallel… 6 request at once seems to be cap with HTTP/1.1. HTTP/2 is opening up the flood gates. Not only will it allow for more requests in parallel, it also allows the client to ask for dependencies using a dependency map with priority weight.

The server also has the ability to send resources to the client without he client first asking. The server knows that client will need this Css file and this JavaScript file. Why not send it in the initial request? The protocol will now transmit using binaries instead of plain basic text.

With the issue of capped requests gone, Robert is suggesting that we don’t need to package up our Css and JavaScript anymore.
No more sprits in Css or embedded binary images. It is still important to minifiy, but no need to package and combine our resources. This brings back the ability for smaller files to be cached. If I change a single line in a large bundle, the entire bundle becomes expired. There will still be a need for compression and expiration. CDNs are still a plus.

Overall, you will see 5%-15% speed increase from HTTP/1.1 to HTTP/2 not taking advantage of the new features. Image the speed increase you can get once you implement the new features.

Listen to the Podcast.

My first look at Go Lang.

2015-07-25T00:00:00+00:00

Had my first look at the Go Lang. Went ahead with a small exercise and wrote a ball clock out of the language.

Overall, I am impressed. It seems similiar to Swift yet has its own glow. I really liked the ability to return multiple values.

Take a look at my solution on GitHub.

Using Components and Resolves in UI-Router States

2015-05-22T00:00:00+00:00

Adding to the Component Pattern in relation to AngluarJs and taking excerpts from this article: component-paradigm

Quick review… The importance of controllerAs and bindToController property in your directive / component. bindToController

In summary, the bindToController property helps in situations where we want to pass something to the directive’s isolated scope from parent component. When used, properties from isolated scope will be automatically bound to controller’s this.

The example below is referencing an inline template instead of a templateUrl in the ui-router state configuration.

$stateProvider
  .state('patients.patient.state', {
    url: /patient/:patientId',
    template: '<div state-patient></div>',
    resolve: {
      // ...
    },
  });

The problem with this is how do we inject our resolve data into the controller which is now not there?

Instead of injecting the resolved dependency data into the directive’s controller, load it into a service. Unfortunately I am not a fan of this approach. It feels too much like scope inheritance…

.state(''patients.patient.state', {
    url: /patient/:patientId',
    template: '<div state-patient></div>',
    resolve: {
        init: function($stateParams, patientResource) {
            return patientResource.init($stateParams.itemId);
        }
    }
});

For details on this pattern, see the article below. The examples are written in ES6, but the concept can be still be applied to our ES5 code base. model-pattern-for-angular-js

Note that this is one way of tackling this problem. I do not agree 100% with this approach but it does lay down the concept and possible alternatives.

Task Runners and Building our JavaScript Code

2015-05-07T00:00:00+00:00

No excuses now, every should be transpiling and building their web application. I put together a slidedeck that went through the whys and the benefits. Take a look…

I based my slidedeck on the presentation Peter Hunt gave back in 2014.

To summarize:

Spas are the best UX experience
Con is that the initial load takes too long
Instagram has 10 SPAs in their architecture
Reduce amount of HTTP requests & bytes downloaded
Bundling everything into one file is not the best approach2.5MB gzip bundled file is too big.
Utilize a module system to intelligently bundle your packages with a dynamic dependency map.

The 2 slides from his presentation that impacted me the most:

###Overall, I argued the need to build web front end code so one could:

Developers to mimic production on their own box.
- Developers are able to identify concatenation and minification issues before code is checked in.
- The build config is shared amongst all environments Prepares us for AngularJs 2 and ES6
Automated versioning of shared packaged libraries.
- Treat our shared libriaries like 3rd parties
- On check-in, build, package and version shared libraries deploying to local package repository like git. This speeds up the build process for the Spa and also removes versioning within TFS.
- Part of the build process can also incorporate the automation of generating documentation and demos. See how AngularStrap and UI-Boostrap and achieving this from their source code.
Utilize a package manager and a local rev. repository.
Automated builds of documentation and shared component demos.
Reduction and even elimination of Glofs and Glogs.
Reduce initial Spa loading time through intelligent bundling: use a module system and an intelligent dependency map bundling tool, like webpack.
Architecting our web application code so it is web server agnostic.
- Instead of loading 100+ servers with our web application files, we can upload them to one location
- Avoids the second hop to our F5 and web farm in our current architecture
- Brings us closer to a true micro services SOA architecture; separating the front end from the middle tier.
- Allows us to use redirection only for api calls. Don’t have to perform a browser redirect during login.
- An example of a server agnostic web application:

AngularAtom: Component-based Organization Directory Structure

2015-04-04T00:00:00+00:00

With the changes in AngularJs 2.0 coming down the pipe, many have started to prepare for the component-based pattern.

Dmitri Moore has a great blog around the AngularAtom proposed directory structure that addresses the component-based structure. Some of the takeaways for me pertaining to this article are I have summarized:

Components folder: all stateless components / services.
- A Components folder can have sub components
- A component has a component.model.js file and a component.service.js. The model contains the data while the service is responsible for getting, setting that data.
- Single responsibility per file standard. Does not place controller, directive and module within the same file.
- Component folder can contain a Data folder for specific JSON data files and related assets
- Each component or state folder can contain a i18n folder for resource localization
State folder: contains everything necessary to render the particular UI state
- Instead of placing all routes / states within a single route.js config file, they are modularized. Each state folder contains its own route config file with that specific route / state.
- Each state may contain one or more child states that, unlike sub-components, each define their own module. This is because each state, be it parent or child, is looked at as an independent citizen that can be added or removed at any time of the application lifecycle.
```
      1. 'phones'         // abstract state, can't be transitioned to
      2. 'phones.list'    // UI shows a list of all phones
      3. 'phones.detail'  // UI shows detail info on the selected phone
 
       |phones| // <-- abstract state that loads default layout
         /  \
        /    \
       /      \
    |list|  |detail| // <-- concete states that plug in their own content into the default layout
```
Layout folder: contains all partial files that support the application shell.
- Layouts are injected into the main app/index.html by the abstract states. Your public section, for example, may inject one layout (ex. public.html) from the app.public abstract state, with this the secure section may inject a completely different layout (ex. secure.html) from the app.secure abstract state.
Helpers folder: contains a collection of various utilities not specific to any component. Usually implemented as JS pure functions.

Summary of Dmitri Moore’s the folder structure below. For a full view of the folder structure, see his GitHub.

…[app-name]/ # application root directory |__app/ # container for all user-generated app code | |__components/ # stateless feature components | |__layouts/ # layout specific partials | |__states/ # application UI states |__vendor/ # 3rd party vendor client libraries global to the entire app |__config/ # app related configuration |__node_modules/ # 3rd party vendor node.js modules global to the entire app |__scripts/ # shell scripts like Glup tasks |__tests/ # e2e tests

John Papa’s style guide is similar to what the AngularAtom folder structure is suggesting; just isn’t as detailed.

Folder by Feature: create folders named for the feature they represent. When a folder grows to contain more than 7 files, consider creating a new folder.
Layout Folder: components that define the overall layout of the application; these may include a shell view and controller (navigation, menus, etc.)

AngularJs and the Component Pattern

2015-03-03T00:00:00+00:00

A few tips and a few standards related to using the component pattern with AngularJs. Highly suggsted to start writing your AngularJs project with this pattern in mind due to the migration path to AngularJs 2.0.

Don’t use ng-controllers; instead modularize your code into directives.
Reduce your reference to $scope. Instead use ControllerAs with vm.
Utilize the PubSub pattern; communicate between directives (components) with loosely coupled events.
Keep AngularJs 2.0 in the back of your mind while writing your AngularJs apps. http://youtu.be/uD6Okha_Yj0
For further Reference concerning these patterns, see the following post.

AngularJs Experience

2015-01-30T00:00:00+00:00

The AngularJs focus group gathered together at HireVue floor last night. The lead developer presented the dos and don’ts that they learned from their 2 year experience with AngularJs when they decided to implement it back in 2012.

To summarize, if you follow John Papay’s style guide, you should be good go. Here is Dave’s presentation from last night: http://slides.com/djsmith/how-we-made-a-mess-of-our-angular-app/#/