Gig History

My experience playing on stage:

Solo:

Feb 2015: Joined a band on stage (bar is Desire) for two songs on Penang Island, in Malaysia.

Creep
Some Chinese song


AmpWagon (I joined the band 12-Jun-2015):

1. 29-Aug-2015: Nate and Wally's Fishbowl
2. 11-Sep-2015: Nate and Wally's Fishbowl
3. 17-Oct-2015: BGSU Tailgate
4. 24-Oct-2015: Halloween Party
5. 7-Nov-2015: The Alehouse
6. 21-Nov-2015: Nate and Wally's Fishbowl
7. 11-Dec-2015: Nate and Wally's Fishbowl
8. 22-Jan-2016: Howard's Club H
9. 17-Mar-2016: Howard's Club H

Groove Cricket (I started the band. First practice was Oct 2016.)

1. 17-Dec-2016: Christmas Party at Dave Riffer's (guitarist) house
2. 13-Apr-2017: Howard's Club H (open mic night)
3. Dec 2017: Christmas Party at Dave Riffer's house

First Set List:

Web Security Implementation

I needed to pick an approach to security for my new web front end for my open source project Presto. My first step was to ask for overall direction from some industry experts. So, special thanks to Jim Manico (@manicode, site) for helping me. While this approach is still evolving as I work through it, I wanted to summarize the security implementation here.

Overview

Instead of defining roles and allowing things based on those roles, define permissions (functionality seems to be a more intuitive word here) and allow things based on those permissions. For example, if I define an admin role, some company may want some admins to do some things and other admins to do different things, so don't lump them all together. Instead, create a list of specific functionality (print this, save that, etc.) and assign each user(?) to each functionality. Then there is a lot more flexibility.

With this approach, we won't have to change source code in the future. For example, if we wanted to add a new AD group, and we specified AD groups/users in code, we'd have to change code. With this approach, each piece of functionality gets its own unique name. Then each is mapped to AD groups in some central store.

Note: We ended up abandoning this approach for one main reason: our security line of trust is at the logic layer in our business logic classes. If we secure at the Web API, then we have to secure correctly at every Web API we implement. It's better to have security in one spot, which, in our case, is at each method in our logic layer.


Implementation

Web API

Web.config (the key is the functionality, the value is the AD group):

<add key="DeleteUser" value="Some AD Group"/>

(Note: The web.config is used here just as a demo to get this working. Perhaps this info should be in the DB.)

FunctionalityAttribute:

public class FunctionalityAttribute : AuthorizeAttribute
    {
        public string FunctionalityName { get; set; }
 
        protected override bool IsAuthorized(HttpActionContext actionContext)
        {
            string adGroup = WebConfigurationManager.AppSettings[FunctionalityName];
 
            if (actionContext.RequestContext.Principal.IsInRole(adGroup)) { return true; }
 
            return false;
        }
 
        protected override void HandleUnauthorizedRequest(HttpActionContext actionContext)
        {
            // Authenticated, but not authorized.
            if (actionContext.RequestContext.Principal.Identity.IsAuthenticated)
            {
                // Use Forbidden because Unauthorized causes a login prompt to display.
                actionContext.Response = new HttpResponseMessage(HttpStatusCode.Forbidden);
            }
        }
    }

API Controller:

[Functionality(FunctionalityName = "DeleteUser")]
public class AppsController : ApiController

(Note: The attributes will actually go on the methods, not the class. This example is just to test at the moment.)

---

Dealing with success and failure in the AngularJS repository call

$http.get('/PrestoWeb/api/apps/')
    .then(function (result) {
        data = result.data;
        $rootScope.setUserMessage("Application list refreshed");
        callbackFunction(data);
    }, function (response) {
        console.log(response);
        if (response.status == 403) {
            $rootScope.setUserMessage("Unauthorized");
            callbackFunction(null);
        }
    });

---

JavaScript

if (user.canAccess("DeleteUser")) {
    // Set AngularJS scope variable that shows that the delete button should be enabled
}

---

WCF Service

What's to stop someone from changing the JavaScript and getting the DELETE button enabled? Nothing, that's why you don't trust the browser. Whatever security we implement on the web page must also be implemented at the service or logic layer. In my case, that would be the WCF service. So while the user can enable the DELETE button by hacking the JS, he won't actually be able to delete because the security at the service (or logic) layer will prevent that.

ToDo: Show WCF security implementation here after I do it.

Resources

Cross Site Scripting Prevention Cheat Sheet
Java Authorization Guide


Some Notes

As a product, you need to support many different kinds of authentication.
As a service, you need to support SAML and similar for federation - especially for big customers.

iTunes and Windows 10 - Update Issue

After installing Windows 10, I let iTunes update itself and then it wouldn't run. So I tried reinstalling it, only to get this error:

After trying quite a few things, I was finally able to get it to install by doing a repair on the Apple Software Update application.

Hope that works for you.

Why Does Programming Take So Long?

I could write 500 pages on this topic. Instead of coming up with analogies and serious reasons why the software development industry has problems justifying things taking "too long," I thought I'd start a list of annoying reasons that cause delays. These are issues that are almost impossible to relate to management because each incident is fairly insignificant, but the sheer volume of occurrences is staggering. It's impossible to remember them all, so here is a list of irritating things that constantly degrade the quality of life of a software developer. I'll record these when they happen, if I can remember to do so.

Bad Characters
We needed to start a SQL job on our QA DB. We've run this job before. Well, we just replaced our old QA server with a new one. A stored procedure and table were missing on the new server. I had to find a developer who had the source code. He emailed me the source code. When I executed the TSQL to create the table and sproc, I got many "incorrect syntax" errors. That's because there were bad, invisible characters in the TSQL. Since it was impossible to tell where these characters were in the file, I had to delete every whitespace character and add a new one throughout the files. What should have taken two minutes, to start the process, took 30 minutes just to get back to the state of having the process in the first place.

Padding
A record wasn't coming back in a database query. The record was there; we could see it. Could not figure out why it wasn't included in the query. Turns out someone padded the value with spaces to make it 10 characters.

Breakpoint
A team is building some SSIS and we are testing and promoting. Guy checked it in with a breakpoint in the SSIS that wasn’t visible in my VS. I spent an hour checking connections, DTC setup, until I finally noticed “breakpoint hit on task X” in the output window.

Icon Width in VS
I needed to look through my recent changesets, so I found the list by my user ID within Visual Studio. Each time I clicked on a changeset to view its details, the icons next to each file in the changeset got bigger and bigger. Near the end, only three or four rows would fit on the window. Finally, VS threw an exception that the width was too big. After trying a few things, I restarted VS and it was working again.

More to come as they happen...

Top 10 Ways to Annoy a Software Developer

10. Talk disparagingly about Scott Hanselman, Jon Skeet, Martin Fowler, or other luminaries of the software development pantheon.

9. Require the code to change as the requirements change, but allow the project documentation to get out of sync.  Attempt to use a series of email chains as a floating addendum to the specification.

8. Tell developers how to implement a solution to a problem instead of just laying out the details of the problem.

7. Assert that “done is better than perfect” but ignore the option of having it done right.

6. Say you’re “too busy” to do any QA.

5.  Imply that a developer is being difficult when he highlights potential difficulties instead of welcoming the opportunity to evaluate assumptions and get out in front of project risks.

4.  Trivialize the development effort for any feature that you are not directly responsible for designing or building.  Doubly annoying when adding new requirements while the project is already in QA.

3.  Put a 2 paragraph project overview in a Word document and call it a func spec.

2.  Set an arbitrary project deadline prior to finalizing the project scope and doing technical analysis.

1.  Send out a congratulatory email after a successful go-live and say “Great work <insert analyst name here> and team!”

WCF or ASP.NET Web API

There are a lot of resources out there that explain the pros and cons of using one over the other. But what about what they actually are? I mean, at the most fundamental level? I researched a bit. This SO answer helped.

WCF and Web API
They are both hosted on a server, and both accept socket requests. The point is to accept messages and do something and possibly return something.

WCF
WCF replaced web services. It can be made to be restful, and it can be made to use SOAP. Hmmm, doesn't restful imply using HTTP GET and/or POST? And if it's restful, then our message protocol can be XML, JSON, plain text, etc. The point is that we're not tied to SOAP here. With SOAP, we're not tied to HTTP, so we can use protocols like TCP.

Web API
Web API uses HTTP. Period. So, what's the point, if WCF can be made to work this way as well? Perhaps it's because WCF needs to be made to fit the HTTP paradigm, and it's not natural, making it a bit of a pain to make it fit?

I've started by reading two good articles, here and here. The first thing I'd like to do is parse this excerpt from that first link:

There is also a need to also support non-SOAP services, especially over HTTP, where you can harness the power of the HTTP protocol to create HTTP services: services that are activated by simple GET requests, or by passing plain XML over POST, and respond with non-SOAP content such as plain XML, a JSON string, or any other content that can be used by the consumer.

First, about non-SOAP services. I understand JSON being non-SOAP, but why is XML non-SOAP? Isn't SOAP really just XML? Perhaps SOAP is XML, but it's XML wrapped in a SOAP envelope, header and body. So, that's the difference? SOAP isn't only XML, it's XML inside SOAP.

What is the power of the HTTP protocol? Is is that we can use simple GET and POST requests, or is there more than that?

Understanding the Conclusions From the article mentioned above:

If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF.

Why? Because HTTP GET and POST simply don't work that way?

If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.

It's not even an issue of being better off, right? I mean, if Web API is only HTTP, then we simply CANNOT use it for anything other than HTTP.

If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.

Makes sense.

Don't Waste Your Life

I’m going to share a personal and embarrassing story. I’m doing so because I hope it will help others that find themselves in a similar situation.

Tony Zmarzly:

Six months ago I was invited to audition for a band. My friend, Tony, asked me to come jam with him to see if it would work. I was nervous. I drank a few beers to help with that. It was obvious from the start that I wasn’t good enough to be in his band, or probably any band, for that matter. In fact, after I played along to the first song, Tony asked: “Could you hear the music?” I can laugh at that now, but it wasn’t a pleasant moment.

Since we both knew early in the evening that it wasn’t going to work, I thought the night was going to be an embarrassing disaster. But, to my surprise, Tony wanted to keep playing. I felt like leaving after the first song so I didn’t embarrass myself further. I ended up staying, and we played music for a couple of hours.

Near the end of the night, I asked him what he thought. As part of his summary, he told me I had “a long way to go.” But he told me all of this in a classy and respectful way. He had the courage to be honest and tell me the truth. He didn’t cop-out with something like: “You’re good, but we still need to check other drummers.” I’m grateful that Tony was honest while still being respectful. The truth was disappointing, but at least I finally knew where I stood. I had two choices at that moment: be depressed and sell my drums, or put in the effort necessary to become a good drummer.

Two months later, I started taking drum lessons at BGSU’s College of Musical Arts. I was lucky to have found an excellent drum teacher in Dave Nelson. I have also played at least 18 hours per week since the beginning of 2014. Now that I was actually and seriously dedicated to drumming, I had a drum room built in the basement. I posted a picture of it on Facebook.

Ramsey Abu-Absi:

After I posted a picture of my new drum room, Ramsey said we should get together and play. Honestly, my first thought was: “he’s just being nice.” That’s Ramsey; super-nice, all the time. When I realized he was serious, I told him that would be great, but deep down I was hoping it wouldn’t happen. Ramsey is a great guitarist. I’m a crappy drummer. I was worried that I would be wasting his time.

The day before we were supposed to get together, I sent him a video of me playing a song. I told him: “This is what you’re getting into.” I guess I wanted him to see me play, and then be able to gracefully bow-out with an excuse. The funny part of this is that he didn’t reply for quite a while. And when he did reply, he said that he was sick and might not be able to make it. I laughed and thought that I had given him his out. However, he told me the next day that he felt much better, so it was on.

I was nervous when we played the first song. However, Ramsey didn’t have time to practice, and he was actually making a couple of mistakes and needed a little time to learn on the fly. I thought, wow, this doesn’t have to be a perfect session. Ramsey kept telling me that it’s all for fun and we’re going to make mistakes. Just have fun and play. After that first song, I wasn’t nervous and had probably the best time drumming in 20+ years.

Mark Bostleman:

Mark had a two-word reply, to a Facebook post, that meant a lot to me. I don’t remember the exact wording of the question, but it was something like: “If you could tell your younger self anything, using just two words, what would it be?” His answer was:  “Do it.”

That simple answer made me think. When I’m 70, do I want to wonder what would have happened if I really gave drumming a serious shot? Or not even drumming, but at least one thing that I really went after and made it my thing? I decided for that thing to be drumming, and I’m having the time of my life now. I’m happier overall, and I’m getting better at it. It’s more enjoyable to play now that I’m getting better.

I’m 43 years old. I had thoughts of it being too late to try and be a very good drummer. But, you know what? I don’t have to be the best drummer. In fact, I don’t have to be spectacular. I just want to be a very good drummer, and I’m on that path now. I'm still early on that path, but at least I'm on it!

Summary:

Life is too short. DO IT, before it’s too late. At least try and fail; that’s better than not trying. Seriously, if you try, then fail, so what? You’ve still gained something: at least you know where you stand. And at least you had the courage to try. And you can decide if you want to give up. You can also decide to stop watching reruns of Family Guy and go after what you want in life. I did it, and I’m so happy that I finally stopped making excuses. I tried. I failed. And it was a great thing. Now, if you'll excuse me, I'm going downstairs to drum...

Update:

Tony invited me to come practice with his band on 30-Aug-2014. I sat in for their drummer who wasn't available to practice that day. I've also practiced with them the last two weeks, performing 13 songs. The practice time is starting to pay off and I look forward to filling-in whenever they need someone.

Update #2 (16-Oct-2015):

I've been with the band for four months now. We're doing our third gig tomorrow. We have 70+ songs. I guess it all worked out...