AlexDresko.com

October 29, 2018

Publishing a Visual Studio extension via command line

Microsoft not so recently added support for publishing Visual Studio extensions to the marketplace via a command line interface called vsixpublisher.

It’s no coincidence they tweeted me upon releasing the feature, as I’d been pestering them for a very long time to make it happen.

The walk-through I linked to will get you going, but might not get you all the way there. If you run into trouble trying to get it to work, here’s a reference implementation that might help:

I have an appveyor build that runs automatically, anytime someone pushes code to the master branch. Here’s how I configured the build to version, package, and publish the vsix to the marketplace.

https://github.com/alexdresko/HSPI/blob/master/update-vsixversion.ps1
This gets called as part of the “Before build script”. It sets the version number inside the vsix manifest based on the appveyor build number.
https://github.com/alexdresko/HSPI/blob/master/publish-vsix.ps1
This gets called as part of the “After deployment script” within my deployment. It’s the thing that actually pushes the built vsix to the marketplace. Note that I’ve configured my deployment to only fire when someone pushes to the master branch.

The trickiest part about the file is that it uses an environment variable to obtain the personal access token, since I don’t want to commit that to source control:

You can set the environment variable in appveyor here:

The MS article shows how to create the personal access token.
https://github.com/alexdresko/HSPI/blob/master/Templates/HomeSeerTemplates/publish-manifest.json
Standard file, almost completely copied from the MS documentation. Be careful to get the “internalName” right. I wish I knew more about how the internal name relates to the vsix identifier, as my lack of knowledge actually caused me to lose access to my plugin on the marketplace. Be careful…whatever that means.
https://github.com/alexdresko/HSPI/blob/master/Templates/HomeSeerTemplates/source.extension.vsixmanifest
This is just my vsix manifest for reference. You might even find it helpful to review the entire repo.

Last, but not least, the end result: https://marketplace.visualstudio.com/items?itemName=thealexdresko.HomeSeerTemplates2

I hope that helps someone who wants to get started using vsixpublisher. let me know if you have any questions, and I’ll try to help.

June 1, 2018September 28, 2018

What is ASP.NET Core 2.1 API “Problem Details” (RFC 7807)

When ASP.NET Core 2.1 came out, there’s was a relatively brief announcement about new support for “Problem Details” (RFC 7807).

In this release we added support for RFC 7808 – Problem Details for HTTP APIs as a standardized format for returning machine readable error responses from HTTP APIs.

If you just want a better explanation of problem details, fear not. I read the documentation for you.

Problem Details is nothing more than a standard JSON format and content type. Here’s a sample from the documentation:

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en
{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/msgs/abc",
"balance": 30,
"accounts": ["/account/12345",
"/account/67890"]
}

HTTP/1.1 403 Forbidden

Content-Type: application/problem+json

Content-Language: en

{

"type": "https://example.com/probs/out-of-credit",

"title": "You do not have enough credit.",

"detail": "Your current balance is 30, but that costs 50.",

"instance": "/account/12345/msgs/abc",

"balance": 30,

"accounts": ["/account/12345",

"/account/67890"]

}

The first three lines indicate the headers returned from the server. 403 is just a sample code. Your API can return any code it needs to return for a given error condition. The Content-Type is important, though.

The only problem details-specific elements for in this example are “type”, “title”, “detail”, and “instance”.

“balance” and “accounts” are custom properties. That means you can include any additional data you want in your problem details.

Honestly, it’s worth digging into the documentation if you want to know more, but here’s what I think is the most important bit:

3.1. Members of a Problem Details Object
A problem details object can have the following members:
o "type" (string) - A URI reference [RFC3986] that identifies the
problem type. This specification encourages that, when
dereferenced, it provide human-readable documentation for the
problem type (e.g., using HTML [W3C.REC-html5-20141028]). When
this member is not present, its value is assumed to be
"about:blank".
o "title" (string) - A short, human-readable summary of the problem
type. It SHOULD NOT change from occurrence to occurrence of the
problem, except for purposes of localization (e.g., using
proactive content negotiation; see [RFC7231], Section 3.4).
o "status" (number) - The HTTP status code ([RFC7231], Section 6)
generated by the origin server for this occurrence of the problem.
o "detail" (string) - A human-readable explanation specific to this
occurrence of the problem.
o "instance" (string) - A URI reference that identifies the specific
occurrence of the problem. It may or may not yield further
information if dereferenced.
Consumers MUST use the "type" string as the primary identifier for
the problem type; the "title" string is advisory and included only
for users who are not aware of the semantics of the URI and do not
have the ability to discover them (e.g., offline log analysis).
Consumers SHOULD NOT automatically dereference the type URI.
The "status" member, if present, is only advisory; it conveys the
HTTP status code used for the convenience of the consumer.
Generators MUST use the same status code in the actual HTTP response,
to assure that generic HTTP software that does not understand this
format still behaves correctly. See Section 5 for further caveats
regarding its use.
Consumers can use the status member to determine what the original
status code used by the generator was, in cases where it has been
changed (e.g., by an intermediary or cache), and when message bodies
persist without HTTP information. Generic HTTP software will still
use the HTTP status code.
The "detail" member, if present, ought to focus on helping the client
correct the problem, rather than giving debugging information.
Consumers SHOULD NOT parse the "detail" member for information;
extensions are more suitable and less error-prone ways to obtain such
information.
Note that both "type" and "instance" accept relative URIs; this means
that they must be resolved relative to the document's base URI, as
per [RFC3986], Section 5

3.1. Members of a Problem Details Object

A problem details object can have the following members:

o "type" (string) - A URI reference [RFC3986] that identifies the

problem type. This specification encourages that, when

dereferenced, it provide human-readable documentation for the

problem type (e.g., using HTML [W3C.REC-html5-20141028]). When

this member is not present, its value is assumed to be

"about:blank".

o "title" (string) - A short, human-readable summary of the problem

type. It SHOULD NOT change from occurrence to occurrence of the

problem, except for purposes of localization (e.g., using

proactive content negotiation; see [RFC7231], Section 3.4).

o "status" (number) - The HTTP status code ([RFC7231], Section 6)

generated by the origin server for this occurrence of the problem.

o "detail" (string) - A human-readable explanation specific to this

occurrence of the problem.

o "instance" (string) - A URI reference that identifies the specific

occurrence of the problem. It may or may not yield further

information if dereferenced.

Consumers MUST use the "type" string as the primary identifier for

the problem type; the "title" string is advisory and included only

for users who are not aware of the semantics of the URI and do not

have the ability to discover them (e.g., offline log analysis).

Consumers SHOULD NOT automatically dereference the type URI.

The "status" member, if present, is only advisory; it conveys the

HTTP status code used for the convenience of the consumer.

Generators MUST use the same status code in the actual HTTP response,

to assure that generic HTTP software that does not understand this

format still behaves correctly. See Section 5 for further caveats

regarding its use.

Consumers can use the status member to determine what the original

status code used by the generator was, in cases where it has been

changed (e.g., by an intermediary or cache), and when message bodies

persist without HTTP information. Generic HTTP software will still

use the HTTP status code.

The "detail" member, if present, ought to focus on helping the client

correct the problem, rather than giving debugging information.

Consumers SHOULD NOT parse the "detail" member for information;

extensions are more suitable and less error-prone ways to obtain such

information.

Note that both "type" and "instance" accept relative URIs; this means

that they must be resolved relative to the document's base URI, as

per [RFC3986], Section 5

April 21, 2018

Chromebook life

Who would have thought I’d love a $500 Chromebook as much as I love my $4000 Dell M6800 (32GB RAM, 1.5TB SSD, I7)? I’ve been so productive over the past four days of ownership that I’m honestly pretty frustrated I didn’t fork over the money for this thing earlier.

See, I’ve always had a powerful laptop as my single, primary machine. It’s the same computer I use at work and home. I wake up in the morning, remove it from the docking station, pack it up, take it work, unpack it, plop it on the docking station, work, remove it from the docking station, pack it up, drive home, unpack it, plop it on the docking station, use it for whatever the evening requires, then rinse and repeat.

I’ve done that process for years. Except, there’s friction in them thar hills.

It turns out, ultra-powerful laptops rarely have ultra awesome batteries. The M6800 lasts about 45 minutes on battery, which totally makes me the laughing stock of most business meetings. The fact that it’s gigantor and weighs 6 tons is just fuel for the flame. I can’t just drag out the big laptop and use it where ever and whenever I want.

There’s also the problem of having to transition my environment from “work mode” to “home mode” and back again. When I get home, I’ve still got my work email open, Visual Studio open, and probably 15 other things related to work still open because that’s the last thing I was doing. I don’t particularly want to shut it all down, but I also want all of the computer’s resources for anything I need in “home mode”. It’s the same problem when I get back to work the next day.

It’s that friction that prevents me from being productive at home most evenings. It’s easier usually to just avoid the computer altogether after work.

Enter, the Chromebook. The real beauty of the Chromebook is that it’s light, fast (for what it does), small, and the battery lasts for hours! Obviously, I’m not doing any development directly on this thing, but I can remote into my big laptop to code when necessary. In fact, I can do almost everything I need to do on the Chromebook except for writing code.

Case and point: I can write blog posts on the back patio while waiting for my wife to great ready.

This thing is a game changer, and I’m super excited for what the future holds.

By the way, I got the Asus C302CA.

March 26, 2017

Thoughts: The Stack Overflow 2017 Developer Survey Results

I found it useful this year to take some notes as I skimmed through the always interesting Stack Overflow developer survey results. Here’s what I came out with this year:

As much as I hate the title, “Full stack web developer” tops the web developer charts. I suppose it’s a good thing I’ve got that on my resume.
It’s surprising to me that the overwhelming majority of people on SO are white or European descent.
It’s surprising to me that so many people have a bachelor’s degree or a master’s degree. I’m in the “Some college” category, and I would have thought there’d be more people without degrees than with.
Some of my favorite technologies (SQL, C#, and TypeScript) continue to be very popular. Job security. I’m also glad I didn’t let someone at work convince me to use CoffeeScript instead of TypeScript. :)
.NET Core is very popular right now. Glad I’m investing in that. I haven’t invested much in Node — even less the Angular — and that bothers me. I was hoping to see more Aurelia and less Angular this year.
Windows is still the best choice and Imma stick with it. I’m always surprised to see AWS overtaking Azure, though. I like Azure.
Glad I’ve invested so heavily in TypeScript. It’s muy popular. Maybe I’ll give Rust a try this year. Also, I wonder if the strong distaste for VB.NET explains why HomeSeer development is so stalled.
Glad I’m investing in .NET Core. Curious why there’s so much distaste for Cordova — I was thinking of using it to build something.
Might be a good idea to continue playing with my Raspberry PI Zero W. Only problem is it doesn’t seem to support anything I want to do.
Confirmed. Again. Visual Studio is the best IDE. I do go against the grain and prefer Sublime to Notepad++, but mostly just because Sublime looks better out of the box. Glad to see Visual Studio Code rising to the top of the ranks. I find myself using it more and more, and it’s getting more and more powerful.
My vendor of choice, Microsoft, is nestled deeply in the largest technology ecosystem.
Glad I invest so much time in DevOps. It’s the highest paying salary developer type. Interesting that web developer is so low on the list.
I get paid very well for what I do.
I do miss TFS sometimes, but, seriously, Stick with git.
Good thing I value communication, getting things done, knowledge of algorithms, understanding my tools, contributing to open source, and my Stack Overflow reputation. Although, I would move SO reputation higher in the list.
I keep reading Agile is dead. SO survey results show otherwise.
I pronounce gif properly.
“Most developers agree that “good enough” is good enough. Shipping and then iterating is the preference of most developers.” <– This
The survey results here are clearly wrong. Get those noisy keyboards out of my office.
I also prefer tabs. I’m alone in this at work.
Feels good knowing I’m not completely crazy for wanting a completely silent office.
“We see a relationship between job satisfaction and pushing code into production frequently. (We still see this even after controlling for other effects, such as industry.) A happy developer is a developer who can ship.” <– This.

All in all, it’s helpful knowing I’m steering my career in the right direction. Perhaps the most surprising thing in this year’s results is the utter lack of the word “security.” Had I taken the survey when I had the chance, I would have noticed this omission earlier, but a developer survey without the mention of security seems flawed.

Now that my ego is sufficiently inflated, I think I’ll go write some code.

March 20, 2017

The difference between a junior and senior level software engineer?

I dislike titles. Keep reading to find out why.

Preface

I was recently asked a series of questions and decided to create blog posts from the answers.

Everything herein came straight from this horse’s mouth. I didn’t once flex my Google-fu or Bing-kwondo except to determine the best way to spell Bing-kwondo. My goal was to respond to the proposed questions solely with the knowledge I’ve gained from experience over the years. When reading my response, please remember – with passion comes opinion. I value your opinion, even if it is different from mine, as difference breeds understanding and growth.

My opinion

First, to set the stage, “Senior” does not necessarily mean “great developer,” “leader,” or “management material.”

I like to think we’re all junior level engineers with varying experience and stack mastery; “Senior” is, therefore, either marketing fluff or a title handed down by an employer to signify organizational hierarchy or seniority.

While employers have donned me Senior in the past, I self-label as a senior developer because it aligns me with the types of jobs I want most. I.E., architect, mentor, leader, mystic code wizard, etc.

Plus, if “senior” grants me the opportunity to hitch a ride in the corporate helicopter, I’m cool with that.

If you want to get technical, some say it requires 10,000 hours to master something. By my rough estimate, I’ve logged more than 20,000 hours since I began passionately writing software in 1999. The key element here is passion.

Passion is what makes a great developer. I’d rather have a passionate new developer on my team than a stodgy old developer with 20,000 hours of passion-free experience. The latter can, in fact, be quite toxic to an organization.

Writing software is an art and my passion. It is my job and my hobby. It is a never-ending learning process wherein one simply cannot know everything. It ranks super high among the things I think about most when I’m not at work, almost to a fault if you were to ask my wife. It’s all I’ve ever wanted to do, and I never plan on working my way so far up the corporate ladder that I’m no longer typing teh codez.

February 23, 2017

What is your definition of a full-stack developer?

Funny you should ask – I’m known for having a strong distaste for the “full-stack developer” moniker, and I’ve started many a friendly debate on the subject.

Preface

I was recently asked a series of questions and decided to create blog posts from the answers.

“Full-stack developer”

I put “full-stack developer” on my resume partially because I do believe I fit someone’s definition of the term, but mostly because I’m afraid “ludicrous-stack developer” won’t appear in search results.

It’s marketing fluff, at best.

If you put a gun to my head, I’ll concede some validity to the title. Developers needed a succinct way to characterize the breadth of their capabilities, and “full-stack” became the hammer.

The problem, of course, is that there is no concrete definition.

I’d describe a full-stack developer as one with the proven ability to fully execute a project from start to finish, specifically including the following tasks (<assessment>/<excitement level> on a 1-10 scale based on the types of projects I’ve worked on in the past):

Brainstorming (9/10)
Requirements gathering (8/10)
Architecture (8/10)
Dev Ops (also up for discussion) (8/10)
Database design (7/9)
Graphic design (7/5)
UX (8/9)
UI (7/7)
Maintenance/support (8/2)
Infrastructure (9/10)
QA (10/6)
The ability to lead a team in the process (8/9)
Front end coding (8/9)
Back-end coding (9/9)
Sales? (1/1)

So why is that my definition of “full-stack”? Because I consider myself to be a software developer, and I’ve performed all of those roles.

I realize that’s a massive skill set, going far beyond what might traditionally be considered a software developer. Most days are spent wearing just one or two hats, but the spirit of “full-stack” is in having the experience of wearing them all.

February 10, 2017February 7, 2017

How does an organization best achieve software quality?

Great question! But is quality even important? Is it possible? How do you know if you’ve achieved quality?

Preface

I was recently asked a series of questions and decided to create blog posts from the answers.

My opinion

There is no silver bullet. Quality is often subjective, unnecessary, or even impossible when faced with constraints.

In general, the following bullets, in no particular order, seem to produce the highest quality software regardless of constraints.

Unit tests, integration tests, and functional tests (all where applicable only)
Continuous, and strict, integration builds
Automation
Code reviews
Pair programming
Continuous personal and professional self-improvement
Humility
Passion
Fantastic leadership
Appropriate communication across all levels of the organization
Reasonable expectations of developers by management
A clean, developer-friendly work environment
Providing developers with the tools they need
Documented and agreed upon standards and procedures
A shared vision, values, and goals
Having the right people on the team
Flexible, modern infrastructure
Powerful developer hardware
Software architecture that encourages quality
A software development lifecycle that doesn’t get in the way or cause bottlenecks

But, really, even if you checked off all those boxes, how would you know if you created a quality product? I guess that’s the first question to ask — What is quality? If “quality” simply means “running” in your organization, then I suppose even most newbie of developers can succeed.

February 7, 2017

What is your definition of “done”?

Such a vital question in the software development world! “Doneness” is how you measure progress. And so it seems important that we should create some definition of the term.

Preface

I was recently asked a series of questions and decided to create blog posts from the answers.

My opinion

Definitive doneness can only be determined if all parties involved fully understand the scope of work requested, the level of doneness requested, and if the work was completed fully at the time of the request.

And that’s hard.

In my experience, a software product is rarely ever done, and “Is it done?” by itself is rarely ever a suitable question.

Individual work items are completable, but false positives arise when:

Team members don’t fully understand the work item
Team members don’t fully read the work item
The work item doesn’t fully document the scope of work to be completed
A required work item doesn’t exist
A completed work item doesn’t line up with company objectives
A team member lacks humility or courage

A great developer strives to understand what “done” means and sets necessary expectations, ideally without using that vague developer speak that always seems to frustrate higher-ups.

In the same vein, a great developer goes above and beyond to exceed expectations, certifiably completing tasks, even when confronted with adversity.

Or we just lie about something being done and stay up for the next 36 hours knocking it out before anyone notices. :)

What’s your definition of “done”?

January 30, 2017

Toastmasters for the software developer

In this video, I, or rather, RealCoder79, give a short speech at Greenville’s Metro Toastmasters about how Toastmasters can benefit software developers.

Toastmasters, if you didn’t know, provides “a supportive and positive learning experience in which members are empowered to develop communication and leadership skills, resulting in greater self-confidence and personal growth.”

Being that I killed www.realcoder79.com recently, I thought it’d be a good idea to give some of that old content a new home.

Enjoy!

January 25, 2017March 20, 2017

A Review of Devart’s Code Compare Diff Tool for Windows

Hi, my name is Alex, and I’m a power hungry software developer. Devart’s Code Compare diff tool for Windows is power. By our powers combined, I am a powerful software developer.

…Continue reading “A Review of Devart’s Code Compare Diff Tool for Windows” [A Review of Devart’s Code Compare Diff Tool for Windows]