Windows 10 Taskbar Auto hide issues

My Dell laptop regularly looses the windows taskbar when I disconnect and reconnect to my dual monitors.  This is very frustrating because the only solution I know of is to restart my PC.  I came across this article http://www.makeuseof.com/tag/5-steps-fix-windows-10-taskbar-issues/ which has an easy solution.

Now when I have the issue all I do is start task manager with CTRL+SHIFT+ESC and restart the windows explorer process and the taskbar reappears.

 

 

Read a book in a week

I found this article interesting: https://hbr.org/2016/02/how-to-read-a-book-a-week

I myself am a slow reader, thinking I have to absorb and remember every thought.  I also struggle to remember what I’ve read.

The suggestions in the article seem to be very useful.  I have be aware and practiced a few of them in the past with some success.  I plan to try out #4 and try to speed up my reading.

Of course there is the book “How to read a book” by Mortimer J. Alder that I should revisit.

Just in case the article becomes inaccessible, I’m posting the points here:

  1. Start with the author. Who wrote the book? Read his or her bio. If you can find a brief interview or article online about the author, read that quickly. It will give you a sense of the person’s bias and perspective.
  2. Read the title, the subtitle, the front flap, and the table of contents. What’s the big-picture argument of the book? How is that argument laid out? By now, you could probably describe the main idea of the book to someone who hasn’t read it.
  3. Read the introduction and the conclusion. The author makes their case in the opening and closing argument of the book. Read these two sections word for word but quickly. You already have a general sense of where the author is going, and these sections will tell you how they plan to get there (introduction) and what they hope you got out of it (conclusion).
  4. Read/skim each chapter. Read the title and anywhere from the first few paragraphs to the first few pages of the chapter to figure out how the author is using this chapter and where it fits into the argument of the book. Then skim through the headings and subheadings (if there are any) to get a feel for the flow. Read the first sentence of each paragraph and the last. If you get the meaning, move on. Otherwise, you may want to read the whole paragraph. Once you’ve gotten an understanding of the chapter, you may be able to skim over whole pages, as the argument may be clear to you and also may repeat itself.
  5. End with the table of contents again. Once you’ve finished the book, return to the table of contents and summarize it in your head. Take a few moments to relive the flow of the book, the arguments you considered, the stories you remember, the journey you went on with the author.

Your database projects will be ready after ### operations are completed

Today I encountered an issue with opening a Visual Studio solution that had a database project in it and visual studio would hang up.  I tried several times to close and reopen.  Occasionally it would say something like “your database projects will be ready after ### operations are completed”.  After searching Google I discovered that it was the database project causing the problem.  For me, I was able to fix the issue by deleting the project bin and obj folder contents.

Coding Standards

Recently, I needed to define some coding standards that I think are important.  I thought it would be good to list them in a post.  My opinion has been impressed on over the years by the writings of “Uncle Bob”, Martin Fowler and Steve McConnell in their books and articles such as: Clean Code, Refactoring and Code Complete.  Another interesting publication is Microsoft’s Framework Design Guidelines.  There are many others that I have read and I highly recommend that all developers strive to write code that is easy to read and maintain.

Here is my short list:

1. Avoid Flag Arguments
They complicate the method signature: http://martinfowler.com/bliki/FlagArgument.html

They add complexity to the API internals. They don’t communicate their intention well, making them harder to use.

2. Prefer Polymorphism to If/Else or Switch/Case

3. Avoid nullable types or at least minimize their visibility

They add complexity to code, especially in API signatures. They require more validation checks.

Only use if it adds value.

Don’t use nullable Boolean values. If you need 3 states then use an enum instead

4. Avoid Negative Conditionals

5. Avoid putting database dependencies into business logic APIs

That is the API shouldn’t call the database but instead the calling API should pass the data in

6. Prefer guard clauses instead of nested if/else return statements

7. Prefer few method parameters

8. Prefer smaller methods and smaller classes

9. Limit Exception Handling.

The point is that you don’t have to catch exceptions at every method but can let them bubble up to the top method. When logging, log in the business layer and catch and log in the method at the top of the call. In general, that should be the practice. There are exceptions such as detail logging in jobs and also where you don’t want the program flow to be aborted.

10. Clean up code as you make changesFormat code. Visual Studio has shortcuts to format code:

Ctrl-k/Ctrl-d – formats code on open file

Ctrl-k/Ctrl-f – formats selected code

11. Remove unused, unreferenced and commented code.

12. Single Lager of Abstraction principle

One issue I see all the time is hard to read logic.  That tends to be fragile and lead to bugs.  Polymorphism help with that.  Also we can develop smaller APIs with the logic so that the main code reads better and the logic is isolated and can be thought of and as a unit.  I believe the concept that I’m describing is the Single Layer of Abstraction principle (SLAP).  “Uncle Bob” and Kent Beck discuss this in detail in their writings.

Web API Attribute Routing

In my continue research into Web API I came across a new feature in Web API 2 called Attribute Routing.  This feature makes it possible to define routes at the API level.  It makes it easier to define complex RESTful URIs where there are child resources like “/customer/123/orders”.  It also gives you the ability to have multiple GETS, POSTS and PUTS on the same controller.

The traditional style of routing is called Convention-Based Routing and you can mix both in the same application.

On a side note, there is also the ActionName attribute.  It doesn’t give you the ability to define the route but it does make it possible for you to have multiple GETS, POSTS and PUTS on the same controller.

You do have to enable attribute routing.  This is done in the WebApiConfig.Register method: config.MapHttpAttributeRoutes();

This ASP.NET link describes attribute routing in more detail: http://www.asp.net/web-api/overview/web-api-routing-and-actions/attribute-routing-in-web-api-2

TSQL ID Columns in Tables

Over my development years, I’ve seen many tables designed with useless ID columns.  The columns serve no purpose.  They are not reference by anything.  Then to make matters worse, a primary clustered key is created on the ID column.

My recommendation is to only add ID columns when you need to create a relationship between tables.  For example, if you have a customer table and a customer orders table, you need the ID field on the customer table to reference on the order table.  But you don’t need the ID on the orders table.  If you have an orderdetails table, then you would need the ID on the orders table.

The extra ID column adds unnecessary storage overhead and you waste your clustered index when you make it a primary clustered key.

It is always beneficial to ponder a little longer about your table designs and determine whether you really need an additional ID column as well which column(s) are the best to create your clustered index on.

Soft Skills by John Sonmez

I’ve just recently purchased the book  Soft Skills by John Sonmez.  I have already been following John’s podcasts and I’ve heard him on .NET Rocks as well as taken his course on PluralSight.  His insight is very helpful.  Some of his ideas comes from a lot of the same books that I have read in the past – like How To Win Friends And Influence People.

The chapters are short enough to read in less than 15 minutes but provide a lot of useful information.  And at the end of each chapter are some actions he recommends.

Basically, the book is about the premise that there is more to being a developer than writing code.  Although I have little to say in a blog and find it difficult to put my thoughts down in writing, his articles and this book are motivating me to step out of my comfort zone.