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...

This webpage has a redirect loop - Chrome and blogspot.com

When using the Chrome browser to visit some sites, including blogspot.com, I would get an exception:

I tried various suggestions that I found, but for me the answer was trivial. The problem occurred when I went to:

inaspiralarray.blogspot.com

I noticed a lone reply on a message board that said to try including www in the URL.

www.inaspiralarray.blogspot.com

That worked. Don't know why. Hope it works for you. By the way, I only had this issue in Chrome.

Steely Dan - Black Cow - Drum Sheet Music

I couldn't find this online anywhere, so I wrote it myself.

We’re not a software shop. Yes, you are.

One of the things that has bothered me over the course of my career is hearing statements like this:

“We’re not a software shop. We just make <product here>.”

The typical scenario for a statement like this is the “justification” of cutting corners on software development:

Since the company really does not develop software, it’s okay for all the other departments to come up with a project plan and how long it will take, then hand that date to the software development team. Never mind that the deadline is not enough time to produce a quality product; it’s just the software piece. It’s good project management to make the software team hurry and hit the deadline.

What’s worse, programmers even use this excuse. And the business loves that.

That is, until the business finds itself mired in constant support, production problems, using unreliable data, and feature enhancements taking longer and longer to complete. The business can think of their situation in these possible ways:

* This is normal. This is just how software development works. We have a lot of production issues, but our team works hard to constantly keep it running.

* The software development team used to be fast and good, but now they’re slow and write a lot of buggy software. They must not care as much as they used to. We need to push them even harder.

* We must have been approaching software development the wrong way. Let’s stop and analyze why things are this way, and see what we can do to develop software the right way.

That last bullet point is rare. Why? Because only companies that “get” software development would ask those questions. And those companies would have done it correctly in the first place. It can happen, though, if enlightened employees are hired during this process.

The first bullet point is an unfortunate situation. Things could be better, but no one sees it, and the business keeps moving, albeit at a slower and slower pace. This is just how things are.

The second bullet point is tragic. The software team has put themselves (yes, it’s their fault) in the terrible situation of having to hurry and create bad software, and for their efforts they are now not trusted by management. They’ll typically spend nights and weekends (and early mornings) fixing things, and adding new things, because that’s what it now takes to keep things running. And many times the development team will do this covertly, because they don’t want management to know that yet another problem occurred. In the end, the software team gets burned out trying to keep up this pace, or management replaces them with offshore developers.

When your company depends on the software that it writes to keep things running and profitable, I hate to break it to you, but you are indeed a software shop. You’re just not admitting it.

Deadlines as excuses for writing poor quality code? No.

Someone said this to me:

"We never get a chance to clean up ABC code or to refactor it.”

My reply:

The business will never explicitly give you that time. It’s up to you (indeed, all of us) as professional developers to not use deadlines as excuses. There is no deadline in the world that should cause a seasoned developer to duplicate code. It’s up to us, with a commitment to quality, to push back when we’re told to hurry. If we don’t do that, who will? It’s professional negligence to use deadlines as excuses. Most businesses think they have done good project management work if they get the developers to hurry and produce the end result more quickly. They don’t realize how much they’re hurting themselves in the long run by sacrificing maintainable code.

Many times deadlines are arbitrary guesses that folks came up with at the beginning of a project. They’re meaningless. They’re actually worse than meaningless because being forced to hit them is detrimental to quality. It’s okay to let the business know that the work won’t be done “on time.” Many developers think they’re trapped into hitting a deadline, when if they just did quality work, and explained the situation to the business, the “deadline” could be moved, or code could be time-boxed. Sacrificing quality, to the degree that I’ve seen in ABC code, should never be an option.

scriptcs in Two Minutes

Want to say you've used scriptcs? Follow this post and you can say that in about two minutes.

(For the longer version, go here: https://github.com/scriptcs/scriptcs)

At a command prompt, run this:

@powershell -NoProfile -ExecutionPolicy Unrestricted -Command "iex ((New-Object Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

Then run this:

cinst scriptcs

That's it. Really. Now you can write C# at a command prompt:

C:\>scriptcs

scriptcs (ctrl-c or blank to exit)

> var message = "Hello, world!";

> Console.WriteLine(message);

Hello, world!

Want to save some C# and run it any time? Do this:

C:\Temp>copy con helloworld.csx

var message = "Hello, world!";

Console.WriteLine(message);

        1 file(s) copied.

C:\Temp>scriptcs helloworld.csx

Hello, world!

Note: I got an error when trying to run this at the root of the C: drive, so I just switched to my temp folder and it worked.

Enjoy!