I’m complicated, man.
I’m complicated, man.
Had a good buddy ask me a few minutes ago about exposing data entities in WebAPI. It’s quick, and almost painless…
Start with creating a new project called WebServices or the like in Visual Studio 2013. Select the WebAPI profile – we’ll only need MVC/WebAPI pieces, not webforms, for this sample.
Start with an Entity Framework data model – here I used the Purchasing.Vendor table from AdventureWorks2012. If you don’t have EF, but it’s POCO, no biggie – you can still right-mouse click on any of the entities and generate views/controllers. Build the project – EF uses Reflection so we need to run a build to work with these entities and expose them in WebAPI.
Right mouse click on the Controllers folder and select Add, New Controller.
In the next screen select the Web API 2 Controllers option.
In the following screen, select your exposed table and make sure you generate a new Data Context as below. I always use the async controller actions by default.
Visual studio will think a little, and then you’ll see the auto-generated class. Look at all those scaffolded goodies!
Run a publish, and navigate using one of those handy REST api calls documented above. For example, sending <myserver>/api/Vendor returned this:
I’m going to attach the ZIP folder of the project. So easy, it feels like stealing!!! WebAPISample
For more detail, see the post here – https://driftboatdave.com/2014/01/13/webapi-the-new-wcf-data-services-and-knockoutjsmvvm-explorations/
Currently we’re examining different ways of coming out with a second version of our shopfloor software, and there’s a lot of pressure to start rolling out a UI – even ahead of a stable data layer, or wireframes of how the end users want to have it interact and display information to our user base.
UI code is expensive. Putting a few days into asking some basic questions about unspoken requirements is cheap. Otherwise, you’re faced with the age-old “you gave me what I asked for but not what I wanted” relationship-ender that’s the bane of so many IT projects.
Usually business and user requirements will be defined (to some extent) at the beginning of the process. Let’s talk about system requirements – both functional and non-functional.
Functional requirements (what the system must do – “the system shall notify the administrator when a package fails) include things like the following:
Non-functional requirements (how the system should operate – “what’s an acceptable amount of uptime?”) include:
Actual users will help you with the functional requirements; non-functional requirements will come from stakeholders. Once stakeholders are identified, you can gather requirements with a variety of methods (interviews, focus groups, questionnaires, observation (either direct or indirect), documentation, and researching similar projects.
Once this is done, you could split up your target audience into personas (including a name, photo, demographics, a descriptive paragraph, and needs/goals/features from a user perspective). Once this is done, you can refine your broad list of requirements into a very fine-tuned list of requirements – including a rationale, success criteria, and a level of importance. This key and often overlooked step will help you deliver a project that the users need, instead of just what they want.
For my project, I doubt I’m going to go as deep into the sensy-style personality demographics that some do – for an internal system we’re not customer-focused enough to care where someone falls on the liberal-conservative or trendy-status quo axis. But I will take the time to recognize that we have three user types – Operator, Engineer, Admin, and Executive – and split up broad requirements into a more focused matrix. This will give us an actionable list of to-do’s, so we won’t waste time writing UI code that doesn’t fill a specific need. Something like this…
As I refine this and get a survey going – our stakeholders are tied up 90% of the time in meetings, so an online survey on SharePoint or SurveyMonkey may be the go-to solution – I’ll create some new posts. I’m happy that we’re being a little more methodical in our second version of the software. Nothing’s worse than thrash when it comes to developer happiness and productivity!
Here’s some good interview tips when you sit down in front of a panel:
Does this feel sneaky? Dishonest? It shouldn’t. You genuinely do want the position, right? And isn’t it in everyone’s best interests to keep your responses short and not fill the room with a lot of hot air? If you are projecting the image of who you are, that’s not dishonesty – it’s putting your best foot forward. These tips came from a life coach – a psychologist – and a friend of mine paid thousands of dollars for these five tips. Try them, and see if you don’t have easier interviews that actually go somewhere.
This is floating around the internet; there’s different versions (anywhere from 15 to 19 to 25) – all are funny.