82 posts tagged with "programming"

Many social websites, and web-based applications, have a notification process where the server sends a signal back to the browser, informing that particular user that there is a message. "You've got mail," as America On-Line used to say it. Consider the picture below, from Twitter, which shows that I have one new notification. That number increments automatically when a new notification arrives, without having to reload the full page. How does that work? Well, this blog post doesn't try to answer that directly. In fact, it is simply a collection of notes pointing out how to use Microsoft's SignalR technology to achieve this.

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.

As a "team lead" software engineer, I feel that an important part of my role is to ensure that the code is simple, but not necessarily easy. In fact, when I hear a developer say that "using this approach is easier," I have to fight the urge to lower my tail and growl menacingly.

Granted: code that only a senior developer, or worse yet only the author, understands is likewise unacceptable. Show me a piece of code that is too complex and abstruse, and we can have a conversation about (a) object oriented design theory and patterns, (b) refactoring to more self-explanatory methods, and (c) adding some appropriate formatting, comments and/or external documentation for blocks of code that are still unnerving. After all, "Everything should be made as simple as possible, but not simpler," to (supposedly) quote Einstein – and frankly, general relativity is still hard to understand without significant study.

Recently I have been looking at ServiceStack's OrmLite "Micro ORM" as a light-weight alternative to Entity Framework. It is relatively easy to use and very powerful, with capability for both code-first and database-first development. After learning the basic interaction, it was time to flip back into TDD-mode.

And then I found quite the challenge: I wanted to write unit tests that insure that I'm using OrmLite correctly. I was not interested (for the time being) in testing OrmLite's interaction with SQL Server itself. That is, I wanted behavioral unit tests rather than database integration tests. Time for a mock. But what would I mock? This ORM framework makes extensive use of extension methods that run off of the core IDbConnection interface from the .Net framework - so it would seem that there is no way to take advantage of Dependency Injection.

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.

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?