Ralph Krausse

Ralph Krausse

JACKSON POLLOCK USED A BRUSH, I USE CODE.

BECAUSE DEVELOPING SOFTWARE IS AN ART.

Using Continuous Integration/Continuous Delivery to create enterprise and mobile applications.

Download Resume

About Me

Father, husband, entrepreneur, engineer, skier, space junkie, dog owner, Marine.

How I think

I wanted to share a bit about how I see myself. Many engineers classify themselves as some sort of expert. A C# expert, Angular expert or whatever expert is the current trend. With technology changing quarterly, your expertise of the of the day may be less important tomorrow.

Therefore I don't label myself as that. So what am I? I am professional learner.

In my opinion, it is more important to understand good programming practices than really getting everything about a certain technology, in fact, you can't. I google that information and do. One needs to understand the business requirements of a project and figure out how to solve them.

So if you need a Service Bus, Angular, NGRX, Repsonsive Design, SDLC, a whatever expert? Then you do not want me.

  • Do you need someone who can understand the project should use a Service Bus because the project will grow so it will, one day, need scale out and be a distributed sytem?
  • Do you need someone who can understand the project should Angular because it is a mature platform and common code could be used with Nativescript to create native mobile applications?
  • Do you need someone who can understand the project should NGRX because the application will be complex enough to require a state machine? Or not.
  • Do you need someone who can understand the project should a Repsonsive Design so that it can be used on different sized screen and devices?
  • Do you need someone who can understand the project should take the time to include a Software Development Life Cycle so that CI/CD can be employed, stakeholders can view progress, the development effort can be measured?
  • Understanding the technology isn't enough, you must understand the what and the how to couple them together.

It isn't that hard to write a C# application to access database data. But when would one use a repository pattern? A unit of work pattern? Dependency Injection? Why would one use Interfaces? Would your repository expose IQueryable? Where and how do you save added entities? Where does your Save() live?

So this applies to SOA, WebAPI, NodeJS, TypeScript, Azure, Patterns... One can go on and on. Do you want someone who can forsee how that one technology or combo of technologies can solve your problem or avoid a problem, then that is me. I think research, reading and technology videos (Udemy, Pluralsight) keeps you abreast of what is important because once you finish your project, chances are, that something new is out there that makes, at least in part, your project - obsolete.

This isn't my resume shown in a different way, I have focused on some current projects that I felt was worth talking about. You will only find newer projects, because honestly, who cares what I did 5 years ago?

Projects

SDLC Environment

Software Development Life Cycle

I decided that it would be worth it to spend the time to bring in a SDLC.

Source Code Management

We were using TortoiseSVN and well who doesn't love a centralized source control system? It's slow, painful and not very team friendly. So…. I guess me, I don't. I brought in GIT, installed GOGS, a freeware self-hosted git service, and installed Jenkins. I was able to convert projects that I used often to build automatically using MSBuild and MSDeploy. So now at the click of a button, I am able to build one or more projects and deploy them to test or production.

Kanban

We are using Assembla for bug tracking. It was Kanban 'like' so we started using that to start moving in the Agile direction.

Azure/DevOps

We were still missing parts, so to complete it, I suggested to our CIO we replace our VMWare environment with Azure on Prem. We were using some Azure in the cloud but it did not make sense to me that we have a completely different environment on prem. Then we replace Assembla with Microsoft DevOps and bring that on prem. This way we can have full control, in an organic environment. We would have projects define in DevOps where would could have a wiki with a project explanation, server information, configuration information, etc – basically a central place where we can keep all the information about the project, your one source of truth. Then DevOps has a great Kanban board that is integrated with other parts of the system. We use the repo DevOps provides to replace Gogs. Use Azure pipelines to replace Jenkins so we do not have to manage that. Add unit and system testing using DevOps. Allow for pull requests when we have code changes. And allow someone other than a developer to deploy a release to production so that the engineers do not have access to production, which is a common request. The next steps are to migration to .NET Core from .NET for many reasons but one main one is that it integrates better with DevOps. Also I wanted to, for cost reasons, deploy our WebAPI to Linux instead of Windows and lastly, move this ALL to Docker containers.

CI/CD

Doing most of that gives us a usable, showable and standard way to do CI/CD.

Microservices Environment

Created a microservices environment where legacy and greenfield applications can call services.

MSI's internal applications (still) run off of mainly one, monolithic webform application. Seeing that future development had to change, I proposed an ecosystem of microservices (before that phrase was coined) and full APIS. To support this, I create an environment to do that so that greenfield projects could be loosely connected.

The host is a service based class that dynamically load DLLs based on meta data. In development/debug mode, it is loaded via a simple windows application so it can easily be attached to the processes while in VS IDE. In test, staging and production environments, it is loaded from a window service so that it automatically runs when the machine is rebooted and runs quietly in the background.

Once loaded, it reads in a json file and enumerates the services (DLLs) to be loaded. To simplify the process, with each DLL, it creates an AppDomain, loads the target with Assembly.LoadFrom(), then using reflection, reads the exported types to ensure the DLL was written with specific interfaces. Once confirmed, find the initialization method in the loaded DLL and invoke it.

Each DLL is responsible to do it's own work but all have a required container that inherits from TaskContainerBase which exports

This allows the TaskService to validate the DLL and can invoke Start() or End() on it so that it can be independently developed, and only knows how to run it or stop it.

After the DLLs are loaded, it monitors the configuration file, more specifiable an enable flag (true/false). If set to false, it will unload the DLL (allowed because it is in loaded into that AppDomain) and will load any new DLLs. This allows me to load and unload any combination of DLLs at runtime without effect other running DLLs. I did not want to be forced to stop the entire service just to upgrade one DLL for instance.

This entire environment allowed us to scale horizontally. Assuming you needed more horse power, we could just add another service, configure the endpoint and lets other applications access it. It was a great solution to scaling vertically.

I ended up creating a few WCF and WebAPI services. Again, in the end, the service has no idea what the service does, it just knows how to load, start and stop it. It was up to the engineer to user the correct base class/interface, then write their own code. We ended with microservices like an email and a sms service, and more WebAPI that dealt with connecting an overseas immigration system to our own and a service that allowed for customized Excel Reporting.

This changed the mindset from a monolithic software development to a services/api development environment. One did not have know how to send a text, you just called an API now. One did not have know how to send an email, again, you just called an API now.

Immigration Site

Site spanned in Azure and OnPrem

Earlier I mentioned that MSI main technology platform was WebForms. While I applaud Microsoft's attempt of bringing in C# developers in the web world (and it was pretty impressive), I failed to embrace it. So I first brought in AngularJS and I did like it. Then Angular2 was born. Ignoring all the love/hate talk out there, I adopted it. I figured that it would be supported for along time (I assume) since Google was pushing it. Also, and I will speak to it more later, but there is a company called Telerik that was bring out a way to write native mobile applications using Angular. So sold!

I was hired to bring in best practices and new technology so I did. I wrote MSI's public facing Visa Immigration application which was in Angular 5. I also wrote the back end to it using C# WebAPI's. It was to be in ½ in the cloud, ½ on prem.

For development, I was able to leverage the TaskServer (See WebAPI and Microservices Environment) to host the WebAPI bypassing IIS for performance reasons (it does still run under IIS on test/prod). The cloud side would house the Angular 5 application, 2 sets of WebAPIs. I used Entity Framework Identity for token based authentication. Another set of APIs would communicate with the OnPrem APIs since we needed to integrate with other services and data.

There was a need to change and update immigration destinations, fees, etc on the frontend. Instead of having me update the code with new data when needed, I created a Excel Spreadsheet that the Immigration team would fill out and then import using another application (another Angular 5 application) that then allowed them to preview the data and publish the data, which would make it available on Production. Even though updating the main application would have been easier, in the long run it was worth it to take the time to write an import application so that the Immigration team could manage destinations, content, fees, etc instead of me doing that work on their schedule.

Skills

  • Angular 2 - 7
  • AngularJS
  • C#
  • Azure Storage
  • Jenkins
  • Azure Cosmosdb
  • Entity Framework
  • ASP.NET Core
  • OAuth
  • NGRX
  • ASP.NET
  • SQL
  • Nativescript
  • Kanban
  • ASP.NET MVC
  • CSS
  • Entity Framework Indentity
  • Azure App Services
  • Azure SQL
  • WebAPI
  • Microsoft DevOps

Military Service

United States Marine Corps (1988 - 1993)

  • Served in the 1st Persian Gulf War
  • Honorable Discharge from Military Service – Rank Sergeant
  • Good Conduct Medal
  • Navy & Marine Corps Achievement Medal
  • Sea Service Deployment Ribbon
  • Navy Unit Commendation
  • Naval Arctic Service Ribbon
  • National Defense Service Medal
  • South West Asia Service Medal
  • Navy Meritorious Unit Commendation
  • Kuwait Liberation

Contact Me

Always interested in talking, projects and opportunities.

Email

ralph.krausse@consiliumsoft.com