173 posts tagged with "technology"

Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ.

This is part two in a series. Part 1.

Let's start with Node.js. I already let you in on the fact that formatting a message for .Net to pick it up is tricky, and I won't get into the detail of that yet. For now, let's concentrate on setting up node.js and communicating with RabbitMQ. We'll get the finer points of interacting with .Net later.

Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ. Naturally, such a test does nothing to prove that one framework is generally faster than the other, but it is a fun exercise nonetheless.

Thus the challenge is this: accept a string message via POST, forward it to the service bus, and return HTTP Status Code 202 (Accepted) along with an acknowledgment that repeats the original message. Both REST services should be self-hosted; free from additional cruft like error-handling*; and should utilize an url like http://localhost:port/Message/mymessage, where "mymessage" is the string to be sent across the bus.

Basic was the first language I learned. Well, partially, in 8th grade. On Apple IIe at school and a Packard Bell 386 PC at home. A few years later, JavaScript came out and it became the first "modern" language I used. As an undergraduate physics major, I found it useful for quickly generating sample data or running some numerical approximations (simpler than Mathematica). Then I wrote a few web minor pages with DOM manipulation, before any of the modern frameworks had come out. I went to work, used it occasionally, but never had any excuses in work or home life to do more than dabble. The revolution was passing me by.

Windows Communication Foundation (WCF) is a great tool for building client/server applications in the .Net environment. It is one of those technologies that can be challenging to dig into when services are just one of many tools needed to assemble a business application, as opposed to being an end in itself. With some of my co-workers in mind, here are some of the lessons I have learned in using WCF for internal, line-of-business, applications. These notes, which will be published in several parts, assume a basic understanding of WCF and contracts.

I have set myself the goal of learning how to develop a Windows user interface with a moderately complex workflow, one that implies a Wizard-like set of screens to guide the user through a set of steps. The demonstration project's architecture will utilize the Model-View-ViewModel (MVVM) pattern, with the help of Caliburn.Micro (CM). The solution will utilize the Application Controller pattern and CM's Conductors.

This is a technical blog, right? Why would I mention this virtue? In Management 3.0, Jurgen Appelo suggests in "Do-It-Yourself Team Values" that the various Agile, Lean, XP, etc. principles are, quite simply, virtues. Teams should pick a small number and focus on them. "Kindness" is not among the 50 virtues he suggests thinking about, but it should not come as a surprise that that my rationale for "kindness" will overlap that of many other virtues, such as "helpfulness," "mindfulness," "tactfulness," and "service." Each of these single words offers a slightly different window into an ineffable world of human goodness, and I choose "kindness" for this theory. First, a minor digression.

Hypothesis: at the beginning of their careers (and perhaps well into them), most software developers think written/verbal language skills are of little importance to their field. To the contrary: as with most science and engineering fields, where language arts and communications classes are seen as secondary at best, the truth is that communication skills are critical to success. Being "coherent" means that one is able to express himself in clear terms, logically and consistently. This ability is essential in both code and "regular" language.

Like many, when I first encountered the term "agile software development," I thought it was an excuse for a cowboy culture: low planning, low documentation, run as fast as you can and assume that each person's brilliance will take care of everything. Since it came up in the context of a very large client asking us about our methodology ("what's a software development methodology?" I asked myself), I thought I should dig into a little more. Integrating Agile Development in the Real World, by Peter Schuh, quickly showed me it is not that simple. Agile development is, in fact, all about fostering a systematic, right-sized, just-in-time development process. For me, being "agile" means embracing change instead of being locked into preconceived notions (requirements). But don't throw everything out the window either.

Executable tests are the best form of requirements documentation. They improve quality through early discovery of bugs and by fostering a more detailed "what-if" analysis: what if we have this input X? What if the user does Y?

Configuring a WCF service across security boundaries can be a tricky business, or so I learned recently. Testing went well, but the move to production failed for a WCF client/server scenario, with the client application encountering an error: SOAP security negotiation with '<myEndpointAddress>' for target '<myEndpointAddress>' failed. See inner exception for more details. Inner exception: The Security Support Provider Interface (SSPI) negotiation failed.