NextCloud Docker Tutorial – Part I

Some time ago, I went on an adventure to try out NextCloud.  During my adventure, I struggled with getting certain aspects of NextCloud working and it took a bit of reverse engineering and a lot of research to accomplish what I wanted successfully.

That is to have a NextCloud instance running in Docker, serving my friends and family! Sneak peak, I’ve been running this since July of 18 without any issues!

If you aren’t familiar with NextCloud or Docker, I suggest researching both technologies, before reading any further.  Especially, Docker since this article is going to assume a basic understanding of docker and docker-compose.  But since you are here I am betting that somewhat what familiar.

The only prerequisite is for you to have Docker installed. I’m not going to into details on how to this since you can run docker on OSX, Unix Systems, and Windows. There are plenty of tutorials out there for all those different platforms. For reference, I will be running Ubuntu Server on an old mac mini 🙂

There will be a series of posts that describe how to get to a production-ready instance of NextCloud and have it be secure, maintain backups, and how to approach upgrades.  Below is the first post aimed at getting you up and running for experimenting.

Continue reading “NextCloud Docker Tutorial – Part I”

Xamarin.Forms Plugin – Unobtrusive FluentValidation

Xamarin.Forms Plugin – Unobtrusive FluentValidation

Background

One of my all time favorite libraries is FluentValidation, Jeremy Skinner has done a great job at producing a library that is easy to use and just works.  Whether it is trivial validation or complicated databases access validation, FluentValidation has the means to get it done; while keeping your validation away from your view.  I won’t go into depth on why one would need/want to separate validation from a view in this post, but I might make another post in future describing in detail why that is important.

This post will assume a basic understanding of MVVM and ASP.NET’s MVC Framework with a little common knowledge of javascript.

The Problem

During my expedition as a Xamarin developer, I’ve seen and tried many different forms of validation.  Some were great and some were just good, but they all seemed have different approaches on when or where the validation gets triggered.

From my experience the best user-interface one can offer when validation is a small and effective means of communication.  Not multiple popups with fancy emoticons of sad faces.  People already don’t like to click on their phones (just look at the most popular apps, they just scroll), so why force them to click an ‘X’ or an ‘okay’ button?  Just tell the user what they should do to correct the form and move on.

The Solution

So one night I decided to blend what FluentValidation.MVCX has to offer with Xamarin.Forms.

Enter the first Unobtrusive FluentValidation Plugin for Xamarin.Forms!

Now this plugin is built on top of the latest FluentValidation NuGet published version.  There isn’t anything that is specific with this version, just needed a starting place. If you need an older version, please let me know and I’ll do my best to support older versions.

Check out the code on GitHub and get the latest version from NuGet!

 

Take care and have a great day!

Cost of Not Having Continuous Integration & Deployment

No really, hear me out for a minute.

By now you’ve heard the terms CI & CD and that it’s the greatest concept since the espresso.  So as any natural and curious developer would, you began trying to understand what it is all about and how you can look like a superstar to your bosses and colleagues.  But this proved to be an extremely daunting task because you don’t control the product/project.

In reality it is suppose to be a daunting task otherwise it would be caked into a project for you.  Lets face it every project has separate and certain needs and trying to create a mold around that would only add to the complexity of the problems.

Nevertheless, I’m here to informed and cheer you on as I believe anyone can achieve CI & CD with a little perseverance!  The hardest part of this won’t be doing the work to get the bits flowing, but to convince you boss(es) and colleague(s) that this is a NEED not a nicety, so that they purchase the tools or allow for the time.  So I’d like to help you make the factual case so you can focus on what really matters.

I’ve previously gone through this process and was successful at the CI & CD and the selling to the “higher ups”.

Cost of Manual Steps

What do business people care about the most?  A good product? Yes.  Happy customers? Hopefully!  Enthusiastic employees?  Of course!

But at the end of a day, they care most about the bottom line of the business.  Therefore, we must make that our target when selling the process to the right people.  I’ll use a real world example that I’ve been apart rather than make something up.

Let’s say you are working at a company that has an established product and “process” that has been “working” for 10+ years.  Why would you ever want to change it?  Well when you start to break down this process you begin to understand that it doesn’t work as great as it could.  The “higher ups” believe the process hums along like a Hellcat Supercharged 6.2 Hemi, but its more like a MOPAR 2.2L I-4.  This is because there are a few select individuals that actually know how the 2.2L runs and if they are out or no longer with the company everyone is left scratching their heads.  If bad enough the company burns the entire team’s time just to get this process re/started.  But since “Frank” always needs his report, the select individuals continually added Gorilla-Tape to the 2.2L, which gets everyone over the hill (for now). 

Usually, this means that the team ignored Industry Standards and “just made it work”.  Which eludes that there the one or two individuals that have “tribal” knowledge on how it works.  Which then leads to an individual having to do 1-10 manual steps just to get the engine started, rather than turn a keep.  And if you can not get a hold of that individual on their vacation then your company cannot produce a product.

Starting to see the problem yet?

Not quite?

Yea but the cost is too much to swallow because we don’t know what it’ll take…

Okay, lets talk some numbers to put into perspective.  Lets, take Bob who is a Quality Assurance Senior and is currently the person in charge of testing and deploying the product out to the customers.  Bob makes 65K a year, which means he gets paid 31.25 (65000 / 2080) an hour.  A mediocre salary for what Bob actually endures on a day-to-day basis, but that’s not the point here.

Now the developers have notified Bob that they’re work is “checked in” and ready for testing.  So Bob begins the process of creating the necessary bits to test with; however, the first step takes about an hour.  Until now, no one has ever questioned “WHY?” it just how it was.  So now Bob waits an hour (31.25 paid) just for the bits to be ready.  Once that is completed, Bob has to then install the necessary bits on remote machines to simulate what is in production; however, Bob knows that this is a joke because the QA machine is 1/18 of what a production machine is capable of.  Because of this it takes Bob about a half hour to install the bits anyway (46.875 paid).  Mean while, the developer realized that something was left out by accident and informs Bob that he’ll need to do another “build”.  So Bob obliges and starts the process over again (93.75 paid).

Up to this point the company has just paid Bob ~100$ for waiting!

Lets stop and think about what this means.

  1. It takes roughly an hour and a half to go from developer to something testable (and that’s if the process doesn’t break down, which it will).
  2. Bob isn’t the only person waiting on a “build” to finish, so the additional analysts’ salaries should be included in the current paid amount.
  3. Obtaining multiple builds a day is extremely time-some and painful.
  4. The business spends a lot of money waiting.

Think about an entire year.  Let’s say a team does an average of three builds a day. That means that Bob is being paid 140.625 (46.875 * 3) a day to complete a “build”.

  • Weekly: 140.625 * 5 = 703.125
  • Monthly: 703.125 * 4 = 2,812.50
  • Yearly: 2812.50 * 12 = 33,750.00

    This is if everything goes perfect, which experience tells me with this kind of process it never will!

This is just one person’s cost to wait to be testing.  This doesn’t include the developer(s) who are waiting on feedback from the items Bob is trying to test.  Now think about scaling this current process out to a team double, triple, quadruple the size.  This is in-deterministic equation since there is no possibility to predict the future!

What Does This Mean?

It means that you need Continuous Integration & Continuous Deployment, unless your company likes throwing money in the wind!

Pretty accurate when you think about it isn’t it?  Why is this important for you the developer?  Well think about the money that their paying Bob to sit around and wait, if Bob could improve this process he has a card in his deck to catch some of the money on his next review!

Challenge those around you how important it is to “pull a lever” and have a testable product.  In the 21st Century there is no reason to be waiting for code to compile for an hour and installations to half that time, let alone having a human manually execute all these tasks!

Now there are a plethora of options when designing a Continuous Integration &| Continuous Delivery system.  Personally, I find it more beneficial to strive to use current Industry Standards for you frameworks.  This way individuals that come behind you in another 5 years won’t be cursing your name every 15 minutes.  Nevertheless, strive to have a prototype running when you go to pitch your plan to the necessary individuals.  People are naturally more visual and makes presenting your case easier, in addition remember talk NUMBERS, NUMBERS, NUMBERS.  If you can show that a process taking over an hour can be automated down to even 20 minutes, you can prove how much money the company will save and how much more work will get done throughout the year!

 

Till next time!

GINA, The Smart Coffee Instrument You’ve Always Wanted by GOAT STORY

Gina Overview

Gina is the first smart coffee instrument that is not only artfully engineered, but also includes everything you’ll need to make the perfect cup of coffee.

Paired with its mobile app you have unlimited power and configuration options, whether its a pour-over, immersion, cold drip, or a combination of them all!  In addition, using the built in scale and app combo you’ll never be guessing how much coffee grounds you should be using!

Whether you are a coffee Connoisseur or just a regular Joe 😉 Gina sure won’t disappoint!  Check out GOAT STORY’s campaign over on KickStarter to get more details!

KickStarter

Hooked On Twitch – V8.9

Recently Twitch made an update to their API that requires all clients to authenticate for every request.  Months before they made the switch they sent out a notification to all registered clients suggesting to perform the update.  Unfortunately, life gets in the way sometimes and I missed that deadline. 🙁

Nevertheless, version 8.9 is available today in Google’s Play Store and address the issue.  So have fun viewing and stay tuned for further updates coming down the pipeline!

Check it out here!

Continue reading “Hooked On Twitch – V8.9”

Automated Build Processes

Over the past few weeks I’ve been diving into automation in general and wanted to share some knowledge.  Soon I’ll be writing up an article that dives into versioning and the importance of combining these processes.  Anyways…

Tasks that are repeated continually should be easily automated to completion.  That’s a pretty hard statement to argue against.  Grab a cup of coffee and lets look at some pros and cons of automation, specifically how you build and deploy your products.

Pros:

  • Audit trail
  • Removal of human error
  • Faster
  • Part of development process
  • No “tribal” knowledge needed

Cons:

  • Extra development time

Now Pros are usually easier to come up with and I could continue the list on another five to ten bullets, but if you’ve made it this far you know the benefits of an automated build and release process.  One may argue that there is no accountability when automating something but I (and many others) argue back that is the furthest thing from the truth.  Having something laid out in source code is the greatest accountability one can reach.  So long as the changes are kept track of.

Types of Build Processes

Over the past few months, I’ve been exposed and developed multiple strategies for a build processes. Each one seemed to be written with different set of tools than the last because of that “one” thing that made the process unique.  And that is okay!  Not every application will be built the exact same way.

Lets take a mainstream product and break down a particular build process. The product has a client front end (mobile or web) and the front end clients talk to a web service that we’ll call the “back end”.  What you may not realize at first but all 3 of these “ends” may need different build processes because they are all targeting a different endpoint.  Mobile especially will have different endpoint if you’re targeting more than one platform.  Therefore, you maybe asking yourself: “Well how can I create a one and all build process?”.  You shouldn’t. Really, don’t try and make a overly complicated build process that is resilient to change because in 2, 5, or 10 years when you’re ready to make a change in the way your business works; you’ll be regretting the decision you or another developer made.

Within the past month or so, I’ve managed to create a flexible build process for two mobile apps, five different web services, and five or so command line utilities.  These build processes range from simple to complex (thanks to Apple).  However, all these build processes were created using PowerShell and no more than 25 lines.

PowerShell for building & automation

We all know PowerShell is great and the answer to most DevOps tasks.  In addition, it can be a great tool for building your build and deploy automation because it is so flexible and runs anywhere.  No really anywhere, even Linux (now).  At first, this journey may seem overwhelmingly difficult to tackle but the key is to take it one step at a time.  For example, if you find yourself right-clicking in Visual Studio to publish a web site to a folder on your machine; you could be saving so much time with automation.

Did you know you can use “MSBUILD” to build and execute that same publish steps with the following:

& 'C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe' "$pathToProject\ProjectFile.csproj" /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=Production /p:VisualStudioVersion=14.0

Really that’s it.  Since, publish profiles are part of a solution and project that means any changes to “Production” are caught in your source control management tool. This is where your accountability comes into play!  Next add some PowerShell to zip the folder up and drop it anywhere else would be as simple as:
Add-Type -Assembly "system.io.compression.filesystem"
[io.compression.zipfile]::CreateFromDirectory($publishedLocation, $DeployDestination)

See how incredibly flexible that is?!  I bet you haven’t even taken a sip of coffee in a while!  Not only can you accomplish file copies and zips using PowerShell, but you can create a publish profile that will complete a Web Deploy for you! All you have to do is change the name of the PublishProfile you supply in you’re script (and maybe some credentials).

Distribution

If you or your company is anything like me and mine, the developers don’t put anything into production.  Not only does that prevent tribal knowledge for leaking in but it also ensures documentation is correct and accurate.  However, distribution can easily be automated using PowerShell or the alike.  Once you’re able to do these two things, you’ve officially achieved the ability to have Continuous Integration and Continuous Delivery.  Then all you need is something like JENKINS, TeamCity, or any other flavor that comes around and you just need to drop your PowerShell scripts in place and you’ve successfully automated your build and distribution process.

 

Till next time!

MSBUILD vs. Web Deploy & Automation

So you’re here, probably on your third or fourth cup of coffee and struggling to automate the deployment of your web site(s). Don’t worry you’re not alone, I alone went threw an entire box of K-cups by the time I finally found the answer! You probably started out with using MSBUILD and the “DeployOnBuild=true” parameter for your publish profile and at first all was great! Your files were in the right location (maybe) and the site was up and running in IIS with no issues, minus the whole authentication hole you created (our secret). So you tried your mad Google skills and stumbled upon Web Deploy which looked extremely promising; but long story short, it fell short or your thinking there has to be a better way of doing this!?!?

And your right there has to be a better way! But first lets understand what MSBUILD and WebDeploy are…

Continue reading “MSBUILD vs. Web Deploy & Automation”

jQuery Noty & ASP.NET MVC

I recently released a project I kept internally into the wild.  This is a plugin has been hugely successful (personally) and the feedback given to the users is incomparable.  There’s no more excuses for us developers in not giving our users the best possibly experience(s) they can have with our products.  Thus, I introduce NotyMVC; a simple little library that integrates the notorious jQuery Noty with ASP.NET MVC’s framework.   As a developer I simply use the provided extension methods or the javascript method to produce a jQuery Noty notification.

ASP.NET MVC

After adding the Nuget Package, you’ll notice in the root Views\Shared folder there is a new file named “NotyNotifications.cshtml”. This is the entry point we use to create the notification bubble.  What you need to do is add this to your preferred (~\Views\Shared\Layout.cshtml, aka “Master Page”), using @Html.Partial(“NotyNotifications”);

 

Then from your controller actions you’ll simply use an extension method to create the notifications. For example,

public ActionResult Contact(ContactViewModel model)
{
...
	return View(model).WithNotification("There seems to be an error", alertType: AlertType.error);
	// OR
	return RedirectToAction("Index").WithNotification("Thank you for contacting..");
}

The extension works off ActionResult, so any redirect, view return, or new type (derived from ActionResult) that comes out will work with this extension.

Think of another use for this or something similar?  Contribute to the GitHub code here!

Till next time,

Have a great day!

SignalR, Autofac, OWIN, and MediatR — How to play nice

If you’re finding this post odds are that you’ve found some of the latest greatest (as of now) tools and concepts storming through the .NET world, but you’ve stumbled upon something that just doesn’t seem right.  Congratulations, you’re a developer now!  But seriously lets get to why you’re here.  This post will be an ever-evolving documentation of the issues I’ve stumbled upon and hope it helps you in quest to greatness!  Grab another cup of coffee and lets start stirring up our code.

OWIN Integration

So OWIN (Open Web Interface for .NET) is all the craze for ASP.NET web developers and it is for a good right.  Not to get into the specifics of why you should use it and the whole mantra behind it, just use it in any new applications.  So that is were I was a few days ago, I started a new application for fun and began integrating all the normal NuGet packages I did two years ago (been a while for web development).  I quickly learned how much I was left behind; it was time to put some mud boots on and begin digging around.  Lets see what was dug up!
Below is the basic of a Startup class for OWIN.

public class Startup
{
     public void Configuration(IAppBuilder app)
     {
     }
}

Everything we do to setup our site is basically an extension method off IAppBuilder; which allows us to do some pretty neat things. So starting from the top, we’ll want to register SignalR and we’ll end up doing the simplest registration to get it up and running:

public void Configuration(IAppBuilder app)
{
     app.MapSignalR();
}

Pretty easy right!

Autofac & SignalR

Awesome, now lets register Autofac as our dependency resolver using OWIN. Majority comes from Autofac’s documentation on SignalR found here.

public void Configuration(IAppBuilder app)
{
     app.MapSignalR();

     var builder = new Builder();
     //For us lazy people:
     builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());

     var config = new HubConfiguration();

     // Register your SignalR hubs.
     builder.RegisterHubs(Assembly.GetExecutingAssembly());

     // Set the dependency resolver to be Autofac.
     var container = builder.Build();
     config.Resolver = new AutofacDependencyResolver(container);

     // OWIN SIGNALR SETUP:

     // Register the Autofac middleware FIRST, then the standard SignalR middleware.
     app.UseAutofacMiddleware(container);

     app.MapSignalR("/signalr", config);

     var builder = container.Build();
}

Looks good right? In fact it does, so you run it but your not able to access your SignalR hubs.   Getting an error with resolving something like:

“Microsoft.SignalR.IMessageBus messageBus can not be resolved”

WHAT IN THE WORLD!?!? Yea very bizarre issue, but that’s how you found this post!

The issue is actually with our registration calls (go figure).  The culprit is (drum roll)…

builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());

That’s right our awesome AnyConcreteTypeNotAlreadyRegisterSource is causing an internal conflict with SignalR’s resolver.  Now I’m not sure (yet) why this is happening under the hood, but I’ve managed to figure out a solution.  AnyConcreteTypeNotAlreadyRegisterSource has an overloaded parameter that takes in a delegate which can solve this issue:

public void Configuration(IAppBuilder app)
{
...
     builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource(TypeRegistation));
...
}

private bool TypeRegistation(Type type)
{
    if (type.FullName.StartsWith("Microsoft.AspNet.SignalR"))
         return false;
    return true;
}

That’s the ‘magic’ to make it work. When ever Autofac tries to resolve a concrete type, it will pass the type through this method and expect a boolean on whether or not it may instantiate that type. Since, we do not wish for it to resolve anything with SignalR, we simply check that FullName starts with “Microsoft.AspNet.SignalR”.

I hope this section helps save some hair in the world!

Till next time!

Microsoft & ETL (SSIS)

So this post is a bit different as it doesn’t relate to mobile or web development particularly, but is more of a conceptualization and analysis.  Recently, I’ve been tasked to move and summarize large sets of data; we’re talking tens of millions of records, resulting in hundreds of gigabytes of space needed.  At first I took a rudimentary approach which involved in writing a console app in C# using ADO.NET.  I won’t even going into using an ORM (Object Relational Mapper) like Entity Framework, lets just say: they’re not efficient in this scenario.

Continue reading “Microsoft & ETL (SSIS)”