DEV Community: Austin French

Ideal Code, I can't today

Austin French — Wed, 01 Sep 2021 15:42:44 +0000

The real world, is rarely ideal

Today, I had to hack it. And I don't mean hammer on the keyboard to get a feature done. Nor do I mean "debug it until I make it", I mean, work against everything I think good, ideal code is. I mean, make something that I feel like it shouldn't be in a code base, part of a library until legacy code is updated.

Backstory

We have an angularJS application, running with jQuery, MVC, and various libraries written for that stack. I've been architecting for months now a path to Angular using ngUpgrade. Most of it has been going great:

Make a thing
Set up the components, services, and classes to make an Angular native and well designed pattern.
Do a little hackery with window variables from the MVC views.
Looks good, functions well, and doesn't break anything the Angular creators would warn against in a style guide.

Hacking it

This though, isn't something I ever thought would be a thing.
Todays goal:

Create a parent Angular component
Define some meta data to pass to a directive component
Have the directive convert the parent components meta data to HTML
Insert the HTML into a rendered element from a library
Have the child component attach the parent component's functions to the window as a function for the onclick attribute of the library rendered angularJs / HTML to call.

It worked!

And it works!

I can create an instance of a class, and assign it something like:

myFunction(myArgument: type){
  // the stuff we need to do in the parent component
  // from the 3rd party angularJs/ Jquery library inserted to the 
  // DOM in a child component rendered HTML
}

element.Function = this.myCallbackFunction;

I am both stoked that I was able to get the basic functionality, but also heartbroken that I had to write something this janky.

Conclusion

The real world is rarely as ideal as the code standard we push. I don't know how long I will have to support this code, but until the called library is fixed / modernized we are stuck. I pity all of our developers just learning Angular, and who might have to grok this concept. And I especially fear for those supporting it years or a decade down the road if the library isn't ever modernized properly.

Always Swagger Your API

Austin French — Wed, 23 Dec 2020 18:36:33 +0000

This is a short and sweet post. And the title summarizes it well enough. Always Swagger Your API.

I can almost hear it now

I never use Swagger because (...)

And let me say, right now. I'll likely address that.

Whenever you are starting a new API, use swagger. I can't recall the documentation, design, and development challenges I've faced because a parameter was slightly mistyped, a class was mis-defined, a class was a slightly different shape, or I had a API call as a GET when I needed and expected it to be a POST.

Swagger solves this. When you need to create an API, being able to rapidly test it, develop against it, and document it saves hours for every minute it takes to implement it.

Reasons you might not want to use it:

It can get very large, and slow
It can expose endpoints (generally touted as a security risk)
Something else to maintain

Too Large

For it becoming large: This is true. And I have two solutions.
a. It can be split, although it creates additional maintenance.
b. Get rid of Swagger after the rough, cowboy days of getting the API up and functional. I think every new API should have swagger through early development. Not necessarily forever.

Security - Exposed endpoints

First, this is a terrible argument from a security standpoint. The bad guys that you should worry about will have better tools to do what they do, including finding your endpoints.

There are real reasons to not want to expose the endpoints however. Perhaps you don't want a user a accident discover the page and create confusion. Or perhaps some calls are not documented on purpose (v2 over v1 endpoints).

Maintenance

You might just not want to deal with maintenance forever. If the swagger gets too large, or your targeting framework changes.

Remove Swagger

I'll say it one last time: Every new API should use Swagger, but when the API is mature enough feel free to remove it

Take Advice, Especially Solicited Advice

Austin French — Fri, 11 Dec 2020 15:45:18 +0000

Overview

I have had an unconventional career path. Some of the randomness includes:

General Manager of a fine dining restaurant.
Former Microsoft MVP.
IT, everything from clearing cookies to driving around the nation setting up equipment, and writing scripts to install software over thousands of machines.
Software Developer, combing backlogs to leading multinational architecture / development.

It's not a bad resume, if I am objective.

Recently, on Reddit I was messaged by someone wanting to know how to get into IT. I fully believe in helping everyone, in anyway I can. So I offered some insight into how I got there, and some advice in general.

Sidebar

Joseph Strauss, a talented and ambitious, yet relatively unaccomplished engineer took on the enormous challenge of the Golden Gate Bridge.

Ultimately, Leon Moisseiff did much of the final design and engineering. We still celebrate Strauss, far more than Moisseiff. But the fact that Strauss solicited the project, and the input required to be successful is how the USA built the iconic structure.

Lesson Learned

We often can't do things on our own. We should ask for advice, and help.

What has me perplexed however was this persons response.

My final piece of advice was something along the lines of

If you find yourself lacking people skills, work on that.
Even if it means picking up a part time job bartending.
Tech has tons of smart, passionate people who aren't articulate
We need more people able to speak with cross functional teams
and negotiate solutions to problems in realistic timeframes

What I got back was something akin to:

F@(k you, you are stupid and racist. No wonder your career has
been involved so much grunt work.

I am paraphrasing here.

Summary

I truly wanted, and would still like for this person to have a fulfilling career.

The thing is, if he solicits for advice, and then throws it away and returns the favor with insults, he won't.

For everyone who solicits advice. Take it. Write it down, sleep on it. Read it again in a year, or five. I have received advice that I took to heart. I have received advice that was too far forward for where I was at the time. And I have received advice that hasn't worked for me (yet?).

And here I am, with a career many people would love to have had. I have a career I have loved. And I hope, for everyone who solicits advice: I hope you have the career and life you seek.

Don't store null bits

Austin French — Tue, 29 Sep 2020 13:56:59 +0000

I have often seen nullable bit columns used in ways that make them a pain to, well use.

I remember when I first started down the path of professional development, and would encounter these patterns and it all seemed to make sense.

"Let's create a column, that represents some choice. The user can choose yes, or no, but also not choose"

ALTER TABLENAME
   ADD ColumnName bit null

As much as this made sense at the time, and the more I have worked with them; the more I have decided that most of the time, this is terrible in practice.

Let's assume a common use case:

An order form for a custom face mask
A User option for "Extra Comfortable Cotton"

In our UI we define it with a TypeScript object similar to:

export class CustomShirt {
   ... // other properties
   IsExtraComfortable: boolean;
}

and in the API we also identify this as

public class CustomShirtOrder
{
    ... //other properties
    public bool? IsExtraComfortable { get; set; }
}

Every looks good here, at a glance. But there are two minor issues for developers further down the road.

The UI/ front end has to care a little too much about the state of boolean.

if (IsExtraComfortable != null && IsExtraComfortable) { }

Which isn't a huge deal, but it is a chance to introduce bugs everywhere the boolean is used. We have to keep in mind that:

We could implement an interface to say this is a nullable field
Misusing it could give us compile time errors
But we can't guarantee it's honored (TypeSafety) because TypeScript is ultimately compiled to JavaScript.

Also the premise of the reasonably named variable 'IsExtraComfortable' is that either the shirt is extra comfortable, or it isn't. If the UI expects a third state, the architecture should also allow one. And I think this is a very important concept: The architecture should reflect the business logic.

Suppose the Order Fulfillment Department also has a department for the extra comfortable shirts. So when selecting a next order they do a search which calls a function:

public Order GetNextShirtOrder(Filter filter)
{
    bool comfortChoice = filter.IsExtraComfortable != null ?
filter.IsExtraComfortable : false;
    var orders = new IQueryable<Order>();

    // when xtra comfort is requested:
    if (filter.IsExtraComfortable.HasValue && comfortChoice)
    {
       orders = db.Orders.Where(w => 
         w.IsExtraComfortable == true);
    }

    // when regular or undecided:
    if (!filter.IsExtraComfortable.HasValue || !comfortChoice)
    {
       // could get true and null, or false and null as required
       orders = db.Orders.Where(w => 
         w.IsExtraComfortable == comfortChoice ||
         w.IsExtraComfortable == null);
    }

    // Other filters

    return orders.OrderBy(o => o.OrderTime).FirstOrDefault();
}

We are creating a lot of extra code, that is harder to maintain and test for quasi-state of comfortable-ness. It's a mess and should not generally be allowed.

Now, the business requirement is possibly something where "IsExtraComfortable" can be opted-in, opted-out, or not selected.

which we could use instead:

ALTER TABLENAME
   ADD IsExtraComfortable tinyint not null

Even better, use a type table which maps to the enum:

public enum ExtraComfortableNess
{
   NotSelected = 0,
   RegularComfort  = 1,
   ExtraComfortable = 2
}

We have a couple important advantages doing this:

We can see more significance in reports to what the values mean
An Int in C# is zero by default, so we can simplify our code
We might not have to touch our code again if another level of comfort is added
Any expense of a join to the type table is only when we would need to see something like a UI value
We can have meta data for the comfort type

Additional thoughts: If we really want a property for IsExtraComforable, we could still achieve this of course:

public bool IsExtraComforable 
{
    get { return ExtraComfortableNess == 1; }
    set { //not settable }
}

Now if in 6 months, the business adds a new "Primo Comfort Cotton", we aren't trying to shoehorn existing logic and new logic together.

Using a nullable boolean, our logic could get a little weird. Obviously a shirt can't be made of two fabrics. This means we would be constantly checking that where one boolean is set, another is unset, or not set.

And what would be the business differences between two orders where:

ShirtFabric : {IsExtraComfortable: false, PrimoFabric: true }

and

ShirtFabric : {IsExtraComfortable: null, PrimoFabric: true }

It's all going to be much easier with:

ShirtFabric : Fabric.PrimoFabric

ShirtFabric : 3

Saving Space

The reason we usually want to use a bit in the first place is space constraints. The argument goes: By using a bit, we have a very small thing to store on the disk, in the servers memory, and on the client.

In SQL, this is only sometimes true.

Where a Byte is 'B', and a bit is 'b'. And 'N' is the number of bit columns on the table our size of bit columns would be more like:

B = ⌈N/8⌉

So 1 column, is still a byte, up to 8 bit columns. Or the same as a tinyint. Nine bit columns would also take 2 bytes of storage. This really is our best argument for using a bit column.

But:
in C# bool is 4 bytes. JavaScript (And by Extension TypeScript) a boolean is also 4 bytes.

So in short, at least most of the time we aren't saving space. In memory a tinyint (byte) could be used, and you'd get up to 255 (0 - 255) possible choices, plus a default without additional overhead.

Perhaps more importantly though, you can't index on a bit column. You can on any int columns. Especially now, where DTUs are expensive in services like Azure, and storage is cheap; The cost of querying millions of rows of non-indexed values is vastly more expensive than sometimes using more data.

And finally, I would be much less harsh on a bit column. We get the space saving of a bit column. We could store up to 8 values in bit columns for the same space as a tinyint, and there is no room for a quasi-third state. But if ever your requirements say something like:

"We will offer standard and rushed processing on all orders; Store whether rushed processing is requested". I encourage you to look at market leaders, and sites you regularly use and note patterns like:

Standard Processing (4-7 days)
Rush Processing (next business day)
Super Saving Processing (save $x by waiting 5-10 business days)

I think we can all smell an enhancement that would break our bit column. I'd opt for the tinyint.

Why you should be a "Night Owl"

Austin French — Fri, 21 Aug 2020 14:11:16 +0000

1. You get more time in the day

OK, the amount of time you are awake, and in the day would be roughly equal. But your productive hours are when everyone else is asleep.

2. You get a sense of achievement

Knowing that you use the hours best for you, regardless of what "office hours" generally are.

4. You get a proud feeling that while most of the world is sleeping, you are working. This feeling is really good for your morale💯

5. 🌸You'll feel better about yourself🌸

If you are a night owl, being on your schedule is great! Going grocery shopping at 10pm or 6am is a great experience!

6. You’ll Have a Better Chance at Completing your tasks💯

A happy well rested self, is going to get more done with a higher degree of quality.

7. You can also just take it slow

With all the morning plebs sleeping, you can buckle down and write code, strategize, and not get sucked into as meetings.

8. 💝Some health benefits 💝

Ok, the science here isn't great for us night owls. Hopefully it's correlative. But the Gym is generally empty between 11pm and 4am!

And although studies say our health tends to be worse, we also tend to have more creativity, endurance, and better reasoning skills!

9. 😆Some funny (and possibly sarcastic) reasons 😆

You can talk about it on social media.
Internet speed is usually faster in the middle of the night.

You can brag about being awake all night, getting stuff done.

Serious Talk

This is a joke of a response to: https://dev.to/nirbhayvashisht/waking-up-early-in-the-morning-how-and-why-1eem

Us night owls get a lot of crap for our chronotype. It isn't easy being tired all day, and then once the sun sets getting a burst of energy.

Unfortunately, when the world was figuring out how to run businesses, factories, and schools; some jerks with money and power chose to slot us all into the great lie about the greatness of early risers. Multiple shifts would be better IMO.

My suggestion: Do what works for you, if you can. And always push for flexible hours. Even if you are a morning person!

And finally, Nirbhay Vashisht offers some great advice for us all! Whatever your schedule is, make it a schedule. A consistent bedtime and wake-time each day will help your route immensely. For me, the perfect bedtime is about 7am (when my real life allows it)