Using Social Media Marketing to Fail Better

by freyar 11. February 2013 13:48

Sometimes it’s hard to make the case for a big investment in social media marketing. It can be difficult to scale, time-consuming, and there’s always the risk of—gasp!—negative feedback.

Socialnomics makes an excellent argument for making social media marketing not just important, but central to the mission and products your company creates. Erik Qualman’s second edition of this book came out a couple weeks ago. Rather than focusing on the nuts and bolts of implementation, it's a wonderful conceptual framework for the importance of social media. It also takes a stab at what's just around the corner, which is very exciting.

My favorite quote so far: "Fail fast, fail forward, fail better." Quick iterative innovation is the watchword, and an engaged conversation with customers is necessary to make that happen. The new climate for product development involves intense competition, margins squeezed by the wide availability of similar products, and a need for speed. He argues that it’s better to move quickly than study something to death and have others beat you to market. But once you move quickly out the door, and some parts of your product fail, you need to respond just as fast.

This requires an ongoing, engaged conversation with your customers. You only fail forward, you only fail better, when you listen to your customers. Qualman argues that social media is the best way, perhaps the only way, to listen to your customers quickly and deeply enough to drive rapid development cycles. It’s not about releasing a half-baked product. It’s about speeding up the product’s improvement cycle, which is something we can all benefit from.

Release, listen, improve, release. Rinse and repeat. At Exsilio, our Social Media Marketing team focuses on embedding inside your organization’s message, and can help you sort through the noise to listen better.

It’s hard for many organizations to be so nimble in their product/service development, though. What challenges are you experiencing?

Forward Engineering with Visio 2010

by luisp 15. April 2011 14:35

 

Many of us by now are familiar with Visio and its Reverse Engineer capability, where you point Visio to a data source and it can generate a somewhat decent database model of the said database. It’s a pretty handy tool to get you started. But what about taking a database diagram and "forward engineering" it? 

Last week I had and project where I needed to normalize a database. The first thing I did was open up Visio and reverse-engineer the existing db. Once I had made all the changes that I wanted to make I downloaded a handy tool from Codeplex that allowed me to "forward engineer" my diagram and generate a script to create the new and improved objects including indexes as well as primary and foreign keys. It is an add-in to Visio and ends up adding a tab to the ribbon for all your Forward Engineering needs. 

 

 

After I ran that script on a blank database all I had to do then was run a delta comparison using (SQL Delta) of the new database with the new objects against the old database. That gave me an update script to run on the old database. Once that was done the old database was up to date and was fully normalized to the specs of my Visio diagram.

Memory Management in .NET : Garbage Collector [GC] - Introduction

by Gita 6. March 2011 22:14

Introduction

.NET offers many useful features like Base Class Library [BCL], Just in Time compiler [JIT], intermediate code known as MSIL, code access security and Garbage Collector aka GC. GC is responsible for memory management and is credited with the success of .NET platform as well as some really strange stories [1].

Basics of Memory Allocation

In .NET, value types are stored on the stack and reference types [objects] are stored on heap. On deeper examination – you will find that pointers to the object are stored on the stack but the actual object memory is allocated on heap.  In .NET, heap based memory is managed by GC.  GC frees up the programmer from keeping count of elements stored in an array, reference counting, etc. and provides protection from common memory leaks and buffer overrun problems.  

Figure 1: Memory Allocation

GC Roots – A brief explanation 

 

GC roots represent memory locations always reachable from the program. There are four types of GC roots – a local variable in the method, static variables, managed object passed to COM and objects that implements Finalizers. Reference counting logic is used periodically to examine GC roots and to mark objects not required in future.

  All objects for which we have active reference in GC roots will be marked as “live” and objects for which GC cannot find reference will be marked as “ready for collection”.  Objects marked as ready for collection are removed from memory during GC sweep process. [GC operates on “mark and sweep” principal -more on this will be covered in future posts]. 

 GC distributes available memory in different generations as Generation 0, 1 and 2 as explained below. 

 

 

Figure 2: Managed Memory

 Objects always start in Generation 0 of GC. All objects that survive one cycle of Generation 0 collection get promoted to Generation 1. All objects that survive one cycle of Generation 1 collection get promoted to Generation 2. Garbage Collection for Generation 2 will cause collection for Gen1 as well as Gen 0 - also known as full collection.

GC Mode of operations: Concurrent Vs Synchronous [5]

GC supports concurrent or workstation as well as synchronous or server mode of operations. Usually, concurrent mode is used in desktop applications and synchronous mode is used in server applications like ASP.NET. In concurrent mode, GC will avoid stopping the application while garbage collection is in progress. In Synchronous mode, GC will suspend the application operation while garbage collection is in progress. Mode in which GC will operate has direct impact on application performance.  CLR supports Workstation GC with Concurrent GC off [default option], Workstation GC with Concurrent GC on and Server GC mode of operations. GC mode can be set in the configuration file of the application [4].

In future posts we will delve deeper into the generational logic of GC and how memory is managed. We will also explore the impact of application level code on GC behavior.

References:

1. http://www.codeproject.com/KB/showcase/IfOnlyWedUsedANTSProfiler.aspx
2. http://en.wikipedia.org/wiki/Heap_(data_structure)
3. http://msdn.microsoft.com/en-us/magazine/bb985010.aspx
4. http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry
5. http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/

A Dose of Theory - Why MVVM?

by jhagal 3. March 2011 14:15

So, how about that Silverlight?

After a rocky initial few years, Silverlight's become quite the tool for creating rich internet applications, not to mention Windows Phone 7 applications. It does this by bringing the power of .NET directly into the web browser, via a plug-in. This brings one huge advantage: Silverlight, at its core, is a client application. That's right, despite being delivered over the web, Silverlight apps are built very similarly to a client application. There's no special tricks keeping track of state, requests from the user can be handled by event handlers, and all that good stuff. It's much easier to make a well- designed application because you don't have to constantly worry about reinstantiating objects. This also means you are freed from the anti-pattern design of ASP.NET. So, what's the best way to make maintainable and reusable code in Silverlight? MVVM.

It works in WPF too, FYI, but I'm ignoring that for now.

The usual response to inquiries about MVVM is, "Yeah, I've heard about it," with the "What IS it?" being implied. This is partly because MVVM hasn't been well publicized, and that's partly because it hasn't really been standardized. So the simplest answer one can give to the question of "What is MVVM" is that it is a design pattern. I'm not going to diverge off onto what design patterns are, except to say that (as Captain Barbossa might say) it's more what you'd call "guidelines" than actual "rules." However, MVVM is more than a design pattern, it is really the design pattern to use in Silverlight. The reason for this is straightforward - it takes advantage of the unique relationship that Silverlight has between the Presentation Layer and the UI Layer. Silverlight may be a client app dev tool, but that doesn't make it a WinForms app dev tool. I learned this distinction. WinForms design patterns don't take advantage of that unique UI layer, but MVVM does.

It stands for Model-View-ViewModel, BTW

MVVM describes the relationship between the Model, View, and the ViewModel. The Model and the View are pretty easy to understand. The Model is your collection of domain objects, and your business logic. The View is where you display your Model, listing domain objects, and listing their attributes. The ViewModel is the real meat of the MVVM model, and is the reason that MVVM is so necessary to a Silverlight project of any complexity. Again, this isn't official, and it isn't standardized really (again, guidelines), but at its core the ViewModel is where you hold the databinding logic that connects your View to your Model's data. Now, this is relatively unique as far as Presentation layers go. Usually, if databinding is to happen, it can't happen in the Presentation layer because the Presentation layer is too far removed from the UI. So what ends up happening is either the Presentation layer and the UI are smashed together, or the databinding happens all in real time and debugging becomes a pain. However, Silverlight's UI has built in hooks to allow for databinding to another object. This entirely changes how the UI relates to the Presentation Layer, because now the Presentation Layer can basically be anything. In fact, if you wanted, you could connect the UI directly to the Model.

Wait, what? Why don't we just do that?

So why the ViewModel? Why MVVM and not just ... MV? Because, as you can imagine, the model is meant to contain ONLY business logic. And if all you were doing, ever, was displaying the attributes of your object, then that could work, as you'd have no presentation logic. For relatively simple Silverlight apps, that could work just fine, more than likely. That raises questions though - what happens when an artist wants to work on the view? What happens when you want to test the UI? What happens if you want one view to show data from multiple domain objects?

This is where the ViewModel comes in. It provides the databinding layer for your UI to connect to. And in this databinding layer you can pull from multiple domain objects, you can sort lists, page lists, split things up and combine things together for display on the view. And the best part? You can even display dummy data for design time. That's right! Now your designer won't have to just try to build something and wonder if that's going to look right. All he has to do is connect to the ViewModel, and dummy data shows up. Now the designer has something to design against, instead of just guessing. And he doesn't need to know any of the logic, because the ViewModel takes care of all that, and if something changes, he's not totally screwed because everything is loosely coupled. Trust me, on a project of any complexity (and even simple ones!) if you bind directly to the model you will eventually regret it. And then you'll have to make a ViewModel for just one View, and then your code is inconsistent and everything is ruined forever.

MVVM and Rapid Development

Like MVC and MVP, the slowest part of design patterns like MVVM is learning them. And like MVC and MVP, once you've learned MVVM, it is significantly faster than attempting to do it the anti-pattern way. Also, trust me on this one, it's signifcantly faster than pretending that Silverlight is old WinForms tech. (That gets you nowhere, slow.) Not only are these design patterns faster to develop against than just smashing code wherever you can, but they're more modular, they're more maintainable, they're easier (and quicker) to design against, and there's generally a lot less of going back and forth over the same code trying to figure out why it breaks every time you make a change. (Again, hard lesson on that one.) This means more time focused on adding new features, and less time trying to track down hard to fathom bugs. Also, there is a nice separation of interests in the code, which lets people figure out where things are faster. Combined with templating in Silverlight, this makes application development very quick.

So MVVM works well for rapid development - once you've learned it. But it's very much worth learning. On a side note, what about rapid development with RIA? Well, that's another post. But yes, it does work with RIA.

Man, so Microsoft must have totally built MVVM right into Silverlight! Err...Right?

So, hey, builtin stuff, yeah. That's most likely coming in Silverlight 5. There is a good reason that MVVM hasn't yet been built into Silverlight - it isn't that old, in all honesty, and it's still being developed, even in terms of theory. And more so, if Microsoft does include a solution, it has to be a solution that appeals to almost everyone. So it's taking a little bit to get to that point.

So in the meanwhile, there are various MVVM frameworks that have been built. The only one I've used so far is MVVM Light, developed primarily by Laurent Bugnion of Galasoft. Now he designed this framework with "Blendability" in mind. That is to say, working with designers who are using Blend is the foremost concern. He readily admits that if you are looking primarily for testability, or have other concerns, MVVM Light might not work out for you. There's also Caliburn and MVVM Foundation. Also, as mentioned earlier, MVVM isn't just Silverlight, it's also WPF. In fact, almost all the frameworks mentioned above support both Silverlight and WPF applications. So really, by learning MVVM you're getting a twofer on app skills. So hopefully, if someone out there is wondering why MVVM is useful, this has helped answer that question. Now you're wondering, hey, heavy on the "why", light on the "how", right? Well, that would quadruple this article, so I'll just post some links to others who have already written about it. Dan Wahlin, Shawn Wildermuth, and for WPF focused, Josh Smith.

Questions and comments welcome below.

Tag cloud