API: Top-Down? Bottom-Up? Somewhere in the Middle?

A Quick Brain-Dump on API Desgin I'll keep this one pretty brief as I haven't totally nailed down my thoughts on this. I still thought it was worth a quick little post: When you're creating a brand new API to expose some functionality of a system, should you design it with a strong focus on how the internals work? Should you ignore how internals work and make it as easy to consume as possible? Or is there an obvious balance? I find myself trying to answer this question without ever explicitly asking it. Any time I'm looking to extend or connect systems, this is likely to come up. Most Recently... Most recently I started trying to look at creating an API over AMQP to connect my game back-end to a Unity 3D front-end. I had been developing the back-end for…

0 Comments

MyoSharp – Update On The Horizon

MyoSharp If you haven't checked it out already, my friend Tayfun and I created an open source C# wrapper for Thalmic's Myo. It's hosted on GitHub over here, so you can browse and pull down code whenever you want. We've had some great feedback from users of our API, so we continue to welcome it (both positive and negative!) in order to improve the usability. Thalmic has plans to release a firmware update to allow more data to be accessible through their API. Right now, MyoSharp is a bit out of date, but once this big firmware update lands we'll take some more time to get it up to date again. Remember, it's open source so you can feel free to contribute! Troubleshooting The most common question I receive is "I keep getting an exception about not being able to connect…

0 Comments

ProjectXyz: Enforcing Interfaces (Part 2)

Enforcing Interfaces This is my second installment of the series related to my small side project that I started. I mentioned in the first post that one of the things I wanted to try out with this project is coding by interfaces. There's an article over at CodeProject that I once read (I'm struggling to dig it up now, arrrrrghh) that really gave me a different perspective about using interfaces when I program. Ever since then I've been a changed man. Seriously. The main message behind the article was along the lines of: Have your classes implement your interface, and to be certain nobody is going to come by and muck around with your class's API, make sure they can't knowingly make an instance of the class. One of the easiest ways to do this (and bear with me here, I'm…

2 Comments

ProjectXyz: Why I Started a Side Project (Part 1)

ProjectXyz Alright, I'll admit it... Even for a placeholder name on a side project it's pretty terrible, right? Well, my apologies. So, if you made it to this post you might be wondering what ProjectXyz is and why I started it up. From a high level, I started working on ProjectXyz so that I could have a hobby programming project to tinker with and I figured I'd blog about my adventures in bringing it all together. I plan on making this a mini-series documenting some of the things I'm learning or experimenting with, so this will serve as the intro to the series. Before we get too far, here's the link to the GitHub site: https://github.com/ncosentino/ProjectXyz Why Have a Side Project? Here's the main thing I want to talk about in part 1 of this series: Why should you have a…

3 Comments

Controlling a Myo Armband with C#

Background Thalmic Labs has started shipping their Myo armband that allows the wearer's arm movements and gestures to control different pieces of integrated technology. How cool is that? My friend and I decided we wanted to give one a whirl and see what we could come up with. We're both C# advocates, so we were a bit taken back when we saw the only C# support in the SDK was made for Unity. We decided to take things into our own hands and open source a Myo C# library. We're excited to introduce the first version of MyoSharp! The underlying Myo components are written in C++, and there's only several functions that are exposed from the library that we can access. In order to do this, we need to leverage platform invocation (PInvokes) from C# to tap into this functionality. Once you…

16 Comments

Refactoring For Interfaces: An Adventure From The Trenches

Refactoring: Some Background If you're a seasoned programmer you know all about refactoring. If you're relatively new to programming, you probably have heard of refactoring but don't have that much experience actually doing it. After all, it's easier to just rewrite things from scratch instead of trying to make a huge design change part way through, right? In any mature software project, it's often the case where you'll get to a point where your code base in its current state cannot properly sustain large changes going forward. It's not really anyone's fault--it's totally natural. It's impossible to plan absolutely everything that comes up, so it's probable that at some point at least part of your software project will face refactoring. In my real life example, I was tasked with refactoring a software project that has a single owner. I'm close…

1 Comment

Yield! Reconsidering APIs with Collections

Yield: A Little Background The yield keyword in C# is pretty cool. Being used within an iterator, yield lets a function return an item as well as control of execution to the caller and upon next iteration resume where it left off. Neat, right? MSDN documentation lists these limitations surrounding the use of the yield keyword: Unsafe blocks are not allowed. Parameters to the method, operator, or accessor cannot be ref or out. A yield return statement cannot be located anywhere inside a try-catch block. It can be located in a try block if the try block is followed by a finally block. A yield break statement may be located in a try block or a catch block but not a finally block. So what does this have to do with API specifications? A whole lot really, especially if you're dealing…

0 Comments

API: Don’t Forget About The Non-Public API!

Background From an object oriented programming perspective, an application programming interface (API) is often referred to as the way other developers can interact with the public members of your class(es) and interface(s). Of course, API can be used to describe how one interacts with a web service (or other types of services), but for this discussion I'm limiting the scope to that of interfaces and classes. Limiting the definition of API to public members (or the equivalent of C#'s "public" in other languages) is omitting one huge part of what it encompasses. The purpose of this post is to clarify, in my opinion, why I think forgetting about the non-public API can lead to bad framework and API designs. API And The Audience I've written before about what I think makes a good API, and I had some comments on Code…

4 Comments

Keep Your Fields Private

Background A recent discussion about this spurred a bit of a debate. Ever since I can remember, I've always been told to keep fields private. If you want to expose them any more than private you should use a property. Of course, I was defending my stance on this and figured I should see what other people were saying. I turned to the trusty Stack Overflow (SO) for some answers. Argument For: Control One of the major categories of arguments for keeping fields private has to do with control. Some great points brought up by SO posters included that properties allow you to easily add verification to your data storage. With a field inside of your class, your control is over how this variable is manipulated is constrained to the class. As soon as you expose something outside of the class,…

0 Comments

Interfaces: Why You Should Be Using Them In Your Code

Background As a developer, there's often a point when you're tasked to build something that's a key part of the architecture of your software. Maybe it's not a key component to the all of the application, but it's pretty foundational at least for a part of the application. Often we put our thinking caps on, plan a bit of what we're about to code, and then dive right into it. If you do TDD, you might go start coding your tests but regardless of your approach, you're likely going to start coding some classes pretty soon and forget completely about the use of an interface. You shouldn't.   Start With Interfaces In my opinion, if you're writing code that's part of your application's foundation, you should start with interfaces. If you're already rolling your eyes and whining to yourself that…

0 Comments

End of content

No more pages to load